2022 IoTDB Summit：用友郭关飞《用友在 Apache IoTDB 应用与生态建设方面的探索与实践》

12 月 3 日、4日，2022 Apache IoTDB 物联网生态大会在线上圆满落幕。大会上发布 Apache IoTDB 的分布式 1.0 版本，并分享 Apache IoTDB 实现的数据管理技术与物联网场景实践案例，深入探讨了 Apache IoTDB 与物联网企业如何共建活跃生态，企业如何与开源社区紧密配合，实现共赢。

我们邀请到多维计算与时序数据库专家，用友高性能多维数据引擎和时序数据库负责人郭关飞参加此次大会，并做主题演讲——《用友在 Apache IoTDB 应用与生态建设方面的探索与实践》。以下为内容全文。

目录

用友简介

应用案例

社区贡献

总结

各位朋友们，大家下午好，很高兴大家能够在这里分享我们用友在 Apache IoTDB 的应用以及生态建设方面的探索以及所做的实践，我是来自用友的郭关飞。

今天下午分享的内容主要分为四个部分，第一部分是我们用友的简介，当然还包括我个人的一些简介。第二部分是我们在应用方面的一些案例。第三部分是用友在社区方面的一些参与的活动以及我们对社区做的一些回馈。最后是我们这段时间在和社区合作方面的一些心得和体会。

01

用友简介

首先，我先介绍一下我们用友，用友是成立于 1988 年，我们主要是做企业云服务以及企业相关的一些服务的工作。我们的目标就是想做全球领先的软件企业的服务商。我是来自用友的郭关飞，我目前主要负责用友时序数据库的研发，在做时序数据库之前，我其实做的是我们用友的多维数据库，目前我专职在做时序数据库这块的研发工作。

02

应用案例

下面的应用案例，我想讲一个在我们用友云上的一个使用 IoTDB 的一个具体案例，这也是我们最近实施的一个案例。正好这个案例我们其实也是做了一个时序数据库的替换。

这个服务是什么呢？我们做的这个项目其实是我们用友云上面的一个 APM 和用户行为分析的产品。什么叫 APM？可能做互联网的同学比较了解，当然我这里也简单科普一下，APM 其实就是应用性能的监控，云上的一些应用因为它其实有好多的监控数据。但是如果没有 APM 的话，万一当云上的服务出现问题，比如说有性能问题或者有一些故障的时候，其实很难定位，所以需要 APM 的服务。而友云音就是这样一款 APM 的服务。

这个是我们友云音的一个架构，这张图看起来比较复杂，我也就不一一介绍了。我们这里头只要关注一下友云音在时序数据库方面的使用的一些东西。友云音在时序数据方面之前使用的是 OpenTSDB 进行存储，同时它里头一些机器分析也是用 OpenTSDB 进行查询。那我们在这个项目上我们要做的主要事情就是使用 IoTDB 来无缝的替换友云音使用的 OpenTSDB。

为什么要做这个事情？其实是因为我们发现 OpenTSDB 在友云音的实际使用中有一些不足，当然了这个不足可能大家也都碰到过。首先就是它的查询性能比较差，其次就是它的写入性能也不高，最后当然是它的资源占用成本比较高。OpenTSDB 在实际项目中它的效果确实不是很好，这里头我们可以有一些简单的量化数据，比如说它的写入性能，它的写入性能其实和 IoTDB 相比要差 6 倍以上，而它的查询性能也要差 5 到 10 倍，而在资源占用方面也是在两倍以上的差距。当然了这几个数据其实是我们在项目实施之后实际测出来的结果，有点从结果反推原因的意思，但实际上我们大家在项目实施的时候肯定是要先做一些技术的调研对吧？但是相信大家做技术调研的时候也能得出差不多的结论。

下面是我们在做 IoTDB 来替换 OpenTSDB 的时候，我们做的第一步，就是需要对两个时序数据库中的元数据进行映射。左边这个图是 OpenTSDB 中的一个数据结构，但大家都了解 OpenTSDB 中的数据其实是存储在 HBase 之上。所以这也意味着就是说如果我们使用了 OpenTSDB，其实我们底下还需要带一个比较庞大的 HBase 的集群。所以大家看到就是说 OpenTSDB 的数据，就是它左边的 Row Key 这一部分它是由好几部分组成，比如说开始的这部分是它的一些 metric 的信息。然后第二部分黄色的其实是时间戳相关的信息。后面的这些部分就是它的一些 tag 的一些信息。把它怎么转化到 IoTDB 的模型上面呢？我们可以看到就是说，它的 tag 我们其实是需要映射到路径上，然后它的一些 metric 的一些信息，我们其实是要转化成不同的时间序列，然后把它的这些值存储到里面，这是一个简单的映射关系。

