[[196732]]

【51CTO.com原創(chuàng)稿件】淘寶、天貓每天有上億個(gè)不同的買賣家進(jìn)行對(duì)話，產(chǎn)生百億條聊天記錄。對(duì)客服聊天記錄的實(shí)時(shí)分析是實(shí)現(xiàn)智能客服的基礎(chǔ)。本文主要分享云客服的整體架構(gòu)，包括實(shí)時(shí)分析的場(chǎng)景、架構(gòu)、技術(shù)難點(diǎn)，以及為何要從 NoSQL 遷移時(shí)序數(shù)據(jù)庫(kù)和使用心得。

網(wǎng)購(gòu)催生客服職能轉(zhuǎn)型

如下圖，是國(guó)內(nèi)客服體系發(fā)展歷程。

國(guó)內(nèi)客服體系經(jīng)歷了傳統(tǒng)客服、Web 端客戶和云客服三個(gè)發(fā)展階段。

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

隨著互聯(lián)網(wǎng)發(fā)展，出現(xiàn)了 Web 端客服，它打破單一的電話形式，客服可同時(shí)接待多個(gè)用戶，降低了客戶等待時(shí)間和客服成本。

到了移動(dòng)互聯(lián)網(wǎng)時(shí)代，用戶觸達(dá)渠道越來(lái)越多，比較碎片化。聚合各渠道的反饋，并且保證各渠道一致的用戶體驗(yàn)是提升企業(yè)服務(wù)質(zhì)量的重要手段，因此出現(xiàn)了云客服。

多渠道和智能化是云客服最明顯的兩大特征。客服可以借助云客服平臺(tái)，統(tǒng)一處理來(lái)自企業(yè)官網(wǎng)、APP、公眾號(hào)等所有渠道的用戶咨詢，從而保證服務(wù)質(zhì)量的統(tǒng)一。

同時(shí)通過(guò)機(jī)器人、智能提示、營(yíng)銷提示等智能插件，提升客服的工作效率，讓客服具備銷售的屬性。

如下圖，是客服職能轉(zhuǎn)型前后對(duì)比圖。

云客服的整體架構(gòu)

如下圖，是云客服的整體架構(gòu)。

云客服架構(gòu)自上而下可分為客戶接觸點(diǎn)、接入層、應(yīng)用層和支撐層。

客戶接觸點(diǎn)。官網(wǎng)、商城、微信、微博等客服接觸點(diǎn)會(huì)通過(guò)統(tǒng)一的接入網(wǎng)關(guān)接入到客服工作臺(tái)。

接入層。接入層首先會(huì)識(shí)別用戶身份，例如：VIP 還是普通用戶，新用戶還是老客戶。不同的用戶會(huì)自動(dòng)路由到不同客服組進(jìn)行服務(wù)。這些客服組在應(yīng)答技巧、推薦內(nèi)容等方面都有所差別。

應(yīng)用層。應(yīng)用層是整個(gè)云客服的核心，包括客服工作臺(tái)、智能插件和客服管理三部分?？头ㄟ^(guò)客服工作臺(tái)統(tǒng)一接待各種渠道的在線和電話咨詢，并根據(jù)用戶反饋形成各種工單分發(fā)給其他部門處理。

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

客服管理包括知識(shí)庫(kù)、質(zhì)檢、績(jī)效考核、坐席、客情等，是客服主管或企業(yè)老板經(jīng)常使用的功能。

支撐層。這層包括知識(shí)庫(kù)、智能語(yǔ)義分析引擎、呼叫云、IM云、待客云和軌跡云等基礎(chǔ)設(shè)施。

云客服的智能插件、客服管理等核心功能都依賴于聊天記錄的實(shí)時(shí)分析能力，下面介紹下實(shí)時(shí)分析的場(chǎng)景、架構(gòu)和關(guān)鍵技術(shù)問(wèn)題。

實(shí)時(shí)分析場(chǎng)景

如下圖，是云客服實(shí)時(shí)分析的幾個(gè)場(chǎng)景。

熱點(diǎn)問(wèn)題分析。及時(shí)分析出用戶反饋?zhàn)疃嗟膯?wèn)題，優(yōu)先解決。特別在新品上線或大促時(shí)，作用很大。

實(shí)時(shí)接待。實(shí)時(shí)展示接待情況，哪個(gè)客服沒(méi)按時(shí)上線，哪個(gè)店鋪接待不過(guò)來(lái)，都一目了然。

