大家好，欢迎来到IT知识分享网。

• 技术之旅讨论了仓库模式化的动机、挑战和技术解决方案，特别是 Meta 数据平台中用于与仓库分析日志相关的数据交换的有线序列化格式的变化。
• 在这里，我们讨论了通过迁移到新的 Tulip 格式来 实现 Meta 的 EB 级数据平台现代化所面临的工程、扩展和非技术挑战。
• 数据的模式化对于这种规模的数据平台起着重要作用。它会影响数据流和开发每个阶段的性能、效率、可靠性和开发人员体验。

迁移很难。此外，由于以下原因，他们在 Meta 上变得更加困难：

• 技术债务：系统已经建立多年，具有不同程度的依赖性和与其他系统的深度集成。
• 非技术（软）方面：引导用户以最小的摩擦完成迁移过程是一门艺术，需要随着时间的推移磨练，并且对于每次迁移都是独一无二的。

我们为什么迁移到郁金香？

在进入迁移故事的细节之前，我们想退后一步并尝试解释此迁移的动机和理由。

随着时间的推移，随着公司需求的增长，数据平台已经演变成各种形式。早期的一个适度的数据平台已经发展成为一个艾字节级的平台。一些服务于较小规模的系统开始显示出不足以满足对它们增加的需求的迹象。最值得注意的是，我们遇到了一些与数据（反）序列化相关的具体可靠性和效率问题，这让我们重新思考我们记录数据的方式，并重新审视第一原则中的想法来解决这些紧迫的问题。

图 1：Meta 分析日志数据流的高级系统图。

记录器是数据平台的核心。该系统用于通过Scribe将分析和操作数据记录到Scuba、Hive和流处理管道。每个产品和数据平台团队都与日志交互。出于遗留原因，日志记录的数据格式是Hive Text Delimited或JSON 。我们之前关于 Tulip 的文章中描述了这些格式的局限性。

进入郁金香连载

为了解决这些限制，开发了Tulip 序列化格式以取代旧的特定于目标的序列化格式。

迁移结果——图表

下图以图形方式描绘了将序列化格式转换为 Tulip 的迁移过程，以显示各个阶段和里程碑的进展。

图表 1：使用 Legacy 与 Tulip 的日志模式。

图 2：通过 Legacy 与 Tulip 每秒记录的字节数。

我们可以看到，虽然日志模式的数量大致保持不变（或出现一些有机增长），但由于序列化格式的变化，记录的字节数显着减少。与格式特定字节节省相关的详细信息在下面的部分中列出。

注意：图 2 中的数字是根据观察到的最大（按量）五个日志记录模式的实际节省量推断的（总流量）。

迁移

概述

我们想将我们的迁移之旅分为两个不同的阶段，各有各的观点。

1. 规划、准备和实验阶段：此阶段的重点是构建技术解决方案，以帮助验证迁移并使其顺利高效地进行。在执行任何迁移之前构建了严格的验证自动化。必须先迁移数据消费者，然后才能迁移生产者。为关键团队执行了少量白手套迁移，这些迁移提供了有用的见解，可以了解下一阶段迁移的重要内容。
2. 扩展阶段：在这个阶段，团队根据早期小规模迁移的经验构建工具和功能。考虑非技术角度并优化高效的人际互动至关重要。

规划和准备迁移之旅

在设计系统时考虑到迁移有助于使迁移变得更加容易。开发了以下工程解决方案，以确保团队配备必要的工具和基础设施支持，以安全地切换有线格式并以可扩展的方式调试迁移阶段可能出现的问题。

解决方案大致分为以下几类：

1. 与 Wire 格式相关：此类解决方案的重点是确保在执行序列化格式的格式切换时将开销降至最低或零。这涉及设计有线格式以实现平稳过渡，并在必要时为各种系统配备格式转换器和适配器。混合模式有线格式数据消耗
2. 测试、调试和推出相关：此类解决方案涉及构建严格的测试框架、调试工具和推出旋钮，以确保可以主动发现问题，并且当在实时系统中发现问题时，团队有能力停止出血并尽快调试和/或根本原因。调试工具影子记录器速率限制和部分推出

混合模式有线格式

挑战：如何通过不要求数据生产者和消费者自动切换序列化格式来简化迁移并降低风险？

解决方案：当翻转单个日志模式以使用新的郁金香序列化协议写入有效载荷时，在单个抄写流上支持混合模式有效载荷是必要的，因为不可能“自动”切换所有数据生产者以使用新格式. 这也允许团队对新格式序列化的推出进行速率限制。

混合模式有线格式对于支持影子记录器的概念很重要，影子记录器在大规模推出之前广泛用于端到端验收测试。

混合模式有线格式的主要挑战是无法更改 Hive 文本或 JSON 格式的现有有效负载序列化。为了解决这个限制，每个 Tulip 序列化有效负载都以 2 字节序列 0x80 0x00 为前缀，这是一个无效的utf-8序列。

数据消耗

挑战：在某些系统中，Hive 文本（或 JSON）序列化格式渗透到应用程序代码中，最终依赖这种格式来使用有效负载。这是消费者突破序列化格式抽象的结果。

解决方案：两种解决方案解决了这一挑战。

1. 阅读器（数据反序列化的记录器对应物）
2. 消费者中的格式转换