第二部分就是我们需要对元数据建模，因为像友云音我们要用 IoTDB 的话，实际上因为 IoTDB 它的一个元数据模型其实是一个树状的模型，而不是像 OpenTSDB 那样，它其实是一个矩阵式的存储。所以我们在远程区建模的时候，需要做一些根据 IoTDB 的这么一个模型的特性，我们需要把它建成一个树状模型。因为我们在 OpenTSDB 里头，其实存储了好多应用的监控以及服务的监控信息。比如说我们主机的一些 CPU 的利用率、网络的利用率、GVM 的内存使用情况、堆的内存使用情况以及其他的一些这些监控相关的信息，所以我们这个模型其实也是按照监控信息的分门别类，把它们分别建模到我们的模型树里头。当然实际上在建模的时候，我们从前面这张图可以看到，我们其实还需要考虑它里头的其他的 tag 信息，比如说我们可能有地域的信息以及我们机房的一些信息等等，都需要做在这里头。

但是在建模的时候其实我们是有一点需要注意的，就是说在 OpenTSDB 里头，因为它的 tag 其实是直接存储在数据的 Row Key 里头，所以它的 tag 其实是无所谓顺序的，它在查询的时候它可以随意指定查询的顺序，这些 tag 的顺序是无所谓的。而在我们 IoTDB 里头，因为 tag 信息我们实际上是建模到那个路径里面，所以我们还需要做的一件事情，就是说需要把这些 tag key 的顺序需要指定。那我们项目实施的时候，为了不引入其他依赖，我们把 tag key 的顺序也用一个单独的，在 IoTDB 里头我们把它单独存储了起来，这样的话我们在使用的时候就是我们只依赖 IoTDB，不用再依赖一个第三方的其他的一个数据库或者一个其他的存储方面的信息。

下面这个是我们对 IoTDB 的一个 SDK 的设计。这个 SDK 主要是干什么？其实主要是适配我们友云音的项目的，就是说在友云音的时候，就是因为我们要访问下面的时序数据库，其实是友云音之前是直接访问的 OpenTSDB，但是我们为了做到就是让它无缝的能切换 IoTDB，所以我们开发了一个 SDK，这样的话应用我们也能屏蔽一些对 IoTDB 的访问细节。同时我们在里头其实也可以做一些类似于分流或者透明迁移方面的工作，做起来就会更加容易一些。

在 IoTDB 实施的时候，其实我们在项目里还需要解决一个问题，就是说我们是存在一段时间，数据要同时写入 IoTDB 以及 OpenTSDB，那为什么要做这个事情呢？其实做过项目实施的同学大家可能都知道，就是我们要做一个这么一个底层时序数据库存储结构的这么一种替换，实际上我们不能太激进，所以我们流量是逐步切过来的。所以其实在流量全部切到 IoTDB 之前，我们需要把数据同时写入到 OpenTSDB 和 IoTDB ，那在做这件事情，其实我们是从业务应用这一块做文章，然后我们把所有的应用数据同时写两份，一份写到 IoTDB 里头，一份要写到 OpenTSDB 里头。

在这里头其实我们需要解决有一些性能方面的问题，你比如说在实际应用的时候，我们发现就是说我们需要时间序列，我们需要动态创建。比如说我们写的一些值，因为我们开始的时候是没法从系统里拿到所有的 tag 组合的。有可能我们在采集的数据上来的时候，我们发现里头会出现新的 tag 的组合。而按照我们刚才设计的那个 device model 那一块的设计方案，就是这些新的 tag 组合其实对应到 IoTDB 里头就会产生新的时间序列，所以这里头我们其实会用到就是，我们会动态的去创建时间序列。我们在插入数据的时候需要动态创建时间序列，而这个动态创建的过程，这是 IoTDB 提供的一个非常好的一个特性，但是在实际使用中它是有一些性能问题。

