字节云原生数仓 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 和 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 的过程中积累了很多使用和优化经验，并不断向社区提出问题反馈和贡献。
我们在搭建自有数据库产品 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 社区逐渐壮大。
--END--
关于 ByConity
ByConity 是字节跳动开源的云原生数据仓库，在满足数仓用户对资源弹性扩缩容，读写分离，资源隔离，数据强一致性等多种需求的同时，提供优异的查询，写入性能。
GitHub ｜https://github.com/ByConity/ByConity
添加小助手加入 ByConity 社区交流群
