在近期的 Apache Kylin × Apache Hudi Meetup 直播上，Apache Kylin PMC Chair 史少鋒和 Kyligence 解決方案工程師劉永恆就 Hudi + Kylin 的准實時數倉實現進行了介紹與演示。下文是分享現場的回顧。
我的分享主題是《基於 Hudi 和 Kylin 構建准實時、高性能數據倉庫》，除了講義介紹，還安排了 Demo 實操環節。下面是今天的日程：
01 數據庫、數據倉庫
先從基本概念開始。我們都知道數據庫和數據倉庫，這兩個概念都已經非常普遍了。數據庫 Database，簡稱 DB，主要是做 OLTP（online transaction processing），也就是在線的交易，如增刪改；數據倉庫 Data Warehouse，簡稱 DW，主要是來做OLAP（online analytics processing），也就是在線數據分析。OLTP 的典型代表是 Oracle、MySQL，OLAP 則像 Teradata、Greenplum，近些年有 ClickHouse、Kylin 等。
02 數據湖
近些年出現了數據湖（Data Lake）的概念，簡單來說數據湖可以存儲海量的、不同格式、匯總或者明細的數據，數據量可以達到 PB 到 EB 級別。企業不僅可以使用數據湖做分析，還可以用於未來的或未曾預判到的場景，因此需要的原始數據存儲量是非常大的，而且模式是不可預知的。數據湖產品典型的像 Hadoop 就是早期的數據湖了，現在雲上有很多的數據湖產品，比方 Amazon S3，Azure Blob store，阿里雲 OSS，以及各家雲廠商都有自己的存儲服務。有了數據湖之后，企業大數據處理就有了一個基礎平台，非常多的數據從源頭收集后都會先落到數據湖上，基於數據湖再處理和加載到不同的分析庫去。
但是，數據湖開始設計主要是用於數據的存儲，解決的是容量的水平擴展性、數據的持久性和高可用性，沒有太多考慮數據的更新和刪除。例如 HDFS 上通常是將文件分塊（block）存儲，一個 block 通常一兩百兆；S3 同樣也是類似，大的 block 可以節省管理開銷，並且這些文件格式不一，通常沒有高效的索引。如果要修改文件中的某一行記錄，對於數據湖來說是非常難操作的，因為它不知道要修改的記錄在哪個文件的哪個位置，它提供的方式僅僅是做批量替換，代價比較大。
03 數據倉庫的加載鏈路
在有這么一個方案之前，我們怎樣能夠支撐到數據的修改從 OLTP 到 OLAP 之間准實時同步呢？通常大家會想到，通過 CDC/binlog 把修改增量發出來，但 binlog 怎么樣進入到 Hive 中去呢？我們知道 Hive 很難很快地修改一條記錄，修改只能把整張表或者整個分區重新寫一遍。為了接收和准實時消費 binlog，可能需要引入一個只讀的 Database 或 MPP 數據庫，專門復制上游業務庫的修改；然后再從這個中間的數據庫導出數據到數據湖上，供下一個階段使用。這個方案可以減少對業務庫的壓力和影響，但依然存在一些問題。
這里有一個生動的例子，是前不久從一個朋友那里看到的，各位可以感受一下。
可以看到在過去的方案是非常復雜的，又要用 MPP 又要用數據湖，還要用 Kylin，在這中間數據頻繁的被導出導入，浪費是非常嚴重的，而且維護成本高，容易出錯，因為數據湖和數據庫之間的文件格式往往還存在兼容性問題。
04 Hudi：新一代數據湖項目
后來我們注意到 Hudi 這個項目，它的目的就是要在大數據集上支持 Upsert（update+insert）。Hudi 是在大數據存儲上的一個數據集，可以將 Change Logs 通過 upsert 的方式合並進 Hudi；Hudi 對上可以暴露成一個普通的 Hive 或 Spark 的表，通過 API 或命令行可以獲取到增量修改的信息，繼續供下游消費；Hudi 還保管了修改歷史，可以做時間旅行或回退；Hudi 內部有主鍵到文件級的索引，默認是記錄到文件的布隆過濾器，高級的有存儲到 HBase 索引提供更高的效率。
05 基於 Hudi+Kylin 的准實時數倉實現
有了 Hudi 之后，可以跳過使用中間數據庫或 MPP，直接微批次地增量消費 binlog，然后插入到 Hudi；Hudi 內的文件直接存放到 HDFS/S3 上，對用戶來說存儲成本可以大大降低，不需要使用昂貴的本地存儲。Hudi 表可以暴露成一張 Hive 表，這對 Kylin 來說是非常友好，可以讓 Kylin 把 Hudi 當一張普通表，從而無縫使用。Hudi 也讓我們更容易地知道，從上次消費后有哪些 partition 發生了修改，這樣 Kylin 只要刷新特定的 partition 就可以，從而端到端的數據入庫的延遲可以降低到1小時以內。從 Uber 多年的經驗來說，對大數據的統計分析，入庫小於 1 小時在大多數場景下都是可以接受的。
這里再總結一下，使用 Hudi 來做 DW 數據加載的前置存儲給我們帶來的諸多的好處：首先，它可以支持准實時的插入、修改和刪除，對保護用戶數據隱私來說是非常關鍵的（例如 GDPR ）；它還可以控制小文件，減少對 HDFS 的壓力；第二，Hudi 提供了多種訪問視圖，可以根據需要去選擇不同的視圖；第三，Hudi 是基於開放生態的，存儲格式使用 Parquet 和 Avro，目前主要是使用 Spark 來做數據操作，未來也可以擴展；支持多種查詢引擎，所以在生態友好性上來說，Hudi 是遠遠優於另外幾個競品的。
06 使用 Kyligence Cloud 現場演示
前面是一個基本的介紹，接下來我們做一個 Live Demo，用到 Kyligence Cloud（基於 Kylin 內核）這個雲上的大數據分析平台；你可以一鍵在 Azure/AWS 上來啟動分析集群，內置多種大數據組件來做建模加速，可直接從雲上存儲或雲上的數據庫抽取數據，提供了自動的監控和運維。
目前 Kyligence Cloud 已經不需要依賴 Hadoop 了，直接使用 VM 來做集群的計算力，內置了 Spark 做分布式計算，使用 S3 做數據存儲；還集成了 Kylignece Insight 做可視化分析，底層可以對接常見的數據源，也包括 Hudi，在最新發布版的 Hudi 已經被集成進來了。
接下來，劉永恆將帶來 Live Demo，他是從業務庫到處數據加載到 Hudi 中，然后 Hudi 隨后就可以從這當中來被訪問。接下來他會演示做一些數據修改，再把這個數據修改合並到 Hudi，在 Hudi 中就可以看到這些數據的改變，接下來的時間就交給劉永恆。