你比如说我们在动态创建时间序列的时候，其实他每次都需要检查这个时间序列在不在，这个过程其实是有一些性能损耗。那如果像我们现在做迁移的这种场景，我们其实对每一条上报上来的数据都要做这个事情，那这样的话性能损耗就会非常大。所以我们采用的方案就是说，我们把我们 device model 的这些信息我们缓存到自己的应用的内存里头，这样的话每条数据上来，我们只需要在内存的缓存里头检查一下这条时间序列是否存在，如果存在的话我们就直接往时间序列里写。那如果不存在，我们再去动态创建，同时把它再写进去，这样的话我们的性能就可以有一个很大的提高。

下面其实还需要就是说我们数据进到 IoTDB 里头之后，我们其实还需要做一件事情，是什么事情？其实就是我们需要进行查询的适配，如果不做查询适配的话，我们其实是没有办法从 IoTDB 里头存储的数据里头查询出结果，所以我们在这做了一个 IoTDB 的查询适配。那这查询适配其实说起来也比较简单，就是我们在应用上做了一个流量的开关，这个开关可以把某些满足条件的流量把它的查询导入到 IoTDB 里头，而把另一些流量还是像原来那样，让它直接从 OpenTSDB 里头查。那这样的话有一个好处就是我们其实是类似于做了一个灰度环境，以及其实是有一个AB测试的环境，那这样话我们的流量其实是逐步的从小到大切过来，当我们用小流量验证没有问题的时候，我们逐步把导向 IoTDB 的流量增大。如果验证继续没有问题的话，我们再放大，直到最后所有的流量都切到 IoTDB 上，一直到这个阶段，我们其实就完成了用 IoTDB 替换 OpenTSDB 的这么一个过程。

当然了这块其实还涉及到一块比较重要的问题，就是历史数据的迁移。历史数据的迁移其实主要涉及到就是我们要从 OpenTSDB 里头把它之前一直积攒的历史数据都要迁移到 IoTDB 里。我们其实也试过好几套方案，在这里头我们也碰到过一些问题，主要是有三个比较难的问题，或者说我们有三个比较影响迁移过程的问题。

第一个就是从 OpenTSDB 里头把数据拿出来，我们最开始的方案就说是直接查线上的 OpenTSDB，这样发现有好几个缺点。第一个就是说对线上的查询压力很大，导致在流量没有完全切换完之前，就是说导致之前依赖 OpenTSDB 的那些线上服务，它的查询会很慢。同时直接从 OpenTSDB 里头线上的服务直接查的话，这个查询过程也很慢，这是它的两个缺点。怎么解决这个问题呢？后来我们就是说经过实际测试发现，就是这个方案其实确实太慢了，那我们怎么办呢？我们所以就是搭建了一个离线的 OpenTSDB 的集权，然后我们把生产上 HBase 的里头的那些时序化的数据，那些文件我们直接通过 copy 的方式 copy 到离线的 HBase 里头，然后在离线的 HBase 上，我们通过 OpenTSDB 的接口，然后我们去把它数据读出来，然后再通过我们的数据的转换直接转成 TsFile 这么一种 IoTDB 能识别的数据格式。

这样的话，其实我们又面临到另一个问题，就是说我们直接从 HBase 里头查数据的时候，其实它的速度又是一个限制，因为它两年的数据，在我们友云音里头，它两年内的数据其实说大也不是很大，大概有两个 T 左右。但是实际上我们查的时候发现，一个线程查起来会非常慢，所以我们在这里头采用了一个策略，就是把 HBase 中的数据按照时间分区给它分成了好多段，在不同的时间段里头我们使用一个线程去查询，这样的话我们就可以多线程的从 HBase 里头把它的历史数据查出来。

