资深开发者眼中的开源云原生数仓 ByConity

5 月 22 日，字节跳动宣布开源 ByConity 云原生数据仓库，项目地址：https://github.com/ByConity/ByConity。

ByConity 基于 ClickHouse 内核开发，采用计算存储分离的架构、主流的 OLAP 引擎和自研的表引擎，提供便捷的弹性扩缩容和极速的分析性能，覆盖实时分析和海量数据的离线分析，帮助企业更好地挖掘数据价值。

文章专题推荐：《开源云原生数仓ByConity技术与实践全解》

ByConity 于 2022 年计划开源，2023 年 1 月发布 beta 0.1.0 版本，一些关注字节 ClickHouse 使用情况的的开发者在 ByConity 开源初期便进行了一些测试，如华为终端云、唯品会、展心展力、中电云、传音控股等团队。部分团队使用 ByConity 进行了 TPC-DS 测试，也有一些深度试用的团队采用生产数据和具体场景进行了测试。

在此期间，社区收到了很多团队对于 ByConity 性能的积极反馈，当然也有团队遇到了一些部署中的难题和阻碍，并为社区提供了许多非常不错的改进建议。在和社区用户交流的过程中我们发现，不同的团队可能会遇到一些相似的问题，也会基于各自的业务需求设计对应的解决方案。

今年 5 月 ByConity 正式开源发布 GA 0.1.0 版本，为了帮助更多关注者在早期更好地使用 ByConity，社区邀请了几位参与 ByConity 测试和试用的团队成员与 ByConity 资深研发工程师进行了一次交流，希望将社区的经验分享给遇到同样问题和正在考虑解决方法的团队。

参与此次交流的几位嘉宾为：

• Kevin Fang，字节跳动 ByConity 资深研发工程师

• 赵金涛，华为大数据研发工程师

• 徐庆岳，中电云数据库内核技术专家

• 程伟，MetaApp 大数据研发工程师

本文根据此次交流中的部分要点整理而成。

Q1：各位在平时工作中会使用大数据的哪些技术和产品？是什么契机让你们接触到 ByConity？

程伟：我们主要是做了一个 OLAP 日志分析平台，开始选的是 ClickHouse，中间存在一些问题。后来通过字节跳动 ClickHouse 技术沙龙了解到字节对 ClickHouse 进行了优化，输出到 ByConity 中，做了开源 ，我们就开始尝试。

徐庆岳：我们是在做定制云计算，自己也有一些数据库产品。在私有云的部分项目中遇到了一些问题，比如说有些产品数据量特别大，每天会有 2 个 PB 的数据进来，查询一般需要是秒级，响应要求也比较高。在产品中，除了查询需求，也有汇入的需求，比如单节点汇入需求要达到差不多 400 兆每秒，查询也要比较快。

按照我们自己目前的方法，汇入需求能达到，但查询的时候，甲方会希望“能不能再快一点？” 。当时我们基于自己开发团队的一些产品感觉有点吃力，就对其他产品做了一些了解，比如 ClickHouse、腾讯云和字节的产品，当然也有一些创业型公司的项目。当时得知 ByConity 开源了，我们想有更多了解，就邀请 ByConity 负责人进行了交流。沟通后发现有些技术方面确实值得借鉴，于是我们做了一些针对性测试，看看某些功能点上是不是可以使用。

赵金涛：我们内部也在广泛使用 ClickHouse，在使用过程中发现它存在一些架构上的短板，比如说扩缩容的成本很高，扩缩容的时候需要刷元数据、停 merge、停 mutate、搬迁数据等代价非常大，集群的资源难以根据负载灵活调整，存在浪费。这个时候看到包括 ClickHouse 公司在内，大数据领域有非常多的产品都在构建云原生能力。

我们认为云原生是大数据的必然趋势。也是这个时候，我们从网上得知字节把在 ClickHouse 领域多年的技术积累贡献出来，开源给社区了。基于这个契机，我们投入到社区里面来，希望借鉴 ByConity 的一些思想，把 ClickHouse 打造成一个高性能的云原生数据库。

