實時數倉是一個產品還是解決方案？

當你直播購物的時候，系統會實時推薦你感興趣的商品，當有新聞事件發生，百度搜尋、微博的熱詞排名會實時更新，當你可能遇到網路詐騙的時候，立馬收到告警電話……這些場景我們並不陌生，而他們背後可能就有實時數倉在提供支援。

近年來，實時分析場景越來越豐富，實時數倉概念變得非常火熱，引發市場關注。IT168&ITPUB策劃了實時數倉系列選題，與業內專家共同探討新技術、新趨勢、新應用。本文為其中一篇，採訪嘉賓是公眾號【資料社】主理人資料一哥，他是大資料資深人士，專注於MPP資料庫研究、流處理計算、資料倉儲架構和資料分析領域。

實時數倉是一個產品還是解決方案?

資料倉儲大家非常熟悉，在1991年出版的“Building the Data Warehouse”，資料倉儲之父比爾·恩門首次提出資料倉儲的概念，資料倉儲是一個面向主題的，整合的，相對穩定的，反映歷史變化的資料集合，用於支援管理決策。

而對於目前比較火熱的實時數倉，市場還沒有形成共識，並沒有統一的定義。資料一哥認為，實時數倉和傳統數倉都是一個資料倉儲，只是隨著業務變化，針對對不同業務場景提供支援。雖然實時數倉這個概念現在才被提到，但是很早就出現了，經歷了幾個重要的發展階段。

在早期，企業資料量並沒有特別大，實時分析需求沒有那麼高，透過關係型資料庫如Oracle、MPP資料庫等業務庫能夠直接做統計分析，滿足實時分析需求。

到了大資料時代，資料量爆發式增長，大資料技術出現，企業會使用Storm流計算框架支援實時熱點排名等簡單實時計算查詢，但是Storm不能很好支援複雜計算。

近些年出現了Spark和Flink等流批一體計算引擎，現在也有很多資料庫廠商聲稱自己在做實時數倉。

在過去，由於業務人員實時分析需求不迫切，且存在技術限制，企業會使用Hive、其他OLAP資料庫離線跑批，業務分析只能做到T+1，即前一天的資料到第二天再進行分析展示，現在很多業務場景也是如此。隨著實時業務需求推動，實時資料增多，實時計算技術不斷髮展，Storm、Flink等實時流計算引擎逐漸發展起來，實時計算框架由原來的流批分離的Lambda架構，發展到流批一體的Kappa架構，且新的架構也在不斷湧現。

“可能往後實時數倉更偏向一個解決方案。不同行業不同業務場景，對實時數倉有不同選型。”資料一哥說，離線數倉與實時數倉都是資料倉儲，離線分析一般會對大資料量進行批次處理，而實時一般會從大資料量中選小資料量進行處理。現在可以看到有不同的資料庫廠商，包括一些開源的OLAP廠商，都說自己能夠做實時數倉，不同的業務場景下都有各自的優勢。

目前市場上見到的實時數倉更多是一個“資料倉儲+流計算引擎”的解決方案組合，而非單獨的數倉產品，比如阿里雲提供Hologres+Flink實時數倉解決方案，星環科技提供ArgoDB+實時流計算引擎Transwarp Slipstream實時數倉解決方案，偶數科技由OushuDB+Lava組合成實時湖倉方案等。據瞭解，也有資料庫廠商正在嘗試將流處理內建到資料庫中提供實時處理能力。

業務需求與技術發展是一個螺旋上升的過程，實時數倉的發展也源自實時業務需求的推動，那麼現在實時數倉有哪些應用場景?在哪些行業應用較快?

實時數倉應用場景有哪些?

資料一哥介紹，實時數倉有一些典型的應用場景，比如實時Top排名、熱詞展現，在百度熱搜、微博熱詞中可以看到;實時告警監控，如物聯網方面，特別是現在火熱的新能源汽車，電池不穩定，對電池使用提供預警等;實時推薦，比較常見，如現在火熱的電商直播推薦。或者在一些購物平臺點選某些商品後，微信朋友圈可能會出現實時推薦廣告等;金融反欺詐，近兩年國家在大力推行網路防詐騙，銀行反欺詐實時預警是實時數倉的一個重要應用場景。

以火熱的電商直播為例，在今年火山引擎原動力大會上，位元組跳動副總裁楊震原介紹，抖音電商實時需求場景非常多，業務活動的頻次很高。需要在不斷爆發的需求之下，保證資料支援能夠很實時地完成，火山引擎實時數倉為抖音電商提供了實時大屏、實時分析、實時預警、實時營銷的全套實時資料。

