簡介：本文重點介紹Hologres如何幫助阿里巴巴客戶體驗部（CCO），構(gòu)建集實時化、自助化、系統(tǒng)化于一體的用戶體驗實時數(shù)倉，完美助力雙11場景，支持上千+服務(wù)大屏，削峰30%，節(jié)約成本近30%。

剛剛結(jié)束的2020天貓雙11中，MaxCompute交互式分析（下稱Hologres）+實時計算Flink搭建的云原生實時數(shù)倉首次在核心數(shù)據(jù)場景落地，為大數(shù)據(jù)平臺創(chuàng)下一項新紀(jì)錄。借此之際，我們將陸續(xù)推出云原生實時數(shù)倉雙11實戰(zhàn)系列內(nèi)容，本文重點介紹Hologres如何幫助阿里巴巴客戶體驗部（CCO），構(gòu)建集實時化、自助化、系統(tǒng)化于一體的用戶體驗實時數(shù)倉，完美助力雙11場景，支持上千+服務(wù)大屏，削峰30%，節(jié)約成本近30%。

作者：映海（任海峰），阿里巴巴CCO數(shù)據(jù)應(yīng)用中臺實時技術(shù)負(fù)責(zé)人

客戶簡介

CCO是Chief Customer Officer的縮寫，也是阿里巴巴集團(tuán)客戶體驗事業(yè)部的簡稱。在阿里巴巴經(jīng)濟(jì)體內(nèi)，CCO是“客戶第一”價值觀落地的組織保障，是整個經(jīng)濟(jì)體客戶體驗的神經(jīng)網(wǎng)絡(luò)，也是觸達(dá)消費者和商家的最前線。“成為新商業(yè)的服務(wù)生態(tài)搖籃”，“讓體驗成為商業(yè)的核心競爭力”是我們的愿景。憑借著為消費者、商家和經(jīng)濟(jì)體提供專業(yè)服務(wù)的小二，為平臺不斷挖掘存量客戶價值的體驗運營專家，為業(yè)務(wù)發(fā)展提供底層支撐的數(shù)據(jù)、產(chǎn)品和技術(shù)人才，我們成為了互聯(lián)網(wǎng)行業(yè)獨一無二的數(shù)字化服務(wù)體驗團(tuán)隊 —— 一支有愛有擔(dān)當(dāng)，富有創(chuàng)造力的“阿里柔軍”。

業(yè)務(wù)背景

從2016年開始CCO開始將實時數(shù)據(jù)應(yīng)用到業(yè)務(wù)中，一開始主要支撐雙十一作戰(zhàn)室大屏應(yīng)用。（注：雙11作戰(zhàn)室又名光明頂，是阿里巴巴雙11期間的總指揮室，其作戰(zhàn)大屏承載了全集團(tuán)雙11期間的作戰(zhàn)指揮系統(tǒng)，是阿里巴巴作戰(zhàn)組織的技術(shù)、產(chǎn)品、服務(wù)串聯(lián)起來的“作戰(zhàn)指揮圖”。）
2017年實時數(shù)據(jù)應(yīng)用出現(xiàn)了規(guī)模化的上漲，不再局限于大促，在日常的客服小二管理實時監(jiān)控、對內(nèi)運營數(shù)據(jù)產(chǎn)品、線上產(chǎn)品數(shù)據(jù)應(yīng)用及算法模型在線應(yīng)用場景中開始大規(guī)模應(yīng)用。2018年開始整體實時數(shù)據(jù)任務(wù)高保障作業(yè)數(shù)已經(jīng)接近400，大促中，雙十一指揮室大屏也全面取消了準(zhǔn)實時的應(yīng)用，全面實時化落地，截止到目前，實時作業(yè)數(shù)已經(jīng)超過800+。從作業(yè)的規(guī)模、各類引擎中間件的使用、業(yè)務(wù)場景的覆蓋發(fā)展到非常多元化的一個階段。

整體上CCO在實時數(shù)據(jù)的應(yīng)用上呈現(xiàn)出幾個特點：

