本文整理自直播《實時數倉助力網際網路實時決策和精準營銷-合一》
視訊連結:
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架構，用一套更簡單的架構支撐多個場景，實作更優成本效益。
活動推薦
阿裡雲基于 Apache Flink 建構的企業級産品-實時計算Flink版現開啟活動：
99元試用
實時計算Flink版(包年包月、10CU）即有機會獲得 Flink 獨家定制T恤；另包3個月及以上還有85折優惠！
了解活動詳情：
https://www.aliyun.com/product/bigdata/sc