看場景、重實操，實時數倉不是“紙上談兵”

這兩年，企業 IT 領域掀起實時數倉熱潮。然而，只要稍做梳理就會發現，實時數倉格局未定，各種流派群雄逐鹿，還有很多需要進一步探討的話題方向。

比如：實時數倉是什麼?如何從概念上去定義?有人認為，傳統資料倉儲做了實時化，就是實時數倉;有人認為，雲數倉、湖倉一體是實時數倉;還有人認為，HTAP 是解決實時數倉需求的一個重要手段!

再比如：實時數倉是一款產品，還是一個解決方案?99% 的企業都會認為是一個解決方案，1% 的企業會認為是一款產品，這 1% 就是阿里雲!

▲阿里雲自研大資料平臺產品負責人劉一鳴(合一)

為了弄清事實真相，幫助使用者找到應用選型 " 快速通道 "，本期實時數倉系列訪談，特邀請到阿里雲自研大資料產品產品負責人劉一鳴(合一)，請他從實時數倉的技術演進、應用場景、架構以及 Hologres 自身實踐角度，一層一層揭開實時數倉的 " 謎團 "!

實時數倉進化

如果，非要給實時數倉下一個定義，一定要符合從 1.0 到 3.0 時代的進化特徵。

首先，得是一個數倉，具備規模資料的互動式分析能力。實時數倉不只是 " 實時 "，很多系統不支援標準 SQL，不能算數倉。所以，屬於 1.0 時代的實時數倉，有一個重要前提，就是支援較為完善的 SQL 以及優秀的大規模分析能力，因此很多系統採用了分散式、列存、索引、壓縮等數倉加速的技術。

其次，面向實時場景做了針對性最佳化，包括實時寫入、實時分析、實時取數等。如果和普通資料庫相同，沒有針對實時場景做最佳化，很難達到實時數倉對吞吐和分析的時效性要求。實時數倉需要具備高吞吐寫入和更新能力，資料寫入即可用，支援靈活的資料更新。比如：很多普通資料庫，雖然能寫也能查，但當資料規模放大到一定程度，要麼犧牲了寫入效能保查詢，要麼犧牲了查詢效能最佳化寫入，無法針對實時資料多場景進行最佳化，這不能算好的實時數倉。

進入 2.0 時代，實時數倉就要儘可能快地支援線上業務。企業之所以做實時數倉，是希望資料進來之後能夠被足夠新鮮地消費，能實時寫入、實時分析，還要支撐線上服務。線上服務場景需要更高的效能、低抖動、穩定性、併發能力，對線上服務場景進行支援，是實時數倉關鍵一環。

而 3.0 時代的實時數倉，可以定義為一站式實時數倉。這個時候的實時數倉，不僅具有高吞吐寫入與更新、端到端的全鏈路實時加工以及低延遲高併發線上服務能力，在保證資料一致的前提下，需要支援多種負載之間完備的隔離和彈效能力，以確保各個業務互不干擾，各自按需使用資源。同時實時數倉的使用通常離不開離線數倉的組合關係，透過離線平臺對歷史資料的週期性匯聚、抽象和加工，並將結果資料匯入實時數倉進行豐富和修正，需要更有效地打通實時與離線兩套系統，實現後設資料和資料的無縫交換，這也是實時數倉落地時需要具備的能力。這種一站式體現在儲存狀態的一致性，減少了不同負載之間的資料同步和儲存開銷，避免了資料服務層的資料孤島難題。

所以，實時數倉既不是傳統資料庫的舊瓶裝新酒，也不是湖倉一體的多產品組合，它和離線數倉的本質區別是，透過對易變資料結構(包括記憶體結構、檔案儲存)和計算資源的細粒度靈活管控，更好地支撐資料的實時寫入、實時更新、實時查詢。至於，很多公司之所以把實時數倉定義為是一個解決方案，是因為技術相對更加複雜，既要考慮寫入和加工能力，又要支援查詢和線上分析場景，不得不針對不同技術需求將多種技術棧堆砌在一起，包括採用流式計算、訊息中介軟體來達到端到端的實時加工，採用列式資料庫應對分析需求，採用行存系統支撐線上服務系統，並依賴複雜的排程配置，實現資料在中介軟體、儲存系統之間的最終一致性。而將複雜技術落地成為一款易於使用的成熟數倉產品，仍然是少數技術創新者在努力的方向。

阿里雲 Hologres，整體技術水平領先業界 1-2 年，是基於在阿里巴巴內部資料技術的廣泛應用與沉澱，一步一步走過來的。阿里有海量資料的複雜應用場景，有歷年雙 11 等大促的深度壓力測試，有在儲存和計算領域深扎多年的技術專家，有上萬名資料小二支援業務的靈活需求與快速迭代，這些都是其他公司不具備的得天獨厚的條件，推動著阿里在資料技術領域的持續創新。

