苏宇荣：大数据系统软件国家工程研究中心&天谋科技技术专家

观点摘录：

天谋科技团队源于清华软件学院，承办大数据系统软件国家工程研究中心，核心产品为工业时序数据库 IoTDB；该产品具备高吞吐、高压缩、端边云协同特性，曾两次刷新 TPCx-IoT 国际权威榜单，在 benchANT 评测中写入、查询、成本三项指标位列第一；核心技术上独创 TsFile 时序数据文件格式，压缩比提升 10 倍以上，还内置 AI Node 时序大模型 Timer，支持零样本预测、异常检测、数据填补，推理效率领先；目前已服务宝武智维、中车四方所等龙头企业，覆盖 200 + 工业企业，涉及钢铁、能源、交通、制造等多个领域。

发言内容：

各位老师、各位专家、各位来自未来物联网的开发者们，大家下午好。

我是来自大数据系统软件国家工程研究中心&天谋科技的苏宇荣。先谈一下今天来这里的感受，我听到了各位老师讲生态、讲布局、讲技术、讲未来，收获非常丰富。我作为一线开发者，想给大家带来一些不一样的东西。

第一，从技术的视角看看工业IOT的发展趋势。第二，工业时序数据库这两年经历了什么，我们的思考是什么。第三，我们作为一个从高校出来的开源项目，进行商业化，它的进展是怎样的。这三点聊完之后，我想大家也会有一个答案。

先介绍一下我们的团队，然后讲讲工业场景IIOT的演进历史，以及对于数据库、时序数据库的构建思考，最后会有一些典型的用例。

一、团队介绍

我们团队源于清华大学软件学院，自成立之初便专注于工业数据与工业时序相关领域。2010年开始接触我国的气象数据等时序数据。后面承办了大数据系统软件国家工程研究中心。我们比较有名的开源产品是Apache IoTDB，近两年在做一些时序大模型的工作，也在做数据处理、应用开发相关的低代码平台。

我今天讲的就是其中的工业数据库Apache IoTDB，这款数据库的发展经历了非常长期的孵化，可以总结成从开源来，又回到了开源去。最开始我们团队是在做气象大数据，是一个863计划的课题，用的是Apache Cassandra去管理数据，当时Cassandra已经是一个很牛的技术了，但管理起来依旧发现有瓶颈。后面我们就自己去研发底层的文件格式，最后慢慢发展成时序数据库。最终在2018年，我们推向了Apache开源基金会，当时是Apache基金会里唯一一个时序数据库软件，2020年成为Top-Level Project（TLP），后面成立了公司，相当于完成了从学校到开源商业化的整条路径。

今天，IoTDB有几个关键词：高吞吐、高压缩、高可用，它是物联网原生的，支持端边云协同的时序基座。

最近两年，我们做了一些事情，大家知道TPC榜单是比较有名的，我们在TPCx-IoT榜单上两次登顶，超过AMD、戴尔、韩国TTA等知名公司，也获得了央视报道。还登录了BenchANT榜单，这是由有很多数据库系统参与的评测，采用固定的数据集、固定的硬件，大家公平地竞争。从学校走出来我们积累了海量的国内IIOT用户，主要集中在航空航天、化工、钢铁等产业。

二、工业场景演变

机器设备不仅是时序数据的生产者，也是时序数据的消费者。时序数据是各种机器产生的数据，以前只是存起来，现在除了存起来还要展示出来，放在IT域和工程师一起做联合决策，决策之后再把信息下发到工业现场，形成一个所谓的价值闭环。也就是机器设备既是产生数据的主体，也是消费数据的主体，既要有EMQ的连接，也要有存储，二者放在一起才能形成真正的价值闭环。

在IIOT里，和传统认知的IOT有什么不同？从数据流的典型架构中可以看到，中间有一个网闸，这是生产和控制隔离的场景，很多To G、To B的企业内部就做了这种区分。左边的是生产网，生产网有很多数据产生，但这些数据不会全量流到最后的控制网，左边的数据是筛选性的、单向的从左到右，右边根据筛选出来的数据做决策和报表，这样既维护了生产区的安全，又能使得右边进行一些数据使能。这就需要有些数据库和中间件的产品承接左和右的数据装载和数据连接，这就是IOT或者IoTDB的核心业务场景。

我们看到了场景之后也在想这些年IOT最大的变化是什么。我总结了几个点：

