大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构

本文主要是介绍大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

  • Hadoop(已更完)
  • HDFS(已更完)
  • MapReduce(已更完)
  • Hive(已更完)
  • Flume(已更完)
  • Sqoop(已更完)
  • Zookeeper(已更完)
  • HBase(已更完)
  • Redis (已更完)
  • Kafka(已更完)
  • Spark(已更完)
  • Flink(正在更新!)

终于到了Flink!

章节内容

上节完成了如下的内容:

  • Spark GraphX 注意事项
  • Spark GraphX 开发过程
  • Spark GraphX 案例

请添加图片描述

官方网站

https://flink.apache.org/

什么是Flink

Apache Flink 是一个框架和分布式处理引擎,用于对无界和有界数据流进行有状态计算,Flink被设计在所有常见的集群环境中运行,以内存执行速度和任意规模来执行计算。

  • Flink起源于2008年柏林大学的研究性项目 Stratosphere
  • 2014年该项目被捐赠给了Apache软件基金会
  • Flink一跃成为Apache软件基金会的顶级项目之一

在德语中,Flink一次表示快速和灵巧,项目采用一只松鼠的彩色图案作为LOGO,这不仅仅是因为松鼠具有快速和灵巧的特点,还因为柏林的松鼠有一种迷人的红棕色,而Flink的松鼠LOGO拥有可爱的尾巴,尾巴的颜色和Apache软件基金会的LOGO颜色相呼应,也就是说,这是一只Apache风格的松鼠。

Flink特点

Flink是一个开源的批处理框架,它具有以下特点:

  • 批流一体:统一批处理、流处理
  • 分布式:Flink程序可以运行在多个服务器上
  • 高性能:处理性能比较高
  • 高可用:Flink支持高可用性(HA)
  • 准确:Flink可以保证数据处理的准确性

Flink场景

Flink主要用于流式数据分析场景,数据无处不在,绝大多数的企业采取的处理数据的框架都会划分为两类:

  • 事务型处理
  • 分析性处理

事务型处理

  • OLTP:On-Line Transaction Processing 联机事务处理过程
    流程审批、数据录入、填报等
    特点:线下工作线上化,数据保存在各自的系统中,互不相通(数据孤岛)

OLTP联机事务处理系统以事务元作为数据处理的单位、人机交互的计算机应用系统。它能对数据进行即时更新或其他操作,系统内的数据总是保持在最新状态。
用户可以将一组保持数据一致性的操作序列指定为一个事务元,通过终端、个人计算机或其他设备输入事务元,经系统处理后返回结果。

OLTP主要用于记录某类业务事件的发生,如购买行为,当行为产生后,系统会记录是谁在何时何地做何事,这样的一行或者多行数据会以增删改查的方式在数据库中进行数据的更新处理操作,要求实时性高、稳定性强、确保数据及时更新成功。

应用主要在:

  • 飞机订票
  • 股票交易
  • 超市销售
  • 饭店前后台管理等等

常见的:ERP、CRM、OA等系统都属于 OLTP 系统。
在这里插入图片描述

在这个期间,每处理一条事件,应用都会通过执行远程数据库系统的事务来读取或更新状态。很多时候,多个应用会共享同一个数据库系统,有时候还会访问相同的数据库或表。
该设计在应用需要更新或数据库扩容或表模式修改时会容易导致问题。

分析型处理

当数据积累到一定的程度,我们需要对过去发生的事情做一个总结分析时,就需要把过去一段时间内产生的数据拿出来进行统计分析,从中获取我们想要的信息,为公司做决策提供支持,这时候就是在做OLAP了。
因为OLTP所产生的业务数据分散在不同的业务系统中,而OLAP往往需要将不同的业务数据集中到一起进行统一综合的分析,这时候就需要根据业务分析需求做对应的数据清洗后存储在数据仓库中,然后由数据仓库来统一提供OLAP分析
OLAP On-Line Analytical Processing:联机分析系统:

  • 分析报表
  • 分析决策
  • 等等

根据业务分析需求做对应的数据清洗后存储在数据仓库中称为ETL(Extract-Transform-Load):从事务型数据中提取数据,将其转换为通用的表示形式(可能包含数据验证、数据归一化、编码、去重、表模式转换等工作),最终加载到分析型数据库中。

