1.摘要

在Halodoc，我们始终致力于为最终用户简化医疗保健服务。随着公司的发展，我们不断地构建和提供新的功能。我们两年前建立的东西可能无法支持我们今天管理的数据量，为了解决这个问题，我们决定改进数据平台架构。在我们之前的博客中，我们谈到了现有平台的挑战，以及为什么我们需要采用Lake House架构来支持企业和利益相关者轻松访问数据。在这篇博客中，我们将讨论我们的新架构、涉及的组件以及拥有可扩展数据平台的不同策略。

2.新结构

我们先来看看改进后的新数据平台2.0的高级架构。

我们的架构分为4层：

1.数据接收/提取层

这一层更关心的是获取原始区域层中的数据，这些数据可以在以后的处理区域中使用和卸载。大多数点击流捕获工具都支持其产品的内部数据捕获服务，因此可以轻松获取或添加原始区域以进行进一步处理。对于MySQL和Postgres等事务性数据源，我们开始使用基于CDC的方法提取数据。由于我们的基础架构主要托管在AWS中，我们选择了数据迁移服务(DMS)来执行基于CDC的迁移。

2.处理层

我们在这里没有执行任何繁重的转换，而是将原始数据转换为胡迪数据集。源以不同的格式(CSV、JSON)被摄取，这些格式需要被转换成列格式(例如parquet)来存储在数据湖中，以便进行高效的数据处理。数据类型根据数据湖兼容性进行转换，时区调整为WIB时间戳。

3.转换楼层

数据工程的挑战之一是有效处理大量数据，并保持成本不变。我们选择Apache Spark进行处理，因为它支持分布式数据处理，并且可以轻松地从千兆字节扩展到千兆字节的数据处理。转换层在数据仓库中生成数据模型，并成为报表使用数据和支持仪表板或报表用例的基础。

4.报告层

报表层主要聚合来自维度和事实表的数据，并为下游用户提供这些数据库的视图。大多数仪表板将建立在这些报告表和物化视图上，因此减少了为重复任务和报告用例连接不同表的计算成本。一旦我们将平台实现到不同的层，下一个挑战就是选择能够支持我们大多数下游用例的组件。当我们调查市场上的数据工程工具/产品时，我们可以很容易地找到大量的工具。我们计划使用AWS云和开源项目来构建内部解决方案，而不是购买第三方许可工具。

下面我们来深入了解一下以上平台中使用的组件。

涉及的组件：

1.管理系统

DMS代表数据迁移服务。这是一个AWS服务，可以帮助在MySQL、Postgres和其他数据库上执行CDC(变更数据捕获)。我们使用DMS从MySQL数据库中读取二进制日志，并将原始数据存储在S3中。在Flask server和boto3实现的帮助下，我们已经创建了自动化的DMS资源。我们可以轻松地向控制表中配置的原始区域参数添加一个新表。

2.S3-原始区域

DMS捕获的所有CDC数据都存储在S3相应分区的原始区域中。该层不执行数据清理。每当源系统中发生插入或更新时，数据将被附加到新文件中。原始区域对于在需要时执行数据集的任何回填非常重要。它还存储从点击流工具或任何其他数据源获取的数据。原始区域用作处理该区域使用的数据的基本层。

3.EMR -胡迪派斯帕克

Apache胡迪用于对位于数据湖中的数据进行UPSERT操作。我们正在运行PySpark作业，它以预定的时间间隔运行，从原始区域读取数据，处理并存储在已处理区域中。区域复制源系统的行为已处理。只有一个UPSERT操作，它被转换成胡迪数据集。

4.S3-治疗区

S3处理层是Halodoc的数据湖。我们存储可变和不可变的数据集。胡迪用于维护可变数据集。诸如CSV或JSON数据之类的不可变数据集也被转换成parquet并存储在这个区域中。这一层还维护或纠正分区，以有效地查询数据集。

5.粘附数据目录

AWS Glue数据目录用于注册表，Athena可以查询该目录进行临时分析。

6.雅典娜(智慧与技艺的女神)

Athena是一个无服务器的查询引擎，支持S3的数据查询。使用Athena对位于数据湖中的数据集进行任何临时分析。

7.红移

红移被用作数据仓库来建立数据模型。所有报告/BI使用案例都由Redshift提供服务。我们在红移中创建了2层。第一层负责存储PD、CD、预约、保险、实验室的所有数据模型，包含事实和维度。我们

已经构建了一个报告层框架来进行聚合和连接，以创建可通过 BI 工具访问的报告表。我们还在这些层中维护物化视图。我们还在我们的数据模型中实现了 SCD type1 和 SCD type2，以捕捉数据集中的历史变化。

8. MWAA

MWAA 用于编排工作流程。

9. Cloud Watch和EFK

Cloud Watch 和 EFK 相结合，构建集中的日志记录、监控和警报系统。

10. Dynamicdb

平台中使用 Dynamodb 将失败的事件存储在控制表中发布。开发了一个再处理框架来处理失败的事件并按预定的频率将它们推送到控制表。

3. 为什么选择基于 CDC 的方法?

在 Halodoc，当我们开始数据工程之旅时，我们采用了基于时间戳的数据迁移。我们依靠修改后的时间戳将数据从源迁移到目标。我们几乎用这个管道服务了 2 年。随着业务的增长，我们的数据集呈指数级增长，这要求我们将迁移实例增加到更大的集群以支持大量数据。

问题如下：

• 由于源处生成的大量数据导致迁移集群大小增加，因此成本高。

• 由于某些后端问题，未更新已修改列时的数据质量问题。

• 架构更改很难在目标中处理。