第三个我们在性能优化的点，就是说我们查出来的这些 HBase 中的数据，我们不是直接通过 sessionAPI 的方式插入到 IoTDB 里头。为什么不这样做呢？就是说我们为什么要采用直接写 TsFile 的方式去做？其实这也是我们刚要解决一个很重要的问题，还是性能问题。那为什么要采用写 TsFile 的方式呢？一个是因为我们之前就是在开始 IoTDB 的开源项目的时候，我们其实很深入的研究过存储层的这一块代码，我们对 TsFile 这块代码也很熟悉，所以自然而然的就想到了说，我们直接把从 OpenTSDB 中查询出来的数据直接写成 TsFile 的方式。同时因为 IoTDB 其实也有一个工具，可以直接把我们的 TsFile 直接就 load 到 IoTDB 的 server 里头，变成它里头的数据。这样的话比我们直接从 OpenTSDB 查出来，然后再直接 insert ，通过 sessionAPI 的方式 insert 到 IoTDB 里头，这样速度会快得非常多。所以最终我们采用的方案就是从生产的 HBase 里头把数据 copy 到一个离线的 HBase 里头，然后在这个 HBase 上我们通过多线程的方式然后去查询。同时我们每个线程把查询出来的数据直接写成 TsFile ，最后通过 IoTDB 的 TsFile load 工具，把我们生成的 TsFile 直接 load 到 IoTDB 里头。通过这么一套流程，我们整个数据的迁移就会变得非常快。

当然最后一点还要解决的就是说我们其实在迁移的时候，它其实还有一部分增量的数据对吧？所以这部分增量的数据那处理起来就比较简单了。因为我们迁移的话，其实是先把历史的大量数据都迁移过来，最后这点增量数据，我们直接就很容易的通过我们直接通过线上独线的生产 HBase 的方式，我们直接就把它迁移到生产的 IoTDB 里头了。但这里头其实我们在做项目的时候，我们其实还发现 IoTDB 有一点小 bug ，我们其实也修复了，它具体什么 bug 呢？其实就是在我们把数据写到 TsFile 里头不同的时间序列的时候，它当时的哈希值计算其实稍微有点问题，就导致我们写出 TsFile 有就是格式不是很对，最后无法 load 到生产的 IoTDB 里头。后来我们也修复了这个 bug，然后顺利的把数据的迁移做完了。

这个是我们最终实施出来的效果。整个从数据的存储的资源占用来说，我们在 OpenTSDB 里头，我们的数据大概其实是有两个 T，但是我们把这两年半的历史数据迁移到 IoTDB 里头，其实它大概只占了 800 个 G，存储的成本能节约一半以上。同时硬件上，之前我们 OpenTSDB 加 HBase 其实是有 5 台机器，都是 8C 16G，大概 5 台机器。那我们实际上迁到 IoTDB ，其实我们用16C 32G 两台机器就够了。那为什么用两台？其实是因为我们要做高可用对吧？那实际上就是说按照我们 IoTDB 的估算公式，其实 32G 内存我们是留了一定的富余的，为以后做其他的更复杂的计算，做一些准备。然后右边这个图其实是我们最终的一些查询速度的对比。大家可以看到，这里头我们切换到 IoTDB 之后，从时序数据库里头查询的速度，我们 IoTDB 比 OpenTSDB 要快出 5 到 10 倍。

上面就是一个我们在友云音的项目里头使用 IoTDB 来替换 OpenTSDB 的一些实践，下面这部分和大家分享一下用友在社区方面参与的一些活动以及贡献。

03

社区贡献

简单总结一下，我们在社区方面总共其实主要是做两件事情，因为我们用友从和社区合作大概是从今年开始，从今年开始我们也是这两块工作，我们在社区方面的两块，一块是对于一个新特性的一些研发，还有一块是我们目前因为我们在项目上实施了 IoTDB 我们做了好多工具。在新特性这块主要第一个就是我们做了一个就是新的路径模式的支持，这个路径模式大家如果经常在社区里看的话，其实也可以看到，就是之前因为那个社区对路径模式也有很长一段时间讨论，正好我们在项目中也需要用到了这么一个特性，所以我们顺手就把它做了。还有一个就是比如说我们可以支持不同的存储组，然后它使用不同的虚拟存储组的数量，为什么有这个需求？其实也是项目中遇到了，当然我们也把它做了一下，其他的我们也都是在项目中碰到的一些事情。

然后在周边工具这块我们其实也是目前做了五个工作。一个就是我们对 IoTDB 做了一套基于外部的管理系统。其次就是我们其实做了一个 IoTDB 的数据备份的工具。还有一个是我们做了一个 TsFile 的管理查看以及管理工具。再然后就是我们其实做了一个数据迁移的工具。还有一个是我们做了一个把数据类型进行转换的工具。这些其实都是从实际从项目上衍生出来的需求，后面我一一的把这几个工具和我们做的一些事情和大家一一分享一下。

