您的位置: 首页  >  文章  >  Flink初步了解

Flink初步了解

分类: 文章 • 2024-02-08 12:22:10

Flink初步了解

废话少说----

1 基本框架

Flink初步了解

2 Flink简介

2.1 Fink是什么

Apache Flink 是一个面向分布式数据流处理和批量数据处理的开源计算平台，提供支持流处理和批处理两种类型应用的功能。

2.2 Flink的来历

Apache Flink的前身是柏林理工大学一个研究性项目，在2014被Apache孵化器所接受，然后迅速地成为了Apache Software Foundation的*项目之一。

2.3 Flink的特点

2.3.1 流处理特性

现有的开源计算方案，会把流处理和批处理作为两种不同的应用类型：流处理一般需要支持低延迟、Exactly-once保证，而批处理需要支持高吞吐、高效处理
Flink是完全支持流处理，也就是说作为流处理看待时输入数据流时*的；批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的。
1.支持高吞吐、低延迟、高性能的流处理
2.支持带有事件时间的窗口（Window）操作
3.支持有状态计算的Exactly-once语义
4.支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作
5.支持具有Backpressure功能的持续流模型
6.支持基于轻量级分布式快照（Snapshot）实现的容错
7.一个运行时同时支持Batch on Streaming处理和Streaming处理
8.Flink在JVM内部实现了自己的内存管理
9.支持迭代计算
10.支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存

2.3.2 API支持

1.支持高吞吐、低延迟、高性能的流处理
2.支持带有事件时间的窗口（Window）操作
3.支持有状态计算的Exactly-once语义
4.支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作
5.支持具有Backpressure功能的持续流模型
6.支持基于轻量级分布式快照（Snapshot）实现的容错
7.一个运行时同时支持Batch on Streaming处理和Streaming处理
8.Flink在JVM内部实现了自己的内存管理
9.支持迭代计算
10.支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存

2.3.3 Libraries支持

1.支持机器学习（FlinkML）
2.支持图分析（Gelly）
3.支持关系数据处理（Table）
4.支持复杂事件处理（CEP）

2.3.4 整合支持

1.支持Flink on YARN
2.支持HDFS
3.支持来自Kafka的输入数据
4.支持Apache HBase
5.支持Hadoop程序
6.支持Tachyon
7.支持ElasticSearch
8.支持RabbitMQ
9.支持Apache Storm
10.支持S3
11.支持XtreemFS

2.3.5 Flink生态圈

Flink 首先支持了 Scala 和 Java 的 API，Python 也正在测试中。Flink 通过 Gelly 支持了图操作，还有机器学习的 FlinkML。Table 是一种接口化的 SQL 支持，也就是 API 支持，而不是文本化的 SQL 解析和执行。对于完整的 Stack 我们可以参考下图。
Flink初步了解
Flink 为了更广泛的支持大数据的生态圈，其下也实现了很多 Connector 的子项目。最熟悉的，当然就是与 Hadoop HDFS 集成。其次，Flink 也宣布支持了 Tachyon、S3 以及 MapRFS。不过对于 Tachyon 以及 S3 的支持，都是通过 Hadoop HDFS 这层包装实现的，也就是说要使用 Tachyon 和 S3，就必须有 Hadoop，而且要更改 Hadoop 的配置（core-site.xml）。如果浏览 Flink 的代码目录，我们就会看到更多 Connector 项目，例如 Flume 和 Kafka。

3 Flink组件栈

3.1 Deployment层

主要涉及了Flink的部署模式、Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2）.

3.2 Runtime层

Runtime层提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、JobGraph到ExecutionGraph的映射、调度等等，为上层API层提供基础服务

3.3 Libaries层

API层主要实现了面向*Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API

3.4 API层

在API层之上构建的满足特定应用的实现计算框架，也分别对应于面向流处理和面向批处理两类。
居中的图片;

4 Flink自身优势

1.支持高吞吐、低延迟、高性能的流处理
2.支持高度灵活的窗口（Window）操作
3.支持有状态计算的Exactly-once语义
4.提供DataStream API和DataSet API

5 Flink分布式环境运行

5.1 JobManager

1.Flink系统的协调者，他负责接受Flink Job ，调度组成Job的多个Task的执行
2.收集Job的状态信息，并管理Flink集群中从节点TaskManager

5.2 TaskManager

1.实际负责执行计算的Worder，在其上执行Flink Job的一组Task
2.TaskManager负责管理其所在节点上的资源信息，如内存、磁盘、网络，在启动的时候将资源的状态向JobManager汇报

5.3 Client

1.用户提交一个Flink程序时，会首先创建一个Client，该Client首先会对用户提交的Flink程序进行预处理，并提交到Flink集群
2.Client会将用户提交的Flink程序组装一个JobGraph，并且时以JobGraph的形式提交的

6 Flink下载安装

6.1 MethodOne

git clone https://github.com/apache/fli…
cd flink
mav clean package -DskipTests
cd build-target

6.2 MethodTwo

到官网下载编译版：https://flink.apache.org/down…
不同环境下到bin目录，运行start-local.bat
运行正常，访问页面：http://localhost:8081

7 Flink入门程序

下一篇说明源码的使用
需要下载的话自己从Github下载

8 实时技术对比。

