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

大数据 存储
计算机技术领域,何尝不是一个江湖。往具体了说,比如有 Windows 和 Linux 系统级别的缠斗;往抽象了说,有私有云和IOE的概念对垒等。虽说技术不像侠客论剑般交手那么直接,但是背后的暗潮涌动还是能让人嗅到一丝火花的气息。今天我们要讨论的当然不是江湖,而是要掰扯掰扯“数据湖data lake”。

引言

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

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

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

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

数据湖下的两大派系

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

  • 一个可以存储大数据的并行系统
  • 可以在不需要另外移动数据的情况下进行数据计算

在我的理解中,目前的数据湖形态大体分为以下三种:

计算存储一家亲

 

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

计算存储一家亲 Pro

 

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

计算存储分家

 

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

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

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

 

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

青梅煮酒

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

计算存储融合 – HDFS

 

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

我们在前文中已经介绍过,在私有云部署中,数据湖的计算存储分离框架一般由 Ceph 的对象存储来提供共享存储。而 Ceph 的对象存储服务是由 RGW 提供的,RGW 提供了 S3 接口,可以让大数据应用通过 S3A 来访问 Ceph 对象存储。由于存储与计算分离,那么文件的 block 信息不再需要存放到 NameNode 上,NameNode 在 S3A 中不再需要,其性能瓶颈也不复存在。

Ceph 的对象存储服务为数据的管理提供了极大的便利。比如 cloudsync 模块可以让 Ceph 对象存储中的数据十分方便地上传到其他公有云;LCM 特性也使得数据冷热分析、迁移成为可能等等。另外,RGW 支持纠删码来做数据冗余,并且已经是比较成熟的方案了。虽然 HDFS 也在最近支持了纠删码,但是其成熟些有待考证,一般 HDFS 客户也很少会去使用纠删码,更多地还是采用多副本冗余。

 

我们通过这张图来简单分析一下 S3A 上传数据的步骤: HDFS 客户端在上传数据时,需要通过调用 S3A 把请求封装成 HTTP 然后发送给 RGW,然后由 RGW 拆解后转为 rados 请求发送给 Ceph 集群,从而达到数据上传的目的。

由于所有的数据都需要先经过 RGW,然后再由 RGW 把请求递交给 OSD,RGW 显然很容易成为性能瓶颈。当然我们可以通过部署多个 RGW 来把负载均摊,但是在请求 IO 路径上,请求无法直接从客户端发送到 OSD,在结构上永远多了 RGW 这一跳。

另外,由于对象存储的先天特性,List Objects 和 Rename 的代价比较大,相对来说会比 HDFS 慢。并且在社区版本中,RGW 无法支持追加上传,而追加上传在某些大数据场景下还是需要的。

由此,我们罗列一下 HDFS 和 S3A 的优缺点:

 

显然,S3A 消除了计算和存储必须一起扩展的问题,并且在存储管理上有着更大的优势,但是所有请求必须先通过 RGW,然后再交由 OSD,不像 HDFS 那般,可以直接让 HDFS 客户端与 DataNode 直接传输数据。显然到了这里,我们可以看到“计算存储融合”与“计算存储分离”两大阵营都尤其独特的优势,也有不足之处。

那么,有没有可能将两者优点结合在一起?也就是说,保留对象存储的优良特性,同时又能让客户端不再需要 RGW 来完成对Ceph 对象存储的访问?

柳暗花明

聊到 UMStor Hadapter 之前,我们还是需要先说一下 NFS-Ganesha 这款软件,因为我们正是由它而获取到了灵感。NFS-Ganesha 是一款由红帽主导的开源的用户态 NFS 服务器软件,相比较 NFSD,NFS-Ganesha 有着更为灵活的内存分配、更强的可移植性、更便捷的访问控制管理等优点。

NFS-Ganesha 能支持许多后台存储系统,其中就包括 Ceph 的对象存储服务。

 

上图是使用 NFS-Ganesha 来共享一个 Ceph 对象存储下的 bucket1 的使用示例,可以看到 NFS-Ganesha 使用了 librgw 来实现对 Ceph 对象存储的访问。librgw 是一个由 Ceph 提供的函数库,其主要目的是为了可以让用户端通过函数调用来直接访问 Ceph 的对象存储服务。librgw 可以将客户端请求直接转化成 librados 请求,然后通过 socket 与 OSD 通信,也就是说,我们不再需要发送 HTTP 请求发送给 RGW,然后让 RGW 与 OSD 通信来完成一次访问了。

 