• 數(shù)據(jù)復(fù)雜度高，覆蓋了從用戶加購、下單、支付到售后退款等全渠道的業(yè)務(wù)場景及數(shù)據(jù)依賴。
• 數(shù)據(jù)量大，從手淘日志（千萬/s 峰值）到交易（幾百萬/s 峰值）到咨詢（幾十萬/s 峰值）。
• 應(yīng)用場景豐富，實時監(jiān)控大屏，實時交互式分析數(shù)據(jù)產(chǎn)品，To B/C類的線上應(yīng)用。

伴隨著場景的豐富、數(shù)據(jù)量的劇增以及業(yè)務(wù)端不斷變化的查詢要求等，既要快速響應(yīng)業(yè)務(wù)需求提供高可靠和低延時的數(shù)據(jù)服務(wù)，又要保證系統(tǒng)不斷的平穩(wěn)運行，其背后的技術(shù)系統(tǒng)不斷受到挑戰(zhàn)。

實時技術(shù)架構(gòu)演進(jìn)歷程

CCO的實時架構(gòu)演進(jìn)分為三個階段：數(shù)據(jù)庫階段、傳統(tǒng)數(shù)據(jù)倉庫階段、實時數(shù)倉階段。

1）數(shù)據(jù)庫階段

第一個階段為數(shù)據(jù)庫階段，采用典型的Lambda架構(gòu)，數(shù)據(jù)從采集->加工->服務(wù)，根據(jù)業(yè)務(wù)場景煙囪化建設(shè)，在數(shù)據(jù)架構(gòu)上不做分層，以任務(wù)為單位來支撐對應(yīng)的應(yīng)用場景，將數(shù)據(jù)全部預(yù)處理完畢，存儲到OLTP和KV引擎，直接通過Point Query提供對外服務(wù)。
在數(shù)據(jù)處理層，通過Flink多流Join，通過Hbase做維表關(guān)聯(lián)，將流式數(shù)據(jù)預(yù)處理到指定粒度，持久化到數(shù)據(jù)庫中并提供對應(yīng)服務(wù)。
在場景少、任務(wù)少的情況下，這種end to end的建設(shè)方式，既靈活又節(jié)省成本，并且能提供較高QPS低RT的服務(wù)能力。但隨著業(yè)務(wù)場景的復(fù)雜度增加，運維開發(fā)成本越來越大，全部采用預(yù)處理并且每個開發(fā)同學(xué)都需要從源頭end to end加工的方式已經(jīng)不能適應(yīng)業(yè)務(wù)的變化。

2）傳統(tǒng)數(shù)據(jù)倉庫階段

隨著實時數(shù)據(jù)應(yīng)用的規(guī)格上線，以及數(shù)據(jù)庫階段的明顯痛點，發(fā)展到了傳統(tǒng)數(shù)據(jù)倉庫階段。傳統(tǒng)數(shù)據(jù)倉庫階段架構(gòu)的優(yōu)化點如下：

• 引入OLAP引擎：小數(shù)據(jù)量的明細(xì)、輕度匯總等數(shù)據(jù)統(tǒng)一存儲到AnalyticDB，支持較高QPS的OLAP Query。
• 數(shù)據(jù)模型及任務(wù)加工分層：在DWD層按照主題將不同數(shù)據(jù)源數(shù)據(jù)整合，并且輸出到Lindorm，然后通過Hlog訂閱，觸發(fā)流任務(wù)反查事實表，將寬表字段對齊輸出到TT，做為DWD中間層存儲。構(gòu)建可復(fù)用的DWS層，將常用維度及指標(biāo)按照主題建模，供下游復(fù)用，減少煙囪化。

通過引入數(shù)據(jù)倉庫的分層架構(gòu)以及MPP的技術(shù)，增強了整個實時數(shù)據(jù)架構(gòu)的靈活性和數(shù)據(jù)的復(fù)用性，但隨著數(shù)據(jù)體量和規(guī)模的增加，我們發(fā)現(xiàn)，任務(wù)量在規(guī)模化膨脹，引擎成本在逐年增加，我們構(gòu)建的數(shù)倉中的數(shù)據(jù)并沒有真正意義上流轉(zhuǎn)起來，由于存儲的多樣，服務(wù)的多樣，造成不可避免的在不同的任務(wù)和引擎中冗余大量的煙囪化的業(yè)務(wù)邏輯和數(shù)據(jù)。

