Halodoc的数据平台转型之Lakehouse架构

在Halodoc，我们始终致力于为最终用户简化医疗保健服务伴随着公司的发展，我们不断地构建和提供新的功能我们两年前建立的东西可能无法支持我们今天管理的数据量，为了解决这个问题，我们决定改进数据平台架构在本文中，我们将讨论我们的新架构，涉及的组件以及拥有可扩展数据平台的不同策略

一.新结构

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

我们的架构分为4层:

1.数据接收/提取层

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

2.处理层

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

3.转换楼层

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

4.报告层

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

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

涉及的组件:

管理系统

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

S3—原始区域

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

EMR —胡迪+ PySpark

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

S3—治疗区

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

粘附数据目录

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

雅典娜

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

红移

红移被用作数据仓库来建立数据模型所有报告/BI使用案例都由Redshift提供服务我们在红移中创建了2层第一层负责存储PD，CD，预约，保险，实验室的所有数据模型，包含事实和维度我们构建了一个报告层框架，用于聚合和连接，以创建可以通过BI工具访问的报告表我们还在这些层中维护物化视图我们还在我们的数据模型中实现了SCD type1和SCD type2，以捕获数据集中的历史变化

MWAA

MWAA用来安排工作流程。

云观察和EFK

云观察EFK相结合，建立一个集中的日志记录，监测和警报系统。

动态数据库

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

第二，为什么选择以疾控中心为主的方式。

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

这些问题如下:

由于源端产生大量数据，迁移集群的规模增大，因此成本较高由于一些后端问题，修改过的列不更新时会出现数据质量问题模式更改在目标中很难处理基于CDC，我们通过启用MySQL中的binlog和Postgres中的WAL开始读取事务数据提取每个事件更改的新文件是一项开销很大的操作，因为会有许多S3 Put操作为了平衡成本，我们将DMS二进制日志设置为每60秒读取和提取一次每一分钟，通过DMS插入新文件基于CDC，我们还解决了大量数据增长的问题，因为我们开始以最大的分钟间隔而不是以小时间隔进行迁移

胡迪提供内置特性来支持开放数据湖当我们在我们的平台中加入或整合胡迪时，我们面临以下一些挑战，并试图解决它们

1.在胡迪数据集中保持最大提交。

2.确定要分区的表。

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

3.选择正确的储物类型。

胡迪目前支持两种类型的存储，即和morcow必须根据使用情形和工作负载准确选择存储类型我们为具有低数据延迟访问的表选择MoR，为数据延迟超过2小时的表选择CoW

4.MOR数据集的不同视图

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

5.胡迪指数

索引胡迪对于维护UPSERT操作和读取查询性能非常有用有全局索引和非全局索引我们使用默认的bloom索引，并为索引选择一个静态列，即非全局索引我们依靠胡迪提交时间来获取增量数据这也有助于在没有任何人工干预的情况下将后期数据处理到待处理的数据湖

5.为什么框架是驱动的。

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

1.使用表格控制平面的好处

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

轻松地对元数据执行任何分析，例如活动管道的数量易于加载新表或数据模型使用python flask API轻松构建API层审计很容易完成

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

2.自动化

自动化总是有助于减少构建和维护平台的工程工作量在Platform 2.0中，我们的大多数管道都是由Jenkins和API实现自动化的我们通过部署flask服务器并使用boto3创建资源来自动创建DMS资源

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

3.记录，监控和报警

尽管我们的基础架构强健，容错且高度可扩展，但有时会出现意外错误，导致基础架构停机为了识别和解决这些问题，我们使用云监控和EFK堆栈来监控和警报我们数据平台中涉及的每个组件

4.工作流程安排

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

动词 一般化

在本文中，我们研究了湖屋架构，构建platform 2.0所涉及的所有组件，以及我们将胡迪用作数据湖的要点。由于我们现在已经构建了数据平台2.0的基础部分，接下来我们计划重点关注平台的以下方面:

质量—gt，维护整个数据仓库的数据检查和数据一致性数据血缘—gt，为数据转换提供端到端的步骤BI的自助服务平台——gt，减少DE团队对入职报表的依赖处理后期维度:保持我们的数据模型的一致性，处理从湖到仓库的后期维度键