“實時數倉挺火，但是應用場景可能沒有那麼多。”資料一哥認為實時數倉整體上還處在初級發展階段，即便是一些中大型企業，實時業務場景也不是很多，有的企業可能沒有專門的實時數倉技術團隊，或者團隊規模很小，幾十甚至上百人做離線數倉，只有幾個人做實時數倉。而中小型企業，由於資料量沒有那麼大，使用關係型資料庫或者MPP資料庫便可以進行實時統計分析，無需進行復雜計算，可能不需要運用Flink這樣的實時計算引擎，或者某些大廠宣稱的實時計算框架。

據資料一哥瞭解，實時數倉在不同行業的落地也參差不齊。整體來看，實時數倉在網際網路行業發展最快，佔有先機，因為一方面技術儲備充足，網際網路企業有大量的相關技術人員，另一方面，組織架構有優勢，傳統行業技術選型需要在流程上層層審批，網際網路行業架構更為扁平靈活。但是目前很多網際網路企業建設實時數倉，都是在進行技術預研或者創新嘗試，並不一定會立馬應用到業務場景中。

另一個對實時數倉應用比較靠前的是金融行業，因為在金融行業有政策監管等多方面的需求，實時分析是剛需，所以實時業務場景應用比較靠前。另一個對實時要求較高的是新能源電動汽車對資料實時收集，除了企業自身需求，還包括國家監管要求，要求對汽車實時資料進行監控。

在大部分傳統企業，目前對實時分析的需求並沒有那麼明顯。這些企業更多使用離線數倉，就像傳統的BI，甚至並不急於知道前一天的資料，只需要針對過去一年的資料分析預判未來一年的趨勢，助力公司決策。

實時數倉選型與落地

資料一哥介紹，在實時數倉選型時，企業會關注以下因素：一是資料同步實時寫入能力，將源端資料同步過來;二是對複雜業務、複雜事件支援。如Storm以前也可以做實時分析，但無法很好支援複雜計算，所以現在用Spark、Flink進行實時處理;三是能做到實時計算的“Exactly-once”，只計算一次，計算多次就會出現計算重複，實時計算與批計算不同，需要對每個操作進行狀態記錄;四是，運維成本低;五是穩定性，需要保證業務穩定性。

不過，資料一哥發現，目前有不少企業在應用實時數倉時採用一些開源元件自研，而不是購買第三方產品或解決方案。因為自研能夠更加靈活應對企業自身的業務需求。但是自研也不是完全從頭創新，企業會借鑑其他廠商成熟的落地方案，結合自己的應用場景，對企業量體裁衣，打造合適的資料展示平臺。特別是近兩年，受疫情以及外部環境影響，很多企業都在降本增效，對於研發等IT投入變得越來越謹慎。

此外，實時數倉在企業的落地與其原有技術棧有很大關係，如果企業沒有相關技術儲備，重新引入一個新的技術體系，會產生很高的成本。比如他所在公司原來使用Spark進行批處理，後來進行實時分析時使用Spark進行流批一體處理，並沒有引入Flink這樣新的實時計算引擎。

需要指出的是，雖然Flink和Spark都是流批一體計算引擎，但是二者的實時資料處理並不相同，Flink與之前的Storm一樣是事件驅動，像水龍頭流水一樣24h不間斷處理，也有人指出像自動扶梯。而Spark是時間驅動將任務進行“微批處理”，相當於電梯，一定時間內處理一部分資料，只能用於一些對於時延要求不是很高的流處理業務。據悉，Spark能夠達到亞秒級，也能滿足很多實時業務場景。

隨著實時資料產生的價值越來越多，未來實時數倉的應用也會更廣泛深入，企業需要結合自身發展需要選擇合適的解決方案。

資料一哥認為實時數倉未來會有以下發展趨勢，一是雲會是實時數倉的重要發展趨勢，公有云可能更有成本優勢。二是，統一技術棧，實時與離線技術棧走向統一，比如企業原來使用Spark做離線計算，未來可能也會使用Spark做實時計算;三是統一資料入口與出口，避免離線與實時統計結果不一致。

而實時數倉想要加速落地，除了增強技術能力，更加簡單易用，還需要建設更完善的技術生態。“技術想要推廣，想要應用發展，生態是很重要的。”