写点什么

将 Flink 融合进消息系统,RocketMQ 为什么选择了与 Kafka 不一样的路

  • 2021-09-27
  • 本文字数:3488 字

    阅读完需:约 11 分钟

将Flink融合进消息系统,RocketMQ为什么选择了与Kafka不一样的路

AI 大模型超全落地场景&金融应用实践,8 月 16 - 19 日 FCon x AICon 大会联诀来袭、干货翻倍!

采访嘉宾 | 袁小栋、杜恒

编辑 | Tina

 

8 月 13 日,RocketMQ 迎来了 5.0 版本,这是继 2017 年发布 4.0 版本之后时隔 5 年的一次重大更新。5.0 版本进行了架构重塑,新增或者修改了超过 60% 的代码,但是对 4.0 的所有功能以及整体架构进行了无缝兼容,且没有引入任何外部依赖。而且其中非常重要的一点是,RocketMQ 兼容了开源 Flink 生态。与 Kafka 只是作为 Flink 的上下游数据不同,RocketMQ 直接实现了 Flink 的基础功能或者算子,并首创性地兼容了 Flink/Blink SQL 标准以及 UDF/UDAF/UDTF。为什么 RocketMQ 会选择将 Flink 融合到一起?这样带来哪些好处?适合哪些应用场景?为解答这些问题,InfoQ 采访了 RocketMQ 开源负责人杜恒和 rocketmq-streams cofunder 袁小栋。

 

InfoQ:RocketMQ 5.0 版本中,您认为的最重大的三个变化是什么?

 

袁小栋、杜恒:RocketMQ 5.0 的建设,是社区与云上逐渐演进的结果,每个特性都不是一蹴而就的,如果非要总结三个最大的变化,我认为就是云原生下的场景化弹性架构事务分析一体的支持 以及 轻量级实时计算引擎 的出现。

 


场景化弹性架构具体来说,就是能够在不同场景下能够以资源使用率最高、运维成本最低的方式进行部署、交付,比如在公有云上基于云盘,RocketMQ 可以非常方便的以单副本的方式运行;在私有化部署的场景下,可以使用两副本的方式进行交付;在两地三中心、异地容灾场景下,又可以以三副本+Preferred Leader 方式进行部署。这种灵活的存储架构,使得 RocketMQ 能够充分利用云上的 IaaS 层资源,这也是从 Cloud Hosting 到 Cloud Native 的一个巨大转变。除此之外,RocketMQ 在不同的场景下也会有不同的分层架构,比如在大数据场景下,RocketMQ 可以以单体架构降低成本、提供就近计算的能力,在公有云多租场景下,会提供存储计算分离的分层架构满足不同用户的接入诉求,而且 RocketMQ 的计算层是彻底消除状态的,用户可以任意节点接入进行消息的发送接收。

 

事务分析一体或者说双引擎是消息、事件、流融合处理平台的一个具体体现,RocketMQ 在保留原来业务消息领域首选偏重于事务场景的前提下,着重对分析进行了提升,包括多索引能力的增强、批的优化、KV 语义点查能力的支持等,都是希望能够用一套架构同时满足业务消息,也能够对大数据计算分析场景进行更好的支持。

 

rocketmq-streams 也就是今天的主题,解决了用户轻量级实时计算场景下资源占用过高、运维负担较重的困扰,也满足了对 RocketMQ 之上流转的宝贵业务数据进行深度计算分析后处理的诉求。

 

InfoQ:rocketmq-streams 是将 Flink 的哪些功能融合进了 RocketMQ?这样做带来了哪些好处?

 

袁小栋、杜恒:功能上 Flink 的基础功能或者算子如 Source、Sink、map、flatmap、split、select、window、union rocketmq-streams 都做了实现,当然也包括一些基础的核心特点:Exactly-once,灵活窗口(滚动,滑动,会话),双流 Join,高吞吐、低延迟、高性能等。

 


rocketmq-streams 的设计之初主要是为了解决用户在使用 RocketMQ 过程中面临的一些轻量级计算的问题,在实时计算领域,社区一直以来的目标都是积极的与 Flink、Spark 等实时计算引擎通过生态合作的方式满足用户诉求。因此,rocketmq-streams 并非要做一个和 Flink 同质的大数据计算引擎,这个引擎场景很明确,主要是满足大数据量->高过滤->轻窗口计算的场景,重点要打造轻量化、高性能和低成本等优势

 

