簡(jiǎn)介：?大數(shù)據(jù)的下一站是什么？服務(wù)/分析一體化（HSAP）

作者：蔣曉偉（量仔） 阿里巴巴研究員
因?yàn)閭?cè)重點(diǎn)的不同，傳統(tǒng)的數(shù)據(jù)庫(kù)可以分為交易型的 OLTP 系統(tǒng)和分析型的 OLAP 系統(tǒng)。隨著互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)量出現(xiàn)了指數(shù)型的增長(zhǎng)，單機(jī)的數(shù)據(jù)庫(kù)已經(jīng)不能滿足業(yè)務(wù)的需求。特別是在分析領(lǐng)域，一個(gè)查詢就可能需要處理很大一部分甚至全量數(shù)據(jù)，海量數(shù)據(jù)帶來(lái)的壓力變得尤為迫切。這促成了過(guò)去十多年來(lái)以 Hadoop 技術(shù)開(kāi)始的大數(shù)據(jù)革命，解決了海量數(shù)據(jù)分析的需求。與此同時(shí)，數(shù)據(jù)庫(kù)領(lǐng)域也出現(xiàn)了一批分布式數(shù)據(jù)庫(kù)產(chǎn)品來(lái)應(yīng)對(duì) OLTP 場(chǎng)景數(shù)據(jù)量的增長(zhǎng)。

為了對(duì) OLTP 系統(tǒng)里的數(shù)據(jù)進(jìn)行分析，標(biāo)準(zhǔn)的做法是把里面的數(shù)據(jù)定期（比如說(shuō)每天）同步到一個(gè) OLAP 系統(tǒng)中。這種架構(gòu)通過(guò)兩套系統(tǒng)保證了分析型查詢不會(huì)影響線上的交易。但是定期同步導(dǎo)致了分析的結(jié)果并不是基于最新數(shù)據(jù)，這種延遲讓我們失去了做出更及時(shí)的商業(yè)決策的機(jī)會(huì)。為了解決這個(gè)問(wèn)題，近幾年出現(xiàn)了 HTAP 的架構(gòu)，這種架構(gòu)允許我們對(duì) OLTP 數(shù)據(jù)庫(kù)里的數(shù)據(jù)直接進(jìn)行分析，從而保證了分析的時(shí)效性。分析不再是傳統(tǒng)的 OLAP 系統(tǒng)或者大數(shù)據(jù)系統(tǒng)特有的能力，一個(gè)很自然的問(wèn)題是：既然 HTAP 有了分析的能力，它是不是將取代大數(shù)據(jù)系統(tǒng)呢？大數(shù)據(jù)的下一站是什么？

背景

為了回答這個(gè)問(wèn)題，我們以推薦系統(tǒng)為例分析一下大數(shù)據(jù)系統(tǒng)的典型場(chǎng)景。
當(dāng)你看到購(gòu)物應(yīng)用給你展示正好想要買的商品，短視頻應(yīng)用播放你喜歡的音樂(lè)時(shí)，推薦系統(tǒng)正在發(fā)揮它神奇的作用。一個(gè)先進(jìn)的推薦系統(tǒng)，核心目標(biāo)是根據(jù)用戶的實(shí)時(shí)行為做出個(gè)性化的推薦，用戶和系統(tǒng)的每一次交互都將即時(shí)優(yōu)化下一步的體驗(yàn)。為了支持這樣一個(gè)系統(tǒng)，后端的大數(shù)據(jù)技術(shù)棧已經(jīng)演變?yōu)橐粋€(gè)非常復(fù)雜和多元化的系統(tǒng)。
下圖展示了一個(gè)支持實(shí)時(shí)推薦系統(tǒng)的大數(shù)據(jù)技術(shù)棧。

為了提供優(yōu)質(zhì)的實(shí)時(shí)個(gè)性化推薦，推薦系統(tǒng)重度依賴實(shí)時(shí)特征和模型的連續(xù)更新。

