[[196732]]

【51CTO.com原創稿件】淘寶、天貓每天有上億個不同的買賣家進行對話，產生百億條聊天記錄。對客服聊天記錄的實時分析是實現智能客服的基礎。本文主要分享云客服的整體架構，包括實時分析的場景、架構、技術難點，以及為何要從 NoSQL 遷移時序數據庫和使用心得。

網購催生客服職能轉型

如下圖，是國內客服體系發展歷程。

國內客服體系經歷了傳統客服、Web 端客戶和云客服三個發展階段。

傳統客服以呼叫中心為主，主要以電話客服為主，人力投入成本高，部門之間溝通少，效率低下。

隨著互聯網發展，出現了 Web 端客服，它打破單一的電話形式，客服可同時接待多個用戶，降低了客戶等待時間和客服成本。

到了移動互聯網時代，用戶觸達渠道越來越多，比較碎片化。聚合各渠道的反饋，并且保證各渠道一致的用戶體驗是提升企業服務質量的重要手段，因此出現了云客服。

多渠道和智能化是云客服最明顯的兩大特征。客服可以借助云客服平臺，統一處理來自企業官網、APP、公眾號等所有渠道的用戶咨詢，從而保證服務質量的統一。

同時通過機器人、智能提示、營銷提示等智能插件，提升客服的工作效率，讓客服具備銷售的屬性。

如下圖，是客服職能轉型前后對比圖。

云客服的整體架構

如下圖，是云客服的整體架構。

云客服架構自上而下可分為客戶接觸點、接入層、應用層和支撐層。

客戶接觸點。官網、商城、微信、微博等客服接觸點會通過統一的接入網關接入到客服工作臺。

接入層。接入層首先會識別用戶身份，例如：VIP 還是普通用戶，新用戶還是老客戶。不同的用戶會自動路由到不同客服組進行服務。這些客服組在應答技巧、推薦內容等方面都有所差別。

應用層。應用層是整個云客服的核心，包括客服工作臺、智能插件和客服管理三部分。客服通過客服工作臺統一接待各種渠道的在線和電話咨詢，并根據用戶反饋形成各種工單分發給其他部門處理。

智能插件以給客服提能為主，例如：自動催單，物流、訂單查詢等，能大大減少客服的重復工作。以及智能的組合銷售、營銷活動提示，能大大提高客服的引導銷售額。

客服管理包括知識庫、質檢、績效考核、坐席、客情等，是客服主管或企業老板經常使用的功能。

支撐層。這層包括知識庫、智能語義分析引擎、呼叫云、IM云、待客云和軌跡云等基礎設施。

云客服的智能插件、客服管理等核心功能都依賴于聊天記錄的實時分析能力，下面介紹下實時分析的場景、架構和關鍵技術問題。

實時分析場景

如下圖，是云客服實時分析的幾個場景。

熱點問題分析。及時分析出用戶反饋最多的問題，優先解決。特別在新品上線或大促時，作用很大。

實時接待。實時展示接待情況，哪個客服沒按時上線，哪個店鋪接待不過來，都一目了然。

實時質檢。及時發現客服是否按規定交流，如是否用尊稱，話術上是否達到要求等。還可分析客戶情緒、滿意度，及時介入客服與客戶的爭執。對于客服人員變化頻繁、新客服多等情況很有用。

實時分析架構

如下圖，是云客服的實時分析架構。

數據采集

數據采集階段主要注意幾個點：

• 盡可能采集更多的數據。“巧婦難為無米之炊”，以客服場景為例，除了聊天記錄外，結合交易數據可以算出客服引導的成交量，結合瀏覽軌跡可以猜測用戶的問題。
• 盡量降低性能消耗和實時性，這里可以用批量發送、日志不落磁盤直接發送等方式。

數據通道

數據通道主要是消息隊列和 API 兩種方式，消息隊列傳輸原始數據，API 提供輔助的原數據。使用消息隊列時要注意：

• 發送時注意消息體的大小，每種消息隊列的***消息體大小都不一樣，例如：RocketMQ 推薦 4KB。打包成***大小再發送可以***程度提高系統吞吐。
• 消費時是批量消費還是單條消費。一般數據量大，對精確度要求不高時用批量消費方式，可提高節點處理能力，但相對的，失敗補償和事務性比較難保證。
• 記錄消息軌跡。有些消息隊列可通過 MsgID 查詢消息的生產端、消費端、消費次數等，方便丟消息或出現重復時進行排查。
• 支持消息重置。當消費端故障或發布時，往往要將消費的偏移(offset)設置到之前的某個時間點，重新消費。

