在这篇博客中，我们将讨论我们的新架构、涉及的组件和不同的策略，以拥有一个可扩展的数据平台。
新架构
1. 数据摄取/提取层
2. 处理层
3. 转换层
4. 报告层
一旦我们将平台实现为不同的层，下一个挑战就是选择能够支持我们大多数下游用例的组件。当我们调研市场上的数据工程工具/产品时，我们可以轻松找到大量工具。我们计划利用 AWS 云和开源项目构建内部解决方案，而不是购买第三方许可工具。
涉及的组件：
1. 管理系统
2. S3 - 原始区域
这还存储从点击流工具或任何其他数据源摄取的数据。原始区域充当处理区域使用数据的基础层。
3. EMR - HUDI + PySpark
4. S3 - 处理区
5. Glue数据目录
6. Athena
7. Redshift
8. MWAA
9. Cloud Watch和EFK
10. Dynamicdb
为什么选择基于 CDC 的方法
在 Halodoc，当我们开始数据工程之旅时，我们采用了基于时间戳的数据迁移。我们依靠修改后的时间戳将数据从源迁移到目标。我们几乎用这个管道服务了 2 年。随着业务的增长，我们的数据集呈指数级增长，这要求我们将迁移实例增加到更大的集群以支持大量数据。
由于源处生成的大量数据导致迁移集群大小增加，因此成本高。
由于某些后端问题，未更新已修改列时的数据质量问题。
架构更改很难在目标中处理。
在基于 CDC 的情况下，我们通过在 MySQL 中启用 binlog（二进制日志）和在 Postgres 中启用 WAL（预写日志）来开始读取事务数据。提取每个事件更改的新文件是一项昂贵的操作，因为会有很多 S3 Put 操作。为了平衡成本，我们将 DMS 二进制日志设置为每 60 秒读取和拉取一次。每 1 分钟，通过 DMS 插入新文件。基于 CDC 还解决了数据量大增长的问题，因为我们开始以最大分钟间隔迁移，而不是每小时间隔数据。
使用Apache Hudi
HUDI 提供内置功能来支持开放数据湖。在我们的平台中加入或集成 HUDI 时，我们面临以下一些挑战并试图解决它们。
保留 HUDI 数据集中的最大提交
确定要分区的表
选择正确的存储类型
MoR 数据集的不同视图
建立在数据湖之上的报告正在查询 _rt 表以获取数据集的最新视图。
HUDI 中的索引
为什么框架驱动
我们之前的大部分实施都是管道驱动的，这意味着我们为每个数据源手动构建管道以服务于业务用例。在 Platform 2.0 中，我们对实现模型进行了细微的更改，并采用了框架驱动的管道。我们开始在每一层上构建一个框架，例如数据摄取框架、数据处理框架和报告框架。每个框架都专用于使用预定义的输入执行某些任务。采用框架驱动减少了冗余代码，以维护和简化数据湖中新表的载入过程。
使用表格格式的控制平面的好处
我们选择 RDS 的原因如下：
轻松在元数据之上执行任何分析，例如活动管道的数量。
易于载入新表或数据模型。
借助 python flask API 轻松构建 API 层。
审计可以很容易地完成。
数据安全
自动化
自动化总是有助于减少构建和维护平台的工程工作量。 在 Platform 2.0 中，我们的大部分流水线都使用 Jenkins 和 API 实现自动化。
我们通过部署烧瓶服务器并使用 boto3 创建资源来自动创建 DMS 资源。
记录、监控和警报
尽管我们的基础设施是健壮的、容错的和高度可扩展的，但有时会出现可能导致基础设施停机的意外错误。为了识别和解决这些问题，我们使用 Cloud watch 和 EFK（Elasticsearch、Fluentbit 和 Kibana）堆栈对我们数据平台中涉及的每个组件启用了监控和警报。
工作流程编排
概括
在这篇博客中，我们查看了 Lake House 架构、构建平台 2.0 所涉及的所有组件，以及我们将 HUDI 用作数据湖的关键要点。由于我们现在已经构建了 Data Platform 2.0 的基础部分，接下来我们计划专注于平台的以下方面：
数据质量 -> 维护整个数据存储的数据检查和数据一致性。
数据血缘 -> 提供数据转换的端到端步骤。
BI 团队的自助服务平台 -> 减少对 DE 团队对入职报告表的依赖。
处理迟到的维度：保持我们的数据模型的一致性，并处理从湖到仓库的迟到的维度键。