【遇见 Doris】Apache Doris 在京东广告平台的应用

6 月 29 日，Doris 有幸得到中国信通院云大所、大数据技术标准推进委员会的支持，在中国信通院举行了 0.11.0 新版本预览线下沙龙。各位嘉宾都带来了干货满满的分享。关注 Doris 官方公众号，后台回复“0629”即可获取各位嘉宾分享 PPT 及现场录像。

今天是刘航源同学代表京东广告平台带来的关于 Apache Doris (incubating)的应用介绍。

此次 Doris 完美支撑了京东 618 大促期间的报表业务。在大家疯狂剁手的背后，Doris 为每一位广告主带来了平稳的在线服务。稳定、高效，是航源对 Doris 在 618 大促期间表现的概括。

需求背景

应用场景举例

• 查询效率与实时性：京东广告平台有上百张报表，每日百亿级别的聚合结果增量，需要保证查询效率与实时性的统一。

• 低延迟：区别于分析师的 ad-hoc 分析需求，报表场景对于延迟要满足毫秒级别。

• 高 QPS：每日有几千万的查询调用量，日常峰值 QPS 达到四千以上，SQL on Hadoop 的方案难以满足。

• 方案简单：既能满足报表查询，又能满足 OLAP 分析型需求，作为数据的统一出口。

为了解决目前存在的问题，京东急需一套完整的、简单已运维且稳定的报表存储方案。

Why Doris ?

目前开源的解决方案主要是 SQL on Hadoop 的生态。但是 Hadoop 方案整体上依赖模块过多，对于业务团队来说，运维成本高。

如果使用公司大数据平台提供的 Hadoop 环境，难免与其他团队共用，查询效率与稳定性难以保证，对于对查询延迟要控制在毫秒级的报表需求更是无法满足。如果自建 Hadoop 环境，自己维护，又会出现运维压力太大的问题。比如使用 Kylin，就需要维护多个 Hadoop 生态模块，任何一个模块的不稳定都可能导致报表系统的异常。

所以我们选择了 Apache Doris 作为我们的报表存储与查询模块，主要考虑到其几个关键优点。

谷歌 Mesa 理论支持，百度工程实践。并且已经进入 Apache 基金会孵化，未来可期，并且后续开发维护有保障。

完善的功能支持，标准 MySQL 协议。因为 Apache Doris 支持 MySQL 协议，现存的很多外围 MySQL 功能模块都可以使用，整体使用都很方便。并且原有的 MySQL 数据库的用户迁移成本很低。

高并发、高 QPS 支持。因为核心代码全部使用 C++实现，性能方面要优于其他语言。另一方面良好设计也保证 Apache Doris 在应对高并发时性能要优于其他开源产品。

方便运维，架构清晰。只有 FE 和 BE 两个模块，外部依赖少。可以专心维护 Doris 系统，其他 ETL 的工作可以交给业务部门处理，解放了人力。

618 战绩

618 大促期间，Doris 提供了非常稳定的线上服务。在线进行了稳定的 schema change，全程无事故。

在导入方面，支撑 100 亿行/日的增量，导入峰值达到 2000w/分钟，秒级导入延迟。

在查询方面，支撑了 4000w+的每日查询，TP99 仅为 150ms。大促期间 QPS 峰值 3000+，压测阶段峰值达到 1w+。

在京东广告平台的应用

下图介绍了数据从产生到入库的过程所有的点击流。订单流消息会进入 Kafka 消息队列，然后经由 Spark/Flink 的计算，生成一个批次数据，这个批次数据产生的频率由业务端控制。产生数据文件后，向 JMQ（京东内部消息队列）中录入一个。任务。后面的 Loader 模块会根据任务中的批次路径拉取数据，导入 Doris 中。

JMQ 内存储的并不是原始的消息，而是经过 Spark/Flink 生成的批次文件的路径。同时会有一个自定义的 Label 标签值，来保证入库任务的不重不丢。因为同一个批次任务使用相同的 Label 值，而 Doris 中一个 Label 值只能被导入一次。而真正业务去重逻辑则放在 Spark/Flink 这一层，由业务方控制，这样就可以使业务与存储解耦开，同时又可以保证 Doris 中的增量频率不会太快，保证了查询的性能。

