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

2019 年 11 月 12 日

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

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


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


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


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


数据湖下的两大派系


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


  1. 一个可以存储大数据的并行系统

  2. 可以在不需要另外移动数据的情况下进行数据计算


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


1.计算存储一家亲



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


2.计算存储一家亲 Pro



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


3.计算存储分家



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


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


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



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


青梅煮酒


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


计算存储融合 – HDFS



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


  1. HDFS客户端向NameNode发送一条创建文件的请求;

  2. NameNode遍历查看后,验证该文件为新文件,随后响应客户端准许上传;

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

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

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

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


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


  • 创建文件、上传block时需要先访问NameNode

  • NameNode上存放了文件对应的元数据、block信息

  • HDFS客户端在上传、读取时直接与DataNode交互


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


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


  1. 数据平衡性不好

  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 Server 开源软件,相比较 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,希望能带来更好的兼容性以及更强的读写性能。


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


本文转载自公众号 UCloud 技术(ID:ucloud_tech)。


原文链接:


https://mp.weixin.qq.com/s/GK2F0ozj_nffq9PRmrxsyQ


2019 年 11 月 12 日 14:30170

评论

发布
暂无评论
发现更多内容

极客时间 - 架构师训练营 - week1 - 作业2

jjn0703

极客大学架构师训练营

史上最诡异问题,iOS 单例初始化两次,你遇到过吗?

liu_liu

ios 初始化 单例 两次

第一周作业

andy

公司出了一款新产品,要不要招代理商?

石云升

用户增长 价值网依赖 产品定位 新产品

mybatis 逆向工程使用姿势不对,把表清空了,心里慌的一比,于是写了个插件。

why技术

Java 源码 mybatis

软件建模与设计文档

大雄

UML

食堂就餐卡系统设计

大雄

架构师训练营练习:食堂就餐卡系统设计

Shawn

年龄性别的问题,好像也不是太大问题……

zhoo299

生活 随笔

第一周UML作业

吴建中

ngrok穿越本地服务器,极客大学架构师训练营 第一课总结,John 易筋 ARTS打卡Week 03

John(易筋)

极客时间 极客大学 ngrok

SpringBoot整合Quartz实现任务定时

北漂码农有话说

SpringBoot 2

第一周总结

andy

第一周总结

ARTS-02

NIMO

ARTS 打卡计划 ARTS活动

使用 Docker Desktop 中的 Kubernetes

FeiLong

Docker Kubernetes

带你学够浪:Go语言基础系列 - 8分钟学复合类型

柠檬橙

golang 后端

ARTS-week-2

youngitachi

ARTS 打卡计划

ARTS打卡Week 03

teoking

ios LeetCode

scala callback hell

HackMSF

编程 最佳实践

第一周学习总结

A Matt

极客大学架构师训练营

架构师训练营-学习笔记-第一周

心在飞

极客大学架构师训练营

MySQL 笔记(二)日志系统

奈何花开

Java MySQL

ARTS-WEEK1

Allen

软件架构基础

dapaul

架构 架构师 极客大学架构师训练营

HBase 常用 Shell 命令手册

Rayjun

Java HBase

ARTS 打卡 WEEK3

编程之心

ARTS 打卡计划

作业1-食堂就餐卡系统设计

A Matt

架构文档-作业01

ashuai1106

UML

面试了 6 轮 Google中国 之后,还是挂了

石头

面试 谷歌Google Java 面试 经验分享 面经

[安利] WSL Linux 子系统,真香!附完整实操

猴哥一一 cium

Docker Linux 推荐 WSL2 Windows 10

就餐卡系统设计

满山李子

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