大數(shù)據(jù)的下一步是什么?混合服務(wù)/分析處理(HSAP)

混合服務(wù)/分析處理(HSAP)具有強大的分析能力，那么會取代大數(shù)據(jù)技術(shù)嗎?大數(shù)據(jù)的下一步發(fā)展是什么?

由于側(cè)重點不同，傳統(tǒng)數(shù)據(jù)庫可以分為以事務(wù)為中心的聯(lián)機事務(wù)處理 (OLTP) 系統(tǒng)和以分析為中心的聯(lián)機分析處理(OLAP)系統(tǒng)。隨著國際互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)量呈指數(shù)級增長，離線數(shù)據(jù)庫已經(jīng)無法滿足企業(yè)的業(yè)務(wù)需求。特別是在分析領(lǐng)域，查詢可能需要遍歷大部分?jǐn)?shù)據(jù)甚至全部數(shù)據(jù)，而海量數(shù)據(jù)帶來的壓力使得采用新技術(shù)變得尤為緊迫。這推動了過去十年左右以Hadoop技術(shù)開始的大數(shù)據(jù)革命，并滿足了對海量數(shù)據(jù)分析的需求。與此同時，在數(shù)據(jù)庫領(lǐng)域出現(xiàn)了幾種分布式數(shù)據(jù)庫產(chǎn)品，以應(yīng)對聯(lián)機事務(wù)處理 (OLTP)場景數(shù)據(jù)的增長。

為了分析聯(lián)機事務(wù)處理 (OLTP)系統(tǒng)中的數(shù)據(jù)，標(biāo)準(zhǔn)做法是定期(例如每天)將聯(lián)機事務(wù)處理 (OLTP)系統(tǒng)中的數(shù)據(jù)同步到聯(lián)機分析處理(OLAP)系統(tǒng)。該架構(gòu)確保分析查詢不會影響在線事務(wù)處理。但是，定期同步導(dǎo)致分析結(jié)果并不是基于最新數(shù)據(jù)，并且這種延遲可能使企業(yè)失去及時做出業(yè)務(wù)決策的機會。為了解決這個問題，近年來出現(xiàn)了混合事務(wù)分析處理(HTAP)架構(gòu)，它使企業(yè)能夠直接分析聯(lián)機事務(wù)處理 (OLTP)數(shù)據(jù)庫中的數(shù)據(jù)，從而確保分析的及時性。分析不再是傳統(tǒng)聯(lián)機分析處理(OLAP)系統(tǒng)或大數(shù)據(jù)系統(tǒng)的獨特功能。那么一個問題是：由于混合事務(wù)分析處理(HTAP)具有分析能力，它將取代大數(shù)據(jù)系統(tǒng)嗎?大數(shù)據(jù)的下一站是什么?

背景介紹

為了回答這個問題，以下將以推薦系統(tǒng)為例來分析大數(shù)據(jù)系統(tǒng)的典型場景。

當(dāng)購物應(yīng)用程序推薦人們想要購買的商品，以及播放喜歡的音樂時，推薦系統(tǒng)將發(fā)揮其神奇的作用。高級推薦系統(tǒng)的核心目標(biāo)是根據(jù)用戶的實時行為進行個性化推薦。用戶與系統(tǒng)之間的每次交互都會實時優(yōu)化下一次體驗。為了支持這樣的系統(tǒng)，大數(shù)據(jù)技術(shù)堆棧已經(jīng)發(fā)展成為一個非常復(fù)雜且分散的系統(tǒng)。

為了提供高質(zhì)量的實時個性化推薦，推薦系統(tǒng)非常依賴于實時功能和模型的持續(xù)更新。

實時功能可以分為兩類：

