HDFS Federation在美团点评的应用与改进

时间 2019-11-09

原文原文链接

HDFS Federation在美团点评的应用与改进

美团点评离线存储团队 ·2017-04-14 19:49html

1、背景

2015年10月，通过一段时间的优化与改进，美团点评HDFS集群稳定性和性能有显著提高，保证了业务数据存储量和计算量爆发式增加下的存储服务质量；然而，随着集群规模的发展，单组NameNode组成的集群也产生了新的瓶颈：node

扩展性：根据HDFS NameNode内存全景和HDFS NameNode内存详解这两篇文章的说明可知，NameNode内存使用和元数据量正相关。180GB堆内存配置下，元数据量红线约为7亿，而随着集群规模和业务的发展，即便通过小文件合并与数据压缩，仍然没法阻止元数据量逐渐接近红线。
可用性：随着元数据量愈来愈接近7亿，CMS GC频率也愈来愈高，期间也曾发生过一次在CMS GC过程当中因为大文件getBlocklocation并发太高致使的promotion fail。
性能：随着业务的发展，集群规模接近2000台，NameNode响应的RPC QPS也在逐渐提升。愈来愈高并发的读写，与NameNode的粗粒度元数据锁，使NameNode RPC响应延迟和平均RPC队列长度都在慢慢提升。
隔离性：因为NameNode没有隔离性设计，单一对NameNode负载太高的应用，会影响到整个集群的服务能力。

HDFS Federation是Hadoop-0.23.0中为解决HDFS单点故障而提出的NameNode水平扩展方案。该方案能够为HDFS服务建立多个namespace，从而提升集群的扩展性和隔离性。基于以上背景，咱们在2015年10月发起了HDFS Federation改造项目。apache

HDFS Federation是以客户端为核心的解决方案，对Hadoop客户端影响较大，在落地应用时也有较多的限制，对上层应用模式有较强的依赖。本文分享了在这次改造的过程当中，基于美团点评的业务背景，咱们对HDFS Federation自己作出的改进和对拆分过程的流程化处理，但愿能为须要落地HDFS Federation的同窗提供一个参考。安全

2、上层应用与业务

基础架构方面，美团点评Hadoop版本为2.4.1，使用了Kerberos做为认证支持。相关技术栈中，Spark应用版本包含1.一、1.三、1.四、1.5，同时使用了Zeppelin做为Spark Notebook的开发工具。在查询引擎方面Hive有0.13和1.2两个版本，同时重度依赖Presto和Kylin，除此以外，也对DMLC提供了平台性支持。数据结构

工具链建设方面，基于Hadoop生态，数据平台组自研了各种平台工具，其中受Federation影响的部分工具备：架构

数仓管理：知足各种Hive表的DDL需求，同时支持UDF和文件上传建表。
原始数据接入：支持日志抓取和MySQL数据接入数据仓库。
非结构数据开发：支持做业托管，提供MR/Spark做业编译、管理、测试、部署一站式服务。
数仓开发：支持ETL的一站式开发和管理，同时在任务状态、诊断、SLA保证方面也有强力的支持；针对流程测试以及数据回收进行了隔离，使用统一的test.db和backup.db。
调度系统：自研的调度系统支撑了天天数万个调度做业，准确的处理做业间的强弱依赖关系，有效的保证了按天数据生产。
查询平台：统一了Hive和Presto的查询入口。

自研的数据平台基本覆盖了90%的数据开发需求，一方面有效的控制了Hadoop客户端的数量，收紧了用户入口，对于发放的客户端，配合Kerberos，也具备很高的掌控力，另外一方面实现了对用户行为的源码级掌控力。并发

数据开发方面，美团点评业务一直持续着爆发式增加，总体集群规模和数据生产流程增量每一年都接近double。业务发展也推进了组织结构的发展，进而也影响到了相应的大数据资产：app

一个Hadoop帐号可能经历过多个业务线，用户应用中，对其余Hadoop帐号的数据进行读写、move较为常见，对这类行为也没有进行过梳理和限制。
完成平台接入后，对生产流程管理的规范较多，但对用户代码的规范较少，用户代码风格多样。

3、应用与改进

3.1 Federation的局限性

在解决NameNode扩展能力方面，社区虽然提供了Federation，但这个方案有很强的局限性：运维

