9 月 6 日，“以实时，见未来”2024 DolphinDB 年度峰会在杭州举办。DolphinDB 创始人、CEO 周小华博士为大家带来了主题为“跨越数据边界：企业级实时计算平台构想”的精彩演讲。

从最初的一站式大数据平台，到高性能时序数据库，再到如今的实时计算平台，DolphinDB 的发展之路充满了创新与突破。演讲中，周博士回顾了 DolphinDB 如何从时序数据库，逐步演进为一个涵盖多模态存储、流批计算、GPU 计算、丰富的业务中间件等等的全方位基础软件的历程。未来，DolphinDB 将致力于构建一个支持多部门协同作战的企业级实时计算平台——Orca。这不仅仅是技术上的进化，更是一种全新的开发模式的探索，可以为金融机构提供更高效、敏捷的解决方案。

以下是周博士在峰会分享的全文内容：

很高兴又和大家见面了。再次欢迎各位的到来。以实时，见未来。这是我们这次大会的主题。也呼应了我们对 DolphinDB 的定位。未来我们希望将 DolphinDB 打造成一个企业级的实时计算平台。

我记得，DolphinDB 的第一个商业化版本刚刚推出的时候。公司的主要成员都是研发岗位。我作为公司的研发兼第一个销售，开始了我的路演生涯。那时，每天的两件核心事情：第一，为下一个版本继续写代码。第二，就是不停的向不同的客户解释同一个问题：DolphinDB 是什么。我们最初的定位叫做一站式大数据平台。试了一段时间之后发现不太灵。精准的踩中了那个年份产品流行语的每一个雷点。一站式，大数据，平台。搜索引擎一检索，能出来上百个同类产品。辨识度非常低。完全不能体现出我们的优势。

我们就琢磨了一下，要换个说法。那个时候，时序数据库的应用还不是特别广泛，基本是国外的开源产品InfluxDB 占据市场。所以我们决定用国产高性能时序数据库这个概念，作为DolphinDB的标签。20 年的时候，snowflake 在纽交所成功上市，市值超330亿美元。紧接着，另一家国产数据库厂商 PingCap 完成了创历史的 2.7 亿美元融资。一下子，国产数据库这个概念被点燃了，我们也收获了很多自然流量的客户。可能到现在，一小部分客户还是以一个数据库、一个时序数据库的视角，来理解来认识 DolphinDB。

但是时序数据库这个定位，还是没法讲清楚 DolphinDB。这是6年前，DolphinDB的架构图。

6 年前 DolphinDB 架构图

可以看到，DolphinDB 其实在设计之初，就已经与传统的数据库有了很大的区别。在分布式存储之上，我们开发了自己的脚本语言，丰富的专业函数库。这些能力融合在一起，形成了一个非常擅长实时数据分析的一站式产品。

这是今天 DolphinDB 的架构图。

现在的 DolphinDB 架构图

DolphinDB 在每一个能力板块都得到了增强。一个个新功能见证了 DolphinDB 向一个实时计算平台不断演进的过程。我们逐渐完善了多模态存储的概念，从单一的 olap 引擎扩展到现在 olap，tsdb，pkey，imoltp，vector 等5个引擎。计算层面增加了流计算和 GPU 计算 Shark。业务中间件能力得到了极大的提升和扩充，函数个数从 600+ 提升到了 2000+，大量的插件，计算引擎和脚本模块从无到有覆盖了诸多的金融业务。

近几年，随着 DolphinDB 在金融机构的使用越来越深入，一个机构拥有多个 DolphinDB 集群的现象越来越普遍。多集群的数据访问、计算、运维的需求越来越迫切。与此同时，用户的计算越来越复杂，任务之间的依赖关系，事件之间的依赖关系，如何简单清晰的表达，越来越成为一个瓶颈。一个企业级的实时计算平台的呼声日益高涨。

企业级实时计算平台——Orca

顺便提一下，我们将企业级实时计算平台这个产品命名为 Orca 虎鲸，这是继单集群版本 Dolphin 海豚，GPU 版本 Shark 鲨鱼，复杂事件处理引擎 Octopus 章鱼之后的又一个海洋家族 logo。虎鲸力量大，速度快，聪明，特别擅长家族协同作战，这个跟多集群多部门协同工作非常类似。我们内部在讨论命名这个产品的时候，说到虎鲸 orca 时，全票一致通过。

大家对企业级实时计算平台，可能都有自己的看法。深入问题之前，我想分享一下自己朴素的理解。这也是跟我们很多用户沟通之后形成的概念。企业级平台首先是能够协同支持金融机构多部门的业务，尤其在表达复杂批计算或流计算的任务或数据的依赖关系时，非常简单高效。其次，数据访问需要变得非常简单，只要给一个全局唯一的标识，就可以得到需要的数据，用户不用去操心是不是最新的版本，不用去操心存储在哪个集群哪个服务器，是不是跟我的计算服务器在同一个集群，不用去操心是不是要避开使用高峰。最后，运维监控和资源管控也必须是企业级的，可以对整个机构的全部集群进行管理。

首先实时计算平台对金融业务的支持必须有足够的深度和宽度。

