拥有海量数据，工业AI却为何跑不出来？

在一家航空企业的现场，工程师们接到一个任务：分析某架飞机的飞行姿态，锁定重点工况。提需求的人觉得这事不难，把各类数据按时间轴对齐就行，业内叫“时标对齐”。在数据库工程师的教科书里，这甚至算不上一道难题：按时间列做个连接，完事。

但真到了现场，事情立刻变了味道。需要对齐的不只是气压、高度、电流、电压、速度、姿态这些常规的数值，还有驾驶舱里录下的语音、机载摄像头拍的图片。更要命的是，这些数据压根不在同一个系统里：数值数据在时序数据库，图片、文本和文档散落在文件系统，还有些被扔进了对象存储。想做一次完整的分析，工程师得先当“搬运工”，把数据从各个系统里捞出来、汇到一处，再逐段拼装对齐，每一次分析，都是一遍重复劳动。

于是，用户向数据库厂商抛出了一个问题：既然我们对这些数据的所有分析都是沿着时间维度展开的，那语音、图片、文档等数据，算不算时序数据？天谋科技CTO乔嘉林给出了他的回答：时序数据的类型，确实不应该只有数值。

进击的数据库

当工业AI开始进入真实生产场景，第一个摆在数据库面前的问题，就是这些原本散落在不同系统、不同介质中的数据，能不能被统一组织和管理起来。

面对管理多模态数据的需求，数据库开发者的第一反应是：尽量不重复造轮子。

乔嘉林表示，天谋科技最先尝试的是BLOB方案，把图片、文本当成一整个二进制数据存进去。实验结果：部分可行。当多模态数据只有几KB、几十KB时，把它们当成一种特殊的数值类型，与传统时序数据放在一起建模、查询，都没问题，还能轻松地统一交给客户端分析。

但随着观测精度提升，高分辨率卫星云图、高清视频涌入数据库，单个对象动辄几兆、几十兆，甚至达到GB级别的体量。这个体量下，BLOB撑不住了：写入逐渐被拒绝。更麻烦的是，想在一个大对象里抽取一小块特征，比如从一整幅卫星云图里抠出某个网格，数据库只能把整块数据搬到客户端再处理，网络和算力的开销大到难以承受。

对此，乔嘉林给的建议是，每个领域都有自己的文件格式，图片格式、视频格式、仿真数据格式，它们在各自的应用里运转良好，有自己的编码和压缩结构。数据库要做的不是消灭这些格式，而是兼容并包，通过一个统一的“对象”对它们进行组织、访问和处理。

在这种理念下，天谋科技提出了面向AI特征提取的数据类型OBJECT，可以把它当作AI的对象类型。与传统的黑盒操作二进制不同，OBJECT让数据库知道对象的具体结构，怎么组织的、数据结构是什么、怎么提取里面的字段信息。这样一来，对多模态数据的操作就不再是“把黑盒子搬来搬去”，而是在数据库里就能做加工和处理。

以文章开头提到的飞机飞行姿态分析场景为例，采用这种理念之后，飞参数据、驾驶舱语音、机载视频、图像，已经能在同一个多模态时序数据库里统一管理，业务侧不必再部署多套系统、再在应用层做拼装。据乔嘉林介绍，这套能力目前已落地航空、气象、具身智能等多个领域。

不过，把不同形态的数据统一管起来，只解决了工业AI面临的第一层问题。真正进入模型训练和分析阶段之后，企业很快还会遇到另一个矛盾：数据明明已经积累了很多年，AI却未必能够顺畅地把这些数据用起来。

数据能存了，AI却“没饭吃”

立足工业场景，对于动辄运转了几十年的工业企业来说，传感器每秒钟都在往数据库里灌数据，比如炼钢炉的温度曲线、输油管道的压力波动、发动机的转速记录，多年积累了海量的数据。然而进入AI时代，企业内部想让AI真正跑起来，发挥价值，却发现被数据“卡”了脖子。

对此，乔嘉林告诉我们，AI时代，工业企业需要的数据与十年前已经截然不同。

十年前，工业现场的需求很简单：把传感器采集的温度、压力、电流等数值存下来，不丢数据，查询速度够快即可。那时候的时序数据库就像一个仓库管理员，它的核心任务是“存得下、查得到”。但今天，企业的诉求变了，他们不再满足于只是把数据存起来，而是希望这些数据能直接喂给AI模型，让机器能看懂设备的状态，预测未来的趋势，甚至自动做出决策。

乔嘉林提到了一个典型的困境：“企业问我们，我存了这么多年的数据，到底能不能发挥价值？”这个问题触及了数据库架构的根本矛盾。传统数据库是为应用系统设计的，支持的是点的查询和少量的统计分析。但AI对数据的使用“更暴力”，海量的全量扫描、随机扫描，负载量级完全不同。更麻烦的是，生产环境的数据库往往隔离在内网，有专门的DBA值守，要保证生产环境的负载稳定和可控，想随意增加计算负载或导出数据都受到严格限制。

这个挑战除了在企业应用AI过程中存在，在具身智能领域也普遍存在。具身智能企业四处喊缺数据，但乔嘉林表示，他与相关企业交流后发现一个细节：机器人正常行走的数据，他们并不缺，也基本没用了，正常场景早就被模型学会；真正缺的是异常场景的数据，缺的是机器人摔倒、碰撞、卡死时传感器记下的那些“稀有样本”。

