聊聊實時數倉架構設計

什麼是實時數倉

首先需要明確什麼是實時數倉，百度百科與維基百科都沒有給出具體說明，哪究竟什麼纔是實時數倉呢？是不是可以通過實時流實時獲取數據就是實時數倉？或者說流批一體就是實時數倉？在或者全面採用實時方式，採集和實時計算纔是實時數倉？這個問題在不同企業可能會有不同答案，有些會認爲提供實時看板或實時報表就算是實時數倉；另外一些可能覺得數倉提供出去數據必須都是實時纔算實時數倉。其實這個問題沒有一個標準答案，不同人、場景、企業對它理解是不一樣的。記得之前有位上司講管理崗與技術崗區別，其中一點是

對待一件事情或需求，T 崗答案都是明確：要麼可以做，要麼不可以做；M 崗的回答看似明確，其實會有多種解讀角度。【這不就是老油條麼，哈哈】

所以從不同角度去解讀實時數倉，對什麼是實時數倉定義是不一樣；一般會有一些幾種定義：

• 具備實時數據處理能力，並能夠根據業務需求提供實時數據的數倉能力，如可以爲運營側提供實時業務變化、實時營銷效果數據。

• 數倉中所有數據，從數據採集、加工處理、數據分發都採用實時方式。

• 從數據建設、數據質量、數據血緣、數據治理等都是採用實時方式。

從中可以看出不同理解，建設實時數倉複雜程度是不一樣。但最終建設一套什麼樣實時數倉還是由業務驅動，需要綜合考慮投入產出。

實時數倉架構設計思路

數據流轉與處理，在實時或者離線數倉基本上都是類似下圖的，因爲分層是一種非常有效的數據治理方式，所以在實時數倉如何進行管理的問題上，首先考慮的也是分層的處理邏輯。

從上圖可以看出，在設計實時數倉方案時，需要對以下幾點進行思考（不是爲了設計出最牛逼技術方案，而是所設計方案是最切合業務場景與資源情況的；有時候牛逼技術方案會加大技術複雜程度與運維難度，會很考驗我們駕馭能力；因此我們選擇的不是技術最牛逼方案，而且最切合我們實際情況方案）：

• 是否數據集成流批一體：離線與實時是否使用統一數據採集方式；如統一通過 CDC 或者 OGG 將數據實時捕獲推送到 kafka，批與流在從 kafka 中消費數據，載入明細層。

• 是否存儲層流批一體：離線與實時數據是否統一分層、統一存儲；如離線與實時數據經過 ETL 處理之後根據統一分層（ODS、DMD、DMS）持久化到同一個數據存儲中。

• 是否 ETL 邏輯流批一體：流與批處理是否使用統一 SQL 語法或者 ETL 組件，再通過底層分別適配流與批計算引擎。

• 是否 ETL 計算引擎流批一體：流與批使用同一套計算引擎，從根本上避免同一個處理邏輯流批兩套代碼問題。

數據集成與存儲層流批一體主要產生以下問題：

• 流處理更容易出現數據丟失，丟失的查詢操作，

• 一般使用消息中間件對流數據進行存儲，消息中間件的存儲特點也決定了，丟失的查詢操作，非常苦難，難以對數。

• Schema 的同步與轉換問題，基於流處理來確保 Schema 保持一致，並且數據不受影響其實並不容易。面對頻繁變動的業務系統，往往維護量會變高

實時數倉架構

根據這幾個是否一體：“是否數據集成流批一體、“是否存儲層流批一體”、“是否 ETL 邏輯流批一體”、“是否 ETL 計算引擎流批一體”，不同流批一體組合會設計出不一樣的實時數倉架構。比較經典的架構有 Lambda、Kappa；還有美團實時數倉架構（實時數據生產 + 實時分析引擎）與阿里的流批一體架構（Lambda+Kappa）。下面分別對這幾個實時數倉架構概括說明。

Lambda 數倉架構