第一，数据的存，这件事情很好解决，就是数据资产保护。后面怎么用是我们这两年思考的。

第二，之前存数据的地方可能就是一台服务器。现在随着资产集中管理的要求，还有各种IOT公司他们会有汇聚的要求，将会是一个从1到N的汇聚过程。底层原理就是数据变得越来越值钱，并希望它流动起来。

第三，希望这些数据到了云侧，能够自动产生价值。因此从2022年开始，我们给时序数据库增加了数据处理、对齐、填补、数据同步、批量实时的AI分析能力。

三、新型工业时序数据库

今天我们围绕需求背景进一步展开谈谈新时代的IOTDB应该是什么样子。我给了三个关键词，分别是File、DB以及AI。

首先是第一个关键词“File”。我们从IoTDB里剥离了TsFile项目，把它贡献给了Apache基金会，实际上我们已经贡献了两款项目给Apache基金会，一个是标准的文件格式TsFile，另一个是核心产品时序数据库。今年在时序数据库里又新开源了一款AI Node原生节点，希望在数据库里能使用原生AI的能力，让用户方便进行推理、预测。文件则是贯穿始终，既可以在边侧生产文件，也可以放在数据库里处理文件，最后可以用AI基于文件进行数据的挖掘，真正贯穿整个端边云。

关于文件，它的优势是什么？我介绍两点：

第一，压缩比很高，传统的TSFile对普通的时序压缩，在有损情况下可以达到100倍，无损的情况下也接近10倍，与CSV和传统数据库相比，空间节省可以达到5-30倍。

第二，开放架构的基石，这和王总所说的架构并不矛盾，它们的体系不一样，他们的是协议，我们是协议之下的数据，TsFile可以作为协议之下的payload，利用高压缩比、可搬迁、直接解析的特性，以及利用它和生态连接的特性赋能价值。这也就是文件的第二个优点，开放。

举两个例子，展现文件在离线场景和在线场景上的优势。

第一个是离线场景，例如国产大飞机试飞数据的处理，其实国产大飞机的试飞数据并不是实时下载的，因为飞机上去之后，可能会遇到网络不好，带宽不够的情况，要等飞机落地之后连接到有线或者无线网再进行处理。而TsFile和IoTDB具有天然的处理优势，可以在机载上生成TsFile文件，落地之后直接挂载在盘上，让IoTDB主动吸取，整个过程只需要一次配置，不需要其他操作。离线数据在某一场景下可以提升25倍的性能，耗时从4小时到10分钟，可以支撑大量飞机的试飞。

第二个是在线互联场景，是之前我们在和宝武智维合作的一个场景，宝武智维的架构遵循了典型的端边云架构。最下面的是各种厂，比如铝箔厂、包装厂，厂里面生产好的数据可以是TsFile，也可以是其他数据，但最终可以转成IoTDB。厂和厂之间再做汇聚，比如以地点为单位，像是宝山厂，这是第一层汇聚。再往上一层的汇聚，是集团一个大的云平台，把全量的集团数据做一次汇总，每层数据都有自己的作用。IoTDB在其中起到的是端边云的协同，数据总线的作用，IoTDB不需要配置任何中间件，可以用一个SQL执行端到端的数据同步，而它的底层正是文件。

接下来是第二个关键词“DB”。这两年有两点关于这方面的洞察：

第一，双模型。这源自我们对工业现场的思考，我们发现，在工业现场的这些同事，他们接触的协议很多都是老外定义的，更像是一个目录结构，像一个树形或者文件夹结构，是一个树形模型，由点和字符构成。但是对于正常公司里的IT同事，他们做预警、分析、给领导出报表，更习惯操纵Excel，或者专业一点说叫表模型。传统的IOT数据量又大，价值又少，这样一倒腾，ETL的价值不仅会衰竭，成本还高。能否用一套数据完成两个模型的分析？当然可以，目前已经成为现实，我们在IoTDB 2.0时代推出了这套思维方式，希望大家可以试用。

第二，自2022年起我们一直在构建时序的特色能力，比如降采样、时序分段、数据补齐与修复。今年，我们又提出了嵌套查询、UDF、趋势探索能力，都内置到了IoTDB里面。值得一提的是，IoTDB的函数框架都是以一种开放式的架构提供出来的，有一个开源的SDK，吸引了大量的社区开发者，他们想到什么需求就往里填一个函数，所以有很多函数是社区开发者基于对场景的理解无私贡献的。这也体现了开源吸引社区治理、共建回馈价值的能力。

