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

[[336209]]

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

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

背景介紹

為了回答這個問題，以下將以推薦系統為例來分析大數據系統的典型場景。

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

為了提供高質量的實時個性化推薦，推薦系統非常依賴于實時功能和模型的持續更新。

實時功能可以分為兩類：

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

這些數據還用于生成實時和離線的機器學習樣本，經過驗證的模型將在推薦系統中不斷更新。

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

這個例子展示了一個非常復雜但典型的大數據場景，從實時數據導入到預聚合，從數據服務、連續聚合、到交互式查詢再到批處理。這種復雜的場景對大數據系統的需求非常多樣化。在構建這些系統的實踐中，可以看到兩個新趨勢。

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

(2)混合服務和分析：傳統的聯機分析處理(OLAP)系統通常在業務中扮演相對靜態的角色。可以通過分析數據來獲得業務洞察力(例如預先計算的視圖和模型等)，并基于獲取的知識通過另一個系統提供在線數據服務。這里的服務和分析是一個分散的過程。與其相反，理想的業務決策過程通常是持續優化的在線過程。服務過程將生成大量新數據，需要對這些新數據進行復雜的分析。分析產生的見解會實時反饋給服務，以創造更大的商業價值。服務和分析正在形成一個閉環。

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

專家認為，實時服務/分析集成應通過統一的混合服務/分析處理(HSAP)系統實現。通過這樣一個系統，應用開發不再需要處理多個不同的產品，也不再需要學習和應用每個產品的問題和局限性，可以顯著簡化業務架構，提高開發和運行效率。這樣一個統一的系統可以避免不必要的數據重復，從而節省成本。同時，該體系結構還可以為系統帶來二級甚至亞二級的實時性能，使業務決策更加實時，從而使數據發揮更大的商業價值。

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

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

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

與其相反，混合服務/分析處理(HSAP)系統不需要這種高頻分布式的事務。混合服務/分析處理(HSAP)系統中通常有兩種數據寫入模式：

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

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

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

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

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

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

混合服務/分析處理(HSAP)面臨的挑戰

作為一種全新的架構，混合服務/分析處理(HSAP)面臨著與現有大數據和傳統聯機分析處理(OLAP)系統截然不同的挑戰。

• 高并發混合工作負載：混合服務/分析處理(HSAP)系統需要處理的并發查詢遠遠超出了傳統的聯機分析處理(OLAP)系統。

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

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

• 靈活性和可擴展性：數據寫入和查詢的負載可能會出現突發峰值，這對系統的靈活性和可擴展性提出了很高的要求。在實際應用中，注意到數據寫入的峰值可以達到平均值的2.5倍，查詢的峰值可以達到平均值的3倍。此外，數據寫入和查詢的峰值不一定同時出現，這也要求系統具有根據不同峰值進行快速調整的能力。

混合服務/分析處理(HSAP)的系統設計

為了應對這些挑戰，典型的混合服務/分析處理(HSAP)系統可以采用以上相似的架構。

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

工作負載隔離

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

系統的開放性

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

混合服務/分析處理(HSAP)的應用

以下將分享阿里巴巴集團的搜索推薦優化運營業務。

原始搜索推薦完善的運營業務架構

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

升級搜索推薦優化運營業務架構

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

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

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