實時計算引擎

常用的有 Storm、Spark 或 Flink，基本環節如下：

• 解析器(Parser)和過濾器(Filter)，盡早把不需要的數據過濾掉，為后續的環節減輕壓力。
• 分詞器(Segmenter)，分詞的關鍵是詞庫的積累，不同行業、不同場景會有不同的術語，詞庫直接影響 Solver 的質量。
• 解答器(Solver)，有三個功能。一是問題歸類，如商品咨詢、物流咨詢、活動咨詢等。二是話術檢驗，如：敏感詞、禮貌用語等。三是情感分析，分析客戶當前的情緒。
• 規則引擎(Rule Engine)，根據前面分析和結合運營規則，計算業務指標。用規則引擎有兩個好處，一是方便計算一些比較復雜的指標，如：復購率。

二是支持動態修改，像調整某個參數的權重這種需求，可即時修改生效，不用發布。

• 指標聚合器(Metric Aggregator)，對算好的基礎數據進行聚合，如按時間，一分鐘、一小時把數據進行匯總、求評價或方差等。

數據存儲

聚合后的數據會存儲到Hbase。如下圖，是基礎的Hbase存儲結構。

Rowkey = metric name + timestamp + tags

Rowkey 由指標名、時間戳和標識這個數據的一組鍵值對構成，后面會介紹如何對這種存儲進行優化。

實時分析的常見問題

做海量數據的實時分析、聚合時，都會遇到一些問題，本文主要挑選數據傾斜、窗口切分和海量時間線這三個最常見的問題來解析。

問題一，數據傾斜

數據傾斜，也叫數據熱點。如下圖，上面是 MapReduce 過程，下面是流處理過程。

不管是 MapReduce 還是流處理，總有某類數據量會多于其他數據，如上圖綠色三角比其他圖形多。實際生產中熱點數據的量可能是其他數據的幾十倍。

這種數據熱點的出現，會導致消息列隊堆積，處理節點內存過高，出發 Full GC 或 OOM，***是工作節點的不停 crash 和遷移，從而加劇這種現象。

那么，如何應對呢?常見方法有：

• 盡可能細粒度 hash。以聊天記錄示例，如果以用戶為最小粒度，一個用戶的所有聊天都 hash 到一起，那有些賬號的數據會很多，就容易出現熱點。

如果進一步細分，以聊天為最小粒度，把 A 和 B 聊天為一類、A 和 C 為另一類，這樣數據就會均勻很多。

• 特殊 key 處理。大部分應用場景都會有一些標桿用戶，其數據量是其他用戶的幾十倍，針對這類客戶可以白名單的方式，進行特殊處理。
• 二段 Merge。把一次性的 Merge 操作劃分成多次。一開始不要求把最終的結果統計出來，可先做局部的 Merge，再做***的 Merge，這樣可緩解數據熱點的問題。但相應的工作節點會變多，成本變高。

問題二：窗口切分

流式計算本質上是把源源不斷的數據，按時間區間把數據給劃分開，這個動作叫窗口切分。如下圖，按照 5 秒或 15 秒進行切分：

常見計算窗口有三種：固定窗口、滑動窗口和會話窗口。如下圖：

• 固定窗口。按照工作節點的系統時間，將數據按固定周期切開，之間沒有重疊，這是理想狀態。

事實上，由于分布式系統在系統時間、網絡延時方面都會存在差異，工作節點收到數據的數據是亂序的，接收時間不能視作數據產生的時間。

• 滑動窗口。固定統計周期上加一個滑動時間，等滑動時間到了再保存結果，關閉窗口。例如：如果預估數據一般延遲 10s，那滑動時間可以設置為 15s，15s 之后才到達的數據。

可以考慮拋棄或者進行特殊的處理邏輯。滑動窗口要緩存的數據比固定窗口多，窗口關閉、狀態存儲、恢復也要復雜一些。

• 會話窗口。不以時間，而是以某些事件作為窗口的劃分，就是會話窗口。以聊天為例，A 和 B 聊天，A 說了一句或多句話后，只有當 B 回復時，才形成一個窗口。這時可以得出響應時間、答問的次數等各類指標。

