秒秒pk10计划三期必中为什么说流处理即未来?

  • 时间:
  • 浏览:0
  • 来源:5分PK10-5分PK10官方

为那此说流处理即未来? ......

本文下发自Stepha秒秒pk10计划三期必中n Ewen在Flink Forward China 2018 上的演讲《Stream Processing takes on Everything》。

亲戚亲戚我们都我们都我们都 都好,今天我的演讲主题看似比较激进:流处理处理所有问题报告 。从这俩程度上来说,我应该 认为这俩演讲是一个多多晓伟对Flink未来(详情参见上一篇文章:Apache Flink®- 重新定义计算)描述的一个多继续。或多或秒秒pk10计划三期必中少或多或少人由于对Flink还是在等待在最初的认知,我确实Flink是一个多流处理引擎,实际上Flink后能 做或多或少或多或少或多或少的工作,比如批处理,比如应用应用程序池池。接下来我会简单的说明我对Flink功能的观点,假如我会深入介绍一个多有点领域的应用和事件处理场景。这俩场景乍看起来都一个多多流处理的使用场景,假如在我看来,实际上它而是一个多很有趣的流处理使用场景。

上图对为那此流处理后能 处理一切作出诠释,将数据看做流是一个多自然而又十分强大的想法。大要素数据的产生过程都是随时间生成的流,比如一个多Petabyte的数据不不凭空产生。那此数据通常都是或多或少事件的积累,比如支付、将商品倒进购物车,网页浏览,传感器采样输出。

基于数据是流的想法,亲戚亲戚我们都我们都我们都 都对数据处理后能 有相应的理解。比如将过去的历史数据看做是一个多截止到某一时刻的有限的流,或是将一个多实时处理应用看成是从某一个多时刻现在结束处理未来到达的数据。由于在未来某个时刻它会停止,后能 了 它就变成了处理从现在结束时刻到停止时刻的有限数据的批处理。当然,它都是由于经常运秒秒pk10计划三期必中行下去,不断处理新到达的数据。这俩对数据的重要理解最好的办法非常强大,基于这俩理解,Flink后能 支持整个数据处理范畴内的所有场景。

最广为人知的Flink使用场景是流分析、连续处理(由于说渐进式处理),那此场景中Flink实时由于近实时的处理数据,由于下发一个多多提到的历史数据假如连续的对那此事件进行计算。晓伟在一个多多的演讲中提到一个多非常好的例子来说明怎么才能 在么在样通过对Flink进行或多或少优化,进而后能 针对有限数据集做或多或少有点的处理,这使得Flink不能很好的支持批处理的场景,从性能上来说不能与最先进的批处理引擎相媲美。而在这根轴的另一头,是我今天的演讲将要说明的场景 – 事件驱动的应用。类似于应用普遍占据 于任何服务由于微服务的架构中。类似于应用接收各类似于件(由于是RPC调用、HTTP请求),假如对那此事件作出或多或少响应,比如把商品倒进购物车,由于加入社交网络中的某个群组。

在我进一步展开今天的演讲一个多多,帮我先对社区在Flink的传统领域(实二十四时 析、连续处理)近期所做的工作做一个多介绍。Flink 1.7在2018年11月300日由于发布。在Flink 1.7中为典型的流处理场景加入了或多或少非常有趣的功能。比如我被委托人非常感兴趣的在流式SQL中带时间版本的Join。一个多基本想法是一个多多不同的流,其中一个多流被定义为随时间变化的参照表,一个多多是与参照表进行Join的事件流。比如事件流是一个多订单流,参照表是不断被更新的汇率,而每个订单都要使用最新的汇率来进行换算,并将换算的结果输出到结果表。这俩例子在标准的SQL当中实际上太久容易表达,但在亲戚亲戚我们都我们都我们都 都对Streaming SQL做了或多或少小的扩展一个多多,这俩逻辑表达变得非常简单,亲戚亲戚我们都我们都我们都 都发现一个多多的表达有非常多的应用场景。

一个多多在流处理领域十分强大的新功能是将比较复杂事件处理(CEP)和SQL相结合。CEP应用观察事件模式。比如某个CEP应用观察股市,当一个多多上涨后紧跟一个多下跌时,这俩应用由于做些交易。再比如一个多观察温度计的应用,当它发现有温度计在一个多超过90摄氏度的读数一个多多的两分钟里后能 了 任何操作,由于会进行或多或少操作。与SQL的结合使类似于逻辑的表达也变得非常简单。

