阿里云实时计算Flink版_实时大数据处理系统_Flink实时流计算-云巴巴 -云巴巴

阿里云实时计算Flink版

阿里云实时计算Flink版，计算结果要低延时，处理无序、无边界的数据，强一致性，保证业务场景可用，支持时间属性的处理。每次增量计算得到的结果，即是当前的精确结果，随用随取，特别适合流计算场景。每一个处理节点能够保留其本地中间状态和上游输入的所有数据。

立即咨询

服务系统在分析层面的局限 icon

实时获取数据分析见解 icon

批处理和流处理的区别？ icon

什么是实时数据处理？ icon

计算结果要低延时，处理无序、无边界的数据，强一致性，保证业务场景可用，支持时间属性的处理

流计算的三种语义

at-most once语义，实现起来最简单，只要把数据低延时的deliver下去，就可以了。at-least once语义，允许数据重复计算，但不可以丢数据。几乎所有系统都能够做到这一点。exactly once语义，业务通常对数据准确性有严格要求，实现起来最复杂，各种系统的实现也不太相同。

如何开发流计算？

如何描述流式计算的抽象逻辑？

编程API的易用: SQL? DSL? DataStream?

如何使用开发，调试成本更低？

如何更方便的数据对比元数据的管理，上下游任务依赖的管理

处理延迟数据

举个例子，假设定义一个跨度为5分钟的sliding window，触发时间为5s，假设在1小时以后，有一条数据来晚了，是需要assign到1小时以前的某些window中，而之前的window已经完成计算，这条数据该如何处理？如果丢弃掉，那么计算结果的一致性无法保障，如果要计算，那必然要把1小时以前的多个sliding window的数据要保留起来，如何保存？如果跨度是1天呢？

有状态的计算

流计算处理的数据是无边界的，同时要进行低延时的计算和输出，还要保证计算结果的强一致性。如果一个事件的影响取决于它之前发生的所有事件，那么计算一定是有状态的，会涉及到保存明细数据还有聚合操作产生的中间结果。如何高效并且正确的管理这些状态就变得非常重要。依靠状态管理可以完成很多场景：例如时间窗口、统计分析、欺诈检测

无状态的计算

流计算处理的数据是无边界的，如果一个事件不与其他事件有任何关联，那么计算是无状态的

Flink中的状态管理 - Chandy-Lamport icon

Chandy-Lamport algorithm算法是Leslie Lamport和K. Mani Chandy在提出的分布式系统做snapshot算法，该算法解决的是分布式系统，针对全局状态一致对齐的问题做了一些前提假设： 1. 假设在处理节点之间消息传输过程中无异常发生，消息能够被完整且不重复的发送到下游。 2. 两个处理节点的消息通信是单向的并且是保序的且控制消息和数据消息走相同的通道。 3. 该分布式系统中任意两点的网络连接都是畅通的。 4. 该分布式系统中的任务一个处理节点都是发起对全局状态进行snapshot操作。 5. 该算法需要是异步的，对系统的数据处理是无干扰的。 6. 每一个处理节点能够保留其本地中间状态和上游输入的所有数据。

该算法的执行过程: 1. 任意一个节点发起snapshot操作，对状态进行持久化操作，然后将一个"maker"发送到每一个输出通道 2. 下游节点接收到maker后，对其本地状态和上游发送过来的数据进行持久化，并继续把maker发送到下游。 3. 重复2过程，直到所有叶子节点完成本次snapshot操作。

Flink状态管理的注意事项 icon

Flink的状态管理这块，设计的是非常不错的，做到exectly-once的同时，实现原理也是非常简单。针对大规模作业场景，需要在开发中特别注意：1. 在流计算中，每一个处理节点基本上都是多partition输入的，checkpoint机制的引入把一个纯流的计算变成一个有barrier的计算，如果有一个输入partition变慢，其下游的所有计算节点都会被block住，等待checkpoint barrier消息。

2. Flink中，只要有一个task挂掉，所有的计算节点，都要进行一个重新分配，并且把状态全部重新回滚到上一个checkpoint点。这样做系统的开销是很大的，以做流计算的经验来看，在一个大集群中，如果有task频繁的挂掉，非常容易导致整个集群的雪崩。

