一個簡化、落地的實時資料倉儲解決方案

從傳統的經驗來講，資料倉儲有一個很重要的功能是記錄資料變化歷史。通常，資料倉儲都希望從業務上線的第一天開始有資料，然後一直記錄到現在。但實時處理技術，又是強調當前處理狀態的一門技術，所以當這兩個相互對立的方案重疊在一起的時候，註定不是用來解決一個比較廣泛問題的方案。於是，我們把實時資料倉儲建設的目標定位為解決由於傳統資料倉儲資料時效性低而解決不了的問題。

實時資料倉儲也引入了類似於離線資料倉儲的分層理念，主要是為了提高模型的複用率，同時兼顧易用性、一致性以及計算成本。通常離線資料倉儲採用空間換取時間的方式，所以層級劃分比較多，從而提高資料計算效率。實時資料倉儲的分層架構在設計上考慮到時效性問題，分層設計儘量精簡，避免資料在流轉過程中造成不必要的延遲響應，並降低中間流程出錯的可能性。實時資料倉儲分層架構如圖1-9 所示。

圖1-9   實時資料倉儲分層架構

l   ODS 層：以Kafka 為支撐，將所有需要實時處理的相關資料放到Kafka 佇列中來實現貼源資料層。這一層是資料輸入層，主要是埋點、流量、日誌等訊息資料的接入。

l   DWD （Data Warehouse Detail ）層：實時計算訂閱業務資料訊息佇列，然後透過資料清洗、多資料來源連線、流式資料與離線維度資訊的組合等，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加資料易用性和複用性，得到最終的實時明細資料。

l   DIM （Dimension ）層：存放用於關聯查詢的維度資訊，可以根據資料現狀來選擇儲存介質，例如使用HBase 或者MySQL 。對於實時ETL 、實時統計，或者特徵加工時需要進行流資料和靜態維表資料關聯處理等情況，這一層是必須的。

l   DWS （Data WareHouse Service ）層：輕度彙總層是為了便於面向即席查詢或者實時OLAP 分析構建的輕度彙總結果集合，適合資料維度、指標資訊比較多的情況。為了方便根據自定義條件的快速篩選和指標聚合，推薦使用MPP 型別資料庫進行儲存。此層可視場景情況決定是否構建。

l   APP 層：面向實時資料場景需求構建的高度彙總層，可以根據不同的資料應用場景決定所使用的儲存介質或者引擎。APP 層已經脫離了資料倉儲，這裡雖然作為一個獨立分層，但實際APP 層的資料已經分佈儲存在各種介質中以供使用。

圖1-10 顯示的是一個簡化的、落地的，並基於MySQL 、Canal 、Kafka 、Greenplum 構建的實時資料倉儲架構。本書後面討論的實踐部分都基於此架構進行設計開發。

圖1-10   基於MySQL 、Canal 、Kafka 、Greenplum 的實時資料倉儲架構

在真實的資料倉儲專案中會涉及多種資料來源，不同資料來源產生的資料質量可能差別很大，資料庫中的格式化資料可以直接匯入大資料儲存系統，而日誌或爬蟲產生的資料就需要進行大量的清洗、轉化處理才能有效使用。幾乎在所有領域的業務資料來源中，關聯式資料庫都佔有絕對比重，而其中MySQL 毋庸置疑是當今最+流+行的關聯式資料庫系統。本書將MySQL 作為唯+一資料來源，一是出於簡化目的，因為後面的實踐均給出程式碼級別的實操，不可能面面俱到；二是MySQL 具有典型性，搞定MySQL 的資料採集就可以解決實際應用中的大部分問題。

Canal Server 從MySQL 從庫產生的binlog （開啟log_slave_updates ）抽取增量資料變更日誌，這樣做有兩個好處。首先，最重要的是它不會影響線上業務，因為Canal Server 只是在從庫建立一個Binlog Dump 執行緒，對MySQL Server 的影響微乎其微。其次，從庫可以隨時啟停複製，這樣可以很容易地為下游元件確定一個增量資料同步起點，在進行首+次全量資料同步時就可以有效利用這一點來實現。

Canal Server 作為資料生產者將記錄資料變化的binlog 以訊息形式傳遞給Kafka 。Kafka 一方面可以將訊息持久化儲存，避免資料丟失，另一方面可以充當資料入倉前的緩衝區。Canal Adapter 作為資料消費者從Kafka 接收訊息，然後將資料寫入Greenplum 資料庫。

資料進入Greenplum 後，就可以利用它提供的規則（rule ）、使用者自定義函式（UDF ）、物化檢視（MV ）等功能，自動、實時、對使用者透明地執行一些複雜的ETL 過程，以及對維度表和事實表的資料維護。Greenplum 是一種成熟的MPP 架構的分散式資料庫，提供了豐富全面的功能，並且效能優良，比較適合當作實時資料倉儲的資料儲存、資料處理和資料查詢引擎。作為資料庫管理系統，還可以利用Greenplum 統一管理後設資料。

圖1-10 所示架構具有門檻低、上手易、實施快的特點，整個構建過程只需要適當安裝配置相關的軟體，再利用SQL 即可完成，不需要其他任何程式設計工作。當然，從來沒有完美的架構，只有適合的解決方案。本架構明顯的一個侷限是隻能處理MySQL 一個資料來源，而且始終以資料庫提供的功能為核心。如果涉及非常複雜的處理邏輯，可以引入類似Flink 的實時計算引擎，並在其上開發自己的應用程式是更好的選擇。

本文節選自《 Greenplum 構建實時資料倉儲實踐》，內容釋出獲得作者和出版社授權。