数据存储框架11

2019年12月12日 16点16分 没有评论

今天下午完成了扩容的测试。两个数据节点node444和node555除了系统盘(80G/SSD)外,每节点还有3块1T硬盘。测试内容为将node444上的三块1T硬盘容量加入到Hadoop资源池之中,然后上传存入一些文件。参考文档[1][2]。具体过程如下。

1.在数据节点node444上,将三块1TSATA硬盘(/dev/sdb,/dev/sdc和/dev/sdd)分区、格式化和挂载到node444的本地目录。

# fdisk /dev/sdb (创建一个主分区sdb1)
# fdisk /dev/sdc (创建一个主分区sdc1)
# fdisk /dev/sdd (创建一个主分区sdd1)
# mkfs.ext4 /dev/sdb1
# mkfs.ext4 /dev/sdc1
# mkfs.ext4 /dev/sdd1
# mkdir -p /data/stor_a
# mkdir -p /data/stor_b
# mkdir -p /data/stor_c
# mount /dev/sdb1 /data/stor_a
# mount /dev/sdc1 /data/stor_b
# mount /dev/sdd1 /data/stor_c
# vim /etc/fstab (开机自动挂载)
  /dev/sdb1   /data/stor_a    ext4    defaults    0 0
  /dev/sdc1   /data/stor_b    ext4    defaults    0 0
  /dev/sdd1   /data/stor_c    ext4    defaults    0 0

2. 在数据节点node444上,在hdfs-site.xml写入配置路径。其中“/opt/hadoop_tmp/dfs/data”是在core-site.xml中设定的路径,/data/stor_a是新增硬盘容量对应的挂载目录。

# vim /usr/hadoop-2.10.0/etc/hadoop/hdfs-site.xml     
 <property>
                <name>dfs.replication</name>
                <value>2</value>
        </property>
        <property>
                <name>dfs.datanode.data.dir</name>
                <value>
                        file:/opt/hadoop_tmp/dfs/data/,
                        file:/data/stor_a,
                        file:/data/stor_b,
                        file:/data/stor_c
                </value>
        </property>

3. 在数据节点node444上,重启datanode服务

# cd /usr/hadoop-2.10.0/sbin
# ./hadoop-daemon.sh stop datanode
stopping datanode
# jps
11276 Jps (可以观察到没有列出datanode)
# ./hadoop-daemon.sh start datanode                                                      
starting datanode, logging to /usr/hadoop-2.10.0/logs/hadoop-root-datanode-node444.out

4. 在任一节点上查看增加后的容量,可以看到node444的容量为2.73T,集群的总容量也发生了变化,即三块1T的容量已经加到资源池中。

# hadoop dfsadmin -report
DEPRECATED: Use of this script to execute hdfs command is deprecated.
Instead use the hdfs command for it.

Configured Capacity: 3054216757248 (2.78 TB)
Present Capacity: 2897777172480 (2.64 TB)
DFS Remaining: 2897528950784 (2.64 TB)
DFS Used: 248221696 (236.72 MB)
DFS Used%: 0.01%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
Missing blocks (with replication factor 1): 0
Pending deletion blocks: 0

-------------------------------------------------
Live datanodes (2):

Name: 172.16.20.40:50010 (node444)
Hostname: node444
Decommission Status : Normal
Configured Capacity: 3003662340096 (2.73 TB)
DFS Used: 124162048 (118.41 MB)
Non DFS Used: 3104387072 (2.89 GB)
DFS Remaining: 2850352889856 (2.59 TB)
DFS Used%: 0.00%
DFS Remaining%: 94.90%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Xceivers: 1
Last contact: Thu Dec 12 03:24:21 EST 2019
Last Block Report: Thu Dec 12 03:13:42 EST 2019

中间遇到并已经解决的问题:
– 在扩容的数据节点上必须重启datanode,否则无法生效。
– 在写配置文件hdfs-site.xml时忘写一个< /property>,排查花了一些时间。

关于上传文件,在NameNode的node333上使用命令行可以完成对应任务。我把node333中的jdk安装包和pdsh压缩包放到hadoop中,如下。

