印尼醫療龍頭企業Halodoc的數據平台轉型之數據平台V2.0

• 2022 年 5 月 14 日
• 筆記

1. 摘要

數據平台已經徹底改變了公司存儲、分析和使用數據的方式——但為了更有效地使用它們，它們需要可靠、高性能和透明。數據在制定業務決策和評估產品或 Halodoc 功能的性能方面發揮著重要作用。作為印度尼西亞最大的在線醫療保健公司的數據工程師，我們面臨的主要挑戰之一是在整個組織內實現數據民主化。 Halodoc 的數據工程 (DE) 團隊自成立以來一直使用現有的工具和服務來維護和處理大量且多樣的數據，但隨著業務的增長，我們的數據量也呈指數級增長，需要更多的處理資源。
由於現代數據平台從不同的、多樣化的系統中收集數據，很容易出現重複記錄、錯過更新等數據收集問題。為了解決這些問題，我們對數據平台進行了重新評估，並意識到架構債務隨著時間的推移積累會導致大多數數據問題。我們數據平台的所有主要功能——提取、轉換和存儲都存在問題，導致整個數據平台存在品質問題。
我們現有的數據平台在過去幾年中為我們提供了很好的服務，但它的擴展性滿足不了不斷增長的業務需求。

2. 平台演進

在舊的數據平台中，大部分數據都是定期從各種數據源遷移到 Redshift。 將數據載入到 Redshift 後，執行 ELT 以構建服務於各種業務用例的 DWH 或數據集市表。
數據平台能夠滿足我們的大部分需求，但隨著數據用例的增加，我們看到業務和數據量增長，為滿足業務需求數據平檯面臨多重挑戰。
問題如下：

• 存儲和計算緊密耦合。我們主要依賴基於 ELT 的方法，其中 Redshift 計算層被大量用於任何數據轉換。我們的 Redshift 集群包含多個 dc2.large 實例，其存儲和計算緊密耦合，擴容時存儲與計算一起擴容導致成本增加。
• 數據高延遲。當前管道中的數據延遲幾乎超過 3-4 小時，因為數據首先在 Redshift 中載入，然後每隔幾個時間間隔執行 ELT 操作。我們的業務和產品團隊希望以更低的延遲分析數據，以便他們能夠更快地做出關鍵業務決策。
• 缺乏數據治理。現有數據平台沒有實施適當的數據治理。在 Redshift 中創建Group，並且根據用戶的角色將用戶分配到每個Group，該方法可以控制數據集訪問，但缺乏列或行級別粒度的訪問控制。
• 儀錶板基於哪些數據集構建缺乏可見性。由於所有數據集市表都是根據用例創建，並且當用戶向 DE 團隊請求時，有多個表包含重複數據。由於我們沒有遵循數據模型（星型或雪花模式），因此在 Redshift 中維護表之間的關係變得非常困難。
• 缺少 SCD 管理。SCD 代表緩慢變化維，當有人想知道數據點的歷史價值時，SCD 非常重要。在當前的數據集市中，沒有實施適當的 SCD，在我們的案例中，像藥品價格、醫生類別等都是要跟蹤的重要特徵。
• 通過 Airflow 記憶體移動數據。在 Halodoc，大部分數據流通過 Airflow 發生，所有批處理數據處理作業都安排在 Airflow 上，其中數據移動通過 Airflow 記憶體進行，這為處理不斷增加的數據量帶來了另一個瓶頸。由於 Airflow 不是分散式數據處理框架，因此更適合工作流管理。相當多的 ETL 作業是用 Python 編寫的，以服務於間隔 15 分鐘的微批處理管道，並在 Airflow 中調度。
• 缺少數據目錄。數據目錄對於任何數據平台提供數據的元資訊都非常重要。直接遷移到 Redshift 的表在現有平台中缺少數據目錄。僅為存儲在 S3 中的數據創建數據目錄，這讓終端用戶檢索有關 Redshift 中表的資訊成為問題。
• 沒有集成的數據血緣。如果有人有興趣了解目標數據表的來源和轉換階段，我們沒有數據血緣來展示它們。數據血緣對於理解數據流、數據轉換很重要，並且如果在目標處生成錯誤資訊，則可以輕鬆調試數據。
• 缺少框架驅動的平台。對於每個用例，我們主要構建端到端的數據管道。大多數程式碼在多個數據管道中重複。數據工程任務中缺少軟體工程原則。因此，很難將每一層上的組件解耦並創建一個抽象層來使整個框架端到端自動化。
• 沒有自動模式演進。處理關係數據時模式演進非常重要。源系統中會發生變化，需要在目標系統中反映出來，而管道不會出現任何故障，當前我們手動執行此操作，我們已經建立了一個流程，DBA 將架構更改通知 DE，DE 負責在目標系統中進行更改。我們想要一種自動化的方式來執行這些操作。

由於數據平台的這些限制，我們意識到第一代數據平台已經走到了盡頭。正是在這一點上，我們決定退後一步，想想我們需要從我們的數據平台中得到什麼。如果必須的話我們並不害怕從頭開始構建一個系統。
數據工程團隊開始使用支援或減輕上述大部分限制的新數據平台來評估和改進現有架構。我們調研到了 LakeHouse 架構，它在通過具有成本效益的解決方案實現可擴展性以及處理大量數據方面發揮著至關重要的作用。因此我們開始圍繞 LakeHouse 架構來構建我們改進後的 Data Platform 2.0。

3. 為什麼我們採用 LakeHouse 架構？

LakeHouse 架構基本上是 Datalake 和數據倉庫的組合，可以在其中無縫地跨湖和倉庫移動數據，並遵循對所有數據集的訪問許可權的安全合規性。
在 Halodoc，我們希望構建一個可擴展的解決方案，我們可以根據需要獨立擴展存儲和計算。我們將以下內容列為我們希望數據基礎設施具備的核心功能：

• 解耦存儲和計算（高度可擴展）。
• 可以存儲所有類型的數據，如結構化、半結構化和非結構化。
• 可以作為整個組織中數據的單一事實。
• 存儲/查詢可變和不可變數據的能力。
• 可與 Spark 或 Hive 等分散式處理引擎集成。

在新架構中，我們利用 S3 作為數據湖，因為它可以無限擴展存儲。由於我們計劃將可變數據也存儲在 S3 中，因此下一個挑戰是保持可變 S3 數據的更新。我們評估了幾個框架，如 Iceberg、Delta Lake 和 Apache Hudi，它們提供了更新可變數據的能力。由於 Apache Hudi 與 EMR 集成度很好，因此我們開始在 Hudi 之上構建數據湖。

4. 為什麼選擇Apache Hudi

• 對文件執行 Upsert 操作。
• 使用各種更新捕獲更新歷史記錄。
• 支援ACID。
• 支援不同的存儲類型（CoW 和 MoR）
• 支援多種數據查詢方式（實時優化查詢、快照查詢、增量查詢）
• 數據集的時間旅行。
• 預裝 EMR，開箱即用。

搭建平台的挑戰

• 新架構中使用的大多數組件對團隊來說都是新的，因此需要一些學習曲線來動手操作和生產系統。
• 構建中心化的日誌記錄、監控和警報系統。
• 在改進架構的同時支援常規業務用例。

5. 總結

在本部落格中，我們介紹了現有數據平台中面臨的一些挑戰/限制，以及一些缺失的功能。 在接下來的部落格中，我們將更多地討論 LakeHouse 架構，以及我們如何使用 Apache Hudi 以及在發布新平台時面臨的一些挑戰。隨著不斷迭代，我們將繼續在新平台中添加新功能，以打造更加強大和可靠的數據平台。