在Halodoc，我們始終致力于為最終用戶簡化醫(yī)療保健服務(wù)伴隨著公司的發(fā)展，我們不斷地構(gòu)建和提供新的功能我們兩年前建立的東西可能無法支持我們今天管理的數(shù)據(jù)量，為了解決這個問題，我們決定改進(jìn)數(shù)據(jù)平臺架構(gòu)在本文中，我們將討論我們的新架構(gòu)，涉及的組件以及擁有可擴展數(shù)據(jù)平臺的不同策略

一.新結(jié)構(gòu)

我們先來看看改進(jìn)后的新數(shù)據(jù)平臺2.0的高級架構(gòu)。

我們的架構(gòu)分為4層:

1.數(shù)據(jù)接收/提取層

這一層更關(guān)心的是獲取原始區(qū)域?qū)又械臄?shù)據(jù)，這些數(shù)據(jù)可以在以后的處理區(qū)域中使用和卸載大多數(shù)點擊流捕獲工具都支持其產(chǎn)品的內(nèi)部數(shù)據(jù)捕獲服務(wù)，因此可以輕松獲取或添加原始區(qū)域以進(jìn)行進(jìn)一步處理對于MySQL和Postgres等事務(wù)性數(shù)據(jù)源，我們開始使用基于CDC的方法提取數(shù)據(jù)由于我們的基礎(chǔ)設(shè)施主要托管在AWS中，我們選擇了數(shù)據(jù)遷移服務(wù)來執(zhí)行基于CDC的遷移

2.處理層

我們在這里沒有執(zhí)行任何繁重的轉(zhuǎn)換，而是將原始數(shù)據(jù)轉(zhuǎn)換為胡迪數(shù)據(jù)集數(shù)據(jù)源以不同的格式接收，需要轉(zhuǎn)換成列格式來存儲在數(shù)據(jù)湖中，以便進(jìn)行高效的數(shù)據(jù)處理數(shù)據(jù)類型根據(jù)數(shù)據(jù)湖兼容性進(jìn)行轉(zhuǎn)換，時區(qū)調(diào)整為WIB時間戳

3.轉(zhuǎn)換樓層

數(shù)據(jù)工程的挑戰(zhàn)之一是有效處理大量數(shù)據(jù)，并保持成本不變我們選擇Apache Spark進(jìn)行處理，因為它支持分布式數(shù)據(jù)處理，并且可以輕松地從千兆字節(jié)擴展到千兆字節(jié)的數(shù)據(jù)處理轉(zhuǎn)換層在數(shù)據(jù)倉庫中生成數(shù)據(jù)模型，并成為報表使用數(shù)據(jù)和支持儀表板或報表用例的基礎(chǔ)

4.報告層

報表層主要聚合來自維度和事實表的數(shù)據(jù)，并為下游用戶提供這些數(shù)據(jù)庫的視圖大多數(shù)儀表板將建立在這些報告表和物化視圖上，因此減少了為重復(fù)任務(wù)和報告用例連接不同表的計算成本一旦我們將平臺實現(xiàn)到不同的層，下一個挑戰(zhàn)就是選擇能夠支持我們大多數(shù)下游用例的組件當(dāng)我們調(diào)查市場上的數(shù)據(jù)工程工具/產(chǎn)品時，我們可以很容易地找到大量的工具我們計劃使用AWS云和開源項目來構(gòu)建內(nèi)部解決方案，而不是購買第三方許可工具

下面我們來深入了解一下以上平臺中使用的組件。

涉及的組件:

管理系統(tǒng)

DMS代表數(shù)據(jù)遷移服務(wù)這是一個AWS服務(wù)，可以幫助在MySQL，Postgres等數(shù)據(jù)庫上執(zhí)行CDC我們使用DMS從MySQL數(shù)據(jù)庫中讀取二進(jìn)制日志，并將原始數(shù)據(jù)存儲在S3中在Flask server和boto3實現(xiàn)的幫助下，我們已經(jīng)創(chuàng)建了自動化的DMS資源我們可以輕松地向控制表中配置的原始區(qū)域參數(shù)添加一個新表

S3—原始區(qū)域

DMS捕獲的所有CDC數(shù)據(jù)都存儲在S3相應(yīng)分區(qū)的原始區(qū)域中該層不執(zhí)行數(shù)據(jù)清理每當(dāng)源系統(tǒng)中發(fā)生插入或更新時，數(shù)據(jù)將被附加到新文件中原始區(qū)域?qū)τ谠谛枰獣r執(zhí)行數(shù)據(jù)集的任何回填非常重要它還存儲從點擊流工具或任何其他數(shù)據(jù)源獲取的數(shù)據(jù)原始區(qū)域用作處理該區(qū)域使用的數(shù)據(jù)的基本層

EMR —胡迪+ PySpark