[root@node333 ~]# ls
anaconda-ks.cfg  hadoop-2.10.0.tar.gz  jdk-7u45-linux-x64.rpm  pdsh-2.26  pdsh-2.26.tar.bz2
[root@node333 ~]# hdfs dfs -put jdk-7u45-linux-x64.rpm /20191212
[root@node333 ~]# hdfs dfs -put pdsh-2.26.tar.bz2 hdfs://node333:9000/20191212
[root@node333 ~]# hdfs dfs -ls /20191212
Found 2 items
-rw-r--r--   2 root supergroup  122585894 2019-12-12 01:58 /20191212/jdk-7u45-linux-x64.rpm
-rw-r--r--   2 root supergroup     490732 2019-12-12 02:01 /20191212/pdsh-2.26.tar.bz2

上传后在Web界面中可以看到文件目录和列表。
2019-12-12 17-02-56屏幕截图

遗留的问题:
– 在Web界面中无法上传文件,估计是权限配置的问题,暂时没有找到解决方法。网上有文章[3]提到“By Default HDFS Web UI is read only, and files or directories can’t be created/modified.”
– 参考[2]和[4]修改hdfs-site.xml尝试让节点下线,发现指定下线节点并未出现Decommission状态。原因需要进一步调查。

分类: 大数据 标签:

数据存储框架10

2019年12月10日 15点42分 没有评论

今天装好了一个三节点的Hadoop。参考这两篇文章[1][2]。中文参考文档虽然详细,但是有些错误。记录我的安装步骤如下。

1.三个节点服务器安装CentOS7.2最小版,配置各节点无密码ssh登录(参考前几天的文章)。

2.在每个节点上安装JDK。在Oracle.com官网上注册,然后下载jdk-7u45-linux-x64.rpm,在每个节点上安装JDK并执行以下命令,用rpm安装后java的路径为“/usr/java/jdk1.7.0_45”。以node333为例:

# rpm -ivh jdk-7u45-linux-x64.rpm
# vim /etc/profile (修改配置文件,增加以下行)
    export JRE_HOME=/usr/java/jdk1.7.0_45/jre
    export JAVA_HOME=/usr/java/jdk1.7.0_45/
    export CLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
    export PATH=$PATH:$JAVA_HOME/bin
# source /etc/profile (使配置文件生效)
# java -version (检查安装是否成功)
    java version "1.7.0_45"
    Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
    Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

3.在节点node333,下载hadoop-2.10.0.tar.gz并解压到/usr下

# ls /usr/hadoop-2.10.0/

4.在节点node333,参考文档[2]配置hadoop。首先配置core-site.xml文件(注意将原文件备件),此次试验将node333设置为集群的namenode。

# cd /usr/hadoop-2.10.0/etc/hadoop
# vim core-site.xml

<configuration>
        <property>
                <name>fs.defaultFS</name>
                <value>hdfs://node333:9000</value>
        </property>
        <property>
                <name>hadoop.tmp.dir</name>
                <value>/opt/hadoop_tmp</value>
        </property>
        <property>
                <name>io.file.buffer.size</name>
                <value>131072</value>
        </property>
</configuration>

其次配置hdfs-site.xml文件(文件路径都在/usr/hadoop-2.10.0/etc/hadoop),设置副本数为“2”(默认为3?)。

# vim hdfs-site.xml
<configuration>
        <property>
                <name>dfs.replication</name>
                <value>2</value>
        </property>
</configuration>

接着配置mapred-site.xml文件,目录中没有这个文件,需要先根据模板生成。将node555设置为SecondaryNameNode。

# cp mapred-site.xml.template mapred-site.xml
# vim mapred-site.xml
<configuration>
        <property>
                <name>mapreduce.framework.name</name>
                <value>yarn</value>
        </property>
        <property>
                <name>dfs.namenode.secondary.http-address</name>
                <value>node555:50090</value>
        </property>
</configuration>

然后配置yarn-site.xml,YARN即Yet Another Resource Negotiator的缩写,是一个资源管理系统。将node444设置为resourcemanager。

<configuration>
<!-- Site specific YARN configuration properties -->
        <property>
                <name>yarn.nodemanager.aux-services</name>
                <value>mapreduce_shuffle</value>
        </property>
        <property>
                <name>yarn.resourcemanager.hostname</name>
                <value>node444</value>
        </property>
</configuration>

接着配置slaves文件,将各节点主机名加入:

# vim slaves
    node333
    node444
    node555 

在hadoop-env.sh中配置JAVA_HOME的路径

# vim hadoop-env.sh (修改对应行)
    export JAVA_HOME=/usr/java/jdk1.7.0_45/

