共计 4432 个字符，预计需要花费 12 分钟才能阅读完成。
摘要：中国工商银行联结华为实现了金融行业首家规模超千台的 Hadoop 集群大版本滚动降级，为期两周的降级过程冲破了传统的离线降级模式，真正实现了业务无感的平滑滚动降级。
2020 年 8 月 27 日，中国工商银行联结华为实现了金融行业首家规模超千台的 Hadoop 集群大版本滚动降级，为期两周的降级过程冲破了传统的离线降级模式，真正实现了业务无感的平滑滚动降级。全程集群作业无中断、性能无影响，为全行上百个利用、上千个场景、上万个作业保障了 7 *24 小时不间断的数据服务。本次滚动降级对金融科技领域意义重大，中国工商银行为金融同业建立了大数据服务连续性上的建设标杆，响应了国家大数据和人工智能策略技术洼地的建设要求，为金融同业大数据平台的高可用建设提供了可参考的综合解决方案。
一、我的项目背景
中国工商银行从 2002 年起继续优化数据架构，推动数据赋能业务，在实现数据大集中的同时，率先建设金融行业企业级数据仓库。以“凋谢、共享”为准则，工商银行于 2016 年启动大数据服务云体系的建设，实现了企业级全量数据集中和通用服务积淀，截至目前以牢靠、高效、易扩大的大数据和人工智能平台为根底，以数据中台为赋能外围，构建了集基础设施、大数据和人工智能技术、海量高时效全数据、规范智能共享服务、丰盛多样业务场景于一体的数据智能生态新模式（如图 1），助力全行服务提质增效，向智能化、生态化时代的跃进。
图 1 中国工商银行大数据服务云现有架构
工行大数据平台的 Hadoop 批量集群已超过一千个节点，日均解决作业数十万个，数据存储数十 PB，赋能于 180 余总行利用和境内外 41 家分行及子公司，承载了全行重点批量作业，其中包含监管报送、反洗钱、反欺诈、损益剖析、减值测算等多个重要业务场景，服务连续性需要较高。为了在保障 7 *24 小时不间断服务的前提下，维持技术引领，Hadoop 集群应做到业务无感的平滑滚动降级，保障技术组件的先进性，升高技术危险，深入技术能力，助力新技术场景翻新和 IT 架构转型降级。
二、我的项目内容
2.1 技术挑战
工行本次滚动降级面向的 Hadoop 集群，部署了 ZooKeeper、HDFS、YARN、MapReduce、Spark、Hive、HBase 等各类组件，各组件的版本更新必然存在一些适用性、兼容性问题（组件版本变更如表 1）。
表 1. 组件版本变更表
此外，集群中每日上万作业的执行，也为无感知的滚动降级加大了难度。次要挑战有以下几点：
一是 Hadoop 2.X 到 3.X 的跨大版本升级中，社区仅提供了 HDFS 的滚动降级能力，YARN 的社区原生指标版本因为与原版本协定不同，无奈反对滚动降级。
二是 Hive 1.2 到 3.1 的跨大版本升级中，因为元数据前后格局不兼容、API 前后版本有变动、局部语法不兼容等问题，导致社区原生版本无奈反对滚动降级。
三是社区原生版本的 HDFS 在降级过程中，删除的文件并不会物理删除，而是挪动到 trash 目录，这一解决对大容量集群的滚动降级造成存储资源压力，妨碍了残余信息爱护。
四是降级前后因为版本变动，每日上万任务量，如何保障安稳运行，尤其是损益剖析、减值测算等外围场景。
五是上千台的物理节点的环境下，须要确保在降级过程中，疾速应答硬件（磁盘、内存等）故障，不影响降级。
六是降级过程较为简单，应答集群降级状态强化监控、告警等运维治理服务，增强关键技术、治理瓶颈的应急响应。
2.2 技术保障
所谓滚动降级，就是借助于 Hadoop 外围组件的高可用机制，在不影响集群整体业务的状况下，一次降级 / 重启大量节点。循环滚动，直至集群所有节点降级到新版本。下图为已 HDFS 组件滚动降级示例：
为应答上述技术挑战我的项目组建了滚动降级小组，由社区 PMC、社区 Commiter、版本 Developer 形成，次要执行了以下技术保障：
一是依靠协定同步、元数据映射转换、API 封装转换等形式，解决了社区协定不同、元数据格式不同、API 变动等导致的兼容性问题，保障了滚动降级过程中低版本的组件客户端的失常应用，目前项目组已将发现的通用问题反馈开源社区。
二是针对 HDFS 社区新版本升级过程中的文件未删除问题，项目组额定实现了 trash 目录主动清理，将逻辑删除转换为物理删除，并增补了旧版本定期清理 trash 目录的工具。一方面确保了基础设施资源利用的有效性，升高存储老本；另一方面贯彻了国标、金标等保 2.0 中的残余信息爱护，确保要害信息存储空间的齐全开释。
三是具体评估了各组件降级过程及降级后版本的性能情况，实现了降级时长的预估，针对降级过程中和预先可能呈现的瓶颈点，做了相应架构调整及优化，助力实现滚动降级的全局可控、全程无感、全面无误。
为解决上千节点规模集群的调度性能，小组推出了自研 Superior 调度器，在旧版本的根底上深度优化了调度算法，将一维的调度转换为二维调度，实现调度速率晋升至每秒 35 万个 Container。
为解决大规模存储的瓶颈问题，社区推出了联邦解决方案，但不同的命名空间的引入，导致下层业务在开发、数据管理、保护上复杂度晋升，为解决这一问题，社区又推出了 Router Based Federation 个性，但因为在 NameNode 之上加了一层 Router 进行交互，导致性能降落。小组提供了如下优化：
l 通过在大集群生产环境中辨认要害瓶颈，咱们通过合并单次读写流程中的交互次数、应用改进的数据通信压缩算法等技术计划，将性能降落管制在 4% 以内。
l 为解决不同命名空间之间数据不平衡的问题，咱们利用 DataMovementTool 主动平衡不同命名空间之间的数据，大大降低了集群保护老本。
同时，小组发现 Hive 的元数据在面对海量表 / 分区的时候，也面临着十分大的瓶颈。尽管社区推出了 Metastore Cache 的解决方案，但仅实用于一个 MetaStore 的场景，多个 MetaStore 的缓存并不统一，导致此个性无奈在理论场景中应用。小组提出应用 Redis 作为代替计划，同时通过分布式锁、缓存黑白名单机制、缓存生命周期治理等技术手段加强了该个性的可用性。
为保障大规模集群在滚动降级期间的容错能力，小组提供了工作级“断点续传”能力，例如：
Hive 不中断业务能力：即当 Hive beeline 断连、Hive Server 因故障重启、MapReduce JobHistory 无响应等起因导致 Hive 工作失败时，工作可能持续重试运行，无需失败从头开始，大大降低了重试老本及工作时长。
AM 的断点续传能力：尽管 Yarn 的 Application Master 故障后，可能立刻在其余节点上被拉起，但之前已执行的计算工作只能从头开始解决。小组提供了 AM 记录工作执行状态、辨别工作执行进度能力，待 AM 因故障被重启拉起后，能够装置之前的记录状态继续执行，晋升了执行效率。
四是运维治理方面，项目组针对性的研发了降级治理服务界面，能够端到端、分步骤地实现滚动降级，便于查看滚动降级状态，实现组件级管制。为了升高在降级过程中对要害工作服务连续性的影响，我的项目实现了按降级批次暂停的性能，有助于在要害作业或者作业顶峰时段，通过暂停降级进行危险躲避，确保业务无影响。此外，为疾速解决降级过程中可能呈现的硬件故障，降级治理服务提供了故障节点隔离能力，在故障产生时，能够跳过对应节点的降级动作，保障了故障解决和降级的同步进行。
2.3 组织保障
本次降级确立了“危险可控、业务无感”的总体目标，因为指标集群规模大、波及利用广、相干部门多，除了上述技术保障伎俩，工行还采取了一系列伎俩，提供组织保障（见图 2），具体形容如下：
图 2 工行滚动降级我的项目组织保障
在项目管理方面，如何保障跨多部门高效协同地实现工作，是集群降级过程中一个微小的挑战。本次滚动降级我的项目，造成了大数据与人工智能实验室牵头、相干部门配合评审施行的组织模式。前者负责制订了整个我的项目具体计划和我的项目流程，通过外部多级评审机制，就总体方案与多部门疾速达成共识，同时依照不同的部门职责实现子任务分配，从而保障跨多部门的我的项目组织架构高效协同工作，安稳推动整体我的项目进度。
降级筹备方面，项目组一是实现了降级版本功能性、非功能性评估，重点验证了滚动降级的正确性、完整性、适用性；二是实现了对全行的利用场景的梳理，定制了分级验证机制，为每一个利用场景制订了相应适度的测试、验证计划，并实现了正式邮件的告知，用于百余利用的配合验证。对于分级验证机制中的数十个典型利用，通过行内“工作单”项目管理形式纳入了我的项目级配合流程，确保对降级过程进行重点验证。
灾备应急设计方面，工行制订了具体的保障计划，包含数据备份策略和回滚策略。对于备份策略，一是在降级之前全量备份集群元数据，排除因元数据失落而导致丢数的状况；二是对于重点批量数据采纳双园区备份，实现双加载以防止主集群降级中的故障危险影响业务。对于回滚策略，一是在技术维度保障了回滚原版本的可行性，保障业务的连续性，二是确立了“无奈疾速解决的生产故障”、“大规模批量作业中断”两项回滚断定条件。上述的“双加载”是重点业务双活运行计划的一部分，次要波及监管报送类损益剖析、减值测算等多个利用场景，该类作业在备集群同步运行，实现重点批量双园区双活，切实防止因单边园区故障影响业务连续性的状况呈现。
降级模仿方面，为了遵循危险可控、循序渐进的准则，工行先后进行了两套较小规模的集群滚动降级。一是 2020 年 3 月针对 Hadoop 批量备集群进行滚动降级，该集群负责同城双活运行的重要批量作业，经生产环境理论验证，降级过程中业务无感知，也未发现集群侧危险；二是 2020 年 4 月，工行搭建一套规模更大的 Hadoop 批量集群，一方面加强批量双活承载能力，另一方面再次验证了滚动降级。两次生产环境模拟之外，开发、测试环境共计 10 套不同的 Hadoop 集群陆续实现了滚动降级验证，实现了降级危险的演绎总结和研发订正，为最大规模的集群降级打下坚实基础。
三、总结与瞻望
中国工商银行联结华为公司实现的本次金融业首家规模超千台的 Hadoop 集群大版本滚动降级，实现了客户无感知，切实保障了客户的外围利益，标记着工行向金融大数据蓝图迈出了重要的一步，借助于 Hadoop 外围组件的高可用机制，实现了端到端分步骤的滚动降级，实现了降级过程中的可视化管制和治理。
大数据的高速倒退带来的社会经济的“反动”，在广度、深度和速度上都将会是空前的，也将会远远超出工业社会的常识和认知，并且倒退所带来的的挑战和艰难也将是前所未有的。在此背景下，中国工商银行会持续建立健全企业级大数据平台，进一步晋升数据洞察能力和基于场景的数据挖掘能力，充沛开释大数据作为基础性策略资源的外围价值，为金融科技利用实际和大数据生态建设建设添砖加瓦。
本文分享自华为云社区《华为云 FusionInsight MRS 金融行业首个 1000+ 大集群滚动降级胜利》，原文作者：Sailing27。
点击关注，第一工夫理解华为云陈腐技术~