复盘领英Hadoop数据丢失事故，我们得到的血泪教训
复盘在 LinkedIn 发生的数据丢失事件，我们认识到：对企业而言，失败往往比成功更具有启发性。其次，如果团队行动太快，又无法以完全透明的方式处理问题，那么失败所带来的影响有可能长期困扰团队。
我们发生了数据丢失的严重事件：
在部分机架中，约有 2% 的设备因意外操作失误而经历了镜像重装。
而问题的根源在于，我们的 Hadoop 基础设施主机生命周期管理体系存在设计错误。更糟糕的是，这一切发生在 LinkedIn 的关键业务生产集群上。（天啊！）
与大多数大数据系统一样，我们的架构也设有内置安全网，能够在突破阈值之前持续对系统加以保护。在 LinkedIn，我们拥有两套大规模 Hadoop 集群，其中存储着大量数据。在每套集群内，所有数据块都拥有 3 份副本，借此实现机架层级的故障冗余支持。每套集群中的两条摄取管道拥有完全独立的路径，可并行实现对数据库数据的摄取跟踪。
下面来看整套架构的高层示意图：
我们的灾难恢复策略主要关注在集群内发生数据丢失时，如何从集群当中复制数据。
下面我们将具体比较这种安全理论，在发生重大事件的真实场景之下，它与实践会存在哪些冲突。
1、小的数据损坏引发严重后果
在此次事件中，相较于机架层面的实际设备离线率，丢失的数据比例相对并不高（只有约 0.02%）。但要命的是，这会导致数据块（HDFS）永久丢失，因为对应的三套副本恰好同时位于受到影响的机架之上。
如果单看理论，即便丢失了受影响机架中的所有计算机，数据丢失量仍能维持在极低水平（约 0.15%）。而且由于受影响机架并未出现所有计算机离线的问题，所以实际丢失的数据块比例应该很低（约 0.03%）——真正情况是，丢失的数据块仅占全部数据总量中的约 0.02%，比预期还要低些。我们还假设当设备离线的短暂间隔之内，Hadoop NameNode 应该会主动复制部分数据块以缓解总体影响。所以总体而言，受此次问题影响的所有文件占比应该只在 0.05% 上下。
在 LinkedIn，绝大多数预定工作流（基于 Spark 的应用程序）都通过 Azkaban 触发。而即使是少量文件损坏，也会导致大量 Azkaban 工作流遭遇失败。本次损坏的文件归属于热数据集，即由众多工作流共同使用的高访问频率数据集。另外，当 Azkaban 流尝试读取包含大量文件的大规模数据集时，即使单一文件损坏也会导致本次读取失败。将这些因素综合起来，真正的结果就是虽然只有 0.02% 的数据丢失，但却有高达 10% 的工作流发生故障（其中相当一部分与业务收入直接相关）。
总而言之，技术集成虽然能够帮助我们较大程度降低数据块丢失比例，但与之对应，即使是极少量的数据损坏也会给生产体系造成重大影响。
2、设计挑战
如前所述，我们的架构设计要求在不同的数据中心内部署两套 Hadoop 集群，其分别拥有自己的并行数据摄取管道。换言之，我们可以将数据从一套集群恢复至另一集群。
在首次进行事件响应时，我们以为可以轻松跨越两套集群恢复并行生成的所有数据，因此响应工作的主要难点，应该只体现在处理 Azkaban 工作流生成的中间数据发生损坏的情形上。
问题在于，除非明确要求，否则这些中间数据不会跨集群复制。出于多种外部因素的考量（包括资本支出、变更频率、易于还原以及恢复时间目标等），在默认情况下，某一集群中 Azkaban 工作流生成的中间数据不会被尽数复制至另一集群处。正是这样的设定，让我们在此次事故中遭遇到一系列出乎意料的挑战。
首先，我们发现需要恢复的数据副本量要比预期当中多得多。这是因为各个 Hadoop 集群之间完全彼此独立，因此数据的组织方式也将有所区别。我们在摄取新数据时使用的是基于时间的数据布局。因此，由于固有的不确定性，特定文件夹中的文件在不同集群之间可能有所差异。
另外，我们将较旧的数据压缩至同一个按单日进行分区的大文件当中，希望借此提高查询效率与系统性能。这些细微差异带来的最终影响是，我们很难确定未受影响的集群中丢失了哪些文件。实际上，只要单日分区中的文件发生少量损坏，我们就必须复制当天之内的完整分区。具体来看，复制单一文件大概需要移动 1 GB 数据，而复制当天完整分区则需要移动约 1 TB 数据。需要处理的数据量因此显著增加，这就极大影响了恢复工作的执行速度。
为了解决这个问题，我们使用到以下技术：
在 LinkedIn，我们拥有 QoS（服务质量）控制机制，用于为网络上特定类型的数据设置优先级，借此管理整个网络资源。其中成员流量的优先级要高于 HDFS 数据。为帮助推进恢复工作，我们临时调整了网络主干路径以提供两倍的传输带宽，从而显著加快了数据恢复速度。
我们以数据驱动方式执行恢复工作。根据给定分区中丢失数据的百分比、数据新鲜度以及已丢失数据的使用层级组合，我们对数据集的恢复优先级进行了排序。
我们与工作流的所有方进行了协调，共同就删除损坏数据商议出执行结果。这方面的挑战在于，Azkaban 流可以根据预定义的时间表重新触发，而且某些流所有方明确提出不可使用某些特定数据（例如带有损坏文件的数据）运行其工作流；也有部分流所有方对延迟非常敏感，强烈希望能够重新启动计算设施。最后，如果多条流在使用同一段损坏的数据，则必须在各工作流所有方之间建立起一项全局管理策略。
当我们将网络带宽增加 2 倍以加快跨集群数据复制时，网络路由层中出现的配置错误给整体系统造成了巨大压力，进而引发并发故障。很明显，盲目加速对系统的大规模恢复确实会带来压力，而且相应风险有可能高于在不超出系统极限的前提下逐步恢复系统所带来的业务影响风险。虽然我们一直很清楚这种风险的存在，但在实际面对之前仍然对其认识不足。
团队发布了一系列用于实现流量恢复的选项。根据业务影响与对应成本，应用程序所有方负责确定各自流程的弹性程度。我们的一部分最关键业务指标计算流会以主动 / 主动高可用性模式在两套集群上运行。在此次中断事件的冲击下，这些与 SLA 直接相关的重要计算流程并没有受到任何影响，可喜可贺！但问题是，这样的设计会带来极高的运营成本。对于预先存在但未经明确定义的弹性策略工作流，我们主要采取三种实现选项：使用部分数据保证工作流运行，等待完整数据恢复（可能需要几天时间）后重新启动工作流，或者在未受故障影响的灾难恢复集群中运行工作流。对于某些由 Azkaban 工作流建立起的主动 / 主动模式下，最后一种选项效果较好，但其在具体实施中的限制也着实不少。
考虑到 LinkedIn 所使用 Hadoop 集群的庞大规模，我们必须与各工作流所有方（我们的客户）合作，以实时方式制定应对策略。某些对延迟非常敏感的工作流所有方选择立即处理部分数据，而另一些所有方则选择等待数据完全恢复。
3、为快速恢复目标寻求新的组织形式
疫情影响下的远程办公新常态，导致我们无法像往常那样在办公室里面对面交流。为此，我们连夜按照美国与印度时区组织起虚拟团队。从组织形式上看，各团队分别采取以下模式：
辐射式模式，即在中心指导之下建立更多辐射式业务轨道。每条跟踪路线都结合自身实际建立起对应的恢复成功标准。
针对特定轨道形成组内消息传递体系，减少中央团队承受的沟通压力。在持续数天的恢复过程当中，这种新形式为随时出现的即席查询留出灵活空间。
同样的，这也让特定客户组建立起其他消息传递通道，借此提高透明度与协调能力。
明确交流节奏，并在轨道通路之间以及各小组之内建立定期接触点，保证归属于不同部门的成员仍然处于同一条战线。
Grid 网格团队负责将所有轨道联系起来，并定期发布关于当前恢复状态的邮件通讯结果，同时保留详细的恢复日志。
总体而言，此次恢复主要分为两项主体计划：数据恢复，与工作流恢复。其中数据恢复由 Grid 网格团队负责处理，而工作流恢复则拥有专门的轨道通路，各轨道负责人立足所在业务部门确定较佳工作流方法。而后，各方选择最具可行性的方法，并跟踪恢复进度以广泛协作。Grid 网格团队以各业务部门的全局优先级为基础建立起一套分阶段的恢复方法，借此保证我们的复杂系统始终保持平衡，且不致在数据恢复与工作注恢复两项高强度工作的压力之下而发生崩溃。在此期间，Grid 团队逐步增加计算容量，以适应恢复过程中随时出现的过量资源需求。
4、学习常态化
回顾整次事件，我们总结出以下教训，未来也将据此认真完善自身运营体系：
应该为 Hadoop 基础设施建立健壮且更为全面的主机生命周期管理机制。
应更深入地了解工作负载之下跨数据中心的网络行为，确保采用自动化方式按需修改网络路由。
我们目前正在构建包括 Hadoop 栈在内的下一代 Azure 基础设施。从中期来看，我们将打造出一套以全新技术栈支撑而成的额外集群，由此进一步提升业务体系的冗余规模。
研究其他架构方案，将此作为我们 Auzre 迁移计划中的重要参考。例如，我们可以一次性摄取数据，并将这些数据复制至灾难恢复集群当中，而后通过数据布局与查询规划优化以降低延迟成本。目前我们正在引入 Apache Iceberg 作为表格式。使用 Iceberg，我们应该能够提升受影响文件的恢复效果。在架构过渡过程中，我们还开发出多款工具，帮助我们完成恢复工作（例如恢复除损坏数据之外的全部数据，以及更轻松地通过另一集群对当前集群中的大文件进行恢复等）。这些工具将被纳入未来更加完善的运行手册当中。
努力审查我们的现有工作流，保证其具有定义明确的灾难恢复协议。
增加灾难演习频率，同时根据记分卡中规定的恢复策略审查各工作流在演练中的实际表现。
继续研究血统分析工具链，事实证明这类方案对于识别工作流及数据依赖关系非常有用。我们还将借此实现端到端的生态系统连接图理解能力，这将为我们应对未来可能出现的重大安全事件时提供宝贵的协调能力。
一部分工作流所有方在其应用程序工作流之内表现出良好的弹性水平。例如，对延迟较为敏感的应用程序会按小时及按天生成多项关键指标，在应用程序逻辑之内建立起明确的数据陈旧性与弹性权衡方案。
我们应专注于提高自身对于数据可用性恢复 SLA 的能力，保证再次发生此类事件时能够快速提供准确可靠的恢复能力结论。我们的内部数据使用者可以通过此类 SLA 以及恢复协议中的条款，做出更加清晰而明智的恢复决策。
参考阅读：
https://engineering.linkedin.com/blog/2020/learnings-from-a-recent-hadoop-incident
声明：文章收集于网络，版权归原作者所有，为传播信息而发，如有侵权，请联系小编删除，谢谢！
欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流
QQ群：26931708
Hadoop源代码研究群
兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop
QQ群：288410967