第一个多Flink 1.7中做了或多或少或多或少工作的功能是Schema升级。这俩功能和基于流的应用紧密相关。就像我应该 对数据库进行数据Schema升级一样,我应该 修改Flink表中列的类型由于重新写一个多列。

另外帮我简单介绍的是流处理技术不仅仅是简单对数据进行计算,这还包括了或多或少或多或少与外部系统进行事务交互。流处理引擎都要在采用不同协议的系统之间以事务的最好的办法移动数据,并保证计算过程和数据的一致性。这俩要素功能也是在Flink 1.7中得到了增强。

以上我对Flink 1.7的新功能向亲戚亲戚我们都我们都我们都 都做了简单总结。下面让亲戚亲戚我们都我们都我们都 都来看看今天我演讲的主要要素,也而是利用Flink来搭建应用和服务。我将说明为那此流处理是一个多搭建应用和服务由于微服务的有趣技术。

我将从左边这俩厚度比较复杂的图说起,亲戚亲戚我们都我们都我们都 都一会儿将聊或多或少其中的细节。首先亲戚亲戚我们都我们都我们都 都来看一个多理解应用简单的视角。如左图所示,一个多应用后能 一个多Container,一个多Spring应用,由于Java应用、Ruby应用,等等。这俩应用从秒秒pk10计划三期必中诸如RPC,HTTP等渠道接收请求,假如最好的办法请求进行数据库变更。这俩应用也由于调用一个多多微服务并进行下一步的处理。亲戚亲戚我们都我们都我们都 都后能 非常自然的想到进入到应用的那此请求后能 看做是个事件组成的序列,或多或少或多或少亲戚亲戚我们都我们都我们都 都后能 把它们看做是事件流。由于那此事件被缓占据 消息队列中,而应用会从消息队列中消费那此事件进行处理,当应用都要响应一个多请求时,它将结果输出到一个多多消息队列,而请求发送方后能 从这俩消息队列中消费得到所发送请求的响应。在这张图中亲戚亲戚我们都我们都我们都 都由于后能 想看 或多或少有趣的不同。

第一个多不同是在这张图中应用和数据库不再是分开的一个多实体,而是被一个多有请况的流处理应用所代替。或多或少或多或少在流处理应用的架构中,不再有应用和数据库的连接了,它们被倒进了一并。这俩做法有利有弊,但其中或多或少好处是非常重要的。首先是性能上的好处是明显的,由于应用不再都要和数据库进行交互,处理后能 基于内存中的变量进行。其次这俩做法有很好假如很简单的一致性。

这张图被比较复杂了或多或少或多或少,实际上亲戚亲戚我们都我们都我们都 都通常会有或多或少或多或少个应用,而都一个多多被隔离的应用,或多或少或多或少请况下你的应用会更符合这张图。系统带有个接收请求的接口,假如请求被发送到第一个多应用,由于会再被发到一个多多应用,假如得到相应。在图中或多或少应用会消费上边结果的流。这张图由于展示了为那此流处理是更适合比较比较复杂的微服务场景的技术。由于或多或少或多或少一个多多系统中不不一个多多直接接收用户请求并直接响应的服务,通常来说一个多微服务都要跟或多或少微服务通信。这正如在流处理的架构中不同应用在创建输出流,一并基于衍生出的流再创建并输出新的流。

到目前为止,亲戚亲戚我们都我们都我们都 都想看 的内容多少还比较直观。而对基于流处理技术的微服务架构而言,亲戚亲戚我们都我们都我们都 都最常问的一个多问题报告 是怎么才能 才能 保证事务性?由于系统中使用的是数据库,通常来说后该有非常心智心智成熟期期比较复杂的数据校验和事务模型。这也是数据库在过去或多或少年中十分成功的由于。现在结束一个多事务,对数据做或多或少操作,提交由于撤回一个多事务。这俩机制使得数据全部性得到了保证(一致性,持久性等等)。

后能 了 在流处理中亲戚亲戚我们都我们都我们都 都怎么才能 在么在做到同样的事情呢?作为一个多优秀的流处理引擎,Flink支持了恰好一次语义,保证了每个事件只会被处理一遍。假如这依然对或多或少操作有限制,这也成为了使用流处理应用的一个多障碍。亲戚亲戚我们都我们都我们都 都通过一个多非常简单流处理应用例子来看亲戚亲戚我们都我们都我们都 都后能 做或多或少那此扩展来处理这俩问题报告 。亲戚亲戚我们都我们都我们都 都会想看 ,处理最好的办法我我确实出奇的简单。