實(shí)時(shí)特征可以分為兩類：

系統(tǒng)會(huì)收集大量的用戶行為事件（比如說(shuō)瀏覽、點(diǎn)擊等），以及交易記錄（比如說(shuō)從 OLTP 數(shù)據(jù)庫(kù)同步過(guò)來(lái)的付款記錄等）。這些數(shù)據(jù)量非常巨大（可能高達(dá)每秒種數(shù)千萬(wàn)甚至上億條），并且其中的絕大部分不是來(lái)自交易系統(tǒng)。為了方便以后使用，這些數(shù)據(jù)會(huì)導(dǎo)入到系統(tǒng)里（圖中的 a），同時(shí)它們會(huì)和各種維表數(shù)據(jù)做關(guān)聯(lián)推導(dǎo)出一系列重要的特征（圖中的 1），這些特征會(huì)實(shí)時(shí)更新到推薦系統(tǒng)以優(yōu)化用戶體驗(yàn)。這里的實(shí)時(shí)維表關(guān)聯(lián)需要低延遲高吞吐的點(diǎn)查支持才能跟得上新產(chǎn)生的數(shù)據(jù)。

系統(tǒng)也會(huì)使用滑動(dòng)窗口等方式去計(jì)算出各種不同維度和時(shí)間粒度的特征（比如說(shuō)一個(gè)商品過(guò)去 5 分鐘的點(diǎn)擊數(shù)、過(guò)去 7 天的瀏覽量和過(guò)去 30 天的銷售等）。根據(jù)滑動(dòng)窗口的粒度，這些聚合可能通過(guò)流計(jì)算或者批處理的方式完成。

這些數(shù)據(jù)也被用來(lái)產(chǎn)生實(shí)時(shí)和離線機(jī)器學(xué)習(xí)的樣本，訓(xùn)練出來(lái)的模型經(jīng)過(guò)驗(yàn)證后會(huì)持續(xù)地更新到推薦系統(tǒng)中。

上述所解釋的是一個(gè)先進(jìn)的推薦系統(tǒng)的核心部分，但這只是整個(gè)系統(tǒng)的冰山一角。除此之外還需要實(shí)時(shí)模型監(jiān)控、驗(yàn)證、分析和調(diào)優(yōu)等一整套體系，這包含：使用實(shí)時(shí)大屏去查看 A/B 測(cè)試的結(jié)果（3），使用交互式分析（4）去做 BI 分析，對(duì)模型進(jìn)行細(xì)化和調(diào)優(yōu)。除此之外，運(yùn)營(yíng)還會(huì)使用各種復(fù)雜的查詢?nèi)ザ床鞓I(yè)務(wù)的進(jìn)展，并且通過(guò)圈人圈品等方式進(jìn)行針對(duì)性的營(yíng)銷。
這個(gè)例子展示了一個(gè)非常復(fù)雜但典型的大數(shù)據(jù)場(chǎng)景，從數(shù)據(jù)的實(shí)時(shí)導(dǎo)入（a），到預(yù)聚合（b），從數(shù)據(jù)服務(wù)（1），持續(xù)聚合（3），到交互式查詢（4），一直到批處理（2）。這類復(fù)雜場(chǎng)景對(duì)大數(shù)據(jù)系統(tǒng)有著非常多樣化的需求，在構(gòu)建這些系統(tǒng)的實(shí)踐中我們看到了兩個(gè)新的趨勢(shì)。

• 實(shí)時(shí)化：業(yè)務(wù)需要快速地從剛剛收集到的數(shù)據(jù)中獲得商業(yè)洞察。寫(xiě)入的數(shù)據(jù)需要在秒級(jí)甚至亞秒級(jí)就可見(jiàn)。冗長(zhǎng)的離線 ETL 過(guò)程正在變得不可容忍。同時(shí)，收集到的數(shù)據(jù)比從 OLTP 系統(tǒng)同步過(guò)來(lái)的數(shù)據(jù)要大得多，用戶瀏覽點(diǎn)擊等日志類數(shù)據(jù)甚至要比它大幾個(gè)數(shù)量級(jí)。我們的系統(tǒng)需要有能力在大量實(shí)時(shí)數(shù)據(jù)寫(xiě)入的同時(shí)提供低延遲的查詢能力。
  
