ByConity的架构与设计：从ClickHouse到云原生
背景和设计理念
ByConity 是一款基于云原生架构的开源数仓产品，其设计理念围绕开源和云原生展开。开源模式有助于软件更早接触用户、了解真实需求，吸引外部开发者参与，提高迭代效率，并促进商业化拓展海外市场。云原生架构则强调重用云基础设施，实现高可靠性和降低成本，同时从设计之初就满足云的需求。存算分离架构避免了传统分布式系统的性能瓶颈和复杂性。
ByConity 发展历程
- 2018年：大规模使用 ClickHouse
- 2020年1月：推出 ByteHouse 云数仓版
- 2020年5月：ByConity 启动开源
- 2022年5月：ByConity 开源 0.1.0-GA 版本发布
- 2023年5月：发布 0.2.0 版本，支持数据湖、ELT、RBAC、提升冷读优化
- 2023年9月：开源一周年
- 2024年5月：发布 0.3.0 版本，支持倒排索引、ELT 能力增强、共享存储的选主方式、冷热性能提升
架构设计
ByConity 采用存算分离架构，主要分为服务层、计算组和存储层：
- 服务层（Cloud Service）：包含 MetaDate（FoundationDB/ByteKV）、Server、Resource Manager、TSO、Daemon Manager 等组件，负责元数据管理、查询解析、计划生成、调度和下发等。
- 计算组（Virtual Warehouse，VW）：包含 Worker，每个表可以设置默认的 Read VW（查询）和 Write VW（导入和 Merge），支持多租户隔离和读写分离，具备水平和垂直动态扩缩容能力。
- 存储层（Cloud Storage）：支持 HDFS、S3 等存储系统。
ByConity 的特性
- 资源隔离
- 高性能
- 数据强一致性
- 读写分离
- 弹性扩缩容
存算分离的设计思考
- 统一的元信息管理：提供高可用和高性能的元数据读写服务，支持完备的事务语义，后端存储系统可插拔。
- 数据存储结构：合并小文件，保持按列存储特性。
- 数据变更：采用 delta part + base part 和 part chain（merge-on-write）机制。
- 数据合并：异步 merge，Old parts 通过 GC 清理。
- 数据缓存：一致性 hash 分配 parts，热数据 worker 节点自动缓存，改进 bucket-lru 算法。
- 唯一键（UNIQUE KEY）：支持唯一键与排序键不同，支持基于版本字段的比较，支持行删除，支持表级别和分区级别。
唯一键 + Upsert 场景
- 数据源（如 Kafka）包含重复数据，如何保障数仓表的数据质量？
- 业务数据流包含行更新，如何高效实时同步和分析？
- 如何提高 RDBMS->数仓的同步时效性，并支持高效分析？
查询优化器
ByConity 实现了 RBO 和 CBO：
- RBO：基于规则的优化能力，使用预定义的启发式规则选择查询执行计划，包括基于 visitor 的全局改写和基于 pattern-match 的局部改写。
- CBO：基于代价的优化能力，通过收集和分析数据库中的统计信息评估不同执行计划的成本，选择成本最低的计划。基于 Cascades 搜索框架，遍历等价计划，选出最优解。
查询调度
- Cache-aware 调度：针对 source 读取数据，最大化 cache 命中率，提升读写性能。
- Resource-aware 调度和流量控制：针对计算节点，最大化资源利用率，合理使用资源。
计算组
- 多租户隔离
- 读写分离
- 水平和垂直动态扩缩容
- 资源共享
与 ClickHouse 的差异
ByConity 在架构设计、功能特性等方面与 ClickHouse 存在差异，主要体现在云原生支持、存算分离、弹性伸缩等方面。
实践案例
- 用户分析系统：320TB 数据，2.3 万亿行，2 万个维度。
- MetaApp 数据分析平台：240core 1760G 资源消耗。
带来的收益
- 知识体系：避免资源抢占，节约资源成本，降低运维成本。
- 开源社区发展：Star 1600+，PR 1700+，Issue 500+，Fork 300+。
2024年整体规划
- 性能提升：优化动态构建 filter 能力、全局字典、Zero-copy、非等值 join 算子优化等。
- 数据湖分析数仓能力：支持 Hive 表查询、写入，支持 Hudi 表查询、写入，支持 Iceberg 表查询等。
- 数据安全和备份恢复：透明加密、表级快照、全量备份恢复等。
- 易用性：一键部署、Local mode、Dbeaver、Kubeblocks、SugarBI、Quicksight 等。
