RisingWave 在超百亿管理规模对冲基金公司中的应用

作者：交易系统工程师   超百亿规模管理对冲基金公司  

1. 公司背景

XX 私募基金（应客户需求，我们对其公司名称做了保密处理）是一家专注于量化投资的超百亿对冲基金公司，成立之初主要以自营期货高频交易为主。目前公司成员近百人，投研团队占比 70%。团队内主要成员大多来自清华、北大、中科大、普林斯顿大学、哥伦比亚大学、宾夕法尼亚大学等国内外知名高校，均为计算机、电子、数理专业等行业高精尖人才。公司发展迅速，管理规模逾百亿。

2. 使用 RisingWave 之前的情况

随着公司业务的快速发展，管理的基金产品越来越多，每天需要处理的账户交易数据规模也在不断增加。在量化交易领域，低延时是非常关键的因素，实时分析市场行情和交易流水可以更迅速地提供进一步的决策，更好的抓住交易机会。早在 2021 年，我们使用 ksqlDB 来做实时预警功能，很快我们发现其设计上的一些功能限制无法应用到更多的场景中。后来我们引入了业内成熟的流处理引擎 Flink 来串连不同的数据系统做 ETL 实时计算，流处理编程接口 DataStream API 通过命令式的语言来描述流计算，其灵活性和丰富的组件可以实现更复杂的数据处理逻辑，但对于非 JVM 技术栈的开发人员来说，也带来了较大的学习和开发运维成本。虽然 Flink 可以满足我们目前的需求，但是考虑到以下几方面问题使得我们继续寻求更适合自身业务场景的流计算系统。

2.1 学习成本

我们公司有着研究员，交易员，系统开发等不同角色的小伙伴，大都并没有 JVM 编程功底，因此从易用性上来说，流计算系统的学习成本就非常重要，这使得 Flink 很难在公司业务线上全面推广。

2.2 资源成本

在实际交易的 Colocation 机房 (在量化交易领域这个词通常表示是服务器托管在离交易所比较近的机房)环境下，硬件资源是非常稀缺的。因此更少的资源占用，更低的部署复杂度都是我们需要考量的因素。

2.3 可观察性

metrics 监控系统和状态可查询功能是在做延时调优和系统调试过程中非常得力的助手，一次微小的逻辑变动都可能会让 CPU 和内存占用发生巨大的变化，因此一个完备的可视化监控系统和状态可查询功能尤其关键。

2.4 技术支持

对于流计算的初学者来说，会遇到很多技术和概念上的困惑，尤其在项目 PoC 阶段，技术团队高效率的沟通和给予高质量的响应支持可以快速地加深对系统的使用了解。

3. 为什么选择 RisingWave

在实时流计算系统的选型上，我们没有历史包袱。经过对 ksqlDB 到 Flink 的使用，我们明白其各自特点和优势，但我们从没停止寻找更优秀更适合自身业务场景的流计算系统，直到 RisingWave 的出现，通过深度使用发现这是一个极其现代化的流计算系统，如同官网上宣传语一样，在某种意义上来讲，它确实重新定义了流计算。其有如下几个特点吸引着我们：

3.1 PostgreSQL

最为打动我们的是 RisingWave 从一开始就选择使用 PostgreSQL 来表达流计算，SQL 作为声明式语言可以说是受众最广的表达方式之一，其简洁、易于理解、高层次的抽象语法使得开发者可以更专注的关注业务逻辑的本质，极大降低学习开发成本，从而提高开发效率。因为其兼容了 Postgres 协议，Postgres 生态中的技术栈均可以应用到 RisingWave 中来，无形之中增添了不少能力。从我们的实践来看，SQL 的表达能力已经可以覆盖绝大部分的业务场景，对于极其复杂个性化的数据处理我们可以通过 UDF 或者其它命令式的语言来实现。

3.2 低延时

天下武功，唯快不破。前面也提到，在量化交易领域，在满足业务功能的前提下，低延时会是非常重要的技术选型考量因素，抛开一些极其苛刻的超低延时场景，我们使用 RisingWave 在对成交流水与维度表实时扩宽、实时仓位累计等场景其端到端延时可以达到 5~10ms 级别，一些更复杂的实时查询如账户盈亏(Profit & Loss)计算和其它监控指标计算也可以在百毫秒内完成。

