Doris 是一款开源的 MPP 分析型数据库产品，不仅能够在亚秒级响应时间即可获得查询结果，有效的支持实时数据分析，而且支持10PB以上的超大的数据集。相较于其他业界比较火的OLAP数据库系统，Doris的分布式架构非常简洁，支持弹性伸缩，易于运维，节省大量人力和时间成本。目前国内社区火热，也有美团、小米等大厂在使用。

本文主要讨论京东客服在人工咨询、客户事件单、售后服务单等专题的实时大屏，在实时和离线数据多维分析方面，如何利用Doris进行业务探索与实践。近些年来，随着数据量爆炸式的增长，以及海量数据联机分析需求的出现，MySQL、Oracle等传统的关系型数据库在大数据量下遇到瓶颈，而Hive、Kylin等数据库缺乏时效性。于是Doris、Apache Druid、ClickHouse等实时分析型数据库开始出现，不仅可以应对海量数据的秒级查询，更满足实时、准实时的分析需求。离线、实时计算引擎百花齐放。但是针对不同的场景，面临不同的问题，没有哪一种引擎是万能的。我们希望通过本文，对京东客服业务在离线与实时分析的应用与实践，能够给到大家一些启发，也希望大家多多交流，给我们提出宝贵的建议。

京东客服作为集团服务的入口，为用户和商家提供了高效、可靠的保障。京东客服肩负着及时解决用户问题的重任，给用户提供详细易懂的说明与解释；为更好的了解用户的反馈以及产品的状况，需要实时的监控咨询量、接起率、投诉量等一系列指标，通过环比和同比，及时发现存在的问题，以更好的适应用户的购物方式，提高服务质量与效率，进而提高京东品牌的影响力。

EasyOLAP Doris 数据源主要是实时KAFKA和离线HDFS文件。实时数据的导入依赖于 Routine Load的方式；离线数据主要使用Broker Load和 Stream Load的方式导入。

EasyOLAP Doris 数据导入链路

目前 EasyOLAP Doris 项目的监控，使用的是 Prometheus+Grafana 框架。其中 node_exporter 负责采集机器层面的指标，Doris 也会自动以 Prometheus格式吐出 FE、BE 的服务层面的指标。另外，部署了OLAP Exporter 服务用于采集 Routine Load 相关的指标，旨在第一时间发现实时数据流导入的情况，确保实时数据的时效性。

EasyOLAP Doris 监控链路

EasyOLAP Doris 为了保障0级业务在大促期间服务的稳定性，采取了主备集群双写的方式。当其中一个集群出现抖动或者数据存在延迟的情况，用户可以自主地快速切换到另一个集群，尽可能的减少集群抖动给业务带来的影响。 

京东OLAP团队分析需求之后，对Doris 做了一定的定制化开发，其中就涉及到动态分区管理功能。尽管社区版本已经拥有动态分区的功能，但是该功能无法保留指定时间的分区。针对京东集团的特点，我们对指定时间的历史数据进行了留存，比如618和11.11期间的数据，不会因为动态分区而被删除。

动态分区管理功能能够控制集群中存储的数据量，而且方便了业务方的使用，无需手动或使用额外代码来管理分区信息。

致力于不断提升用户体验，京东客服的数据分析追求极致的时效性。离线数据分析场景是写少读多，数据写入一次，多次频繁读取；实时数据分析场景，一部分数据是不更新的历史分区，一部分数据是处于更新的分区。在大部分的分析应用中，存在下述几种场景：

针对上述场景，在应用层有解决方案——将查询结果放入到Redis中，缓存会周期性的刷新或者由用户手动刷新，但是也会存在一些问题：

在EasyOLAP Doris 中，一共有三种不同类型Cache。根据适用场景的不同，分别为Result Cache、Sql Cache和Partition Cache。三种缓存都可以通过MySql客户端指令控制开关。

这三种缓存机制是可以共存的，即可以同时开启。查询时，查询分析器首先会判断是否开启了Result Cache，在Result Cache开启的情况下先从Result Cache中查找该查询是否存在缓存，如果存在缓存，直接取缓存的值返回给客户端；如果缓存失效或者不存在，则直接进行查询并将结果写入到缓存。缓存放在各个FE节点的内存中，以便快速读取。

Sql Cache按照SQL的签名、查询的表的分区的ID和分区最新版本号来存储和获取缓存。这三者一起作为缓存的条件，其中一者发生变化，如SQL语句变化、数据更新之后分区版本号变化，都会无法命中缓存。在多表Join的情况下，其中一张表的分区更新，也会导致无法命中缓存。Sql Cache更适合T+1更新的场景。