让亲戚亲戚我们都我们都我们都 都以这俩教科书式的事务为例子来看一下事务性应用的过程。这俩系统维护了账户和其中存款余额的信息。一个多多的信息由于是银行由于在线支付系统的场景中用到的。假设亲戚亲戚我们都我们都我们都 都我应该 处理类似于下面的事务:

由于账户A中的余额大于3000,后能 了 从账户A中转账3000元到账户B。

这是个非常简单的一个多账户之间进行转账的例子。

数据库对于一个多多的事务由于有了一个多核心的范式,也而是原子性,一致性,隔离性和持久性(ACID)。这是不能让用户放心使用事务的多少基本保证。有了亲戚我们都我们都我们都 都,用户不不担心钱在转账过程中会丢失由于或多或少问题报告 。让亲戚亲戚我们都我们都我们都 都用这俩例子来倒进流处理应用中,来让流处理应用不能提供和数据相同的ACID支持:

原子性要求一个多转账要不就全部完成,也而是说转账金额从一个多账户减少,并增加到一个多多账户,要不就一个多账户的余额都后能 了 变化。而不不只一个多多账户余额改变。假如语录钱就会凭空减少由于凭空增加。

一致性和隔离性是说由于有或多或少或多或少用户一并我应该 进行转账,后能 了 那此转账行为之间应该互不干扰,每个转账行为应该被独立的完成,假如完成后每个账户的余额应该是正确的。也而是说由于一个多用户一并操作同一个多账户,系统不应该出错。

持久性指的是由于一个多操作由于完成,后能 了 这俩操作的结果会被妥善的保存而不不丢失。

亲戚亲戚我们都我们都我们都 都假设持久性由于被满足。一个多流处理器有请况,这俩请况会被checkpoint,或多或少或多或少流处理器的请况是可恢复的。也而是说假如亲戚亲戚我们都我们都我们都 都完成了一个多修改,假如这俩修改被checkpoint了,后能 了 这俩修改而是持久化的。

让亲戚亲戚我们都我们都我们都 都来看看另外一个多例子。设想一下,由于亲戚亲戚我们都我们都我们都 都用流处理应用来实现一个多多一个多转账系统会占据 那此。亲戚亲戚我们都我们都我们都 都先把问题报告 比较复杂或多或少,假设转账不都要有条件,仅仅是将3000元从账户A转到账户,也而是说账户A的余额减少3000元而账户B的余额增加3000元。亲戚亲戚我们都我们都我们都 都的系统是一个多分布式的并行系统,而都一个多多单机系统。简单起见亲戚亲戚我们都我们都我们都 都假设系统中后能 了两台机器,这两台机器后能 有不同的物理机由于是在YARN由于Kubernetes上不同的容器。总之它们是一个多不同的流处理器实例,数据分布在这俩个多流处理器上。亲戚亲戚我们都我们都我们都 都假设账户A的数据由其中一台机器维护,而账户B的数据有另一台机器维护。

现在亲戚亲戚我们都我们都我们都 都是做个转账,将3000元从账户A转移到账户B,亲戚亲戚我们都我们都我们都 都把这俩请求倒进队列中,假如这俩转账请求被分解为对账户A和B分别进行操作,假如根据键将这俩个多操作路由到维护账户A和维护账户B的这两台机器上,这两台机器分别根据要求对账户A和账户B的余额进行改动。这并都是事务操作,而而是一个多独立无意义的改动。一旦亲戚亲戚我们都我们都我们都 都将转账的请求改的稍微比较复杂或多或少就会发现问题报告 。

下面亲戚亲戚我们都我们都我们都 都假设转账是有条件的,亲戚亲戚我们都我们都我们都 都只想在账户A的余额足够的请况下才进行转账,一个多多就由于或多或少不太对了。由于亲戚亲戚我们都我们都我们都 都还是像一个多多那样操作,将这俩转账请求分别发送给维护账户A和B的两台机器,由于A后能 了 足够的余额,后能 了 A的余额不不占据 变化,而B的余额由于由于被改动了。亲戚亲戚我们都我们都我们都 都就违反了一致性的要求。