3.3 数据集成

RisingWave 提供了非常丰富的 source 和 sink connector。从主流的消息队列到 OLTP 和 OLAP 数据库，再到数据湖存储引擎，都提供了非常好的支持。在编码方式上也提供了主流的 JSON，Avro，Protobuf，这样可以非常方便且低成本地将现有的业务数据系统集成到 RisingWave 中。如果说 Kafka 是流处理市场最大的赢家，那么 RisingWave 也可以称得上是流计算领域的瑞士军刀。

3.4 丰富算子

在我们进入生产环境的项目中有 50+个表、物化视图、以及与外部系统交互的 source/sink connectors，独有 temporal join、interval join、temporal filter、TopN 算子、实时增量计算提高新鲜度的 materialize view、时间窗口函数、支持乱序处理的水位线机制、以及支持 PostgresSQL 中绝大部分语法比如 common table expression，`DISTINCT ON`等。 可以满足维表拓宽事实表、多路 stream 聚合、实时 ETL、窗口指标统计等场景的应用。

3.5 可观察性

RisingWave 为流作业带来了非常友好完善的可观察性。首先该平台通过 Grafana 仪表板提供了一系列不同粒度的指标，非常适合调优和生产上的指标监控。其次，流作业的内部状态像一张表一样是可以用 SQL 查询的，这对于 debug 非常有帮助。此外由于其是兼容了 Postgres 协议，因此 Postgres生态的工具都可以直接连接 RisingWave，大大简化了 SQL 调试和数据相关问题的排查。

3.6 技术支持

RisingWave 的同学们非常的专业、热情、耐心，在我们初期使用的过程中，给予了我们非常高效和快速细心的解答帮助，让我们更深入地了解 RisingWave 和流计算，在 POC 阶段顺利完成了一些业务的落地。

4. RisingWave 的实施情况

我们和 RisingWave 的合作始于数月前。当时在一些交易场景下，出现了大量需要非常高效低延时的扩宽表，多个数据流实时的聚合，实时指标计算以及和多种数据系统如消息队列和数据库交互的场景。起初使用 Flink 来实现并没有达到预期便捷的效果，同时也希望避免使用其它命令式的语言来开发，这主要是开发运维成本上的考量。在 RisingWave 同学们的悉心指导下，我们仅使用 SQL 声明式的语言就完成了以下业务的开发并应用到了生产环境。

• 从消息队列摄入实时交易成交流水，基于维度表对其拓宽后并sink到下游数据系统

• 基于成交实时累计账户持仓并 sink 到下游数据监控系统

• 基于成交和持仓实时计算账户盈亏 (Profit & Loss) 并 sink 到下游监控系统

• 对行情与交易流水等多个事件流进行实时聚合出衍生消息并 sink 到下游数据系统                                    

5. 总结与展望

经过几个月对 RisingWave 深入学习与实践，我们已经成功将 RisingWave 应用到实盘交易生产环境，并稳定运行。RisingWave 作为冉冉新星，以独特的视角重新定义流计算，以兼容 PostgreSQL 为核心思想，便捷地将多种数据系统集成到一起来简化数据流。不仅有丰富的功能组件，在易用性，低延时，低学习成本，低部署运维成本方面有着巨大的势和吸引力，同时也在不断学习与成长。RisingWave 的出现，解决了我司之前遇到的痛点。从某种意义上来说，也拓宽了流计算的边界，使得我们在面对更创新、更复杂、具有挑战性的业务时都可以从容面对。

——End——

往期推荐

滴滴OLAP的技术实践与发展方向

大数据开发的存储技术探索与实践

一文搞懂 NVIDIA 在 GPU 上高效部署语音 AI 模型的最新应用

强化学习和世界模型中的因果推断

深入浅出快手图数据库：看架构如何让推荐召回更高效

小米数据开发平台架构实践

B站大数据开发治理平台的产品设计心得

如何建设一个良好的可观测性数据平台直击企业痛点？

点个在看你最好看