分爲產生背景、動機、設計、使用案例、demo幾個模塊講解。
Uber的行程在2018年已經達到700個城市，70個國家，200w+司機的規模。
而數據在Uber中可分爲攝取和查詢，而攝取包括從kafka、hdfs上消費數據；查詢則包括使用spark notebook的數據科學家，使用Hive/Presto進行ad hoc查詢和dashboard展示，使用Spark/Hive構建數據管道或ETL任務等。引入Hudi，Hudi可以管理原始數據集，提供upsert、增量處理語義及快照隔離。
這是典型的流、批分析架構，可以看到，流、批處理會共同消費消息中間件（如kafka）的數據，流處理提供小於1min延遲的結果，批處理提供大約1小時延遲的結果，而批處理結果可修正流處理結果，這是一種典型的Lambda架構，即需要維護兩套系統，維護成本會較高。
當使用數據湖後，會提供如下優勢：1. 支持最新數據上的Ad hoc查詢；2. 近實時處理（微批），很多業務場景並不需要完全實時；3. 對於數據的處理更爲得當，如檢查文件大小，這對HDFS這類存儲非常重要，無需重寫整個分區的處理；4. 維護成本更低，如不需要複製數據，也不需要維護多套系統。
Hudi作爲Uber開源的數據湖框架，抽象了存儲層（支持數據集的變更，增量處理）；爲Spark的一個Lib（任意水平擴展，支持將數據存儲至HDFS）；開源（現已在Apache孵化）。
基於Hudi的架構設計，支持upsert，支持增量處理，支持不同的視圖等等，可以看到與典型的Lambda框架不同，此時基於Hudi的分析架構只需要維護Hudi即可，由Hudi提供的能力來滿足上層應用不同的需求。
Hudi在HDFS上管理了數據集，主要包括索引，數據文件和元數據，並且支持Hive/Presto/Spark進行查詢。
Hudi提供了三種不同類型的視圖，讀優化視圖、實時視圖、增量視圖，社區正在重構這三個定義，分別爲讀優化視圖、快照視圖、增量視圖。
對於COW類型，支持讀優化視圖，對於MOR類型，支持讀優化視圖、實時視圖，而對於最新的發佈版而言，COW支持讀優化視圖和增量視圖，MOR支持讀優化視圖、實時視圖和增量視圖。
在COW模式下，讀優化視圖僅僅讀取parquet數據文件，在批次1upsert後，讀優化視圖讀取File1和File2文件；在批次2upsert後，讀優化視圖讀取File 1'和File2文件。
使用COW模式可以解決很多問題，但其也存在一些問題，如寫方法，即更新的時延會比較大（由於複製整個文件導致）。
下面的工作流表示瞭如何處理延遲到達的更新，更新首先會反應至源表（Source table），然後源表更新至ETL table A，然後更新至ETL table B，這種工作流的延遲更大。
根據上面分析，可歸納出如下問題，高社區延遲、寫放大、數據新鮮度受限以及小文件問題。
與COW模式下更新時複製整個文件不同，可以將更新寫入一個增量文件，這樣便可降低數據攝取延遲，降低寫放大。
MOR模式下提供了讀優化視圖和實時視圖。
在批次1upsert之後，讀優化視圖讀取的也是Parquet文件，在批次2upsert之後，實時視圖讀取的是parquet文件和日誌文件合併的結果。
對比Hudi上不同視圖下的權衡，COW下的讀優化視圖擁有Parquet原生文件讀取性能，但數據攝取較慢；MOR下的讀優化視圖也有parquet原生文件讀取性能，但會讀取到過期的數據（並未更新）；MOR下實時視圖數據攝取性能高，在讀的時候會合並；合併（compaction）會將日誌文件轉化爲parquet文件，從實時視圖轉化爲讀優化視圖。
針對compaction（壓縮），Hudi提供了基於MVCC無鎖的異步壓縮方式，這樣便可解耦數據攝取，使得數據攝取不受影響。
異步壓縮會將日誌文件和數據文件合併形成新的數據文件，之後讀優化視圖便可反應最新的數據。
Hudi還提供了併發保證，如快照隔離，批次寫入的原子性。
Hudi使用案例分享
在Uber，通過Uber自研的Marmaray消費kafka中的數據，然後再寫入Hudi數據湖，每天超過1000個數據集的100TB數據，Hudi管理的數據集大小已經達到10PB。
而對於HDFS的典型的小文件問題，Hudi在攝取數據時會自動處理小文件來減輕namenode的壓力；支持大文件寫入；支持對現有文件的增量更新。
Hudi也考慮了數據隱私問題，即數據如何刪除，Hudi提供了軟刪除和硬刪除兩種方式，軟刪除不會刪除key，只會刪除內容，而硬刪除會刪除key和內容。
使用Hudi的增量處理來構建增量管道和dashboard。
