如何在两年内做出一个Apache顶级开源数据库——乔嘉林

 前言 

        数据一旦与时间结合，就拥有了生命。时序数据正是这样一种数据。在金融市场、系统日志、工业产线和智能设备上，时序数据每毫秒都在不断产生。大量的时序数据需要专业的数据库系统来管理。在20世纪70年代以来的相当长一段时间里，关系型数据库都占据了主流地位。直到21世纪初，NoSQL 数据库逐渐流行并占据了半壁江山，这种数据库更能适应互联网上产生的大量非结构化数据。它们当中不乏出色的开源软件。与此类似，时序数据管理的特殊需求也催生了专业的时序数据库产品。在 DB-Engines 网站的排名中，时序数据库产品的受关注度持续上升。

        本篇是时序数据库专家乔嘉林的深度访谈分享，本篇的作者是毕业于清华大学经济管理学院、哥伦比亚大学工程与应用科学学院的 Michelle ，她一直关注包括数据库系统软件在内的 IT Infra 类软件，是多篇深度行业研究的撰写者。

从这篇深度访谈中，您可以了解到：

        开源社区的运作经验

        Apache 基金会有何独特之处

        什么样的项目适合开源

        不同类型的开源项目和社区有何区别

        开源对于个人和项目有何影响

        IoTDB 的技术路线和优势是什么

        数据库产品未来的发展趋势如何

        开源与商业化之间是什么关系

嘉宾介绍：

        乔嘉林是国产高性能开源时序数据库——Apache IoTDB 项目的 PMC，也是其初创团队的主要开发者之一。从 IoTDB 的创始之初，他就加入了团队，不但在研发的道路上一路披荆斩棘，同时也将 IoTDB 项目在多家大型企业实施落地。乔嘉林一直是 IoTDB 开源社区的主要维护者和推广者。在开源社区里，他有一个响亮的名号，铁头乔。不少人通过他的介绍与 IoTDB 结缘。

        本文约10000字，阅读时间约为10分钟。您也可以直接跳至文末阅读访谈总结和感悟。

1. IoTDB 为什么选择了开源？

        乔嘉林：IoTDB 原本是由清华大学团队开发的。这个项目最早可以追溯到2010年左右，由清华大学软件学院王建民教授立项和支持，组建了专注数据库与工业软件的团队进行研发。在很多大型企业的合作落地过程中，IoTDB 的功能和性能都得到了充分验证。

        随着工业上对时序数据管理的需求越来越多，团队觉得应该把 IoTDB 作为开源项目贡献出来，让大家能够利用 IoTDB 解决工业生产和运维领域里卡脖子的问题。另一方面，开源对软件研发和推广有极大的促进作用，我们希望 IoTDB 能汲取更多开源社区的力量，由社区来共同把它建设的更好。另外，国际上知名的开源软件大多数还是源自于国外，我们希望通过IoTDB 的开源，让中国的数据库软件在开源界拥有更大的影响力，也以此来进一步促进国内开源软件的发展。

2. IoTDB 作为一个开源项目能够用两年的时间在 Apache 成功孵化顺利毕业，有哪些经验？

        乔嘉林：一个开源项目要取得成功，最重要的是项目的初始贡献者团队，也就是项目的管理委员会要有统一的思想。他们必须是由衷希望把这个项目做成一个国际化的开源项目，而且持续地往这个目标去努力。有些项目的社区发展到后来不活跃了，可能是因为它被捐赠进 Apache 时只是为了完成 KPI，后续由于企业的战略调整就没有人再维护了。

        另外，整个孵化过程中的重点是对开源贡献者的培养。基础软件或者数据库这个方向，本身上手难度就比其他类型的项目大。因为做数据库需要了解基础理论，代码的行数多、复杂度也高。这时候就需要开源社区的维护人员更加关注新的贡献者的培养。把开源项目网站等基础设施搭建起来，只是一个最低的标准。如果想让新的贡献者能够对项目有深入的理解，并去做一些深入的优化，就需要一对一的交流和辅导。有一位来自 IoTDB 社区的深度贡献者，我跟他的交流就非常多，微信上的文字聊天记录都有几百兆。所以并不是说项目开源了、各类文档写好了，那么社区贡献者就全冒出来了。作为维护者，必须付出大量的精力去与别人分享，这也是一种开源精神。