實(shí)時(shí)質(zhì)檢。及時(shí)發(fā)現(xiàn)客服是否按規(guī)定交流，如是否用尊稱，話術(shù)上是否達(dá)到要求等。還可分析客戶情緒、滿意度，及時(shí)介入客服與客戶的爭(zhēng)執(zhí)。對(duì)于客服人員變化頻繁、新客服多等情況很有用。

實(shí)時(shí)分析架構(gòu)

如下圖，是云客服的實(shí)時(shí)分析架構(gòu)。

數(shù)據(jù)采集

數(shù)據(jù)采集階段主要注意幾個(gè)點(diǎn)：

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

數(shù)據(jù)通道

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

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

實(shí)時(shí)計(jì)算引擎

常用的有 Storm、Spark 或 Flink，基本環(huán)節(jié)如下：

• 解析器(Parser)和過(guò)濾器(Filter)，盡早把不需要的數(shù)據(jù)過(guò)濾掉，為后續(xù)的環(huán)節(jié)減輕壓力。
• 分詞器(Segmenter)，分詞的關(guān)鍵是詞庫(kù)的積累，不同行業(yè)、不同場(chǎng)景會(huì)有不同的術(shù)語(yǔ)，詞庫(kù)直接影響 Solver 的質(zhì)量。
• 解答器(Solver)，有三個(gè)功能。一是問(wèn)題歸類，如商品咨詢、物流咨詢、活動(dòng)咨詢等。二是話術(shù)檢驗(yàn)，如：敏感詞、禮貌用語(yǔ)等。三是情感分析，分析客戶當(dāng)前的情緒。
• 規(guī)則引擎(Rule Engine)，根據(jù)前面分析和結(jié)合運(yùn)營(yíng)規(guī)則，計(jì)算業(yè)務(wù)指標(biāo)。用規(guī)則引擎有兩個(gè)好處，一是方便計(jì)算一些比較復(fù)雜的指標(biāo)，如：復(fù)購(gòu)率。

二是支持動(dòng)態(tài)修改，像調(diào)整某個(gè)參數(shù)的權(quán)重這種需求，可即時(shí)修改生效，不用發(fā)布。

• 指標(biāo)聚合器(Metric Aggregator)，對(duì)算好的基礎(chǔ)數(shù)據(jù)進(jìn)行聚合，如按時(shí)間，一分鐘、一小時(shí)把數(shù)據(jù)進(jìn)行匯總、求評(píng)價(jià)或方差等。

數(shù)據(jù)存儲(chǔ)

聚合后的數(shù)據(jù)會(huì)存儲(chǔ)到Hbase。如下圖，是基礎(chǔ)的Hbase存儲(chǔ)結(jié)構(gòu)。

Rowkey = metric name + timestamp + tags

Rowkey 由指標(biāo)名、時(shí)間戳和標(biāo)識(shí)這個(gè)數(shù)據(jù)的一組鍵值對(duì)構(gòu)成，后面會(huì)介紹如何對(duì)這種存儲(chǔ)進(jìn)行優(yōu)化。

實(shí)時(shí)分析的常見問(wèn)題

做海量數(shù)據(jù)的實(shí)時(shí)分析、聚合時(shí)，都會(huì)遇到一些問(wèn)題，本文主要挑選數(shù)據(jù)傾斜、窗口切分和海量時(shí)間線這三個(gè)最常見的問(wèn)題來(lái)解析。

問(wèn)題一，數(shù)據(jù)傾斜

數(shù)據(jù)傾斜，也叫數(shù)據(jù)熱點(diǎn)。如下圖，上面是 MapReduce 過(guò)程，下面是流處理過(guò)程。

不管是 MapReduce 還是流處理，總有某類數(shù)據(jù)量會(huì)多于其他數(shù)據(jù)，如上圖綠色三角比其他圖形多。實(shí)際生產(chǎn)中熱點(diǎn)數(shù)據(jù)的量可能是其他數(shù)據(jù)的幾十倍。

這種數(shù)據(jù)熱點(diǎn)的出現(xiàn)，會(huì)導(dǎo)致消息列隊(duì)堆積，處理節(jié)點(diǎn)內(nèi)存過(guò)高，出發(fā) Full GC 或 OOM，***是工作節(jié)點(diǎn)的不停 crash 和遷移，從而加劇這種現(xiàn)象。

那么，如何應(yīng)對(duì)呢?常見方法有：

