由紛爭到融合，實時數倉演繹“戰國時代”

群雄並起，諸侯紛爭，實時數倉今天的發展現狀，像極了“戰國時代”。

如果說，戰國是齊、楚、燕、韓、趙、魏、秦七國實力比拼;那麼，與之類似的實時數倉，是流批一體、湖倉一體、雲數倉、HTAP資料庫等多種技術路線並存。不同的是，戰國是亂世，霸主們為生存而進行了一系列探索與努力，英雄大多以悲劇收場;而實時數倉則恰逢數智化盛世，在追求資料處理速度這條道路上，催生出百家爭鳴。

星星之火

所謂 “天下大事合久必分，分久必合”，資料倉儲經歷30多年的發展後，開始出現分裂，以高吞吐、低延時、全鏈路實時加工為主要特徵的實時數倉，誕生於大資料時代，並以星火燎原之勢向網際網路、金融、遊戲、電商等領域蔓延。

事實上，實時數倉雖然是新提法，但不是一個新需求。PostgreSQL ACE Director、南京基石資料技術有限責任公司CTO 白鱔(徐戟)，在接受IT168&ITPUB 實時數倉系列專訪時表示：早在20年前，在設計新一代金融交易系統時，就有人想基於客戶畫像提供個性化服務，包括可以基於歷史資料進行分析，瞭解使用者登入系統時的位置、時間、上網方式等，但那個時候受技術條件限制，無法做實時的指標分析。

那麼，30年前的技術條件是什麼水平呢?歐冶雲商股份有限公司首席資料架構師 薛曉剛 ，則以儲存為切入點，說明實時數倉的快速發展，是技術和業務雙重推動的結果!

2000年左右，當時是1.44寸軟盤。那個年代，硬碟驅動器只有1個G，讀取速度也比較慢，只有4.5MB/秒。之後，隨著儲存技術的進步，出現了隨身碟，1TB級別的磁碟驅動器，再正常不過，但資料傳輸速度依然滿足不了需求，只有 100 MB/s左右，這意味著使用者需要花費半個小時以上的時間，才能讀取整個驅動器的資料。

此種背景下，谷歌在2003年發表了三篇論文：分別是《GFS》(大型分散式檔案系統)、《MapReduce》(大型叢集海量資料處理分散式程式設計模型)、《BigTable》(結構化資料分散式儲存系統)，標準著大資料時代來臨。但從硬體角度看，以hadoop為代表的離線分析，還處於磁頭尋道的階段，透過分散式計算可以“變道超車”，改變之前磁碟IO慢的問題。

如今，隨著硬體及其相關技術的發展，我們已經跨越GB級磁碟階段，單盤SSD已經出現幾十個TB級別的產品，IO的瓶頸不再那麼明顯，處理速度已經提升了萬倍，資料處理量可以是TB級別，甚至出現了非易失性記憶體。

當技術條件足夠成熟，企業可以線上處理TB或PB級資料，過去那種離線分析模式很明顯已跟不上時代。尤其在數字化轉型過程中，企業需要對市場做出快速反應，不管是報表分析(實時資料大盤)，還是使用者畫像(推薦)，都會有時間要求。對於後端支撐的資料倉儲來說，線上交易完成後，企業可以馬上將這些資料進行分析和處理，結合交易快速得出一些判斷，進而輔助業務決策，這便是實時數倉最初誕生的 “搖籃”。

尋求新秩序

問題是，實時數倉到底是什麼?是一款產品，還是一個解決方案?實時數倉系列專訪調研了諸多專家、使用者和服務商!

從梳理結果來看，有人說是一款產品，比如：阿里雲提供的Hologres;有人說是一套解決方案，比如：星環科技的ArgoDB+ Slipstream，透過“混合架構+統一計算引擎+統一儲存管理”形成了一整套方案。與此同時，還有一個方向，看上去不是純粹的數倉產品或者解決方案，比如：滴普科技的FastData DLink，是透過“標準分層+流計算+批次計算+資料湖”實現了湖倉一體;另外，有很多企業則透過HTAP資料庫這種混合架構，滿足實時數倉的業務需求，比如：亞信的AntDB資料庫、天雲資料的Hubble資料庫，走的都是HTAP路線。

除了阿里雲，還有騰訊雲、金山雲等這類雲數倉，則透過雲原生、存算分離、無伺服器的形式，實現了資料實時處理目標。包括很多國產資料庫，也已經融合了Flink、Spark這樣的計算框架，資料過來以後，可以實現行存和列存的自動轉換。