3. IoTDB 加入 Apache 基金会之后，你对Apache 有什么感受？为什么它能够汇集大数据软件的生态圈？

        乔嘉林：大数据系统和 Apache 基金会并没有必然的联系，只是一个自然发展的结果。Apache 基金会确实是有一套行为准则，或者说它所提倡的开源项目的建设方式，去引导这些项目、让项目能够做的更成功。这就是 Apache way。

        Apache way 提倡建设一个更多元化的开源社区，让社区不是一家独大的。它希望这个社区里的贡献者能够来自不同的国家和组织。贡献者在 Apache 社区里面的身份仅通过一个ID来标识，其原本所属的公司和职级都被隐去了。Apache 希望所有贡献者是平等的，贡献者通过在社区里面的贡献去积累自己的声望。

        Apache 提倡用邮件列表的方式进行项目上的交流。这是考虑到有些贡献者并没有实时通信的条件，或者大家不在同一个时区，那么就只能通过邮件列表来交流。Apache 认为即时通讯的产品不利于形成一个全球合作的社区，所以更推荐通过邮件去交流。我们刚开始觉得邮件交流比即时通讯的效率要低。但是从另一个角度来讲，当把一件事情写成一封邮件发出去的时候，我们会对这个事情考虑得更周全，也会把自己的观点表达得更有逻辑、更加清楚，这也从一定程度上提升了沟通的效率。

4. 你觉得什么类型的项目适合开源？

        乔嘉林: 大部分的知名开源项目都是基础设施类、系统软件类的项目，比如 Linux 操作系统、安卓操作系统、Hadoop 等等。这些软件通常源于一个小的团队，但小团队的精力是有限的，面对的场景和需求也是有限的。而大的系统软件的开发不仅需要更多的研发人员参与，还需要更多的需求来引导它成为一款更健康的软件。如果一个基础软件在开发过程中面向的场景不够丰富，那它的产品形态就不会有很好的适用性。所以一个项目越庞大，或者说它的定位越高，需要的贡献者的力量越多，就越适合做开源。

5. 当一个需求有多个开源项目可以实现时，企业如何从中做出选择？

        乔嘉林：这有很多种方法，可以根据开源协议选择，也可以根据公司的需求去选择，还可以根据这个开源项目本身的成熟度等方面去做出选择。

        在开源协议方面，要看这个项目所使用的开源协议和企业的商业化的方式是否一致，例如 Apache 是一种商业友好的协议，但是需要符合规范地去使用。

        如果是从需求方面来说，需要平衡好客户的需求、项目的发展方向和企业自身产品的长期规划。首先是看软件具体的功能、性能指标是否符合当前的要求，如果不能满足，那就还需要考虑二次开发、运维的成本等。从中长期来看，开源项目有自己的发版周期和功能演进方向，那么也要看这个方向和用户的需求以及企业自己的规划是否匹配。如果不匹配，就需要及时做一些调整，比如和社区去讨论，甚至贡献某个功能。

        最后，从开源项目本身的成熟度和社区活跃度方面也可以做一个判断。成熟度方面，开源社区本身有很多度量项目成熟度的模型，比如 Apache 会从7个维度考察项目成熟度（Code、License and Copyright、Release、Quality、Community、Consensus Building、Independence）。Apache 的顶级项目通常在这几个方面做的都很好。从社区方面来说，如果一个项目的社区是跨团队的，那这个社区一定是有吸引人的点，发展潜力也会更大。如果基于开源社区发展出了一些商业公司，那代表着这个社区会有人长期维护，能够保证一定的发展速度，而且遇到技术问题也能够找到专业的解决问题的团队。

6. 在做开源的过程中，你觉得不同的开源平台（如 GitHub、Gitee）有什么区别？

        乔嘉林：GitHub 成名的时间比较早，大家都认同它，就像 Windows 操作系统一样，它的生态已经非常繁荣了。任何的开源项目，基本都能在 GitHub 上找到源代码。国内的代码托管平台起步会艰难一些。但是在功能上，国内社区做的其实也已经很完善了。

7. 不同的开源项目的运作方式有什么区别？

        乔嘉林：不同社区的治理模式不同。这涉及到项目或者社区由谁做决策，比如是不是所有人都可以合并代码、谁有投票资格等等。常见的开源社区治理模式有三种：

        1.单一公司主导。这种软件的设计、开发和发布都由一个公司来控制，也不接受外部贡献。它的开发计划、版本计划、相关讨论都不公开，只有版本发布时候才对外公开源代码。

        2.是独裁者主导。这种社区是由一个人来控制项目的发展，通常是这个项目的创始人。

        3.管理委员会主导。它是由一群人构成项目的管理委员会，来决定重大事项。比如 Apache 的项目就是由 PMC（项目管理委员会）去做决策的。

