作者：蔣曉偉（量仔） 阿里巴巴研究員
因為側重點的不同，傳統的數據庫可以分為交易型的 OLTP 系統和分析型的 OLAP 系統。隨著互聯網的發展，數據量出現了指數型的增長，單機的數據庫已經不能滿足業務的需求。特別是在分析領域，一個查詢就可能需要處理很大一部分甚至全量數據，海量數據帶來的壓力變得尤為迫切。這促成了過去十多年來以 Hadoop 技術開始的大數據革命，解決了海量數據分析的需求。與此同時，數據庫領域也出現了一批分佈式數據庫產品來應對 OLTP 場景數據量的增長。
為了對 OLTP 系統裡的數據進行分析，標準的做法是把裡面的數據定期（比如說每天）同步到一個 OLAP 系統中。這種架構通過兩套系統保證了分析型查詢不會影響線上的交易。但是定期同步導致了分析的結果並不是基於最新數據，這種延遲讓我們失去了做出更及時的商業決策的機會。為了解決這個問題，近幾年出現了 HTAP 的架構，這種架構允許我們對 OLTP 數據庫裡的數據直接進行分析，從而保證了分析的時效性。分析不再是傳統的 OLAP 系統或者大數據系統特有的能力，一個很自然的問題是：既然 HTAP 有了分析的能力，它是不是將取代大數據系統呢？大數據的下一站是什麼？
背景
為了回答這個問題，我們以推薦系統為例分析一下大數據系統的典型場景。
當你看到購物應用給你展示正好想要買的商品，短視頻應用播放你喜歡的音樂時，推薦系統正在發揮它神奇的作用。一個先進的推薦系統，核心目標是根據用戶的實時行為做出個性化的推薦，用戶和系統的每一次交互都將即時優化下一步的體驗。為了支持這樣一個系統，後端的大數據技術棧已經演變為一個非常複雜和多元化的系統。
下圖展示了一個支持實時推薦系統的大數據技術棧。
為了提供優質的實時個性化推薦，推薦系統重度依賴實時特徵和模型的連續更新。
實時特徵可以分為兩類：
- 系統會收集大量的用戶行為事件（比如說瀏覽、點擊等），以及交易記錄（比如說從 OLTP 數據庫同步過來的付款記錄等）。這些數據量非常巨大（可能高達每秒種數千萬甚至上億條），並且其中的絕大部分不是來自交易系統。為了方便以後使用，這些數據會導入到系統裡（圖中的 a），同時它們會和各種維表數據做關聯推導出一系列重要的特徵（圖中的 1），這些特徵會實時更新到推薦系統以優化用戶體驗。這裡的實時維表關聯需要低延遲高吞吐的點查支持才能跟得上新產生的數據。
- 系統也會使用滑動窗口等方式去計算出各種不同維度和時間粒度的特徵（比如說一個商品過去 5 分鐘的點擊數、過去 7 天的瀏覽量和過去 30 天的銷售等）。根據滑動窗口的粒度，這些聚合可能通過流計算或者批處理的方式完成。
這些數據也被用來產生實時和離線機器學習的樣本，訓練出來的模型經過驗證後會持續地更新到推薦系統中。
上述所解釋的是一個先進的推薦系統的核心部分，但這只是整個系統的冰山一角。除此之外還需要實時模型監控、驗證、分析和調優等一整套體系，這包含：使用實時大屏去查看 A/B 測試的結果（3），使用交互式分析（4）去做 BI 分析，對模型進行細化和調優。除此之外，運營還會使用各種複雜的查詢去洞察業務的進展，並且通過圈人圈品等方式進行針對性的營銷。
這個例子展示了一個非常複雜但典型的大數據場景，從數據的實時導入（a），到預聚合（b），從數據服務（1），持續聚合（3），到交互式查詢（4），一直到批處理（2）。這類複雜場景對大數據系統有著非常多樣化的需求，在構建這些系統的實踐中我們看到了兩個新的趨勢。
- 實時化：業務需要快速地從剛剛收集到的數據中獲得商業洞察。寫入的數據需要在秒級甚至亞秒級就可見。冗長的離線 ETL 過程正在變得不可容忍。同時，收集到的數據比從 OLTP 系統同步過來的數據要大得多，用戶瀏覽點擊等日誌類數據甚至要比它大幾個數量級。我們的系統需要有能力在大量實時數據寫入的同時提供低延遲的查詢能力。
- 服務 / 分析的融合：傳統的 OLAP 系統在業務中往往扮演著比較靜態的角色。我們通過分析海量的數據得到業務的洞察（比如說預計算好的視圖、模型等），這些獲得的知識通過另外一個系統提供在線數據服務。這裡的服務和分析是個割裂的過程。與此不同的是，理想的業務決策過程往往是一個持續優化的在線過程。服務的過程會產生大量的新數據，我們需要對這些新數據進行復雜的分析。分析產生的洞察實時反饋到服務創造更大的商業價值。服務和分析正在形成一個閉環。
現有的解決方案通過一系列產品的組合來解決實時的服務 / 分析融合的需求。比如說，通過 Apache Flink 做數據的實時預聚合，聚合後的數據會存儲在類似 Apache Druid 這種提供多維分析的產品中，並且通過 Apache HBase 這類產品來提供數據服務。這種煙囪式開發的模式會不可避免地產生數據孤島，從而引起不必要的數據重複，各個產品間複雜的數據同步也使數據的一致性和安全性成為挑戰。這種複雜度使得應用開發很難快速響應新需求，影響了業務的迭代速度，也給開發和運維都帶來了較大的額外開銷。
我們認為實時的服務 / 分析的融合應該通過一個統一的 Hybrid Serving/Analytical Processing（HSAP）系統來實現。
通過這樣一個系統，應用開發不再需要和多個不同的產品打交道，不再需要去學習和接受每個產品的問題和侷限，這能夠大大簡化業務的架構，提升開發和運維效率。這樣一個統一的系統能夠避免不必要的數據重複從而節約成本。同時這種架構還能夠為系統帶來秒級甚至亞秒級的實時性，讓業務的決策更實時，從而讓數據發揮出更大的商業價值。
分佈式 HTAP 系統雖然具有了實時分析的能力，但是並不能解決大數據的問題。
首先，交易系統同步過來的數據只是實時推薦系統需要處理的一小部分數據，其他絕大部分數據來自日誌等非交易系統（用戶每次購買前往往有數十個甚至數百個瀏覽行為），大部分分析是在這些非交易數據上進行的。但 HTAP 系統並沒有這部分數據，所以在這些非交易數據上做分析就無從談起。
那麼是不是可以將這些非交易數據寫入 HTAP 系統來進行分析呢？我們來分析一下 HTAP 系統和 HSAP 系統在數據寫入模式上的不同。HTAP 系統的基石和優勢是支持細粒度的分佈式事務，交易型數據往往以很多分佈式小事務的方式寫入 HTAP 系統。然而來自日誌等系統的數據並沒有細粒度分佈式事務的語意，如果要把這些非交易型數據導入 HTAP 系統勢必會帶來不必要的開銷。
相比之下， HSAP 系統並沒有這種高頻率分佈式小事務的需求。數據寫入 HSAP 系統一般有兩種模式：1）海量的單條數據實時寫入；2）相對低頻的分佈式批量數據寫入。這就允許 HSAP 系統在設計上做出一系列優化，從而提升性價比，避免把非交易型數據導入 HTAP 系統帶來的不必要開銷。
就算我們不在乎這些開銷，假設能不計成本把數據都寫入 HTAP 系統，是不是就解決問題了呢？答案仍然是否定的。
支持好 OLTP 的場景是 HTAP 系統的前提條件，為了做到這點，HTAP 系統往往採用了行存的數據格式，而分析型的查詢在行存的效率相比於列存有很大的（數量級的）劣勢。具備分析的能力和能夠高效地分析並不是一回事。為了提供高效分析的能力，HTAP 系統必須把海量的非交易數據複製到列存，但這勢必帶來不小的成本，不如把少量的交易數據複製到 HSAP 系統成本更低，同時還能更好地避免對線上交易系統產生影響。
所以，我們認為 HTAP 和 HSAP 會相輔相成，分別引領數據庫和大數據領域的方向。
HSAP 的挑戰
作為一種全新的架構，HSAP 面臨著和已有的大數據以及傳統的 OLAP 系統相比很不一樣的挑戰。
高併發的混合工作負載：HSAP 系統需要處理遠遠超出傳統的 OLAP 系統的併發查詢。在實踐中，數據服務的併發遠遠超出了 OLAP 查詢。比如說，我們在實踐中見到數據服務需要處理高達每秒鐘數千萬個查詢，這比 OLAP 查詢的併發高出了 5 個數量級。同時，和 OLAP 查詢相比，數據服務型查詢對延遲有著更加苛刻的要求。除此之外，更大的挑戰是系統在提供數據服務查詢的同時需要處理非常複雜的分析型查詢。這些混合查詢負載在延遲和吞吐間有著非常不同的取捨。如何高效地利用系統資源處理好這些非常不一樣的查詢，並且保證每個查詢的 SLO 是一個巨大的挑戰。
高吞吐實時數據導入：在處理高併發的查詢負載的同時，HSAP 系統還需要支持海量數據的實時寫入。這些實時寫入的數據量遠遠超出了傳統的 OLAP 系統的需求。比如說，上面的實時推薦場景會持續寫入每秒鐘數千萬甚至上億條事件。和傳統的 OLAP 系統的另外一個區別是 HSAP 系統對數據的實時性有著很高的要求，寫入的數據需要在秒級甚至亞秒級可見，這樣才能保證我們服務和分析結果的時效性。
彈性和可擴展性：數據寫入和查詢負載可能會有突發的高峰，這對系統提出了很高的彈性和可擴展性的要求。在實踐中，我們注意到數據寫入峰值能達到平均的 2.5 倍，查詢的峰值能達到平均的 3 倍。而且數據寫入和查詢的峰值不一定同時出現，這也需要系統有根據不同的峰值做迅速調整的能力。
HSAP 的系統設計
為了應對這些挑戰，我們認為一個典型的 HSAP 系統可以採用類似於上圖的一個架構。
存儲計算分離：所有的數據存儲在一個分佈式文件系統中，我們以數據分片的方式來擴展系統，Storage Manager 會管理這些數據分片（Shard），Resource Manager 管理系統的計算資源，保證系統能夠處理高吞吐的數據寫入和查詢的需求。這種架構能夠快速應對工作負載的變化，當查詢負載變大需要更多的計算資源的時候可以擴展計算資源，當數據量快速增長的時候可以快速擴展存儲資源。存儲計算分離的架構保證了不需要等待移動 / 拷貝數據就能快速完成這些操作。這種架構較大地簡化了運維，為系統的穩定性提供了保障。
統一的實時存儲：為了能夠支持各種查詢模式，統一的實時存儲層至關重要。查詢大體可以分為兩類，一類是簡單的點查詢（數據服務類的大多是這類），另一類是掃描大量數據的複雜查詢（分析類的大多是這類），當然這是一個連續變化的過程，很多查詢介於兩者之間。這兩種查詢模式對數據存儲也提出了不同的要求。行存儲能夠比較高效地支持點查詢，而列存儲在支持大量掃描的查詢上有明顯的優勢。我們可以通過類似 PAX 的方式在行存和列存之間做一個折衷，付出的代價是可能在點查和掃描數據的場景都不能獲得最佳的性能。我們希望在兩種場景都做到最優，所以在系統裡同時支持了行存和列存，用戶可以根據場景選擇每個表的存儲方式。對同時有兩種需求的表我們通過索引的抽象允許用戶同時選擇兩種存儲，系統通過索引維護的機制保證兩者間的一致性。在實踐中我們發現這種設計帶來的效率和靈活性能夠更好地支持業務。
工作負載的隔離：系統在混合工作負載下的 SLO 是通過調度來保證的。在理想情況下，一個大查詢就應該能把所有的資源都利用起來。而當有多個查詢同時運行的時候，這些查詢需要公平地共享資源。由於服務型的查詢通常比較簡單從而需要的資源比較少，這種公平調度的機制能夠保證服務型查詢的延遲即使在有複雜的分析型查詢的情況下仍然能夠得到保障。作為一個分佈式的系統，調度可以分為分佈式和進程內兩部分。Coordinator 會把一個查詢分解為多個任務，這些任務被分發到不同的進程，Coordinator 需要採取一定的策略保證公平性。同樣重要的是，在一個進程內我們也需要讓不同任務公平地分享資源。由於操作系統並不理解任務間的關係，所以我們在每個進程裡實現了一個用戶態的 Scheduler 去更靈活地支持工作負載的隔離。
系統的開放性：很多業務已經使用了其他存儲平臺或者計算引擎，新的系統必須考慮和已有系統的融合。對時效性要求高的查詢，計算和存儲的一體化能夠帶來明顯的優勢。但是對時效性不高的離線計算，存儲層可以提供統一的接口開放數據，這種開放性允許其他引擎把數據拉出去處理能夠賦予業務更大的靈活度。開放性的另外一面是對存儲在其他系統中數據進行處理的能力，這個可以通過聯邦查詢的方式去實現。
HSAP 的應用
這裡我們分享一下阿里巴巴搜索推薦精細化運營業務，下圖顯示了在採用 HSAP 前這樣一個系統架構的示例。
我們通過一系列存儲和計算引擎（HBase、Druid、Hive、Drill、Redis 等）的複雜配合才能滿足業務的需求，並且多個存儲之間需要通過數據同步任務來保持大致的同步。這種業務架構極其複雜，整個業務的開發耗費了大量的時間。
我們在 2019 年的雙十一使用 HSAP 系統升級了這個業務，新架構得到了極大的簡化。用戶、商品、商家屬性數據和海量的用戶行為數據經過實時和離線的數據清洗統一進入 HSAP 系統，由 HSAP 系統向上承接了實時大屏、實時報表、效果跟蹤、實時數據應用等查詢和分析服務。實時大屏、實時銷售預測、實時庫存監控、實時 BI 報表實時監測業務進展，洞悉運營增長，跟蹤算法效果，從而助力高效決策。實時標籤、實時畫像、競對分析、圈人圈品、權益投放等數據產品助力精細化運營和決策。實時數據接口服務支持算法調控、庫存監控預警等服務。一套 HSAP 系統實現了全渠道全鏈路的數據共享和複用，解決了運營、產品、算法、開發、分析師到決策層不同業務視角的數據分析和查詢需求。
總結
HSAP 架構通過統一的實時存儲，數據無需複製就能一站式提供簡單查詢、OLAP 分析、在線數據服務等多樣化的數據查詢和應用服務，滿足數據應用方的訪問和接入需求。這種新架構大大地降低了業務的複雜度，讓我們能夠快速應對新的業務需求。它提供的秒級甚至亞秒級實時性讓決策更及時高效，從而讓數據創造出更大的商業價值。
最後，歡迎加入交互式分析Hologres交流群