本文作者：袁小栋，Apache RocketMQ Committer，RocketMQ Streams Cofonder，阿里云安全智能核算引擎担任人
RocketMQ Streams简介
RocketMQ Streams包含以下四个部分的定义：
（1）Lib包：轻量，启动即可运转。只需求从git下载源码，编译成jar包即可运用。
（2）SQL引擎：兼容了Flink的SQL语法，也兼容了UDF、UETF和UDAF，能够用Flink的语法或将Flink使命直接迁移并进行运用。
（3） 轻量的边际核算引擎：RocketMQ Streams和RocketMQ做了深度的集成。由于RocketMQ支撑MQTT，所以RocketMQ Streams支撑云核算的场景。此外，RocketMQ还支撑音讯的存储和转存，因而根本能够满意边际核算的大部分场景。
（4）SDK：其组件能够独立运用，也能够嵌入到事务里运用。
现有的大数据结构比方Flink、Spark、Storm等都现已非常老练，而咱们在此基础上仍然研发RocketMQ Streams这样一个敞开结构的原因，首要根据以下考虑：
Flink是一个底座比较重的大数据组件，集群开支和结构开支占比较大，运维本钱也比较高，因而合适做中台，由专门的运维人员布置，形成一个大的中台事务。
但是实际事务中必然存在中台无法满意的场景，比方某产品依靠大数据的才能，需求将产品输出给用户，在用户的IDC里布置。假如将大数据核算才能也带着一同布置，则会产生三个问题：榜首，布置费事，由于Flink的布置本钱比较高；第二，运维本钱较高；第三，资源问题，Flink的使命需求提早预设资源，不同的用户日志量不一样，预设资源会很大，Flink无法满意需求。
RocketMQ Streams的定位是合适随产品输出的场景，不合适中台。比方安全风控、边际核算、音讯行列、流核算等，都合适RocketMQ Streams。因而，RocketMQ Streams和Flink的才能能够互为补充。
RocketMQ Streams具有以下 特色：
（1）轻量：RocketMQ Streams是轻量的，1core 1g即可布置；依靠较轻，除了音讯行列没有其他依靠；发布简单，可经过SQL热更新的方法发布。
（2）高扩展：RocketMQ Streams能够扩展Source、Sink、UDF等。
（3）高功能：对过滤做了许多优化，因而在高过滤场景下，功能可提高3-5倍；RocketMQ Streams也完成了一些使命的轻量化，在SQL同源使命归并的场景下，资源可节省50%；一同，它根据流核算，能够完成毫秒推迟。
（4）多布置形式：jar包即服务；能够根据C/S形式经过提交SQL热发布，也能够经过SDK集成到事务里。
（5）超大维表支撑：支撑超大的维表，RocketMQ Streams自研的缓存内存占比仅为Java Map的16.7%；同机器上的多个使命能够同享，节省资源；维表支撑千万等级，不需求指定索引，可根据join条件主动推断索引，做到类似map的O(1)匹配。
（6）丰厚功能：支撑准确核算一次以及灵活的窗口，比方滚动窗口、滑动窗口、分发窗口，也支撑双流Join、维表Join、转化、过滤、大数据开发场景等功能。
上图为RocketMQ Streams支撑的一些惯例大数据算子，与其他大数据结构根本类似，能够进行扩展。
RocketMQ Streams架构及完成原理
不管是Spark仍是Flink，一个成功的大数据组件往往都需求由一个很大的团队经历几年的时刻才能打磨完成。完成RocketMQ Streams首要会面对以下应战：
-
大数据核算功能多且架构杂乱，是否能够完成？
-
与Flink等大数据结构的中心差异是什么，是否会做成Flink的裁剪版？
完成一个轻量级、高功能的大数据核算结构，有必要要有和Flink不一样的思路。
从事务架构剖析，一个惯例RocketMQ事务的架构根本相同，包含输入、无状况的核算、输出成果等。这种惯例的RocketMQ事务架构有两个长处：首要，比较轻量，负载均衡、容错都由RocketMQ完成，不需求别的做；其次，布置简单，假如RocketMQ堵塞，直接扩容事务、增加消费才能即可。
但是这种惯例架构很难完成核算、join以及窗口核算等杂乱核算。要完成此类杂乱核算，有必要完成shuffle，而要完成shuffle则有必要完成不同算子之间的通讯。算子之间的通讯需求有全局的调度和全局的使命办理，而全局的调度和全局的使命办理又需求资源的办理和对使命资源的分配。上述的需求会导致架构变得杂乱，使短时刻内的完成存在稳定性和杂乱性等方面的困难。
逆向考虑能够看到杂乱性的本源是shuffle，处理思路是凭借音讯行列的中转完成shuffle。以shuffle作为分割，将杂乱的拓扑变为简单的拓扑。只需重点突破整个架构的搭建、窗口核算的补充、功能的提高这三个难关，即可完成一个既轻量又有高功能的大数据核算功能结构。
大数据架构包含Spark、Flink等，惯例规划思路是核算和集群的办理一体化。集群的办理要处理高可用问题、task分配和调度问题、job和task容错问题，因而大数据架构的完成存在巨大应战：
（1）集群的办理需求使架构更重，由于高可用意味着有必要引入组件。而且在资源耗费方面，一个集群形式至少需求三个阶段，而集群的开支或许需求 10%的内存。一旦办理结构集群化，使命的分配、资源的设定都需求预设。
（2）类似窗口核算的状况存储要求比较高。大数据组件的布置对内存、大磁盘有要求，而这种要求无疑会增加架构的杂乱性。
（3）经过音讯行列中转来完成shuffle的计划或许会加大RocketMQ的压力，增加布置的杂乱性。
以上三点是根据大数据架构来考虑完成一个轻量化架构的应战。换一种思路，聚集于中心事务，用事务架构的思路去考虑。
惯例的大数据事务都会有一个音讯行列，不管音讯行列是不是RocketMQ。而大多数音讯行列都会完成分片的负载均衡和容错的办理，核算和办理的别离能够借用MQ的集群才能，存储能够选用RocketMQ的紧缩存储来完成。
MQ的最小调度单元是分片，它能够对分片进行负载均衡、容错、调度等操作。只要将使命和分片进行映射，借用MQ的分片办理，即可完成task办理，无需额定完成办理才能。复用RocketMQ的紧缩存储，也不需求额定完成存储。此外，用MQ做shuffle会加大MQ的压力。MQ的音讯量增加，使得CPU的运用率也会增加，全体资源运用率也会增加，因而要选用战略来下降资源耗费。
窗口核算的实时性不高，比方10分钟的窗口只需求每10分钟取出成果。因而能够选用微批的方法，比方1000条核算一次，将1000条根据shuffle key进行分组，分组今后多条数据合并成一条。RocketMQ根据QPS的压力，数据量变大，QPS下降，CPU的压力反而不大，然后进行紧缩，将数据量下降，终究能够削减shuffle开支。
终究成果如下：
（1）选用shared-nothing架构，没有任何集群和结构的开支。
（2）轻依靠：没有增加任何额定的依靠，虽然有MQ依靠，但MQ是事务必需的，能够直接复用事务的MQ。
（3）核算机不需求任何依靠，布置轻量，1core 1g即可布置。
（4）轻耗费：shuffle的中转完成了微批、紧缩和多条归并的战略，7000的QPS只需求0.12的CPU和300兆的内存，资源耗费非常低。
（5）轻扩容：扩容非常简单，由于选用shared-nothing架构，类似于web服务器，音讯堆积时增加实例即可扩容。
窗口的准确核算一次（Exactly-once）是一个难点。流是无边界的，要进行核算核算，则有必要区分窗口。如上图，假定D的位置是一个count，核算10分钟一共接纳多少条数据，有两种完成方法：
（1）每一条数据过来都进行缓存，每非常钟将一切数据进行核算获得成果。这种方法对存储的压力比较大，也不高效。
（2）比较高雅的方法：每来一条数据都只存中心成果，比方榜首条数据，中心成果是1，第2条是2，第3条是3。但这也存在一个问题，假如某个节点出问题或某个使命出问题，中心成果会变为不可控的状况。假如3宕机， 2和1或许会持续完成核算，也或许出现问题不进行核算。因而在B被拉起的时分回放哪条音讯是不可知的，这种状况无法成为准确核算一次。
Flink是业界准确核算最高雅的计划。它的思路很简单，在某个时刻点将整个集群的状况进行一次镜像，每隔一段时刻镜像一次。出现问题时，将一切算子的状况康复一遍再核算。
全体的核算流程如下：job manager定期发checkpoint 给它的数据源。产生两个checkpoint时，checkpoint会跟着数据在算子里走。每个算子接纳到 checkpoint时，需求备份自己的状况，比方窗口算子接纳到一个checkpoint，还无法进行状况备份，需求比及另一个checkpoint也到了之后才能做状况的备份，该规划称为对齐等待。等待的进程取决于两个checkpoint之间流速的差异。等两个checkpoint都到了今后，再同步地进行状况存储，将本地的状况存储到长途的状况。
以上进程开支较大，翻开checkpoint使使命功能会下降约30%。使命越杂乱，体系的开支越大。此外，康复时长也需求考虑，当算子和使命出问题重启时，有必要从长途读取完好的状况，一切算子康复今后才能开端核算。康复进程或许需求几秒到几分钟，时刻较长。
Flink虽然是一个高雅的计划，但仍然存在许多重操作，这是由于Flink计划从整个拓扑考虑，因而考虑点较为杂乱。
而简化的思路为，将杂乱的拓扑经过shuffle拆分红许多简单的子Job。每个子Job的逻辑也很简单，包含三点：榜首，从 source 接纳数据；第二，进行算子的核算；第三，将数据写到Sink。有些子Job算子是有状况，而有些是无状况，无状况的算例只需求确保至少消费一次的逻辑即可。
以上思路或许带来的成果是输出的Sink里存在重复的数据。假如该Sink是终究的成果，则由Sink自己决定能不能去重；假如是shuffle的行列，则会在后面有状况的算子里完成准确核算一次的逻辑。
而有状况的消费数据里存在重复数据，只需进行去重。去重的逻辑如下：在状况存储时，除了存储中心的核算成果，还需将元数据进行存储。元数据指现有的中心成果核算用到的分片以及分片的最大offset对应的数据。数据来的时分，假如该分片的offset比现已核算的小，则将它丢掉，从而经过去重完成了准确核算一次的逻辑。长途存储只需存储一份，无需定时地存储一份完好数据。
别的，Checkpoint 也不会堵塞流程，由于一个Checkpoint的发送仅仅担任获取算子当时现已存储到长途的元数据，而算子的存储进程完全能够异步和微批地进行存储。Checkpoint抵达算子后，只需求告知其成果，不会产生任何堵塞。
音讯源存储offset是根据一切状况算子里面的分片元素，取每个相同分片里的最小值存储，则崩溃后康复时必定能确保至少消费一次。此处能够有重复的数据，可经过去重确保准确核算一次。
SQL 优化器是阿里如此盾的需求。由于需求将公共云的规矩迁到专有云，而专有云的资源有限，只能用原先4%的内存和不到30%的CPU去运转原先1.2倍的规矩。而专有云的另一特色是扩容本钱较高，或许按月扩容，很难扩机器。
综上，公共云迁移到专有用，存在两个巨大应战：
榜首，要用有限的资源承载更多的规矩；
第二，安全场景需求不停地增加规矩来确保安全性，规矩要增加，但需求确保资源不随规矩增加。
因而，进行优化的时分也需求考虑安全的特色。而大部分大数据核算都具有此特色，所以这是一个通用的计划。
根据安全的特色来剖析，安全的特色有三：
（1）正则或过滤类的表达式比较多，能够运用更快的引擎来承载。
（2）一些表达式的字段重复率较高，比方命令行，不管有多少个参数，运维工作的命令都很类似。
（3）数据源比较少，但是每个数据源的规矩比较多。
根据以上三个特色，咱们考虑全体的解法如下：
（1）使命归并，削减使命开支。每起一个使命都会有一个线程池，占有必定的内存开支。而这些使命来自同一个数据源，因而能够将同数据源的公共部分抽取出来，比方对消费数据源完成部分字段的标准化，而对应的规矩能够封装成大使命。依照以上逻辑，10个使命放在一同，只需求5core 5g，所以资源耗费更少，线程更少，内存运用也更少。该解法称为同源归并逻辑。
而资源变少带来的问题是会将这一组使命的容错放在一同，一个使命有问题也会影响到其他使命。因而，用户能够按需挑选使命类型，分为资源灵敏型和过错灵敏型。
别的，同源归并不会导致规矩放在一同变杂乱而使开发测试变得更困难。由于对于开发测试，每一个规矩仍然是独立的，称为动态同源归并。同源归并是下发一个战略后主动归并，将战略撤销则会康复为独立运转，这是能够动态分配的战略。
（2）表达式指纹。一个规矩里有许多过滤条件，处理思路是将一切使命里的过滤条件都在编译期间一致收集。
一个过滤的表达式根本是三元组，包含变量、操作、值。比方正则，变量是command line，操作是正则，值是正则的串。按变量进行分组，比方一个command line有10个表达式，另一个command line有20个表达式，放在一同是30个表达式，将它分为一个表达式分组。
表达式分组的意图是缓存。一条音讯抵达时，处理流程为：先查看缓存，一切表达式分组逐个查看。假如缓存里存在，则直接使用成果；不然，将这一组表达式悉数核算完成然后生成成果。生成的成果是一个bit set，比方100个表达式会有一个100 个bit位，代表该表达式是否触发。
将command line 和bit set放在缓存里，再来一条相同command line的时分，一切表达式都不需求核算，可直接获得成果。然后查看上下文是否存在该成果，假如存在则直接运用，不然再进行核算。依照该流程，假如command line的重复率较高，比方有80%的重复率，只有20%的command line会被真正地核算，其他的只需O(1)时刻来获取成果。
在字段重复率较高的场景中，此战略需求的核算资源大幅下降，由于它能将杂乱的正则核算转化成O(1)的比对核算，资源不会跟着规矩增加而增加。
此外，运用正则的场景中字段重复率比较高，这是一个通用的特性。但即便重复率比较低，由于全体资源开支只增加了一个O(1)的比对，不会增加额定的开支。
（3）Hyperscan正则加快。将一切使命的表达式放在一同，对表达式进行预编译，尤其是正则类。比方用Hyperscan能够对1000个表达式进行预编译，每个表达式单个履行与预编译在一同履行，两者之间约有10倍距离。假如字段重复率不高，能够用Hyperscan加快正则的履行。
流式数据量非常大，存在缓存是否能撑住以及用什么缓存来承载的问题。
首要，缓存是否能撑住能够经过设定边界处理，比方设定300兆的缓存，超越则丢掉一些数据。
其次，能够选用紧缩缓存来承载，用很少的资源能够承载大的数据量。Java的map之所以占用资源较大，是由于存在许多同步、对齐、指针开支。所以缓存只能根据原生的bit数组完成，能够下降资源开支。一个key或许比较长，比方一个command line或许需求几十个或几百个字符。但运用md5存储能够紧缩到十几个字节，而且md5的抵触率、磕碰率非常低。
因而，运用md5保存key，不管key多大，都能够紧缩到16个字节。value则用原始的字节保存，没有任何头部开支。
测试显现，50Byte的key，20Byte的value，1000万的数据用紧缩存储能够到达原始数据的一半，到达Java map的17%，紧缩效果显著。
终究效果：1.2倍的安全规矩，选用32core 40g支撑12000QPS，没有增加任何物理机，也不需求扩容，可满意需求。
RocketMQ Streams在阿里云安全的使用
RocketMQ Streams的榜首个使用是专有云的安全。
专有云和公有云不一样，专有云的资源有限，将整个云布置在用户的IDC机房，在用户机房里扩资源需求向用户申请和采购，不像公有云能够随时扩充资源。因而专有用的弹性不如公共云。
大数据核算是一个产品，不是用户购买今后才会输出。用户买了安全，但不必定买大数据核算，这种状况造成用户买了安全却没有大数据核算。假如由于安全而帮用户买大数据核算，大数据核算的本钱或许比安全更高，导致了大数据落地很难，侵略检测的才能较差，风险较高。因而，咱们终究的战略是选用RocketMQ Streams计划为用户完成布置。
RocketMQ Streams计划需求32core 40g 的内存，即可承载12000QPS，根本能满意用户的需求；对比内存资源，只运用了原先公共云内存资源的4%，CPU的30%不到；从才能覆盖层面看，覆盖了悉数安全规矩，也兼容了Flink的语法规矩，只需开发一次；从安全效果层面看，由于覆盖了一切的安全规矩，完成了安全效果100%保障；从产品覆盖层面看，有多个产品在使用RocketMQ Streams。
RocketMQ Streams的第二个使用场景是云安全中心的混合云。Gartner预测将来80%的企业都会选用混合云和多云的布置形式，但是混合云和多云需求一致的安全运营办理。
多云或边际核算存在的问题首要在于，比方在阿里购买了一些ECS，在腾讯、华为购买了一些ECS，在国外也购买了一些ECS，假如要将ECS的数据汇聚在一同，日志量较大，上传本钱也高。国外的ECS数据回到国内会受到一些约束，除此之外，假如带宽不够，上传日志也或许影响正常事务。
咱们提供的处理战略很简单，将RocketMQ Streams和RocketMQ整合，支撑音讯行列存储，也支撑ETL和流核算，布置到边际端。比方阿里作为一个一致管控区，在腾讯购买两台ECS，将RocketMQ Streams和边际核算引擎布置上，可称为边际核算。在边际核算告警，丢掉原始日志，只回传告警。原始日志在本地还可转存给用户，假如用户需求，也能支撑热更新。只需一个zip包，一键SH即可装置。
RocketMQ Streams的第三个使用场景是IOT。IOT是典型的边际核算场景，应战在于需求用4core 8g来混部其事务和RocketMQ Streams使命，几百个使命的压力非常大。而且它需求选用MQTT这样标准的IOT协议输入，也需求自定义规矩引擎的才能进行核算核算、特征核算、Join核算和维表核算。
RocketMQ Streams的MQTT直接复用了RocketMQ。维表方面，能够完成维表同享，支撑千万级维表，可在同一台机器同享多个实例。SQL则能够支撑归并和热更新。
终究在IOT场景中完成了RocketMQ Streams的才能建设和用户落地。
未来规划
RocketMQ Streams的未来规划包含四个方向：
（1）现在引擎只完成了中心才能建设，配套才能尚有所短缺，未来会进行比方资源调度、监控、控制台、稳定性等方面的完善，使开源用户能够更好地落地。
（2）持续打磨边际核算的最佳实践。
（3）CEP、流批一体和机器学习才能的推进。
（4）丰厚音讯接入的才能，比方增加文件、syslog、http的接入；持续增强ETL的才能，打造音讯闭环；支撑 ES 作为数据源，根据查找的成果。
相关开源地址：
RocketMQ-Streams：
github.com/apache/rock…
RocketMQ-Streams-SQL：
github.com/alibaba/rsq…
参加 Apache RocketMQ 社区
十年铸剑，Apache RocketMQ 的成长离不开全球挨近 500 位开发者的积极参加贡献，相信在下个版本你便是 Apache RocketMQ 的贡献者，在社区不仅能够结识社区大牛，提高技术水平，也能够提高个人影响力，促进本身成长。
社区 5.0 版本正在进行着如火如荼的开发，别的还有挨近 30 个 SIG（兴趣小组）等你参加，欢迎立志打造世界级分布式体系的同学参加社区，增加社区开发者微信：rocketmq666 即可进群，参加贡献，打造下一代音讯、事情、流交融处理渠道。
微信扫码增加小火箭进群
别的还能够参加钉钉群与 RocketMQ 爱好者一同广泛评论：
钉钉扫码加群
关注「Apache RocketMQ」公众号，获取更多技术干货
