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

【资料图】

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

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 是一个开放的社区，欢迎更多对云原生数据仓库感兴趣的小伙伴加入社区，一起交流，一起共建。