一、业务背景
在数据驱动时代，高效的数据处理和分析能力已经成为企业竞争力的关键。在实际业务中，用户会基于不同的产品分别构建实时数仓和离线数仓。其中，实时数仓强调数据能够快速入库，且在入库的第一时间就可以进行分析，低时延的返回分析结果。而离线数仓强调复杂任务能够稳定的执行完，需要更好的内存管理。
二、Byconity简介
ByConity 是新一代的开源的云原生数据仓库，它采用计算-存储分离的架构，在满足数仓用户对资源弹性扩缩容，读写分离，资源隔离，数据强一致性等多种需求的同时，并提供优异的查询、写入性能。ByConity 使用大量成熟 OLAP 技术，例如列存引擎，MPP 执行，智能查询优化，向量化执行，Codegen, indexing，数据压缩等。
2.1 技术架构
ByConity 大体上可以分为 3 层：服务接入层，计算层和存储层。服务接入层响应用户的查询，计算层负责计算数据，存储层存放用户数据。
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模式相关参数可以调整ETL能力
查询优化参数
四、测试结果
本次测试由于硬件资源不是很完备,只测试了没有使用bsp模式和使用bsp模式时一倍worker的两个维度,除此以外还测试没有创建统计信息和创建统计信息之后查询差异,创建统计信息之后,在复杂查询query5、7、8、9等查询中,查询性能提升特别明显.
在使用bsp模式相对查询性能会差一点,因为bsp模式会将一个查询切分成多个task，然后分别执行，每个 task的执行资源相对减少了。在实际测试中,初期由于参数没有调优,exchange会超时,未开启bsp模式的直接返回错误,而开启bsp模式的查询可以完成任务.
在本次测试中,使用Promethus监控了相关查询的资源使用情况.