最后再次配置/etc/profile 加入HADOOP_HOME执行路径:

# vim /etc/profile
    export JRE_HOME=/usr/java/jdk1.7.0_45/jre
    export JAVA_HOME=/usr/java/jdk1.7.0_45/
    export HADOOP_HOME=/usr/hadoop-2.10.0/
    export CLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
    export PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
# source /etc/profile

所有配置完成。

5.在node333上检查已经安装成功,可以显示正确的hadoop版本信息。

# hadoop version
Hadoop 2.10.0
Subversion ssh://git.corp.linkedin.com:29418/hadoop/hadoop.git -r
e2f1f118e465e787d8567dfa6e2f3b72a0eb9194
Compiled by jhung on 2019-10-22T19:10Z
Compiled with protoc 2.5.0
From source with checksum 7b2d8877c5ce8c9a2cca5c7e81aa4026
This command was run using /usr/hadoop-2.10.0/share/hadoop/common/hadoop-common-2.10.0.jar

6.在node333上,将hadoop文件目录和profile文件复制到其它节点(node444和node555)

# scp -r hadoop-2.10.0 root@node444:/usr/
# scp -r hadoop-2.10.0 root@node555:/usr/
# scp profile root@node444:/etc/ 
# scp profile root@node555:/etc/

我在之前的测试中,早早在各节点中解压了hadoop目录,没有同步配置文件,导致node333启动hadoop服务后没有找到数据节点。有些大意了。

在node444和node555上分别执行以下命令,使路径生效。

# source /etc/profile

7.启动hadoop。在node333(已设置为Name Node)上做初始化。

# hadoop namenode -format

2019-12-10 14-35-46屏幕截图

启动hdfs,在hadoop下的sbin下:

# ./start-dfs.sh

2019-12-10 14-44-05屏幕截图
在各节点上执行jps可以看到如下结果:

[root@node333 ~]# jps
7735 Jps
2618 NameNode

[root@node444 ~]# jps
2418 Jps
2207 DataNode

[root@node555 ~]# jps
10192 SecondaryNameNode
10086 DataNode
10526 Jps

8.在浏览器中访问集群,可以看到各节点状态。
11

DataNode列表
222

遗留问题,每个节点还有三块硬盘。这些未挂载未格式化的硬盘容量未体现在集群中,下一步解决。

分类: 大数据 标签:

数据存储框架09

2019年12月6日 14点59分 没有评论

一直以来都想找可以管理多台服务器的工具,今天研究了psdh,感觉比较方便。以下是通过Ubuntu的笔记本管理三台CentOS7.2的具体过程。配置成功的关键是就保证ssh无密码登录。参考了这两篇文章[1][2]

1.安装pdsh
我开始时以为需要被管理的CentOS也要装pdsh,后来证明是不用装的。在管理用的笔记本Ubuntu中使用

$sudo apt-get install pdsh

2.在Ubuntu的/etc/hosts中加入各节点名

172.16.20.30    node333
172.16.20.40    node444
172.16.20.50    node555

3.在Ubuntu上生成公钥,此时可用phillip。

$sudo ssh-keygen -t rsa

4.将公钥复制到被管理的CentOS服务器上。之前用Ubuntu的用户phillip+sudo会返回失败,必须先切换为Ubuntu的root用户,才能执行。在Ubuntu中执行以下命令:

$sudo -i
#ssh-copy-id root@node333
#ssh-copy-id root@node444
#ssh-copy-id root@node555

5.测试将所有服务器的时间于ntp同步,显示主机名。

$ sudo pdsh -w ssh:root@node[333,444,555] hostname
node444: node444
node555: node555
node333: node333
$ sudo pdsh -w ssh:root@node[333,444,555] ntpdate ntp1.aliyun.com
node555:  6 Dec 01:58:06 ntpdate[10235]: adjust time server 120.25.115.20 offset 0.013388 sec
node444:  6 Dec 01:58:06 ntpdate[2338]: adjust time server 120.25.115.20 offset -0.003958 sec
node333:  6 Dec 01:58:16 ntpdate[2405]: adjust time server 120.25.115.20 offset 0.001803 sec

在各个节点之前实现无密码ssh登录的方法和步骤:
1. 在节点(以node333为例),首先修改/etc/hosts,将其它节点主机名加入hosts

# vim /etc/host
172.16.20.30    node333
172.16.20.40    node444
172.16.20.50    node555

