马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
×
作者：互联网大数据团队-Wang Zhiwen
本文重要先容了 vivo 大数据架构的演进历程中 YARN 服务的升级事项，从团体方案出发分析每个环节碰到的标题难点并逐一分析解说，对于研究调理器性能和从事大数据运维工作的同砚具有较大的参考鉴戒代价。 1分钟看图把握焦点要点👇
图 1 VS 图 2，您更倾向于哪张图来辅助明白全文呢？欢迎在品评区留言~
一、配景
vivo 大数据平台早期引入的 Hadoop YARN 2.6.0 版本，在长期运行中已渐渐难以满意当前业务对资源管理服从与集群扩展本事的更高要求。由于该低版本缺乏对 Node Labels 资源隔离、Timeline Server 以及 YARN Federation 等高版本焦点特性的支持，随着集群规模和数量一连增长，在现有根本本事上无法提升运维服从及资源使用率，这对我们万台规模的大集群、日均支持近百万任务的平台是无法担当的。
别的，在盘算引擎层面，除 Spark3 外的其他引擎均无法直接访问基于纠删码（Erasure Coding, EC）存储的冷备数据，严峻制约了数据架构的完备性与盘算服从。这不但限定了多元盘算场景对冷数据的机动调用，也使我们无法充实开释 EC 冷备技能在低落存储本钱方面的潜力。
通过将 YARN 升级至更高版本，我们得以重构集群团体架构：一方面，借助更精致的资源调理本事和加强的多场景隔离机制，能显着提升集群稳固性与资源使用服从；另一方面，同一各盘算引擎底层的 Hadoop 依靠，实现对 EC 冷备数据的无缝读写支持。此次升级不但买通了冷热数据一体化处置处罚的链路，也为未来多样化的盘算负载提供了更高效、可扩展、易维护的根本办法支持。
二、vivo YARN 架构演进历程
vivo 大数据团队创建较早，在履历数据量与集群规模的迅猛增长后，我们深刻意识到：单纯依靠呆板堆叠来满意不停扩张的大数据需求，是一种投入产出比极低的粗放模式。为此，自 2020 年起，团队开始体系性投入人力，探索大数据架构的深度演进，旨在提升集群团体资源使用率，更高效、机动地支持多样化的用户需求。以下是我们自 2020 年以来 Hadoop YARN 服务的关键演进历程：
这一演进历程，标记着 vivo 大数据平台从传统单体集群架构向今世化、精致化、高弹性的资源管理体系的深刻转型。我们不但体系性办理了早期版本在资源隔离、调理公平、运维可扩展性等方面的固有缺陷，更通过存储与盘算协同升级，实现了本钱与效能的双重优化。现在，一个同一、高效、可扩展的大数据根本办法底座已然成型，为未来 AI 与大数据融合、多云调理、Serverless 盘算等创新场景提供告终实支持。
三、升级流程及难点
为实现整个集群的平滑升级，并确保用户业务全程无感知，我们必须妥善应对升级过程中涉及的多项复杂变动。这些变动包罗：将资源调理器由公平调理器（Fair Scheduler）切换为容量调理器（Capacity Scheduler），全面升级 ResourceManager 与 NodeManager 的 YARN 焦点组件，以及同步更新全部盘算引擎所依靠的 Hadoop 客户端版本等关键任务。
为确保上述高风险操纵在万台规模的生产集群中安全、可控地落地，我们开展了多轮覆盖功能、性能、容灾及回滚本事的严酷测试验证，并在此根本上订定了如下清晰、分阶段的升级流程：
该流程按照 ResourceManager → NodeManager → 盘算引擎 → History Server 的序次依次推进，最大限度低落组件间的兼容性风险，保障服务一连性。
那么，毕竟是哪些关键测试与验证工作，支持了云云大规模集群的有序、稳固升级？接下来，我们将深入分析本次升级过程中碰到的焦点技能难点，并具体先容我们针对性计划的办理方案与实践履历。
3.1 调理器平滑切换
在低版本的YARN服务中我们是使用公平调理作为集群的资源分配调理器，为了能在升级后用上高版本的特性nodelabel资源隔离本事，我们盼望在升级期间就完成调理器的切换，使用社区主流的容量调理器。在官方文档中并没有美满的更换操纵文档，两个调理器间存在的一些差别会影响当前用户的使用，且原公平调理器的分配性能在我们内部是颠末深度优化，为能在升级过程中无缝切换，我们团队做了大量的兼容适配和性能优化工作。
3.1.1 兼容与适配
1. 支持使用全路径队列名
在当前的在离线任务中，用户广泛通过全路径队列名（如 root.prod.etl）显式指定运行队列。然而，在升级至 YARN3.1 并启用容量调理器后，这一用法不再被支持——YARN 要求任务提交时仅使用叶子队列的简短名称（如 etl），且全部叶子队列在整个队列树中必须全局唯一，不允许重名。这一变动对现有业务影响巨大：大量汗青任务因队列定名辩说或路径格式不兼容而无法正常提交，若不办理，将严峻拦阻调理器的切换与升级。
为应对这一寻衅，我们深入调研了更高版本的 YARN 社区希望，发现 YARN-9879（于 3.3 版本合入）恰恰提供了对全路径队列名的支持，并放宽了叶子队列名称必须全局唯一的限定，从而能从根本上兼容现有任务的提交方式。然而，该功能所依靠的代码基线与我们当前使用的 YARN3.1 版本存在较大差别，无法直接移植。
为此，我们以 YARN-9879 的终极实现为目标，体系梳理其依靠的代码演进路径，逐个回迁并适配了中心共 35 个干系 PR，涵盖调理器剖析逻辑、队列校验机制及设置加载流程等关键模块。通过这一系列精致化的代码整合与充实测试，我们乐成在 YARN3.1 环境中实现了对全路径队列名的兼容支持，同时排除了叶子队列名称必须全局唯一的硬性束缚，为业务平滑迁移至容量调理器扫清了关键停滞。
2. 支持操持模式
为更高效地使用集群资源，我们此前借助 Cloudera Manager 提供的队列操持模式功能，按小时动态调解各队列的保障资源（minimum capacity）与共享资源（maximum capacity），确保各业务在高峰期可以大概得到富足的资源配额，从而稳固、高效地完成任务产出。
在 YARN 升级后，为在容量调理器上生存这一关键本事，我们在自研的内部运维管理工具中复现了雷同的队列动态调解功能。升级完成后，只需将原有的队列操持设置从 Cloudera Manager 迁移至新管理平台，即可无缝一连原有的资源调理计谋，无需业务侧举行任何改造。这不但保障了资源调理计谋的一连性，也显着低落了升级过程对业务运行的影响。
3. 自界说队列限定场景
在公平调理器（Fair Scheduler）中，支持通过设置 队列级最大运行应用数（max running apps per queue）来限定并发任务数量。当队列中正在运行的应用数到达阈值时，后续提交的任务将进入等候状态，从而确保已运行的任务可以大概一连得到资源、顺遂完成，制止因过分并发导致资源争抢和团体性能恶化。然而，在 YARN3.1 版本的容量调理器中，这一关键本事尚未实现。为保障业务调理活动的同等性与稳固性，我们主动合入了社区补丁 YARN-9930，在容量调理器中新增了对队列级最大运行应用数的限定支持，有用复现了公平调理器的列队控制机制。
别的，容量调理器通过 user-limit-factor 参数控制单个用户可使用的资源上限。比方，当该参数设为 1 时，单个用户最多只能使用即是队列保障容量的资源。但在我们的线上环境中，存在大量弹性调理场景——即队列的共享资源（maximum capacity）远高于其保障资源（如保障 10%，共享可达 80%）。在默认设置下，user-limit-factor 无法充实使用这部门弹性资源，限定了高优先级用户的突发资源需求。为此，我们合入了 YARN-10531，默认环境下关闭队列内用户资源使用的限定，从而更好地支持弹性调理场景。
与此同时，容量调理器还通过 maximum-am-resource-percent 参数限定队列内全部 ApplicationMaster（AM）所能使用的资源总量。原生逻辑仅基于队列的保障容量盘算 AM 资源上限，在高弹性场景下容易导致 AM 无法申请到充足资源而任务启动失败。针对此标题，我们对内部 AM 资源盘算逻辑举行了改造，使其在评估 AM 最大可用资源时，可以大概依据队列的最大共享容量举举措态调解。这一优化显着提升了任务拉起的乐成率，尤其在资源告急或弹性扩缩容场景下效果显着。
通过上述三项关键改进”运行应用数限定、用户弹性资源扩展、AM 资源上限优化“，我们不但补齐了容量调理器在生产环境中的本事短板，更使其在复杂、高并发、弹性化的大规模集群中显现出更强的调理机动性与资源使用服从。
3.1.2 性能优化
除了全面办理调理器的兼容性标题外，为支持万台规模集群的高效调理，我们团队还在容量调理器的性能优化方面开展了大量深入实践。在具体先容我们的优化步伐之前，有须要先扼要阐明容量调理器的焦点运行机制，其团体调理框架如下图所示：
在容量调理器中，每一次 Container 的分配均由 NodeManager 的心跳上报触发。ResourceManager 吸取到 NodeManager 的心跳信息后，会将该节点的资源可用状态转达给调理器，由调理器实行具体的容器分配逻辑。
调理过程依照“逐级择优、公中分配”的原则：
- 起首，从根队列开始，调理器会按层级遍历队列树，在每一层中根据各子队列的当前资源使用比例（已用资源 / 设置容量）举行排序；
- 然后，选择使用比例最低的子队列，并递归进入下一层，直至定位到一个叶子队列；
- 末了，在该叶子队列内部，调理器会对全部活泼应用（Applications）按其已分配资源总量举行排序，优先为资源使用量最少的应用分配容器，以实现队列内应用间的公平调理。
这一机制虽能保障多租户环境下的资源公平性，但在大规模集群（如上万台节点、数万个并发任务）场景下，频仍的队列遍历与排序操纵会带来显着的 CPU 开销和调理延长。正因云云，我们围绕调理路径、数据结构和盘算逻辑等关键环节，实验了一系列针对性优化，有用提升了调理吞吐与相应服从。
1. 排序缓存
在容量调理器的根天职配流程中，每次容器分配都须要对队列及其内部的应用举行排序。以典范的三级队列结构为例，若体系需在1 分钟内完成 50 万次容器分配实验，而每次排序耗时约 0.01 毫秒（实际耗时受队列数量和应用并发数影响），仅排序操纵就将累计斲丧约 15 秒 CPU 时间。这一开销在高并发、大规模集群场景下会显着拖累团体调理性能，成为性能瓶颈。
为缓解这一标题，我们引入了队列与应用排序效果的缓存机制，在包管调理公平性的条件下，大幅低落重复排序带来的盘算开销。其焦点思绪是：在肯定时间窗口内复用已排序的效果，制止每次分配都重新盘算。
具体实现如下：
通过两个新增设置参数控制缓存有用期：
- yarn.resourcemanager.capacity.child-queue-cache-refresh-interval-ms：控制子队列排序效果的缓存时间；
- yarn.resourcemanager.capacity.child-app-cache-refresh-interval-ms：控制叶子队列内应用排序效果的缓存时间。
在每次容器分配前，调理器会查抄对应缓存的前次更新时间是否已超时：
- 若未超时，则直接使用缓存中的排序效果；
- 若已超时，则重新实行排序逻辑，并更新缓存。
通过该机制，可有用限定单元时间内的排序调用频次。仍以每分钟 50 万次分配为例，若将缓存有用期设为 10 毫秒，则每分钟最多仅需实行约 6,000 次应用排序 + 12,000 次队列排序 = 总计约 1.8 万次排序操纵，相比原始方案的 50 万次排序，镌汰高出 96%。
排序次数的大幅降落显着低落了 ResourceManager 的 CPU 负载，提升了调理吞吐本事与相应速率，为万台规模集群的高效资源调理提供了关键性能保障。该优化在真实生产环境中验证有用，已成为我们调理器高性能运行的焦点支持之一。
2. 制止无效分配
在为 Application分配资源的过程中，某些环境下调理器会实行“无效分配”——即触发了分配逻辑，但终极无法乐因素配任何 Container。这类操纵不但浪费调理 CPU 资源，还会低落团体集群调理服从。基于线上大规模集群的运行实践，我们总结出两类重要的无效分配场景：任务自身无资源需求 和 队列资源限定导致分配失败。
（1） 任务无资源需求导致的无效分配
在包罗大量小任务的队列中，此类标题尤为突出。容量调理器在分配前会对叶子队列中的全部 App 按已分配资源量举行公平排序，优先选择资源使用最少的任务。小任务通常能快速获取其所需全部资源，但若未能立即完成（如等候外部依靠或处于空闲状态），在后续调理轮次中仍会因其“低资源使用量”而被优先选中。然而，此时该任务已无新的资源哀求，导致调理器实行了一次“空分配”——即无效分配。
优化方案：
我们在排序前增长资源需求过滤逻辑，仅将当前仍有 pending 资源哀求的 App 纳入排序范围，并将过滤后的效果缓存。通过此方式，彻底制止了对无需求任务的无效调理实验，显着提升了分配服从。
（2）队列资源限定引发的无效分配
此类标题更为复杂，重要源于两个层面：
① 主导资源盘算器（DominantResource-
Calculator, DRC）的比力逻辑缺陷
YARN 使用 DRC 举行多维资源（内存 + vCores）比力。比方，比力资源 与 时，DRC 会根据各资源在集群总容量中的占比确定“主导资源”。若 CPU 占比更高，则以 vCores 为主导维度，从而判定前者“更大”。
然而，在队列最大资源限定校验中，若直接使用 DRC.greaterThanOrEqual(available, request) 判定是否满意分配条件，大概得出“可用资源 ≥ 哀求资源”的错误结论。实际分配时，因另一维度（如内存）不敷，仍会失败，造成无效分配。
社区已在 YARN-11083 和 YARN-10903 中指出该标题。我们的办理方案是：弃用 DRC 的巨细比力方法，转而采取更精确的资源匹配判定：
- 使用 Resources.fitsIn(request, available) 判定哀求是否完全可被满意；
- 或使用 Resources.componentwiseMin 举行逐维度最小值盘算，确保各资源维度均不超限。
该修复已覆盖容量调理器中全部干系校验点，从根本上规避了因 DRC 比力弊端导致的无效分配。
② 多级队列嵌套下的父队列资源耗尽
在典范的多级队列架构中，多个叶子队列共享父队列的弹性资源池。纵然某个叶子队列自身未达最大容量限定，其父队列大概已因其他子队列的高负载而耗尽全部共享资源。此时，调理器在叶子队列层级校验通过，但在实际向父队列申请资源时失败，再次引发无效分配。
优化方案：
我们在资源分配前引入递归式父队列资源校验机制。即在确认叶子队列满意条件后，继续向上遍历其全部父队列，逐级验证是否有充足可用资源容纳本次分配。只有当从叶子到根路径上的每一级队列均满意资源要求时，才真正实行分配。这一机制有用杜绝了因父队列资源不敷导致的分配回滚，大幅镌汰无效调理开销。
（3）指标替换日志 输出
在容量调理器的分配逻辑实现中，为便于调试和追踪每次资源分配的细节，原始代码嵌入了大量细粒度日志（log）。然而在大规模集群的压力测试中，这些日志灵敏袒暴露严峻的性能标题：每几分钟就会天生一个高达 200MB 的日志文件，不但占用大量磁盘 I/O 和存储空间，更因频仍的日志写入显着拖慢了调理器的处置处罚速率，直接影响容器分配性能。
而在实际生产环境中，我们通常并不须要关注每一次分配的具体细节（比方某个任务本次申请了多少内存或 CPU），而是更聚焦于关键性能指标，如：
- 队列与 Application 的排序耗时；
- 单次容器分配实验的处置处罚时延；
- NodeManager 心跳上报到完成调理相应的端到端耗时等。
基于这一观察，我们对日志体系举行了深度优化，一方面，大幅精简并屏蔽了非须要的调试级日志，仅生存非常路径和关键决定点的须要信息； 另一方面，体系性地引入了多项精致化性能指标（Metrics），通过 YARN 的 Metrics 体系及时收罗调理焦点流程的耗时与吞吐数据，并接入监控 诉警平台。
3.2 服务端升级过程中的业务一连性保障
在升级过程中，ResourceManager、NodeManager 以及各类盘算引擎会不可制止地处于 Hadoop2 与 Hadoop3 共存的肴杂状态。这种异构环境对组件间的兼容性、通讯协议及资源调理逻辑提出了严厉寻衅。怎样精准和谐各脚色在差别阶段的状态切换，确保服务一连、任务不停止、数据不丢失，是实现团体平滑升级的关键。接下来，我们将具体先容在整个升级方案推进过程中，各阶段所面对的焦点标题及其应对计谋，涵盖组件依靠辩说、调理器切换、客户端兼容性等多个维度，全面还原这场大规模集群平滑演进的技能实践。
3.2.1 ResourceManager无缝升降级
为实现 ResourceManager 在 Hadoop2 与 Hadoop3 版本之间的无缝切换，我们不但须要确保服务能按操持顺遂完成升级，还必须具备在出现非常时快速、安全回退至原版本的本事，同时保障运行中的任务不受影响。为此，我们订定了一套体系性的保障方案。除了深度优化容量调理器自身的兼容性与性能外，一个关键条件是：新调理器的队列活动必须与原有公平调理器完全对齐。这包罗队列的权限控制、资源分配计谋、用户或应用级别的资源限定等焦点属性。任何弊端都大概导致任务列队非常、资源争抢以致作业失败。
为办理这一困难，我们团队自主研发了一款公平调理器到容量调理器的设置主动转换工具。该工具可以大概剖析现有的 fair-scheduler.xml 设置文件，智能映射其队列结构、权重与资源容量的对应关系，并主动天生符合容量调理器语义的 capacity-scheduler.xml 设置。它精准处置处罚了两类调理器在以下方面的差别：
- 队列层级与定名规范；
- 权重到容量的数学转换；
- 用户限定、AM 资源占比、最大并发应用数等计谋参数的等效表达。
3.2.2 Nodemanager安稳升降级
NodeManager 从低版本直接升级至高版本时，服务可正常运行；然而，在实验从高版本回退至低版本时，却会触发非常：
该标题的根源在于：高版本 NodeManager 在长期化 Container 状态信息时引入了多个新字段（比方 YARN-3998 中新增的容器重启关键元数据），而低版本代码缺乏对这些字段的剖析本事。当低版本 NodeManager 在启动规复（recovery）阶段读取由高版本写入的状态文件时，因无法辨认新增字段而抛出剖析非常，导致容器规复失败，进而影响任务续跑。
针对此类向前兼容性标题，社区提出了两种典范办理方案：
- 在低版本中增补高版本新增的状态字段界说，使其具备剖析本事；
- 在高版本中引入状态字段的开关控制机制，在升级窗口期内禁用新字段写入，待全集群完成升级后再启用。
经梳理高版本相较低版本共新增了 15 个状态字段，涵盖 Container 生命周期管理、安全 Token 机制、AMRMProxy 上下文等多个焦点模块。无论采取上述哪种方案，均需举行大规模代码修改与回归测试，实验本钱较高。思量到以下关键毕竟：
- 正向升级过程本身无兼容性标题；
- 非常仅在回退场景下由低版本无法剖析高版本字段触发；
- 低版本写入的状态信息在高版本中完全兼容（即高版本具备向下兼容本事）。
我们终极采取了更轻量、高效的第三种计谋：在低版本 NodeManager 的状态规复逻辑中加强非常容错机制。
具体而言，当反序列化过程中碰到无法辨认的字段时，体系会主动捕获并安全忽略该非常，跳过未知字段，继续完成别的状态的加载。这一改进确保了纵然状态文件包罗高版本特有字段，低版本 NodeManager 仍能顺遂完成 recovery 流程，保障容器正通例复，从而实现安全、可控的版本回退本事，同时制止了大规模代码侵入和维护负担。
3.2.3 其他标题
在完成 ResourceManager 与 NodeManager 的平滑升降级改造后，我们发现：正在运行的任务在服务升级过程中仍大概因服务端版本变动而失败。具体表现为，任务在升级窗口期内因 Token 序列化格式不兼容而抛出非常，典范日志如下：
经深入分析，该标题的根源在于：高版本 YARN（如 3.1+）集成了 YARN-668、YARN-2615 和 YARN-8310 等特性，将 Token 的序列化方式由 Java 原生字节省全面迁移至 Protobuf 格式。当高版本 ResourceManager 下发 Protobuf 编码的 Token 给尚未升级的低版本 NodeManager 时，后者因仅支持旧版字节省反序列化逻辑，无法剖析新格式，从而导致容器启动失败。针对这一跨版本兼容性标题，我们评估了两种主流方案：
方案一：调解升级序次
先完成全部 NodeManager 的升级，再切换 ResourceManager 版本。但其存在以下风险点：
- 将 ResourceManager 升级这一高风险操纵（涉及调理器切换、性能验证、回滚复杂度）后置，一旦失败，回退本钱极高；
- 在“高版本 NM + 低版本 RM”共存阶段，大概存在未被充实验证的交互兼容性标题，需额外投入大量测试资源。
方案二：序列化方式降级
修改 ResourceManager 代码，欺压其在升级期间继续使用低版本的 Java 字节省序列化 Token。其本质上是临时回退干系社区补丁，会导致部门关键字段（如容器范例 containerType ）丢失。在启用 YARN Federation 等高级特性时，AppMaster 因缺失容器上下文信息，大概做堕落误的资源分配决定，影响任务精确性。
终极方案：动态序列化开关机制
综合衡量稳固性、功能完备性与实验本钱，我们采取了一种改进型方案二：在 ResourceManager 中新增一个序列化方式控制开关支持在运行时动态切换 Token 序列化格式。团体实验流程如下：
- 升级初期：关闭开关，欺压 ResourceManager 使用低版本字节省格式下发 Token，确保与存量低版本 NodeManager 兼容；
- NodeManager 全量升级完成后：开启开关，切换至高版本 Protobuf 格式，启用完备新特性。
该方案兼具安全性与前瞻性：
- ✅ 保障升级期间任务一连性，制止因序列化不兼容导致作业停止；
- ✅ 无需改变升级序次，低落团体和谐复杂度与回退风险；
- ✅ 生存高版本全部功能本事，制止因降级造成容器元数据缺失；
- ✅ 通过设置开关实现平滑过渡，未来亦可用于灰度验证或告急回切。
3.3 引擎侧的平滑升级流程
3.3.1 盘算引擎兼容服务升级
盘算引擎与YARN服务的版本兼容性是确保集群稳固运行的关键环节。接下来将从同一Hadoop依靠、提交节点设置规范、同一Hive客户端版本三个维度，深入分析盘算引擎兼容YARN服务升级的技能方案与实践履历。
起首，同一Hadoop版本依靠是制止运行时兼容性标题的根本。在多版本共存或依靠杂乱的环境中，差别任务大概加载差别版本的 Hadoop客户端库，极易引发 ClassNotFound、NoSuchMethodError 等非常。为此，我们通过显式设置 yarn.application.classpath、mapreduce.
application.framework.path 和 mapreduce
.application.classpath 等参数，欺压全部提交到 YARN 的任务 Container 使用同一的 Hadoop3 依靠路径。这些路径指向集群预置的、颠末严酷测试的 Hadoop3 客户端包，确保无论任务从哪个节点提交，其运行环境中的 Hadoop 焦点类（如 FileSystem、Configuration、RPC 等）均来自同一版本。这种“依靠固化”计谋有用杜绝了因客户端版本不同等导致的任务失败或活动弊端。
其次，克制盘算任务依靠服务端（NodeManager 所在节点）的本地 Hadoop 设置，转而同一使用规范的提交节点设置。这一标题在 Spark2 等早期版本中尤为突出：当未显式指定 classpath 时，Spark 会回退到 DEFAULT_YARN_APPLICATION
_CLASSPATH，该默认值通常包罗 $HADOOP_CONF_DIR，即 NodeManager 本地的设置目次。若某些盘算节点的 hdfs-site.xml 中设置了 dfs.replication=1（比方用于测试或特别存储计谋），那么在该节点上启动的 Container 写入 HDFS 的数据副本数将被设为 1。一旦存储该数据块的 DataNode 发生故障，数据将永世丢失，造成严峻业务风险。通过欺压全部任务从提交端继续设置（如低版本 spark 通过设置雷同 spark.hadoop.{mapreduce|yarn}.application.classpath=./spark_conf/hadoop_conf 参数欺压 Container 加载从提交节点上传的设置文件到classpath），并屏蔽 NM 节点本地设置的影响，我们实现了设置的“提交端同等性”，从根本上规避了因节点设置差别引发的数据可靠性隐患。
末了，我们同一了全部盘算引擎所依靠的 Hive 客户端版本。由于当前平台上的盘算引擎（包罗 Spark SQL、Presto、Hive 等）若继续使用原有的 Hive1.1 版本并加载 Hadoop3 依靠，在启动时会触发如下校验非常：- Caused by: java.lang.IllegalArgumentException: Unrecognized Hadoop major version number: 3.1.1.3.1.0.0-78
- at org.apache.hadoop.hive.shims.ShimLoader.getMajorVersion(ShimLoader.java:169)
- at org.apache.hadoop.hive.shims.ShimLoader.loadShims(ShimLoader.java:134)
- at org.apache.hadoop.hive.shims.ShimLoader.getHadoopShims(ShimLoader.java:95)
- at org.apache.hadoop.hive.ql.io.CombineHiveInputFormat$CombineHiveInputSplit.<init>(CombineHiveInputFormat.java:143)
综上所述，本次 YARN 服务升级通过依靠同一化、设置中心化、同一底层hive客户端依靠三大步伐，体系性办理了盘算引擎与 Hadoop3 的集成困难。这不但为整个升级过程奠基告终实根本，同时解耦了盘算引擎与hadoop版本依靠关系，在生存原有的盘算引擎下将服务端升级到预期版本。
3.3.2 任务安稳切换使用hadoop3依靠
在乐成办理了盘算引擎与 Hadoop 3 的集成困难之后，怎样安稳地将全部任务过渡到使用 Hadoop 3 依靠成为了一个新的寻衅。只管上述步伐可以大概办理标准化 SQL 类任务的兼容性标题，但对于 JAR 范例的任务来说，由于用户大概在其业务包中引入了不兼容的 Hadoop 版本或其他第三方 JAR 包，仍然大概会出现兼容性标题。由于这些业务包对我们而言是一个完全的“黑盒”，而且须要处置处罚的任务数量巨大，在有限的时间内无法逐一分析和测试验证。因此，我们基于调理平台（以下简称 BDSP）计划了一套同一的 JAR 范例任务灰度切换 Hadoop 依靠的流程。
整个灰度流程重要分为三个步调：
第一步：标签标记
在迁移开始前我们会为集群中的全部 Shell 和 JAR 范例任务打上一个 hadoop2 标签。带有此标签的任务在实行 spark-submit 前会主动参加一个环境变量 VIVO_HADOOP_VERSION。当该变量的值为 2 时，Spark 启动入口会选择 Hadoop2 的依靠和设置来运利用命；同理，当该变量的值为 3 时，则选择 Hadoop3 的依靠和设置。如许做的目标是为了确保在迁移过程中，任务可以根据实际需求机动选择符合的 Hadoop 版本举行运行。
第二步：任务灰度
在这个阶段，我们将分批次剔除任务的 hadoop2 标签。此时，BDSP 不会添加 VIVO_HADOOP
_VERSION 变量，因此 Spark 默认会选择 Hadoop3 的依靠和设置来运利用命。假如任务在运行期间发生失败，BDSP 会重新为该任务加上 hadoop2 标签，使其在后续重试阶段可以大概在 Hadoop2 环境下继续运行，从而制止因半夜任务失败而无人处置处罚的环境。
第三步：兼容整改
针对灰度过程中失败的任务，我们会进入兼容整改阶段。业务侧对这些标题举行整改后，可以再次进入第二步继续举行灰度。在这个过程中，我们团队帮忙业务办理了不少兼容性标题，并将一些共性标题直策应用到盘算引擎侧，以防止其他业务碰到雷同标题，从而镌汰团体的兼容性标题发生率。
通过这一系列经心计划的灰度切换流程，我们不但实现了从 Hadoop2 到 Hadoop3 的平滑过渡，还显着提升了任务的稳固性和数据安全性。同时，通过对共性标题的总结和优化，进一步镌汰了未来大概出现的兼容性风险，为大数据平台的一连演进奠基告终实的根本。
四、总结及预测
此次 Hadoop YARN 大版本升级，是一次从兼容性攻坚到架构重塑的深度实践。它不但办理了汗青技能债，更打开了通向高弹性、低本钱、强管理的新一代大数据平台的大门。未来随着 Federation、GPU 调理、资源隔离等本事的深入应用，我们有望构建一个真正“按需供给、智能调理、全域协同”的数据根本办法，为业务创新提供更结实、更灵敏的底座。末了感谢各人的阅读，同时也欢迎各人一起在多云融合架构、冷热存储一体架构及资源精致调理等话题深入互换，共同探索未来更高效、更智能的数据根本办法。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于 
