ByConity 一周年！听听 Committer 们怎么说

采访嘉宾｜叶禧辉、程伟、殷鹏、赵金涛、陈云

2023 年 5 月 ByConity GA 0.1.0 版本正式发布，至今已满一年。今年 8 月，ByConity 1.0 版本也将正式发布。随着项目被更多地测试及使用，社区也有了更多的外部贡献者。ByConity 开源一周年活动上，社区正式官宣全面升级其组织架构，对社区 Contributor、Committer、Maintainer 的进阶方式及权利义务进行了详细的说明。ByConity 期待更多贡献者参与社区，丰富社区多样化，增加社区稳定性。

在一周年之际，我们采访了几位新晋社区 Committer，听听他们使用 ByConity 的经验与建议，以及对 ByConity 的未来畅想与期待。

叶禧辉：ByConity 助力业务落地效率更高，成本更优  

浩鲸科技前身为中兴软创，成立于 2003 年。目前，浩鲸科技业务范围从运营商市场延伸至数字政府、交通应急、公共安全、工业能源等领域，形成了在通信软件、运营服务、大数据、云计算、人工智能、互联网架构等领域的核心竞争力，通过数字技术赋能公共服务和产业升级。公司整体业务线较多，大数据团队专注于数据业务，利用各种大数据的组件和技术，提供技术中台的基础化设施，帮助客户实现比较复杂的业务场景。

叶禧辉长期从事电信运营商行业研发工作，最近十年基本上在大数据领域。使用较多的是 Hadoop 技术栈，对开源项目有深入研究。公司大部分产品都是基于开源产品的封装，因此做了很多开源项目 bug 修正及功能增强的工作。在接触 ByConity 之后，发现社区比较活跃，期间也交流较多。因此希望更多回馈社区，参与社区贡献。

浩鲸科技案例：打造运营商实时分析平台——浩鲸科技 ByConity 应用实践

ByConity 去年宣布开源的第一时间我们就进行了测试。我们在使用 ClickHouse 的过程中遇到了一些问题，调研后发现字节做了相关优化，对于已经使用 ClickHouse 的团队来说是非常有帮助的，因此一直期待有开源或者相关技术参考，去年终于等到了开源版本。

完全开源，从 ClickHouse 迁移 ByConity 成本低

测试之后发现 ByConity 确实解决了之前使用 ClickHouse 的一些痛点问题，效果也比较明显，比如节点扩展。大数据的经验让我们在 HDFS 存储上有一定的技术积累，同时我们也使用了 Hadoop 的存算分离，这些刚好也都是 ByConity 所具备的。因此，不论是技术路径还是业务场景，ByConity 都比较符合我们的需求。

当然我们也有其他的技术路线选择。国内一些其他的 MPP 产品，如 Doris 等，产品特性接近。但对我们来说更多的是技术路径的依赖，ByConity 可以直接迁移 ClickHouse 的经验。相对于花较长的时间重新开始，我们更倾向于选择熟悉且可以深入使用的产品。

另外，ByConity 目前是完全开源的状态，其他产品开源版本相对于付费版本有很多的问题，甚至不兼容，这会导致我们在为客户提供服务的时候非常被动。对于相对底层的开源项目，相较于标准的商业化产品，以我们多年的经验来看，真正使用的时候确实需要较多的技术积累。在资源有限的情况下，综合权衡，ByConity 更能满足我们的需求。

全场景测试 ByConity

现在我们已经在部分客户上线了 ByConity。国内部署了至少两个生产环境，近期我们还将在海外进行第一个版本的部署。通过边测试边部署的方式，我们在陆续测试不同的场景。同时我们也将尝试一些社区使用比较少的场景，通过测试逐渐做切换。

我们提供给客户的更多是一些封装过的产品。对于我们来说，开源更多是一个引擎，上层还围绕出了很多应用，或者整套的数据加工组件。比如一些展示表格、指标产品等我们都已经通过 ByConity 完成了适配，并在部分场景已在生产交付使用。当然，ByConity 和 ClickHouse 还是会有差异，目前确实还存在个别 ClickHouse 能跑通，ByConity 要做修改的场景。

关于使用场景，除了复杂查询和单表，我们还有很多存量的场景，包括清单查询、实时数据库（通过一些流处理的组件，做实时数据的汇入，再进行快速的迭代、分析）。除此之外，有些客户使用的数据库产品（如 MySQL）已经不能满足业务要求，我们会帮助进行切换。因此，很多场景都是已有业务的迁移。相对于全量迁移，我们倾向于边测试边迁移，避免现有版本存在的问题。