Partition Cache 是更细粒度的缓存机制。Partition Cache主要是将一个查询根据分区并行拆分，拆分为只读分区和可更新分区，只读分区缓存，更新分区不缓存，相应的结果集也会生成n个，然后再将各个拆分后的子查询的结果合并。因此，如果查询N天的数据，数据更新最近的D天，每天只是日期范围不一样但相似的查询，就可以利用Partition Cache，只需要查询D个分区即可，其他部分都来自缓存，可以有效降低集群负载，缩短查询响应时间。

一个查询进入到Doris，系统先会处理查询语句，并将该查询语句作为Key，在执行查询语句之前，查询分析器能够自动选择最适合的缓存机制，以确保在最优的情况下，利用缓存机制来缩短查询相应时间。然后检查Cache中是否存在该查询结果，如果存在就获取缓存中的数据返回给客户端；如果没有缓存，则正常查询，并将该查询结果以Value的形式和该查询语句Key存储到缓存中。Result Cache可以在高并发场景下发挥其作用，也可以保护集群资源不受重复的大查询的侵占。Sql Cache 更加适合T+1的场景，在分区更新不频繁以及Sql语句重复的情况下，效果很好。Partition Cache 是粒度最小的缓存。在查询语句查询一个时间段的数据时，查询语句会被拆分成多个子查询。在数据只写一个分区或者部分分区的情况下，能够缩短查询时间，节省集群资源。

为了更好的观察缓存的效果，相关指标已经加入到Doris的服务指标中，通过Prometheus和Grafana监控系统获取直观的监控数据。指标有不同种类的cache的命中数量、不同种类的cache命中率、cache的内存大小等指标。

京东客服Doris主集群，11.11期间，在没有开启缓存时，部分业务就导致CPU的使用率达到100%；在开启Result Cache的情况下，CPU使用率在30%-40%之间。缓存机制确保业务在高并发场景下，能够快速的得到查询结果，并很好的保护了集群资源。

实时数据的导入一直是一个挑战。其中，保证数据实时性和导入稳定性是最重要的。为了能够更加直观的观察实时数据导入的情况，京东OLAP团队自主开发了OLAP Exporter，用于采集实时数据导入相关的指标，如导入速度、导入积压和暂停的任务等。通过导入速度和导入积压，可以判断一个实时导入任务的状态，如发现任务有积压的趋势，可以使用自主开发的采样工具，对实时任务进行采样分析。实时任务主要有三个阈值来控制任务的提交，分别是每批次最大处理时间间隔、每批次最大处理条数和每批次最大处理数据量，一个任务只要达到其中一个阈值，该任务就会被提交。

通过增加日志，发现FE中的任务队列比较繁忙，所以，参数的调整主要都是将每批次最大处理条数和每批次最大处理数据量调大，然后根据业务的需求，调整每批次最大处理时间间隔，以保证数据的延迟在每批次最大处理时间间隔的两倍之内。通过采样工具，分析任务，不仅保证了数据的实时性，也保证了导入的稳定性。另外，我们也设置了告警，可以及时发现实时导入任务的积压以及导入任务的暂停等异常情况。

监控指标主要分为两个部分，一个是机器层面指标部分，一个是业务层面指标部分。在整个监控面板里，详细的指标带来了全面的数据的同时，也增加了获取重要指标的难度。所以，为了更好的观察所有集群的重要指标，单独设立一个板块——11.11重要指标汇总板块。板块中有BE CPU使用率、实时任务消费积压行数、TP99、QPS等指标。指标数量不多，但是可以观测到所有集群的情况，这样可以免去在监控中频繁切换的麻烦。

除了上述说到的采样工具和OLAP Exporter，京东OLAP团队还开发了一系列的Doris维护工具。

京东客服是在2020年年初开始引入Doris的，目前拥有一个独立集群，一个共享集群，是京东OLAP的资深用户。

在业务使用中也遇到了例如任务调度相关的、导入任务配置相关的和查询相关等问题，这也在推动京东OLAP团队更深入的了解Doris。我们计划推广使用物化视图来进一步提升查询的效率；使用bitmap来支持UV等指标的精确去重操作；使用审计日志，更方便的统计大查询、慢查询；解决实时导入任务的调度问题，使导入任务更加高效稳定。除此之外，我们也计划优化建表、创建优质rollup或物化视图以提升应用的流畅性，加速更多业务向OLAP平台靠拢，以提升应用的影响力。