8. 如果有人要从头开始做一个开源项目，你会给他哪些建议？有哪些要注意的地方？

        乔嘉林：首先是了解不同的开源协议的区别，然后选择一个适合自己的开源协议。之后就是把项目按照这个协议的要求，规范化起来。然后就是建设这个开源项目的社区了，也就是通过什么样的方式让别人了解到这个开源社区。开发者需要把自己当成一个外部贡献者去模拟一遍流程，比如外部读者看到一篇介绍本社区的文章时，能不能通过它了解社区运转的基本规则，并且能够联系到社区里的人进一步交流。

        建设一个开源社区像建设游乐场一样，要设计好里面的项目，同时我们还需要充当移动的路牌——从游客进入大门的那一刻开始，到之后他能在这个游乐场体验到哪些游乐设施，我们都要在地图上做好规划。

9. 开源这件事情，对你个人有什么改变或者影响吗？

        乔嘉林：开源最主要的影响还是带来了很多优秀的贡献者。假如没有开源，我可能还是和实验室的同学、老师一起做研发。开源之后，就从一个实验室的团队，变成了跨地区的大团队，工作模式也发生了改变。会有很多甚至素未谋面，却能一起奋斗的朋友。这种感觉非常好。

        比如，我们的第一个深度贡献者是2019年10月份跟我联系的。他和我们一起做查询引擎的改造。当时我因为需要写论文，就暂时离开了项目。但就在我写论文的那一个月里，他把项目代码中的100多个没有跑通的测试用例，一个一个全部修好了。这给我很大的震撼。后来我们也成为了很好的朋友。这就是开源的魅力。我们可能经常听说开源能吸引志同道合的人，但我之前对这个词没有具体的感受。但当我看到那100多个测试用例全都跑通时，我感受到了什么是真正的志同道合。

10. 有了这么多的开源实践之后，回头看，你怎么理解开源精神？

        乔嘉林：对于一个个参与开源社区的贡献者来说，开源精神其实就体现在平时的一些小细节里。

        当有新的贡献者希望参与社区时，怎样去对待新的开源爱好者，如何让自己为其他的开源贡献者做好基础的服务，这属于是开源精神中的奉献的部分。

        当贡献者越来越多的时候，我们就会考虑怎样让这个过程变得更高效，这时的重点就变成了去建设开源的基础设施，比如整理贡献指南，然后把一些容易修改或者适合入门的小任务标记出来，让大家能够更容易地去找到这些任务，这是开源精神中的效率的部分。

        当贡献者充分参与研发时，大家很容易对软件设计有不同的想法。这个时候就需要跟大家充分地沟通，讨论需求、功能定义和实现思路。我们只讨论某个功能应该是什么样子、某种技术有什么优缺点，而不会考虑社区的里开发人员在现实生活中是什么职级。只要他说的话有道理，就会被接受。在开源社区的邮件列表里面，每一个人的身份都只是一个贡献者ID，不带任何的公司职位和背景。这是开源精神里的平等的部分。

11. 作为 IoTDB 项目里面代码贡献量最多的人。你怎样高效的写代码？你觉得写代码需要灵感吗？

        乔嘉林：写代码更多时候需要把逻辑理清楚——一件事情先做哪一步，再做哪一步，有没有并发问题。在做系统时，不要给自己设边界，要不断熟悉那些之前不了解的模块。当我把 IoTDB 的核心模块都理清楚时，是豁然开朗的，遇到问题时，能立马想到问题出现在哪个模块，看一看日志就能推理出bug在哪里。我觉得写代码最快乐的地方在于，能够从刚开始熟悉一个模块，到后来掌控一整个系统，清楚大型系统里面每一个细节的运转情况。

        而且代码写得越简单、逻辑越清晰，质量就越好、效率就越高。尤其是大型系统，如果想让更多人了解，那它的架构一定是非常清晰的。别人最好通过函数名、参数名就能看懂每一个模块在干什么，这样才更可持续。

        灵感有时候也是需要的，但是这来源于日积月累和专注的投入。有句话叫念念不忘，必有回响。有一次为了解决一个bug，我是在梦里分析出了问题出现的潜在原因。有一些产品优化的问题，可能你想了几周都没有思路，但之后的某个瞬间，当你遇到一个类似场景时，可能就想到解法了。所谓灵感，也需要不断思考，接触新的思路。