Hologres 支撐的業務的規模、複雜性和對效率的追求，實現了透過有些開源技術組合無法達成的資料價值目標。行業內不少企業採用部分開源技術棧，如：用 Kafka 做中介軟體，用 Hudi 做離線儲存，用 Presto 做離線查詢加速，用 ClickHouse 做 OLAP 查詢，用 Flink 做流式資料加工，用 MySQL 做快取，用 HBase 做線上服務引擎。這些架構也是阿里採用過的一代實時數倉架構，但當開發效率遇到瓶頸時，當資料鏈路複雜到成為運維負擔時，當資料不一致不得不 80% 時間在對數排查時，工程師們開始思考是否還有更好的解決方案，是否有一個更加集中化、一體化、能力更全面的數倉選擇。而 Hologres 的出現也就重新定義了實時數倉的形態。

基於此，OLAP 查詢和線上服務使用 Hologres，滿足分析的靈活和效率，離線數倉使用 MaxCompute，支撐規模性和 Serverless 擴充套件性，實時流式計算用 Flink，凸顯端到端全實時加工，三者的結合讓實時和離線計算，分析和服務都能達到一個非常好的平衡，滿足業務的多種需求。

阿里雲 Flink 版的出處與 Hologres 的淵源

有人可能會說，阿里雲 Hologres+Flink 這套組合也用了 Flink，和其他解決方案相比，有什麼不同呢?

沒錯，Hologres 要想發揮更好水平，與 Flink 結合，一定是首選。實時計算需要後臺有一套強大的大資料計算能力，而 Apache Flink 作為一款開源大資料流式計算技術，從設計之初就由流計算開啟，相比傳統的 Hadoop、Spark 等計算引擎，更能確保資料處理的低延時，讓資料發揮價值。

早在 2016 年，Apache Flink 捐獻給 Apache 之後的第三年，阿里已經開始大規模上線使用實時計算產品，用於阿里最核心的搜尋推薦以及廣告業務場景。2017 年，基於 Flink 的實時計算產品，開始服務於整個阿里巴巴集團，同年雙 11 服務全集團的資料實時化，包括雙 11 的實時大屏。2018 年，基於 Flink 的實時計算平臺產品不僅服務於集團內部，同時開始服務於雲上中小企業，以公有云的形式對外提供服務。2019 年，阿里巴巴收購了 Flink 的創始公司 -Ververica，阿里的 Flink 實時計算技術團隊和德國總部的 Flink 創始團隊，組成全球領先的 Flink 技術團隊，共同推進整個 Apache Flink 開源社群的發展。

使用者透過 Flink 可以把資料實時寫入到 Hologres，也可以透過 Hologres 做維表關聯。如此一來，離線分析走 MaxCompute，資料的點查、聯邦分析以及 OLAP 分析走 Hologres。舉一個維表加工的例子，Flink 每次加工進來之後，每一條事件都要跟維表做關聯，比如：事件資料中包含了渠道 ID，在分析時需要知道是什麼渠道型別，因為要透過加工鏈路將 ID 還原為渠道屬性，這種關聯有時候每秒鐘要達到上萬、上十萬的 QPS。過去，很多業務團隊採用 HBase 來支撐這類點查業務，但 HBase 沒有 Schema，資料寫錯很難發現，很難修正;現在，Hologres 只用過去 50% 的資源，支撐了 HBase 完整的業務。

與開源 Flink 相比，阿里的實時計算 Flink 版進行了多處核心功能的最佳化，在儲存、網路和傳輸等方面都調整到滿足業務場景所需要的效果。並且，阿里雲 Flink 版和 Hologres 做了大量的結合最佳化工作，不僅支援維表到結果表，也支援透過阿里雲 Flink 的全量讀取、Binlog 讀取、CDC 讀取、全增量一體化等多種方式讀取 Hologres 源表資料，尤其是阿里雲 Flink 支援讀取 Hologres Binlog，就使得 Hologres 能夠達到像 Kafka 等訊息中介軟體同等的能力，一個 Hologres Table 的資料既可以提供給下游阿里雲 Flink 任務消費，還可以對接上游 OLAP/ 線上服務查詢，不僅節省了成本，還簡化數倉架構，同時也讓數倉中的每一個層次都可以實時構建、實時查詢，提升資料的流轉效率。在後設資料管理方面，阿里雲 Flink 版與 Hologres 後設資料打通，支援 Hologres Catalog，實現後設資料的自動發現和管理，也大大簡化了開發和運維管理工作。

