數據倉庫的趨勢

數據倉庫的建設是“數據智能建設”、“數字化”轉型的一個必要且基礎的環節；從智能商業的角度來講，數據的結果代表了用戶的反饋，獲取結果的及時性就顯得尤為重要，快速的獲取數據反饋能夠幫助公司更快的做出決策，更好的進行產品迭代，實時數倉在這一過程中起到了不 可替代的作用；隨著數據時效性在企業運營中的重要性日益凸現，例如，實時推薦、精準營銷、實時風控、實時監控大屏、實時BI報表等，數據的實時處理能力成為企業提升競爭力的一大因素。

數倉架構的演變

想要了解實時數倉的架構，就不得不從整個數據倉庫的架構演變來進行展開；數據倉庫概念是Inmon于1990年提出并給出了完整的建設方法。隨著互聯網時代來臨，數據量暴增，開始使用大數據工具來替代經典數倉中的傳統工具。此時僅僅以Hadoop技術體系替代了傳統數據 倉庫工具，架構上并沒有根本的區別，可以把這個架構叫做離線大數據架構。

后來隨著業務實時性要求的不斷提高，人們開始在離線大數據架構基礎上加了一個加速層，使用流處理技術直接完成那些實時性要求較高的指標計算，這便是Lambda架構。再后來，實時的業務越來越多，事件化的數據源也越來越多，實時處理從次要部分變成了主要部分，架構也做了相應調整，出現了以實時事件處理為核心的Kappa架構。

離線大數據架構

數據通過離線批量的方式同步進入到數據倉庫中，通過構建數倉分層實現數據的ETL鏈路，最后通過多樣式數據服務完成數據需求的滿足，例如推送至業務端MYSQL、HBase，或者是構建獨立的數據集市DM等。

離線大數據架構示意圖

Lambda架構

隨著實時性需求的提出，為了計算一些實時指標，就在原來離線大數據架構的基礎上增加了一個實時計算的鏈路，并對消息隊列實現數據源的流式改造，通過訂閱消息隊列，以流式計算引擎來完成指標增量的計算，推送到下游的數據服務中去，由數據服務層完成離線&實時結果的合并。

Lambda架構示意圖

Kappa架構是由Jay Kreps提出。這種架構只關注流式計算，并不是取代Lambda架構，除非完全滿足你的使用案例。數據以流的方式被采集過來，實時計算引擎將計算結果放入數據服務層以供查詢?？梢哉J為Kappa架構是Lambda架構的一個簡化版本，只是去除掉了Lambda架構中的離線批處理部分；

Kappa架構示意圖

Lambda和kappa架構都有各自的適用領域；例如流處理與批處理分析流程比較統一，且允許一定的容錯，用Kappa比較合適，少量關鍵指標（例如交易金額、業績統計等）使用Lambda架構進行批量計算，增加一次校對過程。還有一些比較復雜的場景，批處理與流處理產生不同的結果（使用不同的機器學習模型，專家系統，或者實時計算難以處理的復雜計算），可能更適合Lambda架構。

實時數倉解決方案

實時數倉分層架構

為了避免面向需求響應的煙囪式構建，實時數倉也引入了類似于離線數倉的分層理念，主要是為了提高模型的復用率，同時也要考慮易用性、一致性以及計算成本；當然實時數倉的分層架構在設計上并不會像離線數倉那么復雜，避免數據在流轉過程中造成的不必要的延時響應；

實時數倉分層架構示例圖

ODS層：
以Kafka為支撐，將所有需以Kafka為支撐，將所有需要實時處理的相關數據放到Kafka隊列中來實現貼源數據層；

DWD層：
實時計算訂閱業務數據消息隊列，然后通過數據清洗、多數據源join、流式數據與離線維度信息等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加數據易用性和復用性，得到最終的實時明細數據；

DIM層：
存放用于關聯查詢的維度信息，可以根據數據現狀來選擇存儲介質，例如使用HBase或者Mysql；

DWS層：
輕度匯總層是為了便于面向AdHoc查詢或者Olap分析構建的輕度匯總結果集合，適合數據維度、指標信息比較多的情況，為了方便根據自定義條件的快速篩選和指標聚合，推薦使用MPP類型數據庫進行存儲，此層可視場景情況決定是否構建；

APP層：
面向實時數據場景需求構建的高度匯總層，可以根據不通的數據應用場景決定使用存儲介質或者引擎；例如面向業務歷史明細、BI支持等Olap分析場景，可以使用Druid、Greenplum，面向實時監控大屏、高并發匯總指標等需求，可以使用KV模式的HBase；數據量較小的時候，也可以使用Mysql來進行存儲。

