本文整理自直播《實時數倉助力互聯網實時決策和精準營銷-合一》
視頻鏈接:https://c.tb.cn/F3.0Wec2I
近年來，實時數倉是互聯網的熱門話題，主要應用場景主要是在實時決策和營銷等領域，這些領域對數據分析的精細度、實時性都有很高的要求，是走在技術前沿的領域。
業務在線化、運營精細化推動數倉實時化、交互化
我們先看一下過去幾年數據分析發展的一些趨勢，如上圖所示。
可以看到，數據分析基本的趨勢是從批處理向交互式分析、流計算的方向演進。在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架構，用一套更簡單的架構支撐多個場景，實現更優性價比。
活動推薦
阿里雲基於 Apache Flink 構建的企業級產品-實時計算 Flink 版現開啟6月限時活動：
0元試用實時計算 Flink 全託管版本（包年包月、10CU）即可有機會獲得 Flink 獨家定製T恤；另包3個月及以上還有85折優惠！
瞭解活動詳情：https://www.aliyun.com/product/bigdata/sc