HSAP 分析服務一體化的獨特之處

Hologres 是兩個英文單詞的組合，即 Holographic+Postgres，Holographic 來源於物理學，Postgres 代表的是 PostgreSQL 生態。

從物理學原理看，地球沒有被黑洞吸進去，是因為有一個臨界點，這個臨界點所組成的面，被證明是一個球面，也叫世介面。與此同時，黑洞裡所有資訊在世介面上都有投影，即 3D 全息投影技術。Hologres 想做的事情是，透過產品化的能力對資料黑洞做全息展示。

為了簡化資料儲存和統一資料服務，阿里雲提出了 HSAP 架構理論 ( Hybrid Serving & Analytical Processing，後續簡稱 HSAP ) ，而 Hologres 是實踐 HSAP 目標的一個具體實現。Hologres 的目標是，做分析服務一體化的實時數倉，典型特徵是：存算分離的雲原生架構、多負載隔離、端到端實時毫秒級的互動式分析體驗、超高 QPS 的線上服務能力等。從應用場景來看，既可滿足實時數倉的需求，也能對離線資料進行查詢加速，同時還可實現實時與離線資料的聯邦計算，為使用者構築全鏈路、精細化運營能力。

為什麼說分析服務一體化能力特別重要呢?

以廣告推薦為例，這是一個非常典型的線上服務場景，如果一個人收藏了一個連結，他就會獲得相應的廣告推薦，該推薦包含了你過去 30 天、60 天 或者 90 天裡的行為，還包括你的教育程度、家庭關係，這些是典型的離線特徵。對於後端技術平臺來說，這些行為不用每天去算，每週算一次就可以。但另一部分特徵是實時的，比如你當下點了什麼內容，對什麼感興趣，跳轉了什麼連結，這部分行為就需要透過 Flink 這樣的流式計算實時處理。只有把實時和離線兩部分資訊結合起來做推薦，才有全面的 360 資訊，使得推薦更加精準，更加具備上下文相關性。

過去，沒有 Hologres 之前，如果一個大資料系統要支撐廣告推薦業務需要寫一條很長的鏈路，反覆同步資料，這很難提供靈活敏捷的資料服務，大量資料作業開發成本很高，出現資料不一致等問題。阿里的工程師嘗試把問題簡化，讓資料不動，透過 Flink 或者 MaxCompute 加工好的資料，直接提供線上服務，這就需要把 Serving 場景做強，面向應用程式，或者面向 API 消費資料的場景時，要有高 QPS、低延遲能力。

而針對 Analytics 能力，很多企業都會基於 OLAP 引擎做資料分析。這部分資料一般會有兩個出口：一個出口是給機器使用，透過 API 訪問，主要是推薦系統和風控系統;另一個出口是給分析師使用，透過 SQL 訪問，看報表，做對比分析，找到趨勢變化。這兩個出口的資料需要保持一致性。Hologres 作為互動式分析引擎，針對兩個場景做了執行最佳化。在支援線上的高 QPS 服務型查詢時，這類查詢邏輯相對簡單，但併發高，因此採用了 Short-Cut 技術，透過 FixedPlan 執行最佳化，減少在 SQL 解析最佳化和排程層的開銷，請求直達儲存節點，延遲更短;在支援分析師的複雜多維分析時，採用 MPP 分散式計算框架、列式儲存和向量化引擎，有效率大範圍過濾資料，保障了億級資料的秒級資料分析。這樣，透過 Hologres 統一資料服務出口，同時支援線上服務和多維分析兩個場景。

Hologres 借鑑了主流的資料架構，包括採用類似 LSM-tree ( Log-Structured Merge Tree ) 這種高吞吐寫入和更新友好的儲存架構，利用了 CPU 指令向量化、非同步化的新技術創新，基於雲原生的計算儲存分離架構，形成了一款低門檻的生產級產品。Hologres 在協議層面上用到了 PostgreSQL 的這種協議，簡化了與業務系統的對接，應用無需重寫，也沒有廠商引擎繫結，開箱即用，核心的儲存引擎、查詢引擎是阿里自研的一套系統，持續改進效率、穩定和易用。

Lambda 與 Kappa 的紛爭

其實，最早阿里雲沒想到要做實時數倉，只是想把實時和離線資料實現一體化。

換言之，阿里雲的 HSAP 架構也是由 Lambda 架構走過來的。眾所周知，Lambda 架構有一個優勢，既支援流式數倉，又能滿足離線數倉的計算要求;但是也有一個弊端，就是流和批分為兩套技術棧，運維要維護兩套系統架構。後來，Kappa 架構出現，有人認為能很好地解決 Lambda 架構的問題，但事實並非如此。因為企業的資料加工永遠會有實時和離線兩條鏈路，這是資料加工作業的屬性決定的。實時鏈路資料總會晚來，或者不來，資料質量並不可靠。所以，只有實時鏈路，解決不了資料質量問題，還需要離線鏈路對實時鏈路的修正和豐富，而依賴訊息中介軟體支撐海量資料的回刷是成本極高及不穩定的架構。也就是說，只要有離線場景，Lambda 架構就有存在的合理性。

