實時數倉入門訓練營：實時數倉助力互聯網實時決策和精準營銷

簡介：《實時數倉入門訓練營》由阿里云研究員王峰、阿里云高級產品專家劉一鳴等實時計算 Flink 版和 Hologres 的多名技術/產品一線專家齊上陣，合力搭建此次訓練營的課程體系，精心打磨課程內容，直擊當下同學們所遇到的痛點問題，由淺入深全方位決議實時數倉的架構、場景、以及實操應用，7 門精品課程幫助你 5 天時間從小白成長為大牛！

本文整理自直播《實時數倉助力互聯網實時決策和精準營銷-合一》
視頻鏈接:https://developer.aliyun.com/learning/course/807/detail/13886

近年來，實時數倉是互聯網的熱門話題，主要應用場景主要是在實時決策和營銷等領域，這些領域對資料分析的精細度、實時性都有很高的要求，是走在技術前沿的領域，

業務在線化、運營精細化推動數倉實時化、互動化

我們先看一下過去幾年資料分析發展的一些趨勢，如上圖所示，

可以看到，資料分析基本的趨勢是從批處理向互動式分析、流計算的方向演進，在10年前，大資料更多的是處理規模的問題，通過并行計算的技術處理海量的資料，那個時候我們更多的是在做資料的清洗，資料模型的設計，對分析的需求并不太多，

如今，我們的大資料團隊基本上都變成了資料分析的團隊，對資料模型的沉淀，對互動式分析的支持能力，對查詢回應延遲的支持效率，對QPS的要求都會越來越多，資料分析也并不只是資料存下來再分析，也有很多計算前置，先有邏輯后有計算的場景，比如在雙11的時候，在多少秒有多少成交量，這樣一個典型的場景就不是先有交易資料后有計算量的問題，一定是隨著交易而發生實時計算結果的程序，

因此，互動式分析和流計算幾乎是一個并行前進的程序，這兩種新的場景對背后技術有很多不一樣的要求，批處理更多的是講究并行度，在互動式分析領域里邊，我們開始有很多的預計算、記憶體計算、索引等技術，所以這個也是推動了整個大資料技術的演進，

總結來看，資料分析支撐著越來越多的在線業務，在線業務包括我們任何時候打開手機，手機螢屏里邊推薦的產品、展示的廣告，這些都是需要在幾毫秒之內回傳結果，靠資料智能推薦出來，如果不推薦的話點擊率、轉化率一定非常低，

因此，我們的資料業務在支撐越來越多的在線業務，在線業務對查詢延遲、QPS、精細度都有非常高的要求，這也推動著數倉向實時化、互動化方向演進，

阿里巴巴典型實時數倉場景

在阿里巴巴有很多數倉的使用場景，例如雙11的實時GMV大屏，GMV只是一個結論性的數字，實際上對資料分析師而言，這個作業只是剛剛開始，我們要向下分析，是什么產品，在什么渠道，針對什么樣的人群，以什么樣的促銷手段，達成這樣的轉化效果，有哪些轉化效果沒有達成，等等一系列分析，這些分析其實非常的細粒度，是精細化分析的效果，

分析之后，就會對所有的商品、人群做一些標簽化，通過標簽化我們下一步可以去指導在線的應用去做推薦、分析、圈選等等，所以有很多資料中臺的業務也會產生，

還有一類業務是偏監控類業務，訂單突然抖動、增長，網路質量的抖動，視頻直播的一些監控等，這些也是實時數倉典型的應用場景，

大資料實時數倉體系的“紛繁蕪雜”

過去我們建設實時數倉的時候參考過很多公司，阿里巴巴也是走過很復雜的一條路線，

上方是我畫的架構圖，第一次看的時候挺興奮的，那個時候自己是個大資料架構師，能夠畫出這么多個箭頭是很體現功力的一件事情，但當真正去做這樣一個系統的時候，發現這個系統的開發效率、運維效率非常令人抓狂，

這套系統從左上角演化開始，訊息從訊息中間件收集，之后是一個離線加工的程序，那個時候我們還沒有很多實時的技術，首先要先解決規模的問題，通過離線的加工，我們會把加工的結果集變成小的結果集，存到MySQL和Redis，這是一個典型的加工服務二元化的體系，

通過把資料變成小資料之后，才能對外提供上層的應用，包括報表應用、推薦應用等，之后資料分析需要實時化，光靠這種“T+1”的離線加工不能夠滿足需求，資料越實時越有背景關系，價值越大，這個時候就有很多計算前置的技術被采用，例如Flink，通過Flink直接消費Kafka里的事件，通過事件驅動的方式做計算，由于Flink是分布式的，因此可擴展性非常好，它可以通過計算前置，通過事件驅動的方式，可以把端到端的延遲做到極致，

然后我們會把結果集也存到一個介質里面，通過Flink加工的結果集是一個非常精簡的結構，一般是以kv6結構為主，放在HBase、Cassandra這樣的系統，這樣的系統對上提供的大屏報表是最快的，比如說雙11的大屏，絕對不能等成交幾千萬、幾億條記錄之后再去做統計，否則查詢性能一定無法滿足，因此，我們一開始都會加工成如以每秒每個渠道為粒度的原始資料集，原始資料集在做大屏分析的時候，就可以從一個很大的資料集變成一個很小的資料集，性能達到極致，

現在我們看到有處理規模，有處理速度，這兩者看起來表面上都滿足一定需求，但其實成本也是不小的，如果想要計算足夠地快，需要把計算前置，這樣的話資料模型的靈活度就會減少，因為我們已經通過Flink把所有的資料匯聚成一個結果集了，

例如，如果有些業務邏輯一開始沒有定義好，比如剛開始分析的是某三個維度的聚合，如果后續想分析第四個維度的聚合，由于提前沒有計算好，因此無法進行分析，所以這里犧牲了靈活性，

此時就有一些相比HBase更靈活，又比Hive實時性更好的技識訓被采用，例如ClickHouse、Druid，資料可以實時寫入，寫入之后也提供一定的互動式分析、自助式分析的能力，