最後一個梯隊，傳統數倉此刻也不會被“立刻革命”，在沒有實際 CDC 功能的場景下，傳統數倉一般基於 Kafka 裡的流式資料生成 ODS、DWD、DWS 的各層資料，以便於查詢實時的資料，同時以小時/天粒度修復ETL資料管道，這種近實時以及準實時數倉解決方案，也可以滿足部分使用者的需求。

業界有一種說法是，企業IT領域紛繁複雜，概念多到可以超過時尚行業。從實時數倉概念火爆，到真正在企業場景落地，每個人都有自己的看法，短期內無法達成統一。但任何事物的出現，都不是一蹴而就，如果單純從數倉發展來看，我們可以概括出幾個重要階段。第一，數倉階段;第二，大資料階段;第三，大資料和MPP資料庫並存的階段;第四，以 Snowflake為代表的雲數倉，近似於實時數倉這樣一個概念;第五，Databricks重新定義了湖倉一體的概念，即圍繞數倉的能力，打造出全新的實時數倉的狀態;第六，流批一體階段，使用者可以基於一套架構解決流和批的場景問題，進而滿足複雜業務需求。

整體來看，雖然各家技術路線不同，短期內無法實現統一，但最終目標一致，那就是讓企業的資料分析變得更快、更易用。一般來說，實時數倉的資料展示能力都不是T+1天的更新頻率，而是T+1秒，其中秒級響應，也不一定就是1秒，3-5秒使用者也可以接受。我們還發現，大多數實時數倉都是以解決方案的形式呈現，透過很多自研或者開源技術，打通資料的採集、計算、加工處理等不同環節，進而滿足時效性要求。

合縱連橫

當實時數倉遍地開花，各條技術路線之間是怎樣一種關係呢?雖然這一時期的外在表現是“大分裂”，但絕對不是各自為政，而是相互融合!

隨著實時計算技術不斷髮展，Storm、Flink等實時流計算引擎逐漸發展起來，實時計算框架由原來的流批分離的Lambda架構，發展到流批一體的Kappa架構，且新的架構也在不斷湧現。在大資料資深人士 資料一哥 看來，雖然離線大資料架構已不能滿足實時需求，逐漸被新一代資料架構取代，但不意味著離線需求也跟著消失，這也是由Flink的火熱帶出的流批一體架構出現的根本原因。

以快手為例，企業最初也是Lambda架構，擁有成熟的離線計算方案，但缺點是不能滿足實時需求，所以另外引入了一條實時鏈路，這樣導致企業需要提供兩套計算引擎，一個提供Streaming能力，一個提供Batch能力，不同引擎提供的API不同，需要兩套業務開發邏輯，很難保證一致性的計算結果。為了解決Lambda的問題，企業最初透過Bean引入統一的API，但無法解決複雜的流批一體場景。之後，企業引入了Spark，透過批來模擬流，以達到實時計算目標，但無法滿足極致的實時計算需求。之後，Flink成為流計算引擎的事實標準，快手進行了大膽嘗試，率先在機器學習和資料整合場景引入Flink Streaming，最終實現了計算和儲存引擎的統一，透過流批融合提供一致性體驗。

同樣，湖倉一體、HTAP都是混合架構下的典型模式，包括MPP資料庫和雲數倉，其實也在相互融合，滿足特定場景需求。目前，HTAP已經是很多國產資料庫的標配，很多人甚至認為HTAP是解決實時數倉問題的有效手段。至於，是不是真的做到了，我們還需要拭目以待。另外，湖倉一體、雲與AI的結合，都是實時數倉走向開放式架構的典型特徵，最終誰能具備更快的資料加工能力，在短時間內滿足使用者的資料消費需求，誰就能贏得市場。

需要重點強調是，諸多技術路線，各有優勢，也會有缺點。但既然是實時數倉，首先線上交易就要達成實時，否則和離線相比沒有太多優勢。其次，要具備統一的儲存能力，如果儲存問題不解決，最終也會影響資料分析結果。其三，實時數倉考驗的是強大的運算處理能力，如何將資料更好地進行運算和處理，是實時數倉落地過程中必須要面對的問題。

最後，針對不同技術路線，不同使用者是如何一步步落地的，我們需要結合具體的業務場景進行嘗試和探索，為了尋找更多“燈塔”類使用者，尋找行業優秀解決方案，IT168&ITPUB搭建了實時數倉選型指南專區(實時數倉選型指南-ITpub)， 最終我們梳理出近十家客戶的實踐案例，和近二十家服務提供商的解決方案，並且未來還會持續更新，希望能為企業和使用者搭建良性互動和溝通平臺，以推動實時數倉走向更高階段。

透過實時數倉變法圖強， 2023精彩還在繼續，《實時數倉選型指南》將以電子書的形式，推送給更多行業使用者，具體內容敬請期待!