【Flink】（04）Apache Flink 漫谈系列 —— 实时计算 Flink 与 Alibaba Cloud Realtime Compute 剖析

一、前言

Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态计算。可部署在各种集群环境，对各种大小的数据规模进行快速计算。

阿里云实时计算（Alibaba Cloud Realtime Compute）则是一套基于Apache Flink构建的一站式、高性能实时大数据处理平台，广泛适用于流式数据处理、离线数据处理等场景。

在这里我们对实时计算Flink和Alibaba Cloud Realtime Compute相关的知识点（能力、限制、典型场景，区别）进行分析。

二、什么是Apache Flink

Flink 项目的理念是：“Apache Flink 是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架”。Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。Flink 被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。

我们可以先从Apache Flink的定义、架构、特点和优势等来进行了解。

2.1 Flink Application

首先，我觉得Flink 应用开发需要先理解 Flink 的Streams、State、Time 等基础处理语义以及Flink 兼顾灵活性和方便性的多层次API。

• Streams：流，分为有限数据流与无限数据流，unbounded stream 是有始无终的数据流，即无限数据流；而bounded stream 是限定大小的有始有终的数据集合，即有限数据流，二者的区别在于无限数据流的数据会随时间的推演而持续增加，计算持续进行且不存在结束的状态，相对的有限数据流数据大小固定，计算最终会完成并处于结束的状态。

• State，状态是计算过程中的数据信息，在容错恢复和 Checkpoint 中有重要的作用，流计算在本质上是Incremental Processing（增量处理），因此需要不断查询保持状态；另外，为了确保Exactly- once 语义，需要数据能够写入到状态中；而持久化存储，能够保证在整个分布式系统运行失败或者挂掉的情况下做到Exactly- once，这是状态的另外一个价值。

• Time，分为Event time、Ingestion time、Processing time，Flink 的无限数据流是一个持续的过程，时间是我们判断业务状态是否滞后，数据处理是否及时的重要依据。

• API，API 通常分为三层，由上而下可分为SQL / Table API、DataStream API、ProcessFunction 三层，API 的表达能力及业务抽象能力都非常强大，但越接近SQL 层，表达能力会逐步减弱，抽象能力会增强，反之，ProcessFunction 层API 的表达能力非常强，可以进行多种灵活方便的操作，但抽象能力也相对越小。

2.2 Flink Architecture

在架构部分，主要分为以下四点：

• 第一，Flink 具备统一的框架处理有界和无界两种数据流的能力

• 第二， 部署灵活，Flink 底层支持多种资源调度器，包括Yarn、Kubernetes 等。Flink 自身带的Standalone 的调度器，在部署上也十分灵活。

• 第三， 极高的可伸缩性，可伸缩性对于分布式系统十分重要，阿里巴巴双11大屏采用Flink 处理海量数据，使用过程中测得Flink 峰值可达17 亿/秒。

• 第四， 极致的流式处理性能。Flink 相对于Storm 最大的特点是将状态语义完全抽象到框架中，支持本地状态读取，避免了大量网络IO，可以极大提升状态存取的性能。

2.3 Flink 重要特点

2.3.1 事件驱动型(Event-driven)

事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。比较典型的就是以 kafka 为代表的消息队列几乎都是事件驱动型应用。

与之不同的就是 Spark Streaming 微批次，如图：

事件驱动型：

2.3.2 流与批的世界观

批处理的特点是有界、持久、大量，非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。

流处理的特点是无界、实时, 无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。

在 Spark 的世界观中，一切都是由批次组成的，离线数据是一个大批次，而实时数据是由一个一个无限的小批次组成的。

而在 Flink 的世界观中，一切都是由流组成的，离线数据是有界限的流，实时数据是一个没有界限的流，这就是所谓的有界流和无界流。

无界数据流：无界数据流有一个开始但是没有结束，它们不会在生成时终止并提供数据，必须连续处理无界流，也就是说必须在获取后立即处理 event。对于无界数据流我们无法等待所有数据都到达，因为输入是无界的，并且在任何时间点都不会完成。处理无界数据通常要求以特定顺序（例如事件发生的顺序）获取 event，以便能够推断结果完整性。

有界数据流：有界数据流有明确定义的开始和结束，可以在执行任何计算之前通过获取所有数据来处理有界流，处理有界流不需要有序获取，因为可以始终对有界数据集进行排序，有界流的处理也称为批处理。

