本文最初发布于 LinkedIn 博客，由 InfoQ 中文站翻译并分享。
简介
去年年底，我们将 LinkedIn 的数据分析技术栈（包括 1400 多个数据集、900 多个数据流和 2100 多个用户）迁移到了基于开源大数据技术的技术栈，本文将概要地介绍一下这个过程。
此举使我们摆脱了第三方专有（3PP）平台的限制，节省了数百万的许可、技术支持和其他运营费用。此外，此举使我们能够自由地扩展和增强我们的组件和平台，从而使我们可以更好地掌握自己的命运。同样重要的是，我们利用这个机会重新规划了数据湖/仓库战略。
虽然大规模的技术迁移通常非常复杂，而且难免延期，但我们的工具和方法允许提前执行，对生产环境未产生任何负面影响。我们还以此为契机，为开发人员和用户改进了整个分析生态。
在这篇博文中，我们将介绍：
如何驾驭和执行一次大规模的数据和用户迁移。
如何以技术迁移为契机改进数据生态。
迁移经验。
旧有的数据分析技术栈
在 LinkedIn 的早期阶段，我们利用几个 3PP 数据平台来支撑业务的快速增长。虽然后来遇到了一些限制，但在当时，将现成的产品拼凑在一起以满足需求要快得多。我们使用 ETL 将数据抽取到数据仓库，然后以此为基础构建报表和分析（如图 1 所示），这在当时是一个标准模式。
图 1：LinkedIn 旧有的数据分析技术栈
虽然这个技术栈在六年中为我们提供了良好的服务，但它有以下缺点。
无法自由演进：由于这个系统的封闭性，我们在创新方面选择有限。此外，与内部和开源系统的集成也是一个挑战。
难以扩展：由于 Informatica/Appworx 许可限制，数据管道的开发被限制在一个小型的中央团队里。这日益成为 LinkedIn 快速发展的瓶颈。这些缺点促使我们在 Hadoop 上新开发了一个并行的数据湖。然而，我们没有一个明确的迁移过程，其结果是同时维护着新旧两个数据仓库。数据在两个技术栈之间复制，导致了双倍的维护成本和复杂性，也让消费者非常困惑（图 2）。
图 2：维护冗余的数据仓库导致了不必要的复杂性
最终，我们制定计划将所有数据集迁移到了新的技术栈上。
根据数据集谱系和使用情况制定迁移计划
早期，我们就意识到，如果不首先探清数据集谱系和使用情况，就很难规划大规模的迁移工作。这些知识将使我们能够：
规划数据集迁移的顺序，即从没有依赖关系的数据集开始，然后再迁移依赖它们的数据集。
识别零使用率或低使用率的数据集以减少工作量。
跟踪新旧系统的用户占比，这是一个关键指标（KPI）。尽管数据集谱系很有价值，但没有现成的产品/解决方案来支持我们这个涉及 3PP、Teradata（TD）和 Hadoop 的异构环境。尽管有一个正在进行中的项目，试图将数据集谱系构建为DataHub的一部分，但这是一个涵盖所有数据集的艰巨任务，而不仅仅是数仓中的数据集，所以无法在本项目要求的时间内完成。因此，我们接受了在前期构建必要工具的挑战，以帮助我们规划和执行迁移工作。
首先，我们创建了一个数据产品，以提供 TD 数据集的上/下游依赖关系。其次，我们创建了数据管道来提取数据集的使用信息。为了获得 TD 元数据以支持这些工作，我们别无选择，只能勉强使用 TD 日志，因为这个闭源系统没有提供任何其他的方式。然而，我们有一个更优雅的解决方案来获得 Hadoop 元数据。我们给 MapReduce 和 Trino 添加了工具，可以发送带有详细数据集访问元数据的 Kafka 事件。然后，这些事件被一个Gobblin作业摄取到 HDFS 中，并用 Hive 脚本进行处理，用于下游消费和仪表盘。整个过程如下图所示（图 3）。
图 3：数据使用情况提取的数据管道
比较有意思的是，上面的数据管道开始是一个实习生项目，最后成为迁移的基石。在 LinkedIn，我们努力为实习生提供真实世界的、有影响力的项目，这就是一个很好的例子，说明我们的实习生可以产生巨大的影响。
利用这些工具，我们对数据集进行了广泛的编目，以帮助我们进行规划。这些目录帮助我们规划了主要的数据模型修订，提供了一个整体的视图，帮助我们找出多余的数据集，并且符合事实/维表。结果，我们将 1424 个数据集并成了 450 个，减少了 70%的迁移工作量。
此外，以前我们的数据模型严重受上游 OLTP 资源的影响，这些数据模型是高度规范化的，为行级事务而设计。然而，我们复杂的业务分析需要将这些模型转化为普通但开销大的表连接。为此，我们对表进行了去规范化和预连接，以简化我们的分析工作（图 4）。
图 4：对表做预连接和去规范化以简化分析
总之，数据集谱系对于迁移来说非常重要，但可能没有现成的。迁移是一个构建簿记工具的好机会，有许多迁移工作之外的好处。
迁移到新的数据生态系统
规划完成后，就可以开始将所有数据集转移到新的生态系统了。在很大程度上，这个新生态系统的设计深受从 TD 迁出的影响，因为它解决了旧有 TD 技术栈的痛点。
数据民主化：Hadoop 生态系统使 LinkedIn 的其他团队能够进行数据开发和采用。相比之下，以前由于许可证的限制，只有一个中心团队可以建立 TD 数据管道。
通过开源项目实现技术开发的民主化：我们现在可以通过开源或自己构建的项目自由地增强技术栈的各个方面。这使我们能够开发许多创新技术来大规模地处理数据（例如，Coral、Data Sentinel和Magnet）。
统一技术栈：同时运行 TD 和 Hadoop 增加了系统维护的成本和复杂性。在新系统中，我们统一了数据管道中使用的技术和工作流（图 5）。这使我们的维护和增强工作都集中在一个地方，大大提升了效率。除了我们的用例外，LinkedIn 的许多其他应用也在向 Hadoop 汇聚（例如，机器学习、预警和实验），这使我们能够综合利用他们所做的一些基础工作。
图 5：LinkedIn 新建的业务分析技术栈
该技术栈包含以下组件：
统一的度量管道（UMP）：一个统一的平台，开发人员可以提供 ETL 脚本创建数据管道。
Azkaban：一个分布式的工作流调度器，负责管理 Hadoop（包括 UMP）上的作业。
数据集读取器：数据集位于 HDFS 上，可以通过多种方式读取。
面向业务分析的仪表板和即时查询；
DALI（LinkedIn 的数据访问层）：一个供开发人员使用的 API，开发人员无需关心存储介质、路径和格式。我们还借着此次迁移重新评估和改善了数据管道的性能。首先，我们必须解决 Avro 文件格式糟糕的读取性能，该文件格式来自上游组件。因此，我们迁移到了 ORC，读取速度提高了约 10 到 1000 倍，同时压缩率提高了约 25 到 50%。其次，我们从性能较差的 Hive/Pig 流迁移到 Spark，使运行时间减少了约 80%。最后，我们调整了我们的工作，以确保适当的资源使用率和性能。
通过在可以完全控制的技术栈上构建平台，我们赋予了自己作为工程师的权力，并确立了我们自己的创新文化。
用户迁移和数据集废弃自动化
在完成数据集的迁移后，我们还需要协调 2100 多个 TD 用户的迁移和 1400 多个 TD 数据集的废弃。这个过程要是手动完成，会特别啰嗦特别费时，容易出现人为错误，并且人力成本非常高。将这个过程自动化可以避免这些问题，但需要我们创建一个本身比较复杂的服务。
我们采用了一条中间路线，借助自动化来协调任务。我们的解决方案的高级架构图如下（图 6）。后端由一个 MySQL 操作数据存储组成，其中的数据来自我们的数据集谱系解决方案。我们构建了一个后端 API 服务来协调废弃工作。该服务会识别候选废弃项，即没有依赖且使用率低的 TD 数据集。随后，该服务向数据集用户发送了关于数据集即将废弃的电子邮件，并通知 SRE 锁定、归档，并在宽限期后从 TD 删除数据集。
图 6：用户迁移和数据集废弃工具的系统架构图
这样一来，这个过程就不那么乏味了，更容易管理了，而且据我们估计，成本只是人工处理的一小部分。需要特别指出的是，要尽可能抓住机会，通过自动化来节省时间、精力和成本。
总结
根据我们的经验，技术迁移是一项艰巨的工作，创新方法是有好处的。下面是我们的经验总结，希望可以为面临类似情况的其他组织提供借鉴。
首先，在技术迁移期间寻找机会改善数据生态。 除了迁移到 Hadoop，我们还利用这个机会大幅更新了我们的数据模型，并改进了数据管道的性能和工作流。要了解具体案例的详细信息，可以阅读这篇博文。
其次，从传统的 3PP 数据库迁移时要警惕性能和功能差异。 为了与 TD 的性能相匹配，我们在 Hadoop 上做了大量的工作（例如 ORC 转换和Spark shuffle优化）。此外，我们不得不实现或放弃在 TD 中我们认为理所当然的功能（例如基于行的访问控制）。为了技术迁移顺利进行，我们建议尽早查明差异。
最后，尽可能利用以及构建自动化解决方案。 在我们的案例中，我们构建了解决方案来推导数据集谱系和使用情况，与下游用户沟通，并废弃数据集。尽管需要前期投资，但最终结果更有成本效益，更不容易出错。此外，这些解决方案在迁移后仍能协助我们进行数据管理，使其成为一项良好的长期投资。
将来，我们期待着 LinkedIn 更大的技术转型；例如，我们正在将整个技术栈迁移到微软Azure，这是我们迄今为止最大最具雄心的迁移。因此，我们将继续以我们的经验为基础，享受不断发展的技术环境所带来的挑战。
查看英文原文：
InfoQ高级技术编辑
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论