首先就是这个新的路径模式，这个需求是怎么产生的呢？其实就是说我们还是在做友云音那个项目的时候，我们发现在做迁移的时候，其实有时候需要用到一个新的模式，而当时的 IoTDB 其实没有。那这个模式是什么呢？就是说我们其实是需要一个零层或者多层的这么一种表示，而当时我们其实 IoTDB 支持的是 * 和 **，那 * 是什么呢？* 其实是它只能表示一层，而 ** 表示一层或多层，但恰恰没有零层或多层。所以我们当时开始的时候想的比较简单，说我们扩展一种简单的语法支持零层或多层，我们所以开始想过的一种用三个 *，因为一个 * 和两个 * 已经被占用了，所以我们就用三个 *。那后来在社区讨论的时候，大家各抒己见，可能觉得还是要更加贴近于正则这么一种表达，所以最后我们最终形成的结论就是这么一种类似于正则的表达方式。

大家看到我们其实有几条规律，一条就是 *。然后我们其实主要就是这么一个形式，就是 *，然后里头一对小括号，里头表示一个开始多少层，后面多少层，我们开始这个层是包含的关系，后面 N 的这个层是不包含的关系，后面的其实都是开始和结束这么两种的一种简化的形式。当然我们想做的 *** 就是 0 到多层这个，其实我们可以看到在第四条已经有所表示了，我们给它就简单的把它用 *** 这么一种类似于简洁的方式来表达了。比如说我们之前的 * 和 **，在我们这里头也可以有一种很正规的表达，当然也可以用我们现在已经实现了这种简洁的表达方式。

下面我们简要介绍我们的 IoTDB 的管理工具。大家看到这个是我们目前基于 web 界面来实现的一个 IoTDB 的管理工具，这里头其实主要就是对时序数据，对 IoTDB 的一些比如管理，比如说我们的连接的管理、用户的管理、权限的管理以及我们查询，然后以及一些简单的监控。当然我们这块其实还做了一些工作，就是对 IoTDB 的测试，你比如我们可能有些用户其实有一些很大的需求，是想把他的数据从其他的时序数据库，比如说 InfluxDB 或者 OpenTSDB 或者其他类似的业务数据库对吧？比如说 MySQL 迁到 IoTDB 上，那时候它其实需要写大量的测试用例，所以我们这里头其实还实现了一个测试管理的功能，方便用户去管理他自己的测试用例。

同时我们能实现就是说连接验证的数据以及连接我们待测试的 IoTDB 数据。同时对我们的一些业务脚本进行验证，同时和自动的结果进行对比，我们实现了这样的一些功能。这块就是我们其实是一个简单的时序数据查询的界面，我们查询出来之后我们可以对时序数据进行简单探索，同时对它其实可以进行一些可视化的显示，我这里头就不细讲了。

下面一个工具其实是我们最近正在做的智能科研出来的一个叫 TsFile 的管理工具，这个工具其实也是源自于我们自己在源码学习过程中，我们需要了解 IoTDB 的存储引擎，但是同时就是 IoTDB 其实我们有一个 TsFile 的 sketch-tool 这样的一个工具。但是这个工具就是只是说对 TsFile 的一些结构性的信息尽量展示，但对内部的细节没有办法做展示。所以基于这个需求，可能别的团队在进行 TsFile 的研究以及引擎的研究的时候也会碰到类似的问题，所以我们就萌生了去研发出这么一个 TsFile 管理工具的想法，所以就做出了这么一个工具。这个工具就是跟 TsFile-sketch-tool 的区别，就是它不光能展示一些结构性的信息，同时我们对内部的信息也可以展示。你比如说我们在 Chunk Group 里头包含了多少的时间序列，然后每个时间序列里头有多少配置，这个配置里头有什么数据，然后我们对数据怎么进行查询，这些功能我们都有，这个工具我们目前正在开展的过程中。

然后就是说这个工具其实我们当时做的时候也考虑到，可能有人需要在上面做一些文章，所以我们这个工具当时设计架构就是说有一个核心的依赖包，同时在核心依赖包外面，我们用户可以自定义 UI 界面。像之前我们其实是基于 JavaFX 做的一个 UI 的界面，但这个 UI 界面后来贡献到社区的时候发现，就是说它的协议可能和 APL 的协议不是很兼容，所以我们现在就是基于 CORE 的核心包我们又开发了一个 Web 的 UI，这个 Web UI 是和 APL 协议是兼容的，所以我们目前正在做这一块的事情。而我现在展示的这一块其实也是基于我们 Web 界面做的一个功能的展示。

