从 Hadoop 到云原生, 大数据平台如何做存算分离

database 投稿 1800 0 评论

今天与大家一起简单回顾 Hadoop 架构以及目前市面上不同的存算分离的架构方案,他们的利弊各有哪些,希望可以给正在存算分离架构改造的企业一些参考和启发。

Hadoop 存算耦合架构回顾

从 Hadoop 到云原生, 大数据平台如何做存算分离

从 Hadoop 到云原生, 大数据平台如何做存算分离

底层存储经过了大概 10 年左右的时间,一直是 HDFS 一枝独秀,带来的一个结果就是它会成为所有计算组件默认的设计选择。上面提到的这些大数据生态里发展出来的各种组件,都是面向HDFS API 去做设计的。有些组件也会非常深入的利用 HDFS 的一些能力,比如深入看 Hbase,在写 WAL log 的时候就直接利用了HDFS 的一些很内核的能力,才能达到一个低时延的写入;比如说像最早的 MapReduce 和 Spark 也提供了数据亲和性(Data Locality)的能力,这些都是HDFS 提供的一些特殊的 API。

这些大数据组件面向 HDFS API 设计的做法, 为后续数据平台上云带来了潜在的挑战。

从 Hadoop 到云原生, 大数据平台如何做存算分离

为什么 Hadoop 在设计之初是一个存储计算耦合的架构?

在机房里面,当时我们面对的最大的问题就是网卡,主流的还是百兆网卡,刚开始用千兆网卡。这个时候,大数据使用的磁盘,吞吐大概是 50MB/s,对网络带宽来说要乘以 8,也就是 400M bps;如果一个节点里放 8 块盘,吞吐都跑起来,就需要几千兆带宽传输了,但是网卡最高也就1Gb。这就意味着每一个节点网络带宽根本不够,无法让这个节点里面的所有的磁盘的能力都发挥出来。所以如果计算任务在网络的一端,数据在数据节点在网络的另一端,计算任务需要说通过网络传输来进行,网络带宽是一个最明显的瓶颈。

存算分离的需求出现

第一企业数据增长很快,但是算力的需求其实长得没那么快。这些任务靠人开发,不会发生一天一倍的去涨的情况,但是产生的数据的速度是是非常快的,有可能是指数型的;而且有些数据产生出来,也不一定马上知道怎么用,但未来会用,所以企业都会先把数据尽可能全量的去存起来,再去挖掘它的价值。

当集群越大,这种不平衡就越严重。而且另外买机器也挺难的,购买的机器必须是计算与存储平衡的。

在这个过程中硬件也有变化,给存算分离架构带来了可行性。首先,10Gb万兆网卡普及了,今天机房里或者包括云上也开始有更多的 20Gb、40Gb,甚至 50Gb,有些 AI 的场景甚至有100Gb的网卡,网络的带宽其实加大了比以前提升了100倍之多。

以前网络传输的瓶颈就基本不存在了。

这些变化加在一起,都进一步减小了需要传输的数据量。同时, 网卡在提升,再加上硬硬盘本身的吞吐没增加多少,企业以前曾经要面对的 I/O 的瓶颈就逐渐的在弱化甚至消除,保证了存算分离的可行性。

如何实现存算分离?

最初的尝试:在云上独立部署 HDFS

从下面的示意图可以看到, DataNode 节点上不再部署 Node Manager,意味着不再把计算任务发送到 DataNode 节点上。存储成为一个独立集群,计算需要用到的数据都会通过网络来传输,端到端的万兆网卡去支持,网络传输线没有在下图标出。

在这个改变里,尽管 HDFS 最巧妙的数据本地性这个设计被舍弃了,但由于网络通讯速度的提高, 给集群的配置带来更大的便利。Juicedata 创始人 Davies,2013 年在 Facebook 工作期间,团队就做了这样的实验, 发现这样的一个存算分离的改造,对整个平台性能的影响是仅仅是几个百分点,但是给集群的配置管理带来了一个还很大的便利,可以独立的部署和管理计算节点了。