对 ByConity 的期待

ByConity 在兼容性方面已经做了很多，很多功能也属于第一梯队，但是我们对 ByConity 还是有更多的期待，包括：

• 兼容性优化：期待 ByConity 在 MySQL 兼容性方面有更好的解决方案，以降低使用成本；

• 增加核心功能：如数据异地容灾、系统权限管理、安全审计等，以提高系统的安全性；

• 丰富运维资料：提高文档的覆盖度，提供问题解决方案，同时建立分享途径，让社区已有的解决方案可以更好分享。

后续我们也会在系统稳定性、高可用方面对 ByConity 进行投入。同时我们也会帮 ByConity 做一些信创的认证。

希望 Roadmap 能够有效落地

Roadmap 基本上覆盖了用户使用的场景，我们所关注的语法更加完善、系统安全性更好以及备份恢复等能力在已发布版本还未实现，但在 Roadmap 中已有所体现，希望能按照 Roadmap 的情况提供对应的能力。同时，Roadmap 也是我们考虑是否研发某个需求的主要参考。

程伟：唯一一年高峰期，业务没有崩溃 

程伟是展心展力的大数据工程师，接触过较多的开源项目，在许多开源社区中活跃，作为 ByConity 早期使用者和贡献者，在 ByConity 社区中积极活跃，为后来的社区用户在部署、使用过程中提供了指导与帮助。程伟认为，不管是开源技术，还是开源项目，一方面，我们可以从中提高自己的技能，另一方面，我们也可以快速地基于开源项目进行业务的试错，能够快速地推进我们的业务。

展心展力案例：ByConity 替换 ClickHouse 构建 OLAP 数据平台，资源成本大幅降低

目前的使用情况：不断提升、继续优化

我们希望在目前主要的业务场景下不断想要提升 ByConity 的性能，以及使用更少的资源进行测试。另外我们计划在日志分析方面进行一些探索，用于替代我们公司常规的服务端日志搜索。目前 ClickHouse 和 ByConity 在双跑状态，后续也会维持维护部分 ClickHouse，但是集群非常少。一方面，我们希望不断对比两种产品各自的优缺点。另一方面我们也想看看 ClickHousee 的一些优点能否调整到 ByConity，或者在性能方面能否不断逼近。这部分也希望和社区一起完成。

我们在 2023 年 1 月 ByConity Beta 版本发布的时候就开始测试了，5 月 GA 之后进行了大规模测试，早期在 K8s 集群的部署上花了很多时间，在 GitHub 上提交了很多问题，后来我们将这部分的经验也总结成文章分享给了社区，让更多使用 K8s 部署的用户可以直接参考。

ByConity 的最大优势是它和 ClickHouse 生态的兼容。因为我们很多代码都是基于 ClickHouse 写的，使用 ByConity 可以无缝衔接。另外我们有拥抱云原生和降低运维压力的诉求，ByConity 云原生存算分离的特性可以帮助我们的缓解运维压力。

之前使用 ClickHouse 时，由于扩缩容的需求，我们使用了本地存储来做扩缩容，体验非常不好，在平常时期没有问题，但只要在业务高峰的时候，就会容易出现数据堆积。因为资源不够用，资源不能快速地进行扩容，所以就会导致查询的速度降低，甚至还会导致业务停滞的问题。

ByConity 部署上线至今已经快一年了，去年是唯一一次寒暑假我们业务没有崩溃的一年。之所以提到寒暑假，是因为在寒暑假是我们的高峰期，很难预测会有多少数据量。之前资源跑空的情况很严重，也会出现数据量突然变大需要增加埋点的情况，因此对快速扩缩容的需求很迫切。而 ByConity 经受住了寒暑假业务高峰的考验。在业务高峰的时候，我们可以通过扩展资源的方式，来稳定地提供服务。

对 ByConity 的期待

增加文档的丰富度是我们首先希望的。虽然现阶段的文档已经比刚开始丰富了很多，但我们也有收到工程师的反馈，表示目前还缺少一些配置文档，导致我们不知道应该如何更细粒度的调整集群。所以后续也希望能够把更细粒度的一些配置发出来，相信这些对社区用户也是非常有帮助的。

另外是优化器负向优化的问题，也就是部分查询用了优化器反而变慢的情况。之前我们遇到过这种情况，因为我们场景比较多，我们会在不同场景中进行选择，如果有开了优化器导致变慢的情况，我们就选择关闭优化器。近期我在帮助另外一个社区用户使用时，发现他们也遇到了类型的情况。我们会反馈给社区，希望后续能一起把问题给解决。