• 服務(wù) / 分析的融合：傳統(tǒng)的 OLAP 系統(tǒng)在業(yè)務(wù)中往往扮演著比較靜態(tài)的角色。我們通過(guò)分析海量的數(shù)據(jù)得到業(yè)務(wù)的洞察（比如說(shuō)預(yù)計(jì)算好的視圖、模型等），這些獲得的知識(shí)通過(guò)另外一個(gè)系統(tǒng)提供在線數(shù)據(jù)服務(wù)。這里的服務(wù)和分析是個(gè)割裂的過(guò)程。與此不同的是，理想的業(yè)務(wù)決策過(guò)程往往是一個(gè)持續(xù)優(yōu)化的在線過(guò)程。服務(wù)的過(guò)程會(huì)產(chǎn)生大量的新數(shù)據(jù)，我們需要對(duì)這些新數(shù)據(jù)進(jìn)行復(fù)雜的分析。分析產(chǎn)生的洞察實(shí)時(shí)反饋到服務(wù)創(chuàng)造更大的商業(yè)價(jià)值。服務(wù)和分析正在形成一個(gè)閉環(huán)。

現(xiàn)有的解決方案通過(guò)一系列產(chǎn)品的組合來(lái)解決實(shí)時(shí)的服務(wù) / 分析融合的需求。比如說(shuō)，通過(guò) Apache Flink 做數(shù)據(jù)的實(shí)時(shí)預(yù)聚合，聚合后的數(shù)據(jù)會(huì)存儲(chǔ)在類似 Apache Druid 這種提供多維分析的產(chǎn)品中，并且通過(guò) Apache HBase 這類產(chǎn)品來(lái)提供數(shù)據(jù)服務(wù)。這種煙囪式開(kāi)發(fā)的模式會(huì)不可避免地產(chǎn)生數(shù)據(jù)孤島，從而引起不必要的數(shù)據(jù)重復(fù)，各個(gè)產(chǎn)品間復(fù)雜的數(shù)據(jù)同步也使數(shù)據(jù)的一致性和安全性成為挑戰(zhàn)。這種復(fù)雜度使得應(yīng)用開(kāi)發(fā)很難快速響應(yīng)新需求，影響了業(yè)務(wù)的迭代速度，也給開(kāi)發(fā)和運(yùn)維都帶來(lái)了較大的額外開(kāi)銷。


我們認(rèn)為實(shí)時(shí)的服務(wù) / 分析的融合應(yīng)該通過(guò)一個(gè)統(tǒng)一的 Hybrid Serving/Analytical Processing（HSAP）系統(tǒng)來(lái)實(shí)現(xiàn)。
通過(guò)這樣一個(gè)系統(tǒng)，應(yīng)用開(kāi)發(fā)不再需要和多個(gè)不同的產(chǎn)品打交道，不再需要去學(xué)習(xí)和接受每個(gè)產(chǎn)品的問(wèn)題和局限，這能夠大大簡(jiǎn)化業(yè)務(wù)的架構(gòu)，提升開(kāi)發(fā)和運(yùn)維效率。這樣一個(gè)統(tǒng)一的系統(tǒng)能夠避免不必要的數(shù)據(jù)重復(fù)從而節(jié)約成本。同時(shí)這種架構(gòu)還能夠?yàn)橄到y(tǒng)帶來(lái)秒級(jí)甚至亞秒級(jí)的實(shí)時(shí)性，讓業(yè)務(wù)的決策更實(shí)時(shí)，從而讓數(shù)據(jù)發(fā)揮出更大的商業(yè)價(jià)值。