Q2：其实咱们碰到的很多的问题都是有共性的，例如在应用 ClickHouse 解决业务问题的时候，遇到扩缩容、性能方面的一些问题。那想问各位老师，大家觉得在解决这些问题的过程中有哪些难点，我们最需要攻克的关键技术点是什么？

程伟：一是在计算方面，希望能够计算得快一些；再就是能够支持更多的数据源；另外是能够支持更庞大的数据量。

徐庆岳：通过对 ByConity 技术的了解，它应该是按 Snowflake 论文来走的，包括元数据、数据的存算分离以及分布式的 MPP。在扩缩容这一块，S3 或者 HDFS 确实是一个很高的提高。但是在计算方面，未来怎么能够感知每个查询所需的计算资源多少？比如一个查询需要一台机器，下一个查询可能需要 100 台机器，从计算方面如何弹性？这可能也是云计算本身存在的最大的一个理由，就是能够感知什么时候把计算资源根据租户来分配，或者根据不同的查询来分配。如果是根据租户，比如根据每个租户的节点拓扑走不同的查询，ByConity 应该是这种路线实现的。但是如果能够更智能地感知当前的查询需要多少个计算资源，那就更好了。

赵金涛：我认为在大数据多维分析领域有两点是需要平衡的，第一是性能，第二是灵活性，极高的性能必然会损失灵活性。比如像 ClickHouse，它的各节点是完全对等的，元数据和数据都分片保存在节点上，这种 ShareNothing 的架构结合 ClickHouse 强大的 MPP 计算能力和极致的细节优化使得 ClickHouse 性能非常快。如果我们想在保证 ClickHouse 性能的基础上，具备更高的灵活性，让它灵活扩缩容，这种诉求和 ClickHouse 原生架构存在冲突。所以基于 ClickHouse 的原生架构去发展很难实现类似弹性伸缩这样的灵活性。

那我们就需要对 ClickHouse 架构改造升级，需要在比较高的灵活性下，仍然能保证性能。在这个过程中，就存在技术挑战，比如需要将数据和节点的绑定解耦，需要实现节点的彻底无状态，元数据要从本地磁盘抽到统一的元数据中心，数据要从本地磁盘推到 HDFS 或者是 S3 等的这些对象存储上。对于大数据分析引擎来讲，这种架构升级涉及的细节非常多，牵一发而动全身，技术挑战也很大。而这种改造必然会带来性能的降低。这时我们要采取其他的一些技术手段，比如缓存等，来提升性能。

Q3：在了解项目之后是如何上手的？是否遇到了一些障碍？体验如何？

程伟：我们最初使用 ByConity，是基于社区提供的 TPC-DS 测试项目来上手的。社区有一个比较详细的教程介绍如何通过 Docker 来部署 ByConity。把 ByConity 部署以后，跑了 TPC-DS 数据。在教程中会涉及到一些不清楚的点，加上我们想修改一些配置，由于对这些配置的了解情况并不是很多，所以就没有达到需要的效果。目前经过跟社区进行沟通，已经解决了这些问题。我们现在已经将 ByConity 部署在 K8s 上，并且基于 ByConity 提供了日志分析服务。

我们团队对 ByConity 社区一个最大印象就是沟通的成本非常低，非常有效果，我们遇到一个问题的时候，在社区提出，很快就有社区的相关同学，以及社区中的一些其他爱好者来协助我们解决这些问题。

徐庆岳：我们团队也在 Docker 上对 ByConity 进行了部署和测试，主要是看对 SQL 兼容性。但由于项目原因我们更关注 ByConity 写入和读取的速度，更多关注技术细节，比如说跟 HDFS 打交道的时候做的一些优化细节，我们会从源码级角度去看。和社区接触的过程中，团队的响应很快。在测试中我们也给社区找出了一个 bug。

在使用中感觉 ByConity 的性能提升很多，比如查询性能。如果说把单个 libHDFS 上拿出来做对比的话，跟 ClickHouse 社区比可以达到百分之四五十的性能提升。后续我们还会再测一测优化函数性能提升如何。