HDFS路径Scheme须要变为ViewFs，ViewFs路径和其余Scheme路径互不兼容，好比DistributedFileSystem没法处理ViewFs为Scheme的路径，也就是说若是启用，则须要将Hive meta、ETL脚本、MR/Spark做业中的全部HDFS路径均的scheme改成viewfs。
若是将fs.defaultFS的配置从hdfs://ns1/变为viewfs://ns/，将致使旧代码异常，经过脚本对用户上万个源码文件的分析，经常使用的HDFS路径风格多样，包括hdfs:///user、hdfs://ns1/user、/user等，若是fs.defaultFS有所更改，hdfs:///user将会因为缺失nameservice变为非法HDFS路径。
ViewFs路径的挂载方式与Linux有所区别：
- 若是一个路径声明了挂载，那么其同级目录都须要进行挂载，好比/user/path_one挂载到了hdfs://ns1/user/path_one上，那么/user/path_two也须要在配置中声明其挂载到哪一个具体的路径上。
- 若是一个路径声明了挂载，那么其子路径不能再声明挂载，好比/user/path_one挂载到了hdfs://ns1/user/path_one上，那么其子路径也自动而且必须挂载到hdfs://ns1/user/path_one上。
一次路径请求不能跨多个挂载点：
- 因为HDFS客户端原有的机制，一个DFSClient只对应一个nameservice，因此一次路径处理不能转为多个nameservice的屡次RPC。
- 对于跨挂载点的读操做，只根据挂载配置返回假结果。
- 对于跨挂载点的rename（move路径）操做，会抛出异常。
Federation架构中，NameNode相互独立，NameNode元数据、DataNode中块文件都没有进行共享，若是要进行拆分，须要使用DistCp，将数据完整的拷贝一份，存储成本较高；数据先被读出再写入三备份的过程，也致使了拷贝效率的低效。
Federation是改造了客户端的解决方案，重度依赖客户端行为。方案中NameNode相互独立，对Federation没有感知。另外HDFS为Scheme的路径，不受Federation挂载点影响，也就是说若是对路径进行了namespace拆分后，若是由于代码中的路径或客户端配置没有及时更新，致使流程数据写入老数据路径，那么请求依然是合法但不符合预期的。

对其中一些名词的解释：