但問題是，Lambda 架構一定需要兩套系統，這該如何解決?本質上，還是技術的割裂，導致架構不統一。好的 Lambda 架構，應該是狀態層統一的，實時的業務邏輯和離線的業務邏輯儘管加工鏈路不同，但儲存層應該統一，減少資料割裂和不一致，透過實時和離線兩套業務邏輯相互補充，離線的業務邏輯對實時資料鏈路進行修正。

在 Lambda 架構實踐過程中，很多企業實時業務用 HBase，離線業務用 Hive，這種儲存割裂狀態，導致資料不一致，口徑不一致。正確的架構選擇應該是 Lambda 的改進版，把資料狀態統一儲存在一個儲存系統，這個儲存同時支援離線批次匯入，也支援實時更新與查詢，這也是一種可落地的批流一體實踐。

雖然，有些企業在推 Kappa，但從實踐的角度看，Kappa 其實是個偽概念，因為實時業務系統如果取代離線，意味著資料要頻繁地修正、更新，而 Kappa 無法從根本上解決這個問題。目前，推 Kappa 架構的企業，大部分是訊息中介軟體廠商，或者一些純粹做實時的團隊。他們假設了一種狀態，所有的資料都可以透過訊息中介軟體恢復。但現實是，企業不會把所有的狀態都透過訊息中介軟體去回放，或者長期儲存。所以，透過訊息中介軟體替代資料庫的方式，只有訊息中介軟體廠商在力推，不具備廣泛落地的參考意義。

在阿里內部，HSAP 架構把分析和服務兩個場景放在一起，解決了資料不一致問題，減少了資料同步的開銷，避免了資料孤島，資料加工鏈路保持了實時和離線雙鏈路，實時業務系統解決時效性問題，離線可以為實時業務系統進行修正和豐富，兩條鏈路各解決各自的問題，使得實時和離線由一套系統承載，也就真正實現了流批一體。

下一代實時數倉更重實操

到今天為止，Hologres 作為標準產品對外提供服務已經兩年多，每年客戶數都是三位數增長。在實踐中，60% 的使用者主要使用 OLAP 場景，20% 主要使用 Serving 場景，還有 20% 做到了 HSAP 混合負載的最佳化架構，透過技術創新為企業降本提效。實時數倉還處於發展過程中，相信隨著大資料的不斷推動，實時數倉會成為推動業務發展的 " 有力抓手 "。

過去，資料團隊更偏內部業務場景，主要的工作就是給管理層出報表，做領導駕駛艙。但在今天，資料團隊正從成本中心轉為盈利中心，大資料團隊要想去影響業務，提升價值感，包括風控、實時畫像、實時推薦等手段，是提升業務的主要入口，這也是實時數倉需求快速增長的最根本原因。實時數倉會成為大資料平臺裡一個重要組成部分，是資料消費端的核心元件。

當然，實時數倉並不是一個新事物，從有數倉開始，使用者需求一直存在。但是，因為方案的不成熟，很多都是由開源元件堆在一起，從開發和運維成本上看，技術門檻比較高，導致實時數倉沒有實現規模化發展。企業必須招聘來自 BAT 的人才才能玩得轉實時數倉，這個是不正常的，也不是時代發展的趨勢，技術一定會普惠化，所有的企業都會用上大資料，但不應該所有的企業都成為技術專家。

真正受市場歡迎的實時數倉產品，簡單、易用是前提，能處理海量資料，不用懂很多引數，不用寫很多程式，能做到只會寫 SQL 就可以上手。另外，企業希望資料寫進來就能用，儘量減少資料加工過程，減少資料鏈條，實現敏捷化。即使業務方突然提出一個新需求，只要改下 SQL 就可以了，不用做任何資料重刷，對開發效率提升來說，帶來的是根本性的轉變。

所以，下一代實時數倉到底如何發展? Hologres 已經 " 打好樣 "! 那就是技術門檻會越來越低，同時計算力會越來越強大，使用方式越來越簡單，不僅資料能實時寫得進來，還要在原始資料上直接做分析，查詢要足夠快，併發足夠高，取數不用等，需求不求人。希望透過 Hologres 這樣的產品，能夠將實時數倉變得更加普惠化、敏捷化，讓各行各業的數智化建設邁上新臺階。