亲戚亲戚我们都我们都我们都 都想看 亲戚亲戚我们都我们都我们都 都都要首先以这俩最好的办法统一做出与非 都要更改余额的决定,由于这俩统一的决定中余额都要被修改,亲戚亲戚我们都我们都我们都 都再进行修改余额的操作。或多或少或多或少亲戚亲戚我们都我们都我们都 都先给维护A的余额的机器发送一个多请求,让它查看A的余额。亲戚亲戚我们都我们都我们都 都不后能 对B做同样的事情,假如这俩例子上边亲戚亲戚我们都我们都我们都 都是关心B的余额。假如亲戚亲戚我们都我们都我们都 都把所一个多多多的条件检查的请求汇总起来去检验条件与非 满足。由于Flink一个多多的流处理器支持迭代,由于满足转账条件,亲戚亲戚我们都我们都我们都 都后能 把这俩余额改动的操作倒进迭代的反馈流当中来告诉对应的节点来进行余额修改。反之由于条件不满足,后能 了 余额改动的操作将不不被倒进反馈流。这俩例子上边,通过这俩最好的办法亲戚亲戚我们都我们都我们都 都后能 正确的进行转账操作。从这俩厚度上来说亲戚亲戚我们都我们都我们都 都实现了原子性,基于一个多条件亲戚亲戚我们都我们都我们都 都后能 进行全部的余额修改,由于不进行任何余额修改。这要素依然还是比较直观的,更大的困难是在于怎么才能 才能 做到并发请求的隔离性。

假设亲戚亲戚我们都我们都我们都 都的系统后能 了 变,假如系统带有多个并发的请求。亲戚亲戚我们都我们都我们都 都是一个多多的演讲中由于知道,一个多多的并发由于达到每秒钟几十亿条。如图,亲戚亲戚我们都我们都我们都 都的系统由于从一个多流中一并接受请求。由于这俩个多请求一并到达,亲戚亲戚我们都我们都我们都 都像一个多多那样将每个请求拆分成多个请求,首先检查余额条件,假如进行余额操作。然而亲戚亲戚我们都我们都我们都 都发现这会带来问题报告 。管理账户A的机器会首先检查A的余额与非 大于3000,假如又会检查A的余额与非 大于3000,由于一个多条件都满足,或多或少或多或少两笔转账操作后该进行,但实际上账户A上的余额由于无法一并完成两笔转账,而后能 了完成3000元由于3000元的转账中的一笔。这里亲戚亲戚我们都我们都我们都 都都要进一步思考怎么才能 在么在样来处理并发的请求,亲戚亲戚我们都我们都我们都 都是能而是简单地并发处理请求,这会违反事务的保证。从这俩厚度来说,这是整个数据库事务的核心。数据库的专家们花了或多或少时间提供了不同处理方案,有的方案比较简单,有的则很比较复杂。但所有的方案都都是后能 了 容易,尤其是在分布式系统当中。

在流处理中怎么才能 在么在处理这俩问题报告 呢?直觉上讲,由于亲戚亲戚我们都我们都我们都 都不能让所有的事务都按照顺序依次占据 ,后能 了 问题报告 就处理了,这也被成为可序列化的形状。假如亲戚亲戚我们都我们都我们都 都当然不希望所有的请求都被依次顺序处理,这与亲戚亲戚我们都我们都我们都 都使用分布式系统的初衷相违背。或多或少或多或少亲戚亲戚我们都我们都我们都 都都要保证那此请求最后的产生的影响看起来是按照顺序占据 的,也而是一个多请求产生的影响是基于前一个多请求产生影响的基础之上的。换句话说也而是一个多事务的修改都要在前一个多事务的所有修改都完成后不能进行。这俩希望一件事在另一件事一个多多占据 的要求看起来半生不熟悉,这似乎是亲戚亲戚我们都我们都我们都 都一个多多在流处理中一个多多遇到过的问题报告 。是的,这听上去像是事件时间。用厚度比较复杂的最好的办法来解释,由于所有的请求都是不同的事件时间产生,即使由于种种由于亲戚我们都我们都我们都 都到达处理器的时间是乱序的,流处理器依然会根据亲戚我们都我们都我们都 都的事件时间来对亲戚我们都我们都我们都 都进行处理。流处理器会使得所有的事件的影响看上去都是按顺序占据 的。按事件时间处理是Flink由于支持的功能。

