大數據之Hudi + Kylin的準實時數倉實現

問題導讀：
1、數據庫、數據倉庫如何理解？
2、數據湖有什麼用途？解決什麼問題？
3、數據倉庫的加載鏈路如何實現？
4、Hudi新一代數據湖項目有什麼優勢？



在近期的 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 可以節省管理開銷，並且這些文件格式不一，通常沒有高效的索引。如果要修改文件中的某一行記錄，對於數據湖來說是非常難操作的，因爲它不知道要修改的記錄在哪個文件的哪個位置，它提供的方式僅僅是做批量替換，代價比較大。



另外一個極端的存儲則是像 HBase 這樣的，提供高效的主鍵索引，基於主鍵就可以做到非常快的插入、修改和刪除；但是 HBase 在大範圍讀的效率比較低，因爲它不是真正的列式存儲。對於用戶來說面臨這麼兩個極端：一邊是非常快的讀存儲（HDFS/S3），一邊是非常快速的寫存儲；如果取中間的均衡比較困難。有的時候卻需要有一種位於兩者之間的方案：讀的效率要高，但寫開銷不要那麼大。

03數據倉庫的加載鏈路
在有這麼一個方案之前，我們怎樣能夠支撐到數據的修改從 OLTP 到 OLAP 之間準實時同步呢？通常大家會想到，通過 CDC/binlog 把修改增量發出來，但 binlog 怎麼樣進入到 Hive 中去呢？我們知道 Hive 很難很快地修改一條記錄，修改只能把整張表或者整個分區重新寫一遍。爲了接收和準實時消費 binlog，可能需要引入一個只讀的 Database 或 MPP 數據庫，專門複製上游業務庫的修改；然後再從這個中間的數據庫導出數據到數據湖上，供下一個階段使用。這個方案可以減少對業務庫的壓力和影響，但依然存在一些問題。



這裏有一個生動的例子，是前不久從一個朋友那裏看到的，各位可以感受一下。



可以看到在過去的方案是非常複雜的，又要用 MPP 又要用數據湖，還要用 Kylin，在這中間數據頻繁的被導出導入，浪費是非常嚴重的，而且維護成本高，容易出錯，因爲數據湖和數據庫之間的文件格式往往還存在兼容性問題。



04Hudi：新一代數據湖項目
後來我們注意到 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 中就可以看到這些數據的改變，接下來的時間就交給劉永恆。