我们做的第三个工具其实就是数据备份工具，这个其实数据备份这件事情其实是在数据库的运维过程中是很常见的一个工作。IoTDB 其实现在也有一个数据备份的工具，但是现在这个数据备份工具就是说它基于 Session API 做的话有一些问题没有解决，比如说第一个就是有可能我们的时间序列不能超过 1000 行。第二个就是可能导出的 CSV 还有效率的问题，所以我们在实际应用发现就是目前数据工具不是很好用，所以我们自己萌生了一个就我们做一个新的数据备份工具的这么一个想法。我们这个新的数据备份工具其实是基于目前我们比较流行的 pipeline 这么一种模式，大家可能做数据迁移的时候一般也都会用这样的模式。所以其实这个模式描述起来比较简单，就是我们其实是有中间其实是一个 channel，大家可以理解为一个 queue 对吧？然后我们在两边有一个 reader 和一个 writer，这个 reader 其实可以自定义对吧？当然我们这里头其实这个 reader 主要就是读取 IoTDB 的数据，然后 writer 当然我们就可以做一些格式化、格式转换、压缩一些数据的处理过程。

目前就是我们其实支持 CSV 和一个二进制格式，当然 TsFile 这个格式我们目前正在和社区合作，现在正在开发中。我们开始其实支持的是 CSV 和 BIN 这么一个格式。那 CSV 其实就是普通的格式，但 CSV 就是他用户易读也比较简单，但实际上在实际生产中它不大可能使用，因为实际上我们要备份的数据可能会非常大，比如说像我们刚才那一个简单的两年内数据，大概有两个 T，你要写 CSV 基本上不太可能，所以我们就设计了一种二进制的格式。

大家看到这是我们自己设计的二进制格式的里头的一些详细情况，现在因为时间关系我就不具体介绍了。但是因为二进制格式我们自己定义的，在实际使用中就是你仅仅作为备份是可以满足的，但实际上如果考虑到比如说我们备份还要恢复的话，我们自定的二进制格式其实稍微就有一点不那么好用。所以目前我们跟社区沟通之后，我们计划再支持一种就是说我们直接把它导出为 TsFile 格式，刚才我们在前面做那个 OpenTSDB 数据库的替换的时候，我们其实也讲过，TsFile 这种格式有一个很大的优势，就是说如果我们备份完了之后，其实我们是可以直接再 load 到 IoTDB 里头的，那这样的话就是我们其实中间会减少一次数据转换的过程，我们数据恢复的时候会效率非常高。

第三个就是我们现在做的一个数据迁移工具，大家看到这个工具其实和前面的那个数据备份工具的架构有点像，但实际上技术实现不太一样，就是我们实际是基于现在阿里的那个 DataX Framework 来做的。那为什么基于这个？就是这里头其实也有一点小故事，主要是因为这是两批人做的，因为我们里头有两个小组，这是两拨人做的，所以现在就是虽然技术架构是统一的，但实际上具体的实现现在还没有统一，后面就是我们可能在社区里头，在社区推动一下，我们可能会让这两个工具的技术架构把它统一起来。

这个是我们数据迁移工具做的一个数据格式转换。我们做这个数据迁移工具其实也是应项目的一个需求做的，这个其实跟前面的工具一样，其实它也有几种方案，就是说我们开始的时候是想着直接从 InfluxDB 里读出来，然后也是通过 sessionAPI 写到 IoTDB 里头。但实际上这个方式还是之前的问题，它的性能比较差。所以我们现在就是采用的方案，就是说通过从 InfluxDB 里头直接把数据读出来，然后通过 DataX Framework 的框架，然后我们直接把它写成 TsFile ，最后通过 TsFile 的 load 工具，我们直接 load 到 IoTDB 里头，这样的话能兼顾效率以及速度。

