Halodoc的資料平臺轉型之Lakehouse架構

1. 摘要

在 Halodoc，我們始終致力於為終端使用者簡化醫療保健服務，隨著公司的發展，我們不斷構建和提供新功能。我們兩年前建立的可能無法支援我們今天管理的資料量，以解決我們決定改進資料平臺架構的問題。在我們之前的部落格中，我們談到了現有平臺的挑戰以及為什麼我們需要採用 Lake House 架構來支援業務和利益相關者以輕鬆訪問資料。在這篇部落格中，我們將討論我們的新架構、涉及的元件和不同的策略，以擁有一個可擴充套件的資料平臺。

2. 新架構

讓我們首先看一下經過改進的新資料平臺 2.0 的高階架構。

我們將架構分為 4 層：

1. 資料攝取/提取層

該層更關心在原始區域層中攝取資料，這些資料可以稍後在已處理區域中使用和解除安裝。大多數點選流捕獲工具都支援來自其產品的內部資料攝取服務，從而可以輕鬆獲取或加入原始區域以進行進一步處理。對於 MySQL、Postgres 等事務性資料來源，我們開始利用基於 CDC 的方法進行資料提取。由於我們的基礎設施主要託管在 AWS 中，因此我們選擇了資料遷移服務 (DMS) 來執行基於 CDC 的遷移。

2. 處理層

這裡我們沒有執行任何繁重的轉換，而是將原始資料轉換為 HUDI 資料集。源資料以不同的格式(CSV、JSON)攝取，需要將其轉換為列格式(例如parquet)，以將它們儲存在 Data Lake 中以進行高效的資料處理。資料型別基於資料湖相容性進行型別轉換，時區調整為 WIB 時間戳。

3. 轉換層

資料工程的一大挑戰是有效地處理大量資料並保持成本不變。我們選擇 Apache Spark 進行處理，因為它支援分散式資料處理，並且可以輕鬆地從千兆位元組擴充套件到 TB 級資料處理。轉換層在資料倉儲中生成資料模型，併成為報表使用資料並支援儀表板或報表用例的基礎。

4. 報告層

報告層主要從維度和事實表中聚合資料，並在這些資料庫之上提供檢視供下游使用者使用。大多數儀表板將建立在這些報告表和物化檢視之上，從而減少為重複性任務和報告用例連線不同表的計算成本。一旦我們將平臺實現為不同的層，下一個挑戰就是選擇能夠支援我們大多數下游用例的元件。當我們調研市場上的資料工程工具/產品時，我們可以輕鬆找到大量工具。我們計劃利用 AWS 雲和開源專案構建內部解決方案，而不是購買第三方許可工具。

讓我們更深入地瞭解上述平臺中使用的元件。

涉及的元件：

1. 管理系統

DMS 代表資料遷移服務。這是一項 AWS 服務，可幫助在 MySQL、Postgres 等資料庫上執行 CDC(更改資料捕獲)。我們利用 DMS 從 MySQL DB 讀取二進位制日誌並將原始資料儲存在 S3 中。我們已經自動化了在 Flask 伺服器和 boto3 實現的幫助下建立的 DMS 資源。我們可以輕鬆地在控制表中配置的原始區域引數中加入新表。

2. S3 - 原始區域

DMS 捕獲的所有 CDC 資料都儲存在 S3 中適當分割槽的原始區域中。該層不執行資料清洗。只要源系統中發生插入或更新，資料就會附加到新檔案中。原始區域對於在需要時執行資料集的任何回填非常重要。這還儲存從點選流工具或任何其他資料來源攝取的資料。原始區域充當處理區域使用資料的基礎層。

3. EMR - HUDI + PySpark

Apache HUDI 用於對位於 Data Lake 中的資料利用 UPSERT 操作。我們正在執行 PySpark 作業，這些作業按預定的時間間隔執行，從原始區域讀取資料，處理並儲存在已處理區域中。已處理區域複製源系統的行為。這裡只是發生了一個 UPSERT 操作並轉換為 HUDI 資料集。

4. S3 - 處理區

S3 處理層是 Halodoc 的資料湖。我們儲存可變和不可變資料集。HUDI 被用於維護可變資料集。CSV 或 JSON 資料等不可變資料集也被轉換為列格式(parquet)並儲存在該區域中。該層還維護或糾正分割槽以有效地查詢資料集。

5. Glue資料目錄

AWS Glue 資料目錄用於登錄檔，並可透過 Athena 進行查詢以進行臨時分析。

6. Athena

Athena 是一個無伺服器查詢引擎，支援查詢 S3 中的資料。使用者利用 Athena 對位於資料湖中的資料集進行任何臨時分析。

7. Redshift

Redshift 用作資料倉儲來構建資料模型。所有報告/BI 用例均由 Redshift 提供服務。我們在 Redshift 中建立了 2 個圖層。一層負責儲存包含事實和維度的 PD、CD、Appointments、Insurance 和 Labs 的所有資料模型。我們已經構建了一個報告層框架來進行聚合和連線，以建立可透過 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 團隊對入職報告表的依賴。

• 處理遲到的維度：保持我們的資料模型的一致性，並處理從湖到倉庫的遲到的維度鍵。