Lambda 有 Batch Layer（批處理）和 Speed Layer（流式處理）。然後通過將批、和流的結果拼接在一起。Lambda 架構具備有數據不可變性質避免人爲引入錯誤問題、支持數據重跑、將複雜的流處理分離出來。而 Batch Layer 和 Speed Layer 由於需要滿足不同的場景，往往會選擇不同的組件。而且，大家寫過 Storm 就會知道，Storm 的代碼寫起來的是挺痛苦的（Trident 會有所改善）。所以，我們需要準備兩套代碼。同樣的邏輯，針對批處理、和流處理要實現兩次。

Lambda 架構問題：

• 兩套架構、各自獨立

• 一種邏輯兩套代碼

• 組件太多

• 數據散佈在多個系統中，互相訪問困難

Kappa 架構

Kreps 提出了另一個維度的思考，我們是否能夠改進，採用流處理系統來建設大數據系統呢？提出完全可以通過建設以流爲核心來建設數據系統。並且，通過重放歷史數據來實現數據重跑。

這種以流處理爲核心來建設數據系統，Kreps 稱之爲「Kappa 架構」。Kappa 和 Lambda 都是希臘字母符號。這套架構遠比 Lambda 架構簡單。就是把原先批處理，改成流處理。它沒有了 Lambda 架構中的 Batch Layer、Speed Layer、以及 Serve Layer。

Lambda 架構問題：

• 大數據量回溯成本高，生產壓力大

• 遺留離線數據數倉的遷移問題，要將成千上萬的 ETL 作業遷往流處理系統，其工作量之大、成本之大、風險之大

• 數據丟失的問題，流處理平臺，數據丟失問題相對於批處理，更容易出現。而且，要進行對數非常困難

實時數據生產 + 實時分析引擎

上圖是美團實時數倉架構設計，數據從日誌統一採集到消息隊列，再到數據流的 ETL 過程，作爲基礎數據流的建設是統一的。之後對於日誌類實時特徵，實時大屏類應用走實時流計算。對於 Binlog 類業務分析走實時 OLAP 批處理。美團實時數倉架構主要是將一些在實時處理面臨的難點，由實時 OLAP 處理。

實時處理面臨的幾個難點：

• 業務的多狀態性：業務過程從開始到結束是不斷變化的，比如從下單 -> 支付 -> 配送，業務庫是在原始基礎上進行變更的，Binlog 會產生很多變化的日誌。而業務分析更加關注最終狀態，由此產生數據回撤計算的問題，例如 10 點下單，13 點取消，但希望在 10 點減掉取消單

• 業務集成：業務分析數據一般無法通過單一主體表達，往往是很多表進行關聯，才能得到想要的信息，在實時流中進行數據的合流對齊，往往需要較大的緩存處理且複雜。

• 分析是批量的，處理過程是流式的：對單一數據，無法形成分析，因此分析對象一定是批量的，而數據加工是逐條的。

Lambda+Kappa

從上圖可以看出，阿里的實時數倉架構是同時 Lambda 與 Kappa 結合；數據集成沒有使用流批一體，分別通過實時採集、數據同步方式實現流與批數據採集。ETL 邏輯流批一體，實現用戶只寫一套代碼，平臺自動翻譯成 Flink Batch 任務和 Flink Stream 任務，同時寫到一張 Holo 表，完成計算層表達的統一。存儲層流與批是分開存儲，但可以實現流批存儲透明化，查詢邏輯完全一致。

總結

架構設計不是爲了設計出最牛逼技術方案，而是所設計方案是最切合業務場景與資源情況的；有時候牛逼技術方案會加大技術複雜程度與運維難度，需要投入更高成本駕馭它；因此我們選擇的不是技術最牛逼方案，而且最切合我們實際情況技術架構。在實時數倉架構設計時，主要是思考 “是否數據集成流批一體、“是否存儲層流批一體”、“是否 ETL 邏輯流批一體”、“是否 ETL 計算引擎流批一體”；權衡這幾個一體帶來問題，而設計出符合業務場景的實時數倉架構。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/V3PabUcJLvqwKnrmuA3H1g