2. 在节点(以node333为例)上执行以下命令

# ssh-keygen -t rsa -f id_dsa (在.ssh目录下生成id_dsa和id_dsa.pub)
# cd .ssh
# cat ip_dsa.pub >> authorized_keys

3. 将生成的密匙id_dsa.pub复制到其它节点(node444和node555),

# scp .ssh/id_dsa.pub root@node444
# ssh root@node444
# cat id_dsa.pub .ssh/authorized_keys (导入复制过来的ssh_key)

这样node444和node555就可以无需密码登录node333了。依次在所有节点操作即可。

tmux很强大,使用了几天后才发现上下翻页只需要Ctrl+b,然后PgUp和PgDn就可以了。tmux的缓冲区命令用于vim或less等场景。

分类: 大数据 标签: ,

数据存储框架08

2019年12月4日 17点32分 没有评论

IOPS,即Input Output Per Second的缩写,表示每秒处理的输入/输出(I/O)次数; 单位时间内系统能处理的I/O请求数量。I/O请求通常为读或者写数据操作请求。

关注IOPS的应用: 随机读写频繁的业务,如小文件存储、OLTP数据库、邮件服务器。这类应用关注随机读写性能,以IOPS为重要的衡量指标。例如,读取10000个1KB文件,用时10秒。IOPS=10000/10=1000,数据吞吐量Throught=1000KB/s约为1MB/s。

关于数据吞吐量的应用: 顺序读写频繁的业务,如传输大量连续数据、电视台的视频编辑,视频点播。这类应用关注连续读写性能,数据吞吐量是重要衡量的指标。例如,读取1个10MB文件,用时0.2秒。IOPS=1/0.2=5,数据吞吐量Throught=10/0.2约为50MB/s。

机械硬盘的服务时间。传统的磁盘为机械硬盘,接口有FC/SAS/SATA,转速通常为5200/7200/10K/15K三种。注意此处的转速单位是rpm,即每分钟的转速(不是每秒)。决定机械硬盘的重要指标是服务时间,即完成一次I/O请求所花费的时间。机械硬盘的服务时间=寻道时间+旋转延迟+数据传输时间。

机械硬盘的数据读写方式: 磁头移动到数据对应的磁道-电机将盘片旋转到数据所在扇区-读写数据

寻道时间TSeek:是读写磁头移动到正确磁道上所需的时间。平均为3-15ms。7200转的平均寻道时间为9ms,10K为6ms,15K为4ms。
旋转延迟Trotation:是盘片旋转将请求数据所在扇区移至磁头下方所需的时间。旋转延迟取决于硬盘的转速,通常使用磁盘旋转一周所需时间的1/2表示。比如7200转硬盘的平均旋转延迟= [60(1分钟)x1000(1秒=1000毫秒)/7200]x(1/2)=4.17ms。这个时间与希捷官网上标识的延迟4.16ms是相同的。实际计算结果为4.16666(6无限循环)。10K的旋转迟延为3ms,15K的旋转迟延为2ms。
数据传输时间Transfer:完成传输所请求数据的时间,取决于数据传输率。其值=数据大小/传输率。SATA硬盘的数据传输率为300MB/s。数据传输时间通常远小于前两部分(寻道时间+旋转延迟),在简单计算时可忽略。

理论IOPS,即在1秒(这个1秒是根据IOPS定义的时间单位:秒)内完成上述读写过程的次数。计算公式为:
IOPS = 1秒/(寻道时间+旋转延迟时间+数据传输时间),数据传输时间相对较小,可以忽略。
以7200转机械硬盘为例子: IOPS = 1000ms(1秒=1000ms)/(9+4.17)=1000/13.17=75.93即76次。
10K IOPS=1000/(6+3)=111,15K IOPS=1000/(4+2)=167。可见,要提高IOPS,可以通过分别减小寻道时间,增大碟片转速和增大数据传输率来实现。在实际测试中,IOPS受到很多因素的影响,包括I/O负载特征(读写比例、顺序和随机、工作线程数、队列深度、数据记录大小)、系统配置、操作系统、磁盘驱动等。测试IOPS,必须尽量在同一基准平台进行,尽管如此还是会有一定的随机性。

分类: 大数据 标签:

数据存储框架07

2019年12月3日 17点13分 没有评论

