心得的体会
刚过了年刚开工,闲暇之余调研了分布式SQL流处理数据库–RisingWave,本人是Flink(包括FlinkSQL和Flink DataStream API)的资深用户,但接触到RisingWave令我眼前一亮,并且拿我们生产上的监控告警场景在RisingWave上做了验证,以下是自己的心得体会:
RisingWave架构简单,运维成本底,基于云原生(可以分别基于计算和存储动态伸缩),同时在开发上屏蔽了Flink等实时处理框架底层需要处理的一些技术细节(状态存储,数据一致性,分布式集群扩展等)。提供了与PostgreSQL兼容的标准SQL接口,用户可以像使用 PostgreSQL 一样处理数据流。并且RisingWave不单单可以处理流式数据,还提供了数据其他流式处理框架(如:Flink、storm)所不具备的数据存储能力,基本可以完全取代FlinkSQL。相对于其他OLAP系统(如:apache doris,starrocks),RisingWave采用同步实时,可以保证实时的新鲜度;强一致性,而不是最终一致性。用户需要做的仅仅是通过开发SQL就可以处理流数据,当然首先需要具备流式数据处理思维(相对于离线)。
RisingWave当然也有自身的不足,相对于Flink可以通过DataStream API自定义灵活的处理流式数据,RisingWave只能解决一些特定的流式场景,无法做太多定制开发;相对于Apache Doris等OLAP实时分析性数据库,RisingWave不适合做分析型随机查询。另外RisingWave是个新事物,正在发展阶段,周边生态和相关文档还不健全,作为尝鲜者可能会踩很多坑。然而令人欣慰的是RisingWave的社区回复还是很及时的,RisingWave官方投入了很多精力在做RisingWave的布道和答疑。
至于争论比较厉害的RisingWav VS FLink的性能和吞吐量上孰优孰劣,针对不同应用场景可能有不同表现,因此没有亲自调研就没有发言权。但我认为在不同的场景下他们应该有各自的优势。无论如何RisingWave部署简单,上手容易,试错成本低是一个不争的事实。RisingWave可以应用在一些数据看版,监控,实时指标等场景。
利用动态和时间过滤器实现监控告警
FlinkSQL解决不了定时触发的问题,FlinkSQL的流处理逻辑只是按event触发,不能按时间条件触发,也就是没有触发器机制。FlinkSQL窗口的定时触发,归根结底也是基于event触发,event驱动的机制。因此需要触发器的场景就需要用到Flink DataStream API的KeyedProcessFunction等算子。但RisingWave利用Dynamic filters 和 Temporal filters 可以间接实现类似场景的触发器机制。
场景描述
现有如下群消息实时指标监控场景:
数据有初始化(init)、查询(query)、回调(callback:succ+fail)三种先后顺序状态。
数据是按预设时间批次分组的,例如:2024-01-01 08:00:00、2024-01-01 08:30:00,实时统计每一个批次内三种不同状态的数据count。
监控指标一:在某一个批次延迟指定的时间(query_timeout)之内(例如:2024-01-01 08:00:00延迟1小时触发时间为系统时间2024-01-01 09:00:00),该批次的query状态数据count没有达到init状态的数量count阀值(即query_count<init_count*query_threshold)就触发告警。
同时结束该批次数据统计,下发该批次数据的指标包括:批次时间、init_count、query_count等
监控指标二:如果指标一告警没有被触发,该批次在满足query状态数据count达到init状态数量count的阀值(即query_count>=init_countquery_threshold)以后,在指定的延迟时间内(callback_timeout),该批次的callback状态数据count没有达到query状态的数量count阀值(即callback_count<query_countcallback_threshold)就触发告警。
同时结束该批次数据统计,下发该批次数据的指标包括:批次时间、init_count、query_count、callback_count等
群消息实时指标监控流程图如下:
实例demo
RisingWave部署可以参考:RisingWave分布式SQL流处理数据库调研
假设:
query_threshold=1, callback_count=1
query_timeout= ‘5 minute’, callback_timeout= ‘1 minute’
0->init,1->query,2->callback
RisingWave SQL:
DROP TABLE t_msg;
CREATE TABLE t_msg(
msg_id int
,status smallint
,public_time timestamp
,process_time timestamp as proctime()
) APPEND ONLY;
set timezone = 'PRC';--PRC(People’s Republic of China)
show timezone;
select * from t_msg;
--统计不同状态的count
DROP MATERIALIZED VIEW mv_t_msg_groupby;
CREATE MATERIALIZED VIEW mv_t_msg_groupby AS
SELECT
public_time
,sum(case when status = 0 then 1 else 0 end) AS init_count
,sum(case when status = 1 then 1 else 0 end) AS query_count
,sum(case when status = 2 then 1 else 0 end) AS callback_count
,max(process_time) as process_time
FROM t_msg
group by public_time;
select * from mv_t_msg_groupby;
--sink_query_alarm
DROP SINK sink_query_alarm;
CREATE SINK sink_query_alarm AS
SELECT
public_time
,init_count
,query_count
,process_time
FROM mv_t_msg_groupby
where public_time + INTERVAL '5 minute' <= now() --query_timeout=1 minute, public_time相当于当前时间延迟1分钟触发,【Delay table changes】
and init_count*1 > query_count --query_threshold=1
WITH (
connector='kafka',
properties.bootstrap.server='192.168.1.100:8092',
topic='t_sink_query_alarm'
)
FORMAT PLAIN ENCODE JSON(
force_append_only='true'
);
--由于RisingWave不支持在【MATERIALIZED VIEW】和【SINK】等【可伸缩流】中指定处理时间字段,因此需要借助外部存储kafka周转
--RisngWave官方给的解释:support a proctime on an append only stream might be easier but on retractable stream could take extra cost. We must think it carefully to introduce such a feature.
--sink_query_succ
DROP SINK sink_query_succ;
CREATE SINK sink_query_succ AS
SELECT
public_time
,init_count
,query_count
,callback_count
,process_time as query_succ_process_time
FROM mv_t_msg_groupby
where public_time + INTERVAL '5 minute' >= now() --query_timeout=1 minute, 在指定的时间内,【Delete and clean expired data】
and init_count*1 <= query_count --query_threshold=1,query_count达到了指定值
WITH (
connector='kafka',
properties.bootstrap.server='192.168.1.100:8092',
topic='t_sink_query_succ'
)
FORMAT PLAIN ENCODE JSON(
force_append_only='true'
);
--source连接器
DROP SOURCE source_query_succ;
CREATE SOURCE IF NOT EXISTS source_query_succ (
init_count int
,query_count int
,callback_count int
,public_time timestamp
,query_succ_process_time timestamp
)
WITH (
connector='kafka',
topic='t_sink_query_succ',
properties.bootstrap.server='192.168.1.100:8092',
scan.startup.mode='earliest', -- earliest ,latest,default:earliest
) FORMAT PLAIN ENCODE JSON;
select * from source_query_succ;
--sink_callback_alarm,用到动态过滤器和时间过滤器
DROP SINK sink_callback_alarm;
CREATE SINK sink_callback_alarm AS
WITH tmp AS (
select public_time, min(query_succ_process_time) as query_succ_process_time -- 动态过滤器
FROM source_query_succ
group by public_time
)
SELECT
b.public_time
,b.init_count
,b.query_count
,b.callback_count
,b.process_time
,a.query_succ_process_time
FROM tmp a
JOIN mv_t_msg_groupby b ON a.public_time=b.public_time
where a.query_succ_process_time + INTERVAL '1 minute' <= now() --query_timeout=1 minute, public_time相当于当前时间延迟1分钟触发,【Delay table changes】
and b.query_count*1 > b.callback_count --callback_threshold=1
WITH (
connector='kafka',
properties.bootstrap.server='192.168.1.100:8092',
topic='t_sink_callback_alarm'
)
FORMAT PLAIN ENCODE JSON(
force_append_only='true'
);
-- 模拟数据
--init
INSERT INTO t_msg values(1,0,'2024-02-23 15:55:00'::TIMESTAMP); --比当前系统时间早
INSERT INTO t_msg values(2,0,'2024-02-23 15:55:00'::TIMESTAMP);
INSERT INTO t_msg values(3,0,'2024-02-23 15:55:00'::TIMESTAMP);
--query
INSERT INTO t_msg values(1,1,'2024-02-23 15:55:00'::TIMESTAMP);
INSERT INTO t_msg values(2,1,'2024-02-23 15:55:00'::TIMESTAMP);
INSERT INTO t_msg values(3,1,'2024-02-23 15:55:00'::TIMESTAMP);
--callback
INSERT INTO t_msg values(1,2,'2024-02-23 15:55:00'::TIMESTAMP);
INSERT INTO t_msg values(2,2,'2024-02-23 15:55:00'::TIMESTAMP);
INSERT INTO t_msg values(3,2,'2024-02-23 15:55:00'::TIMESTAMP);
查看监控结果:
docker run -it --rm edenhill/kcat:1.7.1 kcat -b 192.168.1.100:8092 -t t_sink_query_alarm -C
docker run -it --rm edenhill/kcat:1.7.1 kcat -b 192.168.1.100:8092 -t t_sink_callback_alarm -C