共計 4654 個字符，預計需要花費 12 分鐘才能閱讀完成。

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

業務背景

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

整體上 CCO 在實時數據的應用上呈現出幾個特點：

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

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

應用場景豐富，實時監控大屏，實時交互式分析數據產品，To B/ C 類的線上應用。

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

實時技術架構演進歷程

CCO 的實時架構演進分為三個階段：數據庫階段、傳統數據倉庫階段、實時數倉階段。

1）數據庫階段

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

2）傳統數據倉庫階段

隨著實時數據應用的規格上線，以及數據庫階段的明顯痛點，發展到了傳統數據倉庫階段。傳統數據倉庫階段架構的優化點如下：

引入 OLAP 引擎：小數據量的明細、輕度匯總等數據統一存儲到 AnalyticDB，支持較高 QPS 的 OLAP Query。

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

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

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

3）實時數倉階段

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

首先我們來分析一下，傳統數據倉庫演進為實時數倉最主要的困難點：

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

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

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

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

實時數倉架構

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

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

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

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

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

下面是由 Hologres 組成的現 CCO 實時數倉架構：

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

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

統一服務：Point Query 路由到行存表，Olap Query 路由到列存表。

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

業務價值

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

1）實時架構升級

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

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

2）自助分析快速響應

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

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

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

3）服務資源系統化

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

4）體驗引擎智能化

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

5）整體成本節省近 30%

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

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