12. 如何利用开源实现个人成长？

        乔嘉林：开源是一个平台，不管在哪个平台上，想要实现较大的成长都要有足够的投入。开源社区也是一样，社区里的其他贡献者不会追着让你做什么东西，更多时候是要主动发现问题、发现机会，主动承担责任，所以自驱力是很重要的。这是思想上的。

        接下来有一些具体的操作：

        开源的本质是开放和共享。一方面要从公开渠道主动了解和学习基础知识，比如 GitHub 的使用方式，提PR的方法，Linux的常用命令等，这些都需要自己主动补基础。

        另一些和项目背景相关的问题可以多和社区成员讨论，有一些问题是带历史背景的，可能社区成员的一句话就能解决你的疑问，但是公开资料上却未必能找得到答案。这个过程中可以尝试去结识 PMC，他们对社区非常了解，对于开发者后期贡献代码、建立信任都很有帮助。当然也可以自己去阅读设计文档、阅读源码。

        接下来就是将自己的想法多和社区同步，包括想实现的功能、改进点、设计思路等。多去表达，才能收获更多有用的建议。

        最后就是形成贡献。在开源社区里，开发者能够认识技术大牛、交到志同道合的朋友，大家打破公司、职级、背景的界限去交流技术问题，对于新人来说是非常快的学习方式。但是“纸上得来终觉浅，绝知此事要躬行“，向社区贡献代码才是进步最快的方式。

        Apache 有一句座右铭："Merit never expires"。就是说“一朝贡献，永久贡献”。这个过程重在持续，无论是代码贡献还是做布道师，都是利他利己的。这个过程可以是循序渐进的，同时也要做到充分尊重不同背景的个体。

13. 说回 IoTDB，作为一个数据库，它的设计理念是什么？

        乔嘉林：一个数据库的设计要考虑它的应用场景、架构和部署方式。

        在应用场景上，IoTDB 主要是管理时序数据。时序数据本身也有很多的应用场景，比如金融、机房的相关监控、工业互联网等。我们选择工业互联网作为 IoTDB 的主要应用场景。这一方面是因为，我们团队本身在工业互联网方面有很多积累；另一方面，工业互联网本身的难度更高，涉及到的数据质量的问题很多，给软件提出了更高的要求。所以我们认为把工业互联网场景管理好，其他的领域也就都是能够去适配的。

        接下来就是针对工业互联网的场景去设计架构。从架构方面来说，IoTDB 不只是一个数据库产品。它还包括一个独立的底层数据文件格式——TsFile 。

        在工业的场景中，从数据的产生到后面的消费、应用，跨越了端侧的设备、边缘网关、再到云平台等多个物理环境。那么数据库就不能只在一个环境下标准地去部署。有很多企业需要在边缘端设备上先用一个文件把时序数据管理起来。所以我们设计了一个用于存储时序数据的列式压缩存储文件格式——TsFile。相比于数据库，它的使用会更便捷，也不需要运维。只需要把它放在磁盘上，只要磁盘不坏、数据就不会丢失。

        传统的数据库对我们来说是偏黑盒的东西，我们看不到它底层的文件格式是什么样子。其中的数据文件既拿不出来、也用不了。但是基于我们设计的TsFile，再去设计数据的管理引擎，就可以进行场景的互补。当一个文件和数据库结合起来之后，它是一个更灵活的、可插拔的架构，文件可以从别处生成，然后加载到数据库里面，这就能做到端侧、边侧和云侧的协同；这个文件也可以从数据库里面卸载出来，直接接入其他系统进一步分析利用。这些都是传统的数据库没有的功能。

        这就是我们从工业互联网的场景入手，发展出来的这样一条数据库架构设计的路线。

14. IoTDB 性能方面的优势是如何实现的？

        乔嘉林：这可以分为四点来介绍：

        1.IoTDB 采用了独特的面向工业互联网的数据模型。实际上每一种数据库都是基于数据模型进行读写和数据管理的，比如关系型数据库基于关系模型、key-value 数据库基于键值模型、图数据库基于图模型，所以他们的使用场景也不同。针对工业互联网的时序数据管理场景，IoTDB 提出了树形数据模型，上面由任意属性节点定位设备，设备下面有不同测点，测点下面对应具体的时间序列数据。树形模型是一种新的模型，更偏向工业互联网领域，因为传统的工业协议对测点的描述就是字符串，有特定的编码方式，比如用“region1.turbine1.velocity”这种方式去命名，这和我们的树形模型非常相似。IoTDB也是用“.”将不同层级进行拼接，从而实现通过字符串去定位时间序列。这种模式的好处在于它没有表的约束和字段的限制，每一个时间序列都是独立的。而 InfluxDB 等一些数据库的数据模型，不容易被工业用户接受。

        2.IoTDB 采用了列式存储的文件格式。IoTDB 对于时间列的存储分成两种存储方式。一种是多个序列共享一列时间戳，这与基于关系数据模型所开发的时序数据库的模式相同，这种存储方式的优势在于当数据采集频率比较整齐的时候，存储效率较高。但如果各个测点是独立采集的，时间戳上对不齐，那就可能会产生大量空值。国内其他时序数据库的厂商主要采取的就是这种方式。另一种方式是把每一个测点都作为一个独立的时间序列，一个测点列就对应一个时间列。InfluxDB 采取的就是这种方式。IoTDB 则采用双存储引擎，结合了上述两种方式——多个测点列共享一个时间列，或者每个测点列都各自匹配有单独的时间列，这样就能更好地适应工业互联网场景。此外，IoTDB 除了存储原始数据外，还会存储索引和预计算信息，有助于查询时加速数据过滤、加速聚合计算。

        3.在存储引擎方面，IoTDB 在内存中采用原始数组追加式写入数据。IoTDB 不会在数据写入时同步去做排序的工作，因为这会非常耗时。我们会把排序做成异步操作，在实际刷盘时再做排序、编码和压缩。同时 IoTDB 做了流水线的机制来加速数据从内存到硬盘的持久化过程。我们还设计了一个感知查询负载的机制，能够根据查询负载做数据整理，这样在以后查询数据的时候，效率就会更高。比如同一个设备的传感器的数据通常会被同时查询，IoTDB 就会把这些数据在磁盘上组织到一起；再比如最近几天的数据相比几年前的数据被访问的概率更高，IoTDB 就会把这些比较新的数据放在更易于查询的地方。

        4.IoTDB 在查询引擎方面也做了优化，比如采取列式处理。相比火山模型的逐行迭代，我们采用批量迭代的方式。另外磁盘I/O做了异步化和并行处理，从而达到比较好的弹性。