赵金涛：ByConity 开源以后，我们首先跑了雏形，然后分析了 ByConity 的源码和基于 ClickHouse 的一些改进点。在此过程中，发现 ByConity 是想构建一个比较完善的云原生的数据库，对 ClickHouse 的各种功能角色解耦非常彻底。

我们也和社区一起共建，比如 MergeTree 支持对象存储，Hive 外表支持对象存储，Hive 外表的功能完善等等。在过程此中我们多次和社区一起讨论，一起把能力打磨成熟。近期我们在使用的时候发现某些场景下相比 ClickHouse 性能大幅劣化，也正在和社区一起去分析瓶颈，提升性能。

Q4：后续团队希望将 ByConity 用于什么业务场景，有什么短期和长期的规划？

程伟：现阶段我们主要将 ByConity 用在日志分析平台的搭建。我们使用了 ByConity 的一个 Map 类型来将日志保存起来。一般来说大家都会采用固定的一些字段来做。但我们用了 Map，是因为我们日志中不确定的字段太多，所以我们根据名字和类型，通过创建 3 个 Map 来将我们的日志保存起来。这样日志查询的时候只需要拿到日志的 schema，就可以根据 schema 对应的类型来拿到对应的日志。现在我们每天会打入几百万条数日志数据，目前表现还是非常不错的。

另外我们有一个 OLAP 的数据分析平台，会有 A/B 测试，数据指标分析等功能，现阶段是基于 ClickHouse 来做的，未来我们可能会用 ByConity 来进行尝试，替代 ClickHouse 来把这一部分的业务给推起来。

徐庆岳：云计算公司，像大家都知道的比如火山引擎、华为云都有自研的产品，但不可能每个产品都自研，也会使用开源项目。 ByConity 跟社区版的 ClickHouse 架构差异比较大，也会在某些场景下符合我们的一些需求，在选型的时候就会考虑使用 ByConity。同时我们也会考虑 ByConity 的团队怎么样，以及社区的活跃度。 社区如果不能继续推进的话，对于后续一些功能的使用就会有影响。

未来我们也会和社区和团队做交流，看我们有哪些合适的使用场景，有哪些技术点是双方可以一起来提升的，以及哪些是可以回馈社区的。因为大家都是技术爱好者，希望能够相互成就。

赵金涛：我们的首版本还在构建中，会用于多维分析场景。首先会借鉴 ByConity 构建一个比较完善的云原生的数据库，实现资源弹性伸缩。我们还会借鉴 ByConity 的架构，构建湖仓一体的能力，不仅仅能够用于分析场景，还能用于数仓的场景，比如说可以分析 Hive 外表、Iceberg、Hudi 等等。

首先我们会聚焦第一个场景，会和社区一起解决一些迫在眉睫的问题。比如查询性能，ByConity 热读的性能比较理想，但冷读的查询性能还有比较大的提升空间。所以这段时间我们会把精力放在提升 ByConity 的冷读性能上，我们正在分析冷读的情景，想方法让 ByConity 能够持平或者至少接近 ClickHouse 的原生版本。

我们还发现某些异常场景下偶现数据丢失等现象，我们会着重提升可靠性，确保运行稳定可靠。

性能和可靠性提升后我们会借鉴 ByConity 资源隔离以及云原生的能力，来构建一个比较完善的云原生数据库，能够实现集群的弹性伸缩，集群能够根据查询量的大小动态的去分配资源等等，这些是我们未来的目标。

Q5：对 ByConity 技术路线的看法和诉求

程伟：我们对 ByConity 目前的功能，包括未来想要做的云原生数仓的愿景，都非常看好。之后是否能够支持 ClickHouse 相关的一些数据迁移工作，或者说能够给出一些迁移 ClickHouse 的帮助？这样的话能够让 ByConity 可以更好地去应用起来。

再就是 ByConity 未来是否可以变成一个更通用的分布式计算引擎，可以对更多的数据源进行一些计算。

