ByConity的架构与设计：从ClickHouse到云原生
目录
CONTENTS
背景和设计理念
存算分离架构设计
用户案例分享社区和未来规划
ByConity历史
大规模使用
ClickHouse
2018
CNCH
ByteHouse云数仓版
2020.1
ByConity启动开源
2022.5
2023.5
2023.9
开源一周年
5月19日北京
2024.5
发布0.3.0版本
倒排索引、ELT能力增强、共享存储的选主方式、冷热性能提升
发布0.2.0版
支持数据湖、ELT、
RBAC、提升冷读优化
2023.12
ByConity开源0.1.0-GA
新版本发布
2024.4
ByConity设计之初
开源
开源让软件更早接触用户，了解用户真实需求；
吸引外部开发者参与，汇聚领域人才参与，传播影响力；
更加高效的迭代，软件更佳安全和健康
开源OpenCore模式促进商业化，拓展海外市场
云原生
重用云基础设施，高可靠性和降低成本；
整个系统和架构设计从开始就基于云的需求；
存算分离避免了传统分布式系统的一些性能瓶颈和复杂性
开源从“命名”开始
ByConity
Byte
Community
Convert
ByConity是通过开源，融合一群希望打破常规技术的开发者，改变数据的使用方式
基于云原生架构
服务层（CloudService）
MetaDate：FoundationDB/ByteKV
Server：表元数据缓存、查询SQL解析、计划生成、调度和下发
ResourceManager：服务发现、负载心跳检测
TSO：全局唯?单调递增的时间戳
DaemonManager：调度和管理任务
计算组（VirtualWarehouse，VW）
Worker：执行片段的执?，后台任务的执?、
LocalDiskCache
每个表可以设置默认的ReadVW（查询）和
WriteVW（导入和Merge)
存储层（CloudStorage)
支持HDFS、S3
存算分离的设计思考
需要统一的元信息管理系统
分布式文件系统大多数存在元信息管理压力问题（nn）
分布式统一存储系统大多不支持rewrite，一些对象存储系统甚至不支持append
分布式对象存储系统大多move代价都比较高
iolatency通常情况对比本地文件系统下都存在增加的情况
统一的元数据管理
提供高可用和高性能的元数据读写服务
完备事务语义的支持
后端存储系统可插拔，方便扩展
高效的Part缓存管理
一致性hash
数据存储结构
合并小文件，每个part所有数据存储在一个文件中
保持按列存储特性
数据变更
文件生成后不再变动
deltapart+basepart
partchain（merge-on-write）
读放大
数据合并
异步merge
Oldparts通过GC清理
数据缓存
一致性hash分配parts
热数据worker节点自动缓存
改进bucket-lru算法
避免数据reshuffling
唯一键（UNIQUE KEY）
唯一键+Upsert
面向读取操作进行优化
支持唯一键与排序键不同
支持基于版本字段的比较
支持行删除
支持表级别和分区级别
实际场景
数据源(如Kafka)包含重复数据，如何保障数仓表的数据质量?
业务数据流包含行更新，如何高效实时同步和分析?
如何提高RDBMS-数仓的同步时效性，并支持高效分析?
查询优化器
优化器：本质是对查询计划的等价转换，从中找到最优解或者较优解。ByConity实现了RBO和CBO
RBO：基于规则的优化能力。使用一系列预定义的启发式规则来选择查询执行计划。
基于visitor的全局改写，例如filter下推、列的裁剪、SQL指纹等
基于pattern-match的局部改写，例如多个filter的merge、多个projection的merge
CBO：基于代价的优化能力。通过收集和分析数据库中的统计信息来评估不同执行计划的成本，并选择成本最低的计划作为最佳计划。
基于Cascades搜索框架，遍历等价计划，评估每种等价计划的代价，选出最优解
JoinReorder超过10表启发式搜索
分布式执行计划，属性传递，基于代价生成最优的分布式计划
查询调度
负责对生成的可执行计划plansegmenttree进行调度
Cache-aware调度–针对source，读取数据
最大化cache命中率，提升读写性能
拓扑发生变化时，最小化cache失效的影响
Resource-aware调度和流量控制–针对计算节点，纯计算
最大化资源利用率
合理