阅读器（数据反序列化的记录器对应物）

图 2：用于使用混合模式数据的读取器。

Reader 是一个将序列化有效负载转换为结构化对象的库。阅读器（如记录器）有两种形式，(a) 代码生成和 (b) 通用。读取器对象使用三种格式（郁金香、Hive 文本或 JSON）中的任何一种格式的数据，并生成结构化对象。这允许团队在迁移开始之前将消费者切换为使用阅读器。必须更新应用程序代码以使用此结构化对象而不是原始序列化行。这将有线格式从数据消费者中抽象出来。

在消费者中转换为遗留格式

图 3：消费者中的旧版格式转换。

对于更新应用程序代码以使用结构化对象不可行或过于昂贵（从工程成本的角度来看）的用例，我们为使用系统配备了一个格式转换器，可以使用 Tulip 序列化有效负载并将其转换为 Hive 文本（或 JSON）序列化有效载荷。这在 CPU 利用率方面效率低下，但允许团队继续迁移大量用例。

调试工具

“调试的难度是编写代码的两倍。因此，如果你尽可能聪明地编写代码，那么根据定义，你还不够聪明，无法调试它。” — 布赖恩·W·克尼汉

图 4：CLI 调试工具 loggertail 的运行。

挑战：在日志模式中启用简单的可视化测试和验证数据迁移后。

解决方案：开发 loggertail CLI工具是为了允许在特定日志模式的 scribe 队列中验证迁移后的数据。Loggertail 使用通用的反序列化器。它查询命名日志模式的序列化模式，并使用它来解码输入消息。然后它会生成一个人类可读的（字段名称、字段值）对列表，并将数据打印为 JSON 对象。

影子记录器

“你是进包厢的还是出来的？我们轮流。诀窍在于我们要交换的地方。” ——《声望》

挑战：对通过新格式记录的数据进行端到端测试和验证。

解决方案：影子记录器模仿了原始的日志记录模式，只是它们将数据记录到记录器团队监控的表中。这构成了端到端的验收测试。

除了用户指定的列之外，影子日志记录架构还有两个附加列。

1. 序列化格式：蜂巢文本或郁金香。
2. 行 ID：这是行的唯一标识符，用于标识使用不同序列化格式序列化的两个相同行。

每次请求记录到原始日志记录模式时，影子记录器都会将一小部分行记录到影子表中。使用 spark 作业分析这些表中的行，并确保具有相同 ID 但序列化格式不同的行的内容相同。该验证在推出之前为团队提供了高度的信心。

图 5：影子日志记录的工作原理。

速率限制和部分推出

挑战：在将 Tulip 序列化部署到日志模式期间出现问题时，我们如何才能快速控制流血？

解决方案：即使已经通过影子记录器对每个正在迁移的日志模式进行了验证，我们也必须为迁移过程中无法预料的问题做好准备。我们建立了一个速率限制器来降低风险并使团队能够迅速止血。

扩展迁移

由于剩余 30,000 多个日志记录模式，迁移的扩展阶段侧重于执行迁移，它是自助服务和使用自动化。扩展阶段的另一个重要方面是确保工程师尽可能减少摩擦。

自动化工具

挑战：如何根据相应的 scribe 流的数据消费者选择要迁移的模式？

解决方案：每个日志模式都根据相应的 scribe 流的下游消费者进行了分类。只有那些拥有所有受支持的下游消费者的日志模式才被认为准备好使用郁金香格式。

使用这些数据，构建了一个工具，这样工程师只需要运行一个脚本，该脚本就会自动针对未迁移的日志模式进行转换。我们还构建了工具来检测目标日志记录模式的潜在数据丢失。

最终，这个工具由一个类似 cron 的调度系统每天运行。

非技术（软）方面

挑战：团队在迁移过程中必须处理许多非技术方面的问题。例如，激励最终用户实际迁移并为他们提供支持，以便他们可以安全、轻松地进行迁移。

解决方案：由于迁移的规模和复杂性因具体情况而异，因此我们首先通过任务为工程团队提供准备时间来规划迁移。我们提出了一个实时迁移指南以及一个演示视频，该视频迁移了一些记录器以向最终用户展示应该如何完成。与编写一次且从不（或很少）更新的迁移指南不同，我们决定让该指南保持有效并不断发展。支持小组和办公时间被设置为帮助用户，如果他们偶然发现任何阻止程序。这些特别有用，因为用户发布了他们的经历以及他们是如何解锁的，这有助于其他用户在遇到类似问题时推动事情发展。

结论

在整个数据平台上进行序列化格式转换等巨大的赌注在短期内具有挑战性，但它提供了长期利益并随着时间的推移而发展。

设计和构建解决方案，同时了解执行这种规模的迁移的技术和非技术方面对于成功非常重要。我们希望能够让您一窥我们在此过程中面临的挑战和使用的解决方案。

致谢

我们要感谢与记录器团队合作使该项目取得成功的数据平台团队成员。没有这些团队的跨职能支持和 Meta 用户（工程师）的支持，这个项目和后续的迁移是不可能的。

作者：Bharat Vaidhyanathan、Dhruv Matani、Md Mustafijur Ra​hman Faysal、Saurav Sen

出处:https://engineering.fb.com/2023/01/26/data-infrastructure/tulip-modernizing-metas-data-platform/