一文揭秘字节跳动基于 Apache Doris 的实时数仓探索|应用实践
导读:火山引擎 EMR 作为一款云原生开源大数据平台产品,集成了包括 Hadoop、Spark、Flink 等引擎,并做到 100% 开源兼容。Apache Doris 作为 OLAP 领域中一款极具代表性的开源组件,也被集成到了火山引擎 EMR 产品生态中。本文来源于火山引擎 EMR 团队大数据工程师在 Doris Summit 2022 中的演讲实录,将为大家详细介绍火山引擎 EMR 是一款怎样的产品,火山引擎 EMR 团队对 Doris 社区做出了哪些贡献,火山引擎 EMR Doris 目前具备了哪些能力优化,以及后续的规划方向。
作者|字节跳动数据平台 E-MapReduce 团队 昭伟
火山引擎是字节跳动旗下的云服务平台,将字节跳动快速发展过程中积累的增长方法、技术能力和工具开放给外部企业,提供云基础、视频与内容分发、数据平台 VeDI、人工智能、开发与运维等服务,帮助企业在数字化升级中实现持续增长。
火山引擎 EMR 是一款云原生开源大数据平台产品。首先,从开源大数据平台角度,火山引擎 EMR 集成了开源大数据生态的众多软件栈,包括 Hadoop、Spark、Flink 等引擎,并且做到 100% 开源兼容。Apache Doris 作为一款 OLAP 领域极具代表性的开源组件,所以我们也将其集成在火山引擎 EMR 生态中。其次,从云原生角度,我们也会基于云的特性做深度的能力增强,例如弹性伸缩、存算分离等。
我们在产品发布之初就已经集成了 Doris 引擎,它也是目前火山引擎 EMR 系统中的主力 OLAP 引擎之一。
EMR Doris 是一个开箱即用的云端 Doris 服务。支持海量数据的高效导入、实时更新,支持对 10PB 级别的海量数据进行高并发查询。我们认为 Doris 也是一个比较全面的 OLAP 引擎,不同于 ClickHouse 仅在大宽表的聚合上较为擅长,Doris 的各方面能力均比较出众。
支持向量化执行引擎,完备的 MPP 执行框架,多表关联能力更优异; 用户使用更友好,
支持标准 SQL 以及 MySQL 协议;
支持预聚合表引擎,能方便快速地实现数据的聚合; 数据接入更便捷,提供多种数据导入方式以及异构数据源的访问能力; 具备物化视图的能力,能够实现查询自动路由,通过预计算来提高查询速度和并发。
基于 Doris 的能力优化
基于 Hudi 的数据查询方案
在 22 年上半年,社区和火山引擎 EMR 团队一起做了基于 Iceberg 和 Hudi 的数据湖查询方案,火山引擎 EMR 团队主要负责 Hudi 的方案。
通过以上优化,Doris 实现无缝查询 Hudi 表。当然,目前这一方案只支持 Hudi 中 CopyOnWrite(COW) 存储类型的表,对 MergeOnRead(MOR) 表的支持尚在规划中。
Multi Catalog 联邦查询
22 年 6~7 月,我们和社区合作开启了Multi Catalog 联邦查询的项目,目标是让 Doris 能像 Presto 一样有 Plugin 的能力,可以进行联邦查询,实现 ES、JDBC 等数据源的查询,以及最典型的 Hive 、数据湖的联邦查询。
ComputeNode 计算节点
计算节点与联邦查询有很大的关联性。Doris 本身是典型的 Share-Nothing 架构,所以在它的 BE 节点上计算和存储是强绑定的,这样会带来几个影响:
扩容频繁 ,计算资源不够需要扩容,磁盘不够也需要扩容,只要满足一个条件,就必须要扩容。 弹性能力差 ,因为每个节点都绑定了数据,一旦扩容就需要做数据的迁移。而一旦涉及到数据的迁移,时间相会比较长。而在联邦查询的场景下,用 BE 去承载联邦查询的计算相对来说比较厚重。
多表物化视图
物化视图是一个典型的空间换时间的策略,通过预计算,配合查询时优化器的改写能力来直接查物化视图表,避免重复查询原表消耗过多的资源。
仅支持简单聚合、不支持函数运算,例如当在 Sum 函数中嵌套加入 Case When 语法时,物化视图无法创建。因此在即将发布的 Apache Doris 2.0 中,社区对单表物化视图进行了增强,可以支持更加复杂的 SQL 表达。 Doris 有比较好的 MPP 执行能力,经常会被用来做多表的关联查询,大宽表场景相对较少,因此如果物化视图只有单表时无法最大化发挥 Doris 的性能和场景优势。
基于以上需求,我们联合社区一起研发了多表物化视图,并在即将到来的 Apache Doris 2.0 版本发布这一重大功能。届时可以将带有 Join 的查询结果固化以供用户直接查询,支持定时自动或手动触发的方式进行全量更新查询结果,后续也将进一步支持更加完善的自动增量刷新。
MySQL Load Data
多流 Upset
多流 Upsert 源自于 Flink 中的多流 Join,而多流 Join 需要维护比较大的状态,会导致集群不太稳定,因此很多 OLAP 引擎都支持部分列更新的能力、支持多流 Upsert。
在性能方面,如果数据量不太大的时候,性能表现很优异,而当数据量特别大的时候,目前的这套实现还不是特别好,主要原因是多流 Upsert 是基于旧版本 Merge-on-Read 实现的,在读取时要做大量的合并操作。目前社区 Unique Key 新的 Merge-on-Write 模式实现了性能的大幅优化,后续我们也将计划与社区一起进行全新 Unique Key 部分列更新。
基于 Doris 的应用实践
以上是火山 EMR 对社区的贡献,下面将介绍我们基于 Doris 到底做出了一个怎样的产品。
混合部署
弹性节点组
Doris 本身不具备弹性的,而是有状态服务。但由于我们做了 ComputerNode 能力,也就使 Doris 支持了弹性能力。自适应配置
针对小规格,我们就将 page cache 关闭,把 buffer pool 调小,并调低 index cache 和 Load 内存配置,调小 Session 内存。 针对大规格,我们主要是调大默认 session 内存和默认 batch_size 大小。 中规格相对来说比较中庸,我们调小了 page cache,调低了 load page 内存配置和 index cache。
未来规划
2. 数据存储方面,因为 Doris 数据是自身进行管理,通过 Tablet 副本实现数据的高可用性。但在云时代,Doris 仍旧自己管理数据其实没什么太大的必要,因为云上有 S3、 TOS 这些对象存储产品,它们能保证非常高的可用性,能达到了十几个 9 级别,这是通过 Tablet 副本很难实现的,这也是我们做存算分离的一个初衷。3. 存算分离方面,存算分离是把数据放到远端持久化存储中,通过缓存缓解一部分的查询性能压力。在此之上,我们整个集群就有了更好的弹性,剥离开数据之后的扩容也变的更加灵活方便,相当于做了一个 stateless 的 BE,存算分离也能帮助用户进一步降低成本。另外在稳定性上也会有很大的提升,不需要自己通过 Tablet 副本实现高可用能力了,可用性可以直接交给 S3 和 TOS 等对象存储产品来实现。整体系统复杂度也会大大降低,这也是存算分离能带来的一个非常大的优势。
突破 Master 节点内存限制。现在的元数据全在内存中,当 Tablet 个数超过几千万的时候,内存消耗比较大。我们之前测过差不多 2000 万个 Tablet 的时候,内存达到将近 20G,这 20G 的数据完全在内存里,没办法用磁盘去做溢出。如果有了 MetaServer,比如基于 MySQL RDS,那就只将一些热点缓存在 FE 中,其他的有需要的时候再去拉取,时延也和现在的模式不会有太大差别。
元数据的高可用性。MetaServer产品可以做到跨 AZ 级别,甚至跨 region 级别的高可用,但通过 FE 来说实现是非常困难的,这也是云上和云下的一个巨大的差异点,云上可以通过依赖标准的云产品的能力来实现自己能力, 而在云下这些都需要自建。
节约成本。现在 FE 要通过三节点实现高可用,如果有了 MetaServer,只要一节点就可以,成本也就随之降低。
支持更多类型的外部元数据存储,比如RDS,KV 数据库等。
如果说前面提到的存算分离、MetaServer 都是手段,那我们真正的目的是希望做到 Doris 的极致弹性化。
SelectDB 官网:
https://selectdb.comApache Doris 官网:
http://doris.apache.orgApache Doris Github:
https://github.com/apache/doris
- End-欢迎更多的开源技术爱好者加入 Apache Doris 社区交流群,携手成长,共建社区生态。Apache Doris 社区当前已容纳了上万名开发者和使用者,承载了 30+ 交流社群,如果你也是 Apache Doris 的爱好者,非常欢迎您的加入!