7月29日，2022数智交易未来论坛暨卡方科技生态合作伙伴大会在内蒙古呼和浩特成功举办，DolphinDB 联合创始人兼 COO 初阳春做了主题演讲：「面向数据的敏捷开发」，与众多业界精英一起探求数据库在量化金融的新角色，演讲干货如下。
大家好，我是 DolphinDB 的联合创始人兼 COO。
我们公司的创始团队之前在美国的投资银行、量化私募与公募基金工作过10年时间，在此期间我们开始从事数据库系统的研发，到现在也有10年。过去几年我们在国内也接触了许多券商和量化私募，积累了一定经验。
借此机会和大家分享我们的一点心得：数据库在量化金融的新角色——面向数据的敏捷开发。
数据库的角色演变
我们先来看一下数据库的角色演变。
最开始的数据库角色是存储与一些简单的查询，主要是事务型数据库来承担这个角色。后来由于对某些计算的性能要求，出现了分析型数据库，但是「分析型数据库」有点名不副实，通常只能做些简单的计算，例如聚合计算、分组计算、窗口计算等。
更复杂的计算，还是得交给 Python、Matlab 这样的数据分析系统。在以前数据量比较少的场景，这种操作一般就可以满足需求了，几兆几十兆的数据转换只需几秒钟。但如果是TB级别的数据，那这个数据转换的耗时就太久了，可能整个任务95%的耗时都发生在数据转换环节。
在现代海量数据场景下，复杂计算包括流式计算如果可以在数据库内直接完成，那将是最经济最高效的方式。
20多年前，出现了第一个计算型数据库 kdb+。kdb+ 是华尔街摩根斯坦利的一个工程师开发的，在当时解决了一部分海量高频数据高性能分析的问题。在2000年左右时，还没有大数据 big data 的概念，这个产品可以说非常超前，到现在还被很多海外机构使用。
因此可以说，是量化金融的大规模数据量以及对性能的极致追求，催生了计算型数据库。那么基于这些背景，DolphinDB 做了什么呢？我们进一步完善了计算型数据库。DolphinDB 提供了原生的分布式系统和更全面的数据处理函数，并且使用成本更低的脚本语言。
应用开发模式
数据库的角色，也影响了应用软件的开发模式。
绝大多数机构都是采用这种面向流程的传统应用开发模式，通过流程自动化，提升运行效率。这种模式包括经典的三层软件架构：数据层，应用层与表示层。系统的主要功能和业务逻辑都在应用层处理，通常使用以 Java 为代表的企业级编程语言编写，因此一般由 IT 部门主导整个开发过程。
但是，IT 部门通常不太熟悉业务，业务部门也不太熟悉 IT，所以两者需要反复沟通，造成数据类应用的开发周期特别长。
我曾经在纽约的一个大型公募基金里面任职，遇到过一个项目，我们需要 IT 部门开发一个追踪期权投资组合的各种风险指标的界面，前前后后花了半年时间。也有朋友和我分享过，在华尔街某著名的投行里，一个交易员要求 IT 部门制作一个 Bloomberg 系统上没有的、可以实时展示的交易信号指标，要至少三个月才能做好。
我们建议的新架构分两层：数据逻辑层和表示层。数据和业务逻辑都封装在数据逻辑层，也就是计算型数据库这一层。让业务部门主导核心逻辑开发，IT 部门主导基础设施与开发框架。
在三层架构中，每一个业务部门给出的公式，都需要 IT 部门进行硬编码来实现；但是在面向数据的敏捷开发这种两层架构中，IT 部门搭好系统以后，业务部门可以直接在系统中输入公式，所以新的开发变得非常迅速。
量化金融中的敏捷开发需求
关于量化金融中对于敏捷开发的需求场景，我们可以看两个例子。
因子挖掘——有的策略研发人员需要从几百万、上千万个因子中挖掘出几个因子，这需要非常快速的因子的开发与迭代。
风险控制——很多客户在风控领域的痛点是，一旦发现一个新的风控指标，会希望能够尽快把这个新指标放到生产系统中去。可是在现有的系统中，他们要和厂商或者自己的 IT 部门反映需求，进行开发，还要不断地对接，一般都需要几个月的时间——但是风险不等人啊！
大家可能会说，这些场景传统上都不是数据库能够完成的工作，都是要把数据从数据库中提取到计算引擎中完成的。没错，确实是这样，但是这些工作完全可以使用计算型数据库来进行敏捷开发，大幅提升研发效率。
计算型数据库特点
结合量化金融的具体情况，计算型数据库的特点主要有以下四个方面：面向数据科学、处理异构数据、支持流式计算、实现产研一体。下面我分别针对每个方面详细解释一下。
面向数据科学
在传统的面向流程的三层应用架构中，应用逻辑层的编程语言（如 Java）通过 ODBC、JDBC 等协议向数据库发出 SQL 查询。但编程语言和 SQL 完全运行在不同的空间中，没有任何交集。在一个计算型数据库中，两者高度融合，前者让数据库的开发更简单，后者让数据库的计算更灵活，可以高效完成数据处理的全流程。
Oracle 存储过程很强大，非常敏捷、简单，DBA 都喜欢。但是也有不少问题，例如不支持模块化、函数化编程，代码量大了很难维护；也不支持向量化编程；代码过于复杂繁琐，数据分析人员都不喜欢。这就引出了三层软件架构，把业务逻辑层从数据层中剥离出来。
我们现在又强调业务逻辑层和数据层的合并，那就需要 SQL 与脚本语言的融合。这就要求 SQL 的编写支持模块化、函数化、向量化，让代码更加简洁、高效、可维护，符合现代编程语言的风格。
具体来说，SQL 成为了编程语言中与变量、函数、表达式一样的编程对象，可以赋给一个变量，可以作为函数调用的入参，可以成为一个函数实现的一部分。反过来，SQL 也可以调用编程语言中的各种数据结构（数组，矩阵，字典，集合等）、自定义函数、变量。SQL 也会与分布式编程结合起来，如 SQL 处理的是分布式表，用到了自定义函数和本地变量等，系统会自动进行代码和数据的（反）序列化。
处理异构数据
一个计算型数据库，应当作为一个机构分析任务的「大脑」，可以处理异构数据，也就是不同来源、不同结构的数据。
通常有两种方式来处理异构数据，一是数据湖，二是多模态数据库。最简单的数据湖解决方案，就是用各种原始数据文件存储。这种方式可以存储所有格式的文件，但是性能不够好，不能满足量化金融的极致性能需求。计算型数据库采用的是多模态数据库的方式，通过多种存储引擎来针对性存储各种格式各种场景的数据，通过精细化的索引提升性能。
支持流式计算
量化机构选择流计算方案时，如果不是完全自研，一般只有以下三种选择：
首先是最通用的流计算引擎 Flink。Flink 非常强大，实现了流批一体，在互联网公司中应用很广泛。但是在量化金融机构中，真正用起来的人很少，这是因为 Flink 的技术栈复杂，部署和运维的工作非常重，开发门槛也很高。对量化金融需要的复杂计算，Flink 的开发难度尤其高。
很多出于流计算的需求来找我们的客户，都是觉得 Flink 的开发成本实在太高了。
如果不用 Flink，还可以考虑以 Redshift 为代表的物化视图方案。虽然物化视图方案简单易用，但是由于它只能使用 SQL 语句，所以无法处理量化金融的复杂场景需求。
第三种就是使用以 DolphinDB 为代表的计算型数据库来提供流计算功能。DolphinDB 内置了多种流数据引擎，可以处理非常复杂的流计算场景，提供了流计算的低代码开发，同样实现了流批一体。可以说开发成本非常小，真正实现了流计算的敏捷开发。
实现产研一体
最后，量化金融的「投研仿真」与「生产交易」在大部分机构里面都是割裂的。
如果交易信号的计算、交易系统和算法交易系统都有对应的仿真系统，那么私募或券商自营部门就能够把交易策略从投研环境快速部署到生产环境，并且两边的结果可以快速进行反馈——这就是业界希望看到的量化金融的产研一体化。
今天我们主要看一下交易决策的计算部分。投研仿真包括将历史数据注入投研系统，以及把行情数据回放到行情计算系统，这两部分可以使用计算型数据库。为了保证开发效率，投研仿真系统通常使用 Python 或者 Matlab；为了保证执行效率，通常使用 C++；而使用两套代码会极大增加开发成本。
而如果使用计算型数据库流批一体的流数据计算框架，则可以在投研与行情计算系统中实现产研一体，从而大大提升一个量化机构交易策略的研发效率和研发质量。当然，要实现完整的量化金融全链条的产研一体化解决方案，是需要计算型数据库、交易执行系统与算法交易平台的共同协作和努力的。