基于云原生数据仓库 ByConity 众测

一、业务背景

在数据驱动时代，高效的数据处理和分析能力已经成为企业竞争力的关键。在实际业务中，用户会基于不同的产品分别构建实时数仓和离线数仓。其中，实时数仓强调数据能够快速入库，且在入库的第一时间就可以进行分析，低时延的返回分析结果。而离线数仓强调复杂任务能够稳定的执行完，需要更好的内存管理。

二、Byconity 简介

ByConity 是新一代的开源的云原生数据仓库，它采用计算-存储分离的架构，在满足数仓用户对资源弹性扩缩容，读写分离，资源隔离，数据强一致性等多种需求的同时，并提供优异的查询、写入性能。ByConity 使用大量成熟 OLAP 技术，例如列存引擎，MPP 执行，智能查询优化，向量化执行，Codegen, indexing，数据压缩等。

2.1 技术架构

ByConity 大体上可以分为 3 层：服务接入层，计算层和存储层。服务接入层响应用户的查询，计算层负责计算数据，存储层存放用户数据。

ByConity技术架构图

2.2 Byconity 的主要特性

存算分离

ByConity 存储计算分离的架构，使其原生支持存储计算分离，其中 Insert 使用专门用于写入的计算组，Select 使用专门用于读取的计算组，读写作业之间也不会相互影响。读操作和写操作对硬件资源的要求，以及时间的要求是不同的，可以分配不同的硬件资源去执行读操作和写操作; 避免读写互相影响，影响系统性能和浪费资源

弹性扩缩容

部署的各个节点均可以按需进行单独的扩容缩，对于大集群下扩容成本相对较低

存算分离-读写分离

复杂查询调优

分析型查询可以分为简单查询和复杂查询，简单查询通常是单表检索聚合、大表与小表 Join 查询，查询响应快；复杂查询指的是有大表、多表关联和复杂的逻辑处理，通常查询响应慢消耗资源多。ByConity 在复杂查询上进行了优化设计。 简单的查询可以采用两阶段执行模型，计算节点上面执行的 partial 阶段，服务节点上面执行的 final 阶段，一旦我们需要执行一个复杂的多个聚合或者 join 的查询，两阶段的执行模型灵活性非常低，也让查询的优化变得棘手。为了更好的支持分布式查询，方便执行优化器产生的执行计划，我们引入了支持多轮分布式执行模式的复杂查询。

复杂查询优化器

使用复杂查询执行模型需要开启优化器。需要通过配置 enable_optimizer=1，或者 dialect_type='ANSI' 开启。 同时生成统计信息, 没有统计信息，生成的查询计划不是最优。

ETL 能力

ByConity 在 1.0.0 版本 增加了 bsp 模式

• 可以进行 task 级别的容错；更细粒度的调度；基于资源感知的调度。

• 通过 bsp 能力，把数据加工（T）的过程转移到 ByConity 内部，能够一站式完成数据接入、加工和分析。

三、测试环境及数据集

本次测试使用到 TPCH 数据集。TPC-H 是美国交易处理效能委员会 TPC（Transaction Processing Performance Council）组织制定的用来模拟决策支持类应用的测试集。它包括一整套面向业务的 ad-hoc 查询和并发数据修改。

TPC-H 根据真实的生产运行环境来建模，模拟了一套销售系统的数据仓库。该测试共包含 8 张表，数据量可设定从 1 GB~3 TB 不等。其基准测试共包含了 22 个查询，主要评价指标为各个查询的响应时间，即从提交查询到结果返回所需时间。 在本次测试,TPC-H 生成数据脚本参数设置了 100。即生成 100G 数据

硬件环境

硬件环境

测试数据大小、分区情况

测试数据情况

测试参数设置

bsp 模式相关参数

bsp 模式相关参数调整可以影响 ETL 能力

bsp相关配置参数

查询优化参数

查询优化参数

四、测试结果

本次测试由于硬件资源不是很充足,只测试了没有使用 bsp 模式和使用 bsp 模式时一倍 worker 的两个维度,除此以外还测试没有创建统计信息和创建统计信息之后查询差异,创建统计信息之后,在复杂查询 query5、7、8、9 等查询中,查询性能提升特别明显.

在使用 bsp 模式相对查询性能会差一点,因为 bsp 模式会将一个查询切分成多个 task，然后分别执行，每个 task 的执行资源相对减少了。在实际测试中,初期由于参数没有调优,exchange 会超时,未开启 bsp 模式的直接返回错误,而开启 bsp 模式的查询可以完成任务.

TPCH查询时延情况

在本次测试中,使用 Promethus 监控了相关查询的资源使用情况.