【遇见Doris 2019.12.22】Apache Doris在京东双十一大促中的实践

来自京东零售-商业提升部的刘航源为大家带来了 Apache Doris 在京东双十一大促活动的实践

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

以账户报表为例,京东的报表平台有如下特点:

  • 存储介质多、逻辑计算复杂且延迟敏感:一张报表中通常会有非常多的指标列,涉及多个存储介质(MySQL、Doris、Redis等),这些列都需要实时关联,且需要保证报表是毫秒级数据返回。
  • 聚合数据为主:与Doris的聚合模型场景贴合。
  • 对外业务,服务质量要求高:面对的客户是所有京东的广告主。

京东广告平台在京东内部支持了十余个业务线,300+报表,涵盖了270个底层数据。覆盖了京准通内绝大多数的效果报表。超过80%的业务需求可以通过修改配置支持,并且平台作为统一的数据出口,拥有完善的权限管理系统。

80e417affefbb4d7508f4f8e2b2a1d1 京东使用Doris解决当下面临的问题145

在使用Doris前,原有的业务系统如图所示。报表系统下对接包括MySQL、Redis以及自有系统等,在今年年初时遇到一些困难。主要包括:

  • 性能问题:查询速度慢,满足不了大批量毫秒级返回数据的需求

  • 运维问题:运维困难,难以保障

  • 开发成本高

  • SQL兼容难

于是在19年年初决定使用Doris。

业务现状

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

  • 产品线众多,甚至包括海外产品线

  • 对接的业务方众多

  • 维护集群众多,面临资源隔离和数据隔离的问题

  • 财务相关数据,数据安全性要求高

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

统一化

  • 增量可回溯/可查询:对于导入增量进行把控

  • 更强的抗泄洪能力:因为对接产品线众多,不能因为任务激增而影响到众多产品线

  • 业务方可自助查数、补数

  • 可接受秒级的任务延迟

平台化

  • 数据定时备份

  • 支持任务优先级

  • 细化延迟监控

国际化

  • 支持时区功能

  • 多集群多环境/同名HDFS NS的区分

优化后整体架构如下:

Web Server:

  • 集群运维可视化
  • 统一运维
  • 对外接口系统

ReportEngine:

  • 查询业务引擎
  • 业务逻辑处理
  • 主要作为对外出口对接业务

AdminServer:

  • 任务的管理系统
  • 控制Load并发

数据最开始从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)

WebServer功能

WebServer是京东研发的功能,覆盖了大部分Doris的操作功能,包括建表、建Rollup、建Partition、数据管理、数据查询、数据导入、任务管理、性能监控、集群导入、操作日志查询的功能。业务方可以方便地通过这个平台来提交任务。

数据管理

数据导入

任务管理

未来京东考虑将WebServer贡献给社区,让更多用户享受到WebServer带来的便利。

如何处理历史数据变更

Doris修改数据的成本很高,但数据的修改和删除需求在真实业务中时常出现。

640 (5)

京东经历了几个阶段。

从最开始的无法进行删除操作,发展成采用了外部留存重新刷数的方式。即原来导入的错误数据不要删除,采用replace的方式,将原来的数据全部倒入一份负值的,从而将value刷成0,再将正确的数据导入进去。这种方式的不便之处在于要留存原始错误数据。

后来采用了Doris的delete功能,把错误数据删除后再将正确数据insert进来。

但所有这些方式都存在一个问题,即总有一段时间窗口内数据value为0。这对于外部系统来说是不能容忍的。例如广告主需要查看自己的账户信息,如果因数据变更问题而导致账户显示为0,将是难以接受的,很不友好。

京东非常期待Spark Doris connector的功能正式发布,也已经试用了很大一部分。

应用Spark Doris connector后,对于这类操作将会更加便捷。例如上一行是错误数据,下面的一行是正确数据。Spark可以链接两条流,一条流链接Doris,一条流链接外部的正确数据(例如业务部门给的Parquet文件),做diff操作,将所有value算出diff值。可以看到最后一行的结果,将其导入进Doris即可。这样的好处是可以消除中间的时间窗口,同时也便于平时经常使用Spark的业务方来进行操作,非常友好。

80e417affefbb4d7508f4f8e2b2a1d1 京东双十一大促期间Doris的表现145

稳定性

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

导入性能

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

查询性能

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

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

不仅如此,所有统计指标也是通过Doris来进行分析的:京东在每台Doris上部署了一个Doris的Agent来收集日志,然后将其导入到Kafka中,再通过Doris的Kafka Load,即可使用Doris分析自己的日志。可以通过Doris优秀的OLAP特性,分析任意时间段,任意维度的查询,为问题定位和性能分析提供了很大的帮助。

未来规划

  • 贡献成熟的Web屏体啊
  • 建立UDF平台,提升业务灵活性
  • 参与SQL优化器开发
  • 支持Apache Doris (incubating)社区发展

原文链接:https://mp.weixin.qq.com/s/8XnwJXm4kzq56SvElwL6kA