（二）：Flink概述，Flink如何支持批流处理，程序流程

最新推荐文章于 2024-10-05 03:17:53 发布

haixwang

最新推荐文章于 2024-10-05 03:17:53 发布

阅读量4.5k

点赞数 3

分类专栏： Flink 类比出发学习Flink

本文链接：https://blog.csdn.net/HaixWang/article/details/82827377

版权

Flink 同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

类比出发学习Flink

6 篇文章 2 订阅

订阅专栏

文章目录

前言

以下都尽量对比Spark（或者大数据生态的其他技术）进行理解。

Flink简介，Flink能做什么

Flink简介

Flink最初是一个名为Stratosphere的研究项目，目标是为柏林地区的一些大学建立下一代大数据分析平台。它于2014年4月16日成为Apache孵化器项目。Stratosphere的初始版本基于Nephele的研究论文http://stratosphere.eu/assets/papers/Nephele_09.pdf

Flink最重要的功能，即Flink的流API，是Flink 0.7才引入的。最开始只有Java API，后来的版本也开始支持Scala API。

下图为Stratosphere的演变：
在这里插入图片描述

当下1.x版本的架构为：
在这里插入图片描述

Flink能做什么

支持批处理
交互式处理
实时流数据处理
支持用SQL分析
支持机器学习
数据处理后的托管状态（managed state）
以及仅一次交付（exactly-once）保证

补充：
Atmost-once（在发生故障时可能无法处理）
Atleast-once（即使在出现故障时也至少会被处理一次）
Exactly-once（将被处理一次且恰好一次即使出现故障）

（下图的特性是不完整的）
在这里插入图片描述

所以，这样看来，Flink的目标，和Spark是差不多的。
在这里插入图片描述
一些异同举例：

虽然目标差不多，都想“一统江湖”，但是Flink的生态，还不太完善，还在慢慢的建立
Flink实时处理是其优势，基于此的机器学习，也是优势，虽然也不够完善
托管状态（managed state）是Flink的优势。【尽量将每个Task的历史状态保存在内存中。】
【在流处理中，有些操作仅仅在某一时间针对单一事件（如事件转换map），有些操作需要记住多个事件的信息并进行处理（window operators），受到其他信息的处理结果的影响。后者的这些操作称为有状态的操作。】
准实时处理（微处理）以及较为完善的生态，依然是Spark的大优势。
Flink 与 Spark Streaming都保证 仅一次交付（exactly-once）。【Flink通过定期的异步checkpointing本地状态保存到持久层来保证在出现故障时的exactly-once】

Flink guarantees exactly-once state consistency in case of failures by periodically and asynchronously checkpointing the local state to durable storage.

在 Flink 中，DataSet APi（批）和 DataStream API（流）是同一个公用引擎之上的两个独立的抽象。所以，这两者的行为目前无法合并在一起操作，目前官方正在处理这种问题，详见［FLINK-2320］；但是Spark就不同，DStream以及DataSet（DataFrame[T]）都是封装在RDD之上的，所以可以交互。
计算操作都是懒加载。

下图的红色框，现在看来，可能不太严谨了。（TODO:Flink纯自动化内存管理？连基本的配置都不需要？就因为其是自己控制内存，而spark基于JVM控制内存，就把它们分为configured和automatic？）

1.6开始，spark推出UnifiedMemoryManager开始朝自动化内存管理发展
Spark 内存管理以及内存消耗估算可参考该官方说明
Spark 统一内存管理可参考：Apache Spark 统一内存管理模型详解

Filink也支持三大部署模式：Local、Cluster（Standalone，Yarn，messos）以及Cloud
在这里插入图片描述

选择微批处理还是实时处理

YouTube: Mohanam的例举

第一个用例是金融：信用卡欺诈检测与欺诈预防有些不同。检测是在微批或实时流上发生的事情，而欺诈预防必须实时发生。想象一下，用户正在进行交易，您希望系统查看是欺诈性交易还是有效交易。
比如有两个广告科技行业的场景：一个是聚合来自不同IP地址的不同IP请求，将IP归入黑名单或白名单；另一个是设法阻止一个黑名单IP的特定请求。前者使用微批处理就可以，而后者就需要实时流处理。再比如，在电信行业，统计特定用户使用的带宽，微批处理可能是一个更高效的方案，而网络异常检测就需要实时流处理了。也有一些场景，微批处理和实时流处理都适用，如在IoT行业查看特定工业设备的使用情况。
视频中还对IOT以及电信行业进行了例举。对应博客

计算流程（组件）

这里只是简单的类比下：

在Spark中，我们知道，是RDD/dstream + transform算子 + action算子
而在Flume中，是source、channel、sink
Kafka中，是produce 、存储(或者不存储）、consume
Hadoop中，map、落磁盘(也可以不落磁盘）、reduce
Storm中，是图状结构(拓扑）：spout、bolt
Hive：HiveSQL ->AST(抽象语法树：完成SQL词法，语法解析，将SQL转化为抽象语法树AST Tree；) -> QB(查询块) ->OperatorTree（操作树）->优化后的操作树->mapreduce任务树->优化后的mapreduce任务树
这里的Flink，是source、transformation、sink

Flink如何支持批流处理

理解Flink如何流式实时处理数据，如果不是深入细节去理解，还是很好理解，泛泛而谈，就是来一条处理一条，但是具体是怎样的，还需要以后深入学习才知道。
比如说：

哪条消息发送往哪台机器去计算，是怎样决定的？
处理某条消息如果牵扯到之前的消息处理的状态，那么之前的消息相关的，是怎样传输到其他节点的？
等等

这里先理解下Flink如何进行批处理：

首先，Flink 把批处理看成 Stream 的特殊例子（也就是批处理建立在流式基础之上，Spark Streaming可以理解为是相反的），具体到架构图可知道：

面向流处理对应DataStream API，面向批处理对应DataSet API。
官网讲解的Dataset都是从文件获取数据，我想知道的是：Flink是如何将流式数据批量对待的（因为Flink将批作为流的特例，有文章说——Flink中有一个时间参数，控制缓存多少的数据之后再进行处理。但我迟迟没有找到证据）。
先放着，TODO

程序开发步骤

DataStream和DataSet API是程序员调用的接口。编译程序时，这些API会生成JobGraphs。编译后，DataSet API允许优化器生成最佳执行计划，而DataStream API使用流构建的方式来实现高效的执行计划。然后根据部署模型将优化的JobGraph提交给执行程序。

与Spark“套路”差不多：

获取上下文执行环境
ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();

【Spark中是
SparkContext / SparkSession / StreamingContext 或者
JavaSparkContext / JavaSparkStreaming
】

加载数据，比如：
env.readTextFile等

【spark：

spark.read.jdbc
spark.read.json
spark.read.orc
spark.read.parquet
spark.read.textFile

】

Transformations 算子，比如：

data.flatMap(new FlatMapFunction<String, String>() {
  public void flatMap(String value, Collector<String> out) {
    for (String s : value.split(" ")) {
      out.collect(s);
    }
  }
});