这种以流为世界观的架构，获得的最大好处就是具有极低的延迟。

2.3.3 分层API

最底层级的抽象仅仅提供了有状态流，它将通过过程函数（Process Function）被嵌入到 DataStream API 中。底层过程函数（Process Function） 与 DataStream API 相集成，使其可以对某些特定的操作进行底层的抽象，它允许用户可以自由地处理来自一个或多个数据流的事件，并使用一致的容错的状态。除此之外，用户可以注册事件时间并处理时间回调，从而使程序可以处理复杂的计算。

实际上，大多数应用并不需要上述的底层抽象，而是针对核心 API（Core APIs） 进行编程，比如 DataStream API（有界或无界流数据）以及 DataSet API（有界数据集）。这些 API 为数据处理提供了通用的构建模块，比如由用户定义的多种形式的转换（transformations），连接（joins），聚合（aggregations），窗口操作（windows）等等。DataSet API 为有界数据集提供了额外的支持，例如循环与迭代。这些 API处理的数据类型以类（classes）的形式由各自的编程语言所表示。

Table API 是以表为中心的声明式编程，其中表可能会动态变化（在表达流数据时）。Table API 遵循（扩展的）关系模型：表有二维数据结构（schema）（类似于关系数据库中的表），同时 API 提供可比较的操作，例如 select、project、join、group-by、 aggregate 等。Table API 程序声明式地定义了什么逻辑操作应该执行，而不是准确地确定这些操作代码的看上去如何。

尽管 Table API 可以通过多种类型的用户自定义函数（UDF）进行扩展，其仍不如核心 API 更具表达能力，但是使用起来却更加简洁（代码量更少）。除此之外， Table API 程序在执行之前会经过内置优化器进行优化。

你可以在表与 DataStream/DataSet 之间无缝切换，以允许程序将 Table API 与 DataStream 以及 DataSet 混合使用。

Flink 提供的最高层级的抽象是 SQL 。这一层抽象在语法与表达能力上与 Table API 类似，但是是以 SQL 查询表达式的形式表现程序。SQL 抽象与 Table API交互密切，同时 SQL 查询可以直接在 Table API 定义的表上执行。

目前 Flink 作为批处理还不是主流，不如 Spark 成熟，所以 DataSet 使用的并不是很多。Flink Table API 和 Flink SQL 也并不完善，大多都由各大厂商自己定制。实际上 Flink 作为最接近 Google DataFlow模型的实现，是流批统一的观点，所以基本上使用 DataStream 就可以了。

2.4 Flink 应用场景

我有在社区看了很多师兄分享了他们在自己公司里面基于Flink做的一些实践，包括携程、唯品会、饿了么、滴滴、头条等等。他们的应用场景大多包括实时的机器学习，实时的统计分析，实时的异常监测等等，这些实践案例的共同点就是都用来做实时性的任务。

2.4.1 Flink 应用场景：Data Pipeline

Data Pipeline 的核心场景类似于数据搬运并在搬运的过程中进行部分数据清洗或者处理，而整个业务架构图的左边是Periodic ETL，它提供了流式ETL 或者实时ETL，能够订阅消息队列的消息并进行处理，清洗完成后实时写入到下游的Database或File system 中。场景举例：

• 实时数仓

当下游要构建实时数仓时，上游则可能需要实时的Stream ETL。这个过程会进行实时清洗或扩展数据，清洗完成后写入到下游的实时数仓的整个链路中，可保证数据查询的时效性，形成实时数据采集、实时数据处理以及下游的实时Query。

• 搜索引擎推荐

搜索引擎这块以淘宝为例，当卖家上线新商品时，后台会实时产生消息流，该消息流经过Flink 系统时会进行数据的处理、扩展。然后将处理及扩展后的数据生成实时索引，写入到搜索引擎中。这样当淘宝卖家上线新商品时，能在秒级或者分钟级实现搜索引擎的搜索。

2.4.2 Flink 应用场景：Data Analytics

Data Analytics，如图，左边是Batch Analytics，右边是Streaming Analytics。Batch Analytics 就是传统意义上使用类似于Map Reduce、Hive、Spark Batch 等，对作业进行分析、处理、生成离线报表；Streaming Analytics 使用流式分析引擎如Storm、Flink 实时处理分析数据，应用较多的场景如实时大屏、实时报表。

• 移动应用中的用户行为分析
• 消费者技术中的实时数据即席查询