Apache胡迪用于對位于數(shù)據(jù)湖中的數(shù)據(jù)進(jìn)行UPSERT操作我們正在運行PySpark作業(yè)，它以預(yù)定的時間間隔運行，從原始區(qū)域讀取數(shù)據(jù)，處理并存儲在已處理區(qū)域中區(qū)域復(fù)制源系統(tǒng)的行為已處理只有一個UPSERT操作，它被轉(zhuǎn)換成胡迪數(shù)據(jù)集

S3—治療區(qū)

S3處理層是Halodoc的數(shù)據(jù)湖我們存儲可變和不可變的數(shù)據(jù)集胡迪用于維護可變數(shù)據(jù)集不可變的數(shù)據(jù)集如CSV或JSON數(shù)據(jù)也被轉(zhuǎn)換成列格式并存儲在這個區(qū)域中這一層還維護或糾正分區(qū)，以有效地查詢數(shù)據(jù)集

粘附數(shù)據(jù)目錄

AWS Glue數(shù)據(jù)目錄用于注冊表，Athena可以查詢該目錄進(jìn)行臨時分析。

雅典娜

Athena是一個無服務(wù)器的查詢引擎，支持S3的數(shù)據(jù)查詢使用Athena對位于數(shù)據(jù)湖中的數(shù)據(jù)集進(jìn)行任何臨時分析

紅移

紅移被用作數(shù)據(jù)倉庫來建立數(shù)據(jù)模型所有報告/BI使用案例都由Redshift提供服務(wù)我們在紅移中創(chuàng)建了2層第一層負(fù)責(zé)存儲PD，CD，預(yù)約，保險，實驗室的所有數(shù)據(jù)模型，包含事實和維度我們構(gòu)建了一個報告層框架，用于聚合和連接，以創(chuàng)建可以通過BI工具訪問的報告表我們還在這些層中維護物化視圖我們還在我們的數(shù)據(jù)模型中實現(xiàn)了SCD type1和SCD type2，以捕獲數(shù)據(jù)集中的歷史變化

MWAA

MWAA用來安排工作流程。

云觀察和EFK

云觀察EFK相結(jié)合，建立一個集中的日志記錄，監(jiān)測和警報系統(tǒng)。

動態(tài)數(shù)據(jù)庫

平臺使用Dynamodb將失敗事件存儲在控制表中并發(fā)布開發(fā)了一個再處理框架來處理失敗事件，并以預(yù)定的頻率將它們推送到控制表

第二，為什么選擇以疾控中心為主的方式。

在Halodoc，當(dāng)我們開始數(shù)據(jù)工程之旅時，我們采用了基于時間戳的數(shù)據(jù)遷移我們依靠修改后的時間戳將數(shù)據(jù)從源遷移到目標(biāo)我們使用這條管道已經(jīng)快兩年了伴隨著業(yè)務(wù)的增長，我們的數(shù)據(jù)集呈指數(shù)級增長，這要求我們增加向更大集群的遷移實例，以支持大量數(shù)據(jù)

這些問題如下:

由于源端產(chǎn)生大量數(shù)據(jù)，遷移集群的規(guī)模增大，因此成本較高由于一些后端問題，修改過的列不更新時會出現(xiàn)數(shù)據(jù)質(zhì)量問題模式更改在目標(biāo)中很難處理基于CDC，我們通過啟用MySQL中的binlog和Postgres中的WAL開始讀取事務(wù)數(shù)據(jù)提取每個事件更改的新文件是一項開銷很大的操作，因為會有許多S3 Put操作為了平衡成本，我們將DMS二進(jìn)制日志設(shè)置為每60秒讀取和提取一次每一分鐘，通過DMS插入新文件基于CDC，我們還解決了大量數(shù)據(jù)增長的問題，因為我們開始以最大的分鐘間隔而不是以小時間隔進(jìn)行遷移

胡迪提供內(nèi)置特性來支持開放數(shù)據(jù)湖當(dāng)我們在我們的平臺中加入或整合胡迪時，我們面臨以下一些挑戰(zhàn)，并試圖解決它們

1.在胡迪數(shù)據(jù)集中保持最大提交。

2.確定要分區(qū)的表。

對數(shù)據(jù)湖中的數(shù)據(jù)進(jìn)行分區(qū)總是可以減少掃描的數(shù)據(jù)量并提高查詢性能類似地，在lake中有一個大的分區(qū)會降低讀查詢性能，因為它必須合并多個文件進(jìn)行數(shù)據(jù)處理我們選擇數(shù)據(jù)湖作為最小的每日分區(qū)，并計劃將歷史數(shù)據(jù)歸檔到其他存儲層，如Glacier或低成本的S3存儲層

3.選擇正確的儲物類型。

胡迪目前支持兩種類型的存儲，即和morcow必須根據(jù)使用情形和工作負(fù)載準(zhǔn)確選擇存儲類型我們?yōu)榫哂械蛿?shù)據(jù)延遲訪問的表選擇MoR，為數(shù)據(jù)延遲超過2小時的表選擇CoW

4.MOR數(shù)據(jù)集的不同視圖

