【.com原创文章】淘宝和天猫每天都有数亿不同的买家和卖家进行对话，产生数百亿的聊天记录。实时分析客服聊天记录是实现智能客服的基础。本文主要分享云客服的整体架构，包括实时分析场景、架构、技术难点，以及为什么要从NoSQL迁移时序数据库以及使用心得。网络购物带动了客服功能的转变，如下图所示，是国内客服系统的发展历程。国内客服系统经历了传统客服、网页客户端和云客服三个发展阶段。传统客服主要以呼叫中心为主，以电话客服为主，人力投入成本高，部门间沟通少，效率低。随着互联网的发展，出现了网页端客服，打破了单一的电话形式，客服可以同时接待多个用户，减少了客户等待时间和客服成本。移动互联网时代，触达用户的渠道越来越多，相对碎片化。聚合各个渠道的反馈，保证跨渠道用户体验的一致性，是提升企业服务质量的重要手段，于是云客服应运而生。多渠道和智能化是云客服最明显的两个特征。客服可利用云客服平台统一处理公司官网、APP、公众号等各渠道的用户咨询，确保服务质量的统一性。同时，通过机器人、智能提示、营销提示等智能插件，提高客服工作效率，使客服具备销售属性。下图是客服功能改造前后的对比图。云客服整体架构如下图所示，是云客服的整体架构。云客服架构自上而下可分为客户接触点、接入层、应用层和支撑层。客户接触点。官网、商城、微信、微博等客服接点通过统一接入网关接入客服工作台。接入层。接入层首先会识别用户身份，比如：VIP还是普通用户，新用户还是老客户。不同的用户会被自动路由到不同的客服群进行服务。这些客户服务群体在响应技巧和推荐内容方面各不相同。应用层。应用层是整个云客服的核心，包括客服工作台、智能插件和客服管理。客服台统一接收各种渠道的在线和电话咨询，并根据用户反馈形成各类工单，下发给其他部门处理。智能插件主要针对客服，如：自动订单提醒、物流、订单查询等，可以大大减少客服的重复性工作。并且智能结合的销售和营销活动提示可以大大增加客服指南的销售量。客服管理包括知识库、质检、绩效考核、坐席、客情等，是客服主管或企业主经常使用的功能。支撑层。该层包括知识库、智能语义分析引擎、呼叫云、IM云、酒店云、轨迹云等基础设施。云客服的智能插件、客服管理等核心功能，都依赖于聊天记录的实时分析能力。下面介绍实时分析的场景、架构和关键技术问题。实时分析场景如下图所示，是云客服实时分析的几个场景。热点问题分析。及时分析用户反馈最多的问题，优先解决。尤其是在推出或推广新产品时，非常有效。实时接收。实时显示接待情况，哪些客服未准时在线，哪些门店无法接待，一目了然。实时质量检测。及时发现客服沟通是否按规定进行，如是否使用尊称、说话技巧是否符合要求等。还可以分析客户情绪和满意度，介入客服与客户之间的纠纷。客户及时。对客服人员变动频繁，新客服人员较多的情况很有用。实时分析架构如下图所示，为云客服实时分析架构。数据收集在数据收集阶段，有几点需要注意：收集尽可能多的数据。“巧妇难为无米之炊”，以客服场景为例，除了聊天记录，结合交易数据，可以计算出客服引导的交易额，以及用户的提问可以根据浏览轨迹猜测。最小化性能消耗和实时性，这里可以使用批量发送，日志直接发送不落盘等。数据通道数据通道主要有两种方式：消息队列和API。消息队列传输原始数据，API提供辅助原始数据。使用消息队列时要注意：发送时要注意消息体的大小，每个消息队列的最大消息体大小是不同的，例如：RocketMQ推荐4KB。打包成最大尺寸再发送，可以最大化系统吞吐量。消费时，是分批消费还是单品消费。通常，当数据量较大且准确率不高时，可以采用批量消费的方式来提高节点的处理能力，但相对而言，故障补偿和事务性能难以保证。记录消息轨迹。一些消息队列可以通过MsgID查询消息的生产者、消费者和消费次数，方便在消息丢失或重复时进行排查。支持消息重置。当消费者发生故障或发布时，往往需要将消费的偏移量设置到之前的某个时间点，然后重新消费。常用的实时计算引擎有Storm、Spark、Flink。基本环节有：解析器（Parser）和过滤器（Filter），尽快过滤掉不需要的数据，减轻后续环节的压力。Segmenter，分词的关键是词库的积累。不同的行业和场景有不同的术语，词库直接影响Solver的好坏。求解器具有三个功能。一是问题分类，如产品咨询、物流咨询、活动咨询等。二是言语能力的测试，如：敏感词、礼貌用语等。三是情绪分析，分析客户当前的情绪。规则引擎，根据前面的分析，结合运营规则计算出业务指标。使用规则引擎有两个优点。一是方便计算一些比较复杂的指标，比如回购率。二是支持动态修改，比如调整某个参数的权重，无需发布即可立即修改。MetricAggregator（度量聚合器）将计算出来的基础数据进行聚合，比如按时间、一分钟、一小时汇总数据，计算评估或方差。数据存储聚合后的数据将存储在Hbase中。下图是基本的Hbase存储结构。Rowkey=metricname+timestamp+tagsRowkey由一个metric名称、一个时间戳和一组标识此数据的键值对组成。后面会介绍如何优化这个存储。实时分析常见问题在对海量数据进行实时分析和聚合时，会遇到一些问题。本文主要选取数据倾斜、窗口分割和海量时间线这三个最常见的问题进行分析。问题一、数据倾斜数据倾斜也称为数据热点。如下图所示，上半部分是MapReduce流程，下半部分是流处理流程。不管是MapReduce还是流处理，总有一种数据比其他数据多。比如上图中的绿色三角就比其他图形多。实际生产中的热点数据量可能是其他数据的几十倍。此类数据热点的出现会导致队列中消息堆积，处理节点内存过高，从而触发FullGC或OOM。最后，工作节点的不停崩溃和迁移会加剧这种现象。那么，如何处理呢？常用的方法是：尽可能细粒度的散列。以聊天记录为例，如果用户是最小粒度的，将一个用户的所有聊天记录hash在一起，那么有些账号的数据量会很大，很容易出现热点。再细分的话，聊天是最小的粒度，A和B聊天属于一类，A和C属于另一类，这样数据会均匀很多。特殊键处理。在大多数应用场景中，都会有一些标杆用户的数据量是其他用户的几十倍。对于此类客户，可以采用白名单的形式进行特殊处理。两阶段合并。将一次Merge操作分成多次。一开始不需要统计最终结果。可以先做partialmerge，再做fullmerge，可以缓解数据热点问题。但是对应的工作节点数量会增加，成本也会增加。问题二：WindowSegmentation流式计算本质上是将连续的数据分割成时间间隔。此操作称为窗口分割。如下图，按5秒或15秒拆分：常见的计算窗口有固定窗口、滑动窗口和会话窗口三种。如下图所示：固定窗口。根据工作节点的系统时间，数据按照固定的周期进行划分，相互之间没有重叠，是比较理想的状态。事实上，由于分布式系统中系统时间和网络延迟的差异，工作节点接收到的数据是乱序的，接收时间不能视为数据产生的时间。滑动窗口。在固定的统计周期上加一个滑动时间，滑动时间到后保存结果，关闭窗口。例如：如果预估数据一般延迟10s，那么滑动时间可以设置为15s，15s后数据到达。您可以考虑丢弃或执行特殊处理逻辑。滑动窗口比固定窗口需要缓存更多的数据，窗口关闭、状态存储和恢复也更复杂。会话窗口。不是按时间，而是按某些事件作为窗口的划分，也就是会话窗口。以聊天为例，A和B在聊天，A说了一句或几句后，只有B回复了，才形成一个窗口。此时可以得到响应时间、问答数量等各项指标。一般来说，在处理难度上，Tumbling（固定）