2.4.3 Flink 应用场景：Data Driven

从某种程度上来说，所有的实时的数据处理或者是流式数据处理都是属于Data Driven，流计算本质上是Data Driven 计算。应用较多的如风控系统，当风控系统需要处理各种各样复杂的规则时，Data Driven 就会把处理的规则和逻辑写入到Datastream 的API 或者是ProcessFunction 的API 中，然后将逻辑抽象到整个Flink 引擎，当外面的数据流或者是事件进入就会触发相应的规则，这就是Data Driven 的原理。在触发某些规则后，Data Driven 会进行处理或者是进行预警，这些预警会发到下游产生业务通知，这是Data Driven 的应用场景，Data Driven 在应用上更多应用于复杂事件的处理。

• 实时推荐（例如在客户浏览商家页面的同时进行商品推荐）
• 模式识别或复杂事件处理（例如根据信用卡交易记录进行欺诈识别）
• 异常检测（例如计算机网络入侵检测）

2.5 Flink 优势

Flink 对于有状态流式处理的挑战，主要有以下几点：状态容错、状态维护、Event-time 处理、状态保存与迁移。

2.5.1 状态容错

当我们考虑状态容错时难免会想到精确一次的状态容错，应用在运算时累积的状态，每笔输入的事件反映到状态，更改状态都是精确一次，如果修改超过一次的话也意味着数据引擎产生的结果是不可靠的。

• 如何确保状态拥有精确一次（Exactly-once guarantee）的容错保证？

• 如何在分散式场景下替多个拥有本地状态的运算子产生一个全域一致的快照（Global consistent -snapshot）？

• 更重要的是，如何在不中断运算的前提下产生快照？

2.5.1.1 简单场景的精确一次容错方法

还是以使用者出现次数来看，如果某个使用者出现的次数计算不准确，不是精确一次，那么产生的结果是无法作为参考的。在考虑精确的容错保证前，我们先考虑最简单的使用场景，如无限流的数据进入，后面单一的Process 进行运算，每处理完一笔计算即会累积一次状态，这种情况下如果要确保Process 产生精确一次的状态容错，每处理完一笔数据，更改完状态后进行一次快照，快照包含在队列中并与相应的状态进行对比，完成一致的快照，就能确保精确一次。

2.5.1.2 分布式状态容错

Flink作为分布式的处理引擎，在分布式的场景下，进行多个本地状态的运算，只产生一个全域一致的快照，如需要在不中断运算值的前提下产生全域一致的快照，就涉及到分散式状态容错。

关于Global consistent snapshot，当Operator 在分布式的环境中，在各个节点做运算，首先产生Global consistent snapshot 的方式就是处理每一笔数据的快照点是连续的，这笔运算流过所有的运算值，更改完所有的运算值后，能够看到每一个运算值的状态与该笔运算的位置，即可称为Consistent snapshot，当然，Global consistent snapshot 也是简易场景的延伸。

容错恢复

首先了解一下Checkpoint，上面提到连续性快照每个Operator 运算值本地的状态后端都要维护状态，也就是每次将产生检查点时会将它们传入共享的DFS 中。当任何一个Process 挂掉后，可以直接从三个完整的Checkpoint 将所有的运算值的状态恢复，重新设定到相应位置。Checkpoint的存在使整个Process 能够实现分散式环境中的Exactly-once。

2.5.1.3 分散式快照（Distributed Snapshots）方法

关于Flink 如何在不中断运算的状况下持续产生Global consistent snapshot，其方式是基于用 Simple lamport 演算法机制下延伸的。已知的一个点Checkpoint barrier，Flink 在某个Datastream 中会一直安插Checkpoint barrier，Checkpoint barrier 也会N – 1等等，Checkpoint barrier N 代表着所有在这个范围里面的数据都是Checkpoint barrier N。

举例：假设现在需要产生Checkpoint barrier N，但实际上在Flink 中是由Job manager 触发Checkpoint，Checkpoint 被触发后开始从数据源产生Checkpoint barrier。当Job 开始做Checkpoint barrier N 的时候，可以理解为Checkpoint barrier N 需要逐步填充左下角的表格。

如图，当部分事件标为红色，Checkpoint barrier N 也是红色时，代表着这些数据或事件都由Checkpoint barrier N 负责。Checkpoint barrier N 后面白色部分的数据或事件则不属于Checkpoint barrier N。