也就是说，AI时代的数据问题已经不仅仅是“有没有数据”，还包括“能不能在不影响生产系统的前提下，把真正需要的数据高效交给AI”。

针对这一问题，TimechoDB 采用的AI Ready的开放式架构能够很好的解决。当 AI 需要从数据库中迁移大量数据出来时，不再需要通过数据库查询引擎查询数据，只需要将TimechoDB底层的时序数据文件TsFile拷贝出来，即可形成 AI 可用的时序数据集，对数据库造成的影响降到最低。

事实上，从数据库到时序AI，围绕时序数据的技术和应用生态已经形成了相当规模。据不完全统计，Apache IoTDB开源数据库累计下载量已达1350多万次，累计管理的数据总量超过100PB；企业版激活套数超过5000套；时序大模型Timer自发布以来，累计下载量超过3000万次。

但数据规模越来越大、AI工具越来越成熟，并不意味着模型就能直接解决工业现场的问题。把数据高效送到AI手中，只解决了“AI能不能拿到数据”的问题。拿到数据，并不等于模型真正理解了这些数据。对于工业场景而言，真正决定模型效果的，往往恰恰是企业多年积累下来的工况特征和领域知识。

这也是ToB领域与ToC的AI应用的不同之处，ToC领域的模型可以从海量公开数据中学习知识，而工业数据并不公开，也很少存在于通用数据集中，更多沉淀在企业自己积累多年的工况数据里。每一套装备都有自己独特的数据特征，包括所在地的环境、运行的习惯、老化的节奏。这些是企业的“独家记忆”，也是时序大模型最稀缺的上下文。

为什么时序大模型需要这些企业自身的数据和工况知识？在大语言模型时代，模型的领域知识是人说的话，遵循的是自然语言的逻辑。但时序数据不一样，A企业的设备数据和B企业的设备数据，底层逻辑可能完全不同。一个通用的时序基础模型可以做比较通用的分析，但要解决特别专业的问题，还是有差距。这个差距就来自于它不了解数据本身的特点。

所以需要结合领域数据做模型的后训练，甚至场景适配，做出一个专用模型。乔嘉林把时序模型分成三个层级：基础时序大模型（学习时序数据的通用概念）、领域时序大模型（融入某个行业的大量数据，比如油气或航天领域）、场景模型（针对具体问题，如压缩机异常诊断、管道压力预测，需要绑定更精准的数据和专家知识）。随着上下文的不断植入，模型的专业化水平逐级提升。 

时序数据库的边界在哪里？

从统一管理多模态数据，到为AI提供高效的数据供给，再到支撑更深入的模型训练和场景适配，时序数据库正在一步步向工业AI的应用链路深处延伸。一个更根本的问题也随之出现——时序数据库的边界究竟在哪里？是应该更垂直，还是应该“大而全”？

面对我们提出的这个问题，乔嘉林的回答很务实：要围绕着场景的需求出发。如果不考虑场景需求，做得全而广是一个理念，做得专而细也是一个理念，两个理念在一定程度上都是对的。关键是要结合具体场景来看，“往横着扩一点点，能不能解决用户很大的问题？往深钻一深，能不能帮助用户解决很大的问题？”乔嘉林如是说。

从时序数据的大范畴层面出发，现实中采集到的所有数据，无论是传感器采集的数值曲线，还是照片、音频，都与时间天然相关。不管是存到了关系数据库、对象存储，还是文件系统，它们都是带时间戳的，不然无法按时间分析。“从这个角度讲，世界上产生的数据都在时间维度下面，可以被时间维度管理起来，”乔嘉林进一步表示，“剩下的问题是：在一个具体业务里面，用户对哪类数据的管理需求更迫切？”

乔嘉林告诉我们，有的场景对数值类型的吞吐管理更迫切，这时候就要做得更垂直，性能做得更高。有的场景只是希望对多模态数据进行管理，提供更多功能性、应用性的能力，这时候就需要“大而全”，“毕竟还是有一定的倾向性和优先级，需要结合具体场景以及当前数据库的状态来做判断。”乔嘉林强调道。

这种平衡的背后，是对数据库复杂度的控制。乔嘉林提到一个观点：数据库要控制它的复杂度，不能什么都做，不该做的就不要做。但这个标准没法用详细规则写出来，更多是靠团队的综合判断。

这种判断能力，恰恰是时序数据库厂商的核心竞争力。大型软件做得好不好，往往取决于几个很关键的判断点：团队对于问题的判断是往前走一步，还是往左走一步，结果会很不一样。

回顾时序数据库过去十几年的发展，有一条清晰的线索：从存得下到查得快，再到智能化。2026年的数据库行业，正处于一个微妙的节点。技术在推陈出新的同时，场景、市场都在不断增加，尤其是工业领域，从炼钢高炉的温度监控，到飞机发动机的故障预测，再到具身智能机器人的运动控制。在工业领域，数据库要做的事，就是听懂这个世界每一台机器说的话。（本文首发于钛媒体APP，文｜Leo张ToB杂谈，作者｜张申宇，编辑丨盖虹达）