10分钟了解Hadoop存算分离在DataSimba的应用 | StartDT Tech Lab 03

​写在前面

这是奇点云全新技术专栏「StartDT Tech Lab」的第3期。

在这里，我们聚焦数据技术，分享方法论与实战。一线的项目经历，丰富的实践经验，真实的总结体会…我们畅想未来大趋势，也关注日常小细节。

本篇由奇点云数据平台后端架构专家「纯粹」带来：

作者：纯粹

阅读时间：约10分钟

 

众所周知传统的Apache Hadoop的架构存储和计算是耦合在一起的，HDFS（Hadoop Distributed File System）作为其分布式文件系统也面临一些问题。如：存储空间或者计算资源不足时，两者只能同时扩容、扩容效率低、额外增加成本、灵活性差等。

 

本文会和大家回顾Hadoop的传统架构来分析上述问题，介绍Hadoop实现存算分离的方案，并分享我们DataSimba对于Hadoop存算分离的最佳实践。

 

Hadoop分布式文件系统

（HDFS）的架构和问题

 

HDFS的架构（图源：Hadoop）

 

上图是Hadoop官方对于HDFS的架构图，我们重新回顾一下，一个HDFS集群由一个Namenode和一定数目的Datanode组成。Namenode是中心服务器，负责整个文件系统的namespace和客户端的访问，比如打开、关闭、重命名文件或目录，同时Namenode也负责数据块和具体Datanode节点的映射。

 

01

HDFS的设计目标

回顾完了HDFS的整体架构，我们来想一下HDFS的设计目标：

 

首先，建立错误监测和快速自动的恢复能力。

HDFS常用来部署在低廉的（low-cost）硬件上，并且机器的硬件错误常态化，所以让HDFS具有错误检测和快速、自动的恢复能力，是最核心的架构目标。HDFS处理的关键在于数据访问的高吞吐量，但是POSIX标准有很多硬性约束，所以HDFS一些关键方面对POSIX的语义做了一些修改。

 

其次，“移动计算”。

我觉得Hadoop对海量数据计算最巧妙的实现思想是“移动计算”的思想。在海量数据的情况下，Hadoop将计算逻辑移动到存储节点，因为请求计算和数据的距离越近就越高效。

 

02

HDFS的问题

HDFS作为优秀的分布式文件系统，目前来看还是存在一些问题，我总结为以下几点：

 

1. 计算存储耦合

上文介绍过HDFS采用移动计算的思想，计算的时候只需要将计算代码推送到存储节点上，即可在存储节点上完成数据本地化计算。所以Hadoop中的集群存储节点也是计算节点。

 

2. 扩容问题

正因为上文谈到的计算存储耦合问题，当存储空间或计算资源不足时，只能同时对两者进行扩容。如果用户的计算需求远远大于存储需求，此时扩容集群会造成存储的浪费，相反则是计算资源被浪费。集群节点增多，扩容成本增加，风险也增加了。

 

3. HDFS性能问题

HDFS NameNode的全局锁存在性能瓶颈。

 

4. HDFS成本问题

在HDFS文件系统中，典型文件大小一般都在G字节至T字节。由于HDFS的副本特性，一份文件至少会存储3份，这也会带来存储成本额外的提高。

 

针对上面一些问题，现在Hadoop采用存算分离架构的方案趋势越来越明显。

 

Hadoop 实现存算分离方案

 

方案一

Hadoop 兼容的文件系统

下图是Hadoop3.X 目前兼容的文件系统，支持AWS S3、腾讯云COS、阿里云OSS存储。可以看到用户在上传数据时候，需要调用对应云服务厂商的SDK进行数据的写入，下载文件也是一样的原理。 

图源：纯粹

 

为什么现在可以使用这种方式实现Hadoop的计算存储分离呢？

举一个例子，这是日常生活中遇到的经历：家里的带宽自从升级到100Mbps，从来不用保存电影，要看直接下载，基本几分钟就好了。这在几年前不可想象。

 

带宽的速度，特别是机房内的速度，已经从1000Mbps、2000Mbps提升到了10000Mbps，甚至100000Mbps。但是磁盘的速度基本没有太大的变化。带宽的提高带来了软件架构的变化。

 

方案二

云原生的Hadoop文件系统

虽然方案一可以实现计算存储分离，但是基本架构上还是存在问题：虽然带宽能增加，但如果Hadoop集群机房和对应的对象存储机房距离较远，网络抖动等原因会加大传输失败的几率；另外，比如判断一个目录需要多次的refs请求才能完成操作，多次请求会对性能造成影响。所以我们提出了方案二——DataSimba的文件缓存层。

图源：纯粹

 

上图是目前DataSimba的存算分离架构。

 

DataSimba的文件缓存层是一个java开发的jar包，兼容Hadoop文件系统，按照Hadoop FileSystem API规范来实现。

 

DataSimba的文件缓存层主要实现了Hadoop FileSystem的list、delete、rename、mkdir等接口，其中SimbaInputStream和SimbaOutputStream主要实现了对文件读写优化相关的功能（预读、缓存读、异步写、批量写、文件压缩）。Simba文件缓冲层通过JNI（Java Native Interface）技术转换为本地SimbaFs.so的调用实现相关方法，完成文件的上传/下载操作，作为中间缓存层实现计算存储分离。

 

目前基于这个方案，已经帮助某知名的视频创作工具和服务公司实现AWS EMR到S3的存算分离。

 

压测情况
DataSimba的文件缓存层对“读”做了预读和缓存操作，对“写”的操作通过异步写和批量写的优化，让其性能足够优秀。

 

性能到底咋样？看压测：

我们在发行版本为cdh5的集群、hdfs版本为2.6的情况下做了测试，使用3台阿里云4核14G的ECS做压力测试，对象存储选择的是OSS，并且保证集群节点和OSS在同一机房。下面是关于create_write、open_read、rename、delete 等操作的压测结果。

可以看到DataSimba的文件缓存层的性能在open_read、create_write、rename是远好于HDFS的。

 

小结

本文回顾了传统Hadoop分布式文件系统的架构和问题，我们认为，Hadoop采用存算分离架构的方案是势不可挡的。因此我们介绍了实现Hadoop存算分离的方案，并分享了DataSimba文件缓存层存算分离实现原理和压测情况。真心希望对你所有帮助。

 

本期作者 | 纯粹

奇点云数据平台后端架构专家，奇点云数据中台云原生后端研发负责人，曾在多家互联网科技公司担任PaaS骨干。