分布式 HTAP 系統(tǒng)雖然具有了實(shí)時(shí)分析的能力，但是并不能解決大數(shù)據(jù)的問(wèn)題。

首先，交易系統(tǒng)同步過(guò)來(lái)的數(shù)據(jù)只是實(shí)時(shí)推薦系統(tǒng)需要處理的一小部分?jǐn)?shù)據(jù)，其他絕大部分?jǐn)?shù)據(jù)來(lái)自日志等非交易系統(tǒng)（用戶每次購(gòu)買前往往有數(shù)十個(gè)甚至數(shù)百個(gè)瀏覽行為），大部分分析是在這些非交易數(shù)據(jù)上進(jìn)行的。但 HTAP 系統(tǒng)并沒(méi)有這部分?jǐn)?shù)據(jù)，所以在這些非交易數(shù)據(jù)上做分析就無(wú)從談起。
那么是不是可以將這些非交易數(shù)據(jù)寫(xiě)入 HTAP 系統(tǒng)來(lái)進(jìn)行分析呢？我們來(lái)分析一下 HTAP 系統(tǒng)和 HSAP 系統(tǒng)在數(shù)據(jù)寫(xiě)入模式上的不同。HTAP 系統(tǒng)的基石和優(yōu)勢(shì)是支持細(xì)粒度的分布式事務(wù)，交易型數(shù)據(jù)往往以很多分布式小事務(wù)的方式寫(xiě)入 HTAP 系統(tǒng)。然而來(lái)自日志等系統(tǒng)的數(shù)據(jù)并沒(méi)有細(xì)粒度分布式事務(wù)的語(yǔ)意，如果要把這些非交易型數(shù)據(jù)導(dǎo)入 HTAP 系統(tǒng)勢(shì)必會(huì)帶來(lái)不必要的開(kāi)銷。
相比之下， HSAP 系統(tǒng)并沒(méi)有這種高頻率分布式小事務(wù)的需求。數(shù)據(jù)寫(xiě)入 HSAP 系統(tǒng)一般有兩種模式：1）海量的單條數(shù)據(jù)實(shí)時(shí)寫(xiě)入；2）相對(duì)低頻的分布式批量數(shù)據(jù)寫(xiě)入。這就允許 HSAP 系統(tǒng)在設(shè)計(jì)上做出一系列優(yōu)化，從而提升性價(jià)比，避免把非交易型數(shù)據(jù)導(dǎo)入 HTAP 系統(tǒng)帶來(lái)的不必要開(kāi)銷。
就算我們不在乎這些開(kāi)銷，假設(shè)能不計(jì)成本把數(shù)據(jù)都寫(xiě)入 HTAP 系統(tǒng)，是不是就解決問(wèn)題了呢？答案仍然是否定的。
支持好 OLTP 的場(chǎng)景是 HTAP 系統(tǒng)的前提條件，為了做到這點(diǎn)，HTAP 系統(tǒng)往往采用了行存的數(shù)據(jù)格式，而分析型的查詢?cè)谛写娴男氏啾扔诹写嬗泻艽蟮?#xff08;數(shù)量級(jí)的）劣勢(shì)。具備分析的能力和能夠高效地分析并不是一回事。為了提供高效分析的能力，HTAP 系統(tǒng)必須把海量的非交易數(shù)據(jù)復(fù)制到列存，但這勢(shì)必帶來(lái)不小的成本，不如把少量的交易數(shù)據(jù)復(fù)制到 HSAP 系統(tǒng)成本更低，同時(shí)還能更好地避免對(duì)線上交易系統(tǒng)產(chǎn)生影響。
所以，我們認(rèn)為 HTAP 和 HSAP 會(huì)相輔相成，分別引領(lǐng)數(shù)據(jù)庫(kù)和大數(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 查詢。比如說(shuō)，我們?cè)趯?shí)踐中見(jiàn)到數(shù)據(jù)服務(wù)需要處理高達(dá)每秒鐘數(shù)千萬(wàn)個(gè)查詢，這比 OLAP 查詢的并發(fā)高出了 5 個(gè)數(shù)量級(jí)。同時(shí)，和 OLAP 查詢相比，數(shù)據(jù)服務(wù)型查詢對(duì)延遲有著更加苛刻的要求。除此之外，更大的挑戰(zhàn)是系統(tǒng)在提供數(shù)據(jù)服務(wù)查詢的同時(shí)需要處理非常復(fù)雜的分析型查詢。這些混合查詢負(fù)載在延遲和吞吐間有著非常不同的取舍。如何高效地利用系統(tǒng)資源處理好這些非常不一樣的查詢，并且保證每個(gè)查詢的 SLO 是一個(gè)巨大的挑戰(zhàn)。