推薦系統(tǒng)將收集大量用戶行為事件(如瀏覽、點擊等)和交易記錄(如從OLTP數(shù)據(jù)庫同步的支付記錄等)。這些數(shù)據(jù)量非常大(流量可能高達(dá)每秒數(shù)千萬甚至數(shù)億條)，而且大部分?jǐn)?shù)據(jù)都不是來自交易系統(tǒng)。為了方便以后的使用，這些數(shù)據(jù)將導(dǎo)入到系統(tǒng)中，同時將它們與各種維度表數(shù)據(jù)相關(guān)聯(lián)，推導(dǎo)出一系列重要特征，并實時更新到推薦系統(tǒng)中，優(yōu)化用戶體驗。這里的實時維度表關(guān)聯(lián)需要低延遲和高吞吐量的點檢查支持，以跟上新生成的數(shù)據(jù)。 推薦系統(tǒng)還將使用滑動窗口和其他方法來計算各種維度和時間粒度的特征(例如，過去5分鐘的點擊次數(shù)，過去7天的觀看次數(shù)，以及過去30天內(nèi)某一商品的銷售額等)。根據(jù)滑動窗口的粒度，這些聚合可以通過流計算或批處理來完成。

這些數(shù)據(jù)還用于生成實時和離線的機器學(xué)習(xí)樣本，經(jīng)過驗證的模型將在推薦系統(tǒng)中不斷更新。

以上解釋的是高級推薦系統(tǒng)的核心部分，但這只是整個系統(tǒng)的冰山一角。此外，還需要一套完整的系統(tǒng)，如實時模型監(jiān)控、驗證、分析和調(diào)整，其中包括：使用實時大屏幕查看A/B測試結(jié)果、使用交互式分析用于商業(yè)智能，以及優(yōu)化和調(diào)整模型。此外，運營部門還將使用各種復(fù)雜的查詢來深入了解業(yè)務(wù)進展情況，并利用客戶定位和產(chǎn)品推薦進行有針對性的營銷。

這個例子展示了一個非常復(fù)雜但典型的大數(shù)據(jù)場景，從實時數(shù)據(jù)導(dǎo)入到預(yù)聚合，從數(shù)據(jù)服務(wù)、連續(xù)聚合、到交互式查詢再到批處理。這種復(fù)雜的場景對大數(shù)據(jù)系統(tǒng)的需求非常多樣化。在構(gòu)建這些系統(tǒng)的實踐中，可以看到兩個新趨勢。

(1)實時：業(yè)務(wù)需要從剛剛收集的數(shù)據(jù)中快速獲得業(yè)務(wù)洞察力。寫入的數(shù)據(jù)需要在幾秒鐘內(nèi)可見。漫長的離線ETL(抽取、轉(zhuǎn)換、加載)流程變得令人無法忍受。與此同時，所收集的數(shù)據(jù)遠(yuǎn)遠(yuǎn)超過從聯(lián)機分析處理(OLAP)系統(tǒng)同步的數(shù)據(jù)，事件日志數(shù)據(jù)(例如用戶瀏覽和單擊)甚至比其大幾個數(shù)量級。企業(yè)的系統(tǒng)需要能夠提供低延遲查詢功能，同時以極高的吞吐量寫入數(shù)據(jù)。

(2)混合服務(wù)和分析：傳統(tǒng)的聯(lián)機分析處理(OLAP)系統(tǒng)通常在業(yè)務(wù)中扮演相對靜態(tài)的角色?？梢酝ㄟ^分析數(shù)據(jù)來獲得業(yè)務(wù)洞察力(例如預(yù)先計算的視圖和模型等)，并基于獲取的知識通過另一個系統(tǒng)提供在線數(shù)據(jù)服務(wù)。這里的服務(wù)和分析是一個分散的過程。與其相反，理想的業(yè)務(wù)決策過程通常是持續(xù)優(yōu)化的在線過程。服務(wù)過程將生成大量新數(shù)據(jù)，需要對這些新數(shù)據(jù)進行復(fù)雜的分析。分析產(chǎn)生的見解會實時反饋給服務(wù)，以創(chuàng)造更大的商業(yè)價值。服務(wù)和分析正在形成一個閉環(huán)。

