印尼醫療龍頭企業Halodoc的數據平台轉型之路：數據平台V1.0
- 2022 年 5 月 4 日
- 筆記
1. 摘要
數據是每項技術業務的支柱，作為一個健康醫療技術平台，Halodoc 更是如此，用戶可以通過以下方式與 Halodoc 交互：
- 送葯
- 與醫生交談
- 實驗室測試
- 醫院預約和藥物
所有這些交互都會產生高度敏感、多樣化且通常是非結構化的數據。 因此隨著公司的成長，必須擁有一個強大的數據平台，平台需要滿足如下需求：
- 確保數據的隱私和安全
- 在處理結構化和半/非結構化數據時可靠、可擴展、快速且高可用
- 促進為業務/運營團隊生成報告和實時儀錶板
- 為數據科學團隊提供一個平台來運行實驗、模型和存儲結果
2. 數據平台
Halodoc 基礎設施託管在 AWS 上，公司的數據基礎設施是 AWS 託管服務和自託管服務的組合，Amazon Redshift 是我們存儲各類型數據的主要數據倉庫。
該平台的關鍵組件如下所述
2.1 數據源
Halodoc 生成的數據屬於以下類別：
- 事務數據 – 各種後端服務生成的數據，如諮詢、藥房訂單、約會等，這些數據主要來自關係資料庫 (MySQL)。
- 數字健康記錄 – 醫生預約、醫療賬單、處方、保險索賠等的醫療報告。這些可能是影像或文件，具體取決於醫院和商家合作夥伴。
- 商戶庫存數據 – 我們商戶藥店的庫存數據可以採用不同的格式（csv、xls），通過不同的工具（SFTP、訂製軟體）上傳。
- 來自後端服務的事件——我們的後端由微服務和一個事件生成/消費平台組成，用於這些服務之間的非同步通訊。因此跨不同後端服務生成的事件需要進行實時處理。
- 保險索賠/醫療賬單- Halodoc作為 TPA 還參與索賠解決、驗證索賠和檢測欺詐。這些文檔可以以各種格式（csv、xls、PDF）獲取，需要及時處理以便為患者和保險提供商提供更順暢的理賠體驗。
2.2 批處理管道
批處理管道是我們數據平台的核心，對後端服務和第三方分析工具生成的事務/臨時數據進行處理並寫入數據倉庫。該管道的主要組成部分包括：
- ETL 工具：ETL 代表提取、轉換、載入，ETL 工具有多種選擇。在 Halodoc ETL 主要使用 Airflow 和 Pentaho。
- Pentaho：Pentaho 是一個提供數據提取、集成、轉換、挖掘和載入功能的工具。Pentaho 很大程度上是由 UI 驅動，並且受限於軟體提供的功能，在 Halodoc我們正在慢慢地從 Pentaho 轉向 Airflow。
- Airflow：Airflow 是一個非常靈活的工具，可以更好地控制轉換，同時還可以在現有operator之上構建自己的框架，Airflow 還提供了一個很好的儀錶板來監控和查看作業運行狀態。
數據倉庫和數據湖：數據倉庫是經過優化的資料庫，可以分析來自不同系統的關係型數據，數據結構和模式是預先定義的，以優化快速 SQL 查詢，結果通常用於報告和分析。數據被清理、豐富和轉換，以便它可以作為用戶可以信任的「單一事實來源」。數據湖則是不同的，因為它存儲來自業務線應用程式的關係數據以及來自移動應用程式、物聯網設備和社交媒體的非關係數據，捕獲數據時未定義數據結構或模式。
- Amazon S3 數據湖：Amazon S3 是 Halodoc 的數據湖。 來自各種來源的所有數據首先轉儲到各種 S3 存儲桶中，然後再載入到 Redshift（我們的數據倉庫）中，S3 中的數據也充當備份，以防任何 ETL 作業失敗。
- Amazon Redshift：我們使用 Amazon 的 Redshift 作為集中式數據倉庫，包含一個六節點 Redshift 集群，數據以有規律的節奏從各種來源流入，Amazon Redshift 針對批量載入和通過複製命令從 S3 載入進行了優化，我們所有的業務分析師、數據科學家和決策者都通過各種可視化工具（Looker/Metabase）、SQL 客戶端和其他分析應用程式訪問數據。
存儲在 Redshift 中的數據被建模為星型模式，根據我們擁有的業務單位，由維度表包圍中心事實表。
2.3 實時處理管道
實時數據處理管道作為 Halodoc 事件平台的底層基礎設施，Halodoc 的所有後端服務在每次操作/狀態更改後都會生成事件，並通過此管道進行處理，大多數基於流的系統由以下 4 個組件組成：
- 基於日誌的事件存儲：分散式、可追加的基於日誌的系統，它收集和存儲來自不同來源的數據。例如：Kafka、AWS Kinesis Streams、Google PubSub 等。
- 流計算系統：使用來自事件存儲的數據並在其上運行聚合函數，然後將結果存儲在服務層存儲中，例如AWS Kinesis Data Analytics、Apache Flink、Apache Storm、Apache Spark 等。
- 服務層存儲：存儲聚合數據並提供優化的查詢響應，它也可以存儲時間序列數據。例如InfluxDB、Elasticsearch、AWS DynamoDB 等。
- 服務層：為聚合數據提供可視化表示，例如：Kibana、Grafana 等。
架構
- Apache Kafka – Kafka 已成為大多數開源流處理存儲層的事實標準，用於以低延遲的流方式存儲大量數據。
- Apache Flink：開源平台，為數據流上的分散式計算提供數據分發、通訊、狀態管理和容錯。
- Elasticsearch：開源數據存儲，主要針對搜索進行了優化，但後來作為運營和業務指標的服務層存儲變得非常流行。
- Kibana/Grafana ：一個連接到 Elasticsearch 數據存儲並充當服務層的開源可視化框架。
2.4 數據可視化
有很多可用的數據可視化工具，其中大多數都支援用於構建儀錶板的各種數據源。 我們對工具的選擇主要受以下因素驅動：
- 易用性：BI 開發人員/分析師必須很容易即可創建和維護報告和儀錶板。
- RBAC：我們應該能夠為公司中的不同用戶提供細粒度的訪問。
- 可維護性：工具必須易於維護，無論是在軟體升級、部署和故障排除等方面。
考慮到所有這些因素，我們得出了以下工具：
Looker
- Looker 是一款高級工具，可提供豐富的可視化效果，是我們所有 BI 報告的一站式平台。
- 它提供了一種簡單的方法來衡量 WoW / MoM 增長並跟蹤我們的年度目標。
- 在解決問題時Looker 的支援團隊反應迅速，同時提供具有最新功能的軟體升級。
Metabase
- Metabase 是一個簡單的開源工具，可供公司中的每個人提問和可視化數據。
- 在 Halodoc，Metabase 用作自助服務工具，操作人員和 BI/後端開發人員可以在其中查詢以創建自定義報告和儀錶板。
- 集成插件以發送有關某些關鍵業務指標的實時警報，警報渠道包括slack/電子郵件。
Kibana
- 由於使用 Elasticsearch 作為數據源，Kibana 提供了方便的儀錶板可視化。
- 所有用於監控實時指標（如商家取消、醫生取消等）的實時儀錶板都在 Kibana 中創建。
- 客戶支援和運營團隊依靠這些儀錶板做出及時的決策。
2.5 監控數據基礎設施
監控和警報對於檢查系統和發現生產問題是不可或缺的，它還直接影響平台的可靠性。Halodoc 數據基礎設施由各種工具組成，其中一些由 AWS 管理（Redshift、MSK），而另一些則由內部託管（Elasticsearch、Flink）並由我們的開發運營/數據團隊維護，用於監控的工具包括：
Cloudwatch：它是 AWS 用於監控指標和警報的事實標準，所有 AWS 託管服務（Redshift、MSK、RDS、DynamoDB）都將其指標發布到 Cloudwatch，我們為以下各項設置了警報：
- CPU 使用率和 Redshift 集群運行狀況
- RDS 上的慢查詢
- Lambda 錯誤
- 資料庫連接數等等
警報渠道包括通過 Lambda 發送的 slack/電子郵件。
Prometheus 與 Grafana：Prometheus 和 Grafana 的組合越來越流行，作為 DevOps 團隊用於存儲和可視化時間序列數據的監控，Prometheus 充當存儲後端，Grafana 充當分析和可視化的介面。Prometheus 通過這些目標上的導出器從 HTTP 端點抓取指標，從受監控的目標收集指標。
我們已經自託管了一些平台組件，例如 Airflow、Elasticsearch、Flink 等，自託管這些工具的決定是考慮到成本、devops/數據團隊的經驗和監控成本。
我們為所有這些工具提供了 prometheus 指標導出器，並且使用了用於 Elasticsearch、Airflow 和 Flink 的開源 Grafana 儀錶板，同時在 prometheus 上設置了基於多種可用指標的各種閾值的警報設置，以通過 slack/email 告警。
3. 總結
在這篇部落格中總結了Halodoc的數據平台，從不同來源的數據到各種可視化工具，我們在選擇這些工具時的思考過程，維護和運行此基礎設施是一項艱巨的任務，我們不斷挑戰自己以保持基礎設施簡單並更有效地解決問題。
可擴展性、可靠性和可維護性是構建 Halodoc 技術平台的三大支柱。後續還將介紹數據平台架構到Lakehouse架構的演進，敬請期待。