全量计算与增量计算 icon

全量计算。全量计算起于google的MapReduce，通过“分而治之”的思路，将数据切分成很多小份，将Mapper中对数据进行“归类”，在Reducer对相同“类”的数据进行聚合或其它计算。全量计算的弊端在数据分析计算应用中也是显而易见的，每时每刻数据都在新增或者发生的变化，而进行全量计算产生的结果却一直是固定不变的，直到进行下一次全量计算才会更新。而随时数据的累积变大，全量计算的成本与代价也是越来越高。

只计算新增或变化的小部分数据，并将计算结果与历史计算结果进行"融合"，产生一个新的结果，而不是将所有历史数据全部重新计算，叫做增量计算。如果增量计算的结果与全量计算的结果是一致，但总的计算成本与代价又要远小于全量计算，一个很自然的思路，很多计算场景，数据是实时产生，且计算可增量，增量计算模型是可以替代掉全量计算的。（kappa架构）

如何实现全量计算

对所有商家按销售额做分类统计，销售额在[0,100]区间r的归为一档, [100, 200]区间的的归为一档，以此类推，现通过计算输出每个区间内的商家个数。输入数据为两个column，分别为seller_id和payment：(1, 30), (2, 10), (3, 80), (3, 50)

最终结果为(0-100, 2), (100-200,1)，代表(0-100)这一档的商店数为2，(100-200)这一档的商家为1

如何实现增量计算

1. 增量计算的本质是一个update过程，而不是一个insert过程。在产生计算结果输出的时候，不仅要把新产生的结果输出到下游，还要把之前输出产生的结果，造成的影响撤销掉。类似于将一个update操作转化成一个delete加一个insert操作。2. 对于下游的operater, 不仅要处理insert操作，还要处理delete操作。我们再把这两条应用到上述的增量计算的过程，看看会得到什么样的结果。

回撤流计算的结果如何进行更新？ icon

如上图所示，对wordcount计算后的结果按奇偶进行分桶：当第一个a完成计算，count(a)=1,所以，会把奇数桶的值改成1。当第二个a完成计算，count(a)=2,所以，会把偶数桶的值改成2。那么问题来了，这个a又不是薛定谔的猫，目前只应该存在于偶数桶中，那么奇数桶应该变成0，怎么把奇数桶变成0呢？

增量计算+回撤

增量计算总结

增量计算的优势： 1. 每次增量计算得到的结果，即是当前的精确结果，随用随取，特别适合流计算场景。 2. 与迭代计算与增量算法结合，做增量的模型训练。 3. 每次增量计算量均不大，能够把计算资源拉平，削峰填谷，能够缓解全量计。算集中使用资源的问题

增量计算的注意事项： 1. 为了能够进行增量计算，需要存储额外的状态。 2. 增量计算会产生update消息，相比全量计算来说，总的计算量会大一些。 3. 有些算法不太适合做增量，或者做增量的资源消耗会非常大，一般需要对算法进行调整，典型的像count(distinct)。传统的ETL业务逻辑往往选择在凌晨跑任务，所以在全量计算中，在这段时间内资源使用量相当大，而使用增量计算模型，能够将全天集中式的资源使用削峰填谷，拉平到全天。

数据流与增量表

增量计算处理的是数据流Stream，数据库处理的表Table。Stream其实是Table的changeLog, 而Table是stream进行增量计算的结果

时间类型

事件时间，即事件实际发生的时间。

处理时间，即在系统中观察到事件的时间。

事件时间和处理时间之间的映射不是静态的。

如果您关心数据的事件时间（即事件实际发生的时间），则不能仅在管道中观察到数据的上下文中分析数据。

为了应对无界数据集的无限性质，这些系统通常提供一些对传入数据进行窗口化的概念。

处理时间和事件时间的区别 icon

不感知时间计算

时间无关的处理，即所有相关逻辑都是数据驱动的。只需要关注到达的数据即可，因此除了基本数据传输之外，流引擎实际上没有什么特别需要支持的。

Filter

