Apache Doris在京东广告的应用

Apache Doris介绍

Doris 是分布式、面向交互式查询的分布式数据库，主要部分是 SQL，内部用到 MPP 技术。

什么是 MPP?

MPP ( Massively Parallel Processing )，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。简单来说，MPP 是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果 ( 与 Hadoop 相似 )。

Doris 主要解决 PB 级别的数据量（如果高于 PB 级别，不推荐使用 Doris 解决，可以考虑用 Hive 等工具），解决结构化数据，查询时间一般在秒级或毫秒级。

Doris 由百度大数据部研发 ( 之前叫百度 Palo，2018年贡献到 Apache 社区后，更名为 Doris )，在百度内部，有超过200个产品线在使用，部署机器超过1000台，单一业务最大可达到上百 TB。

Apache Doris主要负责京东的广告平台报表业务，京东的广告平台每天支撑了千万级以上的查询量，同时每天有百亿级的增量需要维护。所有的报表级查询需要毫秒级返回数据，场景主要包括报表查询、多维分析、日志分析等。

京东广告平台在京东内部支持了十余个业务线，300+报表，涵盖了270个底层数据。

报表系统下对接包括MySQL、Redis以及自有系统等，在今年年初时遇到一些困难。主要包括：

性能问题：查询速度慢，满足不了大批量毫秒级返回数据的需求
运维问题：运维困难，难以保障
开发成本高
SQL兼容难

于是我们开始调用替代的方案

SQL on Hadoop ：这种方案有几个问题

HDFS / Spark 性能不稳定：对外的业务如果自建hdfs，对于小团队运维挑战很大，如kylin系统，性能和功能都是可以的。但是负责而庞大的外部模块，让我们觉得运维难度太大。而如果使用大数据平台的共用集群，稳定性不好保障，责任也不好划分。
实时性与性能难兼容：这是整体设计思路决定的。如果是高并发的广告报表业务，hadoop生态实时性无法满足。

ClickHouse方案：ck是目前很流行的解决方案，速度非常彪悍。但是ck也无法避免的有几个问题。

运维很复杂，分布式做的不完整
不支持标准的sql，业务迁移难度大
qps低

Why Doris ?

谷歌Mesa理论支持(Mesa + impala)、百度工程实践
完善的功能支持，标准mysql协议，可以使用mysql-client直接连接
高并发、高qps支持
方便运维，架构清晰，数据迁移门槛低

使用中遇到的问题：

在大规模将系统切入Doris时遇到了下面几个问题：

产品线众多，甚至包括海外产品线
对接的业务方众多
维护集群众多，面临资源隔离和数据隔离的问题
财务相关数据，数据安全性要求高

在切换时有如下几个诉求：

统一化

增量可回溯/可查询：对于导入增量进行把控
更强的抗泄洪能力：因为对接产品线众多，不能因为任务激增而影响到众多产品线
业务方可自助查数、补数
可接受秒级的任务延迟

平台化

数据定时备份
支持任务优先级
细化延迟监控

国际化

支持时区功能
多集群多环境/同名HDFS NS的区分

于是我们开发了一个外部的Admin模块

数据最开始从Kafka进行导入，经过ETL层。ETL会做一份增量数据，数据批次会取决于业务需求。目前线上大部分是每分钟会有一个批次。通过HTTP的接口调用Admin Server，收到Load的任务后，会写到MySQL的消息队列上，向Doris提交一个Load的任务。Doris收到任务后会提交Broker Load将HDFS的数据导入到Doris中。所有历史数据导入任务存储在MySQL中，通过Admin Server来实现可回溯可查询的功能可。同时可实现定期的Backup。同时Load任务的并发是可控制的，也提供了更强的抗泄洪能力及支持任务优先级的能力。

所有提交的任务会通过HTTP的JSON发送到Admin Server里，主要是Doris的Broker Load需要的字段。Label，Path和Type（目前支持csv和Parquet，ORC)

双11大促期间Doris的表现

稳定性

整个大促期间Doris的内存、CPU非常平稳，即使11日凌晨也没有出现大规模上涨
整个集群规模已经的达到了上百台
整个大促期间没有Bug和事故

导入性能

双11当天达到了120亿行的增量（聚合后的数据）
峰值导入在2000万/分钟
所有事实表基本都可以做到秒级延迟

查询性能

京东只用了40台16核Docker支撑了查询，且最高峰CPU占用率仅30%左右。达到的效果：

双11当天承载了8000万+的查询
TP99 58毫秒，TP999 164毫秒
双11当天00:20左右达到峰值QPS达到4500+，压测阶段QPS达到万级以上

目前的问题

SQL优化器能力偏弱
CPU、内存等物理资源无法按需分配
业务灵活性弱
数据更新困难