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

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

作者：映海（任海峰），阿里巴巴CCO數據應用中臺實時技術負責人

客戶簡介

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

業務背景

從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還處于遷移過度階段，為了保證系統的整體穩定性，部分業務還沒有完全替換，后續也會開始推動整體的遷移工作，預計整體遷移完畢后預計可以節省更多的資源。

未來展望

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

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

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

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。