当我们去使用云上资源的时候,这个方案的弊端就显露了。

首先,源自 HDFS 的多副本机制在云上会增加企业的成本。过去,企业在机房使用裸硬盘去搭建一套 HDFS,为了解决裸硬损坏的风险, HDFS 设计了多副本的机制,来保证数据安全性;同时多副本还承载着保证数据可用性的作用。除了磁盘损坏,当某一个 DataNode 的节点临时宕机了,这个节点上的数据访问不到了?多副本机制在可靠性和可用性上都发挥作用。当数据被迁移到云上时,云提供给用户的是经过多副本机制存储的云盘,不再是裸硬盘了,企业用这块云盘去搭一个HDFS,又要做3副本,企业数据在云上要存 9 副本,成本立马飙升了好几倍。

第二个原因, 这个方案不能让企业得到云上的独特价值,比如开箱即用,弹性伸缩,以及按量付费这些云上最大的优势。在云上部署 HDFS, 需要自己创建机器,手动部署和维护,自己监控和运维,而且还不能方便地扩缩容。这种情况下,HDFS 上云实现存算分离,仍然有其痛点。

第三个原因,HDFS 本身的局限。首先是,NameNode,只能垂直扩展,并不能分布式扩展说扩出更多的 NameNode 节点,限制了 HDFS 单集群去管理的文件数量。

根据实际运维经验,一般在 3 亿文件以内,运维 HDFS 还是比较轻松的,3 亿文件之后运维的复杂度就会明显提升,峰值可能就在 5 亿文件左右,就达到单机群的天花板了。文件量更多,需要引入 HDFS的 Federation 联邦的机制,但是它就增加了很多的运维和管理的成本。

公有云+ 对象存储

最早从 AWS 开始,后来所有的云厂商其实都在往这个方向发展,开始推动用对象存储去替代 HDFS。这些方案首先带来了两个 HDFS 无法实现的最明显的好处:

  • 第二,弹性伸缩,企业可以按量付费,不用考虑任何的容量规划,开一个对象存储的 bucket ,有多少数据写多少数据,不用担心写满。

但当对象存储被用来去支持复杂的 Hadoop 这样的数据系统,就会发现如下的一些问题。

    文件 Listing 的性能比较弱
  1. 。Listing 是文件系统中最基础的一个操作。我们在文件系统中 List 目录,包括 HDFS 里面 List 目录,都是非常轻量快的操作。它的性能是源于在文件系统中,数据是一个树形结构。

从 Hadoop 到云原生, 大数据平台如何做存算分离

  1. 对象存储没有原子 Rename, 影响任务的稳定性和性能。在 ETL 的计算模型中,每个子任务完成会将结果写入临时目录,等到整个任务完成后,把临时目录改名为正式目录名即可。

这样的改名操作在 HDFS 和其他文件系统中是原子的,速度快,而且有事务性保证。但由于对象存储没有原生目录结构,处理 rename 操作是一个模拟过程,会包含大量系统内部的数据拷贝,会耗时很多,而且没有事务保证。

/order/2-22/8/10/detail”。改名操作时,需要搜索出所有 Key 中包含目录名的对象,用新的目录名作为 Key 复制所有的对象,此时会发生数据拷贝,性能会比文件系统差很多,可能慢一两个数量级,而且这个过程因为没有事务保证,所以过程中有失败的风险,造成数据不正确。这样看起来很细节的差异对整个任务 pipeline 的性能和稳定性都会有影响。

对象存储数据最终一致性的机制,会降低计算过程的稳定性和正确性。举个例子,比如多个客户端在一个路径下并发创建文件,这是调用 List API 得到的文件列表可能并不能包含所有创建好的文件列表,而是要等一段时间让对象存储的内部系统完成数据一致性同步。这样的访问模式在 ETL 数据处理中经常用到,最终一致性可能会影响到数据的正确性和任务的稳定性。

