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

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

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

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

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

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

2.處理層

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

3.轉(zhuǎn)換樓層

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

4.報(bào)告層

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

下面我們來(lái)深入了解一下以上平臺(tái)中使用的組件。

涉及的組件:

管理系統(tǒng)

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

S3—原始區(qū)域

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

EMR —胡迪+ PySpark

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

S3—治療區(qū)

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

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

AWS Glue數(shù)據(jù)目錄用于注冊(cè)表，Athena可以查詢?cè)撃夸涍M(jìn)行臨時(shí)分析。

雅典娜

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

紅移

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

MWAA

MWAA用來(lái)安排工作流程。

云觀察和EFK

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

動(dòng)態(tài)數(shù)據(jù)庫(kù)

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

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

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

這些問(wèn)題如下:

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

胡迪提供內(nèi)置特性來(lái)支持開放數(shù)據(jù)湖當(dāng)我們?cè)谖覀兊钠脚_(tái)中加入或整合胡迪時(shí)，我們面臨以下一些挑戰(zhàn)，并試圖解決它們

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

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

對(duì)數(shù)據(jù)湖中的數(shù)據(jù)進(jìn)行分區(qū)總是可以減少掃描的數(shù)據(jù)量并提高查詢性能類似地，在lake中有一個(gè)大的分區(qū)會(huì)降低讀查詢性能，因?yàn)樗仨毢喜⒍鄠€(gè)文件進(jìn)行數(shù)據(jù)處理我們選擇數(shù)據(jù)湖作為最小的每日分區(qū)，并計(jì)劃將歷史數(shù)據(jù)歸檔到其他存儲(chǔ)層，如Glacier或低成本的S3存儲(chǔ)層

3.選擇正確的儲(chǔ)物類型。

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

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

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

5.胡迪指數(shù)

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

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

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

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

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

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

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

2.自動(dòng)化

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

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

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

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

4.工作流程安排

任何數(shù)據(jù)平臺(tái)都需要調(diào)度能力來(lái)運(yùn)行批量數(shù)據(jù)管道由于我們已經(jīng)在之前的平臺(tái)中使用了Airflow進(jìn)行工作流編排，因此我們繼續(xù)使用相同的編排工具M(jìn)WAA在減少維護(hù)工作量和節(jié)約成本方面起到了很大的作用我們?cè)谥暗牟┛椭薪忉屃宋覀冊(cè)贛WAA的評(píng)估

動(dòng)詞 一般化

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

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