从「2022数智交易未来论坛」看面向数据的敏捷开发
该页面属于新闻栏目内容，包含文章标题与发布日期信息。
What this page covers
- 活动推广信息与限时报名入口。
- 论坛背景、演讲人身份与演讲主题引入。
- 数据库角色从事务/分析到计算型数据库的演进讨论。
- 传统三层架构与两层架构的开发模式对比。
- 量化金融中高迭代与快速上线需求的示例。
- 计算型数据库的四方面特点概述。
- SQL与脚本语言融合及其对数据科学开发的意义。
技能认证特训营第二期正式开启（限时报名）
页面顶部包含活动推广与报名链接，并强调限时报名与专属福利优惠。
- 提及“技能认证特训营”第二期已正式开启。
- 提供限时报名链接入口。
- 包含“专属福利优惠”的报名描述。
新闻与文章标题/日期
新闻栏目下展示文章标题与发布日期信息。
- 文章标题为“从「2022数智交易未来论坛」看面向数据的敏捷开发”。
- 页面提供该文章的发布日期。
论坛背景与演讲引入
内容介绍论坛举办情况、演讲人身份与演讲主题，并引出“数据库在量化金融的新角色——面向数据的敏捷开发”。
- 提及“2022数智交易未来论坛暨卡方科技生态合作伙伴大会”。
- 论坛地点为内蒙古呼和浩特。
- 论坛举办日期为7月29日（年份语境为2022）。
- 演讲人包括DolphinDB联合创始人兼COO初阳春。
- 演讲主题为《面向数据的敏捷开发》。
数据库的角色演变
该部分讨论数据库从事务型到分析型，再到在库内完成复杂与流式计算的演进，并引出计算型数据库与DolphinDB的完善方向。
- 早期数据库更多承担存储与简单查询角色。
- 分析型数据库通常支持聚合、分组与窗口计算等简单计算。
- 更复杂计算传统上交由Python、Matlab等数据分析系统处理。
- 在TB级数据处理中，数据转换可能占据任务95%耗时。
- 文中提到20多年前出现第一个计算型数据库kdb+。
- 文中将DolphinDB描述为进一步完善计算型数据库的方向之一。
应用开发模式
该部分对比传统三层架构与建议的两层架构，讨论业务与IT协作方式以及对交付效率的影响。
- 传统应用开发常采用三层架构：数据层、应用层、表示层。
- 传统三层架构开发过程一般由IT部门主导。
- IT与业务互不熟悉会导致反复沟通与较长开发周期。
- 建议的新架构为两层：数据逻辑层与表示层。
- 两层架构将数据与业务逻辑封装在数据逻辑层。
量化金融中的敏捷开发需求
该部分用因子挖掘与风险控制等场景说明高迭代与快速上线需求，并提出计算型数据库可提升研发效率。
- 因子挖掘场景强调快速开发与迭代需求。
- 风险控制场景强调新风控指标希望尽快上线生产系统。
- 在现有系统中，风控指标从需求到对接可能需要几个月。
- 传统方式常将数据从数据库提取到计算引擎中完成相关工作。
- 文中主张计算型数据库可用于上述工作以提升研发效率。
计算型数据库特点（四方面）
该部分概括计算型数据库的四个特点，并表示将逐一解释。
- 特点之一：面向数据科学。
- 特点之一：处理异构数据。
- 特点之一：支持流式计算。
- 特点之一：实现产研一体。
面向数据科学（SQL与脚本语言融合）
该部分说明计算型数据库中SQL与脚本语言融合的必要性与方式，包括模块化/函数化/向量化与SQL作为编程对象，并涉及与分布式结合。
- 传统三层架构中应用逻辑层常通过ODBC/JDBC向数据库发出SQL查询。
- 文中描述传统模式下编程语言与SQL运行在不同空间。
- 文中主张计算型数据库中SQL与脚本语言应高度融合。
- 融合需要支持模块化、函数化与向量化，以提升可维护性。
- 文中描述SQL可作为变量/函数/表达式一样的对象使用。
- 文中描述SQL可调用数组、矩阵、字典、集合等数据结构。
- 文中描述SQL可与分布式编程结合并自动处理（反）序列化。
处理异构数据（数据湖 vs 多模态数据库）
该部分对比数据湖与多模态数据库，并说明计算型数据库通过多存储引擎与索引提升性能以满足量化需求。
- 文中将计算型数据库在机构中的角色比喻为分析任务的“大脑”。
- 文中给出处理异构数据的两种方式：数据湖与多模态数据库。
- 文中认为最简单的数据湖方案性能不足以满足量化金融的性能需求。
- 文中描述多模态数据库可用多种存储引擎存储不同格式数据。
- 文中描述可通过精细化索引提升性能。
支持流式计算（三种方案对比）
该部分比较量化机构流计算的三种选择，并描述DolphinDB的流计算功能与低代码开发主张。
- 文中描述量化机构在不完全自研情况下，流计算一般只有三种选择。
- 文中将Flink描述为通用流计算引擎，并支持流批一体。
- 文中称量化机构真正采用Flink的人较少，原因包括技术栈复杂与运维重。
- 文中将物化视图方案描述为简单易用，但只能用SQL。
- 文中将DolphinDB描述为计算型数据库代表之一，并提供流计算功能。
- 文中称DolphinDB内置多种流数据引擎以处理复杂流计算场景。
- 文中提出DolphinDB提供流计算低代码开发以降低开发成本。
实现产研一体（投研仿真与生产交易打通）
该部分讨论投研仿真与生产交易割裂的问题，并提出通过流批一体框架实现产研一体，同时指出需要多系统协作。
- 文中认为投研仿真与生产交易在许多机构中是割裂的。
- 文中描述若存在仿真系统，可加快策略从投研到生产的部署与反馈。
- 文中提到为开发效率常用Python/Matlab，为执行效率常用C++。
- 文中指出两套代码会增加开发成本。
- 文中主张流批一体框架可提升交易策略研发效率与研发质量。
- 文中指出需要计算型数据库、交易执行系统与算法交易平台协作。
Facts index
| Entity | Attribute | Value | Confidence |
|---|---|---|---|
| 技能认证特训营 | 期次/状态 | 第二期正式开启 | high |
| 限时报名链接 | url | https://www.qingsuyun.com/h5/e/217471/5/ | high |
| 技能认证特训营报名 | 优惠描述 | 享专属福利优惠 | low |
| 文章《从「2022数智交易未来论坛」看面向数据的敏捷开发》 | 发布日期 | 2022.08.04 | high |
| 2022数智交易未来论坛暨卡方科技生态合作伙伴大会 | 举办日期 | 7月29日（年份语境为2022） | medium |
| 2022数智交易未来论坛暨卡方科技生态合作伙伴大会 | 举办地点 | 内蒙古呼和浩特 | high |
| DolphinDB | 人物/职务 | 联合创始人兼COO 初阳春 | high |
| 初阳春论坛演讲 | 主题 | 《面向数据的敏捷开发》 | high |
| 演讲核心分享 | 主题表述 | 数据库在量化金融的新角色——面向数据的敏捷开发 | medium |
| DolphinDB创始团队背景 | 从业经历 | 曾在美国投资银行、量化私募与公募基金工作过10年 | medium |
| 创始团队数据库研发经历 | 时长 | 从事数据库系统研发到现在也有10年 | medium |
| 数据库角色演变（早期） | 最初角色 | 存储与一些简单的查询，主要由事务型数据库承担 | high |
| 分析型数据库（OLAP） | 能力描述 | 通常只能做简单计算（如聚合、分组、窗口计算等） | medium |
| 复杂计算处理方式（传统） | 工具 | 更复杂计算需交给Python、Matlab等数据分析系统 | high |
| TB级数据处理 | 耗时分布 | 数据转换可能占整个任务95%耗时 | medium |
| 现代海量数据场景 | 效率主张 | 复杂计算包括流式计算若可在数据库内完成将是最经济最高效方式 | low |
| 计算型数据库kdb+ | 出现时间 | 20多年前出现第一个计算型数据库kdb+ | medium |
| kdb+ | 开发者背景 | 由华尔街摩根斯坦利的一位工程师开发 | medium |
| kdb+与big data概念 | 时间描述 | 2000年左右还没有大数据（big data）概念 | medium |
| kdb+ | 使用情况 | 至今仍被很多海外机构使用 | low |
| 计算型数据库产生原因 | 驱动因素 | 量化金融的大规模数据量以及对性能的极致追求催生计算型数据库 | medium |
| DolphinDB | 定位/动作 | 进一步完善了计算型数据库 | medium |
| DolphinDB | 系统形态 | 提供原生的分布式系统 | medium |
| DolphinDB | 功能 | 提供更全面的数据处理函数 | low |
| DolphinDB | 语言/成本 | 使用成本更低的脚本语言 | low |
| 传统应用开发模式 | 架构 | 经典三层软件架构：数据层、应用层与表示层 | high |
| 传统三层架构开发主导方 | 组织角色 | 一般由IT部门主导整个开发过程 | medium |
| 传统开发协作 | 问题 | IT不熟业务、业务不熟IT，反复沟通导致数据类应用开发周期特别长 | medium |
| 案例：公募基金项目 | 交付周期 | 开发追踪期权投资组合风险指标界面前后花了半年 | medium |
| 案例：华尔街投行交易员需求 | 交付周期 | 制作Bloomberg系统没有的实时交易信号指标至少三个月 | medium |
| 建议的新架构 | 层次 | 两层：数据逻辑层和表示层 | high |
| 两层架构中的逻辑封装 | 位置 | 数据和业务逻辑封装在数据逻辑层（计算型数据库这一层） | medium |
| 两层架构分工 | 职责 | 业务部门主导核心逻辑开发；IT部门主导基础设施与开发框架 | medium |
| 三层架构实现方式 | 公式实现 | 业务部门给出的公式需要IT部门硬编码实现 | medium |
| 面向数据敏捷开发两层架构 | 公式实现 | IT搭好系统后业务部门可直接在系统中输入公式，开发变得迅速 | low |
| 量化金融敏捷需求场景 | 例子 | 因子挖掘：从几百万、上千万个因子中挖掘出几个因子，需要快速开发与迭代 | medium |
| 量化金融敏捷需求场景 | 例子 | 风险控制：发现新风控指标后希望尽快上线到生产系统 | high |
| 风控指标上线（现有系统） | 耗时 | 反映需求、开发、对接一般需要几个月 | medium |
| 传统方式下数据库能力边界 | 处理方式 | 这些工作传统上需把数据从数据库提取到计算引擎中完成 | high |
| 计算型数据库在敏捷开发中的作用 | 效果 | 可用于这些工作以大幅提升研发效率 | low |
| 计算型数据库特点 | 四个方面 | 面向数据科学、处理异构数据、支持流式计算、实现产研一体 | high |
| 传统三层架构数据访问 | 协议示例 | 应用逻辑层语言（如Java）通过ODBC、JDBC等协议向数据库发出SQL查询 | high |
| 传统架构中编程语言与SQL关系 | 运行形态 | 编程语言和SQL运行在不同空间中，没有任何交集 | medium |
| 计算型数据库中SQL与脚本语言关系 | 融合效果 | 两者高度融合：前者让开发更简单，后者让计算更灵活，可高效完成数据处理全流程 | low |
| Oracle存储过程 | 优点 | 很强大、敏捷、简单，DBA都喜欢 | low |
| Oracle存储过程 | 问题 | 不支持模块化/函数化编程；不支持向量化编程；代码量大难维护；代码复杂繁琐导致数据分析人员不喜欢 | medium |
| SQL与脚本语言融合的要求 | SQL编写能力 | 需要支持模块化、函数化、向量化，使代码简洁、高效、可维护并符合现代编程语言风格 | medium |
| SQL在编程语言中的地位（计算型数据库） | 编程对象化 | SQL可作为变量/函数/表达式一样的对象：可赋给变量、作为函数入参、成为函数实现的一部分 | medium |
| SQL与脚本语言互操作（计算型数据库） | 调用能力 | SQL可调用编程语言数据结构（数组、矩阵、字典、集合等）、自定义函数、变量；并可与分布式编程结合，系统自动进行代码和数据（反）序列化 | medium |
| 计算型数据库在机构中的角色 | 比喻/定位 | 应作为机构分析任务的“大脑”，处理不同来源与结构的异构数据 | low |
| 处理异构数据的两种方式 | 方案 | 数据湖；多模态数据库 | high |
| 最简单的数据湖解决方案 | 方式与不足 | 用各种原始数据文件存储可存所有格式，但性能不够好，不能满足量化金融极致性能需求 | medium |
| 计算型数据库的异构数据处理方式 | 方案 | 采用多模态数据库：通过多种存储引擎针对性存储不同格式/场景的数据，并通过精细化索引提升性能 | medium |
| 量化机构流计算方案选择（非完全自研） | 选项数量 | 一般只有三种选择 | medium |
| Flink | 定位/能力 | 通用流计算引擎；非常强大；实现流批一体；在互联网公司应用广泛 | medium |
| Flink在量化金融机构的采用 | 原因 | 真正用起来的人很少，因为技术栈复杂、部署运维重、开发门槛高；量化所需复杂计算开发难度尤其高 | medium |
| 客户对Flink开发成本的反馈 | 原因 | 很多因流计算需求而来的客户认为Flink开发成本太高 | low |
| Redshift（物化视图方案代表） | 方案特点 | 物化视图方案简单易用，但只能使用SQL语句，无法处理量化金融复杂场景需求 | medium |
| DolphinDB | 流计算能力 | 作为计算型数据库代表提供流计算功能；内置多种流数据引擎，可处理复杂流计算场景 | medium |
| DolphinDB流计算开发 | 开发方式/效果 | 提供流计算低代码开发，实现流批一体；开发成本非常小，真正实现流计算敏捷开发 | low |
| 量化金融产研链路现状 | 问题 | 投研仿真与生产交易在大部分机构里是割裂的 | medium |
| 产研一体化的期望形态 | 条件与效果 | 若交易信号计算、交易系统、算法交易系统都有仿真系统，可将策略从投研快速部署到生产并快速反馈结果 | medium |
| 投研仿真系统技术选型 | 取舍 | 为保证开发效率常用Python或Matlab；为保证执行效率常用C++；两套代码会极大增加开发成本 | medium |
| 计算型数据库流批一体框架 | 作用 | 可在投研与行情计算系统中实现产研一体，从而提升交易策略研发效率与研发质量 | low |
| 完整量化金融全链条产研一体化解决方案 | 协作要求 | 需要计算型数据库、交易执行系统与算法交易平台共同协作和努力 | medium |