15. IoTDB 在工业企业落地的过程中，有什么令你印象深刻？

        乔嘉林：近年来互联网等 to C 的行业比较容易引起关注，形成了马太效应。造成的结果就是，制造业等实业所能获得的关注和资源就比较少，工业、制造业的重要意义和很多需求因此就被忽视了。其实这里面有大量的对于软件的需求，而且是很高的需求。

        曾经的一个案例让我印象深刻，那是国内的一家大型钢铁集团，他们之前在时序数据处理方面遇到了很大的问题。在钢铁生产线上，每发生一次设备故障引起的事故，会造成严重的损失，有时甚至是血的代价。集团专家想利用数据挖掘、机器学习的方式，通过机器上产生的数据去预测故障，从而减少损失。但是却苦于没有可用的数据。这不是因为机器产生不了数据，而是因为机器产生了太多的数据，以至于现有的数据库系统没有能力把数据及时地存储下来。这种工业数据的规模到底大到什么程度呢？打个比方，他们每天都像是在过双十一，然而最基础的数据存储问题都解决不了，自然也就谈不上如何加以挖掘利用。他们尝试过 Hadoop 、Cassandra，也曾花费巨资请一些互联网公司的专家团队来提供解决方案。但都无法解决实际需求。后来我们用一台 IoTDB 解决了他们全部时序数据的存储需求，替换掉了之前由多台Cassandra 机器组成的集群，并且在数据压缩比和写入效率方面都有很大的提升。

16. 时序数据库市场里，有一些起步比较早的其他玩家。IoTDB 跟他们相比，优势在哪里，这些优势是由哪些因素决定的？

        乔嘉林：国外的时序数据库，大概从2013年的 InfluxDB 开始起步的。在国内，IoTDB 在2015年左右开始起步，应该是最早去做时序数据库的。我们真正的技术积累，是从2010年左右就开始了。首先，我们的优势来自对这个场景的更深的理解，我们更了解工业场景中存在哪些真正的需求，这样产品就会更加贴近这个场景的性能要求。所以有一些技术难点，比如数据怎样去建模和管理、如何去支持乱序数据，都是我们最早在工业场景中发现的需求。我们会在这些工业的独特场景里面去钻研技术，然后在实际场景里得到检验。其次，我们以清华为主的团队也有很强的科研实力，比如乱序数据管理这个技术，我们最近发了一篇论文到数据库的顶级会议里，结合理论去指导实践。

        InfluxDB 是面向 APM 场景设计的，如监控机房服务器、CPU、内存等，他用的是标签模型，通过标签定位序列。但是标签很容易被漏写，所以查询时有可能查到一些不相关的内容，可以说InfluxDB的模型比较松散。InfluxDB 还有一个缺点在于，当数据量大时，它的聚合查询性能下降很明显，这是因为 InfluxDB 没有预聚合的机制；此外数据写入方面，InfluxDB 有measurement的概念，每个measurement类似一个独立引擎，当引擎多的时候，内存管理的就不好。因此在做下一代数据库时，InfluxDB 提出了 iox 架构，选用了 Parquet 做底层文件存储格式。这类似于 IoTDB 底层接TsFile，这也侧面证明了 IoTDB 选择一个开放的文件格式这条道路是正确的。但是Parquet并没有对时间维度做优化，也还是会存在冗余存储的问题。TsFile 已经解决了这个问题。