在这里插入图片描述
如上图所示,数据实时写入HBase,实时的数据更新也在HBase完成,为了应对OLAP需求,我们定时(通常T+1或者T+H)将HBase数据写成静态的文件(如:Perquet)导入到OLAP引擎(如:HDFS,比较常见的是Impala操作Hive),这一架构能满足既需要随机读写,又可以支持OLAP分析的场景,但他有如下缺点:

  • 架构复杂,从架构上看,数据在HBase、消息队列、HDFS间流转,涉及环节太多,运维成本很高。并且每个环节需要保证高可用,都需要维护多个副本,存储空间也有一定的浪费,最后数据在多个系统上,对数据安全策略,监控都提出了挑战。
  • 时效低,数据从HBase导出成静态文件是周期性的,一般这个周期是一天(或一小时),在时效性上不是很高。
  • 难以应对后续的更新,真实场景中,总会有数据【延迟】到达的,如果这些数据之前已经从HBase导出到HDFS,新到的变更数据就难以处理了,一个方案是把原有数据应用上新的变更后重写一遍,但这代价又很高。

通常数据仓库中的查询可以分为两类:

  • 普通查询:是定制的
  • 即系查询:是用户自定义查询条件的

在这里插入图片描述

  • 实时ETL:集成流计算现有的诸多数据通道和SQL灵活的加工能力,对流式数据进行实时清洗,归并和结构化处理,同时,对离线数仓进行有效的补充和优化,并为数据实时传输提供可计算通道
  • 实时报表:实时化采集、加工流式数据存储,实时监控和展现业务,客户各类指标,让数据化运营实时化。如通过分析订单处理系统中的数据获知销售增长率。通过分析运输延迟原因或预测销售量调整库存。
  • 监控预警:对系统和用户行为进行实时监测和分析,以便及时发现危险行为,如果计算机网络入侵、诈骗预警等
  • 在线系统:实时计算各类数据指标,并利用实时结果及时调整在线系统的相关策略,在各类内容投放、智能推送领域有大量的应用,如在客户浏览商品的同时推荐相关的商品

Flink 核心组成

在这里插入图片描述

Deploy层

  • 可以启动单个JVM,让Flink以Local模式运行
  • Flink也可以以Standalone集群模式运行,同时支持FlinkOnYRAN,Flink应用直接提交到YRAN上面运行
  • Flink还可以运行在谷歌云服务和亚马逊云服务

Core层

在Runtime之上提供了两套核心的API

  • DataStreamAPI(流处理)
  • DataSet API(批处理)

APIs & Libraries 层

核心API上又扩展了一些高阶的库和API

  • CEP流处理
  • Table API 和 SQL
  • Flink ML机器学习库
  • Celly 图计算

Flink 生态发展

在这里插入图片描述

  • 中间部分主要内容在Flink核心组成中已经提到
  • 输入 Connectors (左侧部分):1.流式处理中包含Kafka(消息队列)、AWS Kinesis(实时数据流服务)、RabbitMQ(消息队列)、NIFI(数据管道)、Cassandra(NoSQL数据库)、Elasticsearch(全文检索)、HDFS(滚动文件)2.批处理方式:包含HBase(分布式列式数据库)、HDFS(分布式文件系统)

Flink处理模型

Flink 流处理与批处理,Flink专注于无限流处理,有限流处理是无限流处理的一种特殊情况。

无限流处理

  • 输入的数据没有尽头,像水流一样源源不断
  • 数据处理从当前或者过去的某一个时间点开始,持续不停地进行

有限流处理

  • 从某一个时间点开始处理数据,然后在另一个时间点结束
  • 输入数据可能本身是有限的(即输入数据集并不会随着时间的增长),也可能出于分析的目的被人为设定为有限集(即只分析某一个时间段内的事件)

Flink封装了DataStreamAPI进行流处理,封装了DataSetAPI进行批处理。同时,Flink是一个批流一体的处理引擎,提供了TableAPI/SQL统一批处理和流处理。

在这里插入图片描述

流处理引擎的技术选型

市面上的流处理引擎不止Flink一种,其他的Storm、SparkStreaming、Trident等,实际应用如何进行选型,给大家一些建议参考:

  • 流数据要进行状态管理,选择使用 Trident、SparkStreaming或者Flink
  • 消息投递需要保证At-least-once(至少一次)或者 Exactly-once(仅一次)不能选择Storm
  • 对于小型独立项目,有低延迟要求,可以选择使用Storm,更简单
  • 如果项目已引入大框架Spark,实时处理需求可以满足的话,建议直接使用Spark中的SparkStreaming
  • 消息投递要满足Exactly-once (仅一次),数据量大、有高吞吐、低延迟要求、要进行状态管理或者窗口统计,建议使用Flink

架构组件

