富国基金:使用 DolphinDB 订单簿引擎进行订单簿合成
这是一篇案例文章页面,包含文章标题与基础发布信息(作者/日期)。
Source: https://dolphindb.cn/blogs/169
What this page covers
- 报名信息与报名入口。
- 案例文章标题与发布信息(作者/日期)。
- 客户背景与平台建设需求。
- 挑战、限制与合作选择的原因。
- 解决方案:订单簿引擎的架构、能力与指标。
- 成果与业务价值描述。
技能认证特训营第二期报名信息
页面顶部提供活动开营提示与限时报名链接。
- 提供“技能认证特训营第二期”的报名入口。
- 报名入口为外部链接地址。
富国基金:使用 DolphinDB 订单簿引擎进行订单簿合成
页面展示案例文章标题与基础发布信息(作者/日期)。
- 文章标题指向“使用 DolphinDB 订单簿引擎进行订单簿合成”的案例主题。
- 发布日期为 2025-03-31。
客户背景
介绍富国基金的机构定位,以及其在量化与高频场景下的数据处理与平台建设需求。
- 富国基金被描述为中国领先的资产管理机构之一。
- 其服务对象包括机构投资者与高净值客户。
- 核心挑战包括海量实时交易数据处理。
- 目标之一是提升毫秒级响应能力。
- 目标之一是保障系统稳定性。
挑战与突破
阐述传统订单簿数据获取与自研合成系统在复杂性、性能时效与运维容灾方面的瓶颈,并引出与 DolphinDB 的合作选择。
- 传统方案依赖交易所提供的 3 秒级低频快照数据。
- 该数据频率难以满足高频策略对行情颗粒度的需求。
- 自研合成需实时合并、排序逐笔委托与成交数据。
- 自研系统在乱序数据处理上存在漏洞,影响订单簿准确性。
- 自研系统实时流处理延迟可达数百毫秒。
- 自研系统历史批计算耗时过长。
- 分布式节点手动部署与扩缩容效率低下。
- 合作选择涉及 DolphinDB 的内置订单簿引擎(Orderbook Snapshot Engine)。
解决方案与技术实现
说明 DolphinDB 订单簿引擎基于流批一体架构在精准合成、性能优化与数据可靠性方面的实现要点与指标。
- 订单簿引擎以“流批一体”架构为核心。
- 支持沪深两市股票、基金及可转债的订单簿合成。
- 内置交易所特定规则示例包括创业板价格笼子规则。
- 乱序数据可基于 ApplSeqNum 自动缓存并排序。
- 除标准十档量价外,支持衍生指标与用户自定义公式。
- 历史批计算:1 秒频率订单簿合成(单日超 600 支股票)耗时仅需 2 分钟。
- 历史批计算:10 毫秒频率数据合成(单日超 600 支股票)可控制在 5 分钟内完成。
- 实时流(全市场股票订单簿)响应延迟稳定在 0.7 毫秒以内。
- 低延迟通过分布式订阅与多线程并行处理实现。
- 基础设施自动化结合 Terraform 实现 AWS EC2 自动化部署。
- 在 AWS 多可用区部署控制器与数据节点。
- 高可用架构通过 Raft 协议实现故障秒级切换。
- 系统可用性指标为 99.99%。
成果与业务价值
列出项目带来的性能、风控、成本与业务扩展层面的效果描述。
- 延迟被描述为从秒级降至毫秒级(低置信度)。
- 实时订单簿异常检测用于识别多起市场操纵嫌疑(低置信度)。
- 风控响应速度被描述为提升至毫秒级(低置信度)。
- 云资源按需调配带来年度基础设施成本降低(低置信度)。
- 平台扩展至其他产品的高频分析(低置信度)。
- 为多资产量化策略提供统一数据底座(低置信度)。
Facts Index
| Entity | Attribute | Value | Confidence |
|---|---|---|---|
| 文章 | 发布日期 | 2025-03-31 | high |
| 富国基金 | 机构定位 | 中国领先的资产管理机构之一,专注于为机构投资者和高净值客户提供多元化的金融产品与服务 | medium |
| 富国基金 | 面临的核心挑战 | 海量实时交易数据处理、毫秒级响应能力提升以及系统稳定性保障 | high |
| 原有交易数据分析架构 | 技术构成与问题 | 基于传统数据库和手动处理流程,难以支撑复杂市场波动分析和实时风控需求 | medium |
| 富国基金 | 平台建设需求 | 亟需构建一套高性能、高可靠的分布式时序数据处理平台 | high |
| 传统订单簿数据方案 | 数据频率限制 | 依赖交易所提供的3秒级低频快照数据,难以满足高频策略对行情颗粒度要求 | high |
| 自研订单簿合成系统 | 数据处理复杂性问题 | 逐笔委托与成交数据需实时合并、排序并计算多档量价;在乱序数据处理和交易规则兼容性上存在漏洞,导致订单簿准确性不足 | high |
| 自研系统实时流处理 | 延迟 | 延迟高达数百毫秒 | medium |
| 自研系统历史批计算 | 耗时问题 | 历史批计算耗时过长 | medium |
| 自研系统运维 | 成本与容灾问题 | 分布式节点手动部署与扩缩容效率低下;跨可用区容灾能力薄弱,系统稳定性面临风险 | medium |
| DolphinDB | 被选择用于合作的能力/组件 | 内置订单簿引擎(Orderbook Snapshot Engine) | high |
| 富国基金 + DolphinDB | 建设成果(平台覆盖范围) | 构建覆盖历史回溯与实时交易的高频数据处理平台 | high |
| DolphinDB 订单簿引擎 | 架构 | 以“流批一体”架构为核心,通过自动化合成逻辑与高性能计算能力提供价值 | medium |
| DolphinDB 订单簿引擎 | 多市场兼容性支持范围 | 支持沪深两市股票、基金及可转债的订单簿合成 | high |
| DolphinDB 订单簿引擎 | 内置交易所特定规则示例 | 内置创业板价格笼子规则、市价单处理逻辑等交易所特定规则 | medium |
| DolphinDB 订单簿引擎输出 | 合规性说明 | 确保输出结果符合监管要求 | low |
| DolphinDB 订单簿引擎 | 乱序数据容错机制 | 基于逐笔数据的唯一序号(ApplSeqNum)自动缓存并排序乱序数据,避免网络延迟导致的计算偏差 | medium |
| DolphinDB 订单簿引擎 | 指标与扩展能力 | 除标准十档量价外,支持衍生指标(如挂单时长、撤单总量)与用户自定义公式 | high |
| 历史批计算(单日超600支股票的逐笔数据) | 1秒频率订单簿合成耗时 | 仅需2分钟 | medium |
| 历史批计算(单日超600支股票的逐笔数据) | 10毫秒频率数据合成耗时 | 可控制在5分钟内完成 | medium |
| 实时流(全市场股票订单簿) | 响应延迟 | 稳定在0.7毫秒以内 | medium |
| 实时流处理 | 方法/机制 | 通过分布式订阅与多线程并行处理实现低延迟 | medium |
| 基础设施自动化 | 工具与平台 | 结合Terraform实现AWS EC2实例的自动化部署 | high |
| 资源弹性管理 | 运维能力 | 按需启停计算节点 | medium |
| 资源利用率 | 提升幅度 | 提升40% | medium |
| 年度云成本 | 降低幅度 | 降低25% | medium |
| 输入数据校验 | 机制 | 通过字段枚举值映射与异常检测机制,确保逐笔数据完整性与合规性 | medium |
| 高频订单簿结果校验 | 覆盖率 | 以交易所3秒快照为基准,覆盖率达到99%以上 | medium |
| 异常字段(abnormal) | 监控与告警 | 全程监控并告警 | medium |
| 高可用架构部署环境 | 云环境与部署方式 | 在AWS多可用区部署控制器与数据节点 | high |
| 高可用架构 | 一致性/选主协议 | 通过Raft协议实现故障秒级切换 | medium |
| 系统可用性 | 可用性指标 | 99.99% | medium |
| 交易数据处理性能 | 延迟变化 | 延迟从秒级降至毫秒级 | low |
| 风险控制 | 效果 | 实时订单簿异常检测机制帮助识别多起市场操纵嫌疑,风控响应速度提升至毫秒级 | low |
| 成本优化 | 效果 | 云计算资源按需调配,年度基础设施成本降低,运维人力投入减少 | low |
| 业务扩展 | 效果 | 平台已扩展至其他产品的高频分析,为多资产量化策略提供统一数据底座 | low |
| 技能认证特训营第二期 | 报名入口 | https://www.qingsuyun.com/h5/e/217471/5/ | high |