我們會發現，資料處理將同一份資料分散在三個不同的介質，包括離線處理的介質，近實時處理的介質和全實時處理介質，三個介質往往需要三個團隊來維護，三個團隊隨著時間發生人員的變動，資料加工邏輯一定會有多多少少的調整，造成的結果就是，我們會發現同一個指標通過三個不同渠道產生的計算結果不一致，這個事情幾乎每個公司都會發生，

這還只是表面的問題，對于分析師來說更痛苦，他需要使用不同的資料，訪問不同的系統，學習不同的介面，甚至是有不同的訪問控制機制，這對分析師來說就非常不方便，因此，很多公司都要搭一套所謂的資料中臺，通過中臺來屏蔽底下物理引擎上的不同，這種情況下Presto、Drill這種聯邦計算技術就會被采用，

聯邦計算技術有著二十多年的發展歷史，從最早期的資料資訊系統集成到資料虛擬化，技術一直在發展，這個技術是一套資料不移動、計算移動的技術，聽起來很美好，但是當真正在生產上使用的時候會發現，這套系統的查詢體驗是不可預期的，我們不知道通過系統查詢下去資料是快還是慢，因為它把查詢下壓到不同的引擎，如果下壓到Hive，就沒那么快，要是下壓到ClickHouse可能就比較快，所以這對一個分析師來說，他不知道這個系統的預期是什么，叫不可預期性，例如，以前打開報表可能用了5秒鐘，另外一次可能用了5分鐘，這種情況會讓分析師不知道到5分鐘的時候是正常還是不正常，如果跑在Hive上，就叫正常，如果跑在Drill上，就叫不正常，不可預期性也讓這個系統很難進入生產的領域，所以這個時候我們不得以，還要是通過資料做一次匯聚，變成小的結果集去分析，
我們看到，整個鏈路實際上是由多個組件層層嵌套、層層依賴組成的，除了剛才提到的不同團隊維護會造成資料口徑不一致的情況，對資料維護的成本也會變得非常高，

經常遇到的情況有，我們看到報表上某個數字可能是不正確的，比如某天這個指標突然增長或下滑很多，這時沒人能確認中間是資料質量出問題，還是加工邏輯出問題，或者是資料同步鏈路出錯了，因為中間鏈路太長了，資料源頭如果修改一個欄位，重新補一個資料，那么每一個環節都要重跑，所以說這套架構如果是運行正常就沒有問題，但是一旦資料質量有問題或者資料調度上出問題，環環依賴，這讓整個運維成本變得非常高，

同時，懂這么多技術的人才難找且貴，經常發生的情況是一個公司辛苦培養出這樣的人才，之后就被其他大廠挖走了，這樣的人才從招聘到培養都非常困難，

以上是這套架構的現狀，

今天大資料的復雜，讓人想起60年代

上面這套架構讓我想起60年代，那個時候資料庫基本還沒有誕生，70年代末期才誕生了關系型資料庫，
60年代我們是怎么管理資料的狀態？

在60年代，每個程式員要自己寫狀態維護，有的人用檔案系統，但是光用檔案系統會非常離散，維護起來也非常難，因為資料之間是有關系的，這個時候還有一些網狀結構的系統出現，通過一個檔案可以跳到另外一個檔案去，但是網路結構管理起來也相對比較復雜，因為回圈、嵌套等等，除此之外還有層級結構，也是一種資料型別的描述方式，
所以可以看到，60年代的程式員自己管理資料狀態，其實成本很高，

到了80年代，我們基本上不會再這么干了，因為我們知道所有的狀態盡量都存在資料庫里，也是因為關系型資料庫讓這件事情變得簡單了很多，盡管我們有很多種關系型資料庫，但基本都是以SQL介面為主，這讓我們整個資料的存盤、查詢、管理等成本急劇下降，

這件事情在過去20年又發生了一些不少變化，從大資料的時代到NoSQL到NewSQL，誕生了各種各樣的技術，如Hadoop、Spark、Redis等，這讓資料領域蓬勃發展，

但是我總覺得這個地方隱含了一些問題，可能未來不一定是這樣，目前大資料發展蓬勃但不統一，所以我在想未來是不是可以把大資料技術相對收攏一些，用一種更有描述性的方式來解決問題，而不是讓每個程式員都去學習不同的組件，學習幾十種不同的介面，配置上千個引數，為了提高開發效率，或許在未來我們有必要將這些技術進一步收攏簡化，

實時數倉核心需求：時效性

我們回過頭看一看，脫離這些技術組件，實時數倉到底有什么業務上的需求，針對這些業務需求可以要求什么樣的資料架構，

什么是實時？很多人認為實時分析就是從資料產生到能夠被分析的時間足夠短，其實這并不完全準確，我認為實時數倉分為兩種實時，一種叫端到端的延遲短，另外一種實時也可以稱為準時，就是當我們真正分析資料的時候，能夠拿到有效的資料，并且能夠得出結論，這就可以叫準時，

第一種實時是偏技術的概念，然而我們的業務一定需要這么低的延遲嗎？

通常情況下，業務并不是每秒鐘都在做決策，業務當我們打開報表，我們看數那一刻，這一刻我們關心的資料可能是過去的一天，上一個小時，5分鐘之前，或者是一秒鐘之前的，但經驗告訴我們，99%的資料分析如果能做到5分鐘的延遲，基本能滿足業務上的資料分析需求，在分析場景是這樣的，如果是在線服務的場景，這肯定是不夠的，

所以大多數公司里也許并不要求那么實時，因為這背后的成本是不一樣的，

因為一旦要的是端到端的延遲，就一定需要很多計算前置的業務邏輯，不能等資料都存下來之后再去查詢，因為要求延遲非常地短，我們必須要把很多資料提前匯聚、加工、拉寬，才能讓資料分析的時候計算量足夠小，才可以做到延遲足夠地短，