為了解決業(yè)務(wù)對穩(wěn)定性SLA不同級別的要求，我們將KV引擎和OLAP引擎按照業(yè)務(wù)保障等級做了實例拆分和資源隔離，在保障提升的同時，我們不得不將已經(jīng)加工過的數(shù)據(jù)，重復(fù)加工，并且寫入到不同的實例和引擎中去，這就使得數(shù)據(jù)有非常多的冗余，且多個系統(tǒng)也帶來高額的運維開發(fā)成本。

3）實時數(shù)倉階段

傳統(tǒng)數(shù)據(jù)倉庫階段，隨著任務(wù)規(guī)模的持續(xù)增長，數(shù)據(jù)開發(fā)同學(xué)需要維護(hù)多個任務(wù)作業(yè)，同時業(yè)務(wù)應(yīng)用對實時數(shù)據(jù)的訴求也越來越強，于是，一系列的數(shù)據(jù)開發(fā)問題逐漸呈現(xiàn)，例如開發(fā)效率如何提升，數(shù)據(jù)復(fù)用性如何提高，數(shù)據(jù)成本如何降低？這也就使得我們不得不對數(shù)據(jù)倉庫階段的技術(shù)架構(gòu)不斷優(yōu)化和演進(jìn)，隨之而來的就是第3階段--實時數(shù)倉階段。

首先我們來分析一下，傳統(tǒng)數(shù)據(jù)倉庫演進(jìn)為實時數(shù)倉最主要的困難點：

• 任務(wù)重復(fù)建設(shè)：常用的做法就是按照業(yè)務(wù)場景分拆實例，按照保障等級分拆實例，按照不同服務(wù)形式路由到不同的引擎，比如KV/OLAP。任務(wù)不得不重復(fù)建設(shè)，需要在重復(fù)建設(shè)和穩(wěn)定性上做出權(quán)衡。在實踐中，我們往往選擇了第二或者第三種方式來優(yōu)先保障穩(wěn)定性，由于在同一任務(wù)中增加多個SINK到不同實例，任何一個實例有問題，都會造成整個任務(wù)背壓或者failover，會影響到其它實例的穩(wěn)定性。

• 數(shù)據(jù)存儲冗余：實際場景中，我們需要提供Point Query，Adhoc Query，Olap Query等多種服務(wù)形式，我們需要至少在KV存儲和MPP存儲中存放兩份，造成非常多不必要存儲，存儲成本也只增不降。
• 元數(shù)據(jù)管理：在傳統(tǒng)的KV引擎上，由于schema free的特點，我們無法友好并且高效的管理我們的表及字段的元數(shù)據(jù)信息。
• 加工鏈路復(fù)雜： 其中兩個典型場景是，一是對于dwd層寬表的字段對齊問題，目前只能通過Lindorm的KV特性，可以多個不同的流根據(jù)同一PK進(jìn)行更新，然后通過Hlog捕捉到對應(yīng)PK的每次變化，然后觸發(fā)流對Lindorm寬表的反查，再將整行記錄下發(fā)。二是寫入到MPP引擎的數(shù)據(jù)，往往由于MPP引擎不支持寫入數(shù)據(jù)的重新訂閱消費，造成必須在上游任務(wù)增加SINK，寫入到消息中間件，然后才能支持二次消費，一定程度上也增加了鏈路的復(fù)雜度。

實時數(shù)倉架構(gòu)

鑒于以上建設(shè)實時數(shù)倉的困難點和迫切性，我們也在一直調(diào)研和探索究竟有什么產(chǎn)品能夠有能力解決這些問題。也是某個契機了解到了Hologres，Hologres的定位是服務(wù)和分析一體化，這一點也很符合我們后期的技術(shù)規(guī)劃方向。通過跟團(tuán)隊的深入溝通以及前期產(chǎn)品的深度測試，最終選定了Hologres來作為實時數(shù)倉的主要載體。為什么要選擇Hologres呢？，Hologres有哪些優(yōu)秀的能力可以落地在CCO的場景中呢？

