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

JadenQ
250 阅读4分钟

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

一、本堂课重点内容

Flink概述

Flink整体架构

Flink架构优化

案例讲解

二、详细知识点介绍

Flink为什么出现——概述

2.1 Flink的诞生背景

2.1.1 什么是大数据
  • Value 价值化
  • Volumes 海量化
  • Velocity 快速化
  • Variety 多样化
2.1.2 大数据计算架构发展历史
  • 史前阶段（~2006）
    • 传统数仓
    • Oracle
    • 单机
    • 黑箱
  • Hadoop
    • 分布式文件系统 GFS
    • MapReduce
    • 离线计算——Big Table
  • Spark
    • 批处理
    • 流处理
    • SQL高阶API
    • 内存迭代计算
  • Flink
    • 流计算
    • 实时性更快
    • 流批一体
    • Streaming/Batch SQL
2.1.3 为什么需要流式计算
  • 大数据的实时性带来的价值更大
    • 监控场景：防止业务故障
    • 金融风控：阻断丰线
    • 兴趣推荐：实时推送
  • 批式计算to流式计算
    • 批式计算
      • 离线计算、非实时
      • 静态数据集
      • 小时/天为周期计算
    • 流式计算
      • 实时计算、快速、低延迟
      • 无限流、动态、无边界
      • 7 x 24 h 持续运行
      • 流批一体

2.2 Apache Flink为什么脱颖而出

2.2.1 流式计算引擎发展历程

MapReduce->Hadoop->Flume->Storm->Spark(Spark Streaming)->MillWheel->Kafka->Cloud DataFlow->Flink->Beam

2.2.2 流式计算引擎对比
  • 对比维度
    • Streaming Model
    • 一致性保证
    • 延迟
    • 吞吐
    • 容错
    • Stateful
    • SQL支持
StormSpark StreamingFlink
Streaming Model
一致性保证
延迟
吞吐
容错
Stateful
SQL支持
2.2.3 Why Flink
  • Exactly-Once
    • 精确一次的计算语义
  • 状态容错
    • Checkpoint，基于状态
  • Dataflow编程模型
    • Window等高阶需求支持友好
  • 流批一体
  • Flink具有完整的开原生态
    • Gelly
    • Flink ML
    • ...

Flink如何实现流批一体——整体架构

2.1 Flink分层架构

  • SDK层
    • SQL/Table：数据查询的支持
    • DataStream：Java支持
    • Python：Flink ML解决方案的接口
  • 执行引擎层 (Runtime层)
    • 提供了统一的DAG描述数据处理的pipeline,然后转化为分布式环境的Task，通过Shuffle传输数据
  • 状态存储层
    • 存储算子的状态信息
  • 资源调度层
    • 支持部署在Yarn,Tez,standalone等模式

2.2 Flink总体架构

  • JobManager (JM)
    • 整个任务的协调工作：调度Task，触发做checkpoint，协调容错恢复等
      • Dispatcher: 接受作业，拉起JobManager来执行作业，JobMaster挂掉吼回复作业
      • JobMaster: 管理job的整个生命周期，向RM申请slot，把task调度到对应的TM
      • ResourceManager: 负责slot的管理和调度，TM拉起之后向RM注册
  • TaskManager (TM)
    • 执行一个dataflow graph的各个task以及data streams的buffer和数据交换 Program Code -> DataFlow -> DAG (DataFlow Graph) -> Client 转化为物理执行图。

2.3 Flink作业示例

Source->map->keyBy/window/apply ->Sink

并发度：2->2->2->1

Source和map都chain到一个线程，减少了序列化、反序列化和数据在TM的切换。可以进行判断什么条件下chain。

  • JM向TM申请资源
    • Slot: 在TM进程中单独的一个线程，CPU和内存没有完全严格隔离

2.4 Flink如何做到流批一体

  • 为什么需要流批一体
    • 流（Kafka DIM Flink）实时数仓
    • 批 (Hive) 离线数仓
    • 两套系统需要相同逻辑开发两边
    • 数据链路冗余、需要执行两遍
    • 两套系统（算子、UDF）结果误差
  • 流批一体的挑战
    • 流式计算
      • 实时计算
      • 延迟秒级以内
      • 0-1s
      • 广告推荐、金融风控
      • 无限数据集
      • 低延迟、业务会感知
    • 批式计算
      • 离线计算
      • 小时/分钟
      • 10s-1h+
      • 搜索引擎构建索引、批式数据分析
      • 有限数据集
      • 实时性不高、只关注结果产出时间
  • Flink如何做到流批一体
    • Everything is streaming 批是特殊的流，不同数据使用不同service
      • OLAP Engine
      • Batch Engine
      • Stream Engine
    • SQL层
      • 有/无边界数据查询
    • DataStream API层统一，批和流都可以使用DataStream API来开发
    • Scheduler，Failure Recovery和Shuffle Service层架构统一
  • Flink的Scheduler
    • Flink在1.12版本之前：
      • EAGER 申请一个作业所需要的全部资源同时调度这个作业的全部Task，所有task全部获取资源才可以进行
      • LAZY 先调度上游、再调度下游：先让一个Task运行（spark的lazy execution与查询优化）
    • Pipeline Region
      • 利用Pipeline数据交换方式，如果有shuffle数据交换，构成一个pipeline region粒度
      • 性能介于EAGER和LAZY之间
    • 数据交换模式
      • ALL_EDGES_BLOCKING 所有task之间的数据都是blocking交换模式,数据落入磁盘，分成不同的pipeline region
      • ALL_EDGE_PIPELINE 所有task之间的数据pipeline模式，不落盘，一个pipeline region。
  • Flink的Shuffle Service
    • 基于文件：spark/mr 容错性和稳定性好，基于文件，shuffle数据与task绑定，存磁盘
    • 基于pipeline: Flink Storm低延迟和高性能，shuffle数据与task解耦，shuffle数据没有存储，shuffle服务和计算节点部署在一起，减少网络开销和latency。
    • 共性：流批都为了re-partition
    • Streaming和OLAP,Batch场景（拓展文档）
    • Netty shuffle service, Remote shuffle service

如果要支持OLAP，Flink应当如何优化

  • 本堂课介绍了哪些知识点？

三、实践练习例子：

Flink在OLAP的应用

avatar
文章
阅读
粉丝