• 盡可能細(xì)粒度 hash。以聊天記錄示例，如果以用戶為最小粒度，一個(gè)用戶的所有聊天都 hash 到一起，那有些賬號(hào)的數(shù)據(jù)會(huì)很多，就容易出現(xiàn)熱點(diǎn)。

如果進(jìn)一步細(xì)分，以聊天為最小粒度，把 A 和 B 聊天為一類、A 和 C 為另一類，這樣數(shù)據(jù)就會(huì)均勻很多。

• 特殊 key 處理。大部分應(yīng)用場(chǎng)景都會(huì)有一些標(biāo)桿用戶，其數(shù)據(jù)量是其他用戶的幾十倍，針對(duì)這類客戶可以白名單的方式，進(jìn)行特殊處理。
• 二段 Merge。把一次性的 Merge 操作劃分成多次。一開始不要求把最終的結(jié)果統(tǒng)計(jì)出來(lái)，可先做局部的 Merge，再做***的 Merge，這樣可緩解數(shù)據(jù)熱點(diǎn)的問(wèn)題。但相應(yīng)的工作節(jié)點(diǎn)會(huì)變多，成本變高。

問(wèn)題二：窗口切分

流式計(jì)算本質(zhì)上是把源源不斷的數(shù)據(jù)，按時(shí)間區(qū)間把數(shù)據(jù)給劃分開，這個(gè)動(dòng)作叫窗口切分。如下圖，按照 5 秒或 15 秒進(jìn)行切分：

常見計(jì)算窗口有三種：固定窗口、滑動(dòng)窗口和會(huì)話窗口。如下圖：

• 固定窗口。按照工作節(jié)點(diǎn)的系統(tǒng)時(shí)間，將數(shù)據(jù)按固定周期切開，之間沒(méi)有重疊，這是理想狀態(tài)。

事實(shí)上，由于分布式系統(tǒng)在系統(tǒng)時(shí)間、網(wǎng)絡(luò)延時(shí)方面都會(huì)存在差異，工作節(jié)點(diǎn)收到數(shù)據(jù)的數(shù)據(jù)是亂序的，接收時(shí)間不能視作數(shù)據(jù)產(chǎn)生的時(shí)間。

• 滑動(dòng)窗口。固定統(tǒng)計(jì)周期上加一個(gè)滑動(dòng)時(shí)間，等滑動(dòng)時(shí)間到了再保存結(jié)果，關(guān)閉窗口。例如：如果預(yù)估數(shù)據(jù)一般延遲 10s，那滑動(dòng)時(shí)間可以設(shè)置為 15s，15s 之后才到達(dá)的數(shù)據(jù)。

可以考慮拋棄或者進(jìn)行特殊的處理邏輯。滑動(dòng)窗口要緩存的數(shù)據(jù)比固定窗口多，窗口關(guān)閉、狀態(tài)存儲(chǔ)、恢復(fù)也要復(fù)雜一些。

• 會(huì)話窗口。不以時(shí)間，而是以某些事件作為窗口的劃分，就是會(huì)話窗口。以聊天為例，A 和 B 聊天，A 說(shuō)了一句或多句話后，只有當(dāng) B 回復(fù)時(shí)，才形成一個(gè)窗口。這時(shí)可以得出響應(yīng)時(shí)間、答問(wèn)的次數(shù)等各類指標(biāo)。

總體來(lái)說(shuō)，處理難度上，Tumbling(固定) < Sliding(滑動(dòng)) < Session(會(huì)話)。固定窗口只是理想的狀態(tài)，用于實(shí)際場(chǎng)景會(huì)導(dǎo)致數(shù)據(jù)不精確。實(shí)際使用還是滑動(dòng)窗口的多。

問(wèn)題三：海量時(shí)間線

什么是時(shí)間線(Series)呢?數(shù)據(jù)按各時(shí)間區(qū)間統(tǒng)計(jì)出一個(gè)個(gè)的值，按時(shí)間進(jìn)行展示就形成一條線，故稱作時(shí)間線。如下圖，三種圖案形成三條時(shí)間線。

海量時(shí)間線是指當(dāng)統(tǒng)計(jì)維度變多時(shí)，時(shí)間線個(gè)數(shù)會(huì)指數(shù)上漲!還是以聊天指標(biāo)為例。

假設(shè)，每天有十萬(wàn)個(gè)買家和一萬(wàn)賣家聊天，每個(gè)聊天要統(tǒng)計(jì) 10 個(gè)指標(biāo)，時(shí)間線的個(gè)數(shù)就是 10w *1w * 10 = 100 億!