后能 了 全部说来,亲戚亲戚我们都我们都我们都 都到底怎么才能 在么在处理这俩一致性问题报告 呢?假设亲戚亲戚我们都我们都我们都 都是并行的请求输入并行的事务请求,那此请求读取或多或少表中的记录,假如修改或多或少表中的记录。亲戚亲戚我们都我们都我们都 都首先都要做的是把那此事务请求根据事件时间顺序摆放。那此请求的事务时间后能 了够相同,假如亲戚我们都我们都我们都 都之间的时间也都要足够接近,这是由于在事件时间的处理过程中会引入一定的延迟,亲戚亲戚我们都我们都我们都 都都要保证占据 理的事件时间在向前推进。假如第一步是定义事务执行的顺序,也而是说都要一个多多聪明的算法来为每个事务制定事件时间。在图上,假设这俩个多事务的事件时间分别是T+2, T和T+1。后能 了 第八个事务的影响都要在第一和第一个多事务一个多多。不同的事务所做的修改是不同的,每个事务后该产生不同的操作请求来修改请况。亲戚亲戚我们都我们都我们都 都现在都要将对访问每个行和请况的事件进行排序,保证亲戚我们都我们都我们都 都的访问是符合事件时间顺序的。这也由于那此相互之间后能 了 关系的事务之间自然不后能 了 了任何影响。比如这里的第一个多事务请求,它与前一个多事务之间后能 了 访问一并的请况,或多或少或多或少它的事件时间排序与前一个多事务也相互独立。而当前一个多事务之间的操作的到达顺序与事件时间不符时,Flink则会最好的办法它们的事件时间进行排序后再处理。

都要承认,一个多多说还是进行了或多或少比较复杂,亲戚亲戚我们都我们都我们都 都还都要做或多或少事情来保证高效执行,假如总体原则上来说,这而是全部的设计。除此之外亲戚亲戚我们都我们都我们都 都是要都要更多或多或少东西。

为了实现这俩设计,亲戚亲戚我们都我们都我们都 都引入了这俩聪明的分布式事件时间分配机制。这里的事件时间是逻辑时间,它太久都要有那此现实意义,比如它不需而是真实的时钟。使用Flink的乱序处理能力,假如使用Flink迭代计算的功能来进行或多或少前提条件的检查。那此而是亲戚亲戚我们都我们都我们都 都构建一个多支持事务的流处理器的要素。

亲戚亲戚我们都我们都我们都 都实际上由于完成了这俩工作,称之为流式账簿(Streaming Ledger),这是个在Apache Flink上很小的库。它基于流处理器做到了满足ACID的多键事务性操作。我相信这是个非常有趣的进化。流处理器一现在结束基本里后能 了 任何保障,假如类似于Storm的系统增加了合适一次的保证。但显然合适一次依然不足英文好。假如亲戚亲戚我们都我们都我们都 都想看 了恰好一次的语义,这是一个多大的进步,但这而是对于单行操作的恰好一次语义,这与键值库很类似于。而支持多行恰好一次由于多行事务操作将流处理器提升到了一个多后能 处理传统意义上关系型数据库所应用场景的阶段。

Streaming Ledger的实现最好的办法是允许用户定义或多或少表和对那此表进行修改的函数。Streaming Ledger会运行那此函数和表,所有的那此一并编译成一个多Apache Flink的有向无环图(DAG)。Streaming Ledger会注入所有事务时间分配的逻辑,以此来保证所有事务的一致性。

搭建一个多多一个多库太久难,难的是让它高性能的运行。让亲戚亲戚我们都我们都我们都 都来看看它的性能。那此性能测试是多少月一个多多的,亲戚亲戚我们都我们都我们都 都不后能 了 做那此有点的优化,亲戚亲戚我们都我们都我们都 都而是想看 看或多或少最简单的最好的办法不能有那此样的性能表现。而实际性能表现看起来相当不错。由于你看那此性能条形成的阶梯跨度,随着流处理器数量的增长,性能的增长相当线性。在事务设计中,后能 了 任何协同由于锁参与其中。这而是流处理,将事件流推入系统,缓存一小段时间来做或多或少乱序处理,假如做或多或少本地请况更新。在这俩方案中,后能 了 那此有点代价高昂的操作。在图中性能增长似乎超过了线性,帮我这主而是由于JAVA的JVM当中GC的工作由于由于的。在3一个多节点的请况下亲戚亲戚我们都我们都我们都 都每秒后能 处理合适两百万个事务。为了与数据库性能测试进行对比,通常当你看数据库的性能测试时,我应该 想看 类似于读写操作比的说明,比如10%的更新操作。而亲戚亲戚我们都我们都我们都 都的测试使用的是3000%的更新操作,而每个写操作合适更新在不同分区上的4行数据,亲戚亲戚我们都我们都我们都 都的表的大小合适是两亿行。即便后能 了 任何优化,这俩方案的性能也非常不错。

