印尼醫療龍頭企業Halodoc的資料平臺轉型之路:資料平臺V1.0

leesf 發表於 2022-05-04

1. 摘要

資料是每項技術業務的支柱,作為一個健康醫療技術平臺,Halodoc 更是如此,使用者可以通過以下方式與 Halodoc 互動:

  • 送藥
  • 與醫生交談
  • 實驗室測試
  • 醫院預約和藥物

所有這些互動都會產生高度敏感、多樣化且通常是非結構化的資料。 因此隨著公司的成長,必須擁有一個強大的資料平臺,平臺需要滿足如下需求:

  • 確保資料的隱私和安全
  • 在處理結構化和半/非結構化資料時可靠、可擴充套件、快速且高可用
  • 促進為業務/運營團隊生成報告和實時儀表板
  • 為資料科學團隊提供一個平臺來執行實驗、模型和儲存結果

2. 資料平臺

Halodoc 基礎設施託管在 AWS 上,公司的資料基礎設施是 AWS 託管服務和自託管服務的組合,Amazon Redshift 是我們儲存各型別資料的主要資料倉儲。

印尼醫療龍頭企業Halodoc的資料平臺轉型之路:資料平臺V1.0

該平臺的關鍵元件如下所述

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架構的演進,敬請期待。