大家下午好，我是来自 IoTDB 社区的田原，然后今天跟大家分享一下 IoTDB 在车联网和智慧车厂场景下的一些应用实践。首先做个自我介绍，我毕业于清华大学软件学院，然后读研期间也获得了北京市的科技进步一等奖，目前是 Apache IoTDB 的 PMC member，在 IoTDB的 GitHub 的累积贡献度上排名第三，目前主要是负责 IoTDB 的查询和计算引擎模块。 今天下午将从技术背景、产品介绍和应用案例这三个主要的部分跟大家对 IoTDB 进行一个介绍，以及它的应用案例。首先是技术背景部分，随着这个物联网时代的到来，它给我们带来了海量的时序数据，时序数据是指时间序列数据是按照时间序列记录的这个数据列，在工业物联网当中，机械设备还有传感器实时产生了海量的时序数据，那在我们车联网当中也有海量的持续数据，也就是在车的运行当中，它会产生很多的这样一个行驶的数据，包括车况的数据。每一个数据它会带着一个采集的时间戳，以及一系列的值。 右上角也是看到在 2025 年，我们预测这个数据量每年产生会达到 50 ZB，而其中的时序数据的占比会达到 30%。所以数据的管理是企业全面数字化服务转型升级的基础。那管理好这个时序数据，它能够为工业企业带来哪些新的利润增长点？这里举了一个电厂的例子，其实电厂它在不同的阶段，比如说发电、输电以及配电环节，它都会有各种各样的时序数据去产生，那收集这些数据怎么用？它后面可以做分析。这里举了一个它真实业务的问题，也就是风机投入运行之后，它的测风仪会随着这个环境因素产生震动、腐蚀，出现偏差，那出现偏差之后我们就要校准，那校准的依据是什么？就需要我们去根据采集到的时序数据，然后对它的工况曲线进行建模，获得了风机和迎风角之间的变化模式，去判断要不要对这个迎风角进行补偿。在这个应用时间里面，我们也发现了有存在 32.51% 的风机都存在 4 度以上的风偏差，经过校准之后，每年的风机可多发电 3.13 万元人民币，按照 11. 5 万台的风机去计算的话，这个技术会给业主每年带来超过 1.5 亿人民币的经济效益。 在流程制造行业，包括我们后面会提到的这个汽车生产线上面，它也会有很多设计时、制造时和运维时的数据产生，存储这些时序数据对于后期的工艺流程的优化分析，以及这些残次品的追溯等等都有重要的意义。车联网场景其实不仅仅有我们平时的家用车，还包括一些运输行业的这个货运车以及挖掘机等等。就挖掘机在中国是一个比较特殊的经济的重要信号量，因为中国的财政和金融其实就是土地财政跟土地金融，挖掘机的出货量就意味着这个土木建设行业的兴衰。那这个跟今天的主题没有关系，这里其实想说的是，对于这些企业，货运车和挖掘机的行进轨迹和油耗是跟他们企业成本运行强相关的。所以这些时序数据的采集和分析，对后面的路线的优化其实具有深远的意义的。 除了这些上面的利润增长点以外，时序数据还能为工业企业提供问题溯源的渠道。比如说某某汽车它出现了这个故障，到底是刹车失灵了，还是说这个用户真的是把油门当作刹车了？那这个其实就是公说公有理，婆说婆有理，那最后去法院去定夺的话，依据的就是我们汽车上也有一个黑匣子叫 EDR，它就是用来存储一些汽车安全气囊，弹开的时候会记录汽车碰撞前 5 秒、碰撞时和碰撞后的三个阶段的车速、安全带状态以及自动开关等等关键数据。有了这些数据之后，法院也会有了定夺的标准。
那时序数据它其实是有这样一个价值的谱系的，如果我们仅存储一些实时的数据，它的作用可能就不是那么大，只能用来做一些状态的监控、远程运维等等。包括刚刚说的那个 EDR 层的数据，它可能就是碰撞了前后的一些时序数据，那如果我们想要把这个价值往深度去挖掘，去实现我们的一些故障预测或者说工艺改进以及工艺控制，我们需要把一些时序数据的全生命周期的流程的数据都要存下来，那这就意味着我们的存储成本会变高，因为我们存储的数据会变多。 时序数据的管理有哪些挑战？这第一个就是我们说的随着物联网时代的到来，它的这个测点会变得多，设备会增加，然后它的采样频率也会很高，有的会达到上千以上的赫兹，存储代价大，我们为了挖度深度价值的话，就要存储它的全生命周期的数据，需要长期的存储。 刚刚也介绍过时序数据的典型特点，它产生的速率非常快。然后在这些早期的时候，人们可能用一些通用的关系型数据库，或者说在这些通用的关系型数据库上面去改了一些，比如说他们 TimescaleDB、 KairosDB、 OpenTSDB 等等，就能够解决他们的存储以及查询问题了。但是他们的普遍来讲速度会比较慢，压缩比也会比较低，但是在体量比较小的时候，这些对于客户来讲可能都不是什么问题。那随着时代的演进，数据越来越多，就会有专有的一些时序数据库。比如说 InfluxDB ，它也是一个实时的数据库，工业上面会用的比较多。那它们其实也会有它们固有的问题，它们包括 InfluxDB，它其实只有单机版开源出来了，它的分布式版本是闭源的。那所以应运而生，有了 IoTDB 这一款端边云的时序数据库，它为物联网场景进行优化，并且部署简单，具有很强的性能，它的分布式版本也是开源的。
那关于 IoTDB 我下面也多说几句。Apache IoTDB，它是国际的顶级开源项目，在 2022 年 Apache 基金会全球 362 个项目当中，它的活跃度是排名第二的，超过了我们所熟知其他项目，包括 Spark，Flink，Hadoop，Hbase 等等，仅次于Google的Beam。它的代码贡献者分布于中、美、澳、德、英等国家，是国内唯一一款具有国际化属性的时序 DB 的开源社区。 一款成熟的这个数据库管理系统，它除了包含一些数据库内核的系统，像存储引擎，查询引擎，计算引擎之外，它还要有一些周边的生态工具，这样才能够去在用户那边使用的更好，使用的更便捷。IoTDB 本身它有很多定位，第一个定位它是想做厂内的高效的时序数据管理，对于原始数据，各种各样的数据源，无论它有多么快的写入频率，我们要能接得住。那把这些数据接入之后，我们还要对它存下来，也就是它的全生命周期我们都要进行管理，所以它也要存的下。那最后存下来之后，真正为企业带来价值的是这些数据，我们要查出来，那查出来之后当然有很多应用，包括大屏展示、报表生成等等。那这些查询就会面临着非常多的丰富的查询，包括原始数据，包括聚合查询，他们要查的快。 第二个定位是要构建新一代的端边云的工业数据平台，我们在端侧和边侧还有云侧都有不同的部署形态，这些不同的部署形态是为了应对不同侧的这个硬件资源去量身定做。这里列举了 IoTDB 的一些优势，那这些优势其实刚刚的片子里面也有提到过，所以这边我就简单带过了。
接得住，我们怎么样才能接得住，以前的关系型数据库为什么接不住？是因为他们是行式写入的，只支持秒级的数据接入。IoTDB 自研了这个列式的存储，包括它的存储引擎能够支持毫秒级数据接入，相较于竞品有 10 倍的性能优势。它的端边云协同模块支持不同模式的同步，如果适用于网络良好，要求数据延迟低的场景，那它可以用采集数据实时上传的模式，那如果我们处在一个网络状态较差，要求数据传输要高吞吐，但是对实时性要求又不是那么高的，我们就可以采用第二种方式去同步，也就是批量同步的方式。 IoTDB 刚刚提到它的分布式也是开源的，那它的分布式有哪些特点，或者说哪些优势？首先它的扩展性，它的集群扩容是无需去迁移历史数据的，所以能够达到秒级的扩容，它可用能够支持多副本的管理，多重的去保障数据的安全。这里列了一个容忍单节点失效，当然这个单节点不一定是单节点，取决于你布的副本数，如果你的副本数越多的话，其实能够容忍更多的节点进行失效。 IoTDB 的多副本协议也是我们为物联网场景去专门打造的一个共识协议，它能够支持两副本的高可用，这个是对比 Raft 是一些强硬性的共识协议，它至少需要三副本去起步，那两副本相较于三副本它就能够减少 1/ 3 的存储空间。
刚刚提到的端边云的不同的部署形态，以及即使在云端我们也支持强一致以及高性能这两种部署形态。IoTDB 也会用得便，它对接了很多开源软件，系统的接入也就更加便捷。包括在采集阶段，有我们今天另外一个合作伙伴EMQX，然后包括 Telegraf 等等，然后在处理阶段也支持现在比较流行的流批处理的 Flink 等等，然后在分析阶段与 Spark、Hive、包括 Matlab 有对应的连接器。在应用阶段也支持用 Karaf、Grafana 或者 Calcite、Zabbix 等等去展示我们的数据，展现了 IoTDB 学习成本低，它的提升速度也比较快。用得便，刚刚也提到是这些工具都是我们开箱即用的，我们能够用一些可视化的控制台，包括集群的监测工具，一键部署工具，其实对于 DBA 的这样一种运维是非常便利的。
性能优，它相比于国内外竞品能够提升 2-10 倍的速度，也与国产的一些主流的 CPU 跟操作系统完成了相互的认证，服务于规模以上的工业企业达到了 200 家。还有一点就是我们的开源协议，它是比较友好稳定的，是 Apache的 2.0 的 license，那它的这个 license 有哪些好处？其实有挺多的，这里就不展开细讲。那最主要的一点就是别的人拿到这样一份开源之后，他进行修改，那他修改后的代码其实不必要开源，他也可以选择自己闭源。所以这样一个开源友好的协议就会产生，国内外很多厂商会跟我们去合作，它基于 IoTDB 的底座内核去构建他们自己的产品。举了几个例子，华为的 Fusion Insight 或者阿里的 MaxCompute，用友，东方国信、海尔等等，他们都是底层基于 IoTDB 的内核去构建了他们自己的一套工具链或者说解决方案。IoTDB 作为技术中坚力量，它也辐射了全球的用户，包括德国的宝马和戴姆勒等等，还有日本的小松，美国的西门子。
那下面会跟大家主要介绍一下今天最重要的主题，就是在智能制造以及这个车联网场景和 IoTDB 的一些应用。第一个例子是一个比较有趣的 IoTDB 的应用案例，是我们跟德国的某个汽车厂商一起完成的项目，使用了 IoTDB 的端边云这样一个特色的协同功能，去完成这样多数据同步应用程序，以处理汽车生产过程当中的海量数据。首先跟大家介绍一下这个项目的背景，大家可以在图中看到这个，这其实是一个气动夹紧器，那气动夹紧器在汽车生产线上其实是比较常见的，它用来去固定住或者说，夹紧某一个汽车的部件，然后再向它进行一些操作。这个是一些气动夹紧器的详细的描述，它会跟其许多其他的一些气动夹紧器以相同的功能去协作，它在两个位置之间移动，去它设定好的那两个位置去夹紧，这种运动或者说它施加到的这个材料上面的力就跟它的名字一样，通常来自于下方的这个气动阀。图片中的下半部分就是它的气动阀，它通常连接到工厂当中的某个中央压缩机，这个中央压缩机会产生高压力的压缩空气，阀门打开时这个高压的压缩空气就会进入这个气动阀，这个这个夹紧臂会被顶到它预先设定好的位置。 这个是一项非常简单的技术，由于它唯一的活动部件就是下面的阀门，所以它非常的简单，简单就意味着可控，可控就意味着它易于维护，它承载的信息量非常少，只有打开或关闭，那对应到我们的这个计算机领域，它可能只需要一个 Bit 去存储它 0 或 1 就够了。所以它通常的维护成本很低，故障率也很低。但是这类气动夹紧器目前也会也在慢慢被替换掉，因为它有两个弊端，第一个是它的精确制导做出来比较困难，也就是它的所有的移动到预先设定好的位置，它必须在提前给它调试好。它不能说我要到这个位置，我要 5 厘米，能直接调一下到 10 厘米，这个是需要把它重新拆卸下来去做校准，然后之后它才能把这个间隔扩充到 10 厘米。所以这是它的一个问题，那在于工业生产过程当中，它从一个车型切换到另一个车型的时候，它就比较麻烦了。第二个缺陷就是我们后面要提到的。它的能源效率比较低。那这个能源效率其实是世界范围内一个重要议题，在德国也是一个焦点话题，整个工业界都在想方设法去提高能源利用的效率。左面一张图是关于这个总能耗的统计表，右边这个中间这张图灰色的，就是我们使用气动阀门它的能源效率。大家可以看到它外面首先需要接一个这个高压的电压或者电流去到我们刚刚提到的工厂的中央压缩机，中央压缩机去压缩空气，再把空气传导到我们的这个气动夹紧器上面。首先在它利用电能对空气进行压缩，然后再传输，就这部分的能源损耗已经达到了 80%。然后它在气动阀门，也就是气动夹紧器上面的能源损耗也会达到 3/4，也就是它最后由电能去产生我们这样一个生产效率，最终传导到生产力上面的能源效率只有 5%，这个是非常低的。所以逐步的这个气动夹紧器也会被我们后面会介绍的今天的主角，这个电力的执行器所替代。 这个电力的夹紧器它有几个好处，第一个好处是它不需要高压的空气，它只需要一个普通的可能是屋顶上面，你去架一个太阳能电板，它就能去产生的电能 48 伏就够了，然后经过我们的直流电刷机去传导到我们电力的这个夹紧器上面。它的能源效率还是比较高的，最后保留下来了有大约 60% ，60% 比 5% 可能就是 12 倍的生产力上面的差距。有了这个电力的夹紧器，或者说电力的执行器之后，它就会去替代掉我们下面的这个气动阀门。在这个汽车生产线项目大约有 1 万个左右的夹紧器，它最后都会被这个电机所取代掉了。原来我们也提到这个气动夹紧器，它有很少的信号量，就是关闭跟打开一个 Bit 就够了，但是现在这个电机它里面有十个不同的测点，并且它的测点数将来也会越来越多，包括电压、电流、扭距、倾角等等。那目前他们是以一千赫兹，也就是一毫秒会采集这 10 个测点的一个样本。初步我们进行了测算，计算了这个原始数据量，如果我们将所有收集来的这些数据原始的直接发到他们的中央服务器的话，可能每秒产生的数据流大约有 6.1Gbit 每秒。服务器虽然能够处理，它的处理能力可能这样的去扩展了，但是工厂的这个网络带宽还是比较受限的，它不像数据中心的网络那么强大，目前他们的最好的网络条件也只有 1Gbit 的带宽，最坏的情况下可能只有 10 兆左右的带宽。所以这种简单的部署，直接在中心侧部署一个 IoTDB，然后由设备直接发送这个原始数据的方式显然是行不通的。 在跟大家介绍下面一种部署方式之前，我们刚刚提到了这个 IoTDB 的模型，也就是说我们刚刚提到了一个痛点，就是它后面可能会增加测点或者新增设备。那这个其实在一些普通的或者说其他一些传统的惯性数据化上来讲，你增加设备如果你分表，这些表可能需要去增加一下，增加一张表，或者说增加测点的时候你要增加某一列，那这个其实都需要对 schema 进行一些改动的，但是对于 IoTDB来讲，因为它的 schema 也叫 schema on read，也就是它在写入时无需你对这些 schema 的变动做一些改变。比如说你新增设备了，那你插入的时候，你就直接把那个设备 ID 设成新的设备 ID，或者说你要新增测点了，设备去迭代升级了，那你在写入的时候直接去写那个加上那个测点的 schema 就行了。在 IoTDB 侧，它接收到这些之后，它会为你自动去创建这样一个元数据，无需人力人工去操作了，也节省 DB 大量的心智负担。那这样一个树级的层级结构也其实是跟实际的设备结构一一映射的，它有多级的设备直观管理，它存储的链路也比较清晰，也支持灵活的增删，这一点其实在工业场景里面非常友好的。 那刚刚提到每个设备直接将原始数据包发送到数据中心的这样一种部署方式，是不满足网络带宽的要求的。所以又进一步去想了其他的部署架构。由于一些其他的原因，他们这个生产线上其实已经部署了有 500 个边缘网关，那边缘网关我们就可以再次利用起来，每个边缘网关大约连接了 20 个电机，那在这些网关上我们其实是可以安装上我们 IoTDB 的实例的。那这样的话它的这个 IoTDB 就可以在它的网关本地进行运行，那每一个这样的电机就会将自己的数据发送到它所属的边缘网关上的 IoTDB，这样就能大幅的减省带宽，每一个边缘网关，可能它的每秒的带宽只需要 12.2 比特每秒就够了。虽然对于写入它已经比较优了，也能够满足要求了，全量数据也都存储下来了，但是对于查询的时候，大家想到它有 500 个 LCB 的实例，那我想查某一个设备的时候，那还好我可以在业务端进行一个哈希，然后找到对应的这个网关所在的边缘网关之后，我查那个就行了。但是如果我要做一些联合查询，比如说我想查多个设备的一些信息，作为一个联合的分析，那就是需要类似于中间店的一个功能，它需要去把我们的查询路由到不同的这个边缘网关，数据汇总之后去返回给客户端，那这样一种方式其实对于用户的查询是不太友好的，并且如果要用中间件的方式，他可能还要再去部署一套中间件。 在 IoTDB 它其实是不需要这样一种方式的，它可以在中心侧直接部署另外一个云端的 IoTDB，云端的 IoTDB 与这个边缘网关注册的边，部署的这个边侧的IoTDB，它能够通过 IoTDB 内置的这样一种云边同步的协议自行进行同步，那这样它的这个网络传输的效率是极高的。因为我们并不是传输原始数据了，这个原始数据已经存到 IoTDB 边缘网关的实例里面。那他进一步的进行了压缩，在他们这样一个实际的场景里面，他们的压缩率大概是 1:5，也就是说原来 6.1 GBit 的这个数据在经过 IoTDB 实例压缩之后，他们只传出TsFile，那他的这个网络带宽的需求已经降到 1.2 GBit 了。当然还是离我们的要求有点距离，因为它可能最好的工况条件下也只有 1GBit 每秒。 那有什么办法进一步的去改善这个现状？那在说下面的改善方法之前，同样也会跟大家先介绍一下我们刚刚提到的 IoTDB 的一个特色的这个部署架构，叫端边云协同。在物联网场景下，数据是从端侧产生的，在边侧网关进行收集，并汇聚到我们的云测。端边云三个场景，设备、网关、用户三个角色共同参与了整个数据流。传统的端边云解决方案下面设备在端侧部署采集程序，当网络通畅时，将数据发送到边侧，再进入云侧。当数据网络不同，就是网络不通畅的时候，数据会被写入本地文件，再在网络通畅之后，将数据点逐个发送出去。这样就带来几方面问题，第一是在不同的应用程序当中，在端侧临时存储的文件结构不统一，数据压缩比不高，会导致端侧存储数据的能力弱。此外，由于边侧或者说端侧它不存储数据，完全没有这种数据应用的潜在能力。第二就是边侧跟云侧的数据它被重复写入数据库，这种重复计算其实是带来了我们的资源的浪费。为此我们设计了 IoTDB 的边缘版、单机版、分布式版多种形态的部署方式，并创新了基于操作同步和文件同步的多端边云、多粒度、多延迟容忍的协同模式，最终达到端侧边侧协同，也具备了更强的本地数据管理能力来支撑本地的智能化应用。端侧和边侧已经组织好的数据，它不需要在云端去或者说边端去重复的浪费资源去进行解、压缩等等的操作，从而大幅减少用户管理数据的成本和代价。
回到这个应用案例上来讲，刚刚提到经过 5 倍的压缩之后达到 1.2 GBits，那 1.2 GBits 其实也不满足要求，那怎样才能进一步的满足他们的要求呢？其实压缩率已经达到一个上限了，或者说至少在目前的场景下面，他们的这个数据压缩率没有办法进一步提升了。那没有办法进一步提升压缩率，那就只能想别的办法，看看怎么减少数据量。所以跟这个客户进行交流之后，发现并不是所有的测量值他们都同等重要的，有一些很重要，用户需要实时的对它们进行分析和处理，但有一些只是先存储，现在还没有一些应用的场景。所以他们重新配置了边缘版的数据库，将所有的数据库的原始数据都保存在边缘网观测。但最终去跟云侧的这个 IoTDB 实例进行同步的时候，只选取了两个重要的，需要保持始终实时可用的这个测点，就是所谓他们定义的这个热路径。对于中央服务器来讲，来自这个 1万台电机的这两个测点的实时数据都是实时可用的。相对而言，其他的数据测点只被保留在边缘测的 IoTDB 服务器上，不会自动同步。这个其实对现在的应用已经够用了，但是他们也会担心万一之后的客户他想要去查询没有被上传到中心的 IoTDB 实例的数据怎么办？其实 IoTDB 它支持很多方式去同步这样的数据，它可以支持硬盘的热插阀，也就是说我数据虽然存在这个端侧，或者说边侧边缘网关的这样一个 IoTDB 实例上，我们甚至可以直接把这个硬盘拔下来去插到某一个云端的服务器的实例上面，插上去之后，当然这个分情况，最差的情况我们其实可以用 IoTDB 的 load，直接把这个磁盘的上面的 TsFile 直接 load 到 IoTDB 当中。当然这个可能延迟会有一定的延迟，当然这个也能满足他们的要求，也就是说他们虽然数据目前没有在云端，我们也是有能力将这些数据以一种比较便捷的方式，或者说代价比较低的方式去做这样的传输以及加载。
最后对这个案例做一个总结，这是一家在德国汽车制造厂的生产工厂当中经营的实践，并且也会很快的推广到其他的制造商。一般来说气动执行器到这个电动执行器的转型是提高生产工厂能源效率的大趋势，但是这个会导致生产线当中的数据量大量增加，因为实现了流程优化和精细控制，而使用的电动产生会产生更多的数据。在德国，这个案例问题其实是非常典型的，因为德国许多生产工厂的 IT 基础设施不是顶级的，因此他们必须密切的去关注这个可用的网络带宽。这个案例其实验证了我们可以通过一个运行在边缘侧的 IoTDB，不一定是一个，可能是多个运行在边缘侧的 IoTDB 和某一个，或者说某多个运行在云侧的 IoTDB 集群完成它的数据同步，因为数据已经是高度压缩过以 TsFile 的形式存储在边端的本地的，所以传输的网络带宽的节省是比较大的，并且这个方案是开箱即用的。整个架构它其实不需要用户去改 IoTDB 的任何代码，就是它的同步是自动进行的，我们只需要去改连接到哪些 IoTDB 的配置项就行了，并不会影响任何内核的代码。
接下来会跟大家去介绍一个很有意思的应用案例，也就是 IoTDB 在我们熟知的 V2X，也就是车联网场景的应用实践。同样我会带大家先了解一下整个应用的背景。数字化技术对于汽车进行深度的重构，汽车从一个配备电子功能的机械产品，逐渐演变成为一个配备机械功能的电子产品，这个转变还是很有意思的，它的主语变了，但是它的形容词其实是调了个个，云数据以及 AI 技术的一个融合，逐渐将汽车变成了一个大型的移动智能终端、数据采集载体、能源储能单位和一个移动的多功能空间。总的来说，现在的智能汽车已经逐渐转变为一个具备多功能空间的轮式的移动机器人。 我们的合作伙伴长安汽车在汽车数字化改造的实施路径上面，选择了一个分阶段的数字化的智能改造。大的来看主要有三部分，上云，治数和启智。上云部分主要包含汽车的 1.0 和 2.0，实现车辆的功能上云、数据上云和应用上云。在治数阶段主要是构建一套适合智能汽车的大数据的处理平台，去实现汽车的数据赋能、研发与经营。数据和 AI 功能的闭环进化。在最后的启智阶段实际上做的是数字汽车的 4.0，这块跟国家在推行的智能汽车的云控平台思路是一致的，通过边缘云、区域云和中心云的一个架构去实现整体 V2X 的智慧交通的融合。全场景数据和先进 AI 的闭环进化。在上云阶段，海量接入功能上云、业务上云和数据上云。
长安是打造了自主车企的一个千万级的智能网联汽车混合云平台，去赋能它的研发产品和服务。大的来看，平台主要有三个，就是他们的控制平台、数据平台和服务平台。控制平台主要去实现他们的车端、云端、消费端的一个一体化的架构，去满足多事业部对智能汽车不同的云服务要求，目前是已经支撑了 400 多万网联车的连接能力，然后预计是在 2025 年去提供一个千万级的接入能力。数据平台是将传感数据和车载计算合理的迁移到云端，去构建他们的大数据平台和他们的分期服务，为服务和产品创新去提供数据的支持。服务平台在他们内部其实做了一个开放的平台，去整合互联网生态的优势资源，去构建他们的智能网联生态圈。云上的业务应用，其实跟之前的那种 TSP 的平台是类似的，主要是为用户去提供一个稳定高效的智能网联功能，为智能网联汽车提供全新的功能体现和持续的更新。功能主要分为两块，一块其实就是 TSP 平台主要做的那种数字钥匙、远程泊车、远程控车和诊断，主要是在线的 OTA 升级的远程管车的功能。第二块就是为用户去提供一些在线的电台、音乐、智能推荐、家居联动和在线的主题壁纸等等互联娱乐的功能，在治数阶段主要就是要做到车辆控制器上的数据的上云和改造，以及标准化，因为他们单个的车联网设备，它是少则有差不多 500 项的传感器数据的，那多的其实是有 2000 项的那种信号数据，需要去做他们的采集管理，这一块他们就可以去统一的做一个数据的采集管理平台，然后再构建云上的海量数据的存储和处理能力，去保障高质量的数据。第二部分就是去统一车辆的数据资产管理，从采、治、管、用这四个阶段去进行车联网数据的全生命周期的一个跟踪和管理，去确保数据的隐私安全。
车联网的数据主要是分为四块，也就是我们的车况大数据，主要包含那种高速站和那些电线上面的那种电车信号速度，还有四门两盖的信号交互大数据，主要就是包含智能座舱的信号。然后驾驶和环境数据，主要就是一些传感器去采集的周边的一些数据和高精度地图的一些相关数据。这一块其实不仅仅限在时序数据的范畴了，它可能更多的是一种时空的大数据，包含了空间这样一个维度。那最后一个阶段启智，就是通过端云结合的方式去构建自动驾驶的数据闭环，构建从数据采集、数据处理、模型训练、控制标定模型与软件升级的这样一个闭环机制，这个不是主题，所以我们就略过这个部分。 车联网在长安这边的应用全景图就主要包含四个部分，刚刚已经提到了，就是他们的车控、座舱、IoT 的数据接入和 IoT 的车况管理。车况这块其实主要集中于远程控制和分析，然后座舱这一块主要就是车机埋点和车机的用户行为 。IoT 数据接入，这块包含了准入检测和一些实名的，或者说我们车机的一些激活监控系统。最后是 IoT 的车况，其实这一点是面向他们内部的研发场景的，主要做的就是一个车况的监控，这一块是可以 ToC 的，比如说我们车上面的一些胎压，一些油耗分析等等，用户都是能够直接看到的，或者是新能源车一些电池的三电分机，也就是最后看到的那张车联网的大屏。
这个是他们智能汽车数据架构的平台的一个架构，是基于 Hadoop生态去构建的。IoTDB 主要的位于这个数据存储层，去应对车联网海量时序数据的管理。他们当然也有一些其他的应用，包括做一些分析的那种 OLAP 负载的时候，他们可能会用到 Redis。
车联网这个海量的时序车况管理的挑战，其实主要还是一个体量的问题，因为长安目前它是以一个量产车型为主的这样一个场景，目前的话他们整个平台是接入了约三四百万辆的网联车。最大的挑战主要有四个，第一个是他们百万量级的一个海量的车况的高效传输与处理。第二个就是他们的信号采集，它分为不同的信号，有高速信号，它是毫秒级采集的，那常规信号可能是 30 秒一采的，平均下来的话，那个数据量基本上也会达到每秒上百万条。然后单车的一个多时间序列的高效查询和单车的全时间序列的最经典查询，这个其实也是车联网场景里面比较经典的实时车况和离线车况的查询，然后大数据平台上面也叫做一个设备影子这样一个功能。最后一个其实就是我们车机信号，可能它有时候在一些弱网场景下，它可能会数据无法去可靠的传输和收集，所以它们的数据之间可能会存在间隙或者乱序，甚至有重复的现象去产生。最后总结下来就是难点在于它们的体量大，它们的采集频率、高速性，包括它们的数据的多样性以及存在乱序。 那 IoTDB 其实是如何解决这些问题的？因为 IoTDB 一开始的时候它并不是做车联网起家的，它最开始的时候是面对的工业物联网场景，那工业物联网场景，其实它的场景或者说它的网络现场环境比车联网只差不好。也就是说我们天然的在最开始 IoTDB 诞生之初，就意识到了这样一个数据无法保序到达的难题。以某电厂客户数据为例，它长期存在 50% 以上的乱序数据，大家可以看到左边这个柱状图，它的延迟时长可能在 0-300 分钟不等。这个其实相比于我们的车联网数据的保序已经比它好了，那 30 分钟内乱序数据能够达到 90%。IoTDB 在这样一个背景下，所以它就首创了这个顺乱序分离的存储引擎，乱序数据的处理能力能够达到竞品的 4 倍以上。虽然这个顶会论文发的比较迟，但是这个乱序的存储引擎其实在 IoTDB 很早之前就已经有了，这样一个技术也已经发表到了 ICDE 2022 上。
除了这个顺乱序处理的存储引擎之外，我们想要应对这样一种高通量、高速、高频采集的这样一个写入特征之外，我们还需要去对它进行哪些优化？首先 IoTDB 它的整个存储引擎是 LSM 架构的，大家了解的话可能会知道它的数据是先保存在内存里面，当然写入内存之前，它会先有顺序的写入磁盘 WAL 去保证它的数据的持久化性。那写入内存之后，内存满了之后，我们会对它进行 flush，也就是会刷到磁盘里面，那刷的时候它会按照时间戳对它进行排序。所以排序这一步在 flush 的过程当中其实占了一个比较重的，或者说至少 CPU 看起来，它其实是一个比较重，占比比较大的一个部分。所以我们也是针对了时序数据当中的乱序特征，提出了时序的排序算法，提升它的排序效率大于 30% 左右。针对不同的特征，我们也有不同的排序方式，比如说如果它是递增有序的，我们就分块排序。第二特征就是它延迟较小，我们就从后向前去排，那这样去启发式的去确定分块大小，能够提升我们的排序效率高达 30%，这个排序算法也是目前发表在 ICDE 2023 上。刚刚提到 plus，那 plus 的第一阶段可能是排序，排序完了之后，我们想要把这些数据存储到磁盘上，那怎么样才能减少这个磁盘上面的存储空间？那必然就是编码压缩。那在编码这一块，除了我们常见的一些 RLE 编码，还有 Gorilla 编码之外， IoTDB 也有针对这种非等间隔的时区数据，发明了等间隔的对齐编码，能够提升它的压缩效率高达 50%。在特定的数据场景下面，那这块的细节我也不跟大家去仔细介绍，大家也可以看到下面的论文也列出来了，发表在 VLDB 的 2022 的论文上面，大家如果感兴趣的话，其实去可以去看一下。最后到了你编码完之后，压缩完之后，那最后要落盘，那落盘我们要以一种什么样的文件形式去存储在磁盘上面？这个其实也是 IoTDB 自己的这样一个持续的列式文件存储，能够大幅的降低存储成本。这块其实在刚刚的云边端的架构里面，我也有提到 IoTDB 的端侧，在与边侧或者说云侧同步的时候，它不是说要把数据再反的解压缩出来，以一个原始数据去传输，它是能够直接以 TsFile 的形式进行传输的。而远端去接收到这个 TsFile 的时候，它无需再对这个 TsFile 做任何改动，因为你是两个 IoTDB 它都能认得这个 TsFile。直接放进去在内存里面做一个很轻量的索引操作，我就能直接之后查询的时候，或者说 IoTDB 的管理系统就能够识别到这样一个数据的存在。那 IoTDB 这个自研的紧致的列式存储文件 TsFile，它的无损压缩率能够达到 10 倍，有损压缩率能够达到 100 倍。它也支持一些空值优化，支持序列级别的时间戳，不保留空值，只去存储一些有效的数据，这个能够节省空间 30%。这个是依赖于用户建模，比如说用户他知道以这个车为例，它可能这个车上面有一些是高频采集的，比如刚刚长安汽车，它这个高频采集的每秒能采 1000 个点，但它那些低频采集的，它可能每秒或者每 30 秒才会采集一个点。那这个明显是两个不同 pattern 的一个信号量，它就可以把它分开去建模它的那些高频数据的所有数据点，它可以建模在一起，它们去共享一个时间戳，因为它们可能都是一起采集的。但是那些低频的，虽然它采集频率比较低，所以如果跟那些高频的一起去放在一起去存储的话，它可能会有一些 null 值。那这些 null 值存储的话，虽然现在有一些编码技术，比如说 bitmap 等等，但你去记 bitmap 的话，它也有一定的开销，所以这个依赖用户去建模，我们是能够支持这样一种多值模型和单值模型的。IoTDB 的系统论文也是发表在今年，这个数据库三大顶会的另一个，刚刚其实提到有 ICDE，有 VLDB，这是另一个顶会，就是 SIGMOD 2023 上。
针对车况这个场景，主要还是再回到这个长安汽车的场景上面，他们之前存储引擎是用的 Hbase，也就是他们的历史车况会往 Hbase 里面去写。然后 2.0 的架构就是采用了 Flink 去接他们的 Kafka 的数据去写入 IoTDB。他们的车机数据是先流入到 Kafka，然后再从 Flink 用 Flink 去消费 Kafka 的数据去写入 IoTDB。整个架构升级上面，他们目前测试的体量差不多是每秒 150 万条数据这样，然后一条数据可能差不多有 15-20 个测点，平均下来大概有十六七个测点。在差不多千万级写入的体量下面，之前用 Hbase 集群是他们部署了 10 个 Region Server，并且 Hbase 的存储架构他们也没有用。我刚刚提到的 OpenTSDB，它是一款架在 Hbase 上面时序数据库，所以他们 Hbase 是不支持最新点查询的。他们又把一部分最新点查询后面可以看到加到了 Redis 上面，然后最新点查询去走Redis，然后一些历史数据的历史车况的查询去走 Hbase。按目前他们的 2.0 的版本里面就通过一个存储统一的引擎，就是 IoTDB，它是支持最新点查询的，所以不需要再去部署单独的一个 Redis 了，所以用一个 IoTDB。他们目前部署的还是一个单机的版本，他们用了一个比较好的纵向扩展，他们没有横向扩展，用了一个比较好的机器去部署单机版的一个 IoTDB，当然也有储备，然后去替换掉了原来 10 个 Region Server 的这样一个 Hbase 的集群。那最后统一的用了 IoTDB 这一套引擎之后，去实现了他们的单车的时间范围查询和单车全序列的这样一个最新点查询，然后测出来目前都是毫秒级返回的。
车联网其实有一些很典型的查询场景，除了一些最新点的查询和历史数据的简单查询之外，在车联网场景下也会有一些分析类的查询，这些分析类的查询可能并不一定要用一些 OLAP 的数据库，包括 Doris 等等，下面我们我会跟大家介绍这 5 个具有代表性的查询，能够让大家清晰的去感受出标准的 SQL 跟 IoTDB 查询 SQL 的差别。 首先跟大家介绍一下，就是有一些查询场景，你为什么用标准的关系型 SQL 写出来会那么丑陋，或者说那么冗余？那是因为关型数据库它本身是一个很成熟的技术，在上世纪可能六七十年代的时候，它已经有很完善的一种基于这个数学关系代数的，他们是把这个数据抽象成了一种集合，因为是集合，所以他们是无序的。在一些天然具有顺序语义的查询场景里面，用标准 SQL 去描述就会显得非常的复杂和臃肿，即使我们的业务人员费尽心智去写出了这样的 SQL，其实后期对这 SQL 的维护也是极其困难，并且容易出错的。但是 IoTDB 本身它存储的时序数据就是有时间上的顺序性，对于数据的抽象是序列也就是时间序列，它本身就有顺序性。所以 IoTDB 的查询语言在设计之初就考虑到了这些带有顺序语义的查询测试场景，提供了丰富的具有时序语义特色的查询算子，大大的减轻了SQL 编写人员的心智负担。 下面就是几个例子，第一个例子就是我们需要去查询某一辆车某一天内去发生里程跳变的时刻，这块什么叫里程跳变，我在图中也标出来了，也就是说下一阶段的这个里程跟上一阶段里程不一样的。那第一行是一个特殊的，因为它前面一行是 null，它没有数据，所以我们也把第一行作为一个里程跳变的时刻。那从第 4 行开始，它从 5 跳变到了 6，第 6 行它从 6 跳变到了7，第 8 行他从 7 跳变到了 8，所以我们要筛选出来这些具有里程跳变的时刻，那就是这四行，第一行、第四行跟第六行还有第八行。大家可能我们从人脑去找这样一个很简单，我们一目了然就能找到这四行。但是我们怎么样用 SQL 去编写出来，这个还是比较困难的。
首先给旅程跳变做了一个定义，那最近 ChatGPT 也比较火，也比较出圈，所以我就想考一考 ChatGPT，它能不能帮我们去写出来这样一个 SQL。我这边跟它聊天的时候，当然你不可能直接用我这种自然语言去跟它描述。我得首先给它一个定义，我得告诉它我有一张关系表，这些关系表用于存储汽车存储功能的数据，有三个字段，第一个字段、第二个字段是什么？第三个字段就是我们的里程。然后告诉它我想在这张表上去查里程跳变的时刻，并且给了它里程跳变的准确定义。那我们看 ChatGPT 大约经过 10 秒钟左右，它也是给出来了这样一个回答。当然他这个 SQL 可能写的有一些问题，但是整体来讲 ChatGPT 是给出了正确答案的，并且它对自己写出来这个步骤也给出了解释，大家可以看它解释的还很好。首先第一步我们做这个的话，其实最关键的是要用一个，如果不用那个表的 join 的话，其实比较方便的是用 SQL 的一个窗口函数，就是 lag 去查询每一行的前一行的里程值。然后这边它可能没有太理解我的意思，它是查询了所有的车，并且按日期进行分组了，这块其实我们不需要的。所以它主要是这个 lag 它是能写出来的，它是把前一行找出来，怎么找出来？给表述清楚了。然后第二个就是它外部查询，根据前一行跟后一行的这样一个值的不一样去做里程跳变的判断，所以整体来讲这个它是能够达到八九十分的。
我们根据它写出来或者他解释，我们是能自己去写出来这样一种 SQL 的。关系型 SQL 的关键点主要在于这两行，就刚刚提到 lag 函数，lag你可以理解成，就找到上一行。那这样的话，我当前行减去上一行就得到了一张表，那当前行减去上一行如果是 0 的话，那就代表它没有发生里程跳变，如果是非 0 的，那就发生里程跳变。这个 diff is null 是为了第一行，因为第一行前面没有，所以它减出来是 null，所以这样一个 SQL 它就能完成我们的这样一个功能。那对应到 IoTDB 里面，我们要怎么去编写这个SQL？就是如果大家根本就不知道这个窗口函数，那其实写起来还是比较麻烦的。这是对刚刚这个的基于关系表关系代数给出了一些解释，它先算出了这个 Diff，然后这些 Diff 我们在对它 is null 或者说不等于 0 的进行筛选，最后得到了我们这四行的数据。
我又继续问ChatGPT，你知道怎么用 IoTDB 的查询 SQL 去写出有相同的查询语义的 SQL，然后这里也给出了 IoTDB 的一个树形建模。这个大家刚刚也已经了解到了，ChatGPT 它给出了这样一个方法，显然它已经把 IoTDB当成这个关系数据库，给出来的几乎跟关系型数据一样，它根本不了解 IoTDB 可能并没有窗口函数这个概念，然后我就去提示它，因为我想让它用 IoTDB 的 Diff 这个函数去简化我们的查询 SQL。它说 IoTDB 的 diff 函数确实可以用来简化查询 SQL，具体产品语义如下。其实大家可以看到它根本没有优化，它就是把上面这个 last 换成了diff，然后它还解释的有模有样的。当然它这个解释倒是有一点比较好的是，当然我觉得它的解释本来上面就可能是拼凑出来的，因为它对 diff 的解释还是比较明确。因为 IoTDB 的 diff 就是每一行的当前一行减去前一行的差值，那它写的不对，其实 IoTDB 的 SQL 写出来比较简洁，因为 diff 我们定义的就是当前行去减去上一行。然后我就去问他一下 IoTDB diff 的含义，他也给出来了，他说 diff 是用于计算时间序列差分的这样一个函数去计算相应点之间差值，得出来新的时间序列。其实这个是 1.0 之前的 IoTDB 的 UDF 的一些解释，它解释的是有点过时了，我又去提醒他，我让它去看一下 IoTDB 的 1.1 的文档，这个 diff 函数已经从这个 UDF 变成标量函数了。然后它说感谢提醒，它又再次查阅了这个 1.1 的结果，它去看了 1.1 的给出来的还是跟这个 0.13 的解释是一样的，没有任何区别，还是我们用 user-defined function 给出来的定义，所以这一块也看到 ChatGPT 还是有待训练跟加强的。 那这一块其实我们在 1.0 的时候对 diff 进行了一个重新的定义，它不再是我们之前的 user-defined function了，它变成一个内置的标量函数，它能对一列时间序列进行操作，返回每相邻点的差值。因为它是一个标量函数，所以它输入 n 也输出 n，第一个点跟前一个点的差值定义为 null，这个也是能明显看出来。然后 IoTDB 写出来的要比标准关系型 SQL 写出来的要简洁很多，甚至包括关系型数据库，如果你不用这个窗口函数的话，写出来会更加复杂。
第二个典型查询就是我们要去统计某段时间内某台车的定位异常的天数。那什么叫定位异常的天数？就是我们的 GPS 会采集我们的经纬度坐标，那无效次数大于 10 次，就算一次定位异常。什么是无效次数？就是 GPS 的经纬度连续为 0 的次数大于 10 次。大家要注意这个关键点，一个是连续为 0，还有一个次数连续的次数要大于 10 次。那这一块我列出来这样一个样例，场景里面它虽然有经纬度坐标为 0 的场景出现，但是它没有连续超过 10 次。这个连续是两次，第一行跟第二行，当然到第三行已经不为 0 了，所以这个里面其实是没有出现异常的。然后我们不仅要找出这个定位异常，我们还要统计一个定位异常的天数。需要注意的是这一天如果出现了多次定位异常，它也只能被算作一次。 这个对 ChatGPT 其实是一个比较大的挑战，我们尝试去问他一下，这样这边的建模我就不跟大家念了，主要是看现在 GPT 分析，我觉得它这块分析做的还挺好的，它把它整个思考过程说出来了。第一个就是要确定查询的时间段和车的 ID，这个就是我有条件里面的。第二个是说我要用外部的这个 SQL 去统记该车在时间段内的定位的异常天数，然后它怎么去定位这个异常天数，它就去描述它这里面的子查询要去怎么做，首先要就 vehicle_table 本身要做一个 join，然后再用 lag 跟 lead 去找当前行跟前后两行的 GPS 坐标信息，然后对这些计算出来的信息做一个 flag 的标记，最后用额外子句去按天去统计它的定位异常。它这块显然是刚刚没有注意到，我跟大家说的注意点就是它次数要大于 10 次，它并没有注意到这个点，它说当前好像跟前后两行的 GPS 坐标都为 0，就觉得它是定位异常了，那这个显然是错的，它给出来的这个结果当然也是错的。我这边也是列出来它为什么是错的，它没有超过 10 次。
这款是我给大家写出来，或者说我们客户他们原来是怎么去写这个 SQL 的？其实定义的非常复杂，这边用了一个 temp_table，就是 with 的子句。左边先对这个临时表进行了一个定义，那这个临时表的定义其实用了刚刚的 lag 函数，那刚刚这个 lag 函数，是带其他的参数的。它第二个参数是指往前去找多少行，这边一的话就往前找一行， 2 就往前找 2 行，找 10 的话就往前找 10 行。所以我们把这些都算出来之后，去看当前行，如果是 0，就是两个都是 0，并且它当前行跟前多少行，前 1 到 10 行它都是 0 的话，那我就是一个定位异常了。那有了这样一个处理表筛选出来之后，我们还要在右侧对这些 0 数据行进行什么呢？首先我们要对车辆进行分组，还要对按天进行分组，用最后的统计天数，就是 count 一下这一天里面有多少次统计异常，那有一次统计异常以上的及以上的，那就是异常天。最后再对这个异常天数进行一个count。
然后就是我去问它用 IoTDB 去写出相同查询的 SQL，并给出了一些建模。这块显然它给的也不对，它也把 IoTDB 当做这个关系型数据库了，所以其实前后两边它的这个前后的上下文的学习还不是很够，因为我之前已经提醒过他 IoTDB 并不是一个关型型数据库，它还在这用关型型数据库的方式去给出来。我也告诉它 IoTDB 有很多时序语义特色的算子，比如说 count if 以及 group by time 等等。然后它确实是用了一些 group by time，但是它用的方式肯定不对。然后它的 count if 其实给出来了一个，但是它 10 天的条件又漏掉了，它把 10 天放在 where 这边，也肯定是不对的。
那这个 IoTDB 写出来实际上是很简洁的，就是它用你的 count if 以及我们的 group by time，就是根据时间天数间隔去分组。这块 IoTDB 其实是不需要依赖于之前关系型数据库建模里面那个 setting date，它是不需要存储生成的，它直接根据 setting time，它能对时间做这样一个分组。keep 大于 10，也就是超过了十天，然后判断 count 条件 if 是什么，就是它经纬度坐标都为 0，最后这个abnormal_value_count，也就是它的每天次数大于 0 的时候，我们把它当作一天。
where 查询和关系型数据库是一样的，所以我也想让 ChatGPT 对 group by time 等一些子句进行一些解释。这个解释的也是比较清楚，我相信也是从我们官网上拷贝出来解答的，然后还有 count_if，count_if 它给出来的定义也是准确的，但它漏了几个参数，真正的 count_if 定义其实是计算一段区间内连续满足一个给定条件，并且连续的个数满足阈值条件的次数。也就是它的第二个参数，我们的 keep 它不一定要大于10，它也可以等于某一个值，以及小于某一个值都是可以的。那这个已经能初见端倪了，这么长的一个 SQL 跟 IoTDB 这么简洁的一个 SQL 就能表现出来差距。
下面其实我就跟大家快速过一下。第三个典型查询就是找出所有车的休眠时间的首末条数据并计算出时间差。什么是休眠时间的首末条数据，什么是休眠？就是它的 gw_nm 字段不是 0 或者 1 时都认为它处于休眠状态。这个其实可以看到我在时间里面列出来了，第一条数据跟首末条数据，我们就是要找到这样的数据并计算时间差。同样的ChatGPT，现在明显是错的，然后我又去提示它，告诉它真正的休眠状态的定义是什么，它给出来了这样一个定义。它这个里面用到了一些高级的用法，其实这些我也没有清楚关系型数据库里面能不能这么写，它好像定义了一些局部变量，我觉得这应该不是标准关系数据库里面可以用的 SQL 的定义。
所以客户那边他们原来是怎么写的？他们定义了很多的二级表，这里面有三张，然后最后在这些表上面还要做join，然后再 order by 再查，其实是比较复杂的，这一块大家可以自己去看一看。然后 ChatGPT 给 IoTDB 的给出的 SQL 也不对，然后当然我提醒它了，我说有 group by condition 可以用，但它的 SQL 写的也不对。它对 group by 的解释还可以。所以 IoTDB 最后写出来也非常简洁，它就很简单很符合我们的语义，就是我说 gw_nm 不在 0 或 1，并且不在 0 或 1 的连续的次数大于 2。为什么要大于二？因为它要首末，你一定要这个数据大于二你才有首末，不然首末的话都是同一条数据没有意义了，所以它就大于等于二。最后在最大的数据和最小的一个数据前后的两个差值就能算出来它的时间差了，还是写出来比较简洁的，依赖我们 group by condition 的一个定义。
这块 group by condition 的定义我也去问了一下，现在 GPT 当然我看到它可能说的是错的。group by condition 其实是提供了 IoTDB 提供的一种新的序列内的聚合计算的分段方式，可以将连续的满足用户给定条件的数据行划分为一组，对于不满足用户给定条件的行，就不属于任何分组，简单忽略即可，其实多了一个分组前提下，又多了一个过滤的功能。
第四个典型查询的是取出超过 60 条以上的连续信号量的第一条和最后一条的数据。那什么叫连续信号量，连续信号量是指它的前后两条的时间戳差值不能超过 24，那这块其实我列出了一下，大家可以看到第一行到第四行之间，它差值分别是20、20、20、23，到第四行跟第五行就是 34 了，所以这边就应该进行一个分段，它是属于下一次连续性。这些连续情况持续了多久，第一段是 63 秒，第二段是 67 秒，写关系型数据库就会极其的复杂了。首先我们定义了一堆我们所谓的临时表，然后对临时表还要做查询，就进行一个 group，感兴趣可以去看一看。
我们看看 IoTDB 要怎么去写，IoTDB 即使用 group by session 的功能，它又是另外一个分段的方式，刚刚也提到 group by session 它是做一个什么样的操作，也就是提到它间隔超过 24 秒之后，它就是属于下一个分段。session group 的概念就源自于一个流处理的定义，我们如果它超过 24，我们就把它放到下一个分组里面，基于这样一个 group by session 的这样功能。
这一块大家迅速过一下，找最频繁的驾驶模式，以及每段形成的首末条数据。驾驶属于同一段行程的定义是这样子的，然后我也没有去问 GPT 了，因为 GPT 可能他也回答不出来，所以最后像真正的关系型数据库对的 SQL 会非常复杂。右边是它的最后查询，左边是它的一些明细表的定义，不仅这个地方其实上面也有一张。那么然后关系型数据库为什么不能有我们刚刚的 group by session，group by condition 这些功能呢？主要是在于关系数据库，最开始它没有一个顺序的概念，比如说它没有第一个，没有最后一个，因为你对于集合来讲，哪一个都会是第一个，哪一个都是最后一个，因为它没有顺序。所以这种带有顺序的聚合函数无法在关系 SQL 里面去实现，就是因为关系代数本身它的后面的数学的定义，它就是对于集合进行操作，而集合是无序的，所有的它的操作也是面对行的概念，而没有办法在一些关系表中对某一列单独进行一些操作。
我们 IoTDB 刚才定义的 SQL，其实它的主要的复杂点是在于 select item，如果将 select item 化为一行的话，其实它也很方便。这边主要是这个 group by variation 的定义，这个就是我们刚刚提到怎样去判断一个行程是否属于同一个行程，这个是对于值的这样一个判断，它的值如果超过，跳变的值非常大的话，它属于离群点，它就不属于当前这个组，它划分组的方式就通过 group by variation 去实现。
跟大家介绍了一些典型场景，最后就是 IoTDB 还有一些其他的，在长安汽车里面，比如说最新点查询，还有 last 查询，以及丰富的其他的元数据查询、降采样查询，刚刚提到的分段查询，还有更多一些其他的内置的查询，大家也可以看到关系型数据库和 IoTDB 的差别了，那么长的一个 SQL 让人维护起来比较困难，然后 IoTDB 可能写起来就比较简单。
最后跟大家简单的介绍我们 IoTDB 的公司，也就是我们天谋科技。它是做 IoTDB 的企业化，然后公司主要是来自国际顶级开源项目 IoTDB 的核心团队创立的，然后核心的都是来自清华大学、UC Berkeley 以及德国法兰克福能源集团专家等等。我们的愿景是围绕 IoTDB 去打造物联网时代的数据库软件新基建，让时间发声，让企业用更低的成本去挖掘更大的数据价值。目前也是拥有清华大学时序数据库管理核心专利 30+，也是全球领先的时序数据库管理系统及相关服务的提供商。目前总部是暂设在北京，当然在我们上海和欧洲也都有设立分部。
那 IoTDB 它其实因为公司成立可能比较晚，在 21 年的时候是正式成立的，获得了红杉领投的近亿元的天使轮融资。IoTDB这个项目，它早在 11 年的时候就已经开始孕育了，清华团队参与了 863 的课题，并发现了工业场景上的一些瓶颈，确定了一些方向，这个方向就包括刚刚提到的乱序场景。然后 15 年进入自研阶段，由孙院士和清华大学软件学院王院长去发起启动了清华 IoTDB 的研制，18 年也是王老师把 IoTDB 捐献给 Apache 基金会，去吸引了德美奥的同行的关注。在 20 年 IoTDB 正式的成功的毕业了，变成了 Apache 基金会的顶级项目，建立了全球认可的国际化的开源社区。
在公司成立以来，IoTDB 也是获得了各种各样的荣誉的成就，包括 2021 年的参加国家“十三五”科技展，到 2022 年完成了中国信息通信研究院的可信数据库的认证。我们的应用场景其实已经覆盖了天、空、地、海这 4 个场景，天是指 IoTDB 已经登陆了北邮 1 号卫星，支持科学实验数据，包括向地面去传输它的数据；空其实是成飞和商飞他们的一些试飞数据，包括成飞在飞机制造上面的一些制造数据；地的话覆盖了轨道交通、工厂、车联网、气象站等等场景；海的话是中国船舶，支持生产场景高度复杂的船舶行业高效存储与查询。
这是一些我们的合作伙伴，如果大家感兴趣的话，可以添加一下微信 apache_iotdb 去联系我们，如果有一些应用场景可以互相地讨论，谢谢大家。