在以上的基础上，当数据源收到Checkpoint barrier N 之后会先将自己的状态保存，以读取Kafka资料为例，数据源的状态就是目前它在Kafka 分区的位置，这个状态也会写入到上面提到的表格中。下游的Operator 1 会开始运算属于Checkpoint barrier N 的数据，当Checkpoint barrier N 跟着这些数据流动到Operator 1 之后,Operator 1 也将属于Checkpoint barrier N 的所有数据都反映在状态中，当收到Checkpoint barrier N 时也会直接对Checkpoint去做快照。

当快照完成后继续往下游走，Operator 2 也会接收到所有数据，然后搜索Checkpoint barrier N 的数据并直接反映到状态，当状态收到Checkpoint barrier N 之后也会直接写入到Checkpoint N 中。以上过程到此可以看到Checkpoint barrier N 已经完成了一个完整的表格，这个表格叫做Distributed Snapshots，即分布式快照。分布式快照可以用来做状态容错，任何一个节点挂掉的时候可以在之前的Checkpoint 中将其恢复。继续以上Process，当多个Checkpoint 同时进行，Checkpoint barrier N 已经流到Job manager 2，Flink job manager 可以触发其他的Checkpoint，比如Checkpoint N + 1，Checkpoint N + 2 等等也同步进行，利用这种机制，可以在不阻挡运算的状况下持续地产生Checkpoint。

2.5.2 状态维护（状态后端）

状态维护即用一段代码在本地维护状态值，当状态值非常大时需要本地的状态后端来支持。

如图，在Flink 程序中，可以采用getRuntimeContext().getState(desc); 这组API 去注册状态。Flink 有多种状态后端，采用API 注册状态后，读取状态时都是通过状态后端来读取的。Flink 有两种不同的状态值，也有两种不同的状态后端：

• JVM Heap状态后端，适合数量较小的状态，当状态量不大时就可以采用JVM Heap 的状态后端。JVM Heap 状态后端会在每一次运算值需要读取状态时，用Java object read / writes 进行读或写，不会产生较大代价，但当Checkpoint 需要将每一个运算值的本地状态放入Distributed Snapshots 的时候，就需要进行序列化了。

• RocksDB状态后端，它是一种out of core 的状态后端。在Runtime 的本地状态后端让使用者去读取状态的时候会经过磁盘，相当于将状态维护在磁盘里，与之对应的代价可能就是每次读取状态时，都需要经过序列化和反序列化的过程。当需要进行快照时只将应用序列化即可，序列化后的数据直接传输到中央的共享DFS 中。

Flink目前支持以上两种状态后端，一种是纯 Memory 的状态后端，另一种是有资源磁盘的状态后端，在维护状态时可以根据状态的数量选择相应的状态后端。

2.5.3 Event – Time

2.5.3.1 不同时间种类

在Flink 及其他进阶的流式处理引擎出现之前，大数据处理引擎一直只支持Processing-time 的处理。假设定义一个运算 Windows 的窗口，Windows 运算设定每小时进行结算。Processing-time 进行运算时，可以发现数据引擎将3 点至4 点间收到的数据进行结算。实际上在做报表或者分析结果时是想了解真实世界中3 点至4 点之间实际产生数据的输出结果，了解实际数据的输出结果就必须采用Event – Time 了。

如图，Event – Time 相当于事件，它在数据最源头产生时带有时间戳，后面都需要用时间戳来进行运算。用图来表示，最开始的队列收到数据，每小时对数据划分一个批次，这就是Event – Time Process 在做的事情。

2.5.3.2 Event – Time 处理

Event – Time 是用事件真实产生的时间戳去做Re-bucketing，把对应时间3 点到4 点的数据放在3 点到4 点的Bucket，然后Bucket 产生结果。所以Event – Time 跟Processing – time 的概念是这样对比的存在。

Event – Time 的重要性在于记录引擎输出运算结果的时间。简单来说，流式引擎连续24 小时在运行、搜集资料，假设Pipeline 里有一个 Windows Operator 正在做运算，每小时能产生结果，何时输出 Windows的运算值，这个时间点就是Event – Time 处理的精髓，用来表示该收的数据已经收到。

2.5.3.3 Watermarks

