印尼医疗龙头企业Halodoc的数据平台转型之数据平台V2.0

1. 摘要

数据平台已经彻底改变了公司存储、分析和使用数据的方式——但为了更有效地使用它们，它们需要可靠、高性能和透明。数据在制定业务决策和评估产品或 Halodoc 功能的性能方面发挥着重要作用。作为印度尼西亚最大的在线医疗保健公司的数据工程师，我们面临的主要挑战之一是在整个组织内实现数据民主化。 Halodoc 的数据工程 (DE) 团队自成立以来一直使用现有的工具和服务来维护和处理大量且多样的数据，但随着业务的增长，我们的数据量也呈指数级增长，需要更多的处理资源。

由于现代数据平台从不同的、多样化的系统中收集数据，很容易出现重复记录、错过更新等数据收集问题。为了解决这些问题，我们对数据平台进行了重新评估，并意识到架构债务随着时间的推移积累会导致大多数数据问题。我们数据平台的所有主要功能——提取、转换和存储都存在问题，导致整个数据平台存在质量问题。

我们现有的数据平台在过去几年中为我们提供了很好的服务，但它的扩展性满足不了不断增长的业务需求。

2. 平台演进

在旧的数据平台中，大部分数据都是定期从各种数据源迁移到 Redshift。 将数据加载到 Redshift 后，执行 ELT 以构建服务于各种业务用例的 DWH 或数据集市表。

数据平台能够满足我们的大部分需求，但随着数据用例的增加，我们看到业务和数据量增长，为满足业务需求数据平台面临多重挑战。

问题如下：

• 存储和计算紧密耦合。我们主要依赖基于 ELT 的方法，其中 Redshift 计算层被大量用于任何数据转换。我们的 Redshift 集群包含多个 dc2.large 实例，其存储和计算紧密耦合，扩容时存储与计算一起扩容导致成本增加。
• 数据高延迟。当前管道中的数据延迟几乎超过 3-4 小时，因为数据首先在 Redshift 中加载，然后每隔几个时间间隔执行 ELT 操作。我们的业务和产品团队希望以更低的延迟分析数据，以便他们能够更快地做出关键业务决策。
• 缺乏数据治理。现有数据平台没有实施适当的数据治理。在 Redshift 中创建Group，并且根据用户的角色将用户分配到每个Group，该方法可以控制数据集访问，但缺乏列或行级别粒度的访问控制。
• 仪表板基于哪些数据集构建缺乏可见性。由于所有数据集市表都是根据用例创建，并且当用户向 DE 团队请求时，有多个表包含重复数据。由于我们没有遵循数据模型（星型或雪花模式），因此在 Redshift 中维护表之间的关系变得非常困难。
• 缺少 SCD 管理。SCD 代表缓慢变化维，当有人想知道数据点的历史价值时，SCD 非常重要。在当前的数据集市中，没有实施适当的 SCD，在我们的案例中，像药品价格、医生类别等都是要跟踪的重要特征。
• 通过 Airflow 内存移动数据。在 Halodoc，大部分数据流通过 Airflow 发生，所有批处理数据处理作业都安排在 Airflow 上，其中数据移动通过 Airflow 内存进行，这为处理不断增加的数据量带来了另一个瓶颈。由于 Airflow 不是分布式数据处理框架，因此更适合工作流管理。相当多的 ETL 作业是用 Python 编写的，以服务于间隔 15 分钟的微批处理管道，并在 Airflow 中调度。
• 缺少数据目录。数据目录对于任何数据平台提供数据的元信息都非常重要。直接迁移到 Redshift 的表在现有平台中缺少数据目录。仅为存储在 S3 中的数据创建数据目录，这让终端用户检索有关 Redshift 中表的信息成为问题。
• 没有集成的数据血缘。如果有人有兴趣了解目标数据表的来源和转换阶段，我们没有数据血缘来展示它们。数据血缘对于理解数据流、数据转换很重要，并且如果在目标处生成错误信息，则可以轻松调试数据。
• 缺少框架驱动的平台。对于每个用例，我们主要构建端到端的数据管道。大多数代码在多个数据管道中重复。数据工程任务中缺少软件工程原则。因此，很难将每一层上的组件解耦并创建一个抽象层来使整个框架端到端自动化。
• 没有自动模式演进。处理关系数据时模式演进非常重要。源系统中会发生变化，需要在目标系统中反映出来，而管道不会出现任何故障，当前我们手动执行此操作，我们已经建立了一个流程，DBA 将架构更改通知 DE，DE 负责在目标系统中进行更改。我们想要一种自动化的方式来执行这些操作。

由于数据平台的这些限制，我们意识到第一代数据平台已经走到了尽头。正是在这一点上，我们决定退后一步，想想我们需要从我们的数据平台中得到什么。如果必须的话我们并不害怕从头开始构建一个系统。

数据工程团队开始使用支持或减轻上述大部分限制的新数据平台来评估和改进现有架构。我们调研到了 LakeHouse 架构，它在通过具有成本效益的解决方案实现可扩展性以及处理大量数据方面发挥着至关重要的作用。因此我们开始围绕 LakeHouse 架构来构建我们改进后的 Data Platform 2.0。

3. 为什么我们采用 LakeHouse 架构？

LakeHouse 架构基本上是 Datalake 和数据仓库的组合，可以在其中无缝地跨湖和仓库移动数据，并遵循对所有数据集的访问权限的安全合规性。

在 Halodoc，我们希望构建一个可扩展的解决方案，我们可以根据需要独立扩展存储和计算。我们将以下内容列为我们希望数据基础设施具备的核心功能：

• 解耦存储和计算（高度可扩展）。
• 可以存储所有类型的数据，如结构化、半结构化和非结构化。
• 可以作为整个组织中数据的单一事实。
• 存储/查询可变和不可变数据的能力。
• 可与 Spark 或 Hive 等分布式处理引擎集成。

在新架构中，我们利用 S3 作为数据湖，因为它可以无限扩展存储。由于我们计划将可变数据也存储在 S3 中，因此下一个挑战是保持可变 S3 数据的更新。我们评估了几个框架，如 Iceberg、Delta Lake 和 Apache Hudi，它们提供了更新可变数据的能力。由于 Apache Hudi 与 EMR 集成度很好，因此我们开始在 Hudi 之上构建数据湖。

4. 为什么选择Apache Hudi

• 对文件执行 Upsert 操作。
• 使用各种更新捕获更新历史记录。
• 支持ACID。
• 支持不同的存储类型（CoW 和 MoR）
• 支持多种数据查询方式（实时优化查询、快照查询、增量查询）
• 数据集的时间旅行。
• 预装 EMR，开箱即用。

搭建平台的挑战

• 新架构中使用的大多数组件对团队来说都是新的，因此需要一些学习曲线来动手操作和生产系统。
• 构建中心化的日志记录、监控和警报系统。
• 在改进架构的同时支持常规业务用例。

5. 总结

在本博客中，我们介绍了现有数据平台中面临的一些挑战/限制，以及一些缺失的功能。 在接下来的博客中，我们将更多地讨论 LakeHouse 架构，以及我们如何使用 Apache Hudi 以及在发布新平台时面临的一些挑战。随着不断迭代，我们将继续在新平台中添加新功能，以打造更加强大和可靠的数据平台。