作者：蔣曉偉（量仔） 阿裡巴巴研究員
因為側重點的不同，傳統的資料庫可以分為交易型的 OLTP 系統和分析型的 OLAP 系統。随着網際網路的發展，資料量出現了指數型的增長，單機的資料庫已經不能滿足業務的需求。特别是在分析領域，一個查詢就可能需要處理很大一部分甚至全量資料，海量資料帶來的壓力變得尤為迫切。這促成了過去十多年來以 Hadoop 技術開始的大資料革命，解決了海量資料分析的需求。與此同時，資料庫領域也出現了一批分布式資料庫産品來應對 OLTP 場景資料量的增長。
背景
為了回答這個問題，我們以推薦系統為例分析一下大資料系統的典型場景。
當你看到購物應用給你展示正好想要買的商品，短視訊應用播放你喜歡的音樂時，推薦系統正在發揮它神奇的作用。一個先進的推薦系統，核心目标是根據使用者的實時行為做出個性化的推薦，使用者和系統的每一次互動都将即時優化下一步的體驗。為了支援這樣一個系統，後端的大資料技術棧已經演變為一個非常複雜和多元化的系統。
下圖展示了一個支援實時推薦系統的大資料技術棧。
為了提供優質的實時個性化推薦，推薦系統重度依賴實時特征和模型的連續更新。
實時特征可以分為兩類：
- 系統會收集大量的使用者行為事件（比如說浏覽、點選等），以及交易記錄（比如說從 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 分析、線上資料服務等多樣化的資料查詢和應用服務，滿足資料應用方的通路和接入需求。這種新架構大大地降低了業務的複雜度，讓我們能夠快速應對新的業務需求。它提供的秒級甚至亞秒級實時性讓決策更及時高效，進而讓資料創造出更大的商業價值。