高吞吐實(shí)時(shí)數(shù)據(jù)導(dǎo)入：在處理高并發(fā)的查詢負(fù)載的同時(shí)，HSAP 系統(tǒng)還需要支持海量數(shù)據(jù)的實(shí)時(shí)寫(xiě)入。這些實(shí)時(shí)寫(xiě)入的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)超出了傳統(tǒng)的 OLAP 系統(tǒng)的需求。比如說(shuō)，上面的實(shí)時(shí)推薦場(chǎng)景會(huì)持續(xù)寫(xiě)入每秒鐘數(shù)千萬(wàn)甚至上億條事件。和傳統(tǒng)的 OLAP 系統(tǒng)的另外一個(gè)區(qū)別是 HSAP 系統(tǒng)對(duì)數(shù)據(jù)的實(shí)時(shí)性有著很高的要求，寫(xiě)入的數(shù)據(jù)需要在秒級(jí)甚至亞秒級(jí)可見(jiàn)，這樣才能保證我們服務(wù)和分析結(jié)果的時(shí)效性。

彈性和可擴(kuò)展性：數(shù)據(jù)寫(xiě)入和查詢負(fù)載可能會(huì)有突發(fā)的高峰，這對(duì)系統(tǒng)提出了很高的彈性和可擴(kuò)展性的要求。在實(shí)踐中，我們注意到數(shù)據(jù)寫(xiě)入峰值能達(dá)到平均的 2.5 倍，查詢的峰值能達(dá)到平均的 3 倍。而且數(shù)據(jù)寫(xiě)入和查詢的峰值不一定同時(shí)出現(xiàn)，這也需要系統(tǒng)有根據(jù)不同的峰值做迅速調(diào)整的能力。

HSAP 的系統(tǒng)設(shè)計(jì)

為了應(yīng)對(duì)這些挑戰(zhàn)，我們認(rèn)為一個(gè)典型的 HSAP 系統(tǒng)可以采用類似于上圖的一個(gè)架構(gòu)。

存儲(chǔ)計(jì)算分離：所有的數(shù)據(jù)存儲(chǔ)在一個(gè)分布式文件系統(tǒng)中，我們以數(shù)據(jù)分片的方式來(lái)擴(kuò)展系統(tǒng)，Storage Manager 會(huì)管理這些數(shù)據(jù)分片（Shard），Resource Manager 管理系統(tǒng)的計(jì)算資源，保證系統(tǒng)能夠處理高吞吐的數(shù)據(jù)寫(xiě)入和查詢的需求。這種架構(gòu)能夠快速應(yīng)對(duì)工作負(fù)載的變化，當(dāng)查詢負(fù)載變大需要更多的計(jì)算資源的時(shí)候可以擴(kuò)展計(jì)算資源，當(dāng)數(shù)據(jù)量快速增長(zhǎng)的時(shí)候可以快速擴(kuò)展存儲(chǔ)資源。存儲(chǔ)計(jì)算分離的架構(gòu)保證了不需要等待移動(dòng) / 拷貝數(shù)據(jù)就能快速完成這些操作。這種架構(gòu)較大地簡(jiǎn)化了運(yùn)維，為系統(tǒng)的穩(wěn)定性提供了保障。