17. TsFile是一个列式的文件结构，它跟Parquet 有什么区别？

        乔嘉林：Parquet 是一个通用的列式存储文件格式，它的数据模型是一个嵌套的模型。如果用 Parquet 去存工业数据，需要解决一些问题，比如怎么样在Parquet 的模型里面把数据的主键给表达出来，主键是放到列名上还是列的值上。我们发现用 Parquet 去管理多个设备的时序数据的时候，会需要重复存储一些主键信息，这些数据会形成冗余。又因为冗余，对这些数据块进行索引的时候，就不能很快的去定位数据。

        TsFile 相对于 Parquet 来说有几个改进：因为 TsFile 是为物联网时序数据的管理去设计的，所以它天生比 Parquet 多了几个概念：

        一个是时间概念，Parquet里面只是把时间当做一个普通的长整型数据去存，而TsFile里有默认的时间戳概念。

        此外，TsFile 里有设备和传感器这两个物理含义，而Parquet 是没有的。基于时间、设备、传感器这三个特有的模型的概念，TsFile 里面就会做更多的针对这三个方面的索引。有了这些索引，它的查询速度就会更高，能够达到 Parquet 的一两个数量级以上。

18. 很多数据库都是用 C++ 这样偏底层的语言去写的，因为数据库软件很强调性能。IoTDB 为什么选择了 Java ？你怎么看待这个选择？有没有受到过这种开发语言的限制？

        乔嘉林：有些数据库选择用 C++ 去写，可能也是传统的原因。用 C++ 去实现的数据库，大部分都是支持事务的。其实工业互联网的场景里是不需要事务的概念的。

        Java 有几个好处。一个是跨平台特性，对于从高校出来的项目来说，有利于在前期去更加关注整个数据库的架构，快速调整架构方向，而不用太关注用哪个语言在哪个平台去实现。第二是对于用户来说，Java 更加友好，因为它的部署更加简单。有的用户之前部署过其他系统，发现很麻烦，但是使用 IoTDB 之后，在安装环境的搭建上，只需要装一个 JDK 就好了。所以它确实有简化运维的效果。第三是方便让更多的人参与。现有的一些数据库，比如说 HBase、Cassandra这些也是用 Java 去做的，而且做得很成功。

        当然 Java 确实会有一些限制，比如说内存管理。我们在 IoTDB 里面做了一些机制去避免这种限制。比如让数据库本身去管理内存，而不是完全依赖 JVM 。我们在数据库里面对系统里的对象进行缓存，而不是交给 JVM 进行垃圾回收。数据库里面会做很多的缓冲池去实现循环利用。同时，我们会去对这些缓冲池进行内存统计，精细化地去管理内存。

        现在除了 C++ 之外，也有一些用 Go 语言写的数据库类项目。最近也有一个新闻是某家公司之前用 C++ 写的数据库，后来把 C++ 全删掉又改用 Rust 重新写。所以关于用来实现数据库的编程语言，C++ 已经不是唯一选择。

19. 像 MongoDB 等其他类型的数据库近期也推出了时间序列数据管理的功能，对此你怎么看？

        乔嘉林：MongoDB 想要支持时序数据管理的功能是不难的，这与在关系型数据库或键值型数据库上套一层时序数据管理功能的逻辑是一样的，这只是业务的封装，接口的适配。但这仅仅是功能上能跑通，性能上还是会受到底层设计的影响。

        像 OpenTSDB、KariosDB 是把时序模型套在KV数据库上，结果也是性能差、系统复杂度高。基于关系模型的时序数据库也是有类似的问题，关系模型是集合的概念，并没有序列的概念，模型上的不同会导致底层对数据的抽象不一样，无法达到最优效果。在关系模型中，如果用表去管理时序数据，每一列对应一个传感器，那就需要提前指定好有多少列。但工业上，设备传感器的数量会动态变化，所以关系型时序数据库在功能和性能上就会有牺牲。

        所以虽然其他类别的数据库在功能上也可以支持时序数据管理，但它的极限性能会受到原有数据模式和底层设计方面的局限。

20. 在 IoTDB 的应用方面，未来还有什么拓展空间吗？

        乔嘉林：只要有时间戳就是时序数据，比如GPS信息、机器的日志等等，所以 IoTDB 也可以支持时空数据、日志管理、APM  等。

21. 你认为未来数据库软件的发展方向是怎样的？

        乔嘉林：未来数据库的发展会偏向应用场景，根据场景做特定优化，需要一事一议，比如异步、并行等。优化方式如何和数据库系统结合，需要独立去根据场景来思考。当数据库体量大时，优化某个场景可能需要牺牲其他场景的表现，所以需要根据用户的需求排好优先级。

        数据库向数据领域的上下游辐射一些功能是可能的，但更有可能的还是每一类产品去做自己擅长的事情。比如数据库擅长快速读写，它的核心还是数据管理。再具体一点，关系型数据库最核心的优势之一是事务管理，如果要它同时支持事务和大规模分析，那么对读写路径优化的目标就不同，所以很难通过一种引擎支持不同场景。