还有就是 ByConity 和 ClickHouse 的数据互通。对于 ByConity 和 ClickHouse 最新版本兼容我们的需求并不迫切，我们对 ClickHouse 最新的一些特性要求并不高。但是对于如何与 ClickHouse 的数据进行连接、查询，是我们觉得很有必要的。比如我们会有一些存量业务依然跑在 ClickHouse，大部分业务在 ByConity 跑，中间会面临数据交互的问题，这是我们的一个痛点。如果 ByConity 的数据可以与 ClickHouse 互通，通过一些方式实现两方数据的共同查询。相信对于很多正在使用 ClickHouse 和 ByConity 的用户应该是很有帮助的。

作为社区 committer

成为社区的 committer 之后，我们可以更好地把我们业务中的问题提出来，我们明白社区很难面面俱到，但我们可以提出我们的问题，多在社区发声，协助社区补足一些短板。

后续版本中有两个方面是我们比较关注的：一是对本地磁盘缓存的利用。目前本地缓冲的利用并不好，我们在线上使用时发现 S3 带宽较高，这很可能是因为之前查询时拉取的数据没有被充分利用。二是对 S3 存储的优化。我们认为 S3 上的下载控制还不够精细，还存在一些问题需要工程师来具体判断。我们已经在 GitHub 上提了对应的 issue。

成为社区的 committer 之后，我们主要会在这两部分进行更多的投入和贡献。另外在 K8s 部署方面我们也有一些经验可以支持。之前我们更多的时间花在如何让业务快速跑起来，后面我们也会花一些时间和人力在代码上，更好地使用到 ByConity 云数仓的能力。

对社区发展的期待

希望社区之后有更多的贡献者。目前社区的贡献者还不是很多，一是社区还没有一些可以快速参与贡献的问题或者贡献方式。ByConity 的上手其实并不容易，有些问题很难做。如何帮助大家上手或降低上手难度方面希望可以有一些规划。我相信有很多人愿意参与 ByConity 项目的贡献的。比如我们在 K8s 的部署方面分享了一些经验，但是代码方面的贡献很难做。二是如果不是 C++ 出身，社区代码整体上是非常长且难读的。代码查看和试错都会很费劲，也没有一些好的方法来进行测试。即使想投入一些时间可能也会被复杂的代码给劝退。所以也希望社区可以分享一些好的代码调试方法。

在入门方面，我们可以参考一些社区的入门教程，如 TiDB，为想参与贡献的用户提供一些指导，比如可以从哪开始看代码 / 文档，如果想给 ByConity 加一些函数，应该怎么来加，这就很容易上手贡献了。另外，我们也可以用一些组件的模式，提供对应的文档说明，降低参与贡献的难度。ByConity 确实是一个很大的项目，代码很难读，如果有阅读代码分享的话相信也会有一定的帮助。

还有就是社区的贡献指导。比如我们要贡献参与某部分，那就需要一些对代码相对熟悉人来指导我们如何进行调整一些代码，或者说让我们更好地去参与贡献。

殷鹏：提升兼容性无可厚非，但核心应该是优化器

烽火星空在搭建其 HSAP 数据库 FMDB 的过程中遇到了高并发场景下查询性能不理想，并且某些查询 SQL 有长尾现象等问题。殷鹏是烽火星空大数据开发工程师，在 ByConity 开源早期就对进行了测试，帮助公司产品有效提升了其特定业务场景下的性能和查询流畅性。烽火在使用 ByConity 的过程中积累了很多使用和优化经验，并不断向社区提出问题反馈和贡献。

烽火星空案例：ByConity 助力烽火星空架构优化，产品性能平均提升 3 倍

我们在搭建自有数据库产品 FMDB 的过程中遇到了一些痛点，在选型中发现 ByConity 的功能与公司业务需求整体较吻合，因此最终选择了 ByConity 作为 FMDB 的查询引擎。

之前我们主要采用 Hadoop+Spark 结合的方式，后来我们对 ByConity 进行了测试，发现其在单表查询场景也能达到较好的性能。另外，ByConity 作为一个数仓，既可以和 HDFS 对接，也能发挥数仓读写分离的优势。其实在选型时我们也对 ClickHouse 进行了考虑，其主要是使用本地磁盘，对 HDFS 支持不是很好，在 HDFS 上测试性能也不是特别好。另外 ClickHouse 和 FMDB 的整体架构差异性较大，集成比较困难。而烽火本身的产品架构也是在基于 K8s 的云平台上的，和 ByConity 的集成效果更好。