時(shí)間線的增加會(huì)導(dǎo)致存儲(chǔ)的結(jié)果數(shù)據(jù)大大增加，存儲(chǔ)成本升高、查詢速度下降。因此，我們選擇了時(shí)序數(shù)據(jù)庫(kù)代替原來(lái)的 Hbase。

從 NoSQL 到時(shí)序數(shù)據(jù)庫(kù)

面對(duì)實(shí)時(shí)聚合技術(shù)復(fù)雜、成本高等情況，是否有優(yōu)化方案?時(shí)序數(shù)據(jù)庫(kù)(TSDB)應(yīng)運(yùn)而生。

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

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

• InfluxDB。短小精悍，社區(qū)很活躍。但集群方案收費(fèi)，適合小規(guī)模用戶。
• OpenTSDB。基于 Hbase 的成熟的 TSDB 方案，被很多大公司使用。
• Druid?；跁r(shí)間的 OLAP 列存數(shù)據(jù)庫(kù)，長(zhǎng)處在于 AD-Hoc 的聚合/分析。

如下圖，是基于 NoSQL 預(yù)計(jì)算方案與基于時(shí)序數(shù)據(jù)庫(kù)(TSDB)的實(shí)時(shí)聚合方案優(yōu)劣對(duì)比。

對(duì)比來(lái)看，TSDB 的方案能比較好的解決聚合邏輯復(fù)雜、存儲(chǔ)成本高的問(wèn)題，但由于聊天數(shù)據(jù)量大，查詢慢的問(wèn)題也比較嚴(yán)重。下面將以 OpenTSDB 為例，介紹其存儲(chǔ)優(yōu)化的原理和查詢優(yōu)化的經(jīng)驗(yàn)。

OpenTSDB 存儲(chǔ)優(yōu)化原理

存儲(chǔ)優(yōu)化前，Rowkey = metric name + timestamp + tags 的組合。Rowkey 很長(zhǎng)且重復(fù)很多。如下圖。

OpenTSDB 存儲(chǔ)優(yōu)化原理歸納如下：

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

優(yōu)化后的存儲(chǔ)結(jié)構(gòu)如下圖所示。

OpenTSDB 查詢優(yōu)化經(jīng)驗(yàn)

OpenTSDB 查詢優(yōu)化可以從使用端和服務(wù)端兩個(gè)方面著手：

使用端優(yōu)化：

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

服務(wù)端優(yōu)化：

• 預(yù)集合，先把慢查詢撈出來(lái)，提前去執(zhí)行查詢。查詢之后，把結(jié)果存儲(chǔ)到另一個(gè)地方。預(yù)集合可以由使用方或服務(wù)端實(shí)現(xiàn)。

服務(wù)端實(shí)現(xiàn)對(duì)使用方更友好，正如 InfluxDB 的 Continuous Queries 功能。

• 降精度，OpenTSDB 默認(rèn)是每一秒存一個(gè)數(shù)據(jù)，假設(shè)只要一分鐘，是不是可以每一分鐘只記一個(gè)數(shù)據(jù)，那樣數(shù)據(jù)量就會(huì)變成原來(lái)的六十分之一。

但是要注意降精度后，使用端要將這一分鐘的數(shù)據(jù)先自行累加然后再發(fā)送到服務(wù)端，因?yàn)?Hbase 是默認(rèn)覆蓋而不進(jìn)行累加。

• 結(jié)果緩存，這里不是指請(qǐng)求級(jí)別的結(jié)果緩存，而是要做到 Metric 或者時(shí)間線結(jié)果的緩存。

以上內(nèi)容由編輯王雪燕根據(jù)李灼靈老師在 WOTA2017 “大數(shù)據(jù)應(yīng)用創(chuàng)新”專場(chǎng)的演講內(nèi)容整理。

[[196735]]

李灼靈 (千慕)

阿里巴巴資深研發(fā)工程師

在浙江大學(xué)計(jì)算機(jī)系本碩畢業(yè)后，加入阿里巴巴。先后在共享、商家事業(yè)部負(fù)責(zé)過(guò) TAE、APM、客服 SAAS、千牛問(wèn)答等產(chǎn)品的架構(gòu)和研發(fā)工作，通過(guò) Docker、流式計(jì)算、APM、SAAS 化等技術(shù)推動(dòng)開放平臺(tái)的架構(gòu)升級(jí)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】