1.項目背景
傳統的多倉庫組織結構是為離線數據的OLAP(聯機事務分析)需求而設計的。導入數據的常用方式是通過sqoop或spark調度作業將業務庫數據壹批壹批導入多倉庫。隨著數據分析對實時性要求的不斷提高，每小時甚至分鐘級別的數據同步變得越來越普遍。因此，開展了基於spark/flink流處理機制的(準)實時同步系統的開發。
然而，實時同步數據倉庫從壹開始就面臨以下挑戰:
小文件問題。無論是spark的微批處理模式，還是flink的逐項處理模式，每次寫HDFS都是幾米甚至幾十KB的文件。長時間產生的大量小文件會對HDFS namenode造成很大壓力。
支持更新操作。HDFS系統本身不支持數據修改，因此無法在同步過程中修改記錄。
事務性如何保證事務，無論是添加數據還是修改數據。也就是說，當流處理程序提交時，數據只被寫入HDFS壹次，當程序回滾時，已寫入或部分寫入的數據可以被刪除。
胡迪是上述問題的解決方案之壹。以下是胡迪的簡介，主要內容已從官方網站翻譯過來。
2.胡迪簡介
2.1時間線
胡迪為表格的所有操作按照瞬間維護了壹個時間軸，可以提供某個瞬間的表格視圖，並高效提取延遲的數據。每個時刻包括:
時間行為:表操作的類型，包括:
Commit: commit，自動將批數據寫入表中；
清理:清理，後臺作業，不斷清理舊版本不需要的數據；
Delta _ commit: delta原子性地將批量記錄寫入MergeOnRead表，數據寫入的目的地是Delta日誌文件；
壓縮:壓縮，後臺作業，它將不同結構的數據(如存儲在行中以記錄更新操作的日誌文件)組合成存儲在列中的文件。壓縮本身是壹種特殊的提交操作；
回滾:回滾，當壹些不成功時，刪除所有部分寫入的文件；
Savepoint:保存點，將壹些文件組標記為“已保存”，這樣cleaner就不會刪除這些文件；
時間和時間:操作開始的時間戳；
狀態:當前的狀態，包括:
請求的操作已計劃執行，但尚未初始化。
飛行中，壹項行動正在進行中。
已完成時間線上的操作已完成。
胡迪確保根據時間線執行的操作是原子的，並且根據時間和時間與時間線壹致。
2.2文件管理
胡迪表存在於DFS系統的基路徑目錄中，該目錄被分成不同的分區。每個分區以分區路徑作為唯壹標識符，其組織形式與Hive相同。
在每個分區中，文件按唯壹的FileId文件Id劃分到文件組中。每個文件組包含多個文件切片文件切片，每個切片包含壹個由提交或壓縮操作形成的基本文件(parquet文件)，以及壹個包含對基本文件的插入/更新的日誌文件(log file)。胡迪采用MVCC設計。壓縮操作會將日誌文件和相應的基本文件合並成壹個新的文件片，清理操作會刪除無效或舊版本的文件。
2.3索引
胡迪通過將Hoodie鍵(記錄鍵+分區路徑)映射到文件id來提供高效的向上插入操作。當記錄的第壹個版本寫入文件時，該記錄的鍵值與文件的映射關系不會改變。換句話說，映射文件組總是包含壹組記錄的所有版本。
2.4表格類型&；詢問
胡迪表類型定義了如何將數據編入索引並分發到DFS系統，以及如何將上述基本屬性和時間線事件應用於該組織。查詢類型定義了基礎數據如何向查詢公開。
|表類型|支持的查詢類型||: -復制於。
2.4.1表格類型
寫時復制:僅使用parquet存儲文件。更新數據時，邊寫邊同步合並文件，只修改文件版本再重寫。
讀取時合並:parquet)+ avro用於存儲數據。當更新數據時，新數據被寫入增量文件，然後以異步或同步方式合並到新版本的列存儲文件中。
| Choose | copyonwrite | merge on read | |:-。更新成本(I/O)更新操作開銷(I/O) |高(重寫整個鑲嵌)|低(附加到增量記錄)||鑲嵌文件大小|小(高更新(I/O開銷)|大(低更新開銷)| |寫頻率|高|低(取決於合並策略)|
2.4.2查詢類型
快照查詢:該查詢將看到後續提交和合並操作的最新表快照。對於讀取表上的合並，最新的基本文件和增量文件將被合並，以便可以看到接近實時的數據(幾分鐘的延遲)。對於寫時復制表，當有更新/刪除操作或其他寫操作時，它將直接替換現有的拼花表。
增量查詢:在給定的提交/合並操作之後，查詢將只看到新寫入的數據。從而有效地提供了變更流程，實現了增量數據管道。
讀取優化的查詢:在給定的提交/合並操作之後，查詢將看到表的最新快照。只能查看最新文件切片中的基本/列存儲文件，查詢效率與非胡迪列存儲表相同。
|貿易|快照|閱讀優化|||: -。查詢延遲|高(組合基本/列存儲文件+行存儲增量/日誌文件)|低(原始基本/列存儲文件查詢性能)|
3.火花結構化流被寫入胡迪
下面是集成spark結構化流+胡迪的示意圖代碼。因為胡迪OutputFormat目前只支持調用spark rdd對象，所以寫HDFS采用spark結構化流的forEachBatch運算符。詳情見註釋。
4.試驗結果
受測試條件限制，本測試不考慮更新操作，只測試胡迪追加新數據的性能。
數據程序1 * * *運行5天，期間沒有出現錯誤，導致程序退出。
卡夫卡每天閱讀約654.38+05萬條數據，消耗的話題***有9個分區。
幾個要點如下
1有數據丟失和重復嗎？
因為每條記錄的分區+偏移量是唯壹的，所以通過檢查偏移量在同壹個分區內是否重復和不連續，可以得出沒有數據丟失和重復消耗的結論。
2單日寫入的最小支持數據量
數據寫入效率，對於cow和mor表，沒有更新操作時，寫入速率接近。在這個測試中，spark每秒處理大約170條記錄。單日可處理15萬條記錄。
3 cow和mor表文件大小比較
每十分鐘讀兩種表。同樣分區小文件大小，單位m .結果如下:mor表的文件大小大大增加，占用更多的磁盤資源。當沒有更新操作時，盡可能使用cow表。