剛剛結束的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，同時可應用于流計算中，可以極大降低模型建設的備援度。