流能力的建设,主要是围绕场景需求来建设,当然时间关系还有部分能力未完善,从 Apache RocketMQ 自身来讲,为了更好的支撑 rocketmq-streams, RocketMQ 本身架构也会有调整, 其实主要还是做了存储能力,API 方面一些增强,比如在存储方面,在 queue 语义的基础上,增加了用于点查的 KV 语义用来更好的支持 Checkpoint 存储;逻辑队列更好的解耦 Broker 和分区,在批处理场景中,可以提高数据读取的并发度,彻底消除队列占位以及负载均衡带来的影响;为了提升吞吐量,社区也在紧锣密布的进行 batch 存储的优化;此外,社区还有意对 OpenSchema 开放标准进行支持,提升 RocketMQ 数据治理能力;这些改进不仅仅是对 rocketmq-streams 的支持,而且也会帮助 RocketMQ 成为最符合实时计算引擎 Flink 的消息系统。

 

所以总结来说,融合进来的这部分功能,相对 Flink 本身,有两大性能上的优化:

主要是针对当前要求较多的大数据量 -> 高过滤 -> 轻窗口的场景下,努力提升计算和过滤的性能;除此之外就是部署轻量化,只需要 1core、1g 即可部署,除此之外,能够较好的支持自动容错以及任务的热更新。

 

InfoQ:最开始,决定将 streams 的功能融合进来,是为了解决哪些场景的问题,有着什么样的思考路径?

 

袁小栋、杜恒:首先,前面提到过,RocketMQ 相比于 Kafka,长期以来是作为业务消息领域的首选出现在开发者面前,而在业务消息领域,大量的交易、订单、物流等核心数据通过 RocketMQ 进行流转,于是自然而然的就产生了基于这些珍贵的业务数据进行计算的需求,这是 rocketmq-streams 出现的源动力。

 

其次,在一些资源紧张、运维压力大或者计算场景相对简单的场景下,传统的做法是,用户部署一套庞大的实时计算引擎如 Spark 再把 RocketMQ 中的数据导入进去进行计算,这无疑会极大的增加用户成本以及背负沉重的运维压力,rocketmq-streams 的出现解决了这个问题,rocketmq-streams 只需要 1core、1G 即可运行,极大的降低了用户的成本以及运维压力,因此在轻量级需求、大数据的场景驱动下,rocketmq-streams 应运而生。

 

最后,从 RocketMQ 发展历史来看,RocketMQ 相比于其他消息产品一直坚持在计算方向进行探索,从 3.x 版本的 Filter server,即用户上传一段过滤逻辑到服务端加载运行(这应该也是 Function 的雏形),到 4.x 版本更加强大易用的 Tag,SQL 服务端计算过滤能力的支持,都很大程度上降低了业务服务的处理压力,如今 5.x 版本蓄势待发,在数据已经成为企业的核心价值的今天,一个更加强大的 rocketmq-streams 成为大势所趋, 这也与 RocketMQ 架构发展是一脉相承的。

 

当然幸运的是,随着 RocketMQ 生态的不断发展,不管是在社区,还是在阿里内部,一大批熟悉实时计算的开发者带着问题与思考,逐渐走进 RocketMQ 社区,共同完善 rocketmq-streams。

 

InfoQ:目前 rocketmq-streams 适合哪些场景?是否在阿里内部业务上有落地?

 

袁小栋、杜恒:rocketmq-streams 适合大数据量->高过滤->轻窗口计算的场景,如安全检测,风控,边缘计算,ETL 等场景; 不适合直接用来做窗口计算的场景,因为窗口计算会通过 RocketMQ 做 shuffle,直接做窗口计算,框架的核心过滤优势和轻量优势发挥不出来。

 

rocketmq-streams 现在是在专有云上被广泛用于入侵检测,是云盾的核心组件,在入侵检测场景中,由于所有的规则基本上都会做前置过滤且具有较高的过滤率,然后才会做较重的统计、window、join 等操作,因此在这个场景中,相比于采用其他大规模实时计算引擎,rocketmq-streams 资源占用是其他引擎的 1/70,性能有 3-5 倍的提升。当然在不同场景下,rocketmq-streams 的性能以及资源占用都会有不同的表现,欢迎大家试用并在社区积极反馈。

 

InfoQ:一些计算场景如果 rocketmq-streams 不满足,而需要同时部署 Flink,该如何权衡两套系统的计算资源和运维成本?

 