徐庆岳：这个问题还是比较大的，我觉得每个产品都有自己的场景，对于使用方来说可能主要是看产品的成熟度，如果做得好，甚至可以培养用户的习惯。不同的数据库产品大多使用方法不同，可能使用的 SQL 语句都不同，如果对产品不熟悉，更换产品的对于大多数人来说上手都比较困难。如果 ByConity 成熟之后，在很多场景下，性能和灵活性都兼具了，用户多了，也就慢慢培养了用户的习惯。

数据库的技术路线，我想做数据库的应该都知道，比如存算分离、读写分离等，但是如何把一个产品做成功，可能跟产品未来的发展、社区的发展相关。比如多云部署是否支持等。

赵金涛： ByConity 的 GA 版本已发布，我认为接下来首先要把 ByConity 的能力继续完善，补齐功能，增强冷读性能，提升可靠性，构建一个比较完善的云原生数据库。第二点是把 ByConity 强大的性能拓宽到其他领域，比如说能够把它用到数仓领域，在一定程度上或者在某些场景下能够替代 Spark，能够加速模型层的计算。

Q6：在社区建设方面大家有什么看法

程伟：作为资深用户，对社区的最大的诉求，一是能够有更详细的文档帮助用户快速上手，以及一些比较详细的配置文档，能够让我们对 ByConity 的一些参数进行调整，达到一个更好的状态。再就是与社区沟通中快速反馈的方式。另外就是社区进度的同步，是否有定期的活动。

Kevin：文档化建设是社区非常重要的一部分，后面会有两种类型的文档，一种是给用户看的，比如用户手册，另外一个是面向开发者，会有更多的技术细节。大家在看文档中遇到一些问题也欢迎随时提出。

关于问题反馈，我们最推荐的还是 GitHub 的 issue，大家都能看到，也能帮助遇到相同问题的人。

定期活动我们肯定是有的，比如我们每月都会举办的 webinar，就会有一个专题去讲这些内容。前面讲了 ByConity 的一些技术架构的点，后面会分享一些计划要做的内容。

徐庆岳：之后希望看到 ByConity 技术点和功能迭代更加完善，也希望看到一些好的实现方法。社区共建这块，我觉得可以针对运维同学做一些事情，比如做开设一些课程培训，并进行认证，可以加深对于产品的熟悉程度，也培养了更多的用户。

Kevin：这个角度特别好，目前我们面向的更多是开发人员，随着被用了更多之后，第一手接触的大部分是运维人员。对于这批人我们如何提供更友好的支持，比如教程、上手以及解决问题的通道。后续我们也可以一起商量，通过社区一起来做。

赵金涛：后续可以定期组织一些 meetup，邀请不同企业的开发人员来分享各自的实践。另外还可以组织一些代码解读的活动，解读 ByConity 的架构和关键技术，比如它的查询优化器、导入、集群管理等等，尤其一些关键流程是如何实现的，这样也能让更多的开发者参与进来繁荣社区。

总结

Kevin：非常欢迎大家参与社区共建，一起形成技术的输出。比如每个团队侧重做的模块不一样，可能对某个模块会有非常深的理解，这些我们是不是可以用文章的形式发布出来，汇总起来，放到社区中，让其他的开发者都能够从中受益。

最后希望大家在平时业务当中总结出来的，包括在自己业务上得到验证的一些经验方法，一方面能够回馈给社区，让有共性的这些业务场景能够去使用；另外一方面也希望业界的各位专家们一起加入 ByConity，把 ByConity 打造得更好。

彩蛋

此次访谈中还有一些精彩的技术沟通未在本文章展开，如：

• 在 Map 使用过程中的一些建议和处理方式

• ByConity 冷读和热读的查询性能差异

• 数据湖在 ByConity 未来发展中的考虑与应用场景

• 数据迁移工具的相关讨论

• 如何使用云原生进行降本增效

• Keeper 高可用的探讨

本次访谈完整视频已上传 ByConity B 站：开源云原生数仓 ByConity，社区共建让技术走得更远_哔哩哔哩_bilibili

ByConity 是一个开放的社区，欢迎更多对云原生数据仓库感兴趣的小伙伴加入社区，一起交流，一起共建。

文章专题推荐：《开源云原生数仓ByConity技术与实践全解》