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

在一家航空企业的现场，工程师们接到一个任务：分析某架飞机的飞行姿态，锁定重点工况。提需求的人觉得这事不难，把各类数据按时间轴对齐就行，业内叫“时标对齐”。在数据库工程师的教科书里，这甚至算不上一道难题：按时间列做个连接，完事。 但真到了现场，事情立刻变了味道。需要对齐的不只是气压、高度、电流、电压、速度、姿态这些常规的数值，还有驾驶舱里录下的语音、机载摄像头拍的图片。更要命的是，这些数据压根不在同一个系统里：数值数据在时序数据库，图片、文本和文档散落在文件系统，还有些被扔进了对象存储。想做一次完整的分析，工程师得先当“搬运工”，把数据从各个系统里捞出来、汇到一处，再逐段拼装对齐，每一次分析，都是一遍重复劳动。 于是，用户向数据库厂商抛出了一个问题：既然我们对这些数据的所有分析都是沿着时间维度展开的，那语音、图片、文档等数据，算不算时序数据？天谋科技CTO乔嘉林给出了他的回答：时序数据的类型，确实不应该只有数值。 进击的数据库 当工业AI开始进入真实生产场景，第一个摆在数据库面前的问题，就是这些原本散落在不同系统、不同介质中的数据，能不能被统一组织和管理起来。 面对管理多模态数据的需求，数据库开发者的第一反应是：尽量不重复造轮子。 乔嘉林表示，天谋科技最先尝试的是BLOB方案，把图片、文本当成一整个二进制数据存进去。实验结果：部分可行。当多模态数据只有几KB、几十KB时，把它们当成一种特殊的数值类型，与传统时序数据放在一起建模、查询，都没问题，还能轻松地统一交给客户端分析。 但随着观测精度提升，高分辨率卫星云图、高清视频涌入数据库，单个对象动辄几兆、几十兆，甚至达到GB级别的体量。这个体量下，BLOB撑不住了：写入逐渐被拒绝。更麻烦的是，想在一个大对象里抽取一小块特征，比如从一整幅卫星云图里抠出某个网格，数据库只能把整块数据搬到客户端再处理，网络和算力的开销大到难以承受。 对此，乔嘉林给的建议是，每个领域都有自己的文件格式，图片格式、视频格式、仿真数据格式，它们在各自的应用里运转良好，有自己的编码和压缩结构。数据库要做的不是消灭这些格式，而是兼容并包，通过一个统一的“对象”对它们进行组织、访问和处理。 在这种理念下，天谋科技提出了面向AI特征提取的数据类型OBJECT，可以把它当作AI的对象类型。与传统的黑盒操作二进制不同，OBJECT让数据库知道对象的具体结构，怎么组织的、数据结构是什么、怎么提取里面的字段信息。这样一来，对多模态数据的操作就不再是“把黑盒子搬来搬去”，而是在数据库里就能做加工和处理。 以文章开头提到的飞机飞行姿态分析场景为例，采用这种理念之后，飞参数据、驾驶舱语音、机载视频、图像，已经能在同一个多模态时序数据库里统一管理，业务侧不必再部署多套系统、再在应用层做拼装。据乔嘉林介绍，这套能力目前已落地航空、气象、具身智能等多个领域。 不过，把不同形态的数据统一管起来，只解决了工业AI面临的第一层问题。真正进入模型训练和分析阶段之后，企业很快还会遇到另一个矛盾：数据明明已经积累了很多年，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企业的设备数据，底层逻辑可能完全不同。一个通用的时序基础模型可以做比较通用的分析，但要解决特别专业的问题，还是有差距。这个差距就来自于它不了解数据本身的特点。 所以需要结合领域数据做模型的后训练，甚至场景适配，做出一个专用模型。乔嘉林把时序模型分成三个层级：基础时序大模型（学习时序数据的通用概念）、领域时序大模型（融入某个行业的大量数据，比如油气或航天领域）、场景模型（针对具体问题，如压缩机异常诊断、管道压力预测，需要绑定更精准的数据和专家知识）。随着上下文的不断植入，模型的专业化水平逐级提升。 时序数据