当前视频记录应用的普及和物联网应用的加深,成为数据快速增长的主要推进剂。ZB级数据时代已经嗯到来,IDC分析显示到2023年,两者将贡献近100ZB的数据增量。特别是人工智能技术在视频监控领域的下沉和普及,未来大部分视频监控设备都具有AI能力。AIOT的迅猛发展,使得数据产生由人向机器不断延伸。预计到2023年,超过90%的数据将由机器生成,视频和物联网是主要的数据来源。

如何看到从传统视频向智能视频的转型?
如何从数据的角度赋能智慧视频发展?

从企业角度看数据发展,当前数据非常明显划分为三个层次: 数据产生的终端层面、数据初步汇聚分析的分布式数据中心层面(边缘),最大化提取数据价值的中央数据中心层面(中心)。

终端设备产生的海量数据,如果不加提炼和甄别就全部存储到边缘和核心,将造成资源的严重浪费。这也带动视频分析产品在视频监控领域的快速渗透。传统视频监控最大的特征是一个事后调查系统,案件发生时依靠人力在事后调取录像查看,视频数据保留价值低。而智慧视频会在每一个环节都发生革命性的变化,可以做到事发时实时报警甚至事前预警,视频保留价值明得到提高。从“有据可查”到“防患于未然”的趋势。

智能视频的生态系统:算法、算力和数据。
-算法,设计高效准确的AI算法,开发目标行业的应用。需要算法厂商不断努力。
-算力,计算算力不断提升,成本可控。需要AI芯片厂商发适合市场,可大规模使用的AI芯片。
-数据,存储厂商需要解决人工智能时代的大数据存储问题。

在终端:摄像头将产生大量随机读写结构化的数据,要求更高读写性能的嵌入式闪存产品。
在边缘:传统的边缘服务器向AI边缘和分布式云边缘转变,要求更大容量和更高的可靠性。
在核心: 随着更多视频图像数据不断从边缘/终端汇聚并累计,海量高数据价值存储量带来存储容量和成本的巨大提升。同时,随着云/边的AI训练及推理的增长,高性能的SSD必然被引入做为数据计算的缓存。

分类: 大数据 标签:

数据存储框架06

2019年12月3日 9点12分 没有评论

2019年11月底由中国通信学会举办的“2019天线射频系统与5G通信专题研讨会”上,中国电信技术创新中心副主任杨峰义说,目前困扰5G发展的一大难题是功耗。4G典型的基站功耗月1300瓦,5G为3500瓦。同样覆盖目标的情况下,5G基站的数量将达到4G的3-4倍,这样5G移动网络的整机能耗是4G的9倍以上。

根据统计,2018年三大运营商的移动基站年耗电量为270亿度,总电费约为240亿元。在同样覆盖的情况下,5G的能耗将达到2430亿度,电费达到2160亿元。5G庞大的用电成本将吃掉三家运营商所有的利润,还要亏损。即使未来总基站数达不到4G的3-4倍,总体运营成本也将大幅上涨。

杨峰义说技术进步降低功耗的空间是有限的,降低用电价格才是根本。他建议能针对5G用电出台相关的专享优惠政策。

分类: 大数据 标签:

数据存储框架05

2019年12月2日 16点39分 没有评论

希捷企业级硬盘8T以下容量为E系列空气盘,10T及以上的企业级硬盘为X系列氦气盘。E和X系列的缓存都为256MB,也支持高级写入缓存(2M内置NOR闪存)。经过咨询希捷技术支持,该品牌标注的“高级写入缓存”功能是指在硬盘异常掉电后,利用电机马达尚未完全停止的旋转产生电动势,为写入NOR闪存提供电能支持。GRMS即均方根加速度,多在振动相关的可靠性测试中出现的单位,一般为5。E系列的MTPF为200万小时,X系列为250万小时。每年运行的小时数=365×24=8760小时。E和X的平均时延都为4.16ms。E系列中,8TSATA盘的平均闲置功率为7.64w,运行时(随机读写)的功率为12.81w; 6T的平均闲置功率为6.2w, 运行功率11.67w。企业盘的物理尺寸(长宽高)=147×101.85×26.1毫米。E系列8T盘质量为716g,6T盘质量为693kg,4T为649g。8T盘的最高传输率为249MB/s,6T为226MB/s。X16系列最大传输速率为261MB/s(接口6Gbps),249MB/s(接口3Gbps),随机4K读取IOPS为170,随机4K写入440。X系列所有容量硬盘的平均闲置功率均为5w,最大运行功耗10w(随机读)/6.3w(随机写),机械尺寸为147×101.85×26.11毫米,即厚度增加了0.01毫米。X16系列所有硬盘的质量为670g,X12为705g。