JobManager(作业管理器)

JobManager 是 Flink 集群的核心控制组件,负责整个数据流处理作业的生命周期管理。它的主要职责包括:

  • 任务调度:JobManager 负责将用户提交的作业划分为多个任务,并调度这些任务到不同的 TaskManager 执行。
  • 资源管理:它与资源管理系统(如 YARN 或 Kubernetes)进行交互,以分配和管理作业执行所需的资源。
  • 故障恢复:当作业中的某个任务失败时,JobManager 负责重新调度该任务并从故障点恢复执行,以确保作业的持续进行。
  • 协调点(Checkpointing):JobManager 负责协调 Flink 的容错机制,通过管理 Checkpointing 来保证作业的状态一致性。

TaskManager(任务管理器)

TaskManager 是 Flink 集群中的工作节点,负责执行由 JobManager 分配的具体任务。它的职责包括:

  • 任务执行:TaskManager 接受 JobManager 分配的任务,并执行这些任务。每个 TaskManager 可以同时执行多个任务实例,利用多线程技术提高处理效率。
  • 状态管理:在有状态流处理应用中,TaskManager 负责管理任务的本地状态。当进行 Checkpoint 时,TaskManager 会将任务的状态保存到分布式存储中。
  • 数据传输:TaskManager 负责在不同任务之间传输数据。这些数据可以通过网络在不同的 TaskManager 之间进行传输,也可以在同一个 TaskManager 内的不同任务实例之间进行数据交换。

Dispatcher(调度器)

Dispatcher 是一个相对较新的组件,它的主要职责是处理客户端提交的作业,并将这些作业分配给集群中的 JobManager 进行处理。Dispatcher 也管理 Flink 集群的 REST API,允许用户通过 HTTP 接口提交作业、查询状态、取消作业等操作。

ResourceManager(资源管理器)

ResourceManager 负责与集群管理器(如 YARN、Kubernetes、Standalone 等)交互,管理 Flink 作业所需的资源。它的主要职责包括:

  • 资源分配:ResourceManager 接收 JobManager 的资源请求,并在集群管理器中申请相应的计算资源,如 TaskManager 容器或进程。
  • TaskManager 启动:一旦资源被分配,ResourceManager 会启动新的 TaskManager 实例来执行任务。

Client(客户端)

客户端是用户与 Flink 集群交互的入口。用户通过客户端提交作业到 Dispatcher,客户端负责将用户的作业打包,并通过 REST API 传递给 Dispatcher。客户端还可以用来监控作业执行状态、收集执行结果和错误信息。

Flink Runtime(Flink 运行时)

Flink Runtime 是 Flink 核心数据处理引擎所在的地方。它负责处理数据流、执行用户定义的操作(如 map、reduce、filter 等)、管理状态和执行 Checkpointing。Flink Runtime 的运行环境高度并行化,能够充分利用集群中的计算资源,处理大量的数据流或批数据。

State Backend(状态后端)

State Backend 是 Flink 中用来存储任务状态的模块。有两种主要的状态后端:

内存状态后端:将状态存储在 TaskManager 的内存中,适用于小规模的、对容错要求不高的作业。
RocksDB 状态后端:将状态存储在嵌入式的 RocksDB 数据库中,并支持将状态持久化到分布式文件系统,如 HDFS。适用于大规模、有状态的流处理应用。

Checkpointing 和 Savepoints

Flink 提供了 Checkpointing 和 Savepoints 两种机制来实现容错:

  • Checkpointing:定期将任务的状态保存到分布式存储中,以确保在故障时可以从最近的检查点恢复。
  • Savepoints:用户触发的状态快照,可以在程序升级或重新部署时使用。

Data Stream 和 Data Set API

  • DataStream API:用于流处理,支持无界和有界数据流,提供丰富的操作符和窗口机制。
  • DataSet API:用于批处理,支持有界数据集处理,提供了类似 SQL 的操作符。

Execution Graph(执行图)

当一个 Flink 作业被提交时,它会被转化为一个执行图(Execution Graph)。执行图描述了作业中的各个任务及其之间的依赖关系。JobManager 根据执行图来调度任务,并协调各个 TaskManager 之间的数据传输。

这篇关于大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1117508

相关文章

JS常用组件收集

收集了一些平时遇到的前端比较优秀的组件,方便以后开发的时候查找!!! 函数工具: Lodash 页面固定: stickUp、jQuery.Pin 轮播: unslider、swiper 开关: switch 复选框: icheck 气泡: grumble 隐藏元素: Headroom

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na