Flink实际上是用 Watermarks 来实现Event – Time 的功能。Watermarks 在Flink 中也属于特殊事件，其精髓在于当某个运算值收到带有时间戳“ T ”的 Watermarks 时就意味着它不会接收到新的数据了。使用Watermarks 的好处在于可以准确预估收到数据的截止时间。举例，假设预期收到数据时间与输出结果时间的时间差延迟5 分钟，那么Flink 中所有的 Windows Operator 搜索3 点至4 点的数据，但因为存在延迟需要再多等5分钟直至收集完4：05 分的数据，此时方能判定4 点钟的资料收集完成了，然后才会产出3 点至4 点的数据结果。这个时间段的结果对应的就是 Watermarks 的部分。

2.5.4 状态保存与迁移

流式处理应用无时无刻不在运行，运维上有几个重要考量：

• 更改应用逻辑/修bug 等，如何将前一执行的状态迁移到新的执行？
• 如何重新定义运行的平行化程度？
• 如何升级运算丛集的版本号？

Checkpoint完美符合以上需求，不过Flink 中还有另外一个名词保存点（Savepoint），当手动产生一个Checkpoint 的时候，就叫做一个Savepoint。Savepoint 跟Checkpoint 的差别在于Checkpoint是Flink 对于一个有状态应用在运行中利用分布式快照持续周期性的产生Checkpoint，而Savepoint 则是手动产生的Checkpoint，Savepoint 记录着流式应用中所有运算元的状态。

如图，Savepoint A 和Savepoint B，无论是变更底层代码逻辑、修bug 或是升级Flink 版本，重新定义应用、计算的平行化程度等，最先需要做的事情就是产生Savepoint。

Savepoint产生的原理是在Checkpoint barrier 流动到所有的Pipeline 中手动插入从而产生分布式快照，这些分布式快照点即Savepoint。Savepoint 可以放在任何位置保存，当完成变更时，可以直接从Savepoint 恢复、执行。

从Savepoint 的恢复执行需要注意，在变更应用的过程中时间在持续，如Kafka 在持续收集资料，当从Savepoint 恢复时，Savepoint 保存着Checkpoint 产生的时间以及Kafka 的相应位置，因此它需要恢复到最新的数据。无论是任何运算，Event – Time 都可以确保产生的结果完全一致。

假设恢复后的重新运算用Process Event – Time，将 Windows 窗口设为1 小时，重新运算能够在10 分钟内将所有的运算结果都包含到单一的 Windows 中。而如果使用Event – Time，则类似于做Bucketing。在Bucketing 的状况下，无论重新运算的数量多大，最终重新运算的时间以及Windows 产生的结果都一定能保证完全一致。

三、什么是阿里云实时计算

实时计算(Alibaba Cloud RealtimeCompute，Powered by Ververica)是阿里云提供的基于 Apache Flink 构建的企业级大数据计算平台。它可以在 PB 级别的数据集上可以支持亚秒级别的处理延时，赋能用户标准实时数据处理流程和行业解决方案；在支持 Datastream API 作业开发的同时，提供了批流统一的 Flink SQL，弥补了社区 SQL 功能缺失，使得 BI 场景下的开发变得更加简单。丰富的上下游 connector 保证了与用户已使用的大数据组 件无缝对接；智能作业调优和诊断功能进一步简化了用户的开发和使用。同时，实时计算在 Apache Flink 核心功能的基础上还增强了企业用户所关注的集群稳定、性能优化、安全控制、系统监 控和作业管理等。

目前阿里云实时计算 Realtime Compute 在各行业丰富的场景中都有应用，得到了金融、物流、广告、IoT等行业一线企业的一致认可。

3.1 产品特点

• 强大的实时处理能力

阿里云实时计算集成诸多全链路功能，方便进行全链路实时计算开发，包括：

• 强大的流计算（实时计算）引擎。
  • 阿里云实时计算提供Flink SQL，支持各类错误场景的自动恢复，保证故障情况下数据处理的准确性。
  • 支持多种内置函数，包括：字符串函数、日期函数和聚合函数等。
  • 精确的计算资源控制，高度保证您的作业的隔离性。
• 关键性能指标为开源Flink的3到4倍。数据计算延迟优化到秒级。单个作业吞吐量可达到百万（记录/秒）级别，单集群规模达到数千台。
• 深度整合各类云数据存储。阿里云实时计算可以直接读写包括数据总线DataHub、日志服务LOG、云数据库RDS版、表格存储TableStore、分析型数据库MySQL版在内的各类数据存储系统，无需进行额外的数据集成工作。

