2021开源之夏收获与心得

大四毕业前，骏哥邀请我一起参加开源之夏，他说我们可以一起选IoTDB社区的项目。刚开始我还有点畏难，担心自己的能力不足，但还是被怂恿着报名了。

我选的项目是Apache IoTDB - Apache Skywalking适配器。当时认为这个项目主要是按照Skywalking的要求用IoTDB实现它的存储接口，项目难度中等，应该还是挺好做的。只需要熟悉IoTDB的使用和Skywalking的接口要求，而且还可以参考其它的Skywalking存储插件。

前期的分析是没错的，但没想到实现的时候还是遇到了很多困难，这个单独模块的开发工作量也远超我的想象。

首先我是第一次接触IoTDB，第一次接触时序数据库。IoTDB的存储模型和关系型数据库是不同的。刚开始我并没有好好设计存储方案，和导师和社区的交流也不够。然后直接采用类似关系型数据库的存储方案。结果接口快写完了才发现，Skywalking有的接口要求分组聚合查询，也就是要使用group by，但IoTDB仅支持依照时间戳（group by time）或者某一路径层（group by level）分组。所以这种类似关系型数据库的存储方案是无法满足这种查询需求的。此外，IoTDB有这样一个特性：运行时将路径Path的数据存储在内存中，将物理量Measurement存储在硬盘中。IoTDB本身是没有索引的，但可以通过将某些数据作为路径Path的一部分来实现类似索引的功能。因为类似关系型数据库的存储方案并没有采用这种类似索引的存储方法，所以它的查询效率是相对差的。

在中期报告提交之前，发现了采用类似关系型数据库的存储方案的两点不足：一是无法实现group by，二是没有索引。

随后开始采用带索引的存储方案对项目进行重构。由于将部分数据存储在Path中，所以来自同一个Model的数据被分散到了多个Device中，查询时需要跨多个Device进行查询。但IoTDB对于这个场景的支持并不完善，面对关系型数据库中的聚合、排序、分页查询，IoTDB往往都无法直接满足查询的需求，需要使用暴力法处理，也就是将所有符合条件的数据都查出来，然后再自行实现聚合、排序、分页的功能。这样会造成数据传输开销大、系统处理资源占用大的情况。暂时还没有好的方法可以解决这个问题，要等后续IoTDB针对这类场景增加不同语义的关键字或者完善现有的查询语义才行。

在方案二的开发过程中，我真正体会到了什么叫测试驱动开发（Test-Driven Development，TDD）。我几乎针对每一个DAO接口都编写了相应的测试用例，然后才开始重构原有的查询过程。TDD的开发模式让我能够具有更好的开发质量和更高的效率，确保接口的实现是和设计一致的。完成开发后，我向Skywalking社区提交了PR。社区的几位老师对我的工作提出很多建议，也让我在进一步了解了Skywalking高度自动化的项目开发管理。具体有以下几点：

1. 使用git rebase合并commit
   我提交PR的时候有80+的commit，这样不利于对于代码审查和最终的合并。所以就使用了git rebase将commit压缩到了个位数。我自己操作的时候是使用IDEA自带的Rebase图形化界面，没有直接使用命令行操作。但基本分三步：
   • git rebase：将之前merge的代码全部rebase到master分支之上。
   • git rebase -i：将master分支上的commit进行合并。
   • git push --force origin iotdb-adapter， 将本地rebase的结果强制push到远端。
2. 使用TestContainer和AssertJ进行测试
   TestContainer可以让本地测试和线上测试保持一致，尤其是DAO层的测试。DAO层的测试依赖于所使用的数据库，TestContainer确保本地测试和线上测试使用同一类型同一版本的数据库Docker镜像。AssertJ提供了语义更清晰，功能更丰富的断言集合，比JUnit和Java自带的断言要更好用。我写的UT都是针对DAO接口的测试，但这些接口的测试已经在e2e测试中进行了覆盖，而且DAO接口也更适合于在分布式环境下进行测试，也就是说Skywalking不推荐使用UT来测试DAO层接口，所以我最后将我写的UT都删掉了。
3. 持续集成（Continuous Integration，CI）
   Skywalking使用Github Actions通过高度自动化的CI来保证项目的功能完整性和安全性。功能完整性依赖于对项目的完善的e2e测试。Skywalking优秀的e2e测试框架甚至已经独立出来成为一个单独的项目：SkyWalking Infra E2E。
4. 持续交付（Continuous Delivery，CD）
   Skywalking使用Github Actions自动发布dev docker镜像到Github Packages中。这样确保用户可以随时使用最新的版本。
5. 对CVE（Common Vulnerabilities & Exposures）的严格要求
   Skywalking通过将所有的依赖的版本和证书进行了统一管理，确保依赖的开源软件中具有尽可能少的CVE。当然这一点也是因为Skywalking商用非常广泛，各大厂对于系统安全性的要求的很高，系统中的CVE往往是不可容忍的。有些bug可能不是写出来的，而是依赖出来的。开发前进行技术选型的时候，也要评估依赖软件的可靠性安全性，否则后续会将问题和bug蔓延到自己的代码中。
6. 对他人产品的尊重是很重要的，这也是开源精神的一部分。https://github.com/apache/skywalking/pull/8202

这次的开源之夏，我付出了很多时间与精力，也收获了很多东西，真正的让自己参与到了开源社区之中。我提交PR时有6k+行的代码，删除UT和readme后还有近4k行。还记得自己第一次发邮件、第一次提issue的时候的不安，但还是得到了社区热情的回应。还记得自己向Skywalking提交的第一个PR被接受并且合并到了主干中的时候的那种兴奋激动，虽然只是修复了一个边缘的小bug，但却是我第一次真正向社区贡献了有价值的东西。看着Skywalking 8.8.0的CHANGES中有我修复的三个小bug，还是小有成就感的。希望我在黄老师和吴老师的指导下开发的最终产物IoTDB storage plugin（也就是Apache IoTDB - Apache Skywalking适配器）能够顺利合并到主干中，在Skywalking 8.9.0中发布。

创造价值的过程是充实而美妙的，再次感谢开源之夏能给到这样一个机会让我在开源社区中创造价值，实现自我价值。再次感谢IoTDB社区的黄向东老师（@jixuan1989）和Skywalking社区的吴晟老师（@wu-sheng）的指导。还得感谢骏哥拉我入坑，常常一块讨论共同遇到的各种问题，共同进步。