时间不可知处理的一种非常基本的形式是过滤。假设处理Web 流量日志，过滤掉并非来自特定域的所有流量。判断该日志是否命中规则，如果未命中则将其删除。由于这种事情在任何时候都只依赖于单个元素，因此数据源的时间属性并不会对数据本身产生影响。

Join

另一个与时间无关的示例是join。Join两个无界数据源时，只关心来自两个源的元素到达时连接的结果，则逻辑中没有时间元素。可以简单地将流缓存在内存中。当另一个流到达时，只需要关注是否在其中包含相同元素（实际操作中，通常会对其配置TTL，以保证buffer数据不会无限增大）

窗口感知时间的计算 icon

由于处理时间和事件时间之间并没有绝对的关系，某些数据最终会出现在错误的处理时间窗口中（可能来自分布式系统的时间滞后、网络延迟等等）从而导致处理时间不可信。当按事件时间进行窗口化时，可以保证计算的一致性，但是会引入新问题。在无界数据处理中，消息不保序和消息丢失会影响事件时间窗口的完整性：如何确定已经获得了事件时间 X 之前的所有数据？很多情况下完全无法保证。当今数据处理系统都依赖于某种机制，从而达到某种完整性概念。

窗口类型

处理无界数据的最常见方法是将输入数据窗口化到固定大小的窗口中。每一个窗口作为单独的有界数据源进行处理。

• 固定窗口：固定窗口将时间分成具有固定大小时间长度的段。

• 滑动窗口：滑动窗口由固定长度和固定周期定义。如果周期小于长度，则窗口重叠。如果周期等于长度，则退化成固定窗口。如果周期大于长度，则会有一种奇怪的采样窗口，会发生数据丢失。与固定窗口一样，滑动窗口通常是对齐的。

• 会话窗口：动态窗口的一个示例，Session由一系列事件组成，当一段时间内没收到新的消息时，认为Session已经结束可以出发窗口。Session窗口的长度不能预先定义，完全取决于实际数据的情况。它们也是未对齐窗口的典型示例， Session窗口的长度在不同数据集之间实际上永远不会相同。

ProcessTime开窗 icon

简单、适合定性估计、适合做预估

• 很简单。实现非常简单。只需在数据到达时暂时缓冲，并在窗口关闭时触发计算，将结果输出到下游

• 判断窗口完整性很简单。系统默认窗口的所有输入都已经到达，窗口不关心内部数据完整性。这意味着在按ProcessTime进行窗口化时，无需以任何方式处理“迟到”数据。

• 适用于推断源的信息，许多监控场景都属于这一类。比如跟踪每分钟Web 服务的请求数。

ProcessTime可以很好的检测web请求数，同时监控服务是否发生中断。因为并不需要保证所有相关日志全部到达没，也不需要关注乱序。

EventTime开窗 icon

最重要的问题是如何确定，窗口内的数据都已经到达呢？图中的白色实线表示两个Demo数据。这两个数据都到达与它们所属的EventTime窗口不匹配的ProcessTime窗口。因此，如果这些数据已被窗口化到关心事件时间的用例的处理时间窗口中，则计算结果将是不正确的。EventTime的正确性是使用EventTime时间窗口的主要诉求。

如何保证数据全部到达，并且有效的处理呢？Buffer：由于窗口时间延长，需要更多的数据buffer。存储通常是大数据处理系统中最便宜的。此外，许多聚合不需要缓冲整个输入集（例如，sum和avg等）。完整性：事实上，很多情况下做不到。许多情况下（大多数大数据系统）给出一个相当准确的窗口完成的启发式估计。但如果正确性至关重要的情况下（如计量计费），大多数系统将窗口的扩展性交给用户，让用户可以自定义窗口触发的逻辑，从而满足特定场景下的精准计算需求。

产品推荐

捷为iTimes智能工时管理系统

捷为iTimes智能工时管理系统，作为A!时代企业数字化转型的数据基石，致力于将无形的工时投入，转化为可精确衡量、可精准追溯的数字资产。iTimes通过可视化、精细化、数字化、智能化的工时全流程管理，不仅管理时间，更可洞察价值--精确核算项目成本、精准评估人力效能、清晰追湖研发投入，为企业的精益运营、管理合规、战略决策和可持续发展提供坚实的数据支撑。

免费试用

查看详情