現(xiàn)有解決方案通過一系列產(chǎn)品的組合來滿足實時服務(wù)/分析融合的需求。例如，通過Apache Flink進行數(shù)據(jù)的實時預(yù)聚合，聚合的數(shù)據(jù)將存儲在提供多維分析的產(chǎn)品(如Apache Druid)中，而數(shù)據(jù)服務(wù)將通過諸如Apache HBase之類的產(chǎn)品提供。這種煙囪開發(fā)模式將不可避免地生成數(shù)據(jù)孤島，從而導(dǎo)致不必要的數(shù)據(jù)重復(fù)。各種產(chǎn)品之間復(fù)雜的數(shù)據(jù)同步也使數(shù)據(jù)的一致性和安全性成為一個挑戰(zhàn)。這種復(fù)雜性使應(yīng)用程序開發(fā)難以快速響應(yīng)新需求，影響了業(yè)務(wù)的迭代速度，還給開發(fā)、操作和維護帶來了額外的大量開銷。

專家認(rèn)為，實時服務(wù)/分析集成應(yīng)通過統(tǒng)一的混合服務(wù)/分析處理(HSAP)系統(tǒng)實現(xiàn)。通過這樣一個系統(tǒng)，應(yīng)用開發(fā)不再需要處理多個不同的產(chǎn)品，也不再需要學(xué)習(xí)和應(yīng)用每個產(chǎn)品的問題和局限性，可以顯著簡化業(yè)務(wù)架構(gòu)，提高開發(fā)和運行效率。這樣一個統(tǒng)一的系統(tǒng)可以避免不必要的數(shù)據(jù)重復(fù)，從而節(jié)省成本。同時，該體系結(jié)構(gòu)還可以為系統(tǒng)帶來二級甚至亞二級的實時性能，使業(yè)務(wù)決策更加實時，從而使數(shù)據(jù)發(fā)揮更大的商業(yè)價值。

盡管分布式混合服務(wù)/分析處理(HSAP)系統(tǒng)具有實時分析功能，但無法解決大數(shù)據(jù)的問題。

首先，事務(wù)系統(tǒng)同步的數(shù)據(jù)只是實時推薦系統(tǒng)需要處理的數(shù)據(jù)中的一小部分。大多數(shù)其他數(shù)據(jù)來自日志等非事務(wù)系統(tǒng)(用戶在每次購買前通常有幾十甚至數(shù)百次的瀏覽行為)。大多數(shù)分析都是在這些非事務(wù)數(shù)據(jù)上進行的。但是，混合事務(wù)分析處理(HTAP)系統(tǒng)沒有這部分?jǐn)?shù)據(jù)，因此無法進行分析。

這些非事務(wù)數(shù)據(jù)能否寫入混合事務(wù)分析處理(HTAP)系統(tǒng)進行分析?以下分析一下混合事務(wù)分析處理(HTAP)系統(tǒng)和混合服務(wù)/分析處理(HSAP)系統(tǒng)在數(shù)據(jù)寫入模式上的差異。混合事務(wù)分析處理(HTAP)系統(tǒng)的基礎(chǔ)和優(yōu)勢是支持細(xì)粒度的分布式事務(wù)。事務(wù)性數(shù)據(jù)通常以許多分布式小事務(wù)的形式寫入混合事務(wù)分析處理(HTAP)系統(tǒng)。但是，來自日志和其他系統(tǒng)的數(shù)據(jù)并沒有細(xì)粒度分布式事務(wù)的語義。如果要將這些非事務(wù)性數(shù)據(jù)導(dǎo)入到混合事務(wù)分析處理(HTAP)系統(tǒng)中，必然會帶來不必要的開銷。

與其相反，混合服務(wù)/分析處理(HSAP)系統(tǒng)不需要這種高頻分布式的事務(wù)?；旌戏?wù)/分析處理(HSAP)系統(tǒng)中通常有兩種數(shù)據(jù)寫入模式：

(1)海量單筆記錄的實時寫入;

(2)頻率相對較低的分布式批處理數(shù)據(jù)寫入。

這使混合服務(wù)/分析處理(HSAP)系統(tǒng)可以進行一系列優(yōu)化設(shè)計，從而提高成本效益，并避免由于將非事務(wù)性數(shù)據(jù)導(dǎo)入混合事務(wù)分析處理(HTAP)系統(tǒng)而導(dǎo)致的不必要的開銷。