總體來說，處理難度上，Tumbling(固定) < Sliding(滑動) < Session(會話)。固定窗口只是理想的狀態，用于實際場景會導致數據不精確。實際使用還是滑動窗口的多。

問題三：海量時間線

什么是時間線(Series)呢?數據按各時間區間統計出一個個的值，按時間進行展示就形成一條線，故稱作時間線。如下圖，三種圖案形成三條時間線。

海量時間線是指當統計維度變多時，時間線個數會指數上漲!還是以聊天指標為例。

假設，每天有十萬個買家和一萬賣家聊天，每個聊天要統計 10 個指標，時間線的個數就是 10w *1w * 10 = 100 億!

時間線的增加會導致存儲的結果數據大大增加，存儲成本升高、查詢速度下降。因此，我們選擇了時序數據庫代替原來的 Hbase。

從 NoSQL 到時序數據庫

面對實時聚合技術復雜、成本高等情況，是否有優化方案?時序數據庫(TSDB)應運而生。

什么是 TSDB?它是專門存儲按時間順序變化(即時間序列化)的數據，支持原始數據查詢和實時聚合，支持數據壓縮，適合海量數據處理。

以下是比較熱門的開源解決方案：

• InfluxDB。短小精悍，社區很活躍。但集群方案收費，適合小規模用戶。
• OpenTSDB。基于 Hbase 的成熟的 TSDB 方案，被很多大公司使用。
• Druid。基于時間的 OLAP 列存數據庫，長處在于 AD-Hoc 的聚合/分析。

如下圖，是基于 NoSQL 預計算方案與基于時序數據庫(TSDB)的實時聚合方案優劣對比。

對比來看，TSDB 的方案能比較好的解決聚合邏輯復雜、存儲成本高的問題，但由于聊天數據量大，查詢慢的問題也比較嚴重。下面將以 OpenTSDB 為例，介紹其存儲優化的原理和查詢優化的經驗。

OpenTSDB 存儲優化原理

存儲優化前，Rowkey = metric name + timestamp + tags 的組合。Rowkey 很長且重復很多。如下圖。

OpenTSDB 存儲優化原理歸納如下：

• 為每個 metric、tag key 和 tag value 都分配一個 UID，縮短 row key。
• 將同一小時的數據存儲到不同的列中，減少 key-value 數。
• 使用偏移量時間戳，進一步減少列名占用空間。

優化后的存儲結構如下圖所示。

OpenTSDB 查詢優化經驗

OpenTSDB 查詢優化可以從使用端和服務端兩個方面著手：

使用端優化：

• 合理拆分 Metric，這類似于關系型數據庫的分表，將相關性不強的屬性拆開到多個 Metric 中，減少時間線個數，查詢時自然會有所改進。
• 注意 Tag 順序，要將經常指定維度往前排，最明顯的就是用戶 ID，查詢數據時指定用戶 ID 進行范圍查詢，Hbase Scan 的數量就會少很多。
• 并發查優化，OpenTSDB 默認是一個小時數據存一行，那么可以按小時把請求拆分，如查最近二十四小時就拆成二十四個請求進行查詢，整體的響應時間就會有所改進。

服務端優化：

• 預集合，先把慢查詢撈出來，提前去執行查詢。查詢之后，把結果存儲到另一個地方。預集合可以由使用方或服務端實現。

服務端實現對使用方更友好，正如 InfluxDB 的 Continuous Queries 功能。

• 降精度，OpenTSDB 默認是每一秒存一個數據，假設只要一分鐘，是不是可以每一分鐘只記一個數據，那樣數據量就會變成原來的六十分之一。

但是要注意降精度后，使用端要將這一分鐘的數據先自行累加然后再發送到服務端，因為 Hbase 是默認覆蓋而不進行累加。

• 結果緩存，這里不是指請求級別的結果緩存，而是要做到 Metric 或者時間線結果的緩存。

以上內容由編輯王雪燕根據李灼靈老師在 WOTA2017 “大數據應用創新”專場的演講內容整理。

[[196735]]

李灼靈 (千慕)

阿里巴巴資深研發工程師

在浙江大學計算機系本碩畢業后，加入阿里巴巴。先后在共享、商家事業部負責過 TAE、APM、客服 SAAS、千牛問答等產品的架構和研發工作，通過 Docker、流式計算、APM、SAAS 化等技術推動開放平臺的架構升級。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】