内部测试及客户认可

我们将 ByConity 封装到 FMDB 作为整体提供给业务层，也就是我们的内部客户。公司内部对 ByConity 认可度较高，因为 ByConity 的性能确实比之前 FMDB 的某些方面好，性能提升较快，也不像 Hadoop 比较繁重。ByConity 作为云数仓，应用性比较好，稳定性也不错，在现场部署之后也一直表现稳定。

我们从选型到测试一直都使用内部场景进行测试，并通过一些典型场景来验证。ByConity 的架构和我们之前所设想的架构也比较吻合。

对于烽火来说，我们的内部业务类型很多，我们会先对单表查询场景进行优化。多表复杂查询我们也进行了相关测试，但是因为场景比较复杂，涉及问题较多，我们会在内部进行测试再决定后续的应用，最终考虑怎样和 FMDB 进行适配。另外我们之前有些业务在 ClickHouse 上，如特征查询，后续我也希望把特征检索查询迁移到 ByConity。

ByConity 的核心在于优化器

一直以来，ByConity 的整体框架表现突出，与其他同类数据库相比，其性能优势显著。在实际使用过程中，我们发现若能进一步完善运维相关的支持体系，将有助于提高用户体验，例如提供关于运维插件兼容性的详细说明，比如是否可以兼容 ClickHouse 的运维插件，是否兼容一些可视化的插件，如果兼容插件应该如何使用调整，以及后端可视化可以如何去使用等等。

社区如果能积极接入其他开源项目的插件，也可以更加丰富社区的生态。由于实际场景较多，部署方式不同，需求也各异，之后可以考虑发动社区共同参与。目前看起来 ByConity 一个重心是数据湖，并致力于兼容其他数仓产品的部分功能。如今市场上数据库 & 数仓产品确实很多，每个产品都有自己的特点，而之所以会出现肯定是满足了特定场景。如果 ByConity  要兼容各类产品进来也无可厚非。然而，我们认为这应该是 ByConity 一项附加功能，核心依然应该在于优化器。尽管市场上同类产品很多，兼容性固然重要。但我们认为对于复杂查询场景的支持和优化，如果能有效提升其性能，是相对更关键的点。

ByConity 和 ARM 的兼容

目前都在提倡国产化，国产芯片基本都是基于 ARM 的，未来可能会有更多的服务器基于 ARM，因此对于 ARM 的需求可能会越来越高。前段时间我们也收到了类似的需求，后续可能要在 ARM 上部署我们的产品。这部分还是会比较耗费精力的，因为里面的编译调整很多。社区如果有人做这件事，相信会很有帮助。

进一步扩展和适配，完善产品性能

我们发现现阶段 ByConity 的索引还不是特别完善。比如它支持的一些主键索引可以使查询速度比较快，但是其他的一些索引能力上查询性能还不太好。所以我们会考虑用倒排索引进一步扩展。

我们有一些复杂查询的场景计划使用 ByConity，作为计算引擎和我们的产品 FMDB 也需要做适配，我后面主要会做这部分的工作。社区方面，之前我们在 ORC 部分和使用 Hive 方面有一些改进和提升，这部分陆续贡献给社区。另外我们使用的过程中把 FoundationDB 换成了 RocksDB，改动不是特别大，比较适合一些部署规模较小不想用 FoundationDB 的用户，这部分更换的方式也会考虑通过 PR 或者文档的方式贡献到社区。

赵金涛：打造一个高性能、高可靠、实时的云原生多维分析引擎

大数据行业深度参与者，对 Kylin、Doris 、ClickHouse 等分析引擎均有了解和投入。在社区接触到 ByConity 之后持续关注 ByConity 相关特性，并积极参与 ByConity 的能力构建。从使用到贡献，赵金涛和社区一直保持着良性的互动，并把一些有价值的优化贡献给社区。

赵金涛认为参与开源项目对个人有非常多的提升，不仅能够开阔视野，提升个人技术实力，也能够通过参与开源社区构建自己关注的特性，从而提升自己的产品能力。从社区获取到贡献社区，是一个良性循环。

