ByConity（王蕴博）：ByConity的架构与设计：从ClickHouse到云原生.pptxVIP

ByConity的架构与设计：从ClickHouse到云原生

演讲人：王蕴博

王蕴博

字节跳动首席开源布道师、开源基础设施负责人。中国计算机学会(CCF)开源发展委员会副秘书长，CCFGitLink社区负责人，CCFGLCC发起人兼组委会主席。前腾讯开源联盟委员（TOSA），前滴滴开源办公室负责人。

长期专注于大数据、DevOps、AI等方向；对开源治理、项目孵化、开源合规等具有丰富的经验。

背景和设计理念

存算分离架构设计 用户案例分享 社区和未来规划

2023.5

2022.5

大规模使用ClickHouse

2018

CNCH

ByteHouse云数仓版

ByConity历史

2024.5

2023.12

2023.9

2020.1

2024.4

云原生

●重用云基础设施，高可靠性和降低成本；

●整个系统和架构设计从开始就基于云的需求；

●存算分离避免了传统分布式系统的一些性能瓶颈和复杂性

ByConity设计之初

Byte—一ByConityCommunity

Convert

ByConity是通过开源，融合一群希望打破常规技术的开发者，改变数据的使用方式

开源从“命名”开始

●服务层（CloudService）

●MetaDate：FoundationDB/ByteKV

●Server：表元数据缓存、查询SQL解析、计划生成、调度和下发

●ResourceManager：服务发现、负载心跳检测

●TSO：全局唯⼀单调递增的时间戳

●DaemonManager：调度和管理任务

●计算组（VirtualWarehouse，VW）

●Worker：执行片段的执⾏，后台任务的执⾏、LocalDiskCache

●每个表可以设置默认的ReadVW（查询）和WriteVW（导入和Merge)

●存储层（CloudStorage)

●支持HDFS、S3

基于云原生架构

ByConity的特性

存算分离的设计思考

●需要统一的元信息管理系统

●分布式文件系统大多数存在元信息管理压力问题（nn）

●分布式统一存储系统大多不支持rewrite，一些对象存储系统甚至不支持append

●分布式对象存储系统大多move代价都比较高

●iolatency通常情况对比本地文件系统下都存在增加的情况

●完备事务语义的支持

●后端存储系统可插拔，方便扩展

●高效的Part缓存管理

●一致性hash

统一的元数据管理

●提供高可用和高性能的元数据读写服务

●合并小文件，每个part所有数据存储在一个文件中

数据存储结构

●保持按列存储特性

●文件生成后不再变动

●deltapart+basepart●partchain（merge-on-write）

●读放大

数据变更

●异步merge

●Oldparts通过GC清理

数据合并

●一致性hash分配parts

●热数据worker节点自动缓存

●改进bucket-lru算法

●避免数据reshuffling

数据缓存

唯一键+Upsert

●面向读取操作进行优化

●支持唯一键与排序键不同

●支持基于版本字段的比较

●支持行删除

●支持表级别和分区级别

●数据源(如Kafka)包含重复数据，如何保障数仓表的数据质量?

●业务数据流包含行更新，如何高效实时同步和分析?

●如何提高RDBMS-数仓的同步时效性，并支持高效分析?

唯一键（UNIQUEKEY）

实际场景

●优化器：本质是对查询计划的等价转换，从中找到最优解或者较优解。ByConity实现

了RBO和CBO

●RBO：基于规则的优化能力。使用一系列预定义的启发式规则来选择查询执行计划。

●基于visitor的全局改写，例如filter下推、列的裁剪、SQL指纹等

●基于pattern-match的局部改写，例如多个filter的merge、多个projection的merge●CBO：基于代价的优化能力。通过收集和分析数据库中的统计信息来评估不同执行计

划的成本，并选择成本最低的计划作为最佳计划。

●基于Cascades搜索框架，遍历等价计划，评估每种等价计划的代价，选出最优解●JoinReorder超过10表启发式搜索

●分布式执行