22. 如何理解开源在中国的火热？中国的数据库软件适合选择开源吗？

        乔嘉林：近两年大众对开源的关注度多了，相关的大会和用户也多了，感受到了开源的火热。这和开源公司的很多融资活动有关系。国家在政策方面也在支持开源。

        在数据库界，Oracle 仍然首屈一指，而它是闭源的。在这种市场已经被瓜分了的情况下，开源更有助于其他产品收获更多贡献者和反馈，加速前进和超越。尤其是中国当前的数据库产品比照国外数据库的标杆还有很大差距，数据库软件开源可以加快中国在数据库领域的追赶速度，同时也可以吸引中国更多软件的开发者加入底层软件的开发、培养更多数据库开发人才。

23. 开源与商业化是否矛盾？

        乔嘉林：开源对商业化有促进作用，商业化也是好的社区发展的必然趋势。像MongoDB、Kafka、Spark、InfluxDB 等知名开源项目，背后都有商业化公司。商业化公司也会大力反哺社区。即使是没有开源的 Snowflake，也斥资8亿收购了开源的 Streamlit 用于构建基于数据的应用程序，而 Streamlit 也将继续建设和支持自己的开源项目及其背后的社区。

24. 什么样的开源项目适合商业化？开源项目被商业化后如何保持核心竞争力？

        乔嘉林：一些小型的工具类开源项目不太适合商业化，因为它并不能提供足够多的服务。那些足够底层、被更多场景应用、足够复杂的开源项目比较适合商业化。

        把开源代码拿去做商业化版本是很常见的事情。但即使做了内部分支或是闭源版本，如果做了大的版本和功能改动，最好也要 upstream 到上游社区，否则后续版本就只能一直闭源，这就和开源社区无关了，也享受不到开源社区的红利。所以大家倾向于在商业版中保留周边功能，但内核功能还是捐给开源社区，这样才能持续共同发展。那么，商业化的核心竞争力应该是对代码的熟悉程度，和对社区的影响力。

25. 如何看待云厂商拿开源项目商业化？这与项目创始团队成立的商业化公司冲突吗？

        乔嘉林：这确实在经济上会有一些冲突。但是一些云厂商在进行商业化的同时，也对社区保持着持续贡献，比如阿里云、华为云都与 IoTDB 的社区有合作，并且都在持续贡献。毕竟社区没有限制谁能去赚钱。从另一个角度来讲，一个开源社区能够孵化更多的商业公司，也说明了这个社区的成功。

26. 开源软件是否涉及安全问题，用户是否有办法规避？

        乔嘉林：一般来说开源项目不会刻意埋雷。从用户的角度来说，可能是无法避免开源软件有bug这样的问题的。但开源对于用户还是更加友好的，至少用户可以知道软件的bug在哪里、是否会出现在他的应用场景中、何种情况会触发bug。另外开源项目也支持代码检测。而且开源社区会记录下软件的bug，一旦发现就会尽快处理掉。从这个角度来讲，开源反而可能更安全。

访谈总结

        在访谈中，乔嘉林分享了关于开源软件的深入见解，也分享了 IoTDB 的技术路线，设计思想，以及对数据库行业发展发向和对开源项目商业化的思考。作者将乔嘉林的部分观点总结如下:

1. 开源软件和开源社区

        开源项目在孵化器的成功孵化，需要初始贡献者团队有统一的思想，以建设一个国际化的开源项目为目标持续努力，也需要重点关注对开源贡献者的培养。

        建设一个开源社区像建设游乐场一样，要设计好里面的项目，同时还要为游客做好地图规划。

        开源精神强调奉献、高效、包容和平等，这些都体现在做项目的具体细节里。

        大型系统软件更适合开源。因为该类软件的开发不仅需要更多的研发人员参与，还需要更多的需求来引导。只有软件所面向的场景足够丰富，其产品形态才能有很好的适用性。一个项目越庞大，定位越高，需要的贡献者的力量越多，就越适合做开源。

        企业用户在选择要使用的开源项目时，可以根据开源协议选择，也可以根据公司的需求去选择，还可以根据这个开源项目本身的成熟度等方面去做出选择。