从上图可得知,App over librgw 在结构上是优于 App over RGW 的,请求在 IO 调用链上少了一跳,因此从理论上来说,使用 librgw 可以获得更好的读写性能。

这不正是我们所寻求的方案吗?如果说“计算存储融合”与“计算存储分离”两者的不可调和是一把锁,那么 librgw 就是开这一把锁的钥匙。

UMStor Hadapter

基于 librgw 这个内核,我们打造了一款新的 Hadoop 存储插件 – Hadapter。libuds 是整个 Hadapter 的核心函数库,它封装 librgw。当 Hadoop 客户端发送以 uds:// 为前缀的请求时,Hadoop 集群就会将请求下发给 Hadapter,然后由 libuds 调用 librgw 的函数,让 librgw 直接调用 librados 函数库来请求 OSD,由此完成一个请求的完成处理。

Hadapter 本身只是一个 jar 包,只要将这个 jar 包放到对应大数据节点就可以直接使用,因此部署起来也十分便捷。同时我们还对 librgw 做了一些二次开发,比如,让 librgw 能够支持追加上传,弥补了 S3A 在追加上传上的短板。

 

我们对 HDFS、S3A、Hadapter 做了大量的性能对比测试,虽然不同的测试集有其独特的 IO 特性,不过我们在大多数测试中都获取到了类似的结果:HDFS > Hadapter > S3A。我们在这里用一个比较典型的 MapReduce 测试: word count 10GB dataset 来看一下三者表现。

 

为了控制变量,所有的节点都采用相同的配置,同时 Ceph 这边的冗余策略也和 HDFS 保持一致,都采用三副本。Ceph 的版本为 12.2.3,而 Hadoop 则采用了 2.7.3 版本。所有计算节点均部署了 Hadapter。在该测试下,我们最终获取到的结果为:

 

可以看到,HDFS 凭借其 data locality 特性而获取的读性能,还是取得了***的成绩;而 Hadapter 这边虽然比 HDFS 慢,但不至于太差,只落后了 35s;而 S3A 这边则差出了一个量级,最终耗时为 HDFS 的两倍。我们之前所说的的,理论上 librgw 比 RGW 会取得更好的读写性能,在这次测试中得到了印证。

客户案例

Hadapter 在去年迎来了一位重量级客人。该客户是一家运营商专业视频公司,我们为它搭建了一套结合了大数据、机器学习、流媒体服务以及弹性计算资源池的存储后台解决方案。集群规模达到 35PB 左右。

Hadapter 在这套大数据平台下,主要为 Hbase、Hive、 Spark、 Flume、 Yarn 等应用提供后台支持,目前已经上线。

 

结语

好了,现在我们把 HDFS、S3A、Hadapter 都拿出来比较一下:

 

虽然上述列举了不少 HDFS 的缺点,不过不得不承认,HDFS 仍旧是“计算存储融合”阵营的定海神针,甚至可以说,在大部分大数据玩家眼中,HDFS 才是正统。不过,我们也在 Hadapter 上看到了“计算存储分离”的新未来。目前 UMStor 团队正主力打造 Hadapter 2.0,希望能带来更好的兼容性以及更强的读写性能。

这场较量,或许才拉开序幕。

责任编辑:未丽燕 来源: 网络大数据
相关推荐

2012-05-16 09:33:28

后PCITPC时代

2010-12-09 16:44:49

2017-05-18 15:59:05

WiFi应用3D物体

2009-12-21 13:46:38

Linux桌面

2018-05-24 17:24:35

UCloudUMStor存储

2010-10-11 16:52:09

2013-01-28 11:34:11

云对象存储大数据分析对象存储

2013-08-08 10:07:43

大数据存储结构化数据

2018-01-24 10:33:18

存储

2018-09-19 10:15:45

块存储文件存储对象存储

2022-10-08 07:45:09

块存储磁盘硬盘

2018-03-20 10:37:33

存储大数据管理

2017-07-13 11:13:18

大数据数据存储

2016-11-08 19:19:06

2022-09-01 23:34:18

大数据数据分析工具

2015-10-22 19:00:43

明略数据

2012-08-24 18:31:52

红帽虚拟化

2018-07-04 09:30:55

列式存储格式

2022-08-14 14:52:45

数据存储实践
点赞
收藏

51CTO技术栈公众号