即使企業(yè)不在乎這些支出，假設(shè)可以不計成本地將所有數(shù)據(jù)寫入混合事務(wù)分析處理(HTAP)系統(tǒng)中，那么能否解決問題?其答案是否定的。

支持聯(lián)機事務(wù)處理 (OLTP)方案是混合事務(wù)分析處理(HTAP)系統(tǒng)的先決條件。為此，混合事務(wù)分析處理(HTAP)系統(tǒng)通常采用基于行存儲的數(shù)據(jù)格式，而基于行存儲中的分析查詢效率大大低于列存儲。具有分析能力并不等于能夠有效分析，為了提供有效的分析功能，混合事務(wù)分析處理(HTAP)系統(tǒng)必須將大量非事務(wù)數(shù)據(jù)復(fù)制到列存儲中，但這勢必帶來大量成本。最好以較低的成本將少量事務(wù)數(shù)據(jù)復(fù)制到混合服務(wù)/分析處理(HSAP)系統(tǒng)，同時，可以更好地避免對在線事務(wù)系統(tǒng)的影響。

因此，混合服務(wù)/分析處理(HSAP)和混合事務(wù)分析處理(HTAP)將會互補，并將分別引領(lǐng)數(shù)據(jù)庫和大數(shù)據(jù)的發(fā)展方向。

混合服務(wù)/分析處理(HSAP)面臨的挑戰(zhàn)

作為一種全新的架構(gòu)，混合服務(wù)/分析處理(HSAP)面臨著與現(xiàn)有大數(shù)據(jù)和傳統(tǒng)聯(lián)機分析處理(OLAP)系統(tǒng)截然不同的挑戰(zhàn)。

高并發(fā)混合工作負(fù)載：混合服務(wù)/分析處理(HSAP)系統(tǒng)需要處理的并發(fā)查詢遠(yuǎn)遠(yuǎn)超出了傳統(tǒng)的聯(lián)機分析處理(OLAP)系統(tǒng)。

實際上，數(shù)據(jù)服務(wù)的并發(fā)性遠(yuǎn)遠(yuǎn)超出了聯(lián)機分析處理(OLAP)查詢。例如，人們在實踐中已經(jīng)看到，數(shù)據(jù)服務(wù)每秒需要處理數(shù)千萬個查詢，這比聯(lián)機分析處理(OLAP)查詢的并發(fā)性要高出5個數(shù)量級。同時，與聯(lián)機分析處理(OLAP)查詢相比，數(shù)據(jù)服務(wù)查詢對延遲的要求更加嚴(yán)格。而且，更大的挑戰(zhàn)是系統(tǒng)在提供數(shù)據(jù)服務(wù)查詢的同時需要處理非常復(fù)雜的分析查詢。這些混合查詢有效載荷在延遲和吞吐量之間具有不同的權(quán)衡。如何有效利用系統(tǒng)資源來處理這些完全不同的查詢，并確保每個查詢的服務(wù)水平目標(biāo)(SLO)是一個巨大的挑戰(zhàn)。

混合服務(wù)/分析處理(HSAP)系統(tǒng)在處理高并發(fā)查詢負(fù)載的同時，還需要支持海量數(shù)據(jù)的實時寫入。實時寫入的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)超過了傳統(tǒng)聯(lián)機分析處理(OLAP)系統(tǒng)的要求。例如，以上實時推薦場景將持續(xù)每秒寫入數(shù)千萬甚至數(shù)億個事件。與傳統(tǒng)聯(lián)機分析處理(OLAP)系統(tǒng)的另一個區(qū)別是混合服務(wù)/分析處理(HSAP)系統(tǒng)對實時數(shù)據(jù)的要求很高。為了確保服務(wù)和分析結(jié)果的效率，其書面數(shù)據(jù)需要在幾秒鐘甚至幾秒鐘內(nèi)可見。

靈活性和可擴展性：數(shù)據(jù)寫入和查詢的負(fù)載可能會出現(xiàn)突發(fā)峰值，這對系統(tǒng)的靈活性和可擴展性提出了很高的要求。在實際應(yīng)用中，注意到數(shù)據(jù)寫入的峰值可以達(dá)到平均值的2.5倍，查詢的峰值可以達(dá)到平均值的3倍。此外，數(shù)據(jù)寫入和查詢的峰值不一定同時出現(xiàn)，這也要求系統(tǒng)具有根據(jù)不同峰值進行快速調(diào)整的能力。

