Apache Doris在新浪微博的实践

在我们上线运行Doris时,又发现RapidsDB这款MPP数据库非常优秀,号称能支持TB级数据在毫秒内响应(处理千亿的数据在毫秒内响应)。可以预见,随着数据库技术的不断进步,可以大大提高OLAP的数据分析能力。

一 开发背景

从2018年开始,新浪微博使用Kylin做OLAP数据分析,但是Kylin只能用来做固化的OLAP数据分析,固化的多维分析,就需要提前定义好指标和维度,同时Kylin又有维度爆炸的风险。这样,就不能随意添加条件或者关联表进行灵活的数据分析查询。

还有一个更严重的问题,Kylin中都是聚合后的数据,没有保留明细数据,在查询问题的时候,没有办法进行下钻分析。

二 面临的痛点

2.1 汇总数据的交互式查询

数据分析师团队最典型的应用场景就是,在各种维度下进行自定义查询,面对如此灵活多变、多见即所得的应用场景,既有的Kylin系统是没办法支持的。我们没办法把所有的场景都能预想出来。Kylin是一种预计算的执行引擎,比如我们想计算过去3个月微博,在每个渠道的展现情况,需要重新计算3个月的Cube,要花费几个小时的时间。

2.2 明细数据的交互式查询

除了要分析汇总数据之外,对明细数据的查询也是一种刚需。通常会选择MySQL这种关系型数据库作为明细数据的快速检索,但是如果数据量非常大,MySQL显然是不能够支持的,并且如果遇到大量数据同步、新增字段和历史数据变更的时候,运维成本都非常高。

2.3 生产环境面临的挑战

数据呈爆炸模式增长,每天都需要用新的维度对历史数据进行回溯。在使用Kylin计算时,会有如下问题:

  1. 每天都要回溯历史数据,就失去了增量计算的意义。
  2. 每天要回溯历史数据量非常大,大概有10亿+的历史数据需要回溯。
  3. 数据计算耗时4个多小时,存储2TB+,消耗大量计算存储资源。
  4. 不支持明细数据的查询。

2.4 解决方案:引入MPP引擎,数据现用现算

随着分布式、并行化技术成熟应用,MPP引擎逐渐表现出强大的高吞吐、低时延计算能力,号称“亿级秒开”的引擎不在少数,单从业务实际应用考虑,性能在千万量级关联查询现场计算秒开的情况下,已经可以覆盖到很多应用场景,具备应用的可能性。

2.5 MPP引擎的选型

开源并且熟知的OLAP引擎有很多,比如Greenplum、Apache Impala、Presto、Doris、ClickHouse、Druid、TiDB等,我们结合自身业务的需求,从引擎建设成本出发,并立足于公司技术生态融合、集成、易用性等维度进行综合考虑,我们最终选择了Apache社区的Doris。

Apache Doris在新浪微博的实践

Apache Doris介绍

Doris是一种MPP架构的OLAP执行引擎,主要整合了Google Mesa(数据模型)、Apache Impala(MPP Query Engine)和Apache ORCFile (存储格式,编码和压缩)的技术。

3.1 Doris的架构

Doris的架构和TiDB类似,借助MySQL的协议,用户可以使用任意MySQL的ODBC/JDBC以及MySQL客户端,都可以直接访问Doris。Doris中的模块主要包括FE和BE两类:FE主要负责元数据的管理、存储,以及查询解析等;BE节点主要负责数据的存储、以及查询计划执行。

一个用户的SQL请求,经过FE解析、规划后,将具体的执行计划发送给BE,BE完成具体的查询任务。

FE的主要代码都是由Java开发,而BE的底层代码是由C++开发的。

Apache Doris在新浪微博的实践

3.2 Doris的数据分布

如果从Table的角度看数据结构,用户的一张Table会拆分成多个Tablet,Tablet会生成副本,存储在不同的BE中,从而保证数据的高可用和高可靠性。

Apache Doris在新浪微博的实践

3.3 易运维

Doris 部署无外部依赖,只需要部署 BE 和 BE,即可搭建起一个集群。

支持 Online Schema Change:支持在线更改表模式 ( 加减列,创建 Rollup ),不会影响当前服务,不会阻塞读、写等操作;这种执行是异步的 ( 用户不需要一直盯在那里 )。

3.4 Doris的特点总结

  • 同时支持高并发点查询和高吞吐的Ad-hoc查询。
  • 同时支持离线批量导入和实时数据导入。
  • 同时支持明细和聚合查询。
  • 兼容MySQL协议和标准SQL。
  • 支持Rollup Table和Rollup Table的智能查询路由。
  • 支持较好的多表Join策略和灵活的表达式查询。
  • 支持Schema在线变更。
  • 支持Range和Hash二级分区。

四 采用Doris做OLAP引擎

新浪微博采用30台BE+5FE的Doris环境,效率、性能表现情况如下:

  1. 支持30+个数据分析产品类型以上,整体响应速度达到ms级。
  2. 支持百万、千万级大表关联查询,同时进行维表关联的雪花模型,经过Colocate Join特性优化,可以实现秒级响应。
  3. 日级别,基于渠道、微博类型,同时满足汇总及下钻明细查询,都可以在秒级别查询出数据。
  4. 7日数据趋势分析查询,需要2~3秒。在数据量较大时,需要调动很多的集群资源,因此MPP的并发性能受限于集群的性能。
  5. 通过3年多的应用以及Doris的不断改进升级,Doris的高可靠、高可用、高可扩展性也得到进一步验证。

4.1 Colocate Join

Colocate Join(Local Join)是和Shuffle Join、Broadcast Join相对的概念,即将两表的数据提前按照Join Key Shard,这样在Join执行时就没有数据网络传输的开销,两表可以直接在本地进行Join。

整个Colocate Join在Doris中实现的关键点如下:

  • 数据导入时保证数据本地性。
  • 查询调度时保证数据本地性。
  • 数据Balance后保证数据本地性。

4.2 Bitmap 精确去重

当数据量越来越大,到几十亿几百亿时,使用的IO资源、CPU资源、内存资源、网络资源会变得越来越多,查询也会变得越来越慢。

于是我们在Doris中新增了一种Bitmap聚合指标,数据导入时,相同维度列的数据会使用Bitmap聚合。有了Bitmap后,Doris中计算精确去重的方式如下:

Apache Doris在新浪微博的实践

五 经验总结

在平台同学的共同努力下,Doris引擎性能还有较大提升空间,相信以Doris引擎为驱动的ROLAP模式会为微博的业务团队带来更大的收益。

在我们上线运行Doris时,又发现RapidsDB这款MPP数据库非常优秀,号称能支持TB级数据在毫秒内响应(处理千亿的数据在毫秒内响应)。可以预见,随着数据库技术的不断进步,可以大大提高OLAP的数据分析能力。

内容出处:,

声明:本网站所收集的部分公开资料来源于互联网,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。文章链接:http://www.yixao.net/tech/26025.html

发表评论

登录后才能评论