最后这块我们其实还有一个就是修改时间序列的类型。这块其实就是说为什么会产生这个工具？其实也是项目上的实际需求催生的，因为实际上我们在项目用的时候，会发现我们可能开始对某些时间序列设置的时间类型它不是那么的恰当。在我们项目上线一段时间之后，有可能发现，我可能需要把时间数据、时间序列的类型改成另一种格式，这个时候我们就产生了对线上的时间序列的数据类型进行转换的这么一个需求。现在其实没有这么一个好的转换工具，所以我们在开发的这个工具的时候，因为我们之前对存储引擎的源码做过研究，大家可以看到之前的工具都是直接写 TsFile，所以我们做这个工具的时候，我们也想到就是说你既然要转类型，我们就直接从现在的 TsFile 里把数据读出来，然后把需要转的时间序列的类型，我给你转成新的类型，然后再写成新的 TsFile 这样就可以了，然后基于这个思想，我们就产生了这么一个工具。

实际上在这里还有好多优化的空间。你比如说我可能我们需要转换数据类型的时间序列是少数，而不需要转化的是多数对吧？那这个时候如果把所有的时间序列都到内存里都做解压解码，然后再转化类型、压缩、编码，这样的工作它其实就比较是一种浪费。所以我们在这里头其实有一个提高效率的处理，就是说我们只把需要进行数据类型转换的这些时间序列对它做解压解码、类型转换以及压缩和编码。但是对于不需要的，我们相当于直接在内存里头给它过一下，从 TsFile 读出来再直接写到 TsFile 就可以了，经过这样的一个优化，其实这个工具的效率会非常高。

04

总结

最后一部分是我们在做开源的一些总结。这里头其实我简单画了一个状态转换图，因为大家都是搞研发的，所以我也用研发的语言来说这个事情。就是说因为我们也是从 2022 年开始，然后深度参与到 IoTDB 社区里头的，所以我觉得从我们这段时间的经历来看，首先就是说我们首先还是需要去学习使用它，那怎么使用？其实就是你不光学源码，同时我们还要在实际的项目中去应用，只有在项目中应用，我们才会发现好多新的需求。像前面我们介绍的我们做的那些工具以及对社区的一些新特性的贡献，其实都是我们在项目的应用中发现出来的一些，我们把这些回馈到社区里头，然后变成 IoTDB 的新特性。同时我们因为毕竟是企业，所以我们还要基于开源社区做一些创新性的工作，所以我们可能把一些新想法我们贡献到开源社区里头。然后同时就是说在开源社区里头，我们把它孵化成之后我们再吸收进来，做到我们的商业创新的版本里头去，这是我们目前在开源的模式上我们采用的一个路线。

最后是我们大概这一年左右，我们在做开源的一些心得体会，当然这是我们一家之言，大家可以跟我们一起讨论。第一个就是因为我们肯定要研究源码，我们做开源肯定是要研究源码，但我觉得光研究其实没有用，还要进行高频的分享。那高频到什么程度呢？当时我们在研究源码的时候，要做到至少每周一次到两次分享，我们同时分成好几个小组，比如说我们研究存储引擎的小组，研究查询计算引擎的小组，我们每个小组每周至少得有一次分享，而且不同小组之间还要有穿插的交流，这样的话那每个人都知道别人在做什么，同时对别人做的工作也有一个比较深的了解。

同时就是说我们要在项目中实际去应用我们的 IoTDB，同时在应用中我们会发现问题，我们同时还要解决这些问题。同时我们把解决问题的方案形成一些通用的解决方案，回馈到社区里头。那最后其实我们还要，就是说我们在社区里头其实要进行比较积极的参加社区的活动，比如说现在 IoTDB 社区就有很好的双周会以及线下的 Meetup，这些活动我觉得大家还是要积极的参加。参加这个有一个好处，就是我们可以了解 IoTDB 的最新进展，你比如说像双周会上，其实对每两周的工作我们都会做一个简要的总结，以及对于一些别人的方案或者别人做的一些工作我们还会有一些展示，这样的话方便我们去了解社区的最新进展。同时我们还是要对社区有所回馈，我们要积极参与形成新特性的开发，其实这样的话也是我们开源和商业模式的一种很好的方式。我们把新特性的开发贡献到社区，让大家去试用，等孵化成熟之后，其实公司可以把这些新特性吸收到自己的商业版本里头，这样的话我们就可以很好的做到一个开源以及自己商业创新方面的一个兼顾。

好，那我今天的分享就到这里，谢谢大家。