混合服務(wù)/分析處理(HSAP)的系統(tǒng)設(shè)計

為了應(yīng)對這些挑戰(zhàn)，典型的混合服務(wù)/分析處理(HSAP)系統(tǒng)可以采用以上相似的架構(gòu)。

存儲和計算的存儲分解：所有數(shù)據(jù)都存儲在分布式文件系統(tǒng)中，企業(yè)通過切分來擴展系統(tǒng)。存儲管理器將管理這些碎片。資源管理器對系統(tǒng)的計算資源進行管理，保證系統(tǒng)能夠處理高吞吐量的數(shù)據(jù)寫入和查詢要求。該架構(gòu)可以隨著工作負(fù)載的變化而快速擴展，當(dāng)查詢負(fù)載變大時可以擴展計算資源，當(dāng)數(shù)據(jù)量快速增長時，可以快速擴展存儲資源。存儲和計算的分離確保了這些操作可以快速完成，而無需等待數(shù)據(jù)的移動/復(fù)制。該架構(gòu)顯著簡化了操作和維護，為系統(tǒng)的穩(wěn)定性提供了保證。 統(tǒng)一實時存儲：為了支持各種查詢模式，統(tǒng)一的實時存儲層至關(guān)重要。查詢可以大致分為兩種類型，一種是點查詢(其中大多數(shù)是數(shù)據(jù)服務(wù)類型)，另一種是掃描大量數(shù)據(jù)的復(fù)雜分析查詢(其中大多數(shù)是分析類型)。當(dāng)然，兩者之間有許多查詢。這兩種查詢類型也對數(shù)據(jù)存儲提出了不同的要求?；谛械拇鎯梢愿行У刂С贮c查詢，而列存儲在支持具有大量掃描的查詢中具有明顯的優(yōu)勢。需要在行存儲和列存儲之間做出折衷，但其代價是在檢查和掃描數(shù)據(jù)的情況下無法獲得優(yōu)質(zhì)性能。希望在兩種情況下都能達(dá)到優(yōu)質(zhì)效果，因此系統(tǒng)同時支持行存儲和列存儲，并且用戶可以根據(jù)方案選擇每個表的存儲。對于同時具有兩個需求的表，允許用戶通過索引抽象同時選擇兩種存儲，系統(tǒng)通過索引維護機制確保兩者之間的一致性。在實踐中，發(fā)現(xiàn)此設(shè)計帶來的效率和靈活性可以更好地支持業(yè)務(wù)。

工作負(fù)載隔離

通過計劃來保證在混合工作負(fù)載下系統(tǒng)的服務(wù)水平目標(biāo)(SLO)。在理想情況下，大型查詢應(yīng)該能夠利用所有資源。當(dāng)多個查詢同時運行時，這些查詢需要公平地共享資源。由于面向服務(wù)的點查找查詢通常相對簡單，并且需要較少的資源，因此這種公平的調(diào)度機制可以確保即使存在復(fù)雜的分析查詢，也仍然可以保證面向服務(wù)的查詢的等待時間。作為分布式系統(tǒng)，調(diào)度可以分為分布式調(diào)度和過程調(diào)度。協(xié)調(diào)器將查詢分解為多個任務(wù)，這些任務(wù)分配給不同的進程。協(xié)調(diào)人員需要采取某些策略來確保公平。同樣重要的是，企業(yè)還需要允許不同的任務(wù)在流程中公平地共享資源。由于操作系統(tǒng)不了解任務(wù)之間的關(guān)系，因此在每個進程中都實現(xiàn)了一個用戶狀態(tài)調(diào)度程序，以更靈活地支持工作負(fù)載隔離。

系統(tǒng)的開放性