• 支持行存列存，HSAP的混合服務(wù)能力：針對現(xiàn)有的Point Query的場景，可以采取行存方式存儲，針對典型的OLAP場景，可以采取列存方式存儲。
• 高吞吐的實時寫入：經(jīng)過實際測試，對于行存的寫入，目前可以滿足我們業(yè)務(wù)上千萬/s的吞吐要求，在列存的OLAP場景上，可以輕松應(yīng)對我們幾十萬/s的高聚合數(shù)據(jù)寫入要求。
• 行存的日志訂閱以及維表關(guān)聯(lián)能力：我們寫入Hologres行存表的數(shù)據(jù)，可以通過Binlog訂閱，通過Hologres connector，輕松應(yīng)用Flink的任務(wù)開發(fā)中，將公共層明細(xì)數(shù)據(jù)有選擇的進(jìn)行二次計算，并寫入回Hologres，提供給不同的應(yīng)用場景，一定程度上解決了Hologres引擎和Blink引擎計算的算力平衡和高QPS的相應(yīng)問題。
• 云原生：支持彈性擴(kuò)縮容和高度可擴(kuò)展性，今年大促我們在幾分鐘內(nèi)完成平時幾倍資源的擴(kuò)容，可以輕松應(yīng)對日常和大促的彈性業(yè)務(wù)需求。

下面是由Hologres組成的現(xiàn)CCO實時數(shù)倉架構(gòu)：

• 統(tǒng)一存儲：需要Point Query的表在Hologres中使用行存模式，并且存放公共明細(xì)層、公共輕度匯總層，需要OLAP查詢的表使用列存模式，存放于應(yīng)用層明細(xì)、應(yīng)用層匯總。
• 簡化實時鏈路：Hologres行存集群存放的公共層數(shù)據(jù)，通過Binlog訂閱，供應(yīng)用層做二次消費，替代Lindorm訂閱日志，再通過額外任務(wù)反查獲取整行記錄的鏈路。
• 統(tǒng)一服務(wù)：Point Query路由到行存表，Olap Query路由到列存表。
• 流批一體：小型維表的加速不再通過異構(gòu)數(shù)據(jù)導(dǎo)入的方式加載，而是直接在Hologres中創(chuàng)建外表，通過外表與內(nèi)表的聯(lián)邦查詢（join）能力，直接為線上OLAP應(yīng)用場景提供服務(wù)。

業(yè)務(wù)價值

從開始接觸Hologres，到Hologres真正落地CCO的具體場景，包括雙11光明頂指揮大屏，以及日常運營等場景，Hologres帶來的顯著業(yè)務(wù)價值主要如下：

1）實時架構(gòu)升級

• 實時數(shù)據(jù)閉環(huán)流轉(zhuǎn)
  截止當(dāng)前60%的實時作業(yè)運行在新實時數(shù)倉架構(gòu)上，公共層明細(xì)的維護(hù)全部切換為通過Hologres Binlog訂閱來消費，今年為了維護(hù)系統(tǒng)穩(wěn)定性，我們?nèi)匀话巡糠趾诵臉I(yè)務(wù)的Point Query查詢放在Lindorm，并通過Flink任務(wù)消費Binlog來保持兩邊引擎的實時同步，在壓測中通過Hologres connector目前可以支持到上千萬/s的單表寫入和讀取，已經(jīng)超出了我們業(yè)務(wù)的訴求。
• 大促削峰降成本
  今年大促中，實際效果上，交易峰值在幾百多萬每秒寫入到行存表后，我們借助Hologres Server端針對同一批次同一PK多次變化的merge能力和Hologres Connector的攢批能力，完成寫入和寫出，30%的削峰效果，降低了服務(wù)器成本。

2）自助分析快速響應(yīng)

• FBI+Vshow+Hologres 自助實時大屏
  我們將現(xiàn)有公共層明細(xì)數(shù)據(jù)實時同步到Hologres列存表，通過業(yè)務(wù)小二在FBI自定義大屏配置，實現(xiàn)了實時數(shù)據(jù)業(yè)務(wù)自助分析的能力，解決了每年大促遇到的業(yè)務(wù)訴求和數(shù)據(jù)開發(fā)資源的Gap。