在内部我们使用了三种导入方式，下面分别介绍下使用的场景：

Stream Load：主要使用在导入实时数据方面，当前内部数十张表，每张表一分钟一更新。保证了业务数据的准实时。并且因为 Stream Load 的同步任务，内存传输数据的特性，Stream Loader 不需要拉取数据到本地磁盘，可以实现直接读取 hdfs 上的增量数据，内存解析，内存导入的功能。

Broker Load：主要用在单次更新数据量较大的多维分析型报表和 T+1 更新的离线表的业务上。目前最大单次更新在 30G+，性能稳定良好，一般可在 20 分钟以内完成入库。

KafkaLoad：因为 Kafka 的原因，以及业务方有重复发送消息的情况。Apache Doris 直接对接 Kafka 的 Kafka Load 方式无法实现消息去重的功能，所以我们目前并没有将其使用在广告效果报表方面。而我们在一些日志分析的需求上使用 Kafka Load。因为日志分析对数据准确性没有要求非常高，那么使用 KafkaLoad 就可以省去中间的 ETL 的工作，简化了整体架构。

查询心得

设置合理的分区分桶列：因为 Doris 会根据分区分桶实现过滤，所以建表时应该谨慎选择分区列和分桶列。能否命中分区分桶列，对查询的影响非常大。

建立合理的 Rollup 表：可以说物化 rollup 的功能是 Doris 查询效率高的关键因素，因此建立合理的 rollup 表非常重要。那么实际使用中如何选择 rollup 呢？一般是将 Doris fe 的日志导入 Doris 中，分析慢查询，Scan bytes 等指标，找到消耗资源大的查询，针对这些实际的查询建立 Rollup 表。

设置 doris_max_scan_key_num：oris 会将可枚举的类型拆分查询，比如 id=5 and date>='2019-01-01' and date<='2019-01-31'的查询，doris 会将其拆分成 31 个小查询分别查询[5,2019-01-01]...[5,2019-01-31]，但是会有一个阈值（doris_max_scan_key_num），超过这个阈值后不再拆分，可根据业务调整

建议

最后京东列举了在使用过程中遇到的几个问题，在这里欢迎有更多的同学加入我们，让 Doris 变得更好。

1、SQL 优化器能力偏弱：使用过程中发现 Doris 的 SQL 优化器的优化结果并不足够好，这对于大规模的分析型需求是难以接受的。当然，目前 Doris 已经在开始优化了，相信不久就可以解决这个问题。

2、多机房部署有困难：如果整个机房的服务不可用了，如何容灾。目前 Doris 是无法感知机房信息的，所以如果单集群的 be 分布在多机房，势必会对 IO 压力很大，对查询性能造成影响。如果多机房多集群双写，对业务压力又会非常大。

3、维度表更新困难：这个是所有 olap 类型数据库的通病，就是为了保证查询的效率，无法大规模的 update 数据。造成实际业务中一些维度表（比如 hive 的 replace）更新困难。对于这种需求可以通过 drop+rename 的方式解决，就是每次新建一张临时表，然后导入数据。再将原表删除，将临时表 rename 成正常的表名来实现 replace 的功能

4、大规模平台化的能力不足：在我们使用的过程中，出现过个别查询因为查询量大或者触发 bug 导致整个集群的大量资源被占用，无法回收。目前仅能设置 exec_mem_limit 参数控制，并且将一些报表型的查询和 olap 分析型的查询分离部署。

此次沙龙我们有幸邀请到了来自一点资讯、京东、搜狐、百度智能云的技术大牛带来他们的应用实践和开发分享。

其他嘉宾的分享会在近日放出，欢迎关注 Apache Doris (incubating)官方公众号，后台回复“0629”即可获取各位嘉宾分享 PPT 及现场录像。

欢迎扫码关注：

Apache Doris(incubating)官方公众号

相关链接：

Apache Doris 官方网站：

http://doris.incubator.apache.org

Apache Doris Github：

https://github.com/apache/incubator-doris

Apache Doris Wiki：

https://github.com/apache/incubator-doris/wiki

Apache Doris 开发者邮件组：

dev@doris.apache.org

本文分享自微信公众号 - ApacheDoris（gh_80d448709a68）。

如有侵权，请联系 support@oschina.cn 删除。

本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。