我是AI时代的无业游民，我游荡在现实与意念之间
不止于时序存储：DolphinDB 如何成为 AI 时代的工业智能底座
工业数据基础设施正在经历一次不太显眼但很关键的转向。过去几年，行业讨论的焦点是"能不能把传感器数据存下来"；现在，问题变成了"存下来的数据能不能直接喂给模型、能不能在毫秒级完成特征计算、能不能同时支撑实时决策和历史回溯"。DolphinDB 这类时序数据库被重新拿出来讨论，本质上不是因为存储本身变难了，而是因为 AI 对数据底座的要求变了------它要求存储、计算、分析在同一套系统里完成，而不是像过去那样把数据搬来搬去。
30 秒结论
- 本文判断：时序数据库的竞争重心正从"写入吞吐 + 压缩比"转向"计算下推能力 + 与模型训练/推理链路的衔接能力"。DolphinDB 被当作"工业智能底座"讨论，反映的是这一趋势，而非单纯的产品宣传。
- 适用对象：正在做工业物联网、设备预测性维护、量化分析方向项目的在校学生与转行者；需要理解"数据底座"在 AI 链路中位置的人。
- 不适合谁：只想学 SQL 语法、不打算接触真实数据链路的人；以及期待本文给出某产品选型结论的人------本文不做选型推荐。
- 一句话建议：把"能写一段在时序库内完成特征计算的代码"作为作品集里的一小块能力，比堆砌工具名更有说服力。
关键证据
事实一：计算下推成为主流诉求。 工业场景里，一个振动传感器每秒可能产生数千个点，一个工厂有上千个测点。如果特征计算（滑动窗口均值、峰值、频谱）放在应用层做，数据要先出库再进模型，延迟和带宽都吃不消。把计算下推到存储层，是近年时序数据库和实时分析系统共同的技术方向。DolphinDB 主打的就是在库内用类 SQL 脚本完成流批一体的计算。
事实二：AI 链路对"特征工程位置"提出新要求。 当前主流大模型（如 GPT-5.5、Qwen3.6 Max、GLM 5.1、DeepSeek 4.0 Pro 等）在工业场景中更多承担的是"基于结构化特征的推理与交互"，而不是直接吃原始时序流。这意味着特征计算的质量和时效性，直接决定了下游模型能不能用。数据底座因此从"仓库"变成了"特征工厂"。
合理推断：未来 1--3 年，时序数据库与向量库、特征存储的边界会进一步模糊，"一套系统完成从原始点到特征向量"会成为工业 AI 项目的常见架构诉求。这一点我标注为推断，因为目前各家产品的融合程度差异很大，尚无统一标准。
展开说明
理解这件事，关键是把"数据底座"在 AI 链路里的位置画清楚。一个典型的工业智能项目，链路大致是：采集 → 存储 → 特征计算 → 模型训练/推理 → 决策回写。传统做法是每一段用不同系统，段与段之间靠 ETL 搬运。问题在于，搬运本身有延迟、有丢失、有版本不一致。
DolphinDB 的设计思路是把"存储"和"特征计算"放在同一层。对学习者来说，不需要理解它内部的分区、副本机制，只需要抓住一个可迁移的概念：计算下推。下面这段伪代码展示的是一种典型写法------在库内直接算滑动窗口特征，而不是把数据拉出来再算：
sql
-- 在时序库内直接计算每个设备的滑动窗口特征（示意，非特定版本语法）
SELECT device_id,
window_start,
avg(vibration) AS v_avg,
max(vibration) AS v_max,
std(vibration) AS v_std
FROM sensor_stream
GROUP BY device_id, window(60s)这段代码小，但它对应了一个面试常被追问的点：为什么特征计算要放在数据层而不是应用层？ 答案不是"性能更好"这种空话，而是三个具体约束------数据量导致搬运成本高、实时性要求导致链路不能太长、训练与推理必须用同一套特征定义以保证一致性。能把这三个约束讲清楚，比会背某个产品的参数更有价值。
再往深一层，工业智能里还有一个容易被忽视的约束：历史回放。模型上线后要回溯验证，就需要在历史数据上重算特征。如果特征逻辑写在应用代码里，回放时容易和线上逻辑漂移；写在数据层，回放和线上用的是同一段逻辑。这是"底座"这个词的真正含义------它不只是存，而是让计算有唯一可信的来源。
落地建议
第一件：动手写一段窗口特征计算。 不需要装 DolphinDB，用任意支持窗口函数的环境（比如本地跑一个轻量时序库，或直接用 pandas 模拟）写一段"按设备、按 60 秒窗口算均值/峰值/标准差"的代码，并写清楚为什么这样切窗口。这段代码可以直接放进作品集，配一段 200 字的说明。
第二件：画一张链路图。 把你做过的项目（课程设计也算）按"采集→存储→特征→模型→决策"画出来，标出每一段之间数据是怎么流动的、有没有搬运。这张图能帮你在面试里回答"你的数据是怎么到模型里的"这类问题。
第三件：准备一个反例。 想清楚"什么情况下不该把计算下推"------比如特征逻辑频繁变更、团队没有库内脚本维护能力时，下推反而增加耦合。能说出反例，说明你不是在背概念。
风险与反例
结论不成立的情况之一：项目数据量很小、实时性要求低。这时候把特征计算放在应用层完全够用，引入库内计算只会增加学习成本和运维负担。
结论不成立的情况之二：团队规模小、没有专人维护数据层脚本。库内脚本一旦成为特征定义的唯一来源，它的可测试性、版本管理就需要额外投入，小团队容易顾此失彼。
需要标注的不确定性：本文对"时序库与特征存储融合"的趋势判断，基于当前公开的技术方向和产品演进，但具体到某一款产品能否长期胜出，我无法判断，也不建议读者据此做选型决策。对在校学生和转行者而言，真正可迁移的是"计算下推""特征一致性""历史回放"这几个概念，而不是某个产品的 API。