袁小栋、杜恒:rocketmq-streams 会积极融入 Flink 生态,就当前阶段来说,rocketmq-streams 可以独立部署,部署 rocketmq-streams 不会带来额外的软件开销,除此之外,现在我们正在做一个能力,rocketmq-streams 可以发布成 Flink 任务,部署在 Flink 集群上,发挥资源和性能优化的优势,使整体任务资源大幅下降,运维和资源复用一套。最后前面也提到, rocketmq-streams 的另外一个项目 rsqlDB 会对 Flink/Blink SQL、UDF/UDAF/UDTF 进行支持,当使用 rocketmq-streams 不能满足当前的计算需求时,可以将 rocketmq-streams 计算任务迁移到 Flink。

 

InfoQ:您们对流处理这部分有哪些未来规划?



袁小栋、杜恒:目标还是打造最快的轻量计算引擎,需要把轻和快做到极致。如利用 RocketMQ 架构的优势做本地计算、KV 作为远程存储等; ETL 也会是我们将来拓展的一种场景,开发 DSL,支持热更新的 ETL 也是我们将来的一个重点方向;除此之外,会积极的融入 Flink 生态,取长补短,支持更广的计算场景。

 

嘉宾简介:

袁小栋:Apache RocketMQ Committer, rocketmq-streams cofunder,阿里云安全智能计算引擎负责人

 

杜恒:Aapache RocketMQ PMC member, OpenMessaging TSC member, 阿里云消息专有云及开源生态负责人

 

延伸阅读:

终于!RocketMQ 迎来第五个大版本,深度解读“消息、事件、流”超融合处理平台

 

2021-09-27 08:0011409

评论 2 条评论

发布
用户头像
消费队列和流数据计算融为一体,成为流数据处理平台,好像可行. kafka也有个kafka strean ,利用kafka自身的消息分区和消费者模型实现分布式数据计算
2021-11-17 14:44
回复
用户头像
这是有点肆意妄为了
2021-09-30 13:40
回复
没有更多了
发现更多内容

架构误区系列6:过度异步化

agnostic

定时任务 支付系统 消息队列

Linux 安装

芯动大师

Linux Linux操作系统 11月月更

DCM:中间件家族迎来新成员

石臻臻的杂货铺

后端 SPL 11月月更

【LeetCode】自定义字符串排序Java题解

Albert

算法 LeetCode 11月月更

日期工具类-操作字符串和Date、LocalDate互转,两个日期的时间差等

共饮一杯无

Java 11月月更 日期工具类

RESTful API类渗透测试的特点

阿泽🧸

RESTful API 11月月更

kitti数据集在3D目标检测中的入门

Studying_swz

3D点云 11月月更

WordPress零门槛的付费阅读插件:WPPAY

ABC实验室

主成分分析PCA与奇异值分解SVD-降维后的矩阵components_ & inverse_transform

烧灯续昼2002

Python 机器学习 算法 sklearn 11月月更

第九期 - 模块七

wuli洋

Dockerfile 常用命令

蜗牛也是牛

设计模式之美——多用组合少用继承?

GalaxyCreater

设计模式

《编程的原则》读书笔记(三):软件架构的基本技法和非功能需求

Chares

软件工程 软件开发 编程原理 软件开发原则

基于k8s发布系统的实现

tiandizhiguai

云原生 K8s 多集群管理

企业级业务架构设计笔记三:设计起点与设计过程

程序员架构进阶

架构 业务架构 11月日更 11月月更

MongoDB源码学习:Mongo中的OpRunner

云里有只猫

mongodb 源码学习

[力扣] 剑指 Offer 第四天 - 0~n-1中缺失的数字

陈明勇

Go 数据结构与算法 力扣 11月月更

支付API设计

agnostic

API

Java中的System类

共饮一杯无

Java 11月月更 system类

开发H5都会喜欢这个Vite插件

小鑫同学

前端 插件 11月月更

制订需求分析框架和分析计划

穿过生命散发芬芳

需求分析 11月月更

AST 初探深浅,代码还能这样玩?!

蔡农曰

前端 后端 代码

极客时间运维进阶训练营第四周作业

老曹

关于python的成员方法,类方法,静态方法

乔乔

11月月更

Java顶层类Object类(toString、equals)

共饮一杯无

Java Object 11月月更

Java反射(一)反射机制

浅辄

Java 反射 11月月更

工业互联网数据处理架构

刘旭东

kafka IoT 工业互联网

jenkins pipline 基本语法

忙着长大#

设计模式之美-为什么要基于接口而非实现编程?

GalaxyCreater

设计模式

二阶思维

元闰子

人生 思维 二阶思维

日期时间类(Date、DateFormat、Calendar)

共饮一杯无

Java 11月月更 日期工具

将Flink融合进消息系统,RocketMQ为什么选择了与Kafka不一样的路_架构_Tina_InfoQ精选文章