Apache Flink相比于Apache Spark，目前Spark的生态总体更为完善一些，且在机器学习的集成和应用性暂时领先。但作为下一代大数据引擎的有力竞争者-Flink在流式计算上有明显优势，Flink在流式计算里属于真正意义上的单条处理，每一条数据都触发计算，而不是像Spark一样的Mini Batch作为流式处理的妥协。Flink的容错机制较为轻量，对吞吐量影响较小，而且拥有图和调度上的一些优化，使得Flink可以达到很高的吞吐量。而Strom的容错机制需要对每条数据进行ack，因此其吞吐量瓶颈也是备受诟病
鉴于如上3个通用的实时计算技术的比较，AbutionGraph选用了具有竞争力的下一代大数据技术Flink作为实时数据接入源，同时也是国内首个使用Flink作为数据源的图数据库，且为此实现了一些常用的消息组件接口：Kafka-2.0、Kafka-0.10、RocketMQ、ActiveMQ、Socket等，使用Flink作为与AbutionGraph的实时数据接入时，您可以不关注数据源有多少种，它支持任意多的不同消息组件同时对已有图形增量更新。
鉴于Spark在离线批量计算、分布式机器学习的“王者”地位，技术生态也非常的完善。AbutionGraph顺其自然的将Spark作为离线计算（OLAP）平台，可将图形数据轻易的转变为Spark DataFrame/GraphFrame，反之，也可以将Spark DataFrame直接转换到AbutionGraph的图形中，这种数据源有别于Flink-即如上所说这是大批量的数据入库。此外，AbutionGraph还基于Spark构建了一个世界最丰富的分布式图挖掘算法库-AbutionGCS，它目前包含13大类60余种图算法。

9 既往平台问题

AbutionGraph之所以要实现大规模准实时图形数据分析平台，是因为以往的图形数据存储平台大多数都为离线式系统，少量的实时系统也存在一些问题。比如：
较高的延迟，导入数据无法满足准实时查询的要求；
流式数据导入性能不足，无法支撑大规模的在线数据实时摄入，IO出现瓶颈；
批量导入数据前需要将原始数据依据Schema规整为gson/gxml等指定文件格式，数据ETL大多是高延迟且多日多步的；
此外，以往平台支持的数据源较为单一，无法多源数据同时入库。

10 现有案例

10.1 场景一：Event-driven Applications【事件驱动】

Flink初步了解

上图包含两块：Traditional transaction Application（传统事务应用）和Event-driven Applications（事件驱动应用）。
Traditional transaction Application执行流程：比如点击流Events可以通过Application写入Transaction DB（数据库），同时也可以通过Application从Transaction DB将数据读出，并进行处理，当处理结果达到一个预警值就会触发一个Action动作，这种方式一般为事后诸葛亮。
Event-driven Applications执行流程：比如采集的数据Events可以不断的放入消息队列，Flink应用会不断ingest（消费）消息队列中的数据，Flink 应用内部维护着一段时间的数据（state），隔一段时间会将数据持久化存储（Persistent sstorage），防止Flink应用死掉。Flink应用每接受一条数据，就会处理一条数据，处理之后就会触发（trigger）一个动作（Action），同时也可以将处理结果写入外部消息队列中，其他Flink应用再消费。
典型的事件驱动类应用：
1.欺诈检测(Fraud detection)
2.异常检测(Anomaly detection)
3.基于规则的告警(Rule-based alerting)
4.业务流程监控(Business process monitoring)
5.Web应用程序(社交网络)

10.2 场景二：Data Analytics Applications【分析】

Flink初步了解

Data Analytics Applications包含Batch analytics（批处理分析）和Streaming analytics（流处理分析）。
Batch analytics可以理解为周期性查询：比如Flink应用凌晨从Recorded Events中读取昨天的数据，然后做周期查询运算，最后将数据写入Database或者HDFS，或者直接将数据生成报表供公司上层领导决策使用。
Streaming analytics可以理解为连续性查询：比如实时展示双十一天猫销售GMV，用户下单数据需要实时写入消息队列，Flink 应用源源不断读取数据做实时计算，然后不断的将数据更新至Database或者K-VStore，最后做大屏实时展示

10.3 场景三：Data Pipeline Applications【管道式ETL】

Flink初步了解

11 现有案例

11.1 阿里巴巴

11.1.1 实时监控

  1. 用户行为预警、app crash 预警、服务器攻击预警
  2. 对用户行为或者相关事件进行实时监测和分析，基于风控规则进行预警

11.1.2 实时报表

  1. 双11、双12等活动直播大屏
  2. 对外数据产品：生意参谋等
  3. 数据化运营

11.1.3 流数据分析

  1. 实时计算相关指标反馈及时调整决策
  2. 内容投放、无线智能推送、实时个性化推荐等

11.1.4 实时仓库

  1. 数据实时清洗、归并、结构化
  2. 数仓的补充和优化

11.2 滴滴出行

1、轨迹数据：轨迹数据和订单数据往往是业务方特别关心的。同时因为每一个用户在打车以后，都必须要实时的看到自己的轨迹，所以这些数据有强烈的实时需求。
2、交易数据：滴滴的交易数据，
3、埋点数据：滴滴各个业务方的埋点数据，包括终端以及后端的所有业务数据，
4、日志数据：整个的日志系统都有一些特别强烈的实时需求。

相关推荐