ByConity 在 ClickHouse 的基础上构建了统一的元数据管理能力，将元数据存到 KV 元数据中心，数据存到 HDFS 或对象存储，实现了元数据和数据的解耦；将节点和元数据、节点和数据以及节点和计算状态彻底解耦，从 ClickHouse 存算一体节点完全对等的 SharedNothing 架构升级到存算完全分离的云原生架构。ByConity 在保持 ClickHouse 大宽表极致性能的基础上，解决了 ClickHouse 存算一体难以伸缩的痛点，这个架构升级是非常有价值的。此外，ByConity 还优化了查询引擎，提升多表复杂查询的性能，将 ClickHouse 大宽表的极致性能扩展到雪花模型，这也是很有价值的。

ByConity 适合数据波动大的业务，能降低成本。例如，某些业务在双 11、618 以及节假日等特殊时期数据量大，但平时的数据量较小；若使用 ClickHouse 扩容需在新节点重建元数据，缩容需搬迁数据，扩缩容是比较困难的，若按业务高峰建集群存在资源浪费成本过高；可使用 ByConity 利用其快速扩缩容的能力降低成本。其次 ByConity 适合存在明显波峰波谷的业务，如离线分析业务夜间导入白天查询，夜间导入负载较低，白天查询负载高性能下降显著；利用 ByConity 灵活伸缩的能力夜间缩容降低成本，白天扩容提升性能，达到成本和性能的平衡。

优化元数据，降低维护成本提升可靠性

我最关注的是 ByConity 元数据的性能和可靠性。ByConity 的元数据存储组件是 FoundationDB，这是一个支持事务的分布式 KV，比较小众，文档少维护成本高。元数据中心一旦故障整个集群不可用，是 ByConity 集群的核心组件和中心瓶颈，要采取措施确保元数据高可靠高可用。其次，ByConity 部分产品化功能尚不完善，例如其组件数量众多，这无疑会增加维护的复杂性。再者，ByConity 尚处于发展初期，相较于 ClickHouse 等成熟引擎而言，可靠性可维护性等仍存在一定差距。

我认为理想的分析型数仓，首先应该是一个高性能的分析引擎，能支持千亿万亿数据的秒级分析。第二，它应该既能够支持实时分析，也能支持离线分析、日志检索分析等，以满足不同场景的需求。第三，对于数仓，它应该具有高稳定性和可靠性，确保系统可长期稳定运行。第四，还应关注运维成本，希望组件比较简单，降低维护成本。

ByConity 有较多的组件，还是存在优化空间的。运行层的 Worker 和管理层的 Server 肯定是需要的，其他组件我们是否可进行调整？例如，管理层有四个组件 Server、Daemon Manager、Resource Manager 以及 TSO，Daemon Manager 和 Resource Manager 两个组件较为相似，是否能够合并以降低维护成本？可进一步探讨。

成为社区 Committer 之后我会继续投入到功能改进中。我认为 ByConity 目前最大的痛点是元数据，所以我会首先关注元数据，确保大数据量高负载下元数据的可靠性，即使元数据中心故障乃至元数据丢失也要确保可修复；其次尝试在元数据模块引入其他存储组件，以降低 ByConity 元数据存储组件的维护难度；再次改进元数据读取方式，多线程并行读取等提升性能。

优先聚焦分析场景，性能可靠性优于其他分析引擎

我认为社区的首要任务仍然是把 ByConity 分析场景的各项特性做好，优先聚焦大数据分析领域，在性能、可靠性和稳定性等方面做到优于 ClickHouse。如，大宽表性能要打平 ClickHouse，星型模型性能要优于 ClickHouse；对于 ClickHouse 的分片场景，ByConity 可以构建等效乃至超越分片的处理能力；可靠性方面类似 ClickHouse 只要数据在即使 ZooKeeper 元数据完全丢失也能修复，ByConity 要做到即使元数据中心故障完全不可用也有手段能修复；稳定性方面要做到极端负载下服务降级但可稳定运行。我们应当持续聚焦分析场景，尤其是实时分析、离线分析以及日志检索等场景。在实践案例中看到，某些业务 ByConity 和 ClickHouse 是共用的，这表明，ByConity 在某些场景下还未完全替代 ClickHouse，可通过社区力量来继续优化。在全方位覆盖分析场景后，我们可以再进一步扩展，把数仓或其他领域纳入产品范畴。

期待 LTS 版本与不中断升级

关于社区治理方面，我期待 ByConity 能类似 ClickHouse 既有快速迭代的特性版本，也有相对稳定长期维护的 LTS 版本。其次，ByConity 新版本保持与旧版本接口兼容，不同的 LTS 版本之间能无缝升级无需过多配置，升级过程业务不中断。

