印尼醫療龍頭企業Halodoc的數據平台轉型之Lakehouse架構

• 2022 年 5 月 22 日
• 筆記

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