Hologres是如何完美支撐雙11智能客服實時數(shù)倉的

這篇文章將為大家詳細講解有關Hologres是如何完美支撐雙11智能客服實時數(shù)倉的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

業(yè)務背景

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

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

• 數(shù)據(jù)復雜度高，覆蓋了從用戶加購、下單、支付到售后退款等全渠道的業(yè)務場景及數(shù)據(jù)依賴。

• 數(shù)據(jù)量大，從手淘日志（千萬/s 峰值）到交易（幾百萬/s 峰值）到咨詢（幾十萬/s 峰值）。

• 應用場景豐富，實時監(jiān)控大屏，實時交互式分析數(shù)據(jù)產品，To B/C類的線上應用。

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

實時技術架構演進歷程

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

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

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

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

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

• 引入OLAP引擎：小數(shù)據(jù)量的明細、輕度匯總等數(shù)據(jù)統(tǒng)一存儲到AnalyticDB，支持較高QPS的OLAP Query。

• 數(shù)據(jù)模型及任務加工分層：在DWD層按照主題將不同數(shù)據(jù)源數(shù)據(jù)整合，并且輸出到Lindorm，然后通過Hlog訂閱，觸發(fā)流任務反查事實表，將寬表字段對齊輸出到TT，做為DWD中間層存儲。構建可復用的DWS層，將常用維度及指標按照主題建模，供下游復用，減少煙囪化。

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

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

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

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

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

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

• 數(shù)據(jù)存儲冗余：實際場景中，我們需要提供Point Query，Adhoc Query，Olap Query等多種服務形式，我們需要至少在KV存儲和MPP存儲中存放兩份，造成非常多不必要存儲，存儲成本也只增不降。

• 元數(shù)據(jù)管理：在傳統(tǒng)的KV引擎上，由于schema free的特點，我們無法友好并且高效的管理我們的表及字段的元數(shù)據(jù)信息。

• 加工鏈路復雜： 其中兩個典型場景是，一是對于dwd層寬表的字段對齊問題，目前只能通過Lindorm的KV特性，可以多個不同的流根據(jù)同一PK進行更新，然后通過Hlog捕捉到對應PK的每次變化，然后觸發(fā)流對Lindorm寬表的反查，再將整行記錄下發(fā)。二是寫入到MPP引擎的數(shù)據(jù)，往往由于MPP引擎不支持寫入數(shù)據(jù)的重新訂閱消費，造成必須在上游任務增加SINK，寫入到消息中間件，然后才能支持二次消費，一定程度上也增加了鏈路的復雜度。

實時數(shù)倉架構

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

• 支持行存列存，HSAP的混合服務能力：針對現(xiàn)有的Point Query的場景，可以采取行存方式存儲，針對典型的OLAP場景，可以采取列存方式存儲。

• 高吞吐的實時寫入：經過實際測試，對于行存的寫入，目前可以滿足我們業(yè)務上千萬/s的吞吐要求，在列存的OLAP場景上，可以輕松應對我們幾十萬/s的高聚合數(shù)據(jù)寫入要求。

• 行存的日志訂閱以及維表關聯(lián)能力：我們寫入Hologres行存表的數(shù)據(jù)，可以通過Binlog訂閱，通過Hologres connector，輕松應用Flink的任務開發(fā)中，將公共層明細數(shù)據(jù)有選擇的進行二次計算，并寫入回Hologres，提供給不同的應用場景，一定程度上解決了Hologres引擎和Blink引擎計算的算力平衡和高QPS的相應問題。

• 云原生：支持彈性擴縮容和高度可擴展性，今年大促我們在幾分鐘內完成平時幾倍資源的擴容，可以輕松應對日常和大促的彈性業(yè)務需求。

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

• 統(tǒng)一存儲：需要Point Query的表在Hologres中使用行存模式，并且存放公共明細層、公共輕度匯總層，需要OLAP查詢的表使用列存模式，存放于應用層明細、應用層匯總。

• 簡化實時鏈路：Hologres行存集群存放的公共層數(shù)據(jù)，通過Binlog訂閱，供應用層做二次消費，替代Lindorm訂閱日志，再通過額外任務反查獲取整行記錄的鏈路。

• 統(tǒng)一服務：Point Query路由到行存表，Olap Query路由到列存表。

• 流批一體：小型維表的加速不再通過異構數(shù)據(jù)導入的方式加載，而是直接在Hologres中創(chuàng)建外表，通過外表與內表的聯(lián)邦查詢（join）能力，直接為線上OLAP應用場景提供服務。

業(yè)務價值

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

1）實時架構升級

• 實時數(shù)據(jù)閉環(huán)流轉
  截止當前60%的實時作業(yè)運行在新實時數(shù)倉架構上，公共層明細的維護全部切換為通過Hologres Binlog訂閱來消費，今年為了維護系統(tǒng)穩(wěn)定性，我們仍然把部分核心業(yè)務的Point Query查詢放在Lindorm，并通過Flink任務消費Binlog來保持兩邊引擎的實時同步，在壓測中通過Hologres connector目前可以支持到上千萬/s的單表寫入和讀取，已經超出了我們業(yè)務的訴求。

• 大促削峰降成本
  今年大促中，實際效果上，交易峰值在幾百多萬每秒寫入到行存表后，我們借助Hologres Server端針對同一批次同一PK多次變化的merge能力和Hologres Connector的攢批能力，完成寫入和寫出，30%的削峰效果，降低了服務器成本。

2）自助分析快速響應

• FBI+Vshow+Hologres 自助實時大屏
  我們將現(xiàn)有公共層明細數(shù)據(jù)實時同步到Hologres列存表，通過業(yè)務小二在FBI自定義大屏配置，實現(xiàn)了實時數(shù)據(jù)業(yè)務自助分析的能力，解決了每年大促遇到的業(yè)務訴求和數(shù)據(jù)開發(fā)資源的Gap。

• 靈活的索引機制
  根據(jù)場景，靈活定制索引，通過distribution key、clustering key、segment key可針對排序、檢索、聚合等多維分析場景做靈活定制，大大提升了查詢性能

• table group和shard count優(yōu)化
  按照業(yè)務場景將需要關聯(lián)的表放入同一個table group，通過local join減少shuffle的機制，可極大提升OLAP query的響應時間。創(chuàng)建哨兵表，方便開發(fā)同學可以直接對新增表做新增/修改/刪除。實踐中，盡量將表放入盡可能小的shard count的table group，可極大減少每次SQL啟動的開銷，減少響應時間，我們實際優(yōu)化中，一個針對小二的聚合操作，由秒級優(yōu)化到毫秒級。

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

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

4）體驗引擎智能化

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

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

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

關于Hologres是如何完美支撐雙11智能客服實時數(shù)倉的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。