RisingWave 助力乾象投资打造实时监控平台

作者：乾象投资

1背景介绍

公司背景

乾象投资是一家以人工智能和机器学习为基础的科技型量化投资公司，致力于将严谨的数理统计理论和前沿计算机技术相结合，从而为投资人创造长期可持续的回报。团队核心成员来自 Stanford、CMU、Facebook 和 Google 等顶尖高校和公司。目前，公司管理规模已突破 100 亿元人民币。

业务背景

乾象投资通过为交易行为建立一系列告警规则，例如监测账户交易活跃性、现金量充足性以及交易行为是否符合相关法规等，来确保交易系统的健康和交易的合规性。这套告警系统的输入来自交易机器实时的业务信息，输出则是对当前交易行为是否符合预期的判断，对稳定性、低延时和计算结果准确性有着严格的要求。乾象使用 RisingWave 搭建了这套监控系统。目前，RisingWave 能够处理上万 QPS 的输入消息，并在秒级别的延迟下输出告警。

2为什么要替换原有的数据库系统？

在使用 RisingWave 之前，乾象使用了自建的服务将实盘数据实时写入某主流 olap 数据库（以下简称为 X 系统），通过周期性查询进行告警。选择 X 系统主要是基于下面几个优点：

1. X 系统有很强的写入性能，大约为 50~200 MB/s，结合高吞吐的中间件，可以实现低延时入库，适合需要不断写入（不需要修改）的场景。
2. 物化视图可以提前处理数据，优化查询表现，特别是对于告警规则涉及的聚合操作。

但是，随着 X 系统的开发和使用，乾象遭遇了新的困难：

1. X 系统对高并发查询并不友好。从设计上，X 系统是用来处理数量较少但是计算密集的请求，所以单条查询就可能用完 X 系统所有的资源。官方建议的 QPS 是 100，这限制了监控业务的继续发展。为了解决这个问题，乾象采取了一些缓解措施，比如重新设计分区、索引粒度，限制单个查询可以使用的资源等；同时，使用物化视图提前处理数据，优化查询表现，特别是对于告警规则涉及的聚合操作。
2. X 系统对于分布式一致性的支持不充分。X 系统在进行数据变更时，都会产生一个临时分区，而不会更改原始数据文件，对数据文件的修改操作会要等到数据合并时才进行。因此，X 系统只能保证数据的最终一致性，而不能保证强一致性。这导致乾象在实际使用过程中，需要对数据的处理万分小心，也为了防止数据表结果的不一致，不能使用 Join 操作，这对于数据流的处理带来了不便。
3. X 系统对水平拓展的支持不足。分片间通行会影响查询性能，水平扩展会直接导致查询变慢，使开发人员很难平衡分片（sharding）和查询性能（query performance）。同时，由于 X 系统大部分处理都是异步的，水平扩展会带来数据的不一致性，这也给乾象系统的可扩展性带来了极大的挑战。

那么，有没有系统能够一次性解决这些业务痛点？乾象在寻求新的数据库方案时遇到了 RisingWave。RisingWave 是一家致力于搭建高性能、高可用性、高可扩展性的流式数据库公司。通过深入了解和研究，乾象最终选择使用RisingWave 来替代 X 系统搭建风控系统。引入 RisingWave 后，乾象在计算节点数量降低一半的情况下，提高了 3 倍的数据实时性，大大地提升了集群的性价比。

3为什么选择 RisingWave？

3.1 高效的增量模型带来更加极致的性能

作为流式数据库，RisingWave 可以通过与 Postgres 兼容的 SQL 创建物化视图的方式帮助用户快速建立实时流处理任务。RisingWave 的物化视图支持实时增量更新，也就是说，每当一批新数据到来时，都会触发计算并更新实时的物化视图结果。在 RisingWave 内部，会维护将每个物化视图涉及的算子的内部状态，以提供更好的增量更新能力。也正是 RisingWave 更高性能的增量模型设计，带来了超过 X 系统的性能。此前，乾象在 X 系统实现的是分钟级别监控，根据测量，数据进入 X 系统的 P90 延迟在秒级别，而在 RisingWave 落地之后，这个数据降低了数倍之多，入库时间只有亚秒级。

3.2 丰富的增量计算实现了资源成本的极致节约

在数据处理过程中，全量计算会处理所有的数据，而增量计算只对新添加或修改的数据进行计算，因此全量计算会带来显著的性能开销以及资源和成本的增加。在业务上，乾象希望尽可能避免全量计算，但遗憾的是，X 系统的物化视图在一些常用语法上存在限制。例如，窗口函数（Window Function）在交易分析中非常常见，用于计算每行数据前后特定范围内的聚合结果。相比之下，RisingWave 提供了 OverWindow 算子，对窗口函数的支持更加出色。增量计算的减少也降低了乾象的资源成本开销。在乾象的一个监控集群中，相同的监控业务支持，未使用物化视图的 X 系统集群需要数百核，使用物化视图并进行精细调优的 X 系统集群需要数十核（13%）。而 RisingWave 只需十个核以内的计算资源就能完成相同的任务。相比于未使用物化视图的 X 系统集群来说，RisingWave 降低了乾象 95% 以上的计算资源，相比于开启物化视图的 X 系统集群来说，也降低了至少 70% 的计算资源，实现了成本的极致节约。

3.3 混合架构带来了更加优秀的水平扩展能力

如何做好水平扩展和查询性能之间的平衡，对于开发者来说一直是个难题，但在 RisingWave 上并不存在这个难题。由于 RisingWave 是维护远程状态（remote state）和本地状态 （local state）的混合形态，这也就意味着它既能利用云存储的特性有更强的弹性扩缩容能力，又能够通过 local cache 维持查询的高性能。在这样的架构设计下，开发者可以不再纠结于水平扩展和查询性能的两难问题。

