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、内存等物理资源无法按需分配
- 业务灵活性弱
- 数据更新困难