2. IoTDB的设计思想、技术路线，数据库行业的发展方向

        数据库的设计要考虑它的应用场景、架构和部署方式。在工业的场景中，从数据的产生到后面的消费、应用，跨越了端侧的设备、边缘网关、再到云平台等多个物理环境。因此IoTDB不能只在一个环境下标准地去部署。所以IoTDB不只是一个数据库产品。它还包括一个独立的底层数据文件格式——TsFile。TsFile和数据库结合起来之后，形成了更灵活的、可插拔的架构，这是传统的数据库所不具备的功能。

        除此之外，在数据模型方面，IoTDB采用了独特的面向工业互联网的树形模型；在存储引擎方面，IoTDB采用了流水线的机制，将排序、编码和压缩进行了异步处理；在查询引擎方面，IoTDB采用了列式处理和批量迭代的方式，达到了比较好的弹性。

        除了工业数据外，IoTDB也可以支持时空数据、日志管理、APM等。

        MongoDB等其他类别的数据库虽然也推出了支持时序数据管理的功能，但其极限性能会受到原有数据模式和底层设计方面的局限。

        未来数据库的发展会偏向应用场景，根据场景做特定优化。数据库向数据领域的上下游辐射一些功能是可能的，但更有可能的还是每一类产品去做自己擅长的事情。

3. 开源与商业化

        数据库软件开源可以加快中国在数据库领域的追赶速度，同时也可以吸引中国更多的软件开发者加入底层软件的开发、培养更多数据库开发人才。

        开源对商业化有促进作用，商业化也是好的开源社区发展的必然趋势。足够底层的、能被更多场景应用的、足够复杂的开源项目比较适合商业化。商业化的核心竞争力应该是对代码的熟悉程度，和对社区的影响力。

作者评论

        1977年，33岁的拉里·埃里森创立了 Oracle，一个属于关系型数据库的时代开启了。它的中文名称甲骨文，颇具历史厚重感。这种起源于商朝的文字系统见证了人类记录信息方式的历史变迁：从甲骨到竹简，从纸张到硬盘。

        信息的数量和形式一直在变化，作为信息的载体也一直在变化，而这种变化如今正在更为明显的快速发生——关系型数据库已经不再独霸天下，各种非关系型数据库迅速崛起瓜分市场。正如乔嘉林所说，“每一类产品去做自己擅长的事情”，这也正符合我们所看到的趋势。

        放眼整个数据库软件领域，时序数据正在异军突起，受到的关注越来越多。市场上不仅有像 IoTDB 这样的原生时序数据库，也有其他类型的数据库产品在拓展时序数据方面的功能。据 IDC 预测，到2025年，时序数据的规模在所有类型数据中的占比将达到30%。这是一个即将到来的巨大市场。当趋势来临时，所有人都想蹭到红利，但只有足够专注的人才能乘势而飞。

        与乔嘉林的这次深度访谈恰巧发生在端午节期间，我们得知团队仍在紧锣密鼓的进行新版本的迭代。乔嘉林从读博开始就专注于 IoTDB 的研发，他对工业场景的实际需求、对各种数据库的技术细节、对开源社区的建设和运作都如数家珍。他的语言富有逻辑，洞察深刻，这也许就是出身于高校的技术创始人的特点——踏实严谨而又敏锐创新，饱含情怀而又不忘初心。

        IoTDB 项目也让我联想到了另一个知名大数据开源软件 Spark。同样是诞生于高校，Spark 从加州大学伯克利 AMP 实验室走出，也同样经过 Apache 的孵化，成长为全球顶级开源项目。如今从互联网公司的大数据实时计算推荐平台，到金融公司的实时风控平台等，Spark 的身影随处可见。其背后的商业化公司Databricks，由 AMP 实验室的多位 Spark 创始团队成员联合创立，现在也已成长为估值数百亿美元的企业。Spark 选择了开源，与社区共享共建的方式让 Spark 快速获得了大量用户基础，而它的商业化也借此取得了成功。

        对于像 IoTDB 和 Spark 一类的基础软件公司，开源的意义不仅在于收获更多参与开发的贡献者和深度互动的用户，也在于获得更多的应用场景，这使得这类基础软件更加具备适用性。而以打磨好产品为基础，通过用户建立口碑，再以安全等功能和运维服务作为付费的入口，开源项目的商业化天然具备PLG的模式，这种在to C领域大行其道的商业模式，目前在to B领域也正得到更多的认可，我也期待 IoTDB 在时序数据库领域能够取得持续成功。

关于我们

        Apache IoTDB——海量时序数据管理解决方案，一款高吞吐、高压缩、高可用、物联网原生的开源时序数据库。从0到1自研时序存储方案、物联网数据模型、低流量数据传输方案，使得纳秒级采样数据写入无压力、TB级数据查询毫秒级、数据存储无损压缩数十倍。核心技术源自清华、自主可控。目前已在国家电网、国家气象局、中航成飞、中核集团、长安汽车、金风科技等企业广泛应用。

        作为全球性开源项目，截至目前 Apache IoTDB 已拥有 215 名贡献者、2.2K Star、703 Forks。我们为大家提供了参与指南，欢迎越来越多的小伙伴助力 Apache IoTDB 项目的不断发展与前进。