許多企業(yè)已經(jīng)使用了其他存儲平臺或計算引擎，因此新系統(tǒng)必須考慮與現(xiàn)有系統(tǒng)的集成。查詢、計算和存儲的集成需要很高的時間效率，可以帶來明顯的優(yōu)勢。但是，對于沒有高時間效率的脫機計算，存儲層可以提供一個統(tǒng)一的接口來打開數(shù)據(jù)，這使得其他引擎能夠提取數(shù)據(jù)進行處理，并給業(yè)務(wù)帶來更大的靈活性。開放性的另一方面是處理存儲在其他系統(tǒng)中的數(shù)據(jù)的能力，這可以通過聯(lián)合查詢來實現(xiàn)。

混合服務(wù)/分析處理(HSAP)的應(yīng)用

以下將分享阿里巴巴集團的搜索推薦優(yōu)化運營業(yè)務(wù)。

原始搜索推薦完善的運營業(yè)務(wù)架構(gòu)

可以通過一系列存儲和計算引擎(HBase、Druid、Hive、Drill、Redis等)的復(fù)雜協(xié)作來滿足業(yè)務(wù)需求，多個存儲需要通過數(shù)據(jù)同步任務(wù)來保持近似同步。這種業(yè)務(wù)架構(gòu)極其復(fù)雜，整個業(yè)務(wù)架構(gòu)的開發(fā)需要大量的時間。

升級搜索推薦優(yōu)化運營業(yè)務(wù)架構(gòu)

阿里巴巴2019年的網(wǎng)站購物購買額超過2684億元人民幣(379.6億美元)，而阿里巴巴已在2019年的“雙十一”通過混合服務(wù)/分析處理(HSAP)系統(tǒng)對其業(yè)務(wù)進行了升級?；旌戏?wù)/分析處理(HSAP)系統(tǒng)總共支持1.45億個在線查詢，這進一步支持了非常復(fù)雜的業(yè)務(wù)的分析和決策過程，同時，這些分析背后還包含具有1.3億個實際數(shù)據(jù)的大規(guī)模數(shù)據(jù)記錄而不會生成冗余數(shù)據(jù)。

阿里巴巴新的架構(gòu)更加簡化。用戶、商品、商家的數(shù)據(jù)和大量用戶行為數(shù)據(jù)從在線和離線ETL進入混合服務(wù)/分析處理(HSAP)系統(tǒng)?；旌戏?wù)/分析處理(HSAP)系統(tǒng)提供查詢和分析服務(wù)，例如實時數(shù)據(jù)可視化、實時報告、效果跟蹤、實時數(shù)據(jù)應(yīng)用等。它通過提供實時數(shù)據(jù)可視化、實時銷售等服務(wù)幫助做出更好的決策。預(yù)測、實時庫存監(jiān)控、實時商業(yè)智能報告、實時監(jiān)控業(yè)務(wù)進度、監(jiān)控運營增長、跟蹤算法效果、實時標(biāo)簽、實時肖像、競爭分析、客戶定位、產(chǎn)品推薦以及獎金分配等數(shù)據(jù)產(chǎn)品有助于精確的運營和決策。實時數(shù)據(jù)服務(wù)支持算法控制、庫存監(jiān)視和預(yù)警以及其他服務(wù)。一套混合服務(wù)/分析處理(HSAP)系統(tǒng)實現(xiàn)了所有渠道和所有過程的數(shù)據(jù)共享和重用，從而從運營商、產(chǎn)品所有者、算法所有者、開發(fā)人員、分析師或高級經(jīng)理的不同業(yè)務(wù)角度解決了數(shù)據(jù)分析和查詢要求。

通過提供統(tǒng)一的實時存儲而不需要任何數(shù)據(jù)復(fù)制，混合服務(wù)/分析處理(HSAP)架構(gòu)為點查找查詢、聯(lián)機分析處理(OLAP)分析、在線數(shù)據(jù)服務(wù)以及其他各種查詢和服務(wù)提供了一站式服務(wù)。這種新的架構(gòu)顯著降低了應(yīng)用程序的復(fù)雜性，并使企業(yè)能夠快速響應(yīng)新的業(yè)務(wù)需求。實時性能中的秒級甚至亞秒級延遲使決策更加迅速和高效，從而允許數(shù)據(jù)創(chuàng)造更大的商業(yè)價值。