• 在基于 CDC 的情况下，我们通过在 MySQL 中启用 binlog(二进制日志)和在 Postgres 中启用 WAL(预写日志)来开始读取事务数据。提取每个事件更改的新文件是一项昂贵的操作，因为会有很多 S3 Put 操作。为了平衡成本，我们将 DMS 二进制日志设置为每 60 秒读取和拉取一次。每 1 分钟，通过 DMS 插入新文件。基于 CDC 还解决了数据量大增长的问题，因为我们开始以最大分钟间隔迁移，而不是每小时间隔数据。

4. 使用Apache Hudi

HUDI 提供内置功能来支持开放数据湖。在我们的平台中加入或集成 HUDI 时，我们面临以下一些挑战并试图解决它们。

保留 HUDI 数据集中的最大提交

HUDI 根据配置集清理/删除较旧的提交文件。默认情况下，它已将保留的提交设置为 10。必须根据一个工作负载正确设置这些提交。由于我们在 5 分钟内运行了大部分事务表迁移，因此我们将 hoodie.cleaner.commits.retained 设置为 15，以便我们有 75 分钟的时间来完成 ETL 作业。甚至压缩和集群添加到提交，因此必须分析和设置更清洁的策略，以使增量查询不间断地运行。

确定要分区的表

在数据湖中对数据进行分区总是可以减少扫描的数据量并提高查询性能。同样，在湖中拥有大分区会降低读取查询性能，因为它必须合并多个文件来进行数据处理。我们选择我们的数据湖来进行最小的每日分区，并计划将历史数据归档到其他存储层，如 Glacier 或低成本的 S3 存储层。

选择正确的存储类型

HUDI 目前支持 2 种类型的存储，即。MoR(读取时合并)和 CoW(写入时复制)。必须根据用例和工作负载精确选择存储类型。我们为具有较低数据延迟访问的表选择了 MoR，为可能具有超过 2 小时数据延迟的表选择了 CoW。

MoR 数据集的不同视图

MoR 支持 _ro 和 _rt 视图。_ro 代表读取优化视图，_rt 代表实时视图。根据用例，必须确定要查询哪个表。我们为 ETL 工作负载选择了 _ro 视图，因为数据模型中的数据延迟约为 1 小时。建立在数据湖之上的报告正在查询 _rt 表以获取数据集的最新视图。

HUDI 中的索引

索引在 HUDI 中对于维护 UPSERT 操作和读取查询性能非常有用。有全局索引和非全局索引。我们使用默认的bloom索引并为索引选择了一个静态列，即非全局索引。我们依靠 HUDI 提交时间来获取增量数据。这也有助于将迟到的数据处理到要处理的数据湖，而无需任何人工干预。

5. 为什么框架驱动

我们之前的大部分实施都是管道驱动的，这意味着我们为每个数据源手动构建管道以服务于业务用例。在 Platform 2.0 中，我们对实现模型进行了细微的更改，并采用了框架驱动的管道。我们开始在每一层上构建一个框架，例如数据摄取框架、数据处理框架和报告框架。每个框架都专用于使用预定义的输入执行某些任务。采用框架驱动减少了冗余代码，以维护和简化数据湖中新表的载入过程。

使用表格格式的控制平面的好处

在我们的平台中，控制平面是一个关键组件，用于存储元数据并帮助轻松载入数据湖和数据仓库中的新表。它存储启用数据迁移所需的必要配置。对于构建任何产品，元数据在自动化和控制管道流程方面起着至关重要的作用。在 Yaml、DynamoDB 或 RDBMS 中，我们有不同的选项可供选择。我们选择 RDS 的原因如下：

• 轻松在元数据之上执行任何分析，例如活动管道的数量。

• 易于载入新表或数据模型。

• 借助 python flask API 轻松构建 API 层。

• 审计可以很容易地完成。

• 数据安全

在医疗保健领域，安全一直是我们数据平台中启用的重中之重。我们在私有子网中托管了几乎所有基础设施，并启用 Lake Formation 来管理对 Data Lake 的访问。我们还对静态数据使用 AWS 加密。这提供了数据湖和整体数据平台的安全存储。

自动化

自动化总是有助于减少构建和维护平台的工程工作量。在 Platform 2.0 中，我们的大部分流水线都使用 Jenkins 和 API 实现自动化。我们通过部署烧瓶服务器并使用 boto3 创建资源来自动创建 DMS 资源。

我们几乎所有的基础设施/资源都是通过 Terraform 创建的。SRE 在建立我们的大部分数据平台基础设施方面发挥了重要作用。

记录、监控和警报

尽管我们的基础设施是健壮的、容错的和高度可扩展的，但有时会出现可能导致基础设施停机的意外错误。为了识别和解决这些问题，我们使用 Cloud watch 和 EFK(Elasticsearch、Fluentbit 和 Kibana)堆栈对我们数据平台中涉及的每个组件启用了监控和警报。

工作流程编排

任何数据平台都需要调度能力来运行批处理数据管道。由于我们已经在之前的平台中使用 Airflow 进行工作流编排，因此我们继续使用相同的编排工具。MWAA 已经在减少维护工作量和节省成本方面发挥了很大作用。我们在之前的博客中解释了我们在 MWAA 中评估的内容。

6. 概括

在这篇博客中，我们查看了 Lake House 架构、构建平台 2.0 所涉及的所有组件，以及我们将 HUDI 用作数据湖的关键要点。由于我们现在已经构建了 Data Platform 2.0 的基础部分，接下来我们计划专注于平台的以下方面：

• 数据质量 -> 维护整个数据存储的数据检查和数据一致性。

• 数据血缘 -> 提供数据转换的端到端步骤。

• BI 团队的自助服务平台 -> 减少对 DE 团队对入职报告表的依赖。

• 处理迟到的维度：保持我们的数据模型的一致性，并处理从湖到仓库的迟到的维度键。