統(tǒng)一的實(shí)時(shí)存儲(chǔ)：為了能夠支持各種查詢模式，統(tǒng)一的實(shí)時(shí)存儲(chǔ)層至關(guān)重要。查詢大體可以分為兩類，一類是簡(jiǎn)單的點(diǎn)查詢（數(shù)據(jù)服務(wù)類的大多是這類），另一類是掃描大量數(shù)據(jù)的復(fù)雜查詢（分析類的大多是這類），當(dāng)然這是一個(gè)連續(xù)變化的過(guò)程，很多查詢介于兩者之間。這兩種查詢模式對(duì)數(shù)據(jù)存儲(chǔ)也提出了不同的要求。行存儲(chǔ)能夠比較高效地支持點(diǎn)查詢，而列存儲(chǔ)在支持大量掃描的查詢上有明顯的優(yōu)勢(shì)。我們可以通過(guò)類似 PAX 的方式在行存和列存之間做一個(gè)折衷，付出的代價(jià)是可能在點(diǎn)查和掃描數(shù)據(jù)的場(chǎng)景都不能獲得最佳的性能。我們希望在兩種場(chǎng)景都做到最優(yōu)，所以在系統(tǒng)里同時(shí)支持了行存和列存，用戶可以根據(jù)場(chǎng)景選擇每個(gè)表的存儲(chǔ)方式。對(duì)同時(shí)有兩種需求的表我們通過(guò)索引的抽象允許用戶同時(shí)選擇兩種存儲(chǔ)，系統(tǒng)通過(guò)索引維護(hù)的機(jī)制保證兩者間的一致性。在實(shí)踐中我們發(fā)現(xiàn)這種設(shè)計(jì)帶來(lái)的效率和靈活性能夠更好地支持業(yè)務(wù)。

工作負(fù)載的隔離：系統(tǒng)在混合工作負(fù)載下的 SLO 是通過(guò)調(diào)度來(lái)保證的。在理想情況下，一個(gè)大查詢就應(yīng)該能把所有的資源都利用起來(lái)。而當(dāng)有多個(gè)查詢同時(shí)運(yùn)行的時(shí)候，這些查詢需要公平地共享資源。由于服務(wù)型的查詢通常比較簡(jiǎn)單從而需要的資源比較少，這種公平調(diào)度的機(jī)制能夠保證服務(wù)型查詢的延遲即使在有復(fù)雜的分析型查詢的情況下仍然能夠得到保障。作為一個(gè)分布式的系統(tǒng)，調(diào)度可以分為分布式和進(jìn)程內(nèi)兩部分。Coordinator 會(huì)把一個(gè)查詢分解為多個(gè)任務(wù)，這些任務(wù)被分發(fā)到不同的進(jìn)程，Coordinator 需要采取一定的策略保證公平性。同樣重要的是，在一個(gè)進(jìn)程內(nèi)我們也需要讓不同任務(wù)公平地分享資源。由于操作系統(tǒng)并不理解任務(wù)間的關(guān)系，所以我們?cè)诿總€(gè)進(jìn)程里實(shí)現(xiàn)了一個(gè)用戶態(tài)的 Scheduler 去更靈活地支持工作負(fù)載的隔離。