• 托管的实时计算服务

不同于开源或者自建的流式处理服务，阿里云实时计算是完全托管的流式计算引擎。阿里云可以针对流数据运行查询，无需预置或管理任何基础设施。在阿里云实时计算，可以享受一键启用的流式数据服务能力。阿里云实时计算天然集成数据存储、数据开发、数据运维、监控报警等功能，方便以较小成本试用和迁移流式计算。同时，实时计算提供完全租户隔离的托管运行服务。从最上层工作空间，到最底层执行机器，提供高度有效的隔离和全面防护，客户可以放心使用实时计算。

• 低廉的人力和集群成本
大量优化的SQL执行引擎，提供比开源Flink作业更高效且更廉价的计算作业。在开发成本和运行成本方面，阿里云实时计算均要远低于开源流式框架。例如，项目预算时客户需要考虑如下成本：

• 编写一个复杂业务逻辑下Flink作业Java代码的人力成本。
• 针对作业的调试、测试、调优和上线工作成本。
• 后续长期用于Flink或Zookeeper等开源软件的运维成本。

如果使用阿里云实时计算服务，客户可以专注于业务。

3.2 产品定位

目前实时计算适用的应用场景

• 实时的网络点击PV、UV统计。
• 统计交通卡口平均时间段内（例如平均每5分钟）的车流量。
• 水利大坝的压力数据的统计和展现。
• 网络支付中涉及金融盗窃固定行为规则的告警。

目前实时计算无法实现的场景

• Oracle存储过程无法使用实时计算替换。实时计算无法从功能上完全替换掉Oracle存储过程，两者面向问题领域不一致。
• Spark作业无法无缝迁移至实时计算。Spark中涉及实时计算的部分，可以通过改造，完成从Spark至实时计算的迁移。完成迁移后您可以省去运维Spark和开发Spark等工作成本。
• 实时计算无法实现多条复杂规则引擎的告警功能。如果单一数据存在多条复杂规则的告警，在系统运行的同时，告警本身也会发生变化。这类场景建议使用规则引擎系统解决，实时计算主要针对的不是此类问题。

当前实时计算对外接口定义为Flink SQL加UDF。实时计算提供服务于流式数据分析、统计、处理等应用场景的一站式开发工具。面向的用户包括数仓开发人员、数据分析师等。您通过编写Flink SQL，即可完成自身流式数据分析业务，不需要参与底层代码开发。

3.3 基本概念

• 计算集群（ComputeCluster）
  计算集群是承载实时计算产品计算任务的分布式集群系统，基于YARN模式。根据集群的形态不同，实时计算分为独享模式和共享模式。
• 开发界面（WebConsole）
  实时计算提供了一套完整在线IDE开发工具，一站式集成数据存储、数据开发、数据运维和监控报警等功能，辅助您进行业务开发。
• 项目空间（Project）
  项目空间是实时计算最基本的业务组织单元，是您管理集群、作业、资源和人员的基本单元。您可以新建项目，也可以以子账号身份加入其它项目空间。
• 实时计算单元（CU）
  在实时计算中，作业的实时计算单元为CU。1 CU描述了1个实时计算作业最小运行能力，即在限定的CPU、内存和I/O情况下对于事件流处理的最小能力。1个实时计算作业可以指定在1个或者多个CU上运行。当前对实时计算单元（CU）运行能力的定义：1 CU=1 CPU + 4GMEM。其处理能力约为：
  • 简单业务：例如单流过滤、字符串变换等操作，1 CU每秒可以处理10000条数据。
  • 复杂业务：例如JOIN、窗口和GROUP BY等操作，1 CU每秒可以处理1000到5000条数据。

3.4 产品形态

目前有两种产品形态，可以适应不同客户的需求。
底座适配Hadoop(EMR)、K8S(ACK)两大调度体系，可以适配不同技术栈的客户需求。

3.5 应用场景

3.5.1 已有流处理系统迁移

如果本地已安装Flink、Storm或Spark Streaming系统，可以直接迁移到实时计算产品。

3.5.2 按照部门场景划分

可以根据企业部门不同的角度对实时计算进行划分：

• 业务部门：实时风控、实时推荐、搜索引擎的实时索引构建等。
• 数据部门：实时数仓、实时报表、实时大屏等。
• 运维部门：实时监控、实时异常检测和预警、全链路Debug等。

