字节跳动开源ByConity：基于ClickHouse的存算分离架构云原生数仓( 三 ) _字节跳动

其次是自研的面向 ClickHouse runtime 执行层、与之完全匹配的查询优化器。基于四个大方向（基于规则、基于 cost、基于数据依赖、基于反馈）提供极致优化能力，能极大提高查询性能，特别是在复杂查询场景下能带来数倍至数百倍的性能提升。虽然业界成熟的数仓引擎都会配备查询优化器，但据了解，从 ClickHouse 技术方案衍生出来的查询优化器，目前在业界应该没有第二个方案。

然后是对元数据存储和管理的优化。使用 ClickHouse 比较多的团队可能都会遇到一个问题，随着集群管理的元数据越来越多，ZooKeeper/Keeper 会面临很大的 coordinate 压力，可能出现元数据不一致的问题，轻则查询报错，重则整个集群宕机。这类问题在 ByConity 从系统层面得到了解决。ByConity 基于高性能的分布式 key-value store（FoundationDB）做元数据管理，并在 catalog api 上层实现了完备事务语义（ACID）支持，提供了高效可靠的元数据服务，能够将元数据吞吐拉升到百万级别。

除了架构上的差异化亮点，ByConity 和 ClickHouse 在使用过程中又有哪些异同？社区也有不少开发者对此有疑问。前不久 ByConity 社区组织了一场直播，从使用角度对两者差异做了介绍，主要从以下几个关键维度展开：

在资源隔离与扩缩容设计上的架构与组件差异
在库表创建、数据导入与查询上的差异
在事务支持与特殊表引擎上的差异

文章插图
ByConity 与 ClickHouse 的差异总结（来源：ByConity 社区）
感兴趣的读者可以查看直播回放视频( https://www.bilibili.com/video/BV1Ro4y1b7mu/?buvid)进一步了解。
后续规划
随着 ByConity 正式官宣开源，后续项目会遵循开源社区的模式来运营和治理，社区治理原则相关的文档目前已经同步到项目 GitHub 上，并面向整个社区开放讨论。
对于 ByConity 接下来的技术发展路线，团队基于自身现状初步做了一些规划，今年下半年侧重点会放在权限控制、数据安全和组件高可用等方向。还有一些社区关注度比较高的问题，比如对数据湖分析的支持，包括对接 Hudi、Iceberg 等功能，也在 Roadmap 规划之中。

文章插图
ByConity 2023 年技术路线 Roadmap
陈星表示，未来 ByConity 希望从一个只面向即时型分析的轻量级数仓，向一个能够处理更多复杂工作负载、更成熟的数仓去演化。当然，这其中挑战非常大，也不是短时间内能够做好的，需要与社区共同努力。
对于一个新的开源项目，社区往往会非常关注项目的长期投入和发展问题。翟鹿渊表示，字节去年成立开源委员会，就是字节更加重视开源的一个信号，而开源委员会有一条原则是做精品项目，从公司层面会聚焦少数重点项目做长期的战略投入，ByConity 是其中之一。另外，如前所述，ByConity 和 ByteHouse 研发团队基本是完全重合的，只是每个人的工作有一部分在做商业版、一部分在解决开源社区相关反馈，开源和商业版融合度非常高。未来 ByConity 会朝着一个更加开放的引擎开发模式去发展，今年年中会将内外部代码层面完全拉齐，后续对 ByteHouse 的改动会基于 ByConity 源代码用开源的方式来开发，即先在上游开发，开发完成后在再往回拉。这个开发模式调整可以说是大动干戈，但也从侧面印证了字节长期投入 ByConity 的决心。
未来除了 ByConity 社区自身的代码贡献，字节内部业务场景、ByteHouse 的客户场景带来的迭代和改进也会反哺给 ByConity，帮助 ByConity 持续迭代优化。比如，字节内部使用规模还在逐步增大，可能会打破以往设计方案的一些假设条件，导致调度策略或者资源分配策略要适应内部业务做优化和调整，这些优化都会输出到 ByConity 。商业化产品同理，商业版用户在使用中遇到的问题或反馈的修改，也会同步到 ByConity 。
写在最后
对于一个开源项目，引入更多参与者、让社区往多元化方向发展往往是重要目标之一，ByConity 也不例外。从发布 Beta 版开始，ByConity 团队就公布了社区路线图，并积极与社区成员共同探讨和解决大家在试用过程中遇到的问题，团队有耐心、也有信心，更是非常期待未来能够与更多开发者和合作伙伴一起共建共享，激发更多创造力。
对于社区多元化可能会给项目创始团队带来的新问题，比如项目无法按照最初规划的技术发展路线演进等，陈星和翟鹿渊都表示，希望这个幸福的烦恼早些到来。