编者按：
8 月 22 日，2026 时序数据技术创新大会在北京成功举办，引发广泛关注。本次大会以「DB × AI」为主题，多位院士专家领衔，超 30 位嘉宾齐聚一堂，共同探讨数据库与人工智能融合发展的新趋势、新技术与新实践。
天谋科技数据库内核研发工程师、Apache IoTDB PMC Member 田原在技术分论坛发表“数据基座：多模态时代的时序数据库如何承载工业数据”主题演讲。
田原表示，这是他第四次在大会上分享 IoTDB 的最新进展。回顾过去几年的演进历程：Apache IoTDB 从 0.13 版本发展到 1.0；正式推出分布式版本；随后持续完善树模型查询语句，提升用户使用的便捷性；去年，IoTDB 从 1.0 迈向 2.0，在保留树模型的基础上新增表模型，并进一步兼容标准 SQL。
在此基础上，田原分享了工业时序数据库走向多模态的技术路径：通过 object 类型将视频、音频、图像等非结构化数据纳入统一的数据平面，以时间轴和设备身份建立跨模态关联，并进一步为 AI 运维、根因分析和多模态预测提供完整的工业上下文。演讲同时结合气象数据管理，介绍了相关能力的落地实践。
全文 5 千余字，阅读约需 10 分钟，以下是本文目录及演讲主要内容：
为什么需要工业多模态时序数据库
过去，企业使用 IoTDB 与 TimechoDB，主要存储的是标量数据，如温度、压力、振动等数值类型数据。当然，也可能会有一些 string、blob 这类对象，但这些数据通常都比较小，具有固定的字节大小，例如 4 字节或 8 字节。
但在工业场景中，一台设备产生的数据并不只有标量，还包括视频、音频、图像和文档等非结构化数据。
过去，企业往往需要搭建多个平台，将数据对应存储在时序数据库、对象存储、日志平台和音视频平台中，这样一来，业务侧就需要分别维护权限体系，并自行完成不同平台之间的数据关联和根因分析。
更重要的是，单一的标量数据只能说明某个时刻发生了异常，却无法解释异常是如何发生的。
例如，时序数据库中记录了故障时刻的 87.4 温度值，这只能说明异常发生了，却无法解释异常是如何发生的。要完成进一步诊断，我们还需要结合同一时刻的波形、声音、图像、日志和检修记录等信息。
这些多模态数据可以为异常判断提供关键证据，不应该被视为彼此独立的事件。如果将它们存储在不同平台，就需要在业务层再次进行整合。
现有架构还会带来以下问题：
设备标识不统一：同一台设备在不同平台中可能被记录为“设备一”“device 1”或“设备1”，增加了数据关联和统一查询的难度。
数据标准不一致：不同人员或平台在处理数据时，可能采用不同的时区和精度标准，影响数据对齐与分析结果。
权限接口不统一：各个平台分别维护权限体系和访问接口，业务侧需要额外处理权限认证与数据访问。
数据生命周期管理不统一：不同类型的数据分散在多个系统中，需要分别设置和维护保留周期。例如，视频监控数据保留一周或 30 天时，相关的时序数据、日志和其他上下文信息也应采用相匹配的生命周期。
因此，我们希望在统一的数据平台中，将多模态数据与时序数据一并管理，通过统一的设备标签和时间轴实现数据对齐。其中，时序数据用于定位异常发生的时间，图像、日志和音频等信息则用于解释事件上下文。只有将这些信息整合起来，才能还原完整的工业现场，而不必再从多个系统中分别检索和拼接数据。
Object：让非结构化数据进入时间轴
介绍一下，我们将如何解决多模态数据的统一管理问题。
TimechoDB 在 2.0.10 版本中新增了 object 类型。它的设计思路与对象存储有相似之处，可以将原本需要依赖对象存储完成的一部分工作纳入数据库中，但在使用方式和数据管理能力上也存在差异。
Object 类型可以围绕事件锚点（time）和资产身份(asset)，将不同类型的数据关联起来。事件锚点指异常发生的具体时刻，可用于对齐温度、压力等标量数据，以及视频、音频等多模态数据；资产身份则通常对应工业场景中的设备 ID，用于统一关联同一设备产生的各类数据。时，标量数据和视频、音频等证据都可以作为表中的字段进行存储，其中非结构化数据以 object 类型承载。
这样，结构化条件能够帮助我们精确定位异常事件，而 object 则用于补充事件的上下文信息，支持后续解释和追溯。
将 object 数据纳入 TimechoDB 后，用户可以通过一条 SQL 在同一张表中完成筛选和返回，权限边界也能够统一由数据库管理。同时，不同数据可以共享同一套 TTL 生命周期策略，避免在多个平台中分别维护。
TimechoDB 还提供了 UDF（用户自定义函数）能力，并支持计算下推和过滤下推。对于一个容量达到数 GB 的文件或图像，用户实际需要的可能只是其中十几分钟的数据。传统方式通常先从 S3 （注：Amazon Simple Storage Service）对象存储中完整读取整个文件，再截取所需片段；借助 UDF 和 file handle，我们可以像操作本地文件一样处理对象，并通过局部读取只获取目标时间段的数据，即使面对特殊的视频编解码格式，也能减少不必要的数据传输。
在存储实现上，TsFile 中主要保存对象的路径等元信息，路径指向object中的文件，并支持区间读取、文件长度检查等能力。大文件的实际内容仍由数据库统一管理，但不必完整写入原有的 TsFile 数据块中。
这里有一个点需要补充，就是 object 类型与已有的 blob 类型的区别和选择问题。
两种类型适用于不同的场景。blob 本质上是二进制数据，通常适合存储体量较小、需要完整读写的内容；当对象超过一定大小（例如 32 KB），且存在流式写入或局部读取需求时，则更适合使用 object。
在使用方式上，object 支持将数据拆分为多个分片，按顺序流式写入，并可根据指定的 offset 和 length 读取部分内容；blob 通常需要将完整对象一次性写入，并在读取时返回完整数据。
Object 技术原理：写入、合并与查询优化
接下来，我们进一步介绍 object 类型的实现方式。
1.对象写入
与 object 类型相比，blob 在写入时通常需要先将完整对象组织好，再一次性传输。例如，一个 1 GB 的 blob 对象，就需要将完整的 1 GB 数据发送出去。但 RPC 接口默认的单个 frame 往往无法承载如此大的数据，也不具备流式写入能力。因此，blob 更适合存储体量较小、需要完整读写的数据，对于大对象的写入支持相对有限。
object 类型则采用分片（chunk）写入的方式。我们可以通过 offset 和 length 指定每个分片的位置与大小，将数据不断追加到对象文件中。分片大小可以根据内存条件灵活调整：内存充足时可以设置为 1 MB，内存较小时也可以设置为 128 KB。这样，写入过程中的峰值内存主要取决于单个分片的大小，而不需要与整个对象的体量相关，从而支持大对象的流式写入。
当最后一个分片写入完成后，我们会追加一个 EOF 标记，表示对象已经完整写入。只有收到 EOF 后，这个 object 才会对外可见。如果写入过程中出现异常或中断，未完成的对象不会被读取，从而保证对象写入的原子性。
同时，在共识复制过程中，object 也不会作为一个完整对象一次性传输，而是以分片形式按顺序发送，并在副本上依次应用。这样，各个副本都能够在本地读取完整对象，同时不会读到尚未写完的不完整数据。
2.后台合并
TimechoDB 使用 SM 引擎，写入完成后会进行异步合并。
如果使用 blob 存储大对象， blob 会将数据存储到 TsFile 列式的存储文件中，合并时需要读取并反序列化完整的数据块，再完成归并和重写，容易产生较大的 I/O 开销和写放大。
使用 object 类型后，TsFile 中主要保存对象的路径和长度等元信息，实际对象内容则存储在独立的对象文件中。合并时只需要处理对象的间接路径和长度信息，不必读取右侧对象存储中的完整内容，因此合并过程更加轻量，也能有效减少写放大。
虽然 object 与其他数据类型在底层存储方式上有所不同，但它仍然由 TimechoDB 统一管理。对象的写入、复制、查询、TTL、删除、垃圾回收和权限控制，都可以沿用数据库自身的管理机制，从而与现有组件保持协同。
3.查询优化
查询所做的最大优化在于计算的 push down（下推）。
大对象查询通常会伴随标量数据的过滤条件。多数故障定位场景并不需要读取完整的视频或文件，而是先通过温度、压力、时间等标量条件定位异常事件，再读取对应时间范围内的部分对象数据。
因此，查询时会优先执行选择率较高的过滤条件，确定需要读取的对象及其时间范围，之后再对对象进行局部读取，避免不必要的对象 I/O。
直接执行 SELECT 查询时，返回的通常只是一个对象视图或句柄，其中包含对象类型和大小等信息，并不会直接返回完整对象。真正读取对象时，可以通过内置的 read_object 函数读取完整内容，也可以指定 offset 和 length，只读取目标区间的数据。
另外是函数下推，由于对象数据可能存储在多个副本节点上，查询引擎还会将针对对象的过滤和计算下推到对象所在的副本节点执行。
对于标量数据而言，跨节点传输的成本相对较低；但对于大对象，网络传输往往是主要瓶颈。因此，我们针对这个问题做了优化，将过滤条件、相关计算以及用户编写的 UDF 下推到对象所在节点，可以减少大对象在网络中的传输，再将计算结果返回上层。
此外，用户的二进制对象可能采用特定文件格式，需要依赖第三方库进行解析。例如，视频解码库通常需要接收一个 File 对象或文件路径，才能读取磁盘中的数据。为支持这类场景，我们提供了获取对象文件的接口，使用户能够在 UDF 中调用第三方库，并使用对象的局部读取能力。
由于对象的具体内容和格式通常由用户最了解，UDF 也可以根据实际算法只读取所需的字节，而不必加载整个对象。
气象数据管理实战：object支持局部区域数据读取
接下来介绍一个已经落地的项目，看看我们如何使用 object 类型管理气象数据。
大家平时打开天气 App，通常会查询所在区域的温度、风速和湿度。这些气象数据通常具有不同的空间精度，例如 1 公里、3 公里或 5 公里。
在查询时，用户只需要提供所在位置的经纬度，系统就可以判断其落在哪个空间网格或区域中，并返回对应的温度、风速和湿度数据，而不必扫描全国范围的完整数据。
从存储角度看，这些数据可能以包含全国信息的大对象形式存在，例如 TIFF 格式的栅格文件。我们可以将 TIFF 文件以 object 类型存储在 TimechoDB 中，并与其他标量信息一并管理。
对于个人天气查询，通常只需要读取其中一个局部区域；对于区域分析，例如查询北京市海淀区覆盖了哪些网格，也只需要读取对应的局部数据，而不必加载全国数据。如果目标区域只占完整文件的 5%，那么实际读取和传输的数据量也可以控制在整体数据量的约 5%。例如，原本需要在网络中传输 100 MB 的完整文件，现在可能只需要传输其中约 5 MB，从而显著降低 I/O 和网络传输开销。
气象数据的业务模型比较复杂，数据采集周期可能是 5 分钟，也可能是 1 小时。查询时，系统通常会先根据结构化字段进行过滤，例如筛选最新数据、指定时间范围，或选择温度、降水量等指标，先锁定候选文件，再调用我们开发的 UDF（用户自定义函数）执行局部读取。
再来看看在 UDF 中的实现细节：我们首先将用户输入的位置转换为数据格式所需的坐标，然后判断目标位置与哪个区域或瓦片相交，计算对应的字节范围，再调用第三方读取方式解析这部分瓦片数据。解析完成后，将温度等结果转换为 float 或其他标量字段并返回。
因此，即使完整文件达到较大的体量，实际算法所需读取的数据可能只有几十 KB。当然，对于分析类任务，也可以执行完整文件读取。
除此之外，降雨量、雷达信息、站点异常等不同类型的数据，也可以统一存储在 TimechoDB 中，共享同一套时间、设备 ID 和资产 ID 等上下文信息，从而支持预警分析和跨模态数据关联。
统一数据平面，支撑 AI 运维与多模态分析
最后，我们总结一下，统一的数据平面能够为企业带来什么价值。
当我们使用 AI 进行运维时，真正的难点往往不在于 AI 是否足够智能，而在于它是否掌握企业内部的业务背景。比如，用户希望查询某一时间段、某个区域的降水量，AI 或智能体需要知道数据库中的表名、列名，以及用户所说的中文概念分别对应哪些数据。
因此，首先需要实现数据平面的统一。统一并不意味着把所有数据转换成同一种格式，而是让不同类型的数据能够在同一个平台中建立关联。
在 TimechoDB 中，不同数据可以共享统一的 tag，也就是设备 ID。用户可以通过某个异常指标对应的字段，定位到同一行中关联的非结构化数据，并直接在 TimechoDB 中完成查询，从而形成 AI 共享的、统一的数据上下文。
这些数据包括日常监测的 metric、日志 log、链路追踪 trace，以及视频、图像等多模态信息。它们可以围绕统一的时间和 tag 建立稳定的关联锚点。
经过采集、处理、标准化和关联后，再结合异常检测能力，AI 助手就能够基于完整上下文辅助判断问题。
统一的数据平面还能够约束上下文质量。即使结合 RAG，也只需要围绕一套统一的数据和业务定义构建知识，而不必分别维护多套彼此不一致的信息。除了时间和资产身份，空间、事件等不同维度也可以共享统一的上下文，从而构建一个可关联的工业现场。
这样，数据采集、存储、查询、函数计算和 AI 能力都可以置于同一套上下文中，无需在多个平台之间反复搬运数据，AI 也能够更准确地定位问题。
从告警、假设、证据到结论和行动，每个步骤都可以保留相关的对象、时间、资产和函数结果，并支持双向追溯。例如，我们既可以从异常指标定位到对应的视频或日志，也可以从视频中发现异常后，沿着其时间线回溯到对应的时序数据，进一步判断这是异常漏检、数据漏传，还是数据本身存在缺失。
最后总结一下，我们希望 TimechoDB 保存的不只是传统的 metric 等标量信息，还能够保存日志、视频、图像等多模态数据，完整记录工业现场的上下文。随着完整事件不断积累，这些数据将为多模态先兆预测、预测性维护和多模态模型训练提供基础。
所有预测和 AI 应用的前提，都是拥有足够且可用的数据。如果数据分散在多个系统中，处理和关联都会变得困难；而当这些数据统一沉淀在 TimechoDB 中，就能够基于统一的数据体系开展多模态数据处理、预测和训练。
当然，当前 object 类型仍有许多问题需要继续推进。例如，对于视频这类特殊数据，后续还需要进一步研究，是否应将视频按帧拆分，并与对应时间戳的标量数据建立关联。这些也将是我们接下来持续探索的方向。
我们希望最终实现的，是从一个数据点还原完整的工业现场，构建真正的工业多模态时序数据库。