3.5.3 按照技术领域划分

在前面，Flink的使用场景中，我们便做了技术划分，实时计算也是按这三个部分进行划分的。

• 实时ETL和数据流

实时ETL和数据流的目的是实时地把数据从A点投递到B点。在投递的过程中可能添加数据清洗和集成的工作，例如实时构建搜索系统的索引、实时数仓中的ETL过程等。

和Spark的不同之处在于，Flink使用流式处理来模拟批处理，因此实时计算能提供亚秒级、符合Exactly-once语义的实时处理能力，通过构建实时的数据通道，在不同的存储之间搬运和转换数据。

• 实时数据分析

数据分析指的是根据业务目标，从原始数据中抽取对应信息并整合的过程。例如，查看每天销量前10的商品、仓库平均周转时间、文档平均点击率、推送打开率等。实时数据分析则是上述过程的实时化，通常在终端体现为实时报表或实时大屏。

• 事件驱动应用

事件驱动应用是对一系列订阅事件进行处理或作出响应的系统。事件驱动应用通常需要依赖内部状态，例如点击欺诈检测、风控系统、运维异常检测系统等。当用户的行为触发某些风险控制点时，系统会捕获这个事件，并根据用户当前和之前的行为进行分析，决定是否对用户进行风险控制。

3.5.4 场景实践

在电商行业实战场景：

• 利用实时计算获取最新交易记录
• 使用实时计算完成时态势感知和订单地理分布，有助于企业及时的优化产品品类的分配和发布
• 实时计算能够实时的去监控用户的消费金额，在双十一活动中，筛选满足营销红包发放条件的用户
• 使用实时计算制作实时PV和UV曲线图
• 使用实时计算完成数据的实时处理、多类目的管理
• 使用实时计算完成订单与销量的统计

IoT行业实战场景：

工业客户拥有1千多台设备，分布在不同城市的多个厂区，每个设备上有10个不同种类传感器，这些传感器，大概每5秒采集并上传一份数据到日志服务（Log/SLS）。同时，上述传感器分布在多个设备、多个厂区，用户在RDS上记录传感器、设备、厂区的分布维表。

使用阿里云实时计算可以将数据按照一定窗口汇聚，并根据传感器不同维度进行数据筛选，打平为一张宽表，完成多维度传感器数据分析。

视频直播行业实战场景：

• 视频核心指标监控，使用实时计算监控系统稳定性和平台运营情况
• 使用实时计算完成直播数字化运营，包括热门视频、用户走势等等

3.6 使用限制

目前实时计算所支持的服务范围和相应的限制，包括CU处理能力的限制、项目创建的限制。

3.6.1 支持地域

实时计算当前支持的地域

• Flink半托管（基于 ACK）：华南1（深圳）、华北2（北京）、华东2（上海）、华北3（张家口）、华东1（杭州）。
• Blink独享/共享集群（原产品线）：
  独享模式（按量付费）：华东1（杭州）、华北2（北京）、华东2（上海）、华南1（深圳）。
  独享模式（包年包月）：华东1（杭州）、华北2（北京）、华东2（上海）、华南1（深圳）、华北3（张家口）、中国（香港）、新加坡。
  共享模式：华南1（深圳）

3.6.2 CU处理能力

实时计算当前在内部压测场景下，一个CU的处理能力估算如下：

• 简单业务：例如单流过滤、字符串变换等操作，1CU每秒可以处理10000条数据。
• 复杂业务：例如JOIN、窗口、GROUP BY等操作，1CU每秒可以处理1000到5000条数据。

3.6.3 作业、任务数量限制

实时计算对整个项目（Project）下属的作业、Task版本、IDE打开Task页面数量均有不同限制。包括：

• 单个项目下允许最多创建作业的个数为100。
• 单个项目下允许最多的文件夹的个数为50，层级最大不超过5层。
• 单个项目下允许最多的UDX或JAR个数为50。
• 单个项目下允许最多注册数据存储的个数为50。
• 单个作业允许最多的历史保存版本数为20。

四、Flink vs. Blink

4.1 Spark Streaming、Kafka Streams、Storm等存在的问题

在设计一个低延迟、exactly once、流和批统一的，能够支撑足够大体量的复杂计算的引擎时，Spark Streaming 等的劣势就显现出来。Spark Streaming的本质还是一个基于microbatch计算的引擎。这种引擎一个天生的缺点就是每个microbatch的调度开销比较大，当我们要求的延迟越低，额外的开销就越大。这就导致了Spark Streaming实际上不是特别适合于做秒级甚至亚秒级的计算。

