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