除了上述由于文件系统和对象存储本身差异带来的问题外,在对象存储上使用 Hadoop 的另一大问题,就是对象存储对于 Hadoop 组件的兼容性相对弱。在文章开头 Hadoop 架构介绍中提到了 HDFS 是 Hadoop 生态早期几乎唯一的存储选择,上层各种各样的组件都是面向 HDFS API 开发的。而到了对象存储上,数据存储的结构变了, API 也变了。

所以,目前公有云它提供的大数据组件里面能包含的计算组件是有是有限的,一般只能包含 Spark、 Hive、 Presto 三个常用组件,而且还只能包含少数几个版本。这样就会给将大数据平台迁移上云,或者有需要使用自己的发行版和组件需求的用户带来了挑战。

企业如何能够享受到对象存储的强大性能,同时又兼顾文件系统的准确性?

对象存储 + JuiceFS

这也是我们去做 JuiceFS 的一个出发点,希望能够站在对象存储之上去补充他不擅长的部分,与对象存储一起以比较低廉的价格服务好密集性的数据计算、分析、训练这些场景。

从下面这个简单的示意图看到, YARN 管理的这些执行节点上,都带一个 JuiceFS Hadoop SDK, 这个 SDK 可以保证完整兼容 HDFS。图片下方可以看到, SDK 它需要访问两个部分,左侧是 JuiceFS Meta Engine,右侧是 S3 bucket。Metadata engine 就相当于 HDFS里的 NameNode,整个文件系统的元数据信息会存储在这里,元数据信息包括目录数、文件名,权限时间戳这些信息,并且相应的解决掉了 HDFS NameNode 扩展性 、GC 这些的痛点。

相较于直接使用对象存储, JuiceFS 还有哪些优势呢?

    HDFS 100% 完整兼容
  1. 。这得益于我们最初完整兼容 POSIX 的这个设计。POSIX API 的覆盖程度以及复杂程度是大于 HDFS的,HDFS 在设计的时候就是去简化了 POSIX,因为最先去实现复杂的 API 集,再去简化它就变得非常容易了,所以这也是 JuiceFS 能实现 100%实现 HDFS 完整兼容性的一个原因。

同时, 用户可以和 HDFS 一起使用,无需完全替换 HDFS。这也得益于 Hadoop 系统的设计,在一个 Hadoop 集群里,可以配置多个文件系统,JuiceFS 和 HDFS 可以同时使用,并不是互相替代的关系,而是可以互相合作。这样的架构给我们我们现有的集群带来的好处是用户不用完整替代现有的 HDFS 集群,完整替代的工作量和风险上都太大了。用户可以结合着业务,结合着集群的情况,分步分批的去做融合。

  1. 元数据性能强大,JuiceFS 将元数据引擎独立出来不再依赖于 S3 里面的原数据性能,保证了元数据的性能。使用 JuiceFS 的时候,对底层对象存储的调用简化到只是 get、 put、delete 这三个最基础的操作,像 listing, update 等命令都用不到,在这样的架构下,用户就避开了对象存储元数据性能弱的问题,最终一致性这些问题也都不再存在了。

  2. 原子 rename, 因为有独立的原数据引擎,JuiceFS 也可以支持原子 rename。

  3. 缓存,有效提升热数据的访问性能,提供了 data locality 特性。缓存可以让热数据缓存到执行器 worker 节点本地的一些磁盘空间上。有了缓存后,会反复访问的热数据,不需要每次都通过网络去对象存储里面读数据。而且 JuiceFS 特意实现了HDFS 特有的数据本地性的 API,让所有支持数据本地性的上层组件都能重新获得数据亲和性的感知,这会让 YARN 把自己的任务优先调度到已经建立缓存的节点上面,综合的性能可以和存储计算耦合的 HDFS 相当的。

  4. 兼容 POSIX, 与机器学习、AI 相关的任务应用结合方便。JuiceFS 还兼容 POSIX,可以和机器学习, AI相关的这些业务更便捷地融合。

编程学习分享 » 从 Hadoop 到云原生, 大数据平台如何做存算分离

赞 (0) or 分享 (0)
游客 发表我的评论   换个身份
取消评论

表情
(0)个小伙伴在吐槽

高效,专业,符合SEO

联系我们