为时序数据库 IoTDB 底层架构“保驾护航”，来听听新晋 Committer 的贡献心路！

把 IoTDB 底座做得更扎实

2025 年 4 月 10 日、4 月 14 日，经 Apache IoTDB 社区投票，李宇衡、舒文炜成为时序数据库 Apache IoTDB Committer。他们都来自天谋科技，长期专注于 IoTDB 的核心模块与底层架构，在参与这些“看不见却至关重要”的模块贡献中，他们经历了哪些挑战与收获？

李宇衡

我是李宇衡，是分布式时序数据库工程师，主要关注管理节点、共识层、集群稳定性、可运维性等方向。我最早从 2023 年初开始给 IoTDB 提交 PR，2024–2025 年集中在IoTDB 集群 / Region 侧的稳定性与可运维性改进上。
关于 Apache IoTDB

最开始你是怎么了解到 Apache IoTDB 这个项目的？

在学生时代我就接触到了 IoTDB，当时就发现它在时序数据存储、高吞吐写入，还有端到端生态这几个方面技术都非常先进，社区氛围也超级活跃。
一开始加入社区的时候我只是修点小问题、实现一些小功能来练手，后来因为希望帮助 IoTDB 继续越来越好，就正式加入了天谋科技，慢慢开始深入到集群与一致性相关模块的研发工作中。
是什么让你最终选择参与到 Apache IoTDB 这个项目中？

其实最终选择深入参与 Apache IoTDB，主要有两个点特别吸引我：
一个是它的软件工程流程做得非常规范，像 Region 迁移、共识层卡顿处理、Procedure 的并发和恢复这些，都特别“工程化”，有清晰的衡量标准和改进空间，做起来很有实感；
另一个就是社区的反馈非常快，不管是功能设计评审还是代码 Review，机制都很成熟，让我提出的优化能很快落地，同时自己也感觉成长得特别快。
在 Apache IoTDB 中主要负责哪一部分的内容？

我主要参与的是这几块内容：

• 保障 Region 运维和迁移的可靠性：比如完善迁移流程、增加快照校验、确定并发与重试策略。具体做过确定性选择协调者、两阶段拆分迁移流程，还有 IT 框架的迭代。
  
• Procedure 框架的重构：这部分主要做了状态机简化、并发安全增强等等工作。
  
• 集群和元信息治理：比如确保 ConfigNode 和 DataNode 之间信息能够可靠地传递，还有系统属性文件的管理。
  

在参与 IoTDB 项目建设的过程中，有哪些收获？

在参与 IoTDB 项目的过程中，我最大的体会就是：基础软件的可靠性真的特别重要，而要做到可靠，必须得有一套多层次、多维度的质量保障体系来支撑。
比如说，在 IoTDB 里，每项新功能从设计到上线，都要经过很多环节，像功能评审、代码 Review、单元测试、集成测试、还有手工测试和 Atoms 性能监控等等。每一步都严格把关，才能保证最终的质量。
有什么参与贡献过程中的故事分享？

在参与 Region 迁移功能开发的时候，我们把原来 IoTConsensus 中的本地成员列表管理，完全转给了 ConfigNode 来统一处理。这样不仅大幅降低了系统的复杂度，也提高了整体可靠性。虽然这个改动本身逻辑并不复杂，但从提出到最终落地，前后经历了大概四次 PR，用了将近一年才真正完成。
这件事让我感触特别深：哪怕是后来看来非常“理所应当”的优化，在实际开发过程中也往往需要一步步摸索。好的设计往往需要多次迭代来产生，真的不是一蹴而就的。
是什么让你能一直坚持参与 Apache IoTDB 项目，最终成为 Committer 呢？

能一直坚持下来，主要还是因为解决的都是真实的线上问题，而且每次优化都能看到实实在在的效果，比如搞定一个线上故障、把迁移失败率降下去，或者打通某个关键路径，这种“立竿见影”的正反馈特别有成就感。
再加上社区里的讨论氛围一直很好，每一次代码评审都是高质量、“干货满满”的，大家都很专注在把事情做好，自然而然我也就越做越投入了。
关于开源社区