所以如果追求的是端到端的延遲，要做很多計算前置的作業，剛才我們提到，如果計算全部前置，靈活性會有損失，所以這件事是有成本的，相對來說，如果追求的是一個準時的系統，那可以把一部分的計算邏輯后置，換取的是一個靈活分析的場景，

例如雙11的時候只是為了追求延時，那我們只會把最后一個GMV存下來，這是一種場景，這事就結束了，但這件事不符合公司要求，公司一定要出詳細的報告，需要知道什么時候賣的好，什么時候賣的不好，所以這種情況下，全部提前預計算的方式肯定是不適合的，需要有更多的明細資料能夠存下來，我們可以做更多的互動式分析、關聯分析、探索式分析，所以說這兩套系統背后的需求是不一樣的，

相對來說，我覺得絕大部分公司要的其實是個準時的系統，它需要具備計算后置的能力，具備實時寫入、寫入即可分析的能力，哪怕分析的效率不是那么高，還要具備靈活分析的能力，

實時數倉核心需求：資料質量

資料質量是實時數倉建設里很重要的一環，剛才提到如果不追求資料質量，只追求時效性的話，一開始通過計算前置加工成一個結果集，這個結果集告訴我們GMV達到了100億，絕大部分老板是不敢相信的，因為這100億背后可能是資料質量出問題，也可能是計算邏輯寫錯了，所以說系統要能夠保證資料質量，

資料質量分兩個方面，一個是多久發現質量問題，另一個是多久修正質量問題，這兩個解決思路是不太一樣的，

如果想發現資料質量問題，就需要讓計算程序的狀態能夠被持久化，就希望資料倉庫引擎里邊能夠有明細，以及匯總資料能夠落盤，這些資料可以被檢查，這樣的話，當老板問指標為什么增長這么多，到底是哪個客戶帶來的增長，你就可以通過這些明細的資料去檢查原因，分析資料時如果發現錯了能否修正，這也是很關鍵的問題，

有些系統只能看不能改，這是很多大資料系統的通病，大資料系統在處理規模性問題非常好，但是處理小的問題，如更正資料就特別地難，因為它每次更正都是需要很大的資料塊為單位，或者是沒有主鍵，將整個檔案替換，所以更新起來確實比較難，

發現問題和修正問題相比，我更希望一個系統能夠具備修正資料問題的能力，

修正問題就是在發現資料質量的時候，可以簡單地更新資料的狀態，比如說單行資料的更新，單列資料的更新，批量的更新等，有很簡單的方式做資料的重繪，資料重繪的狀態這個事情經常會發生，例如上游資料質量有問題，加工邏輯寫錯了等，都需要做資料重繪的作業，

其次，我也希望資料修正的時候盡量能夠只修正一個系統就好，

剛才我們看到，一份資料的資料源出錯了之后，它要在后端4~5個環節反復流轉，這意味著一旦資料出錯了之后，在4~5個環節里面都要做資料修正的作業，這里面的資料存在大量的冗余和不一致，要修正的話每個環節都要修正，這也是特別復雜的一件事情，所以我們希望數倉的狀態盡量只存一個地方，這樣話我只修正一處就可以了，

實時數倉核心需求：成本優化

成本分為三部分，分別是開發成本、運維成本和人力成本，

開發成本表示我們想要業務需求多久能上線，做同樣一件事，是需要一個團隊還是一個人，是需要一周還是一天，所以開發成本是很多公司很關心的一件事情，如果開發不出來，就意味著很多業務的需求是被壓制或者是抑制的，
我們希望IT同學不需要再很疲憊地回應業務團隊取數的要求，經常發生的情況是，等資料真正加工完之后，業務團隊反饋說資料加工得不對，等IT同學好不容易修正對了之后，業務團隊表示活動結束了，想看的資料已經沒有意義了，
因此，好的數倉系統一定是技術和業務解耦，技術團隊保障資料平臺運行的穩定可靠，而業務團隊的取數盡量要自助化，自己通過拖拽的方式生成感興趣的報表，這是我們認為良好的系統，只有通過這樣的方式來降低開發的門檻，讓更多的人自己去取數，實作資料資產的可復用，業務自助開發，

同時，為了加快開發效率，鏈路一定要足夠短，

就像我們一開始看見的架構圖，如果中間四五個環節，任何環節都要配置調度，任何一個環節出錯了之后都要監控，那么開發效率上一定是非常沉重的，如果開發鏈路足夠短，資料減少傳遞，開發效率也會高很多，所以我們要提高開發效率，希望能夠做到技術和業務解耦，也能夠做到資料鏈路足夠的短，

運維成本簡單翻譯過來就是說過去集群太多，花的錢太多，

我們要開四五套集群，反復調度與監控，因此，如果未來有機會重新選型新的數倉，應該考慮如何降低成本，用更少的集群，更少的運維來提供更多的能力，包括一些彈性的能力，公司在月底或者促銷活動這種對計算量分析量有要求的時候，可以做一些彈性的擴縮容，適應不同的計算負載變化，這也是非常重要的一個能力，可以節省公司的運維成本，

第三個成本就是人力成本，包括招聘成本和學習成本，

大資料是一個相對比較復雜的系統，做過Hadoop技術的應該知道，幾千個引數，十幾個組件各自互相依賴，任何節點宕掉都可能會引起其他系統的各種各樣的問題，

其實學習和運維成本都是比較高的，剛才提到資料庫的例子是很好的一個范本，降低開發的成本可以用描述性語言，也就是SQL的方式，通過SQL的方式可以把整個開發門檻急劇降低，絕大部分同學在本科的時候都已經學過資料庫這樣的課程，所以用SQL的方式比那些需要學習API，需要學習SDK的方式更有效率，這樣的話，人才在市場上也更容易找到，也讓公司把更多的精力從底層平臺運維，向上層資料價值挖掘上轉變，

通過標準SQL跟其他系統對接，不管是開發工具還是BI展示工具，都會更加地方便，

以上是從業務需求推匯出來的一些技術需求，

第一代實時數倉：資料庫階段

接下來我們看一下，過去的一些實時數倉開發技術是否能夠滿足以上需求，