陈云：期待更多 committer 加入，加深社区共建

大数据领域从业者，由于工作性质，在 ByConity 之前鲜少参与开源社区。同样是在使用 ClickHouse 的过程中遇到了一些问题，因此做了一些调研并最终选择了 ByConity。在使用的过程中在社区中不断交流沟通，逐渐深度参与并陆续提交了一些 PR。

存算分离并完全兼容 ClickHouse

我之前在用 ClickHouse，使用过程中出现了一些问题。首先，运维困难，尤其在加机器或者扩容操作时都需要人工参与；其次，其节点可扩容性欠佳，单机上有些热点问题不能很好解决；第三，资源隔离方面表现有所不足，公司所提供的 SaaS 产品涉及众多用户的数据，而 ClickHouse 在不同用户数据隔离方面能力很局限。

为此，我们对市场上类似功能的系统进行了调研。尽管 ClickHouse 也推出了存算分离的版本，但是属于商业版功能而无法体验。之所以开始试用 ByConity，是因为我之前在文章中了解到它有存算分离的特性，并支持多资源组隔离，这和我们的需求比较契合，因此开始试用。

从 2023 年 10 月开始测试，主要想了解 ByConity 在日志数据分析的场景效果如何。12 月开始准备数据双写，期间遇到了一些问题，在社区的帮助下进行了定位修复。今年 3 月基本有一个可以上线的版本，目前还在灰度导量的过程。在测试过程中发现，或许是刚开源的原因，ByConity 有些场景可能没有还没有覆盖，前期会有一些零散的 bug，后续较快的恢复了。

我们还尝试过一些其他的开源产品，最终选择 ByConity 的原因在于，它与 ClickHouse 的生态系统具有高度兼容性，这将有助于我们的业务顺利迁移至新系统。另外了解到字节内部也在广泛使用，这也是我们选择的原因之一。综合考虑，我们逐步在线上环境中部署并使用了 ByConity。

对社区的建议和新版本的期待

对于那些初次接触 ByConity 平台的使用者，我认为前期的脚本部署过程相对比较复杂。鉴于当前环境下，许多用户可能都搭建了自己的流水线，而非通过脚本部署，在开始上手时可能会面临一定的挑战与困难。期望社区在进一步完善文档内容的同时，为用户提供更为丰富的细节解读。大多数用户通常会通过阅读代码文件来掌握整体架构，并借助文档资料来理解技术细节。

目前我正在使用最新发布的 0.4.0 版本。关于未来的新版本，我个人比较期待以下几个方面的改进与升级：首先，支持行列过滤功能将极大地方便我们对数据的筛选和处理；其次，倒排索引的性能优化将有助于提升数据检索效率；最后，向量检索的引入将有望更好地满足用户需求。

支持算子和 builder 性能优化

作为社区 committer，我希望在性能优化方面为社区提供更多支持，尤其是算子和 builder 的性能优化。

ByConity 在多表优化方面表现较好，然而我在这方面还没有太深入的体验。单表是我主要了解的场景，重点看 ByConity 的存算分离和扩容能力。有一点感受是，和其他社区相比，ByConity 大部分的功能都是自己在做内部迭代，和社区的连接不够紧密。其实有些特性可以和其他公司共建，从而加深彼此间的合作。

关于社区未来的发展规划，我期待能够定期召开会议，这样可以及时分享项目进展及后续方向，同时根据具体工作内容指定相应的负责人，以项目管理方式推进各项工作。

我期望能有更多的外部 committer 加入 ByConity，共同参与社区建设。当然在拥有更多 committer 后，也需要积极调动大家的积极性，让大家发挥更大作用。

写在最后  

通过和几位 committer 的沟通，我们发现他们对于想参与社区的同学给出了几乎类似的建议。兴趣驱动和业务驱动是两个主要方面，但是只有先用起来，才会发现问题，并通过在社区上寻求帮助或反馈问题逐渐加入社区。同时也非常欢迎大家把使用或者迁移经验分享到社区，并通过丰富社区生态，让 ByConity 社区逐渐壮大。

关于 ByConity 

ByConity 是字节跳动开源的云原生数据仓库，在满足数仓用户对资源弹性扩缩容，读写分离，资源隔离，数据强一致性等多种需求的同时，提供优异的查询，写入性能。

GitHub ｜https://github.com/ByConity/ByConity

添加小助手加入 ByConity 社区交流群