字节云原生数仓 ByConity 开源一周年!听听 Committer 们怎么说

原创
08/06 18:04
阅读数 1.4K

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 社区逐渐壮大。

--END--

关于 ByConity

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

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

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

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
返回顶部
顶部