RW 实践

背景

首先介绍一下我们团队的情况，我司数据中台团队成立于2022年初，最开始聚焦于离线数仓和报表，人员配置在6个人左右的小团队。技术架构比较复杂，组件相对来说比较臃肿，一次报表刷新的时间大概在12小时左右，在我们数据量并不是特别大的情况下效率并不高。2023年年末团队经历一波换血过后，我们就开始着手整个数据中台的架构治理。当然其他细节我就不在这儿过多介绍，比较新颖的是，为了支持风控实时计算的需求，我们引入了比较新的RisingWave作为我们实时计算的补充，同Flink一起支撑整个团队的实时流水线。

RisingWave

RisingWave 是一个分布式架构的 SQL 流式数据库，能简单、高效、可靠地处理流数据。RisingWave 提供增量更新、一致性的物化视图——这是一种持久的数据结构，承载了流处理的结果。RisingWave 让开发人员能够通过级联物化视图来表达复杂的流处理逻辑，从而大大降低了构建流处理应用的难度。此外，它还允许用户直接在系统内持久化数据，而无需将结果传送到外部数据库进行存储和查询。

整体架构

案例

1. 车辆在途打标

我司有一个项目需要对所有平台注册的车辆进行标记，简单来讲就是需要经过计算，然后标记车辆是否在途。这个需求相对来说比较简单，只需要查询平台跟这个车相关的订单，关联最新的位置，如果有就是在途，并且有最新位置，没有则非在途。所以对于这个案例，我们全程都是在RisingWave计算，首先通过 RW CDC 将车辆，打卡等相关表 CDC 到 RW, 然后再通过join关联车辆最新的位置（可以利用窗口函数等计算）并且标记是否在途。join后的是 Materialized View ，为了方便查询，我们又将最终的结果sink 到了 mysql 提供给业务系统查询。

需要注意的是

• RW CDC 以及 最后结果 Sink to mysql 都需要映射，RW 采用psql 而我们业务系统都是mysql， 所以中途的映射算是一个比较繁琐的事情
• Timestamp & Datetime 在映射后的时区问题，需要谨慎处理，必要的时候需要单独转换
• 没有自动化部署！！！ 由于采用SQL方式，所以我们只能手动执行，曾经仓试过集成liquibase等都失败告终，最后不得不统一手动执行
• decouple sink 如果经常遇到跑着跑着 RW 就crash 了，并且整个集群都在 crash 那应该是下游存在瓶颈导致无法checkpoint

2. 订单打标

这个需求类似于第一个案例，不同的是这个需求很复杂，设计的场景比较多。如果还是通过SQL来做就不是很合适，也不方便测试。好在RW提供了UDF，并且支持多种方式的UDF部署方式，可以嵌入也可以远程部署，这给与了我们很大的扩展空间。综合考虑，我们采用 java UDF 并且部署为remote service。整个流水线就变了为了 RW CDC 将订单信息通过到RW， RW MV 调用 remote UDF 对每一个订单进行打标，最后将结果sink到mysql 供业务系统查询。

需要注意的是

• remote service 的调用并不是很稳定，1万次总有几次失败，可能是网络抖动，这个时候就需要设置失败重试，否则就会得到NULL值

整体使用感受

最开始接触这个还是比较抗拒的，毕竟已经有业界比较成熟的Flink 摆在哪儿，当时我们是从比较早的版本开始试用的，还是经常能遇到一些bug，好在RW团队还是比较敏捷，团队修复发布速度较快。 整体稳定性也有待提高，偶尔因为性能问题会导致整个集群崩溃，etcd也不是很好恢复。