舟山网站建设设计,wordpress网站迁移教程,网络设计的三个层次,论坛类网站建设一、背景 2015年10月#xff0c;经过一段时间的优化与改进#xff0c;美团点评HDFS集群稳定性和性能有显著提升#xff0c;保证了业务数据存储量和计算量爆发式增长下的存储服务质量#xff1b;然而#xff0c;随着集群规模的发展#xff0c;单组NameNode组成的集群也产生… 一、背景 2015年10月经过一段时间的优化与改进美团点评HDFS集群稳定性和性能有显著提升保证了业务数据存储量和计算量爆发式增长下的存储服务质量然而随着集群规模的发展单组NameNode组成的集群也产生了新的瓶颈 * 扩展性根据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改造项目。 HDFS Federation是以客户端为核心的解决方案对Hadoop客户端影响较大在落地应用时也有较多的限制对上层应用模式有较强的依赖。本文分享了在此次改造的过程中基于美团点评的业务背景我们对HDFS Federation本身做出的改进和对拆分过程的流程化处理希望能为需要落地HDFS Federation的同学提供一个参考。 二、上层应用与业务 基础架构方面美团点评Hadoop版本为2.4.1使用了Kerberos作为认证支持。相关技术栈中Spark应用版本包含1.1、1.3、1.4、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。业务发展也推动了组织结构的发展进而也影响到了相应的大数据资产 * 一个Hadoop账号可能经历过多个业务线用户应用中对其他Hadoop账号的数据进行读写、move较为常见对这类行为也没有进行过梳理和限制。 * 完成平台接入后对生产流程管理的规范较多但对用户代码的规范较少用户代码风格多样。 三、应用与改进 3.1 Federation的局限性 在解决NameNode扩展能力方面社区虽然提供了Federation但这个方案有很强的局限性 1. HDFS路径Scheme需要变为ViewFsViewFs路径和其他Scheme路径互不兼容比如DistributedFileSystem无法处理ViewFs为Scheme的路径也就是说如果启用则需要将Hive meta、ETL脚本、MR/Spark作业中的所有HDFS路径均的scheme改为viewfs。 2. 如果将fs.defaultFS的配置从hdfs://ns1/变为viewfs://ns/将导致旧代码异常通过脚本对用户上万个源码文件的分析常用的HDFS路径风格多样包括hdfs:///user、hdfs://ns1/user、/user等如果fs.defaultFS有所更改hdfs:///user将会由于缺失nameservice变为非法HDFS路径。 3. 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上。 4. 一次路径请求不能跨多个挂载点 * 由于HDFS客户端原有的机制一个DFSClient只对应一个nameservice所以一次路径处理不能转为多个nameservice的多次RPC。 * 对于跨挂载点的读操作只根据挂载配置返回假结果。 * 对于跨挂载点的renamemove路径操作会抛出异常。 5. Federation架构中NameNode相互独立NameNode元数据、DataNode中块文件都没有进行共享如果要进行拆分需要使用DistCp将数据完整的拷贝一份存储成本较高数据先被读出再写入三备份的过程也导致了拷贝效率的低效。 6. 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库、用户目录初期我们使用了运营手段解决了这个问题 1. 将迁移路径放到独立的目录下比如/user/hivedata/xx.db迁移到/ns2/hivedata/xx.db这样挂载声明则不会太过复杂。 2. 由于用户组路径大都应用于MR、Spark作业中修改路径需要重新编译因此初期应用时只对Hive库路径。 3. 由于跨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开源的数据拷贝方案它通过以下方式在不增加存储成本的情况下对数据进行拷贝 1. 通过getBlockLocation获取源文件块分布。 2. 通过ClientProtocolHDFS包中的接口下同创建目标文件。 3. 通过ClientProtocol addBlock在参数中指定源块分布作为favoredNodes常规情况下NameNode会优先选择favoredNodes中的DataNode作为块的保存位置特殊情况下比如存储空间不足DataNode负载过高等也有可能返回不同位置。 4. 整理源和目标块位置使相同DataNode的位置能一一对应。 5. 通过ClientDatanodeProtocol向源DataNode发送copyBlock请求。 6. 在DataNode中如果copyBlock请求中的源和目标相同则通过在Linux文件系统中建立硬链的方式完成拷贝否则通过原有逻辑完成拷贝。 但是在计划合入时该方案也有自身的问题 社区path为HDFS-2139一直处于未合入状态且当时Patch内容相对Facebook的方案来说部分细节没有考虑例如文件lease无法构造硬链时的降级DFS Used的统计问题等。Facebook的源码相对成熟但其源码基于0.20facebookarchive/hadoop-20已有四年没有更新很多源码发生变化DFS Used的统计问题也没有解决。虽然Facebook将FastCopy合入DistCp但也有部分缺陷 每个路径生成一个mapper每个mapper只处理一个路径如果目录层次过高容易导致数据倾斜如果目录层次太低容易产生过多mapper。只对迁移路径进行属主同步其父目录没有处理。与DistCp耦合定制比较复杂。所以综合以上内容我们完善了HDFS-2139并更新了issue在合入Facebook实现的基础上解决了DFS Used的统计问题除了这个Patch我们也实现了独立的FastCopy MR作业解决了上述问题。最终在拆分时15小时完成14PB数据拷贝保证了方案的可行性。 另外需要注意的是对于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问题 https://issues.apache.org/jira/browse/HADOOP-12253https://issues.apache.org/jira/browse/TEZ-2600https://issues.apache.org/jira/browse/HIVE-11364https://issues.apache.org/jira/browse/HIVE-10790https://issues.apache.org/jira/browse/HIVE-6152https://issues.apache.org/jira/browse/HIVE-11920https://issues.apache.org/jira/browse/HIVE-75293.3.3 其他问题 Hive create table .. as .. 会导致临时文件所在目录和表目录不在同一namespace导致move结果失败目前已修复思路同HIVE-6152将临时文件生成在表目录中。Hive表的元数据中SERDEPROPERTIES中可能会存在对HDFS路径的依赖在梳理路径硬编码时容易忽略掉。Spark 1.1在启用viewfs时会产生不兼容问题。开源分布式机器学习项目DMLC目前也尚不兼容ViewFs。四、拆分流程与自动化 随着namespace拆分经验的积累其流程也逐渐清晰和明确 1. 当namespace的NameNode逐渐接近瓶颈包括RPC和元数据量时对Hadoop用户对应的用户组目录和Hive库目录进行分析得出元数据量通过分析fsimage和一天内RPC量通过分析审计日志进而得出需要拆分的用户数据。 2. 对于需要拆分的数据分析其和不需要拆分数据的rename关系如果存在rename关系则需要重新选择拆分数据。 3. 如果需要则搭建新namespace环境。 4. 关闭相关namespace balancer。 5. 根据fsimage分析出待拆分路径元数据分布得出一个路径列表使列表中每个路径下的文件块数基本接近。 6. 基于第四步的结果进行首轮拷贝首轮拷贝中针对不需要比较验证的情况作出了优化FastCopy MR工具会递归的拷贝路径如果目标路径已存在说明之前已拷贝成功过则不进行拷贝。 7. 之后进行多轮补充拷贝通过ls -r得到文件和目录列表拷贝过程中开启-delete -update非递归的进行检测与拷贝这样对于源目录有更新的文件和目录会进行覆盖包括权限和属主的更新源目录新增的目录和文件会进行拷贝源目录删除的文件和目录会进行删除这样可以会每一层的目录进行检测可以同步目录权限和属主发生的变化同时也不会产生较大的数据倾斜。 8. 准备好新挂载配置找一个非工作时间进行最终一轮的操作 a. 禁止源目录的权限FastCopy使用hdfs身份运行不受影响。 b. 进行最后一轮补充拷贝。 c. 由于数据大多数情况下基于硬链进行拷贝所以存在文件长度相同但内容有问题的可能性极低拷贝完成后可以通过du路径校验并逐渐找到数据长度不一致的文件进行重考。 d. 对客户端分发新挂载配置。 e. 对NodeManager分发 新挂载配置并进行decommission重启YARN已支持recovery。 f. 更新Hive meta。 g. 开放目标目录权限。 9. 观察一周如果没有问题则删除源目录。 10. 重启balancer。 以上是已经固定下来的步骤其中第1、2、5、6、7步第8步中的a~c是可以进行自动化的这也是后续工作过程中有待完善的部分。 五、总结 HDFS Federation作为以客户端配置为核心的NameNode横向扩容解决方案对业务背景有较强的依赖另一方面方案本身也有较多的局限性。本文以美团点评实际应用场景出发介绍了方案局限性在业务背景下的影响分享了对局限性的解决和实施经验。对HDFS Federation应用到已运营较长时间的大规模HDFS集群有一定的借鉴意义。 六 参考文献 HDFS NameNode内存全景HDFS NameNode内存详解HDFS FederationHDFS scalability with multiple namenodesAN INTRODUCTION TO HDFS FEDERATIONHDFS Federation设计动机与基本原理七 作者简介 俊宏美团点评离线存储团队高级开发工程师2013年毕业于哈尔滨工程大学2015年加入美团负责美团点评HDFS、HBase服务的开发和运维HBase服务负责人。 美团点评离线团队深耕Hadoop生态中HDFS、HBase、CarbonData、Alluxio等泛存储领域尤其在HDFS、HBase方面有大量的源码和架构改造经验致力于为美团点评提供稳定、高效、易用的大数据存储服务。 最后发个广告美团点评数据平台中心长期招聘离线计算平台、实时计算平台、数据平台工具链与服务等方向的技术专家有兴趣的同学可以发送简历到liujunhong02#meituan.com。