第一代實時數倉技術我們叫資料庫階段，是典型的Lamda階段，

這個架構基本是有一個業務需求，就有一套資料鏈路，資料鏈路分為實時和離線兩部分，資料收集到訊息中間件，一部分走實時，加工結果集，存到MySQL/HBase，另一部分離線通過Hive/Flink，加工結果集，也是存到MySQL/HBase，都是把大資料變成小資料，然后對上提供服務，

這套架構已經有很多人分析過問題了，兩套架構互相資料冗余，產生資料不一致，這是比較直接的，但這里更重要的問題是煙囪式的開發，

當業務端提出一個新需求的時候，程式員就要去找這個資料來自于哪個資料源，它應該跟哪些第三方資料源做關聯，要做怎么樣的匯聚加工，然后生成一個結果集，最后我們會發現這個結果集或者是生成的數百張報表端，其中80%的部分互相有很大的冗余部分，有的業務部門看的是這三個指標，另外一個部門看的是其中兩個指標，中間可能只是換了一個欄位，這是經常發生的狀況，原始資料都是一樣的，但是統計的欄位你多一個我少一個，但是我們就要重新端到端去開發，嚴重降低開發效率，運維上也很難，開發了幾千張報表，我們不知道這些報表是否有人在使用，我們也不敢輕易下線，

除此之外，一旦任何一個資料源的欄位增加或減少，都要去調整、運維、修改，這件事幾乎是一個災難，如果是一個人開發那么問題不大，我們見過很多開發團隊，四五個同學每天頻繁寫腳本，然后這些人員有人離職，有人入職，最后誰也不敢刪老同事的代碼，最后就變成調度幾千個腳本，天天在查糾錯，可能是腳本的錯，也可能是資料質量的錯，這件事讓運維成本變得非常的高，

因此，這種煙囪式的開發屬于上手很快，但在實際運維上是不可持續的一件事情，我們解決煙囪式問題的方式是把共享的部分沉淀下來，這就進入實時數倉的第二個階段：傳統數倉階段，

第二代實時數倉：傳統數倉階段

資料倉庫是很好的概念，就是把那些可被復用的計算指標沉淀出來，因此數倉里面要分層，有DWD、DWS、ADS三層，通過層層的沉淀，把共享的部分向下沉，把差異的部分向上移，減少重復建設的問題，這也是數倉經過幾十年沉淀出來的一套基本的方法論，

這種方式通過Kafka驅動Flink，Flink在計算程序中做一些維表的關聯，維表關聯基本上是把Flink關聯到一個KeyValue系統上做維表的拉寬，拉寬之后還會把這個結果重新寫到Kafka另外一個Topic里面，然后做二次的聚合、匯總，生成一些DWS或者ADS，最后把結果存在OLAP/HBase系統，

為什么這地方結果存盤一部分是OLAP系統，一部是HBase系統？

OLAP系統是一個面向數倉分層非常好的表結構，但是這類系統沒辦法支撐在線的應用，在線應用要求QPS每秒上萬的查詢，查詢模式相對比較簡單，但對QPS要求非常高，絕大部分數倉系統是很難滿足這個要求，所以這個時候不得不把系統存在HBase，提供毫秒級回應的能力，

這個系統解決了前面煙囪式的問題，但我們看到OLAP/HBase系統里面仍然存在資料冗余，同樣一份資料，描述同樣一份邏輯，在數倉和KeyValue系統里邊仍有冗余，公司業務團隊會根據SLA的不同進行選擇，如果對延遲非常敏感，就把結果放在HBase里面，如果對延遲不敏感，但對查詢靈活性有要求，會放在 OLAP里面，

另一方面， HBase系統在開發上還是不太方便，因為這是一套結果比較簡單的KeyValue系統，所有的查詢都需要基于Key去訪問，然后Value部分是沒有Scheme的，一旦業務單位發現資料質量有問題的時候，沒有辦法很簡單地檢查看某一個行、某一列的值，不能隨時去協調更新它，這是一個Schema Free系統的一些局限，元資料管理起比較不方便，

第三代實時數倉：分析服務融合階段

實時數倉第三階段是分析服務融合階段，這個階段在阿里內部已經實作，外部絕大部分的公司也在探索的道路，

這個階段跟之前的階段有兩個區別，一方面是在服務端的統一，不管是OLAP系統還是點查系統，通過一個系統統一，減少資料的割裂，減少介面的不一致，減少一份資料在不同系統之間來回傳遞，實作了統一存盤的效果，這讓我們資料狀態的檢查、修正都變得更簡單，介面上統一到一個系統，安全、訪問、控制、應用開發的介面可以一致化，在服務端做了一些優化，

另一方面資料加工鏈路也做了一定的優化，這里面沒有Kafka了，其實有沒有卡夫卡是一個可選項，因為有些系統具備了一定的事件驅動能力，比如Hologres，它具備內置的Binlog事件驅動能力，因此可以把Hologres當做一個Kafka來使用，通過Binlog搭配Flink實作了DWD、DWS、ADS層層實時匯聚，這也是一個非常好的能力，
通過這樣一個架構，組件只剩下Flink和Hologres，中間沒有其他的外部系統，依舊可以通過實時鏈路驅動起來，資料沒有分裂，所有資料都存在資料庫，

關鍵收益是開發鏈路變短了，讓調錯成本也變低，其次是資料的明細狀態被存盤，因為HBase很難存明細狀態，如果服務系統里面存下明細之后，資料查錯、修錯的成本就變得非常低了，除此之外，組件變少，相應地運維成本也降低，

阿里雙11實時業務實踐

阿里雙11就是通過上述方式去做，雙11場景下的吞吐量幾乎是世界最大的，

