本文作者：袁小栋，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：
https://github.com/apache/roc…
RocketMQ-Streams-SQL：
https://github.com/alibaba/rs…
退出 Apache RocketMQ 社区
十年铸剑，Apache RocketMQ 的成长离不开寰球靠近 500 位开发者的积极参与奉献，置信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅能够结识社区大牛，晋升技术水平，也能够晋升集体影响力，促成本身成长。
社区 5.0 版本正在进行着热火朝天的开发，另外还有靠近 30 个 SIG（兴趣小组）等你退出，欢送立志打造世界级分布式系统的同学退出社区，增加社区开发者微信：rocketmq666 即可进群，参加奉献，打造下一代音讯、事件、流交融解决平台。
微信扫码增加小火箭进群
另外还能够退出钉钉群与 RocketMQ 爱好者一起宽泛探讨：
钉钉扫码加群
关注「Apache RocketMQ」公众号，获取更多技术干货
发表回复