这是传统的数据仓库不能直接拿过来作为企业级实时计算平台的重要原因。金融行业，尤其是跟量化投资相关的领域，对于数据分析的应用、数据价值的挖掘，程度之深、维度之广、投入之大，几乎可以说是其他所有行业加起来的总和。我身为曾经的从业者，现在的服务者，深以为然。这从侧面反应出一个问题，那就是金融领域的业务开发，是专业性极高，非常复杂的。

普通策略开发流程

以普通的策略开发为例，一个有效的策略上线，要经历特征工程、因子评价、策略回测、代码转写、结果校验等多个阶段，才能最终上到实盘去运行。这个实现的过程，首先业务人员要具备较好的数学、统计、金融理论等学科知识的储备。通过这些能力将业务逻辑整理出来，通过计算机工程来进行落地实现。而在落地的过程中，为了追求业务运行的效率，又对业务人员的计算机工程能力有较高的要求。计算平台如果在业务支持上没有深度，这项工作的落地会非常耗时耗力，失去了平台建设的意义，还不如让策略研发人员自己去用Python。

DolphinDB 对金融业务的支持

一个稍具规模的金融机构，业务线通常有很多。从权益到 FICC，从行情、投研、交易、风控到合规，每一个都需要相应的 IT 系统支持。虽然，不能要求一个平台十八般武艺样样精通，但至少在核心能力上有足够宽度的支持。否则各个业务部门的各个系统极易演变成一个个孤立的烟囱系统或信息孤岛。

对金融业务的友好支持，一直是 DolphinDB 引以为傲的一个点，也是 DolphinDB 区别于其它基础软件最显著的一个点。我想，在座的 DolphinDB 的用户对这一点也深有体会。前面初总也介绍了 DolphinDB 这几年在不断拓展金融业务的边界，从最初的权益量化投研这个单一场景，到现在已经覆盖十余个场景。今后，我们会继续坚持这个特色，把底层技术和金融业务融合起来，让大家落地业务更快更方便。

现在我们具体来看一看基于 DolphinDB 的金融业务开发模式。DolphinDB 软件用一句话概括就是 多模态存储 + 批计算 + 流计算 + 编程语言 + 业务中间件。与金融业务的融合体现在业务中间件这个模块上。具体我们可以通过内置函数库，内置引擎，插件和模块 4 种方式来实现业务中间件。

这种新的开发模式与传统的烟囱模式最大的区别是不同的业务系统共享一个由存储，计算和业务中间件构成的一个强大的底座。让真正懂业务的人写脚本或调 API 进行快速的二次开发，实现业务快速落地。因为业务的开发非常敏捷，成本占比较小，整个形状看起来像一把锯子上的锯齿，我们称之为锯齿开发模型。锯齿开发模式可以大大提升金融业务的开发效率，降低投入成本。

DolphinDB 锯齿开发模型

谈到业务中间件，不得不提一下我们客户的一个担忧。很多客户表示，开发业务中间件很好，功能很强大，也方便业务落地，但会不会摊子铺得太大，造成系统复杂度增加，最终导致系统失控？我这儿回应一下。首先非常感谢我们的客户对我们产品的关切。但是单纯从技术和架构的角度来看，业务中间件并非系统的核心，它只是基础设施暴露的一个框架，允许横向的去拓展业务逻辑。不论开发一个中间件，还是 100，1000个中间件，DolphinDB 的基础架构保持不变，也不会增加系统的复杂度。另外，业务中间件这一块，我们也会更加开放，把标准接口暴露出来，更多的中间件将交由我们的客户或第三方去开发。

企业级实时计算平台，第二个需要解决的核心问题，就是数据一致性的问题。

简单说，就是一个金融机构内部，在任何一个时间点上，有一个全局的唯一数据视图。我们的核心业务部门可以在这个数据视图上，开展行情，投研，交易，绩效，风控，合规等业务的数据写入，查询和计算，得到正确可靠的结果。这与资管领域的 IBOR 数据模型一直在倡导的数据一致性，或黄金单一数据源标准，讲的是同一个事情。

那为什么在一个金融机构中数据的一致性这么难？为什么同一份数据非得有多个不同版本的拷贝？这儿有很多因素，有非技术的原因，譬如某些行业中的厂商不愿意开放数据接口，又譬如因为合规性的问题部门之间必须有防火墙隔离数据。这些非技术原因，DolphinDB 也无能为力。还有很多技术原因导致的数据不一致的问题，这将会是我们重点要攻克的目标。

针对同一个数据节点上的计算任务太重，不得不创建多个数据拷贝来分担计算压力的场景，DolphinDB 会采用存算分离的技术，通过对用户无感的缓存来解决数据不一致的问题，第一个版本会在 10 月初发布。针对异地距离太远，不得不创建本地拷贝来提升性能的问题，可以使用 DolphinDB 已发布的集群间异步数据复制的能力来解决，或者用 Raft Learner 这样的分布式复制协议来解决。针对因跨集群，权限管理不便导致数据拷贝的问题，DolphinDB 会在年底的版本推出更为全面的单点登录方案。针对不能跨集群计算而导致数据拷贝的问题，DolphinDB 正在推出跨集群的 SQL 计算能力。最后对于企业级的数据管理来说，一个全局的数据目录至关重要，可以用全局唯一的地址来标识每一个数据资源，便于数据访问。DolphinDB 正在推出一个集群 + 集群内目录的二级数据目录管理方法。