• 靈活的索引機制
  根據(jù)場景，靈活定制索引，通過distribution key、clustering key、segment key可針對排序、檢索、聚合等多維分析場景做靈活定制，大大提升了查詢性能
• table group和shard count優(yōu)化
  按照業(yè)務(wù)場景將需要關(guān)聯(lián)的表放入同一個table group，通過local join減少shuffle的機制，可極大提升OLAP query的響應(yīng)時間。創(chuàng)建哨兵表，方便開發(fā)同學(xué)可以直接對新增表做新增/修改/刪除。實踐中，盡量將表放入盡可能小的shard count的table group，可極大減少每次SQL啟動的開銷，減少響應(yīng)時間，我們實際優(yōu)化中，一個針對小二的聚合操作，由秒級優(yōu)化到毫秒級。

3）服務(wù)資源系統(tǒng)化

服務(wù)資源現(xiàn)場管理上千+大屏，幫助服務(wù)資源現(xiàn)場合理調(diào)度人力、預(yù)測排班，實時監(jiān)控預(yù)警，幫助幾十+SP服務(wù)商，多家政企和數(shù)十+校企等大幅提升服務(wù)資源的調(diào)度能力，讓上萬+小二能快速響應(yīng)商家和消費者的服務(wù)請求。

4）體驗引擎智能化

基于CCO業(yè)務(wù)數(shù)據(jù)+消費者全渠道語聊數(shù)據(jù)+行為操作數(shù)據(jù)，圍繞逆向全鏈路交易場景，買賣家聯(lián)合、結(jié)構(gòu)化和非結(jié)構(gòu)化交叉，深度洞察問題根因，并快速解決問題，以往從發(fā)現(xiàn)問題到去查問題以及解決問題，需要耗費大量的人力、精力以及物力，而現(xiàn)在體驗引擎的智能化，使得問題能夠被快速定位，這樣也就有更多的時間和精力去解決問題，往往幾分鐘就能得到解決，提升了整個流程的用戶體驗。

5）整體成本節(jié)省近30%

對于業(yè)務(wù)來說，成本也是一個重要的考慮因素，尤其是在數(shù)據(jù)量越來越大的情況下。替換Hologres之后，在整個雙11期間，整體的成本預(yù)估節(jié)省幾百萬，相比之前節(jié)省30%左右。目前CCO還處于遷移過度階段，為了保證系統(tǒng)的整體穩(wěn)定性，部分業(yè)務(wù)還沒有完全替換，后續(xù)也會開始推動整體的遷移工作，預(yù)計整體遷移完畢后預(yù)計可以節(jié)省更多的資源。

未來展望

未來我們希望可以繼續(xù)在流批一體、HSAP上做更深入的探索，希望能與Hologres保持持續(xù)的共建，能夠推動引擎發(fā)展也能更好的服務(wù)于業(yè)務(wù)發(fā)展。

• 服務(wù)SLA：希望Hologres可以有主備機制，在存儲計算分離的架構(gòu)上，計算引擎可以主備，存儲可以在不同的Pangu集群存在多副本的能力，保證業(yè)務(wù)在寫入和讀取上，任何主鏈路故障的情況下，可以無感切換到備實例。
• 實例間實時同步：在實踐中，由于不同業(yè)務(wù)場景的不同保障等級，拆分實例可能將是未來較長時間內(nèi)的一個可行的解決方案，當(dāng)前我們是通過Flink任務(wù)將數(shù)據(jù)做實例間同步，實例間互相實時同步數(shù)據(jù)的能力可以極大的降低業(yè)務(wù)開發(fā)成本和維護(hù)成本。
• 資源隔離：真正意義的行/列混存，可以在同一個表上支撐Point Query和Olap Query，獨立的資源分配，又互不影響。
• 彈性變更：table group的shard count可以動態(tài)擴(kuò)/縮，能夠靈活應(yīng)對峰值及日常的業(yè)務(wù)需要。
• 二級索引：對于Point Query支持海量數(shù)據(jù)的非PK point query，同時可應(yīng)用于流計算中，可以極大降低模型建設(shè)的冗余度。

原文鏈接：https://developer.aliyun.com/article/778544?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的Hologres是如何完美支撑双11智能客服实时数仓的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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