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團隊對入職報表的依賴處理后期維度:保持我們的數據模型的一致性，處理從湖到倉庫的后期維度鍵