可以看到，資料通過實時通道走訊息中間件，首先一般是點擊流資料，然后需要通過Flink做一些維表拉寬的操作，點擊流里面記錄了什么ID點擊了什么樣的SKU，這個時候要把SKU作為表達寬，把它翻譯成是什么商品，什么類別，什么人群，通過什么渠道點擊的，把這些維表拉寬之后，存在Hologres里邊，Hologres在這里扮演實時數倉的角色，另外一部分資料會離線定時同步到離線數倉MaxCompute，MaxCompute扮演的是一個歷史全域資料的概念，我們經常會統計消費者過去一段時間的消費行為變化，這部分資料的加工時效性要求不高，但是資料量非常大，是在MaxCompute里執行的，

在分析的時候，Hologres和MaxCompute通過聯邦查詢的方式關聯在一起，所以并不需要把資料都放在一個地方，用戶還是可以通過實時和離線做聯邦查詢的方式減少資料的冗余，

Apache Flink – 實時計算的行業事實標準

Apache Flink 已成為實時計算的行業事實標準，各個行業都在使用，阿里巴巴是這方面的領導者，開源技術背后都有一家成功的商業公司，Flink 背后這家商業公司正是阿里巴巴，

實時計算的部分很簡單，就是 Flink ，但是在倉庫系統的選擇上不太容易，因為選項非常的多，主要可以分為三類，分別是事務系統，分析系統和服務系統，

事務系統就是產生資料的系統，它有很多業務系統，這個系統上不太容易直接做分析，因為直接分析的時候，負載很可能影響在線系統的穩定性，而且性能也無法保證，因為這些系統它是面向隨機讀寫優化的，基本是以行存為主，

對于統計分析類的場景，IO開銷非常大，它基本上是給DBA準備的，保證線上系統穩定性，所以我們做的第一件事就是事務系統和分析系統的分離，把這些資料先做一次同步，同步到分析系統里面去，

分析系統專門為分析做了很多優化，我們會采用列存、分布式、匯總、構造語意層等建模的方式，把分析的資料模型簡化與豐富，然后提高資料分析的性能，這是面向分析師的系統，

另外一個系統叫Serving系統，過去主要是NoSQL，如今還有HBase、Cassandra、Redis，這類系統我也把它認為是一種型別的分析，也是取數，它只是取數相對比較簡單，更多是通過主鍵進行取數，但是這類系統也是通過資料來驅動的場景，更多是支持在線應用，也有資料高吞吐、更新等能力，

可以看到，資料從源頭產生之后，一般有兩個出路，一個是進入分析系統，一個是進入服務系統支持在線應用，我們會發現資料其實在不同系統里產生了很多的割裂，之后就意味著資料的移動，資料的搬遷，資料的依賴，介面的不一致，此時我們開始想辦法做創新，

第一個創新是在服務系統和分析系統的邊界處，我們思考一個系統是否既可以做分析又可以做服務，這個想法比較理想但在有些場景下確實也是適合的，

但是這樣的系統也有一些限制，第一個限制是系統的底線要保證事務，事務是對計算能力開銷非常大的一件事情，可以看到絕大部分分析系統不支持事務，因為事務要帶來很多的鎖，如果有分布式鎖的話，開銷就會變得更大，所以這類系統具備了一定能力，但也犧牲了一部分的性能，因此在高并發場景下并不太適合，

另一個限制是資料模型上的不適合，在TP上產生的表可能有幾百張，但是分析師不愿意去看幾百張的表，他更愿意把幾百張的表匯聚成幾張大的事實表和維度表，這樣的方式更符合分析語意層的要求，

綜上所述，這個系統很難做到資料模型上既能適合TP系統，又能適合AP系統，所以我覺得HTAP系統的局限性比較大，

另外一端的創新是，我們思考一個系統是否既可以支持分析的場景，查得足夠靈活，又可以支持在線服務的場景，支持高并發，支持快速的查詢，支持資料的可更新，這也是很重要一個場景，

如果用一個系統支持這兩個場景的話，就會讓我們資料遷移、資料開發的成本又降低了很多，

我們看到這兩個創新系統里很多共性的部分，比如資料基本以只讀為主，基本沒有鎖的要求，都需要資料被加工、抽象，可以看到這里定義的分析系統和服務系統的共性是非常大的，有機會做創新，

常見實時數倉架構選型參考

接下來我們看一下 Flink 和市面上常見其他的數倉技術組合做實時數倉，從各個維度進行性能分析，

例如MySQL的系統，它提供很好的介面，MySQL開發起來比較方便，支持各種函式也多，但實際上它的可擴展性、資料的靈活性都會差很多，因為Flink加上MySQL就是把資料變成一個結果集來使用，缺少很多的中間狀態，資料需要搬遷，修正成本非常高，

我們繼續思考，MySQL擴展性不好，HBase擴展性非常好，它可以處理很大資料規模的問題，但HBase資料重繪的能力比較弱，想隨時更新某一行/列的資料的話不太方便，模型靈活度不太好，因為它基本上就是KV系統，如果不是按照Key去查就很不方便，

接著是最近幾年非常火的ClickHouse，它查詢速度非常快，非常適合寬表的場景，資料分析如果只有寬表是可以，但是我們知道資料分析光靠一張寬表往往是不夠的，需要很多表的關聯、嵌套、視窗計算，所以ClickHouse對于這種場景就有些勉強，ClickHouse不支持標準的SQL，很多的函式、關聯操作都不支持，特別在表關聯的場景下，性能下降也是比較明顯，除此之外，ClickHouse在元資料管理上也有很大的局限，它缺少一個分布式的元資料管理系統，所以在運維上成本還是比較高的，

除此之外還有資料湖的一些技術，Flink 加上Hudi/Iceburg，它給大資料平臺提供了一定的資料更新能力，還依舊保持資料規模性的問題，因此我們說它在資料修正問題上表現較好，但在查詢性能上，這類系統確實沒有做過多的優化，因為要把性能做得好，則需要一定的索引，需要跟查詢引擎做足夠多的深度優化，Hudi/Iceburg基本還停留在存盤層的可更新能力上，更多的還是在元資料管理上的優化，所以在性能上比較一般，

最后是Hologres，相對來說它在資料模型靈活度、分析自助性、可擴展性、資料修正能力、運維能力等方面表現優異，是一個不錯的系統，它支持完整表的Scheme，用戶可以做任意表的連接/嵌套，也支持秒級的查詢回應，

