轉載/ITPUB 作者任朝陽
當你直播購物的時候，系統會實時推薦你感興趣的商品，當有新聞事件發生，百度搜索、微博的熱詞排名會實時更新，當你可能遇到網絡詐騙的時候，立馬收到告警電話……這些場景我們並不陌生，而他們背後可能就有實時數倉在提供支持。
近年來，實時分析場景越來越豐富，實時數倉概念變得非常火熱，引發市場關注。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做實時計算；三是統一數據入口與出口，避免離線與實時統計結果不一致。
而實時數倉想要加速落地，除了增強技術能力，更加簡單易用，還需要建設更完善的技術生態。「技術想要推廣，想要應用發展，生態是很重要的。」
最後給大家分享一個大數據決策平台構建方案，需要領取。