3.4 分布式强一致性

RisingWave 通过引入 Barrier 机制来确保计算图中各节点间的状态一致性，这在外部表现为物化视图（Materialized View, MView）之间数据的一致性。Barrier 机制是一种同步方法，用于分布式系统中保证数据处理的原子性和一致性。在 RisingWave 中，这种机制确保即使在分布式环境下，访问多个物化视图时，用户得到的结果都是强一致的。这种强一致性保证，让用户在执行 SQL 操作时，无论数据如何分布或更新，都能获得准确且一致的结果。这在处理复杂的分布式查询和实时数据分析时尤为重要，因为它消除了数据不一致带来的混淆和错误，这对于数据的使用者而言是十分方便且有意义的。

3.5 丰富的 Sink 接口支持

RisingWave 提供广泛的 Source Connector 和 Sink Connector，极大地简化了数据的整合与传输。这些连接器支持从各种 source 到 sink 的无缝对接，能够高效处理多样化数据流。此外，RisingWave 支持 JSON、Avro、Protobuf 等多种编码格式，优化了系统间的集成，提高了数据兼容性与处理效率。尤其对于构建实时监控系统而言，这些特性使得 RisingWave 能够实时处理和分析大量数据流，为系统提供强大的数据支持和稳定的性能表现，成为实时数据处理的重要工具。与此同时，结合 RisingWave 的物化视图特性，能够实现将处理后的物化视图数据汇入 Kafka, 从被动告警变为主动告警，摆脱了高并发查询的痛点。

3.6 UDF 自定义服务支持

类似 MySQL 的自定义函数，RisingWave 允许用户把自定义的逻辑通过用户定义函数（UDF）加入 RisingWave 的流计算。尽管 SQL 已经非常强大，但 UDF 提供了更多的自由度，特别适用于处理一些情景，例如一些涉密逻辑，或从现有系统迁移过来而无法完全兼容的情况。通过 UDF 自定义函数，乾象能够在不改变整体架构的情况下更加方便地将业务逻辑进行迁移。

3.7 可观测性

RisingWave 为自身构建了一套可观察性系统，利用 Grafana 提供了多种指标和不同粒度的仪表板，支持将监控导入内部或者用户维护的 Prometheus 系统中。这一特性使得 RisingWave 能够无缝整合进公司现有的 Prometheus 监控体系中，极大地方便了监控管理。

3.8 技术支持

在项目 POC 阶段，RisngWave 为乾象提供了有力的技术支持，使开发人员更好地理解了 RisingWave 流数据库的使用方法，遇到业务逻辑的迁移不兼容的情况，也能及时提供积极反馈和建议。

4基于 RisingWave 的解决方案

在选择 RisingWave 作为实时监控系统的数据库、计算引擎后，乾象搭建了如下的实时监控架构：交易机器通过 Kafka 传递业务数据。RisingWave 在 Kafka 源表之上，建立了物化视图，用于计算不同聚合条件下的交易数据，与阈值比较，生成告警结果。RisingWave 还提供了将数据写回 Kafka 的功能。告警服务会监听 Kafka 流，向监控人员发送相应的告警通知。

目前，这套监控方案的运行稳定出色，具体表现为以下几点：

1. 提供了存算一步到位，支持全面数据的能力。RisingWave 数据库集中存储了所有与交易相关的信息，包括交易订单和账户信息等原始数据，这使得告警规则被集中定制。RisingWave 数据库还存储了监控规则计算的结果。一旦触发告警，监控人员能够通过 SQL 查询获取原始数据、处于中间状态的数据以及处理过的数据，使问题的定位更为便捷。
2. 提供了流表一体的能力。RisingWave 呈现流计算的方式是物化视图，用户须使用 SQL 创建物化视图。SQL 作为一种声明式语言，可以涵盖绝大多数代码编程表达的语义。在需要修改告警规则的情况下，修改 SQL 相比在机器上修改代码更加灵活。除了在开发方面的优势，RisingWave 实现了真正的实时数仓。它流式地消费数据，流式地处理，确保了动态结果的低延时和准确性。
3. 提供了数据流转的能力。RisingWave 支持将处理后的数据汇入 Kafka。相较于其他数据库，这一特性改变了数据库通常只能被动查询的使用方式，也摆脱了数据库查询 QPS 的限制。

5总结与展望
经过对 RisingWave 深入学习与实践，乾象已成功将 RisingWave 应用到实盘交易生产环境，并实现了稳定运行。RisingWave 提供了强大的可靠性、可扩展性、高效连接、出色的可观察性以及杰出的客户支持，解决了乾象此前在系统业务上的一些痛点，为实时监控平台提供了更好的解决方案。接下来，RisingWave 将继续致力于流批一体的实现，在未来，RisingWave 既可以实时处理从各种数据源流入的数据，也能对存储在数据湖中的大规模数据进行高效分析，提升用户数据分析和处理能力，以助力企业适应不断变化的市场需求和技术挑战。

关于 RisingWave 

RisingWave 是一款基于 Apache 2.0 协议开源的分布式流数据库，致力于为用户提供极致简单、高效的流数据处理与管理能力。RisingWave 采用存算分离架构，实现了高效的复杂查询、瞬时动态扩缩容以及快速故障恢复，并助力用户极大地简化流计算架构，轻松搭建稳定且高效的流计算应用。RisingWave 始终聆听来自社区的声音，并积极回应用户的反馈。目前，RisingWave 已汇聚了近 150 名开源贡献者和近 3000 名社区成员。全球范围内，已有上百个 RisingWave 集群在生产环境中部署。