如果是應用在線的系統，要求上萬、上十萬的高QPS回應，Hologres也是可以支持的，除此之外，它是一個完全分布式可擴展的架構，可以隨著負載變化彈性伸縮，資料支持靈活更新，直接使用SQL的Update、Delete做資料的更新，它是一個托管的服務，彈性伸縮能力都是通過白屏化的界面進行操作，所以運維上是比較簡單的，開發上就是一個標準SQL介面，所以會寫JDBC、ODBC的程式都可以拿來做開發，

綜上所述，我覺得Hologres具備了其他系統的優勢，也彌補了一些不足，是目前比較推薦的實時數倉架構選型，

下一代大資料數倉理念HSAP：分析、服務一體化

HSAP：Hybrid Serving & Analytical Processing

Hologres的設計背后一個理念叫HASP，就是同時支持Hybrid Serving和Analytical Processing兩種負載，希望做到統一存盤，在資料寫入的時候，不管是批量寫入還是實時寫入，用它可以使得寫入效率足夠的高，

其次，物件服務的時候統一服務介面，不管是內部互動式分析的場景，還是在線點查的場景，都可以通過同樣一個資料服務介面輸出，通過把這兩個場景融合在一起，提高開發效率，

• Hologres = Better OLAP + Better Serving + Cost Reduced

Hologres，隸屬阿里自研大資料品牌MaxCompute，云原生分布式分析引擎，支持對PB 級資料進行高并發、低延時的SQL查詢，支持實時數倉，大資料互動式分析等場景，

在我們的定義中，Hologres是一個更好的OLAP，過去OLAP系統查得足夠快、足夠靈活等特點，這個系統必須要具備，

其次它是個Better Serving，過去點查系統高吞吐的寫入、更新、查詢、10萬以上的QPS等能力，這個系統也可以支持，

Cost Reduce并不是表示這個系統一定很便宜，而是指我們的學習成本、運維成本通過這個系統可以急劇下降，這些都是我們給系統帶來的收益，

云原生實時數倉解決方案：實時計算 Flink 版 + Hologres

在架構層面上，它是一個比較靈活的架構，

資料實時接入進來之后，把加工層分成兩個環節，一個叫明細層加工，一個叫匯聚層加工，

明細層加工的時候也是做清洗、關聯、轉換，通過Flink來完成計算，加工完之后就可以把明細結果直接存下來，如果處理的是訂單資料，這樣基本就可以了，因為訂單資料的資料量在千萬規模的公司已經算是比較大的體量了，

這類明細資料直接對外提供報表服務，不需要做很多的二次匯聚加工，在清理加工的程序中經常會做維表的關聯拉寬，這類點查場景在Hologres里邊也是非常適合的，過去用HBase/Redis做的事情，在Hologres里邊建一張表就可以完成，在明細加工階段，既可以通過行表做拉寬，又可以用明細資料存下來，一讀一寫兩種場景都可以支撐，

如果是行為資料、點擊流資料的話，資料量往往更大，資料價值度更低，這個時候全存明細的話，分析效率比較低，此時可以去做二次的匯聚預加工，加工成一些輕度匯總層，就是輕度加工成DWS層，可以存下來也可以繼續加工到ADS層，針對某個業務場景加工成一張最終的ADS結果集，也可以存下來，這類場景變成更小的資料，可以支撐更高的QPS，

因此對上來說，這個數倉系統給我們提供更多的靈活性，做互動式分析盡量存明細，做在線點查的話，就把這個表加工成一個可以按照主鍵進行查詢的一個表即可，這給開發帶來很多的靈活性，

加工也并不一定都是通過流計算的方式，有些情況下也可以通過資料存檔明細資料，在資料庫里邊和做批量的調度都可以再繼續做二次的匯聚預加工，

實時數倉場景1：即席查詢

Hologres里定義了三種實作實時數倉的方式，第一種叫即席查詢，

即席查詢就是那種不知道查詢模式是什么樣子，反正先把資料存下來，然后提供盡量多靈活性的場景，

因此，此時我們就會建議，盡量把操作層（ODS層）的資料經過簡單的資料質量的清理、關聯，然后存到明細資料即可，先不做過多的二次加工匯總，因為此時應該怎么分析資料都不太明確，可以通過視圖封裝，建很多View的方式，對外提供服務，

View是對邏輯做很好的封裝，把底下表的關聯、嵌套等復雜計算提前封裝起來，但這個時候沒有提前做固化，這樣的話原始資料如果有任何的更新，我們隨時重繪一層資料，只更新一個地方的資料即可，不需要把上面所有的匯聚表更新，因為上面沒有匯聚表，匯聚的是視圖，

因此，這種計算的靈活度非常高，但它的查詢性能不一定是最好的，因為視圖計算量非常大，每次查視圖的時候都要對底下的原始資料做關聯、嵌套，所以計算量相對比較大，適合對QPS要求不高，對靈活性要求比較高的場景，

實時數倉場景2：分鐘級準實時

第二種場景叫分鐘級準實時，這種場景跟剛才相比，對QPS要求更高一些，查詢相對更加固化，

此時，我們就會把剛才那些視圖的部分，我就會把它物化成一張表，邏輯還是剛才的邏輯，但是變成表了，變成表之后，查詢的資料量就會小很多，提升查詢性能，這也是比較簡單的方式，可以通過DataWorks的調度程式，用分鐘級調度也可以實作準實時，5分鐘或者10分鐘生成一個調度批次，能夠滿足絕大部分公司的業務場景需求，

通過這套方式，開發變得非常簡單，任何環節、任何資料有錯誤的時候，只要DataWorks調度重新運行就可以，運維也變得非常簡單，

實時數倉場景3：增量資料實時統計

還有一些場景對資料延遲非常敏感，資料產生的時候必須就加工好，此時通過增量計算的方式，提前用Flink將明細層、匯總層等層層匯聚，匯聚之后把結果集存下來再對外提供服務，這就是增量計算的方式，