之前有过参与开源社区的经验吗？对开源/开源社区有什么新的认识吗？

之前也给一些开源项目提交过零散的 PR，但真正深入参与 IoTDB 之后，让我更确信：在分布式系统里，把那些流程中“隐性的”、大家默认的约定明确化，才是系统稳定的关键。
比如自动化的集成测试、静态检验、还有足够详细的警告和报错日志，这些看起来好像是锦上添花的东西，其实是一个可长期演进的项目最基础的地基。
你觉得开源社区对 Apache IoTDB 的“加成”是？

我觉得开源社区给 IoTDB 带来了两个特别关键的“加成”：
一个是问题场景更真实：来自不同用户、不同部署环境的使用方式，帮我们覆盖到了很多平时难以预料的边界情况，让系统变得更好用、更管用。
另一个是质量门槛被自然地推高了：因为所有代码都要经过公开的 Review，还有可回归的测试机制，这促使我们每个功能都得先确保“可用”，然后不断优化到“优雅”。
有没有给想要参与 Apache IoTDB 开源社区贡献的小伙伴一点小建议？

还真有我自己的几条“经验之谈”：
第一是多沟通，讲清楚。提 Issue 的时候，尽量把“现象→你觉得的原因→怎么验证→可能怎么修”这条思路表达清楚，这样大家更容易跟进和帮忙。
第二是可以从小地方开始入手，比如改进日志语义、增强 IT 稳定性、小范围 NPE 修复，这类贡献既实际，也很好上手。
第三是可以试试用自动化工具。开发功能或者修 Bug 的时候，记得配上合适的单元测试或集成测试，这是保证代码质量的关键一步。
成为 Committer 的感言！

成为 Committer 代表社区对我的信任，感谢大家的认可与帮助！接下来我会继续在 ConfigNode、Region 运维可靠性以及共识层体验这些方面慢慢打磨，把这些“平时看不见、出事就关键”的 IoTDB 底座做得更扎实。
也欢迎更多小伙伴一起加入进来，咱们一起把 IoTDB 做得更稳、更快、更好用！

舒文炜

大家好，我是舒文炜，2022 年 12 月底实习的时候加入了天谋科技，从那时候开始参与 Apache IoTDB 社区。
关于 Apache IoTDB

最开始你是怎么了解到 Apache IoTDB 这个项目的？

大学的时候我对分布式系统比较感兴趣，有一次在读 Raft 作者的博士论文，偶然发现了 IoTDB PMC 谭新宇的 GitHub 仓库，里面有他对这篇论文的翻译。后来我又去看了他的博客，通过他的分享，第一次了解到了 Apache IoTDB。
是什么让你最终选择参与到 Apache IoTDB 这个项目中？

其实选择加入 IoTDB，主要是觉得它在工业物联网和大数据场景种有很强的应用价值，真的能解决实际问题。而且社区氛围特别开放和包容，像我这样的新人也能很快融入进来，找到自己能贡献的地方。
在这里，我不光可以把学到的知识用在真实项目里，还能通过跟社区里的小伙伴交流，不断学到新东西、打开新思路。这种既能实践又能成长的环境，对我来说特别有吸引力。
在 Apache IoTDB 中主要负责哪一部分的内容？

在 Apache IoTDB 里，我一开始主要负责存储引擎，尤其是 compaction 模块的工作。刚加入社区的时候，主要是从修 bug 开始，慢慢熟悉代码，后来也陆续做了一些规模大一点的新功能开发和性能优化工作。
因为 compaction 和 TsFile 的读写关系紧密，后来我也参与到 TsFile 相关的设计和实现里。今年开始，随着 compaction 模块趋于稳定，我加入了天谋科技的查询引擎组，参与了树转表模型相关的功能开发，还有一些查询性能优化方面的工作。
在参与 IoTDB 项目建设的过程中，有哪些收获？

在长期参与 IoTDB 项目的过程中，一方面，我对数据库系统有了更深入的理解，学会了如何写出更规范、更容易维护的代码。
另一方面，我也越来越关注用户实际的需求和问题，意识到了很多设计和优化其实不是纯技术的“炫技”，而是应该解决用户在使用过程中的真实痛点。
有什么参与贡献过程中的故事分享？