Kafka Streams 是从一个日志系统做起来的，它的设计目标是足够轻量，足够简洁易用。这一点很难满足我们对大体量的复杂计算的需求。

Storm是一个没有批处理能力的数据流处理器，除此之外Storm只提供了非常底层的API，用户需要自己实现很多复杂的逻辑。

4.2 Flink的优势

（1）不同于Spark，Flink是一个真正意义上的流计算引擎，和Storm类似，Flink是通过流水线数据传输实现低延迟的流处理；

（2）Flink使用了经典的Chandy-Lamport算法，能够在满足低延迟和低failover开销的基础之上，完美地解决exactly once的目标；

（3）如果用一套引擎来统一流处理和批处理，那就必须以流处理引擎为基础。Flink还提供了SQL/tableAPI这两个API，为批和流在query层的统一又铺平 了道路。因此，Flink是最合适的批和流统一的引擎；

（4）Flink在设计之初就非常在意性能相关的任务状态state和流控等相关技术的设计，这些都使得用Flink执行复杂的大规模任务能时性能更胜一筹。

4.3 Flink和Blink的主要区别

简单地说，Blink就是阿里巴巴开发的基于开源Flink的企业版计算引擎。如前面所说，虽然Flink在理论模型和架构方面有很多创新，但是在工程实现上还有不少问题。

2015年到2016年，阿里巴巴团队主要专注于解决Blink的runtime稳定性和scalability的问题：

（1）优化了集群调度策略使得Blink能够更好更合理地利用集群资源；

（2）优化了checkpoint机制，使得Blink能够很高效地处理拥有很大状态的job；

（3）优化了failover的策略，使得job在异常的时候能够更快恢复，从而对业务延迟造成更少的影响；

（4）设计了异步算子，使得Blink能够在即使被读取外部数据阻塞的同时还能继续处理其他event，从而获得整体非常高的吞吐率。

在拥有了稳定的runtime之后，开始专注于增强Blink的易用性 。所以在2016年底到现在，阿里巴巴团队大力开发Blink实时计算SQL，通过SQL作为统一API服务于各种复杂业务。从规范Streaming SQL的语义和标准，到实现UDX、join、aggregation、window等一系列SQL最重要的算子，几乎一手打造了完整的Streaming SQL，并且将这些工作推回了FLink社区，得到Flink社区的认可。

4.4 流数据的SQL查询存在的难点，以及Blink的解决方案

流计算SQL设计中最大的难点就是Stream SQL的语义和标准。这个事情在Flink和Calcite两个社区一直都在讨论研究中，后来达成共识—世界上不存在Stream SQL。流和批的计算可以自然而然地在传统SQL这一层统一。

流计算所特有的unbounded特性其实本质只是何时观测抽样计算结果，这种属性可以作为一个job的configure来设置而无需去改变用户的业务查询逻辑。为了能够使用传统SQL在流计算上执行，阿里巴巴和Flink社区一起引入了动态表的概。除了动态表之外，阿里巴巴还提出并解决了流计算撤回等其他重要的流计算场景拥有的概念。有了这些语义和功能，使用传统批处理SQL就能写出Blink流式计算的任务，这样就使得使用Blink SQL作为一个支持流处理和批处理的统一的API成为可能。

基于Blink SQL，阿里巴巴打造了新一代阿里巴巴流计算平台streamCompute。现在整个阿里集团包括搜索、推荐、广告等大部分核心流计算业务都是通过streamCompute平台来提供服务。

五、Referece

阿里云实时计算产品文档
https://help.aliyun.com/product/45029.html?spm=5176.13910061.1131226.3.60735f872nXZRJ

阿里云实时计算整体解决方案
https://developer.aliyun.com/article/765097spm=a2c6h.12873639.0.0.383449ffOD9vSk&groupCode=sc

阿里云实时计算产品案例&解决方案汇总
https://developer.aliyun.com/article/691499

Apache Flink 中文社区
https://ververica.cn/

Apache Flink 中文社区B站视频地址
https://space.bilibili.com/33807709?spm_id_from=333.788.b_765f7570696e666f.2

我的Flink学习记录专栏
https://blog.csdn.net/beiisbei/category_9882999.html