分类: 大数据 标签:

数据存储框架04

2019年11月27日 15点18分 没有评论

看完企业级硬盘和普通硬盘的区别,归纳了如下几点:
– 企业级硬盘的外壳做工比普通硬盘要扎实: 企业级硬盘的外壳表面略带弧形(龟壳),普通硬盘是平面。
– 企业级硬盘内部碟片的中心转轴和整个盘体通过螺丝相连,增加了稳定性。普通硬盘内部碟片的中心转轴没有与其它盘体相连固定。
– 企业级硬盘内部碟片的部分被一块半园环装的铝合金固定。企业级硬盘转速较快,为了保证碟片的整机稳定性,增加了此片铝合金固定件。普通硬盘没有此部件。
– 企业级硬盘电机的磁铁体积明显大于普通硬盘,使得企业级硬盘的电机获得更大的推力。
– 企业级硬盘的主轴电机相对较细,主要是在体积相同的情况下,放置更大的转子,
– 企业级硬盘电路板上的主控芯片采用FPGA,一并封装了缓存。普通硬盘的主控芯片和缓存芯片是分开的,且以针脚形式链接到硬盘电路板。

“分久必合,合久必分“,可以对应分布式存储和传统存储产品的关系。这两种力量在长期的互为作用下,形成行业创新的动力。随着云计算和大数据时代的到来,传统SAN存储产品虽然不会消亡,但已经很难满足海量数据处理的需求,分布式存储的创新给用户带来更好的选择。

企业级用户选择存储供应商,完全由自身业务与应用场景而定。大部分企业用户主要考虑两点:一是对系统稳定、可靠和安全的要求;二是商业化产品应用的稳重要求,即选择有自研能力的存储厂商,明显会减少许多不必要的试错过程。如果有很强技术能力的用户,他们可能会选择开源软件。

在分布式存储市场上坚守十年技术迭代和创新的厂商比较少。”十年磨一剑“,经历十几年技术洗礼的某公司就是其中之一。其产品经受了市场考验和取得较好的市场成绩,主要原因有四点:经验、本地化、融合架构和性能卓越。

如何描述经验? ”不经一番寒彻骨,怎得梅花扑鼻香。“只有经过长期的实战,才能获得对诸多用户场景成功落地的丰富经验。任何一个分布式存储系统,都是从最初的版本一代一代优化升级,然后才能变得成熟,并成为厂商决胜市场的关键。这是获得经验的根本所在。

分类: 大数据 标签:

数据存储框架03

2019年11月26日 11点25分 没有评论

公司的愿景和目标? 帮助客户通过挖掘其数据的潜力,并利用其数据中的价值进行智能创新。利用公司丰富的创新、开发和经验资源,将在运营技术(OT)领域广泛专业知识与经过验证的信息技术(IT)产品创新和解决方案相结合,为工商企业提供数据驱动解决方案。

业务转型标志着公司的一次巨变,因为我们在不断推进公司的统一社会创新愿景。公司多年来一直帮助客户利用数据的力量来只是具有实效的商业举措。现在,鉴于世界正在被数字化工具和流程改变,我们进行业务调整和转型,

-数据中存在的机会:数据已经成为企业最大的财富,前提是他们能够从中获得可以付诸行动的发现。数据是获取新的收入来源、提高客户体验、改善市场洞察力以及降低经营成本的关键。我们的产品和方案能够帮助客户充分发掘其数据的价值。

-新兴的物联网市场: Gartner,Inc表示”2020年物联网相关支持将达到4400亿美元,在这一时期,将有超过210亿个传感器和端点相链接。“

-优雅的便携式架构: 能够在工作场所或云端运行,支持在边缘和核心的工业物联网部署。