2023 到 2024 年，我参与的 compaction 模块经常遇到一个非常棘手的问题：在处理数据时，系统会报错提示某些本应按时间顺序排序的数据文件中或文件间存在乱序。更麻烦的是，当我们通过 compaction 的报错日志发现这些问题时，往往已经无法追溯到最初是哪个环节的 bug 导致的，而且这些错误在正常读写场景下几乎很难复现。因为系统里涉及 TsFile 的模块很多，每次遇到这种问题，我和组里的同学几乎只能一点点去翻查相关代码和日志，靠推测来定位可能的原因，效率就不高。
后来，为了提高排查效率，我们在多个关键路径的日志中增加了更多额外信息。这样一来，当问题再次出现时，虽然还是不能直接锁定具体 bug，但至少可以借助这些日志快速排除一部分无关模块，排查范围大幅缩小，定位效率一下就上来了。
再后来，经过我和组里其他同学的大量修复和优化，在 IoTDB 较新的版本中，这类问题已经基本没有了。同时，新版本也增加了自动修复机制，从旧版升级到新版后，如果发现已有数据文件存在异常，系统也能在 compaction 过程中自动完成修复。
这段经历让我有一个特别深的体会：做系统开发，除了写功能代码，还得特别关注可观测性、可调试性，以及异常场景下的自愈能力。
是什么让你能一直坚持参与 Apache IoTDB 项目，最终成为 Committer 呢？

说到底，还是兴趣让我一直坚持了下来。在整个过程中，IoTDB 社区总能不断带来新的挑战和学习机会，让我一直有东西可学、有方向可以突破——这种持续成长的感觉，真的让我愿意一直投入下去。
关于开源社区

之前有过参与开源社区的经验吗？对开源/开源社区有什么新的认识吗？

在加入 Apache IoTDB 之前，我没有直接参与过开源社区的经验。通过参与 IoTDB 社区的贡献，我对开源有了新的认识。
我觉得开源不仅仅是代码的贡献，更是与全球开发者协作、共同推动项目发展的过程。在社区中，大家会通过代码 review、issue 和邮件交流不断碰撞想法，这让我在技术能力、代码规范以及沟通协作方面都有了很大提升。同时，我也体会到开源社区的开放与包容，每个人的贡献都可能对整个项目产生积极影响，这种成就感对于社区的参与者们真的非常重要。
你觉得开源社区对 Apache IoTDB 的“加成”是？

首先是技术迭代更快、也更成熟了。社区有来自不同背景的用户和开发者，大家会不断提出问题、贡献改进方案，这能更快发现潜在的问题并优化功能。
其次是项目影响力和生态都扩大了。开源让更多公司和用户了解、使用 IoTDB，形成了“使用-反馈-贡献”的正向循环，推动项目持续发展。
最后是人才与经验的沉淀。在社区里，不同开发者之间的交流与合作不仅提升了代码和项目质量，也让每个人都能在实践中积累经验，不断成长。
有没有给想要参与 Apache IoTDB 开源社区贡献的小伙伴一点小建议？

我觉得最重要的是先开始尝试参与。可以从关注社区的 issue 列表开始，选择一些相对简单的 bug 来修复，既能熟悉流程，也能慢慢建立信心。即使暂时没有合适的 issue，也可以针对某个功能点自己主动做一些分析，比如利用性能分析工具观察运行情况，往往能发现一些代码实现上可优化的地方，也是可以提交给开源社区的。
成为 Committer 的感言！

能够成为 Apache IoTDB 的 committer，我深感荣幸。这不仅是对我过往贡献的认可，更是一份新的责任与信任。
回顾加入社区以来的经历，感觉自己一直在不断学习与成长，也切身感受到了开源协作带来的价值与力量。IoTDB 社区开放且包容，每一份贡献都会被重视。无论是修复问题、完善文档还是提出新想法，都能为项目带来价值。
所以，真诚地欢迎更多伙伴加入 IoTDB 社区，一起推动项目不断发展！

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！