流/批/OLAP 一体的 Flink 引擎 | 青训营笔记

FlemingFan
160 阅读4分钟

这是我参与「第四届青训营 」笔记创作活动的的第2天


0x00 Flink概述

0.1 背景

大数据(Big Data):指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。

0.1.1 架构发展

  1. 史前阶段～2006（传统数仓、单机）

  2. Hadoop（分布式、Map-Reduce、离线计算）

  3. Spark（批处理、流处理、SQL高阶API、内存迭代计算）

  4. Flink（流计算、实时快速、流批一体、Streaming/Batch SQL）

0.1.2 为什么需要流式计算

大数据 实时性 的价值及其重要

业务处理从批式计算向流式计算转变

1_流和批.png

0.2 Flink的脱颖而出

0.2.1 流式计算引擎发展历程

1_流式计算引擎发展.png

0.2.2 流式计算引擎对比

1_流式计算引擎对比.png

0.2.3 为什么选择Flink

Flink是一个基于有界数据集和无界数据集之上的有状态计算的分布式处理框架

1_why flink.png

0.3 Apache Flink开源生态

1_开源生态.png


0x01 Flink整体架构

1.1 Flink分层框架

  1. SDK层：SQL/Table、DataStream、Python;

  2. 执行引擎层(Runtime层)：执行引层提供了统一的DAG,用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转化成分布试环境下的Task,Task之间通过Shuffle传输数据；

  3. 状态存储层：负责存储算子的状态信息；

  4. 资源调度层：目前Flink可以支持部署在多种环境；

1.2 Flink总体架构

1_Flink整体框架.png

Fink集群包含两个核心组件：

  1. JobManager(JM):负责整个任务的协调工作，包括：调度task、触发协调Task做Checkpoint、协调容错恢复等：

  2. TaskManager(TM):负责执行一个DataFlow Graph的各个task以及data streams的buffer和数据交换。

1.2.1 Flink - JobManager

JobManager细分有三个模块：

  1. Dispatcher: 接收作业，拉起JobManager来执行作业，井在JobMaster挂掉之后恢复作业；

  2. JobMaster: 管理一个job的整个生命周期，会向ResourceManager申请slot,将task调度到对应TM上；

  3. ResourceManager: 负责slot资源的管理和调度，Task manager拉起之后会向RM注册；

1_JobManager三模块.png

1.3 Flink如何流批一体

1.3.1 为什么需要流批一体

  • 业务中，需要实时统计的业务数据，我们需要流处理

  • 业务中，需要隔天统计的业务数据，我们需要批处理

1_流批一体why.png

1.3.2 Flink为什么能流批一体

批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种特殊的数据流。因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

Flink天然地支持有界和无界数据，这是Flink支持流批一体的基础。并目Flink在流批一体上，从上层的API到底层的处理机制都是统一的，是真正意义上的流批一体。

1.3.3 Flink如何做到流批一体

  1. SQL层：

  2. DataStream API层统一，批和流都可以使用DataStream API来升发；

  3. Scheduler层架构统一，支持流批场景；

  4. Failover Recovery层架构统一，支持流批场景；

  5. Shuffle Service层架构统一，流批场景选择不同的Shuffle Service;

1.3.4 流批一体的Scheduler层

Flink支持两种调度模式：

1_Scheduler.png

而后，为了让调度层面能够同时处理上图两种场景，抽象出Pipeline Region Scheduler

1_Pipeline.png

1.3.5 流批一体的Shuffle Service层

  1. 什么是Shuffle

在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle,

实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle。

  1. Shuffle的实现方式

    • 基于文件的Pull Based Shuffle,比如Spark或MR,它的特点是具有较高的客错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；

    • 基于Pipeline的Push Based Shuffle,如Flink、Storm、Presto等，它的特点是低延迟和高性能，但也因为shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复；

  2. 流和批Shuffle间的差异

    • 数据生命周期：流的Shuffle数据与Task绑定，批Shuffle数据与Task解耦

    • 数据存储介质：流的Shuffle数据通常存储在内存，批的Shuffle数据通常存储在磁盘中

    • 部署方式：流的Shuffle服务和计算节点部署在一起，可以减少网络开支


0x02 Flink架构优化

2.1 流/批/OLAP业务场景

  • 业务中，运营需要对数据进行交互分析，我们需要OLAP计算

1_OLAP.png

OLAP计算是一种特殊批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大的区别。

2.2 Flink的OLAP优化

2.2.1 Flink做OLAP的优势

  • 引擎统一

  • 既有优势

  • 生态支持

2.2.2 Flink OLAP的挑战

  • 面向的作业为毫秒级

  • 频繁启停产生资源碎片

  • Latency+QPS要求高

2.2.3 Flink OLAP架构现状

Gateway接收Client提交的SQL Query,对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群

1_OLAP架构现状.png

avatar
文章
阅读
粉丝