支持MoR _ro和_rt視圖_ro代表讀取優(yōu)化視圖，而_rt代表實時視圖根據(jù)用例，您必須確定要查詢哪個表我們?yōu)镋TL工作負(fù)載選擇了_ro視圖，因為數(shù)據(jù)模型中的數(shù)據(jù)延遲大約為1小時基于數(shù)據(jù)湖構(gòu)建的報告正在查詢_rt表，以獲取數(shù)據(jù)集的最新視圖

5.胡迪指數(shù)

索引胡迪對于維護UPSERT操作和讀取查詢性能非常有用有全局索引和非全局索引我們使用默認(rèn)的bloom索引，并為索引選擇一個靜態(tài)列，即非全局索引我們依靠胡迪提交時間來獲取增量數(shù)據(jù)這也有助于在沒有任何人工干預(yù)的情況下將后期數(shù)據(jù)處理到待處理的數(shù)據(jù)湖

5.為什么框架是驅(qū)動的。

我們以前的大多數(shù)實現(xiàn)都是管道驅(qū)動的，這意味著我們手動為每個數(shù)據(jù)源構(gòu)建管道來服務(wù)于業(yè)務(wù)用例在Platform 2.0中，我們對實現(xiàn)模型進(jìn)行了細(xì)微的修改，并采用了框架驅(qū)動的管道我們開始在每一層上搭建框架，比如數(shù)據(jù)攝取框架，數(shù)據(jù)處理框架，報表框架每個框架都專門使用預(yù)定義的輸入來執(zhí)行某些任務(wù)框架驅(qū)動的采用減少了維護冗余代碼，簡化了數(shù)據(jù)湖中新表的加載過程

1.使用表格控制平面的好處

在我們的平臺中，控制平面是存儲元數(shù)據(jù)和幫助在數(shù)據(jù)湖和數(shù)據(jù)倉庫中輕松加載新表的關(guān)鍵組件它存儲啟用數(shù)據(jù)遷移所需的必要配置對于構(gòu)建任何產(chǎn)品來說，元數(shù)據(jù)在自動化和控制管道過程中起著至關(guān)重要的作用在Yaml，DynamoDB或RDBMS中，我們有不同的選項可供選擇

輕松地對元數(shù)據(jù)執(zhí)行任何分析，例如活動管道的數(shù)量易于加載新表或數(shù)據(jù)模型使用python flask API輕松構(gòu)建API層審計很容易完成

在醫(yī)療保健領(lǐng)域，安全性一直是我們數(shù)據(jù)平臺的重中之重我們在私有子網(wǎng)中托管幾乎所有的基礎(chǔ)架構(gòu)，并支持Lake Formation管理對數(shù)據(jù)湖的訪問我們還對靜態(tài)數(shù)據(jù)使用AWS加密這為數(shù)據(jù)湖和整個數(shù)據(jù)平臺提供了安全的存儲

2.自動化

自動化總是有助于減少構(gòu)建和維護平臺的工程工作量在Platform 2.0中，我們的大多數(shù)管道都是由Jenkins和API實現(xiàn)自動化的我們通過部署flask服務(wù)器并使用boto3創(chuàng)建資源來自動創(chuàng)建DMS資源

我們幾乎所有的基礎(chǔ)設(shè)施/資源都是通過Terraform創(chuàng)建的SRE在我們大部分?jǐn)?shù)據(jù)平臺基礎(chǔ)設(shè)施的建設(shè)中發(fā)揮了重要作用

3.記錄，監(jiān)控和報警

盡管我們的基礎(chǔ)架構(gòu)強健，容錯且高度可擴展，但有時會出現(xiàn)意外錯誤，導(dǎo)致基礎(chǔ)架構(gòu)停機為了識別和解決這些問題，我們使用云監(jiān)控和EFK堆棧來監(jiān)控和警報我們數(shù)據(jù)平臺中涉及的每個組件

4.工作流程安排

任何數(shù)據(jù)平臺都需要調(diào)度能力來運行批量數(shù)據(jù)管道由于我們已經(jīng)在之前的平臺中使用了Airflow進(jìn)行工作流編排，因此我們繼續(xù)使用相同的編排工具M(jìn)WAA在減少維護工作量和節(jié)約成本方面起到了很大的作用我們在之前的博客中解釋了我們在MWAA的評估

動詞 一般化

在本文中，我們研究了湖屋架構(gòu)，構(gòu)建platform 2.0所涉及的所有組件，以及我們將胡迪用作數(shù)據(jù)湖的要點。由于我們現(xiàn)在已經(jīng)構(gòu)建了數(shù)據(jù)平臺2.0的基礎(chǔ)部分，接下來我們計劃重點關(guān)注平臺的以下方面:

質(zhì)量—gt，維護整個數(shù)據(jù)倉庫的數(shù)據(jù)檢查和數(shù)據(jù)一致性數(shù)據(jù)血緣—gt，為數(shù)據(jù)轉(zhuǎn)換提供端到端的步驟BI的自助服務(wù)平臺——gt，減少DE團隊對入職報表的依賴處理后期維度:保持我們的數(shù)據(jù)模型的一致性，處理從湖到倉庫的后期維度鍵