Apache Hudi在醫療大資料中的應用

本篇文章主要介紹Hudi在醫療大資料中的應用，主要分為５個部分進行介紹：1. 建設背景，2. 為什麼選擇Hudi，3. Hudi資料同步，4. 儲存型別選擇及查詢優化，5. 未來發展與思考。

1. 建設背景

我們公司主要為醫院建立大資料應用平臺，需要從各個醫院系統中抽取資料建立大資料平臺。如醫院資訊系統，實驗室（檢驗科）資訊系統，體檢資訊系統，臨床資訊系統，放射科資訊管理系統，電子病例系統等等。

在這麼多系統中構建大資料平臺有哪些痛點呢？大致列舉如下。

• 接入的資料庫多樣化。其中包括很多系統，而系統又是基於不同資料庫進行開發的，所以要支援的資料庫比較多,例如MySQL，Oracle，Mongo db，SQLServer，Cache等等。
• 統一資料建模。針對不同的醫院不同的系統裡面的表結構，欄位含義都不一樣，但是最終資料模型是一定的要應用到大資料產品上的，這樣需要考慮資料模型的量化。
• 資料量級差別巨大。不一樣的醫院，不一樣的系統，庫和表都有著很大的資料量差異，處理方式是需要考慮相容多種場景的。
• 資料的時效性。資料應用產品需要提供更高效的實時應用分析，這也是資料產品的核心競爭力。

2. 為什麼選擇Hudi

我們早期的資料合併方案，如下圖所示

即先通過binlog解析工具進行日誌解析，解析後變為JSON資料格式傳送到Kafka 佇列中，通過Spark Streaming 進行資料消費寫入HBase，由HBase完成資料CDC操作，HBase即我們ODS資料層。由於HBase 無法提供複雜關聯查詢，這對後續的資料倉儲建模並不是很友好，所以我們設計了HBase二級索引來解決兩個問題：1. 增量資料的快速拉取，2. 解決資料的一致性。然後就是自研ETL工具通過DataX 根據最後更新時間增量拉取資料到Hadoop ，最後通過Impala資料模型建模後寫入Greenplum提供資料產品查詢。

上述方案面臨瞭如下幾個問題

• 資料流程環節複雜，資料要經過Kafka，HBase，Hdfs，Impala。
• 資料校驗困難，每層資料質量校驗比較麻煩。
• 資料儲存冗餘，HBase儲存一份，Hive Hdfs 也儲存一份。
• 查詢負載高，HBase表有上限一旦表比較多，維護的Region個數就比較多，Region Server 容易出現頻繁GC。
• 時效性不高，流程長不能保證每張表都能在10分鐘內同步，有些資料表有滯後現象。

面對上述的問題，我們開始調研開源的實現方案，然後選擇了Hudi，選擇Hudi 優勢如下

• 多種模式的選擇。目前Hudi 提供了兩種模式：Copy On Write和Merge On Read，針對不同的應用場景，可選擇不同模式，並且每種模式還提供不同檢視查詢，。
• 支援多種查詢引擎。Hudi 提供Hive，Spark SQL，presto、Impala 等查詢方式，應用選擇更多。
• Hudi現在只是Spark的一個庫， Hudi為Spark提供format寫入介面，相當於Spark的一個庫，而Spark在大資料領域廣泛使用。
• Hudi 支援多種索引。目前Hudi 支援索引型別HBASE，INMEMORY，BLOOM，GLOBAL_BLOOM 四種索引以及使用者自定義索引以加速查詢效能，避免不必要的檔案掃描。
• 儲存優勢， Hudi 使用Parquet列式儲存，並帶有小文合併功能。

3. Hudi 資料同步

Hudi資料同步主要分為兩個部分：1. 初始化全量資料離線同步；2. 近實時資料同步。

離線同步方面：主要是使用DataX根據業務時間多執行緒拉取，避免一次請求過大資料和使用資料庫驅動JDBC拉取資料慢問題，另外我們也實現多種datax 外掛來支援各種資料來源，其中包括Hudi的寫入外掛。

近實時同步方面：主要是多表通過JSON的方式寫入Kafka，在通過Flink多輸出寫入到Hdfs目錄，Flink會根據binlog json的更新時間劃分時間間隔，比如0點0分到0點5分的資料在一個目錄，0點5分到0點10分資料一個目錄，根據資料實時要求選擇目錄時間的間隔。接著通過另外一個服務輪詢監控Hdfs是否有新目錄生成，然後呼叫Hudi Merge指令碼任務。執行任務都是提交到執行緒池，可以根據叢集的資源調整併合並的數量。

這裡可能大家有疑問，為什麼不是Kafka 直接寫入Hudi ？官方是有這樣例子，但是是基於單表的寫入，如果表的資料多達上萬張時怎麼處理？不可能建立幾萬個Topic。還有就是分流的時候是無法使用Spark Write進行直接寫入。

4. 儲存型別選擇及查詢優化

我們根據自身業務場景，選擇了Copy On Write模式，主要出於以下兩個方面考慮。

• 查詢時的延遲，
• 基於讀優化檢視增量模式的使用。

關於使用Spark SQL查詢Hudi也還是SQL拆分和優化、設定合理分割槽個數（Hudi可自定義分割槽可實現上層介面）,提升Job並行度、小表的廣播變數、防止資料傾斜引數等等。

關於使用Presto查詢測試比Spark SQL要快3倍，合理的分割槽對優化非常重要，Presto 不支援Copy On Write 增量檢視，在此基礎我們修改了hive-hadoop2外掛以支援增量模式，減少檔案的掃描。

5. 未來發展與思考

• 離線同步接入類似於FlinkX框架，有助於資源統一管理。FlinkX是參考了DataX的配置方式，把配置轉化為Flink 任務執行完成資料的同步。Flink可執行在Yarn上也方便資源統一管理。

• Spark消費可以支援多輸出寫入，避免需要落地Hdfs再次匯入。這裡需要考慮如果多表傳輸過來有資料傾斜的問題，還有Hudi 的寫入不僅僅只有Parquert資料寫入，還包括後設資料寫入、布隆索引的變更、資料合併邏輯等，如果大表合併比較慢會影響上游的消費速度。

• Flink對Hudi的支援，社群正在推進這塊的程式碼合入。

• 更多參與社群，希望Hudi社群越來越好。