跟傳統增量計算方式不一樣的地方是，我們建議把中間的狀態也持久化下來，好處是提升后續分析的靈活度，以及修正資料差錯的成本會急劇下降，這也是我們看到很多公司在用的方式，以前把資料通過Kafka Topic串起來全實時，一旦中間資料質量有問題的時候，Kafka的資料很難修正，也很難檢查哪里的資料有問題，查錯成本非常高，

把每一條Topic資料同步到Hologres之后，一旦資料有問題，它在表資料庫里邊對這個表進行修正，然后在資料庫里通過資料進行重刷，實作資料的修正，

Hologres實時數倉場景3個場景選擇原則

在實際業務中，我們可以根據不同的情況做選擇，Hologres實時數倉場景3個場景選擇原則如下：

• 如果純離線計算，優先MaxCompute；
• 如果實時需求簡單、資料量不大、只需要增量資料即可統計結果，適合場景3：增量資料實時統計；
• 如果有實時需求但是實時性要求不是很高，但開發效率優先，優先走分鐘級準實時方案，適合場景2：分鐘級準實時；
• 實時要求非常高，即席查詢需求，資源較為充足，適合場景1：即席查詢，

阿里客戶體驗系統(CCO)數倉實時化改造

CCO服務運營系統：數字化運行能力決定了消費者和商家的服務體驗，

阿里客戶體驗系統(CCO)實時數倉改造

實時數倉經歷了資料庫->傳統資料倉庫->實時資料倉庫三個階段，

• 業務難點：
  1）資料復雜度高，加購、下單、支付、售后全渠道，90%實時資料；
  2）資料量大，日志（千萬/秒)，交易（百萬/秒)，咨詢(萬/秒)；
  3）場景豐富，實時監控大屏，實時互動式分析資料產品，ToC線上應用，

• 技術架構:
  DataHub + 實時計算 Flink 版 + Hologres + MaxCompute
• 收益:
  1）整體硬體資源成本下降30+%；
  2）高吞吐實時寫入：支持了行存千萬/秒，列存幾十萬/秒寫入要求；
  3）簡化實時鏈路：面向公共層的開發和復用；
  4）統一服務：同時支撐了多維分析和高QPS服務化查詢場景；
  5）MC-Hologres查詢服務：2020雙11當天查詢latency平均142ms，99.99% 的查詢在200ms以內；
  6）支撐200+實時資料大屏搭建，為近300+小二提供穩定的資料查詢服務，

電商營銷活動分析

接下來舉一個營銷的例子，

過去營銷活動都是提前一個月做各種規劃，包括在什么地方投什么樣的廣告，給什么人群投廣告，投什么樣的代金券等，但這件事在互聯網領域里有更高的要求，例如雙11這類場景，對實時策略的調整需求越來越多，活動可能只有一天的時間，我們要實時地去了解成交排行，成交構成，庫存情況，每個流量通道的轉化率，比如打開一個網頁，一開始要推薦的是某個商品，但是隨著時間流逝會發現，商品轉化率非常的低，此時我們需要調整營銷策略，

因此，在這種實時營銷的場景下，對實時資料分析的要求非常高，需要實時了解每個渠道，每類人群，每類商品轉化率/成交率等，根據情況實時調整營銷策略，最后提高轉化率/成交率，

阿里內部計算大概架構如上所示，產品搭建使用QuickBI，互動式分析使用Hologres，資料加工的部分通過Flink和MaxCompute，這是一個比較經典的架構，

實時計算 Flink 版 + RDS/KV/OLAP 方案

實時計算 Flink 版 + RDS/KV/OLAP這套架構是早期的方案，所有計算邏輯通過Kafka串起來加工的方式，然后用Flink匯總成結果集存起來，它的局限是開發效率和資源消耗非常大，

我們知道，資料分析可能是N個維度，例如時間、地域、商品、人群、類別等，其中不同維度還可以進一步做劃分，例如類別分一級類別、二級特別、三級類別，人群畫像包括消費能力、教育程度、地域等，任何維度組合做關聯分析都會產生一定的結論，

因此，我們說過去的計算量非常大是因為要算2 ?種組合，才能把所有可能被分析的角度都提前算好存下來，使得分析師看報表的時候，不管他選擇什么維度的組合，都可以找到對應的計算結果，但這個計算量是個天文數字，不可能有程式員寫出這么多的計算，如果沒有計算則沒有結果集，

除此之外，如果我們一開始算三個維度組合，突然老板覺得這三個維度不足以判斷出今天發生到底什么事，想再加一個維度，但我們沒有提前寫這段邏輯，這時候上線資料已經消費完了，沒有辦法重新計算出來，或者重新計算成本非常大，因此這是資源消耗非常大的一種方法，而且我們開發完之后，計算了幾千張中間表，這些結果集/組合關系是否有人使用，我們無法不確定，只能先算出來，放在資料庫里面存一張臨時表，成本非常大，

實時計算 Flink 版 + Hologres 互動式查詢方案

如上所示，改革之后的架構其實沒有本質的變化，還是那些加工的邏輯，最大變化在于通過視圖的方式替代了很多中間加工的程序，視圖在資料庫里面做計算，把一部分計算前置的任務放在了計算后置，

原始資料還是通過訊息中間件，通過Flink做決議去重，然后存著明細資料，明細資料不再做很多的二次匯總加工，而是通過很多邏輯視圖，無論想看幾個維度，可以隨時寫到SQL陳述句，視圖可以隨時上線，它并不影響原始的資料，這樣的話，我們想查什么資料它就算什么資料，所有的分析負載沒有浪費，開發效率也會變得非常高，從過去要計算2 ?，到現在只存了一張明細，針對業務需求場景做一些輕度匯總層，DWD和DWS的邏輯封裝，建視圖就可以了，大幅提升開發效率，

運維成本要求架構具備很好的彈性伸縮能力，這也是Hologres具備的能力，在雙11流量大十倍的場景下，可以隨時彈性擴容，十分方便，

助力業務快速決策調控