這里要注意下，其實APP層已經脫離了數倉，這里雖然作為了數倉的獨立分層，但是實際APP層的數據已經分布存儲在各種介質中用于使用。

基于Flink SQL 構建的實時數倉

隨著業務場景的豐富，更多的實時需求不斷涌現，在追求實時任務高吞吐低延遲的同時，對計算過程中間狀態管理，靈活時間窗口支持，以及 exactly once 語義保障的訴求也越來越多。

科杰大數據實時計算平臺集成當前最新Flink版本，支持元數據管理，任務調度管理，提供完善監控的能力，支持實時SQL模型以及擁有實時計算場景一系列特性，為客戶提供全鏈路的實時數倉技術解決方案。

為什么選擇Flink？

實時計算平臺之所以選擇用Flink替代原有Storm、SparkStreaming是基于以下原因考慮的，這也是實時數倉關注的核心問題：

1.高吞吐、低延時；

2.端到端的 Exactly-once，保證了數據的準確性；

3.可容錯的狀態管理，實時數倉里面會進行很多的聚合計算，這些都需要對于狀態進行訪問和管理；

4.豐富的API，對Streaming/Table/SQL支持良好，支持UDF、流式join、時間窗口等高級用法；

5.完善的生態體系，實時數倉的構建會涉及多種存儲，，Flink在這方面的支持也比較完善。

我們在看看FlinkSql有哪些優勢呢，我們從四方面去看：第一，支持 ANSI SQL 的標準； 第二，豐富的數據類型與函數支持，包括常見的算術運算與聚合運算； 第三，可自定義 Source/Sink，基于此可以靈活地擴展上下游； 第四，使用SQL進行數據處理，技術門檻要低于Jar的開發，批流SQL可以進行有效的快速轉換。

基于Flink的實時數倉數據流轉過程

數據在實時數倉中的流轉過程，實際和離線數倉非常相似，只是由Flink替代Hive作為了計算引擎，把存儲由HDFS更換成了 Kafka，但是模型的構建思路與流轉過程并沒有發生變化；

數據流轉示意圖

數據在實時數倉中的流轉過程，實際和離線數倉非常相似，只是由Flink替代Hive作為了計算引擎，把存儲由HDFS更換成了 Kafka，但是模型的構建思路與流轉過程并沒有發生變化。

元數據管理

元數據是數倉建設必不可少的基礎數據，我們通過元數據來了解數據，但是Kafka本身沒有Hive/GP等傳統數倉組件的metastore，必須自己維護數據schema。科杰大數據實時計算平臺提供了一站式的元數據管理功能支持；我們也提供了元數據的版本維護功能；

Kafka元數據管理

Kafka元數據版本管理

基于WEB的IDE開發

界面化的SQL開發模塊，支持FlinkSql關鍵字自動識別，數據預覽、一鍵引用數據Table等輔助編譯功能，支持代碼版本的回滾，自定義函數UDF的上傳與使用、自動識別代碼拓撲圖、提供作業單機數據調試功能，極致簡化了使用Flink進行數據ETL的過程與難度；

程序設計

任務作業管理

提供一站式全托管的實時任務作業管理能力，可以對實時計算任務進行上下下操作的同時，提供了完善的任務監控支持；

程序管理

可視化集群大屏監控

實時計算平臺提供豐富的Kafka集群數據監控，包括集群監控大屏、主題管理、消費者應用、集群監控和告警功能等，幫助管理者監控和管理Kafka的狀態，對消費者應用數據積壓情況進行及時告警；

監控大屏

寄語

以上是我們依托于科杰實時計算平臺以及多年為客戶提供專業的實施服務與解決方案的經驗總結的實時數倉的建設思路，我們會不斷的完善實時計算平臺，研究更多行業的實時數據需求場景，為各行業客戶持續提供頂級的實時數倉解決方案！ 科杰大數據(www.lzycw.cn)作為領先的數據中臺綜合服務商，已先后在金融、通信、新零售、教育、互聯網領域進行數據中臺的落地與服務，通過賦能企業數字基礎設施，幫助客戶構建數據資產，加速全線業務智能化的實現?？平軐⒊掷m致力于新型基礎設施的構建與服務，以軟件定義大數據能力，以數據賦能組織與行業發展，通過基礎設施的構建與服務助力數字化轉型與數字經濟建設。