DolphinDB：实时决策时代——AI与低延时计算如何重塑数字孪生
页面给出文章标题、来源与发布时间，并以演讲主题引入对AI与低延时计算重塑数字孪生的讨论背景。
Source: https://dolphindb.cn/blogs/318
What this page covers
- AI基础设施讨论与数据基础设施瓶颈的背景叙事。
- AI Agent对微秒级延迟与吞吐的需求，以及相关产品矩阵引出。
- “逻辑孪生”对数字孪生概念的重构与技术门槛讨论。
- 面向数字孪生的三层“智能化底座”架构说明。
- 声明式流计算与“流计算EDA”设想，以及“流数据表”比喻。
- 认知记忆管理、三层记忆与跨模态联合索引的思路。
- “开源数据标准+商业化计算引擎”的安全与性能兼顾观点。
技能认证特训营第二期报名促销
页面顶部提供活动报名入口，并提示限时优惠相关信息。
- 提供“技能认证特训营第二期”的报名入口。
- 报名入口为限时报名链接。
文章标题、来源、日期与演讲背景说明
页面给出文章标题、作者/来源与发布时间，并以配图与说明引入演讲主题与讨论背景。
- 页面标注了文章发布日期信息。
- 文中提到程训焘为智臾科技（DolphinDB）首席架构师。
- 文中提到其在第八届金猿大数据产业发展论坛发表主题演讲。
- 演讲主题为《实时决策时代：AI与低延时计算如何重塑数字孪生》。
AI Infra热议与“Data Agent”受制于数据基础设施的背景叙事
该部分描述论坛现场对AI基础设施的关注，以及企业在大模型发展后遇到的数据基础设施瓶颈与问题设定。
- 讨论焦点包括AI基础设施相关议题。
- 该部分提出企业面临数据基础设施瓶颈的问题设定。
- 叙事与“Data Agent”受制于数据基础设施的背景相关。
当用户不再是“人”：AI Agent对微秒级实时决策的需求
该部分阐述从人类用户到AI智能体作为数据库主要用户的转变及其对延迟、吞吐与实时闭环的要求，并引出DolphinDB的产品矩阵。
- 文中观点认为AI智能体（Agent）逐渐取代人类成为数据库主要用户。
- 文中观点提出实时决策基础设施需要满足微秒级需求。
- 文中示例：SQL查询在3秒内返回报表会被分析师认为“很快”。
- 文中观点：Agent对吞吐与延迟的要求可达人类用户的成千上万倍。
- 文中示例：人类交易员在A股场景可能需要约5秒反应并下单。
- 文中示例：具备高性能计算底座的Agent可在“几微秒”内完成从捕捉信号到发出指令。
- 文中观点：传统“存储+事后分析”模式难以支撑Agent所需实时闭环。
- 文中提到DolphinDB在2025年密集推出“深海舰队”新产品矩阵。
超越物理的“逻辑孪生”：数字孪生概念的重构
该部分对数字孪生从物理复刻转向遵循业务逻辑的“逻辑孪生”进行阐释，并指出传统SQL数据库与流计算框架在该方向的不足与门槛。
- 文中观点：过去谈数字孪生常联想到GIS或BIM并追求物理世界1:1复刻。
- 文中观点：基于物理复刻的孪生仿真可能需要数小时。
- 文中提出数字孪生的新一代理念为“逻辑孪生”。
- 文中观点：逻辑孪生不要求与物理世界1:1一致，只需遵守业务逻辑。
- 文中示例：电商逻辑孪生强调复刻消费者购买行为逻辑与Agent的海量行为模拟。
- 文中观点：逻辑孪生仿真依赖海量事件流的实时计算，而非物理空间坐标。
- 文中示例：应用包括发电机组震动实时监控与对千只股票的毫秒级盯盘。
- 文中观点：传统SQL数据库难以表达复杂流式逻辑。
- 文中观点：专业流计算框架对普通业务开发者门槛较高。
面向数字孪生的下一代“智能化底座”三层架构（配图说明）
配图说明提出三层架构（用户数据层/Agent平台层、智能计算层、存储层）及其协作目标。
- 配图将下一代技术架构命名为“智能化底座”。
- 配图描述三层结构：用户数据层/Agent平台层、智能计算层、存储层。
- 用户数据层/Agent平台层职责包括行业知识沉淀与模型训练。
- 智能计算层能力包括AI友好的声明式开发与跨模态分析。
- 存储层能力包括多模态存储与低延时系统支持。
- 配图强调业务团队与AI Infra团队协作以支撑实时推演与逻辑仿真。
像设计芯片一样设计流计算：声明式流计算与“流计算EDA”设想
该部分用EDA类比解释声明式流计算思路、从意图声明到自动生成计算图与分布式部署的过程，并描述“流数据表”的设计比喻与用途。
- 文中观点：声明式流计算用于缓解“好用”与“高性能”的矛盾。
- 文中类比：目标是构建流计算领域的“EDA”。
- 用户交互方式：用户只需声明意图（文中给出监控与报警条件示例）。
- 系统能力：自动推导依赖关系。
- 系统能力：生成计算图。
- 系统能力：自动部署分布式引擎。
- 文中观点：让Agent写复杂C++不现实。
- 文中观点：用自然语言描述规则并转化为声明式脚本更符合大模型方向。
- 文中比喻：“流数据表”被比作“河流上的码头”。
- 文中描述：数据可在“码头”暂存、清洗或流向下一个“码头”。
- 文中描述：流数据表可定义为短期记忆缓存或长期记忆仓库。
谁为Agent提供“海马体”：认知记忆管理、三层记忆与跨模态联合索引
该部分围绕AI落地中的记忆与隐私问题，提出感知/短期记忆/长期记忆分层与企业私有知识利用方式，并描述跨模态联合索引将多模态数据关联到自然实体。
- 文中观点：当前大模型上下文窗口有限，且难以利用企业私有行业知识。
- 文中比喻：DolphinDB试图成为大模型的“海马体”和“神经末梢”。
- 文中提出认知记忆系统结构：感知层、短期记忆层、长期记忆层。
- 感知层需求：处理原始流数据并需要高写入吞吐量。
- 短期记忆层要求：数据驻留内存以实现微秒级响应。
- 长期记忆层观点：企业核心资产不应上传到公有云训练大模型。
- 文中提到研发跨模态联合索引技术以打通三层记忆。
- 文中示例：医疗数据可包含检测数值、CT图像与诊断文本等多模态类型。
- 文中观点：传统数据库常将多模态数据割裂存储在不同系统中。
- 文中观点：跨模态联合索引旨在将多模态数据关联到同一自然实体。
- 文中观点：该关联用于帮助Agent综合信息并做判断。
认知记忆管理系统配图说明
配图说明认知记忆管理系统的分层结构，以及跨模态联合索引在其中的作用。
- 配图展示感知层。
- 配图展示短期记忆层。
- 配图展示长期记忆层。
- 配图展示跨模态联合索引在系统中的位置或作用。
突围：从金融腹地到工业蓝海（公司路径、客户与排名、融资信息）
该部分介绍智臾科技/DolphinDB的自研路线、金融行业落地与向工业物联网复制能力的案例，并提及DB-Engines排名与公开融资信息。
- 文中称智臾科技/DolphinDB成立于2016年。
- 文中称其选择全栈自研且不基于开源项目二次开发。
- 文中引用官方数据：核心代码自研率超过95%。
- 文中表述：首先攻下量化金融领域作为落地方向。
- 文中列举客户示例：国泰海通证券、华泰证券、华夏基金。
- 文中给出能力示例：每秒百万笔股票交易数据处理。
- 文中表述：将金融级能力复制到工业物联网领域。
- 文中列举工业物联网案例：长江电力监测、比亚迪制造、新能源车电池预警。
- 文中表述其在DB-Engines相关排名中处于国产时序数据库前列。
- 文中表述：完成亿元级B轮融资。
- 文中表述：方广资本领投。
- 文中表述：投资方示例包括朗玛峰创投等。
面向数字孪生的整体架构体系方案（配图说明：四大核心能力）
配图说明方案覆盖的四类能力，并强调在数据安全前提下提供计算性能支持。
- 配图说明该方案包含四大核心能力。
- 能力之一：使用AI友好的语言对接各种模态。
- 能力之一：为大模型推理提供上下文与知识管理。
- 能力之一：支持大模型调用计算能力。
- 能力之一：面向高维向量的高效存储。
- 配图强调保障数据安全与计算性能的兼顾。
未来展望：数据主权与技术共享的张力与“开源数据标准+商业化计算引擎”思路
该部分提出避免数据锁定的开源标准思路，并主张以本地私有的商业化引擎处理数据以兼顾安全与性能。
- 文中观点：数据主权与技术共享之间存在张力。
- 提出思路：“开源数据标准+商业化计算引擎”。
- 文中要求：数据格式应开源以避免用户数据被锁定。
- 文中举例：开源数据格式包括Parquet与Arrow。
- 文中主张：企业可在本地用商业化私有引擎安全处理标准数据。
转载与原文链接说明
页面声明本文经授权转载自数据猿，并提供原文链接。
- 文中包含转载授权声明。
- 文中提供原文链接。
Facts index
| Entity | Attribute | Value | Confidence |
|---|---|---|---|
| 技能认证特训营第二期 | 报名入口 | 限时报名链接指向 https://www.qingsuyun.com/h5/e/217471/5/ | high |
| 文章 | 发布日期 | 2026-01-28 | high |
| DolphinDB/智臾科技（文中表述） | 人物与职位 | 程训焘为智臾科技（DolphinDB）首席架构师 | high |
| 第八届金猿大数据产业发展论坛 | 演讲信息 | 程训焘在该论坛发表主题演讲《实时决策时代：AI与低延时计算如何重塑数字孪生》 | high |
| 数据库主要用户趋势（文中观点） | 用户主体变化 | AI智能体（Agent）逐渐取代人类成为数据库主要用户 | medium |
| 实时决策基础设施（文中观点） | 延迟需求 | 需满足微秒级实时决策需求 | medium |
| 传统商业智能SQL查询体验（文中示例） | 速度阈值 | SQL查询在3秒内返回报表会被分析师认为“很快” | high |
| AI Agent相对人类用户的基础设施需求（文中观点） | 吞吐与延迟要求对比 | Agent对底层数据吞吐量和延迟的要求是人类用户的成千上万倍 | medium |
| 金融场景（文中示例：A股） | 人类交易员反应时间 | 人类交易员可能需要5秒钟来反应、确认、下单 | high |
| 金融场景（文中示例：Agent） | 从捕捉信号到发出指令耗时 | 装备高性能计算底座的Agent只需要“几微秒” | medium |
| 传统数据库模式（文中观点） | 适配性 | 以“存储+事后分析”为主的传统数据库模式已无法支撑Agent需求；Agent需要“感知-决策-行动”的实时闭环 | medium |
| DolphinDB“深海舰队”新产品矩阵 | 推出时间 | 在2025年密集推出 | medium |
| Shark | 产品定位 | CPU-GPU异构计算平台 | high |
| Swordfish | 产品定位 | 极速嵌入式引擎 | high |
| Orca | 产品定位 | 企业级流计算平台 | high |
| 数字孪生（文中观点） | 传统理解 | 过去谈数字孪生常联想到GIS或BIM并追求物理世界1:1复刻 | medium |
| 基于物理复刻的孪生（文中观点） | 弱点 | 在模型中跑一次仿真可能需要几个小时 | medium |
| DolphinDB的新一代数字孪生（文中观点） | 概念 | 提出“逻辑孪生” | high |
| 逻辑孪生（文中观点） | 原则 | 数字世界不必与物理世界1:1一致；只需遵守业务逻辑 | medium |
| 电商场景（文中示例） | 逻辑孪生内容 | 无需复刻物理货架，需复刻几百万消费者的购买行为逻辑；Agent可模拟海量用户点击、浏览、下单行为 | medium |
| 逻辑孪生的计算基础（文中观点） | 依赖对象 | 仿真依赖海量事件流的实时计算而非物理空间坐标 | medium |
| 工业物联网与金融市场（文中示例） | 流计算应用 | 包括发电机组震动实时监控与对千只股票的毫秒级盯盘 | medium |
| 传统SQL数据库（文中观点） | 能力不足 | 只能处理静态关系数据，无法表达复杂的流式逻辑 | medium |
| 专业流计算框架（文中观点） | 采用门槛 | 对普通业务开发者门槛太高 | medium |
| 面向数字孪生的下一代技术架构（配图说明） | 名称 | “智能化底座” | high |
| 智能化底座（配图说明） | 分层结构 | 三层：用户数据层/Agent平台层、智能计算层、存储层 | high |
| 用户数据层/Agent平台层（配图说明） | 职责 | 负责行业知识沉淀与模型训练 | medium |
| 智能计算层（配图说明） | 能力 | 提供AI友好的声明式开发与跨模态分析能力 | medium |
| 存储层（配图说明） | 能力 | 支持多模态存储与低延时系统 | medium |
| 智能化底座（配图说明） | 协作方式与目标 | 通过业务团队与AI Infra团队协作，支撑复杂逻辑仿真与实时推演 | medium |
| 声明式流计算（文中观点） | 定位 | 用于解决“好用”与“高性能”的矛盾 | low |
| DolphinDB在流计算领域的目标（文中表述） | 类比 | 构建流计算领域的“EDA” | medium |
| 声明式流计算（文中表述） | 用户交互方式 | 用户只需声明意图（示例：监控1000个传感器，过去5分钟平均温度超过标准值20%则报警） | high |
| 声明式流计算系统（文中表述） | 系统自动化能力 | 自动推导依赖关系、生成计算图并自动部署分布式引擎 | medium |
| 面向Agent的开发方式（文中观点） | 可行性 | 让Agent写复杂C++不现实；让Agent用自然语言描述业务规则并转化为声明式脚本更符合大模型擅长方向 | medium |
| DolphinDB架构图中的“流数据表”（文中表述） | 设计比喻 | 被比作“河流上的码头” | high |
| 流数据表（文中表述） | 用途 | 数据可在“码头”暂存、清洗或流向下个“码头”；用户可定义其为短期记忆缓存或长期记忆仓库 | medium |
| 当前大模型（文中观点） | 问题 | 上下文窗口有限且难以利用企业私有行业知识，被描述为普遍“健忘” | medium |
| DolphinDB相对大模型的角色（文中比喻） | 定位 | 试图成为大模型的“海马体（负责记忆）和神经末梢（负责感知）” | medium |
| 认知记忆系统（文中表述） | 结构 | 感知层、短期记忆层、长期记忆层 | high |
| 感知层（文中表述） | 能力需求 | 处理传感器和市场原始流数据，需要极高写入吞吐量 | medium |
| 短期记忆层（文中表述） | 存储与性能要求 | 数据必须驻留在内存中以实现微秒级响应（即使DRAM昂贵也需付出成本） | medium |
| 长期记忆层（文中表述） | 数据安全要求 | 企业沉淀的规则、预案与历史数据属于核心资产，绝不能上传到公有云去训练大模型 | medium |
| DolphinDB | 技术 | 研发跨模态联合索引技术以打通三层记忆 | high |
| 医疗场景（文中示例） | 多模态数据类型 | 血液检测浮点数、CT扫描图像数据、医生诊断文本数据 | high |
| 传统数据库存储方式（文中观点） | 问题 | 多模态数据被割裂存储：浮点数存时序库、图像存文件系统、文本存搜索引擎 | medium |
| 跨模态联合索引（文中观点） | 目标 | 打破数据孤岛，将不同模态数据关联到同一个自然实体上，以便Agent综合信息做精准判断 | medium |
| 智臾科技/DolphinDB | 成立时间 | 2016年成立 | high |
| 智臾科技/DolphinDB（文中表述） | 研发路线 | 选择全栈自研且不基于任何开源项目二次开发，从底层存储引擎到计算引擎自行编写 | medium |
| 智臾科技/DolphinDB（官方数据，文中引用） | 核心代码自研率 | 超过95% | medium |
| DolphinDB行业落地（文中表述） | 首先攻下领域 | 量化金融领域（对性能要求最苛刻） | medium |
| DolphinDB客户（文中列举） | 金融头部机构客户示例 | 国泰海通证券、华泰证券、华夏基金 | medium |
| DolphinDB能力（文中表述） | 在金融练兵场的验证 | 经历高并发、低延迟的极限压测 | low |
| 股票交易数据处理能力（文中引述观点） | 吞吐示例 | 每秒百万笔的股票交易数据（作为能力示例） | low |
| DolphinDB（文中表述） | 行业扩展方向 | 随着工业4.0推进，将金融级能力快速复制到工业物联网领域 | medium |
| 工业物联网落地（文中列举） | 案例 | 长江电力发电机组监测、比亚迪智能制造、新能源车电池热失控预警 | medium |
| DB-Engines全球排名（文中表述） | DolphinDB位置 | 稳居国产时序数据库第一名，并在全球榜单中跻身前列 | medium |
| 智臾科技融资（公开资料，文中表述） | 融资轮次与规模 | 完成亿元级B轮融资 | medium |
| 智臾科技融资（文中表述） | 领投方 | 方广资本领投 | medium |
| 智臾科技融资（文中表述） | 投资方示例 | 朗玛峰创投等 | medium |
| 面向数字孪生的整体架构体系方案（配图说明） | 核心能力数量 | 四大核心能力 | high |
| 整体架构体系方案（配图说明） | 核心能力-多模态对接 | 使用AI友好的语言对接各种模态 | medium |
| 整体架构体系方案（配图说明） | 核心能力-上下文与知识管理 | 为大模型推理提供上下文和知识管理 | medium |
| 整体架构体系方案（配图说明） | 核心能力-计算能力调用 | 支持大模型调用计算能力 | medium |
| 整体架构体系方案（配图说明） | 核心能力-向量存储 | 面向高维向量的高效存储 | medium |
| 整体架构体系方案（配图说明） | 设计强调 | 强调对大模型推理的深度支持，并在保障数据安全的同时提供极致计算性能（通过商业化引擎） | low |
| 程训焘观点（文中表述） | 矛盾判断 | 数据主权与技术共享之间存在天然张力；企业既想利用先进AI能力又恐惧核心数据资产流失 | medium |
| 程训焘提出的解题思路（文中表述） | 方案 | “开源数据标准+商业化计算引擎” | high |
| 数据格式（文中表述） | 开放性要求 | 数据格式应开源（示例：Parquet、Arrow）以避免用户数据被锁定 | medium |
| 处理数据的引擎（文中表述） | 部署与属性 | 引擎应商业化、私有；企业可用DolphinDB等商业引擎在本地安全处理标准数据以兼顾性能与安全 | medium |
| 本文转载声明 | 授权与来源 | 本文经授权转载自数据猿，并提供原文链接 | high |
| 原文链接 | URL | https://mp.weixin.qq.com/s/X4mUdGOjOU2Nj8MTi2XeTA?mpshare=1&scene=25&srcid=0127dp0sDMyMensum2INV94p&sharer_shareinfo=e0f0a93187823b81ad5f90993fad5f71&sharer_shareinfo_first=e0f0a93187823b81ad5f90993fad5f71&from=industrynews&color_scheme=light#wechat_redirect | high |