系統(tǒng)的開(kāi)放性：很多業(yè)務(wù)已經(jīng)使用了其他存儲(chǔ)平臺(tái)或者計(jì)算引擎，新的系統(tǒng)必須考慮和已有系統(tǒng)的融合。對(duì)時(shí)效性要求高的查詢，計(jì)算和存儲(chǔ)的一體化能夠帶來(lái)明顯的優(yōu)勢(shì)。但是對(duì)時(shí)效性不高的離線計(jì)算，存儲(chǔ)層可以提供統(tǒng)一的接口開(kāi)放數(shù)據(jù)，這種開(kāi)放性允許其他引擎把數(shù)據(jù)拉出去處理能夠賦予業(yè)務(wù)更大的靈活度。開(kāi)放性的另外一面是對(duì)存儲(chǔ)在其他系統(tǒng)中數(shù)據(jù)進(jìn)行處理的能力，這個(gè)可以通過(guò)聯(lián)邦查詢的方式去實(shí)現(xiàn)。

HSAP 的應(yīng)用

這里我們分享一下阿里巴巴搜索推薦精細(xì)化運(yùn)營(yíng)業(yè)務(wù)，下圖顯示了在采用 HSAP 前這樣一個(gè)系統(tǒng)架構(gòu)的示例。

我們通過(guò)一系列存儲(chǔ)和計(jì)算引擎（HBase、Druid、Hive、Drill、Redis 等）的復(fù)雜配合才能滿足業(yè)務(wù)的需求，并且多個(gè)存儲(chǔ)之間需要通過(guò)數(shù)據(jù)同步任務(wù)來(lái)保持大致的同步。這種業(yè)務(wù)架構(gòu)極其復(fù)雜，整個(gè)業(yè)務(wù)的開(kāi)發(fā)耗費(fèi)了大量的時(shí)間。

我們?cè)?2019 年的雙十一使用 HSAP 系統(tǒng)升級(jí)了這個(gè)業(yè)務(wù)，新架構(gòu)得到了極大的簡(jiǎn)化。用戶、商品、商家屬性數(shù)據(jù)和海量的用戶行為數(shù)據(jù)經(jīng)過(guò)實(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ù)測(cè)、實(shí)時(shí)庫(kù)存監(jiān)控、實(shí)時(shí) BI 報(bào)表實(shí)時(shí)監(jiān)測(cè)業(yè)務(wù)進(jìn)展，洞悉運(yùn)營(yíng)增長(zhǎng)，跟蹤算法效果，從而助力高效決策。實(shí)時(shí)標(biāo)簽、實(shí)時(shí)畫(huà)像、競(jìng)對(duì)分析、圈人圈品、權(quán)益投放等數(shù)據(jù)產(chǎn)品助力精細(xì)化運(yùn)營(yíng)和決策。實(shí)時(shí)數(shù)據(jù)接口服務(wù)支持算法調(diào)控、庫(kù)存監(jiān)控預(yù)警等服務(wù)。一套 HSAP 系統(tǒng)實(shí)現(xiàn)了全渠道全鏈路的數(shù)據(jù)共享和復(fù)用，解決了運(yùn)營(yíng)、產(chǎn)品、算法、開(kāi)發(fā)、分析師到?jīng)Q策層不同業(yè)務(wù)視角的數(shù)據(jù)分析和查詢需求。

總結(jié)

HSAP 架構(gòu)通過(guò)統(tǒng)一的實(shí)時(shí)存儲(chǔ)，數(shù)據(jù)無(wú)需復(fù)制就能一站式提供簡(jiǎn)單查詢、OLAP 分析、在線數(shù)據(jù)服務(wù)等多樣化的數(shù)據(jù)查詢和應(yīng)用服務(wù)，滿足數(shù)據(jù)應(yīng)用方的訪問(wèn)和接入需求。這種新架構(gòu)大大地降低了業(yè)務(wù)的復(fù)雜度，讓我們能夠快速應(yīng)對(duì)新的業(yè)務(wù)需求。它提供的秒級(jí)甚至亞秒級(jí)實(shí)時(shí)性讓決策更及時(shí)高效，從而讓數(shù)據(jù)創(chuàng)造出更大的商業(yè)價(jià)值。

總結(jié)

以上是生活随笔為你收集整理的大数据的下一站是什么？服务/分析一体化（HSAP）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。