当前位置:主页 > 数据驱动 >

UMStor Hadapter:大数据与对象存储的柳暗花明

 发布时间:2018-07-15 来源:

引言

但凡是千禧年之前出生的国人,心里大体都有一个武侠情结,那是一个由金庸、古龙的一本本武侠小说以及港台武侠剧堆砌出来的武林世界。虽说现在的电影可以发达到让观众看到各种奇幻特效,但回味起来,似乎还不如金庸笔下一个令狐冲给江湖朝堂带来的翻覆动荡刺激。

侠骨文心笑看云霄飘一羽, 孤怀统揽曾经沧海慨平生,武侠的迷人在于一个个小人物不单单被分成正邪两派,每个人都有自己的独立意志,通过不懈努力,最终得以在江湖这个大舞台上各展身手,江山人才代出,各领风骚数年,刀光剑影间,让人大呼好不过瘾。

计算机技术领域,何尝又不是一个江湖。往具体了说,比如有 Windows 和 Linux 系统级别的缠斗;往抽象了说,有私有云和IOE的概念对垒等。虽说技术不像侠客论剑般交手那么直接,但是背后的暗潮涌动还是能让人嗅到一丝火花的气息。

今天我们要讨论的当然不是江湖,而是要掰扯掰扯“数据湖data lake”。

数据湖下的两大派系

数据湖这一概念最早应该是在 2011 年由 CITO Research 网站的 CTO 和作家 Dan Woods 提出。简单来说,数据湖是一个信息系统,并且符合下面两个特征:

一个可以存储大数据的并行系统
可以在不需要另外移动数据的情况下进行数据计算
在我的理解中,目前的数据湖形态大体分为以下三种:

计算存储一家亲

 

UMStor Hadapter:大数据与对象存储的柳暗花明

 

计算资源和存储资源整合在一起,以一个集群来应对不同业务需求。可以想象,如果后期公司体量增大,不同的业务线对数据湖有不同的计算需求,业务之前会存在对计算资源的争抢;同时,后期扩容时,计算和存储得相应地一同扩展,也不是那么的方便。

计算存储一家亲 Pro

 

UMStor Hadapter:大数据与对象存储的柳暗花明

 

为了应对上述方案中的资源争抢问题,一般的解决方案就是为每个业务线分配一个数据湖,集群的隔离能够让每个业务线有自己的计算资源,可以保证很好的业务隔离性。但是随之而来的问题也是显而易见的:数据孤岛。试想几个业务线可能需要同一个数据集来完成各自的分析,但是由于存储集群也被一个个分开,那么势必需要将这个数据集挨个复制到各个集群中去。如此,数据的冗余就太大了,存储开销太大。同时,计算和存储的扩容问题也仍然存在。

计算存储分家

 

UMStor Hadapter:大数据与对象存储的柳暗花明

 

俗话说的好,距离产生美。在这个模式中,计算和存储被分隔开来。每个业务线可以有自己的计算集群,来满足其业务需求。而后台都指向同一个共享存储池,由此解决了第二个方案中的数据冗余问题。并且由于计算、存储分离,在后期扩容时,也可以各自分别扩容。这一分离性也符合弹性计算的特征,让按需分配成为可能。

我们将方案一和方案二可以归为“计算存储融合”这一派系,目前最有代表的应该就是 Hadoop 的 HDFS,这套大数据默认的存储后台有着高容错、易扩展等优点,十分适合部署在廉价设备上;而方案三可以单独拿出来,归为“计算存储分离”派系,最有代表的是 Amazon EMR。EMR 借助 AWS 得天独厚的云计算能力,并且辅以 S3 对象存储支持,,让大数据分析变得十分简单、便宜。

在私有云场景中,我们一般会采用虚拟化技术来创建一个个计算集群,来支持上层大数据应用的计算需求。存储这边一般采用 Ceph 的对象存储服务来提供数据湖的共享存储后台,然后通过S3A来提供两者之间的连接,能够让Hadoop的应用能够无缝访问 Ceph 对象存储服务。

 

UMStor Hadapter:大数据与对象存储的柳暗花明

 

综上所述,我们可以看到在“数据湖”这一概念下,其实隐约已经分成了两个派系:“计算存储融合”, “计算存储分离”。下面,让我们谈谈这两个派系的优缺点。

青梅煮酒

在这一节,我们会把“计算存储融合”和“计算存储分离”这两个框架摆上台面,来讨论一下他们各自的优缺点。

计算存储融合 – HDFS

 

UMStor Hadapter:大数据与对象存储的柳暗花明

 

HDFS 客户端往 HDFS 写入数据时,一般分为以下几个简要步骤:

HDFS 客户端向 NameNode 发送一条创建文件的请求
NameNode 遍历查看后,验证该文件为新文件,随后响应客户端准许上传

HDFS 客户端根据默认 block size 和要上传文件的大小,来对文件做切分。比如 default block size 是 128M, 而上传文件是 300M,那么文件就会被分割成 3 个 block。

客户端请求上传 block,NameNode 通过分析集群情况,返回该 block 需要上传的 DataNode。由于默认 HDFS 的冗余策略是三副本,那么就会返回 3 个 DataNode 地址。

客户端通过建立 pipeline,向对应的 DataNode 上传 block 数据。

当一个 block 上传到 3 个 DataNode 后,客户端准备发送第二个 block,由此往复,直到文件传输完毕。

HDFS 读取数据步骤不在此赘述。对于 HDFS 写入数据的步骤,我认为重要比较重要的有以下几点:

创建文件、上传 block 时需要先访问 NameNode
NameNode 上存放了文件对应的元数据、block 信息
HDFS 客户端在上传、读取时直接与 DataNode 交互

作为“计算存储融合”的代表 HDFS,其中心思想是通过d ata locality 这一概念来实现的,也就是说,Hadoop 在运行 Mapper 任务时,会尽量让计算任务落在更接近对应的数据节点,由此来减少数据在网络间的传输,达到很大的读取性能。而正是由于 data locality 这一特性,那么就需要让 block 足够大(默认 128M),如果太小的话,那么 data locality 的效果就会大打折扣。

但是大的 block 也会带来 2 个弊端:

数据平衡性不好
单个 block 上传时只调用了 3 个 DataNode 的存储资源,没有充分利用整个集群的存储上限

计算存储分离 – S3A

文章评论

互联网 自媒体专栏 智能硬件 资本动态 移动互联网 游戏 数据驱动 滚动新闻 O2O 访问移动版
Copyright © 2002-2013 搞数码网 版权所有  电话:0510-898978789 邮箱:89898989@qq.com 地址:北京市新会金水岸国商大厦B-6-B