這帶來了非常大的收益，過去需要很復雜的計算邏輯流程，資料從產生到輸出結果，可能需要幾個小時的計算程序，這意味著我們過了幾個小時才能判幾個小時之前的資料，調整業務邏輯想看結果的話又要等幾個小時，整個業務的靈活性大打折扣，

使用Flink + Hologres這套架構之后，資料實時產生、實時分析，隨時可以做業務實時決策調控，分析靈活性非常高，例如很多客戶反饋，剛開始以為某些商品會賣得很好，結果到晚上發現跟預期完全不一樣，爆品反而是預期之外的商品，這些都是在提前計劃好的報表上看不出來的問題，真實場景中有很多靈活上線新業務的需求，如果新業務可以在數分鐘或者一小時之內上線，就能夠解決這些靈活性的場景，這也是Hologres實時數倉帶來一大收益，

高效的實時開發體驗

我們可以看到像大屏開發，大屏里邊有幾十個不同的指標，以前這類系統開發的時候也是比較復雜，要拿不同的資料源做不同的匯聚，通過不同的調度才能夠生成這樣的資料，

使用Hologres之后，2人日就可以完成開發，因為背后不需要那么多調度，寫幾條SQL陳述句即可，大幅提升開發效率，

它單日寫入可以支撐500億條以上記錄，峰值寫入QPS為100W+/s，查詢回應延遲小于1秒，不管是在寫入資料量還是分析體驗都做得非常不錯，

Hologres數倉開發三階段

Hologres不僅有建實時數倉，有準實時、全實時、增量實時等不同計算方式，在公司數倉建設的不同階段，Hologres有不同的使用方式，包括探索方式、發展方式和成熟方式，

探索方式是對靈活分析需求比較多，資料模型也不太固定，分析師不確定想怎么使用資料的場景，因此這個時候數倉建設以明細層的匯聚為主，首先要把公司的資料集中化，資料不集中的話，分析效率無法保障，以ODS建設為主，DWD為輔，給ODS層做一定的質量保障，把資料的清洗、關聯、拉寬等基本作業做好，生成一些DWD明細層資料，然后在明細的資料之上直接提供分析，一定要把ADS層做薄，上面不要做很多的調度、匯聚，因為這時候分析資料的方法還不確定，以下層建設為主，在Hologres里可以存明細資料，用列/行存都可以，

第二個階段叫快速發展階段，這個時候的主要特征一般是公司開始考慮資料中臺，開始儲備資料產品經理、資料分析師這樣的角色，此時開始沉淀公司的指標體系，沉淀公司可被復用的資料資產， DWD已經不滿足了，要繼續在DWD之上做一些面向可復用的寬表，一些性能關鍵的場景還可以做二次加工匯聚變成ADS層表，Hologres有行/列存，可被復用的指標基本是用列存為主，如果需要ADS點查場景，可以繼續二次加工變成行存，

第三個階段進入成熟穩定階段，此時公司的指標體系相對比較完善，有很多可被復用的指標，就需要從之前按照業務場景的匯聚往下沉淀成DWS可被服用的匯聚層，很多公司的公共指標要變成公司的指標庫，這時候以DWS建設為主，
在這個階段Hologres也提供技術支持，可以看到從DWD到DWS，Hologres支持內置的Binlog驅動可以做持續的匯聚作業，

可以看到，數倉建設分為不同階段，不同的階段有不同的建設重點，在不同的建設階段，可以采用Hologres不同的技術來適應不同的需求，

總結

最后我們總結一下，Hologres是什么？

首先Hologres是一個開發相對比較簡單的系統，會寫SQL陳述句就可以使用，它對SQL幾乎沒有限制，不管是連接操作、視窗操作都可以支持標準的JDBC，

Hologres采用兼容Postgres介面的方式，所以不管是開發工具還是BI工具，它都可以選擇Postgres協議和Holo對接，

Holo里所有的資料結構是基本的表，這個表里有資料型別，有主鍵，有索引，這都是大家比較熟悉的概念，因此學習成本非常低，

其次，這個系統查詢足夠快，它具備實時寫入、寫入即可查，端到端實時是最基本的要求，資料寫進去都不需要落盤就可以查，

除此之外，它跟大資料生態系統的結合是非常原生的，不管是Flink還是MaxCompute，Flink有很多原生的Connector，支持Holo原生的Binlog介面，支持最高性能的吞吐，Hologres和MaxCompute在檔案系統層面是打通的，所以很多情況下，資料在MaxCompute系統下加工完，不需要導到Hologres系統里面，Hologres可以當做外表去查詢它，性能也是比MaxCompute直接查會更好一些，但是如果需要性能更高的話，還是需要把MaxCompute的表導到Hologres里面來，

傳統上MaxCompute導到任何其他OLAP系統，基本上都需要比較長的時間，但由于MaxCompute和Hologres底下檔案系統打通，所以同步程序并不是把資料讀出來再寫到另外系統里面去，而是在通過檔案系統底層介面直接進行像Copy一樣的操作，因此性能可以提高10~100倍，

最重要一點還是開發效率上的提升，大家過去可能要以周為單位來建設系統，如今可以以天為單位建設，我們可以把更多的時間用在資料挖掘上，而不是在資料平臺的底層運維上，

運維友好方面也有很多收益，Hologres是一個托管的服務，用戶可以很靈活地彈性伸縮容，在擴容的時候，計算節點和存盤節點可以獨立擴容，當計算節點不夠的時候可以單獨擴容，并不需要計算和存盤同時擴容，

這套技術是在阿里巴巴的場景下被嚴格驗證，這和很多其他技術不太一樣，它不是為了做商品進行銷售的產品，這套技術在阿里內部經過4年多次雙11場景，幾十個不同的BU反復驗證，我們認為它已經是一個可以被更多用戶使用的成熟技術，因此我們把它變成一個云上托管的服務提供給廣大用戶使用，通過HASP架構，用一套更簡單的架構支撐多個場景，實作更優性價比，

原文鏈接：https://developer.aliyun.com/article/785295?

著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，