从做双控存储开始的二十年时间内,公司一直坚持积累与创新。回顾这段历史,公司给人的印象比较低调而理性。低调在于,针对技术和产品的研发,始终坚持以用户需求和市场发展为先的路线,不会有”只因技术而做技术“的激进。理性在于,多年的行业经验,成就了公司善于在合适的时间选择合适的技术放在合适的平台上(三个合适/PPT),理性看待技术创新的独特优势。这对于任何一个企业级存储厂商的健康发展来说,都显得尤为重要。(然后举例说明)单从这两个(案例)关键技术的创新发展来看,谨慎严谨,理性创新,使得低调的公司不断取得进步。毕竟这些年来传统存储整体市场规模增长已经不是十分明显,出货量一度出现下滑的趋势,同时因为后来全闪存阵列与传统存储的有效结合,才将传统存储的影响力进一步拉了回来。全球传统存储市场发展趋势和全闪存的表现,最终让公司选择了突破自己,成就数字时代下的存储新未来

数字化时代的企业用户所面临的不只是传统应用环境的挑战,还有来自物联网与大数据发展带来的基础架构现代化的新挑战,这对存储产品提出了新的需求:
– 需要进一步优化存储产品的性能,为处理物联网数据和流数据分析等现代工作负载加速。
– 需要对来自Oracle,SAP等传统企业应用、来自容器化的现代应用,以及来自大型机的关键业务应用等多样化工作负载,进行高效的处理和有效的管理。
– 需要确保架构等前瞻性,以适应企业发展的未来需求
– 需要优化总体拥有成本,增强现有数据服务的价值并延长其生命周期,扩展现有存储资产的价值。
– 需要简化管理并加速自动化,基于AI创建新的管理机制,快速提高IT运营效率。

挑战和机遇并存。新需求的出现预示着存储产品的发展必须经历一次跨越时间的变化。数字化时代,必然需要企业用户在存储产品方面具备应对多样化环境的能力。存储产品应数字化新时代发展而顺势转型的进程开始了。

没有一成不变的产品,更没有一成不变的数据。正是因为企业用户自身的数据变化,带来了数据存储的变革。在企业级用户领域,传统存储厂商不断受到来自公有云厂商存储解决方案的影响。一个传统的企业级存储厂商,在高端存储产品创新上倘若不能实现与时俱进的创新,不能融入对物联网、大数据和云环境等新兴技术的支持,那后果将不堪设想。因此,在针对与云环境的对接上,添加了一个文件存储网关。用户数据可以通过该网关平滑移到公有云,利于存储资源的综合有效的应用。其移动到公有云的数据将被对象化,可以快速建立索引方便检索。

关于”高性能、高可靠、高扩展、高灵活“:
– 高性能,是存储产品的显著指标。在强调IOPS超快的同时需要考虑响应时间(IOPS指的是每秒的读写次数,何谈响应时间?此处有问题)。
– 高可靠,是存储产品的必须性指标。只有在重视高可靠的基础上,追求更高的性能,才是厂商和用户的正确选择。存储产品拥有8个9的设备可靠性,主要源自其架构具备强大的自愈能力,专为始终在线的业务而设计。
– 高扩展,由于企业用户数字化转型的加快,无论是面对大型机平台的传统需求还是容器平台的云原生需求,都必须有灵活的支持。存储产品需要全面兼容主流的各种存储介质。
– 高灵活,这是企业用户数字化平台所必须的能力。针对有苛刻要求的大型机应用和有着弹性特点的容器应用,实现了灵活的支持,并且具备跨平台的数据迁移和整合能力。

在应对这样复杂的应用环境下,样样在行,从而为企业用户带来更好的应用体验。

随着云计算的发展,计算架构的变化也催生了存储架构从Scale Up走向Scale Out。Scale Out架构带来更大存储容量的扩展性,也早成为企业级存储用户的一个核心要求,任何传统的紧耦合方式必然无法满足对更多节点的要求。可是新的问题是,对于庞大的存储节点,必须要采取更适合的互联技术。因为节点互联技术会直接影响到存储的延迟性和相应管理的复杂性。那么存储产品如何从物理层和逻辑层来保证节点链接和传输的稳定高效?

从企业用户需求的角度出发,优秀的存储产品更需要好的运营管理。这样才可以让用户在用好产品的同时,可以更容易体验到好产品的好用之处。存储产品的性能瓶颈会随着时间的推移不断被打破,但是性能再好、机器再可靠,没有一个与时俱进的运营管理,那可就拉底存储的段位了。运营管理工具的价值和意义是,采用AI技术增强能力,提供简单、强大、联合管理,这是目前企业用户在数据存储管理上最关心的话题。