最后是第三个关键词“AI”。最近几年，LLM这件事情很火，什么都想往LLM里塞。但语言模型上下限有限，时序数据长度又很长，塞进去能否理解到数据里的偏差，我们团队对此进行了探索，使用LLM处理时序数据，最终发现在工业领域效果比较差，至少对原始数据的处理效果比较差。我们在想有没有更好的解决方案呢？我们就采取了软件工程里通用的一种思维方式，就是从通用到专用，提出了时序大模型。

这一方向由我们清华团队持续深耕，并推出了新一代生成式时序大模型Timer。输入一段时序，它就会推出一段时序，基于这种方式，我们就可以使用它自己预测生成的时序，和现实的情况或者未来的数据做对比，从而能够实现预测、告警等功能。

Timer取得了很多学术界Benchmark的成果，但这并不重要，最终，我们还在想一个问题，有了这么好的模型，如何去使用？生态是会影响开发者使用、商业化落地的gap，其实易用性也是一个gap，大家都知道有大模型，有数据库，但我们在数据库里存数据，如何让模型去用呢？为了解决好这个问题，我们今年推出了一键微调功能，希望在数据库里也能对模型进行微调，使用模型进行推理，不需要再像传统方式一样把数据做一次导出，写很多代码做预测。希望开发者能实现“手可摘星辰”的目标。

今年，我们在时序数据库中提出了传统节点之外的AI Node节点，并进行了开源。可以支持模型的自定义装载、模型的微调训练以及模型的推理。以前在库外做的模型训练、微调工作我们已经帮使用者做完了，现在，在AI Node中就包括了模型训练、推理、管理的能力。用非常简单的一句SQL语句就能形成自己的工业模型，这样可以让在前线战斗的IT工程师享受更多自己的时光，不需要为每个设备、每个测试点去写他们自己的规则。

AI Node有哪些能力？经过进一步的包装，实现了数据质量的画、检、修函数，都是基于模型预测做的进一步包装。另外，支持模型微调和推理一体化能力，避免了传统数据库从库里调数据，再把数据写回去的一系列ETL流程，一定程度上也解决了AIOT领域资源少、数据量大、大家又不愿意付出成本的痛点。

四、典型应用案例

我们通过开源或者间接开源的方式服务了很多平台，包括大家知道的云厂商、服务商我们都有合作，构建他们自己的时序数据库。

第一个向大家介绍的客户是宝武智维，这是一家传统的端边云企业。IoTDB进入之前，他们用的是基于Hbace生态的openTSDB，我印象比较深刻的一点是我记得他们有一个集群有16个节点，当时他们的运维同学只能做一件事情，遇事不决就重启，重启还不一定能启来。当时我们推荐他们把一部分数据抽出来用IoTDB，这件事情最终推动他们做了全集团的替换。当时一台IoTDB的效果，在单机情况下管到了16台设备，当然后续使用了分布式的方式。后面发现，他们也有端边云的需求，之前是用卡夫卡搭的一套体系，涉及到数据的读、写、多个进程的连环调用，很费劲，也很耗费资源，运维人员也不愿意用。用了IoTDB之后，彻底解决了端边云协同的问题。整体应用下来有两个好处：一是资源上确确实实降下来了，二是端边云协同方面确确实实简单了。这一套体系已经应用于21个大基地、27个子平台，公司里有近1万个客户在使用。

第二个向大家介绍的客户是非常早期的开源用户，早在IoTDB 1.0版本发布前就已开始使用。他们最初选择IoTDB的核心原因是 TsFile具备强大的压缩比，此前他们曾使用另一款时序数据库，海量高频数据存储后体量极为庞大，累计达 200TB。在未部署集群、仅依赖单台服务器的情况下，要承载 200TB 数据难度极大。最终他们通过TsFile完成数据迁移，将数据存入IoTDB后，不仅存储量大幅降低，查询与读取效率也较之前有了明显提升。这充分体现了文件所带来的价值。

最后做一个总结，今天我们从技术与开发者的视角，分享了对AIOT领域的洞察，以及File、DB、AI如何在全栈协同的流程下为大家带来优势和体系。并且希望感兴趣的开源者一起拥抱开源、参与开源。