本文整理自直播《基於Hologres的實時數倉新架構-金曉軍(仙隱)》
視頻鏈接:https://c.tb.cn/F3.0dOBIZ
典型業務場景列舉
提到實時數倉，我們可以看一下數據業務典型的應用場景。
如上圖所示，第一類場景是實時大屏。如今一般來說，不管是做to C還是to B的業務，或者說給上司看，都喜歡做一個業務大盤，來展現整個業務的運行情況。
第二類場景是BI報表，這類業務是從傳統的離線BI報表產生的，只不過隨著實時數據、實時業務的需求越來越旺盛，所以實時BI報表的需求也越來越多。
第三類場景是用戶畫像，不管是做金融還是做推薦，都是做千人千面，希望能夠通過歷史數據、用戶行為數據得到用戶的興趣，來給用戶提供更好的服務。
第四類場景是預警監控，或者說是流量監控。不管是做APP的還是做服務器端的監控，最終都是把數據收集上來，以這樣大盤的形式進行展現。最終可以在這些預警指標進行報警，來保證監控業務的穩定性。
數據業務無論是離線還是實時，大致可以分為以上這麼四類。
傳統數據倉庫數據處理流程
接下來我們看一下傳統離線數倉是怎麼樣的一個處理流程。
上方是一個典型的傳統離線數倉的數據處理鏈路。
首先，從業務系統CRM、ERP或者其他數據源把這些業務數據收集上來，然後經過離線數倉的ETL，然後對數據的話進行數據清洗、數據加工。在這個過程中涉及數據建模、數據分層，最終會把加工後的數據，或者是最終要產生BI報表的數據，通過BI工具或者寫到數據庫裡面，推到一個在線系統裡面去，最後提供給用戶進行訪問，這些用戶可能包括產品的用戶、運營同學或老闆。
用戶希望能夠從這樣的數據裡面看到，比如整個產品的售賣情況，或者業績的增長趨勢，系統的一些指標等，這就是一個比較典型的離線數倉的處理流程。
批量數據分析流程有以下幾個特點：
- T+1數據接入
多種數據源接入 - 定時數據開發與應用
1）數據提取/數據轉換/數據加載
2）ODS數據處理
3）DWD標準數據場景
4）MDM元數據
5）數據集市應用 - 核心痛點
1）ETL計算/存儲/時間成本過高
2）數據處理鏈路過長
3）無法支持實時/近實時數據分析
Lambda：割裂的架構，需要變革
為了解決傳統數倉的問題，出現了一些新的解決思路。
首先在2011年之後興起了Lambda架構，如上圖所示。
Lambda的大致思路還是以傳統的離線數倉為主，然後引入了實時數據的處理鏈路。T+1數據還是走傳統離線數倉鏈路，然後再加上一個實時的數據鏈路，再把這些實時數據和離線數據彙總到一起，然後再通過一個Merge層提供數據服務，對外提供的服務可能是點查詢，也可能是做複雜分析，還有可能是做聯邦查詢。然後在這上面去加數據應用，比如上文提到的BI報表，實時大屏，用戶畫像等。
從架構的名稱Lambda就能夠看出來，其實它是在傳統離線數倉基礎上加了實時，解決傳統離線數倉的問題。但其實整個Lambda架構也有一些問題，主要存在的問題是架構複雜、數據同步難、資源消耗大、數據孤島、人才培養難、開發成本高、不敏捷。
比如，Lambda架構並沒有從源頭上解決傳統離線數倉的問題，而是在傳統離線數倉上加了一條鏈路，這會讓整個系統變得更加複雜。
在架構複雜的基礎上，數據可能會存兩份或者存多份，實時鏈路和離線鏈路數據不統一。除此之外，整個架構維護起來也是非常複雜的，並且開發成本比較高。比如說離線鏈路用Spark或者Hive，實時用Flink，但其實這些SQL是不太一樣的。還有元數據如何管理，數據如何治理，再加上提供服務的時候，Merge層可以用HBase、Redis這樣的系統去做，這些API其實都是非常複雜的。對一個小企業，做這種數據開發或者說做這種數據平臺，資源是有限的，學習成本非常高的。經常發生的情況是，小公司剛把一批同學培養起來能夠熟悉這些系統，然後就被其他公司挖走了，因此人才成本也非常高。
阿里巴巴的整個數據業務也是沿著這條路走過來的，我們思考有沒有什麼方法來簡化這個架構，下面來看一下。
首先一個簡單的思路，就是能不能把離線數據和實時數據進行統一。我們首先做的事情是實時/離線一體化，把實時ETL和離線ETL進行統一，整個數據模型進行統一。
在實時/離線一體化的基礎上，分析部分是偏離線的，服務部分是偏在線的，我們思考能否把這兩部分也做一個統一，讓一份數據既服務於離線又服務於在線。我們把這樣的架構叫做分析服務一體化，分析相當於離線分析，服務是提供在線服務。如果真能做到一體化的話，相當於是由傳統的OLAP變成了分析服務一體化架構。
思路有了，接下來我們看一下怎麼去做這個事情。
阿里業務場景原架構
阿里巴巴原來的業務也是由傳統Lambda架構走過來的，下面介紹阿里巴巴一個業務場景：搜索推薦場景。
如上圖所示，最早的時候這個架構就是為了解決實時推薦。大家都清楚阿里巴巴最主要的是電商業務，電商業務以淘寶為核心，打開淘寶會給用戶推薦很多內容，其實這些推薦的內容都是一些行為事件，包括在滾屏看到的那些內容都是一條條事件。這些事件會實時寫到後臺服務裡面，然後經過Flink做實時ETL，做實時的模型訓練，或者做數據採樣，會把這些數據寫到HBase或Cassandra裡面。
通過在HBase裡面做實時的模型訓練，再把這些模型推到搜索引擎或者在線服務裡面，這樣的話就能夠完成實時推薦的鏈路閉環，能夠提供點查詢的數據服務。
那麼我們想對已經存在的數據樣本或者數據特徵進行分析怎麼辦？我們引入列式查詢的產品，比如ClickHouse或者Druid做分析，然後去接一些報表。如果還需要做數據的離線歸檔怎麼辦？可以通過MaxComputer或者Hive去做離線歸檔。有了實時數據和離線數據，那麼就要去做離線/實時的聯邦分析，又引入Drill和Presto。我們都清楚，像Drill和Presto這樣的系統的話，它整個的性能或者QPS承載的併發非常差的，如果想提高併發怎麼辦？我們引入了Redis和MySQL去做這樣的一個Cache，然後通過非常短週期的調度，從 Drill和Presto去做查詢，再把結果寫到Redis或MySQL裡面去，然後整個數據去對接API服務或者對接報表等。
上方就是阿里巴巴搜索推薦場景原來的業務架構，是一個典型的Lambda架構。絕大部分公司從業務出發的話，也是這麼一個架構。
下一代實時數倉如何選型
按照上文的思路，如果我們想去簡化這樣的架構，把實時/離線一體化，再把分析服務一體化，我們需要一個新的實時數倉，應該怎麼去做，考慮哪些問題？
首先，必須支持實時寫入，傳統離線T+1肯定是不可以的。除此之外，能夠支持非常實時的計算。
第二是能夠把實時數據和離線數據存放在一起，做到實時/離線數據一體化，減少數據的移動。
第三是希望平臺跟上層的業務能夠解耦，意味著平臺必須具備一定的通用性，而不是一個定製的產品。
第四是對於上層業務使用的API，我們希望能夠擁抱開源生態，並且希望整個系統或者產品是一種雲原生的架構，便於雲上用戶使用。
為了解決上述問題，我們從已有的一些開源產品裡面找找靈感，看看它們現在是怎麼去做的，每個產品解決哪些問題。
如上所示，首先一大類是數據庫產品，如MySQL、PostgreSQL等，它們比較典型的是支持事務，事務最重要的是支持ACID，做到讀寫一致性，保證數據的一致性。但是它們有個缺點，就是Scalability往往很難做到PB級別，同時不能做非常複雜的Query分析。
第二類是現在面向於分析加速或者OLAP這樣的系統，比較典型有Presto，ClickHouse，Hive等，這類的特點是大規模數據掃描、過濾、彙總，語義層，分佈式，列式存儲，面向分析師。
第三類是Serving場景，提供高併發，支持簡單快速的查詢，比如Cassandra、HBase、Redis等，能夠提供非常高的性能。
目前有一種趨勢是很多產品在做HTAP，就是把Transaction和Analytics融合，相當於在一個產品裡滿足這兩部分能力，目前有很多產品在一定程度上都能做到，其中有一些隔離性或者數據一致性的問題，但是基本是可解的。這類場景的話往往是Transaction，以TP為主業務基礎，然後在TP數據的基礎上做一定的分析。針對這種場景，我們對讀寫一致性沒有很高的要求，只要做到最終一致性就好了，更多的是要求能夠支持非常高併發的查詢和分析。把這兩類場景結合到一起的話，我們叫做Hybrid Serving/Analytics Processing（HSAP）。
目前在市場上並沒有這樣一類產品，我們希望做出這樣的產品來解決分析服務一體化。有了架構理念，下面我們看一下如何實現。
新一代技術理念HSAP：分析、服務一體化
Hybrid Serving/Analytical Processing
我們首先想到是做統一存儲，把離線數據和實時數據放到一起做規劃處理，然後對統一存儲的數據提供統一的數據服務，上層的數據應用如數據報告、數據看板、在線應用等，都直接通過在線的數據服務，提供統一查詢出口，就可以解決上文的問題。
有了這樣的思路後，我們研發了一個產品——Hologres。
簡單介紹一下Hologres這個產品的名字是怎麼來的，它是由兩個單詞拼成的，一個是Holographic，另一個是Postgres。
Postgres代表PostgresSQL的生態，Holographic來源於物理學。
我們知道，黑洞連光都能夠吸進去，但是我們在地球上並沒有被黑洞吸進去，是因為我們離這個黑洞足夠遠，這是否就意味著有這一個臨界點，這個臨界點之內的都會被黑洞吸進去，臨界點之外的能夠逃出黑洞引力。
由這個臨界點組成的一個面，被證明是個球面，我們把它叫做世界面。有科學家證明黑洞裡面的所有信息在世界面上都有投影，意味世界面上包含黑洞的全部信息，也就我們經常提到的3D全息投影技術，全息的英文單詞就是Holographic。
Hologres想做的事情是通過產品對數據黑洞做全息展示，全部信息在Hologre能夠提供服務的能力，並且數據存在Hologres的數據黑洞裡面。
阿里搜索推薦：從N到1，Hologres簡化大數據架構
上圖為使用Hologres前後的架構對比圖，使用了Hologres之後整個架構就變得非常簡單了。
首先，Flink實時寫入到Hologres裡面，也可以通過Hologres做維表關聯。同時，通過實時數據可以歸檔到MaxCompute裡面。這樣的架構對於數據服務來說非常簡單，離線分析走MaxCompute，數據的點查詢、離線加速、聯邦分析或交互式分析等可以走Hologres。
整個阿里巴巴的業務架構由左邊演變成右邊，帶來的收益是業務敏捷響應，數據自助分析，避免數據割裂，賦能數據服務，簡化運維管理。
下面我們來簡單看一下Hologres到底是個什麼樣的產品。
- Hologres = Better OLAP + Better Serving + Cost Reduced
Hologres基於HSAP理念，雲原生分佈式分析引擎，支持對PB級數據進行高併發、低延時的分析，支持實時數倉，大數據交互式分析等場景。
Hologres的特點是提供分析服務一體化，如點查詢景，類HBase、Redis場景。OLAP場景能夠提供PB級別複雜查詢，毫秒級交互式分析。Hologres以實時為中心設計理念，查詢快，實時數據寫入快，並且能夠支持實時數據、離線數據的快速導入。整個架構是存儲計算分離的架構，在雲上面跟MaxCompute無縫打通，並且從Hologres這個名字就能看出來，Hologres兼容PG語法，支持PG開發運維工具。
如上圖所示，Hologres是典型的存儲計算分離架構，整個數據是在一個共享存儲裡面，這個共享存儲可以是阿里雲內部的存儲產品盤古，也可以是數據湖的產品，比如OSS、Hive或者MaxCompute這樣的存儲。
計算節點都是在容器裡面，提供一個Worker，還有一個角色是Frontend，相當於是能夠接收用戶的SQL。接收完SQL以後進行SQL解析生成AST，然後通過優化器把AST轉化成分佈式的執行計劃，通過Coordinator發給這些Worker去做，每個Worker裡面有自己的調度系統，有數據的分片管理，同時還有Cache，然後能夠分步式執行。整個計算節點是MPP架構，然後是存儲計算分離的。
存儲計算分離
下面我們看一下存儲計算分離能帶來的好處。
一般來說，現在的大數據產品或者數據庫產品，存儲計算就幾種關係。
第一類是傳統Oracle的RAC，它們是Shared Disk/Storage的架構，相當於有單獨的計算節點，每個計算節點有自己的本地盤，有自己的內存，然後還有一個存儲集群。存儲集群相當於是一個管理的磁盤陣列，這些盤對這些節點都是開放的，這些節點能夠直接訪問存儲的數據。
第二類架構是Shared Nothing，開源系統用得比較多的像Clickhouse或者Druid，特點是存儲節點不共享。存儲節點和計算節點綁定，相當於每個計算節點有自己的一塊存儲。如果其他的計算節點想讀另外節點的存儲，必須通過網絡請求到計算節點，然後通過計算節點再把這個數據給另外的節點。
這個架構帶來的問題是很容易產生數據熱點，比如Node2，假如它數據特別多，這個數據也沒辦法存到其他節點上，這樣的架構往往會使整個Scalability受限。
第三類是雲原生這種完全存儲計算分離的架構，計算節點部署在容器裡面或者是單獨的服務器ECS，存儲是以共享的存儲服務或者DFS的方式進行訪問。整個架構非常清晰，對於計算節點來說，看到的就是一個非常大的分佈式文件系統，計算節點只需要關心到底要訪問哪個文件，而不需要知道這個文件到底在哪存的，容錯怎麼去做。
Hologres就是採用這樣的計算存儲分離架構，架構帶來的好處是可以按需購買，在雲上面需要多少計算就買多少計算資源，需要多少存儲就買多少存儲資源。
流批統一的存儲
有了分析服務一體化的架構，就能把流計算和批計算的結果進行統一。
以前流計算產生的結果寫到流計算存儲，離線計算的結果寫到離線計算存儲，引入了Hologres以後，相當於不管是離線計算還是流計算，都寫到Hologres裡面來，數據的一致性能夠得以保證。
Hologres支持點查詢、分析型查詢，主要是因為Hologres的存儲引擎支持兩種文件格式，一種是行存，一種列存。顧名思義，行存就是同一行數據的多個列是連續存放在一起的。如圖所示，列存就是相同列存放在一起，帶來的好處就是在分析的時候能夠提高Cache命中率，並且可以用向量計算做一些加速查詢。
整個Hologres存儲引擎的架構是類似於LSM-tree架構，數據先寫MemTable，寫滿以後Flush成文件，小文件太多的話合併成大文件然後做管理。
Hologres：為分析服務一體化設計的實時數倉
Hologres的宗旨是做分析服務一體化的實時數倉，簡單總結有以下三方面的特點：
- 雲原生：存儲計算分離架構
- 計算存儲資源彈性擴展，按需使用；
- 低成本、高可用、高可靠；
- 與MaxCompute底層打通，透明加速，實時離線一體。
- 統一存儲：流批統一的存儲
- 行列共存，列存對分析友好，行存對點查快速；
- 高效數據分片、分段、壓縮、索引；
- LSM-like寫友好數據結構，高吞吐數據寫入，支持更新，寫入即可見。
- 極致性能：C++ Native執行，引擎+優化器
- 向量化、全異步等執行引擎優化；
- 輕量級用戶態線程調度，同時支持多種查詢負載（高併發、複雜統計）；
- 公平調度算法（CFS），高併發充分利用計算資源。
交互式分析典型應用場景
由於Hologres架構非常簡單，因此典型的應用場景也就非常簡單，大致可以分為以下三類。
第一類是替代傳統的離線數據做加速查詢，可以把傳統的離線數據導到Hologres裡面來，這樣的話就能夠變得很快。
第二類是做實時數倉，跟Flink進行配合，把實時的ETL實時數據加工寫到Hologres裡面，然後在Hologres做實時的數據分析。
第三類是把實時離線一體化，能夠把實時/離線數據都寫到Hologres，甚至可以通Hologres做聯邦查詢，直接對其他系統的數據進行查詢。
下面舉幾個業務場景的例子。
阿里客戶體驗系統(CCO)實時數倉改造
2020雙十一活動期間，實時計算 Flink 版 + Hologres為阿里客戶體驗系統(CCO)構建了集實時化、自動化、系統化於一體的用戶體驗實時數倉。
以前的阿里客戶體驗系統(CCO)也是典型的Lambda架構，存儲層有MySQL，HBase等，只用Holo去存這種Server數據。
架構升級主要有以下幾個業務難點：
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+小二提供穩定的數據查詢服務。
菜鳥：智能物流
菜鳥智能物流分析引擎是基於搜索架構建設的物流查詢平臺，日均處理包裹事件幾十億，承載了菜鳥物流數據的大部分處理任務。
需求訴求：
1）HBase的架構下維表數據導入耗時長、資源浪 費嚴重、成本高；
2）HBase不能同時滿足PointQuery和OLAP分析，數據導入導出引發數據孤島、數據同步負擔、冗餘存儲、運維成本和數據不一致等問題。
升級後的架構
升級架構後的客戶收益：
1）整體硬件資源成本下降60%+；
2）更快的全鏈路處理速度（2億記錄端到端3分鐘）；
3）一個系統，滿KV和OLAP兩個場景，沒有數據冗餘；
4）解決大維表實時SQL查詢需求；
5）強Schema，有效避免潛在錯誤，節省時間。
友盟+：PB級用戶行為交互式分析
友盟+是國內最大的移動應用統計服務商，其統計分析產品U-App&U-Mini & U-Web為開發者提供基本報表統計及自定義用戶行為分析服務，支持精細化運營。
業務痛點：
1）業務數據量大，年新增行為數據10PB級，個性化、自定義地交互式用戶行為分析強需求；
2）基於MaxCompute提供異步離線的adhoc分析和優化、以及自研引擎開發嘗試均無法滿足業務需求；
3）導出到MySQL/Hbase方案的二次開發和數據導出鏈路長、成本高、操作不靈活。
升級後的架構
客戶收益：
1）PB級數據毫秒級查詢響應；
2）與MaxCompute深度集成，能夠利用Range Cluster索引加速，實時離線聯邦查詢，同時也可以實現冷熱數據混合查詢，有利於成本性能平衡；
3）計算資源彈性伸縮，可兼顧擴展性、穩定性、性能、成本。
實時推薦、API as service
實時推薦（特徵查詢、實時指標計算、 向量檢索召回），提高廣告留存率， 實時計算 Flink 版+PAI+Hologres with Proxima。
客戶收益：
1）支持2000萬日活用戶快速向量檢索，千萬級u2u,i2i 均可以20ms返回 ；
2）通過SQL描述業務邏輯，無需手工編碼(select a, b, proxima_distance(c) as distance from table order by distance desc limit k;)；
3）加工邏輯簡化，無需額外集群（Redis）。
活動推薦
阿里雲基於 Apache Flink 構建的企業級產品-實時計算 Flink 版現開啟活動：
99元試用實時計算 Flink 全託管版本（包年包月、10CU）即可得定製 Flink 獨家定製T恤；另包3個月及以上還有85折優惠！
瞭解活動詳情：https://www.aliyun.com/product/bigdata/sc