企业级数据的一致性建模是一个非常基础，复杂，但又十分重要问题。这个问题搞好了，系统的可用性，易用性，正确性就能上来了。让大家在用数据的时候，非常的便捷，非常的丝滑，非常的放心，真正做到只需要知道数据的唯一标识和数据字典，就可以去操作数据了。

企业级实时计算平台另一个有挑战性的问题是计算依赖的问题。

一个金融机构中各业务部门之间，一个部门里的多个计算任务之间，一个计算任务内的各模块之间，都存在依赖关系。如果用一幅图来表示，我们称之为计算依赖图。譬如我们需要计算一个持有各类金融资产的机构的风险指标，无论是事后风控的批处理计算，还是事中风控的的流式计算，都会呈现一幅复杂的计算依赖图。

计算依赖图

在这个风险计算的依赖图中，任何一个模块，譬如行情和头寸的变化，都会触发后续的模型或计算指标的变化，最终算出整个机构的风险指标。这种链式的实时计算模型正是我们这个平台名称的由来。在业务上，对处于高度市场竞争的金融机构来讲，企业级实时计算模式是非常有价值的，可以大大提升一家机构对市场反应的灵敏度。

DolphinDB 已经具备非常强大灵活的批计算能力和流计算能力，我们暴露了大量的引擎，模块，函数和算子给最终用户，可以用这些底层的能力去灵活实现各类计算任务。但是这些底层的 API 接口并不擅长表达复杂的依赖关系。我们的用户尝试用这些底层接口去编写具有复杂依赖关系的任务时，发现代码过于复杂，并且难以后期维护和管理。如果再跟分布式计算和高可用结合起来，代码愈加晦涩难懂。

我们已经意识到了这个问题。我们准备引入一种新的声明式的 API 来描述金融业务的需求逻辑，来表达任务之间的依赖关系。后台系统负责将这些 high level 的业务逻辑转化成底层的 API 接口调用。

这种方式的好处是业务描述与具体实现完全分开。这样业务人员开发会更加简单，聚焦于业务场景的描述，不用陷于实现的诸多细节之中。另一个好处是便于系统做优化。譬如计算资源怎么分配，任务怎么调度安排，状态管理怎么实现，数据源的副本如何选择，高可用怎么实现，计算执行的逻辑计划和物理计划的优化，可以做很多工作。当系统复杂时，自动的优化可能比用户人为的选择更有效。

当一个企业级的实时计算平台具备的功能有足够的宽度和深度，能满足各部门业务拓展的需要，具备扎实的一致性数据底座，具备描述和优化复杂的业务依赖关系的能力，自然而然就会引出对运维，监控以及资源管控的强力需求。

DolphinDB 目前只具备单一集群的运维能力，而事实上，已经有数十家金融客户在运行着 2 个以上的 DolphinDB 集群。我们会通过几个版本的迭代，提供多集群的运维能力。DolphinDB 会增加一种新的节点类型 Master of Master （MoM）。通过 MoM 类型节点，可以便捷的实现多集群运维。

通过全局的数据目录，计算依赖图，Dashboard，我们可以对 DolphinDB 集群以及正在运行的计算任务提供可视化的监控手段。用户可以层层下钻，去发现和诊断问题。

Orca 中的实时计算任务都做好了状态管理，可以非常低的代价将任务转移到其它节点。因此， Orca 的计算资源将具备较好的弹性伸缩能力。

打造一个企业级的实时计算平台，是一项艰巨的工程。我们已经预估了工程的难度和复杂性，这将是 DolphinDB 接下来一年最核心的研发工作。我们准备分 4 个版本来实现所有的核心功能，分别是今年的 10 月，明年的 1 月，5 月和 9 月，每个版本要发布的内容，暂时保密。

新版本时间节点

做难而正确的事，这个熟悉的网红金句，一般用在科技公司年会或峰会的结尾处，彰显价值。有点俗套，但我觉得用在我们正在做的这件事情上，平心而论，不过分。打造一个企业级的实时计算平台，国内国外的很多金融机构都想做。但据我所知，至少国内还没有一家金融机构拥有这样的计算平台。所以这个事情的难度肯定比我 2012 年写 DolphinDB 的第一行代码时更大，但是我们现在拥有一个更强更稳定的团队，而且已经打下了 12 年的基础，我更有信心。退一万步讲，这件事情即便做的不够好，也可以为后来的研发人员提供更多宝贵的经验。做好了，则可以大幅提升我们金融乃至其它行业的生产力。正因为这件事情的价值很大，即便在如此恶劣的经济大环境下，我们仍然愿意放手一搏，去做一家科创企业该做的事情。正因为难，在这个过程中，也更希望得到大家的支持和呵护！也欢迎感兴趣的朋友会后做更多技术上和业务上的探讨。感谢大家的聆听，希望大家在今天的会场有收获！