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