基于Flink的實時數倉搭建秘訣 |附課件下載√
分享嘉賓：個推數據部資深數據研發工程師 羅揚（筱得）
個推TechDay"治數訓練營"系列直播課第二期舉辦。來自每日互動（個推）的資深數據研發工程師為大家詳細解讀了實時數倉架構演進，分享了實時數倉的技術選型要點，并結合實戰案例詳細剖析實時數倉搭建秘訣。
課件下載
關注個推技術實踐微信公眾號，
后臺回復"實時數倉"，
獲取本期直播課件~
直播回顧
當下，企業的實時計算需求越來越高頻。比如很多企業在建的實時數據可視化大屏就是很典型的實時計算場景：大屏數據實時刷新，展示最近一分鐘甚至半分鐘內的交易額。類似的實時計算場景還有很多，比如智能算法推薦、系統風險預警、實時特征工程等。
而以往的離線數倉具有高延時性，數據時效性一般為T+1，調度頻率也是以天為單位，無法滿足這些場景的數據時效性要求。所以，實時數倉便成為很多企業的大數據架構選擇。
何為實時數倉？
關于實時數倉，目前行業內還沒有一個標準的定義。我們可以從以下幾個方面來理解"實時數倉"：①實時數倉主要支持實時數據處理，并能夠根據業務需求提供實時數據。②實時數倉的整個數據鏈路均采用實時的方式，包括數據歸集、加工處理、數據分發等各環節。③另外，實時數倉的數據生態也采用實時方式，比如數據建設、數據質量、數據血緣、數據治理等。
數倉架構演進
從經典數倉架構到離線數倉架構，再到能支撐實時計算場景需求的Lambda和Kappa架構，數倉架構也經歷了較長的演進過程。
數倉架構演進
這里著重介紹一下Lambda架構和Kappa架構。
Lambda架構其實是在離線數倉架構的基礎上，新增了一條實時鏈路，用于支撐低延時業務場景的計算需求。與此同時，離線計算（批處理）鏈路仍然存在。也就是說，Lambda架構采用實時和離線兩條鏈路。由于同一部分業務代碼需要有兩套邏輯支撐，所以Lambda架構的后期維護比較復雜，對資源的消耗也比較大。
基于此又迭代產生了Kappa架構。Kappa架構在Lambda架構的基礎上進行了優化，刪除了Batch Layer（批處理層）的部分，將數據通道以消息隊列進行替代，使用同一套邏輯進行離線和實時任務的計算。不過，目前Kappa架構還不是非常成熟，仍存在一些無法解決的問題。
鑒于Lambda架構和Kappa架構都存在一些缺陷，目前很多企業將兩者相結合，采用Lambda+Kappa的混合架構進行數倉建設。比如，針對大部分實時指標，企業仍然使用Kappa架構進行計算；針對少量關鍵指標（比如金額相關），則使用Lambda 架構的批處理模塊重新計算，增加一次校對過程，以此確保數據的時效性和計算結果的準確性。
實時數倉技術選型
目前主流的實時計算引擎有Storm、Spark和Flink。如下圖，每個計算引擎都有其特性。
各實時計算引擎特性對比
我們建議綜合考慮延時和實時場景需求等方面因素，來進行計算引擎的選型。
1. 延時
如果對延時要求較低，可以使用Spark Streaming。Spark Streaming的API非常豐富，并且吞吐量高。此外Spark已經發展較長時間，其生態體系也比較成熟。
如果對延時要求高，則推薦使用Flink。Flink的API也是相對比較豐富的，而且目前Flink社區非常活躍，尤其是在中國，其相關生態迭代迅速。
Structured Streaming也能夠滿足低延時需求，但是其目前的使用率還比較低，生態迭代發展較慢，相對來講不是非常成熟。
2. 實時場景的要求
如果企業需要支撐一些比較特殊的實時場景需求，比如窗口、Watermark等，我們比較推薦Flink。Flink對實時場景的支持已經非常完善了。相對而言，Storm的優勢不明顯，且整體較為陳舊，不是特別建議使用。
實時數倉的建設
和離線數倉一致，實時數倉的建設也采用分層思想：ODS原始層對接原始數據；在ODS原始層之上，對數據進行ETL處理，形成DWD明細層；維度數據比如區域信息，建設成DIM維度層；最終經過數據的分析加工，形成DM匯總層。
下圖是實時數倉的分層設計案例，供參考。
對于實時數倉的不同數據層，直播課程里都介紹了相應的建設核心、建設方法。
1. 對于ODS層，需要使數據來源盡可能統一，并能夠利用分區來確保數據局部有序。
2. 對于DWD層，重點是解決原始數據中存在的數據噪聲、數據不完整和數據格式不統一等情況，形成規范、統一的數據源。在DWD層，除了數據本身，我們還需要為每條數據額外補充一些信息，以應對實時數據生產環節的一些常見問題。比如為了解決重復數據的問題，需要給每一個數據打一個標記，形成"唯一鍵"，來標記微調數據。
3. 對于DIM層，業內一般采用維表關聯等建設方式。
需要注意的是，DIM層的建設要分兩部分來看。一是針對變化頻率較低的維度數據，比如說地域信息等，可以將離線中的維度數據同步到緩存，然后在緩存中進行訪問，或者通過一些公共服務以及維度服務進行查詢；二是針對變化頻率較高的維度數據，比如說一些商品的價格信息，需要監測其變化情況，并創建一張價格變動的拉鏈表。
4. 最后是DM匯總層的建設。這一層主要是對共性指標進行統一加工，同時根據主題進行多維度的匯總等操作。
為了降低計算的延時，實時數倉減少了分層。所以相比離線數倉，實時數倉層次更少。同時，實時數倉和離線數倉分別采用不同的數據存儲方式。離線數倉主要采用Hive，實時數倉主要采用消息中間件，比如Kafka，來存儲明細數據，對于維度數據，實時數倉多采用HBase、MySQL等數據庫進行存儲。
實時數倉的建設過程還是比較復雜的，本期課程還以Flink為例，為大家拆解了基于Flink進行實時數倉建設的全過程。
更多課程詳情
查看直播回放視頻立即GET√
個推技術實戰
Q&A精選
直播過程中，大家就課程內容進行了交流，本文挑選了直播間的精彩提問做了Q&A梳理。
Q1：數據倉庫和數據湖之間有哪些關系？
A：大數據架構從以數倉為主到演變為數倉+數據湖的形式，其實是業務系統越來越復雜、數據量級越來越大、數據種類越來越多的體現。
早期的數據分析需求大多面對的是業務系統的日志數據，為了適應大規模OLAP場景需求以及支持跨業務系統的復雜場景，基于數倉的大數據處理架構逐漸衍生出來。
隨著業務系統的復雜性提升，數據量顯著增加，數據結構也更加多元化，結構化數據、半結構化數據，甚至圖像、語音、視頻等非結構化數據越來越豐富。也許很多數據暫時未得到明確應用，但考慮到數據中可能蘊藏著的巨大潛在價值，企業需要先做好這些數據的存儲，以便后續進行探索和挖掘。
這樣就很自然的出現了一種妥協的解決方案，我們稱之為"數據湖"，即從先進行數據處理后進行數據使用，轉變為：先存儲數據，待到后續想要使用數據時再考慮具體的數據加工處理方式。
"數據湖"架構既節約了前期的數據接入成本，又可以避免因為數據加工造成有價值信息丟失的情況。
綜上，數倉和數據湖面對的是兩種不同的大數據場景，個推目前也是通過將兩者結合，以更好地進行數據價值挖掘。
Q2：實時任務與離線任務如何調度？
A：調度可以大致從任務調度、資源調度、調度框架幾個方面展開說明。
任務調度：目前，無論是實時還是離線引擎，都會將任務劃分為幾個階段（stage）執行。在任務調度機制上，實時任務和離線任務有一定差異。實時程序一般為常駐程序，會在調度階段給每個stage提前分配資源，待所有資源申請好之后開始運行任務。離線程序一般則是按照順序依次調度、依次申請資源。
資源調度：資源調度主要是對集群進行資源分配。離線和實時任務在這方面區別不大，目前主流的方式是采用yarn、k8s。
調度框架：調度框架主要負責任務的啟動、調度、監控。離線和實時任務使用的框架基本一致，常見的有azkaban、dophinscheduler。
Q3：實時數倉的建設過程中有哪些容易讓人陷入誤區的點？建設過程中如何避免呢？
A：首先，沒有一種技術能夠適用于所有的場景，實時數倉的引入在增加數據時效性的同時也會使數據處理的架構復雜性增加。比如在Lamada架構下，企業還需要維護兩套代碼。所以，實時數倉在應用的時候，首先要從業務場景出發，期望通過引入實時數倉來解決哪些問題以及達成哪些目標，需要提前思考清楚。
其次，在很多場景下，實時數倉還會出現數據質量不高、離線實時數據不一致、故障容忍度低等缺點，所以數據開發人員還需要考慮這些新問題可能對業務造成的影響。
總體而言，實時數倉的建設還是要緊密結合公司的真實情況和業務需求，避免投入了很多的資源，無法帶來業務收益，甚至對業務產生干擾。
Q4：Lambda架構和Kappa架構有區分嗎？
A：在數據鏈路、開發成本、技術棧等方面都有較大區別：
數據鏈路：Lambda架構存在離線、實時2條鏈路，而Kappa架構會統一數據鏈路。
開發成本：主流Lambda由于歷史原因不同鏈路會使用不同的計算引擎，如離線采用Spark、實時采用Flink，開發成本較高。而Kappa架構一般會統一計算引擎，開發流程簡化，維護成本較低。
技術棧：Lambda的2條數據鏈路會使用不同體系的組件，如離線采用Hive、Spark，實時采用Kafka、Flink，而kappa架構統一使用實時相關的組件，如Flink、Kafka。
Q5：實時數倉的實時能達到什么級別？
A：實時數倉通過中間件和更少的數據層級來減少數據的處理周期，實時性可以達到秒級、毫秒級。
個推TechDay"治數訓練營"
個推TechDay"治數訓練營"系列直播課程由每日互動（個推）結合自身多年來的數據挖掘和治理經驗特別打造。
匯聚多位優秀大數據架構師的實操方法論，凝結眾多數據開發和數據分析工程師的一線實踐經驗，個推TechDay"治數訓練營"下期更精彩，請大家持續關注~