一个多多在事务性能带有趣的问题报告 是当更新的操作对象是一个多比较小的集合时的性能。由于事务之间后能 了 冲突,并发的事务处理是一个多容易的事情。由于所有的事务都独立进行而互不干扰,那你是所以是那此问题报告 ,任何系统应该都能很好的处理一个多多的问题报告 。当所有的事务都现在结束操作同或多或少行时,事情现在结束变得更有趣了,你都要隔离不同的修改来保证一致性。或多或少或多或少亲戚亲戚我们都我们都我们都 都现在结束比较一个多只读的应用程序池池、一个多又读又写假如后能 了 写冲突的应用程序池池和一个多又读又写并有中等程度写冲突的应用程序池池这三者之间的性能。我应该 想看 性能表现相当稳定。这就像是一个多乐观的并发冲突控制,表现很不错。那由于亲戚亲戚我们都我们都我们都 都真的我应该 针对类似于系统的阿喀琉斯之踵进行考验,也而是反复的更新同一个多小集合中的键。在传统数据库中,这俩请况下由于会出显 反复重试,反复失败再重试,这是这俩亲戚亲戚我们都我们都我们都 都总想处理的糟糕请况。是的,亲戚亲戚我们都我们都我们都 都的确都要付出性能代价,这很自然,由于由于你的表带有几行数据每被委托人都想更新,后能 了 你的系统就抛弃了并发性,这这俩而是个问题报告 。假如这俩请况下,系统并没崩溃,它仍然在稳定的处理请求,我确实抛弃了或多或少并发性,假如请求依然不能被处理。这是由于亲戚亲戚我们都我们都我们都 都后能 了 冲突重试的机制,我应该 认为亲戚亲戚我们都我们都我们都 都一个多多基于乱序处理天然冰的冲突处理的机制,这是这俩非常稳定和强大的技术。

亲戚亲戚我们都我们都我们都 都还尝试了在跨地域分布的请况下的性能表现。比如亲戚亲戚我们都我们都我们都 都是美国、巴西,欧洲,日本和澳大利亚各设置了一个多Flink集群。也而是说亲戚亲戚我们都我们都我们都 都是个全球分布的系统。由于你在使用一个多关系型数据库,后能 了 我应该 付出相当高昂的性能代价,由于通信的延迟变得相当高。跨大洲的信息交互比在同一个多数据中心甚至同一个多机架上的信息交互要产生大得多的延迟。假如有趣的是,流处理的最好的办法对延迟并都是十分敏感,延迟对性能有所影响,假如相比其它或多或少或多或少方案,延迟对流处理的影响要小得多。或多或少或多或少,在一个多多的全球分布式环境中执行分布式应用程序池池,的确会有更差的性能,要素由于也是由于跨大洲的通信数率不如统一数据中心里的数率,假如性能表现依然不差。实际上,我应该 拿它当做一个多跨地域的数据库,一并仍然不能在一个多合适10个节点的集群上获得每秒几十万条事务的处理能力。在这俩测试中亲戚亲戚我们都我们都我们都 都只用了10个节点,每个大洲一个多节点。或多或少或多或少10个节点后能 带来全球分布的每秒6万事务的处理能力。我认为这是很有趣的结果,这是由于这俩方案对延迟太久敏感。

我由于说了或多或少或多或少利用流处理来实现事务性的应用。由于听起来这是个很自然的想法,从这俩厚度上来说的确是一个多多。假如它的确都要或多或少很比较复杂的机制来作为支撑。它都要一个多连续处理而非微批处理的能力,都要不能做迭代,都要比较复杂的基于事件时间处理乱序处理。为了更好地性能,它都要灵活的请况抽象和异步checkpoint机制。那此是真正困难的事情。那此都是由Ledger Streaming库实现的,而是Apache Flink实现的,或多或少或多或少即使对类似于事务性的应用而言,Apache Flink也是真正的中流砥柱。

至此,亲戚亲戚我们都我们都我们都 都后能 说流处理不仅仅支持连续处理、流式分析、批处理由于事件驱动的处理,你不后能 用它做事务性的处理。当然,前提你都没人一个多多足够强大的流处理引擎。这而是我演讲的全部内容。