跳到主要内容
版本:0.2.0

主要原理概念

简介

ByConity 的查询执行流程如下图所示,首先通过元数据服务获取查询所需要的元数据信息,然后根据用户 sql 通过优化器生成高效的查询计划,并调度到相应的计算组上去读取数据并执行,最终进行结果集的汇总并发送回客户端。为了用户更好的了解 ByConity 查询的工作原理,此章会介绍 ByConity 的主要原理。

元数据管理(Catalog Service)

元数据管理(Catalog Service)的功能主要是对读写请求的元数据进行读写操作。元数据服务是一个非常关键的服务,其决定了查询的可用性和正确性。在 ByConity 里,我们不仅提供了高可用,可扩展的元数据管理服务,还在其之上实现了完备的事务语义保证(ACID)。除此之外,ByConity 还借助缓存,对查询涉及到的原数据提供低延迟读取,保证查询性能高效稳定。

查询优化器(Query Optimizer)

优化器(Query Optimizer) 是数据库系统的核心之一,优秀的优化器能极大提高查询性能,特别是在复杂查询场景下优化器能带来数倍至数百倍的性能提升。

ByConity 自研优化器基于四个大的优化方向提供极致优化能力:

  • RBO:基于规则的优化能力。支持:列裁剪、分区裁剪、表达式简化、子查询解关联、谓词下推、冗余算子消除、Outer-JOIN 转 INNER-JOIN、算子下推存储、分布式算子拆分等常见的启发式优化能力。
  • CBO:基于代价的优化能力。支持:Join Reorder、Outer-Join Reorder、Join/Agg Reorder、CTE、物化视图、Dynamic Filter 下推、Magic Set 等基于代价的优化能力。并且面向分布式计划融合了 Property Enforcement。
  • DBO:基于数据依赖的优化能力。支持:唯一键、functional dependency、Order dependency、Inclusion dependency 等基于数据依赖关系的优化能力。
  • HBO:基于查询反馈的优化能力。支持:基数估计动态调整、并行度动态调整、执行计划动态调整等基于历史执行反馈的优化能力。

计算组(Virtual Warehouse)

计算组(Virtual Warehouse: 简称 VW) 是计算资源的虚拟组织,可以将计算资源按需划分为多个虚拟集群,在不同租户之间提供物理资源隔离。每个虚拟集群里包含 0 到多台计算节点,按照实际资源需求进行动态扩缩容。

计算资源扩缩容的方式有两种:

  • 一种是纵向扩容,即调整计算组的 CPU 核数和内存大小;
  • 另一种是横向扩容,增减计算组的数量,提升系统并发能力;

在存储计算分离的架构下,计算资源与存储资源是解耦的且无状态的,扩缩容过程不需要迁移和平衡数据,因而可以实现快速弹性扩缩容。

计算节点主要承担的是计算任务,这些任务可以是数据写入、用户查询,也可以是一些后台任务。在 ByConity 存储分离架构下,用户查询可以实现读写分离,降低读写作业之间的互相干扰。用户查询和后台任务,可以共享相同的计算节点以提高利用率,也可以使用独立的计算节点以保证严格的资源隔离。用户可以根据计算任务的特性、优先级和业务类别不同,构建多个计算组,并设置不同的资源弹性策略,提高计算效率降低成本。

虚拟文件系统(Virtual File System-VFS)

ByConity 采用 HDFS 或 S3 等云存储服务作为数据存储层,用来存储实际数据、索引等内容。数据表的数据文件存储在远端的统一分布式存储系统中,与计算节点分离开来。底层存储系统可能会对应不同类型的分布式系统。例如 HDFS,Amazon S3, Google cloud storage,Azure blob storage,阿里云对象存储等等。

不同的分布式存储系统,有很多不同的功能和不一样的性能,会影响到功能的设计和实现。例如 hdfs 不支持文件的 update, S3 object move 操作时重操作需要复制数据等。ByConity 通过存储的服务化,对计算层提供统一的抽象文件系统接口,存储层采用 S3 还是 HDFS 对计算层透明;计算层可以支持 ByConity 自身的计算引擎之外,将来还可以便捷地对接其他计算引擎,例如 Presto、Spark 等。

列式存储(Columnar Storage)

与主流分析数据类似,ByConity 采用列式存储格式,减少不必要的数据 IO 提高查询性能,并对数据进行高效压缩,降低存储成本。除此之外,对于连续存储的列式数据,ByConity 通过向量化执行技术,进一步提升查询性能。

主要流程

查询执行

  1. 用户提交 Select Query 到服务节点;
  2. 从元数据服务获取需要的元数据信息,对 Query 进行 Parsing,Planning,Optimising,生成执行计划;
  3. 服务节点根据可用的计算资源对执行计划进行调度,发送任务到计算节点;
  4. 计算节点接收到 Query 子查询;
  5. Query 从虚拟文件系统(VFS) 获取数据,并根据 Query 的执行计划在计算节点上执行,并发回计算结果给服务节点汇总;

数据写入

  1. 用户提交 Write Query 到服务节点;
  2. 服务节点对写入请求根据调度策略选择合适的写入节点执行;
  3. 写入节点执行写入,将数据写到本地盘并 dump 到云存储端;
  4. 提交 part 元数据到元数据服务(Catalog Service),提交事务,写入完成;

计算组扩缩容

资源管理器(Resource Manager)负责对计算资源进行统一的管理和调度,能够收集各个计算组的性能数据,资源使用量,为读写任务和后台任务动态分配资源并进行扩缩容,提高资源使用率。ByConity 的组件都已经容器化,通过调整 kubernets 的 replica 数量可以非常方便的对指定的计算组进行扩缩容。除此之外,还可以结合计算组资源使用量,通过设置 kubernets 的扩缩容阈值实现动态扩缩容。