在HDFS中namespace是指NameNode中负责管理文件系统中的树状目录结构以及文件与数据块的映射关系的一层逻辑结构，在Federation方案中，NameNode之间相互隔离，所以社区也用一个namespace来指代Federation中一组独立的NameNode及其元数据。
Scheme是URI命名结构（[scheme:][//authority][path][?query][#fragment]）中的一部分，用于标识URI所使用的协议，HDFS路径也是一个URI，常见的Scheme为HDFS，在Federation的方案中，HDFS路径Scheme为ViewFs。
挂载点（mount point），它在HDFS Federation中和Linux中的概念近似，指在HDFS客户端上下文中，将ViewFs为Scheme的一个路径，好比viewfs://ns/user，映射到一个具体的HDFS路径上，好比hdfs://ns2/user，这个路径能够是任意Scheme的HDFS路径，这样对于viewfs://ns/user实际上会被转换为对hdfs://ns2/user的操做。

3.2 局限性带来的问题和解决

3.2.1 Scheme兼容性问题

Scheme的兼容问题要求在上线时全量替换业务方代码中的路径，虽然对业务方大多数源码具备掌控力，可是因为不可灰度带来的全量修改带来的测试、上线、修复工做的成本，全量操做带来的运维时间，以及对数据生产稳定性的影响都是不能接受的。为此，以能灰度启用Federation特性为目标，对HDFS客户端进行了修改：机器学习

增长了ViewFs和HDFS两种Scheme路径的兼容性：
- 修改了org.apache.hadoop.fs.FileSystem.fixRelativePart(Path)，该函数在DistributedFileSystem各种请求处理中均有调用，本来用于处理相对路径，而ViewFileSystem不会调用。在这里，若是遇到了ViewFs为Scheme的路径，则利用ViewFileSystem中的挂载信息返回真正的HDFS路径。
- 修改了org.apache.hadoop.fs.viewfs.ViewFileSystem.getUriPath(Path)，该函数在ViewFileSystem各种请求处理中均有调用，本来用做判断路径Scheme为ViewFs，同时处理相对路径。一方面，因为Federation的挂载配置中，只有经过挂载点查询真实路径的数据结构，逆向查询比较复杂，改动也比较大，另外一方面，从运营角度看咱们也不但愿维持很是复杂的挂载配置。因此在这里，作了一个限定，对于HSFS为Scheme的路径与其在Federation的挂载点路径相同，因此在此函数中若是遇到了HDFS为Scheme的路径，直接使用org.apache.hadoop.fs.Path.getPathWithoutSchemeAndAuthority(Path)去掉Scheme便可。
fs.defaultFS变动会对原有代码带来影响，可是将其配置为ViewFs为Scheme的路径才能使HDFS Scheme的应用逐渐收敛，所以，咱们增长了用于指定默认namespace的配置fs.defaultNS，使hdfs:///user这样即便没有提供Authority的路径也能路由到正确的NameNode。

针对Scheme局限性的改造，虽然提升了兼容性，使方案可以进行灰度，但却使DistributedFileSystem和ViewFileSystem耦合，又增长了一条ViewFileSystem挂载限制，所以只适合在过分期间应用。

3.2.2 挂载配置限制

ViewFs的挂载方式与Linux有所区别，若是彻底继承现有HDFS不变，则须要很是多的挂在配置项，而且后续每次增长Hive库、用户目录，初期咱们使用了运营手段解决了这个问题：

将迁移路径放到独立的目录下，好比/user/hivedata/xx.db，迁移到/ns2/hivedata/xx.db，这样挂载声明则不会太过复杂。
因为用户组路径大都应用于MR、Spark做业中，修改路径须要从新编译，所以初期应用时，只对Hive库路径。
因为跨namespace不能进行rename，因此分析NameNode审计日志，获得Hive库路径和用户组路径没有rename关系的库，只对这些库进行迁移。

经过以上三种手段，对于ETL流程这种不须要编译的代码，能够直接替换，对于MR、Spark做业来讲推进修改的成本也有所下降。

为了进一步下降后续拆分红本，咱们在ETL和做业开发两个方面提供并推广了根据库表信息从Hive meta中取得库表HDFS路径的工具，减小了代码中对库表路径的硬编码。

以上的运维手段，能知足美团侧常规的拆分需求，可是随着点评侧数据融合，点评侧数据也做为总体集群的一个namespace加入进来。然而，咱们对点评侧平台的掌控力没有深刻到源码级别，所以没法统一推进更改HDFS路径。若是不对挂载逻辑进行修改，在合并重复路径时，须要将美团侧/user路径合并到点评侧/user路径中，可是因为跨namespace没法进行rename，势必会形成用户做业的失败。所以，咱们对挂载逻辑进行了修改，使其同Linux的挂载方式相同。

3.2.3 同namespace，不一样挂载点不能rename

业务方不少Hive库表数据会先生成在测试库表或用户目录中，验证完成后将数据加载到对应时间分区中。在挂载配置中，业务方Hive库、Hive测试库、用户组目录通常不会挂载到同一目录下，即便三者在同一namespace下，因为不一样挂载点间不能rename的限制，也没法进行加载。在源码分析的过程当中，发现如下注释：

// Note we compare the URIs. the URIs include the link targets.
// hence we allow renames across mount links as long as the mount links
// point to the same target.
if (!resSrc.targetFileSystem.getUri().equals(
          resDst.targetFileSystem.getUri())) {
  throw new IOException("Renames across Mount points not supported");
}
*/
//
// Alternate 3 : renames ONLY within the the same mount links.
//
if (resSrc.targetFileSystem !=resDst.targetFileSystem) {
  throw new IOException("Renames across Mount points not supported");
}

能够发现社区是有考虑相同namespace路径能够进行rename操做的（注释掉的缘由没有找到），所以，咱们将这段逻辑打开，替换掉了“renames ONLY within the the same mount links”。

3.2.4 存储成本与拷贝效率问题

使用Federation方案时，集群节点规模为2000多台，元数据已达6亿，存储使用已近80%。按照规划，存储容量将不足以支撑所有待迁移数据，可是拆成屡次操做，周期和运维成本都比较高，所以咱们开始调研FastCopy。

FastCopy是Facebook开源的数据拷贝方案，它经过如下方式在不增长存储成本的状况下对数据进行拷贝：

经过getBlockLocation获取源文件块分布。
经过ClientProtocol（HDFS包中的接口，下同）建立目标文件。
经过ClientProtocol addBlock，在参数中，指定源块分布做为favoredNodes，常规状况下NameNode会优先选择favoredNodes中的DataNode做为块的保存位置，特殊状况下（好比存储空间不足，DataNode负载太高等）也有可能返回不一样位置。
整理源和目标块位置，使相同DataNode的位置能一一对应。
经过ClientDatanodeProtocol向源DataNode发送copyBlock请求。
在DataNode中，若是copyBlock请求中的源和目标相同，则经过在Linux文件系统中创建硬链的方式完成拷贝，不然经过原有逻辑完成拷贝。

可是，在计划合入时，该方案也有自身的问题：

社区path为HDFS-2139，一直处于未合入状态，且当时Patch内容相对Facebook的方案来讲，部分细节没有考虑，例如文件lease，没法构造硬链时的降级，DFS Used的统计问题等。
Facebook的源码相对成熟，但其源码基于0.20（facebookarchive/hadoop-20），已有四年没有更新，不少源码发生变化，DFS Used的统计问题也没有解决。
虽然Facebook将FastCopy合入DistCp，但也有部分缺陷：
- 每一个路径生成一个mapper，每一个mapper只处理一个路径，若是目录层次太高，容易致使数据倾斜，若是目录层次过低，容易产生过多mapper。
- 只对迁移路径进行属主同步，其父目录没有处理。
- 与DistCp耦合定制比较复杂。

因此，综合以上内容，咱们完善了HDFS-2139，并更新了issue，在合入Facebook实现的基础上解决了DFS Used的统计问题；除了这个Patch，咱们也实现了独立的FastCopy MR做业，解决了上述问题。最终，在拆分时15小时完成14+PB数据拷贝，保证了方案的可行性。

另外须要注意的是，对于HDFS来讲，没法感知哪一个块是经过硬链构造的，所以，一旦源和目标文件同时存在时，开启balancer，会由于块的迁移致使存储使用的增长。所以，迁移期间，通常建议暂停相关namespace的balancer。

3.2.5 重度依赖客户端

基于以上几点改进，虽然下降了拆分红本和兼容性，使Federation的应用成为可迭代方案，可是若是没有对客户端强大的掌控力，客户端实例不能彻底更新，HDFS路径硬编码不能获得完全梳理，反而会形成数据生产方面的混乱，成为此方案的掣肘。

通过美团侧数据平台的多年运营，对客户端以及业务代码有很是强的掌控力，有效避免了上述问题的发生。

3.3 计算和查询引擎的问题和解决

一方面，虽然Federation已出现了多年，但Hive、Spark等上层应用对Federation的支持仍然存在问题，另外一方面，随着应用的逐渐加深，虽然有些问题并非代码bug，但在美团点评的应用场景下，仍然产生了必定问题。咱们针对这些问题，进行了探索和改进。

3.3.1 安全问题

安全方面，计算引擎（包括MapReduce和Spark）在提交做业时，会向NameNode发送RPC，获取HDFS Token。在ViewFileSystem中，会向全部namespace串行的申请Token，若是某个namespace的NameNode负载很高，或者发生故障，则任务没法提交，YARN的ResourceManager在renew Token时，也会受此影响。随着美团点评的发展YARN做业并发量也在逐渐提升，保存在HDFS上的YARN log因为QPS太高，被拆分为独立的namespace。但因为其并发和YARN container并发相同，NameNode读写压力仍是很是大，常常致使其RPC队列打满，请求超时，进而影响了做业的提交。针对此问题，咱们作出了一下改进：

container日志由NodeManager经过impersonate写入HDFS，这样客户端在提交Job时，就不须要YARN log所在namespace的Token。
ViewFileSystem在获取Token时，增长了参数，用于指定不获取哪些namespace的Token。
因为做业并不老是须要全部namespace中的数据，所以当单个namespace故障时，不该当影响其余namespace数据的读写，不然会下降整个集群的分区容忍性和可用性，ViewFileSystem在获取Token时，即便失败，也不影响做业提交，而是在真正访问数据时做业失败，这样在不须要的Token获取失败时，不影响做业的运行。

另外，客户端获取到的Token会以namespace为key，保存在一个自定义数据结构中（Credentials）。ResourceManager renew时，遍历这个数据结构。而NodeManager在拉取JAR包时，根据本地配置中的namespace名去该数据结构中获取对应Token。所以须要注意的是，虽然namespace配置和服务端不一样不影响普通HDFS读写，但提交做业所使用的namespace配置须要与NodeManager相同，至少会用到的namespace配置须要是一致的。

3.3.2 已存在Patch问题

3.3.3 其余问题

Hive create table .. as .. 会致使临时文件所在目录和表目录不在同一namespace，致使move结果失败，目前已修复，思路同HIVE-6152，将临时文件生成在表目录中。
Hive表的元数据中，SERDEPROPERTIES中，可能会存在对HDFS路径的依赖，在梳理路径硬编码时，容易忽略掉。
Spark 1.1在启用viewfs时，会产生不兼容问题。
开源分布式机器学习项目DMLC目前也尚不兼容ViewFs。

4、拆分流程与自动化

随着namespace拆分经验的积累，其流程也逐渐清晰和明确：

当namespace的NameNode逐渐接近瓶颈（包括RPC和元数据量）时，对Hadoop用户对应的用户组目录和Hive库目录进行分析，得出元数据量（经过分析fsimage）和一天内RPC量（经过分析审计日志），进而得出须要拆分的用户数据。
对于须要拆分的数据，分析其和不须要拆分数据的rename关系，若是存在rename关系，则须要从新选择拆分数据。
若是须要，则搭建新namespace环境。
关闭相关namespace balancer。
根据fsimage，分析出待拆分路径元数据分布，得出一个路径列表，使列表中每一个路径下的文件块数基本接近。
基于第四步的结果进行首轮拷贝，首轮拷贝中针对不须要比较验证的状况做出了优化：FastCopy MR工具会递归的拷贝路径，若是目标路径已存在说明以前已拷贝成功过，则不进行拷贝。
以后进行多轮补充拷贝：经过ls -r获得文件和目录列表；拷贝过程当中开启-delete -update，非递归的进行检测与拷贝，这样对于源目录有更新的文件和目录会进行覆盖（包括权限和属主的更新），源目录新增的目录和文件会进行拷贝，源目录删除的文件和目录会进行删除；这样，能够会每一层的目录进行检测，能够同步目录权限和属主发生的变化，同时也不会产生较大的数据倾斜。
准备好新挂载配置，找一个非工做时间，进行最终一轮的操做：
a. 禁止源目录的权限（FastCopy使用hdfs身份运行不受影响）。
b. 进行最后一轮补充拷贝。
c. 因为数据大多数状况下基于硬链进行拷贝，因此存在文件长度相同，但内容有问题的可能性极低，拷贝完成后，能够经过du路径，校验并逐渐找到数据长度不一致的文件，进行重考。
d. 对客户端分发新挂载配置。
e. 对NodeManager分发新挂载配置，并进行decommission，重启（YARN已支持recovery）。
f. 更新Hive meta。
g. 开放目标目录权限。
观察一周，若是没有问题则删除源目录。
重启balancer。

以上是已经固定下来的步骤，其中第一、二、五、六、7步，第8步中的a~c是能够进行自动化的，这也是后续工做过程当中，有待完善的部分。

5、总结

HDFS Federation做为以客户端配置为核心的NameNode横向扩容解决方案，对业务背景有较强的依赖，另外一方面方案自己也有较多的局限性。本文以美团点评实际应用场景出发，介绍了方案局限性在业务背景下的影响，分享了对局限性的解决和实施经验。对HDFS Federation应用到已运营较长时间的大规模HDFS集群有必定的借鉴意义。

六参考文献

七做者简介

俊宏，美团点评离线存储团队高级开发工程师，2013年毕业于哈尔滨工程大学，2015年加入美团，负责美团点评HDFS、HBase服务的开发和运维，HBase服务负责人。

美团点评离线团队，深耕Hadoop生态中HDFS、HBase、CarbonData、Alluxio等泛存储领域，尤为在HDFS、HBase方面有大量的源码和架构改造经验，致力于为美团点评提供稳定、高效、易用的大数据存储服务。

最后发个广告，美团点评数据平台中心长期招聘离线计算平台、实时计算平台、数据平台工具链与服务等方向的技术专家，有兴趣的同窗能够发送简历到liujunhong02#meituan.com。

HDFS Federation在美团点评的应用与改进

HDFS Federation在美团点评的应用与改进

1、背景

2、上层应用与业务

3、应用与改进

3.1 Federation的局限性

3.2 局限性带来的问题和解决

3.2.1 Scheme兼容性问题

3.2.2 挂载配置限制

3.2.3 同namespace，不一样挂载点不能rename

3.2.4 存储成本与拷贝效率问题

3.2.5 重度依赖客户端

3.3 计算和查询引擎的问题和解决

3.3.1 安全问题

3.3.2 已存在Patch问题

3.3.3 其余问题

4、拆分流程与自动化

5、总结

六 参考文献

七 做者简介

六参考文献

七做者简介