管理程序模板带来企业用户在管理和IT工作流程上的简化。收集并分析遥测数据,自动执行日常任务和动作,管理和保护数据,简单的设备管理,这四大模块是企业用户在存储产品上最想要的体验。客户需要具有全局运营洞察能力。进一步分析来看,将人工智能引入基础架构管理和运营中,借助一套智能的集成化系统管理软件,可以为企业用户带来战略性业务成果。与第三方工具一起集成起来,有助于企业更加轻松地分析和管理从服务器、虚拟机、网络到存储的数据中心环境,进而优化应用整个数据路径。

maintain

处于转型期的存储公司依然保有创新进取的初心。二十年,对于一个企业的技术坚持来说,在常年的激荡和风雨之中,它早已沉淀下来成熟的动力。因此,在IT新旧交替的关键时期,任何一个走在数字化转型路上的厂商和企业用户,都需要对数据存储的现代化进行深度考量,谨慎而理性地对待新兴技术的发展,坚持在合适的时间选择合适的存储技术放在合适的平台上,真正发挥数据应有的价值。

分类: 大数据 标签:

数据存储框架02

2019年11月25日 14点53分 没有评论

不管做什么产品,都要与业务本身紧密相连。现在是一个专业化,比专业性的时代。不能简单地把一个技术套到一个产品上就叫创新了,而是要通过技术把之前难以实现的、具有价值的事情做成做好。

凡事均有因果,不论是做事还是思考,在没有找到底层核心逻辑之前,都是存在很大的挖掘和探索空间的。做技术架构设计,如果能回答以下几个问题,那么架构就没有问题:
– 你同类产品的架构方案大概是什么样子的,他们都有哪些优缺点
– 你的产品主要解决的核心问题、面临的核心挑战
– 你的技术架构设计相对同类产品来说,具有哪些优势,是如何解上述第二点中问题的
不管是做架构还是开发,永远相信世界上没有最好的技术,只有最适合当前应用场景的技术。前段时间在和客户交流时,讲方案总觉得不顺畅。我想主要是没有弄清上面的三个问题,不理解就没有办法去说清楚,更不要谈如何发挥。

AARRR模式: 包括Acquisition获客、Activation激活、Retention留存、Revenue变现和Refer裂变五个环节。
– Acquisition,战略合作获得客户。战略合作是大多数公司需要考虑的重点,一方面可以通过战略合作提升自身在业内的声音,另一方面也可以通过战略合作,战术授权和OEM协议等,获得一定规模的行业进展机会。对于大厂商来说,不可能在每一项技术领域都做得非常深入和精到,只要公司的软件、应用确实有业内难得的深入,那么战略合作的可能性就极大。这对公司的发展尤其重要,借力使力,是最先最快迎来客户的方式。
– Retention,技术服务存留。既然有了战略合作带来的客户基础,想要获得战略合作伙伴的好评,客户的青睐,关键在于提供积极的技术服务支持,并且要专业。新产品需要经过一定规模用户的检验才能最后产品化,走向更广阔的市场和行业。通过积极、专业、贴身周到的技术服务,完全有可能存留既有的客户和合作伙伴的持续合作。
– Activation,激活用户体验。在软件应用方面,需要更多考虑用户的体验,考虑到用户的问题和痛点,自然可以赢得更多的好口碑。好口碑犹如品牌催化剂、起到市场推进事半功倍的作用。
– Revenue,在行业专注变现方面。公司要持续向前发展,不能仅仅依靠融资,还需要通过变现来获得新鲜血液。公司的员工、能力和技术都是有限的,要在有限的资源情况下,抓住一个或两个重点行业进行深耕,进行深入研究和让产品更好的匹配。这样才能彰显公司自有的优势,否则,很容易变成竞争的劣势。因为在任何一个行业中,都可能遇见大厂商或者大机构的触角。“人有我有”容易,“人有我精”会难一些。既然难一些,才有更多的竞争机会。要不然连进入某行业的门都没有,何谈行业变现呢。
– Refer,用户口碑裂变。好的用户体验自然可以带来良好的用户口碑,但是想要获得用户在口碑方面的裂变效果,必然需要在对用户、对合作伙伴的技术支持上下一番苦功夫不可。用户口碑的裂变,不仅仅需要靠技术支持的到位,更需要在品牌推广、市场推广、技术推广、服务推广等方面形成合理,才能真正实现最后的用户口碑裂变。

分类: 大数据 标签: