2024-02-28（Kafka，Oozie，Flink）

1.Kafka的数据存储形式

一个主题由多个分区组成

一个分区由多个segment段组成

一个segment段由多个文件组成（log，index（稀疏索引），timeindex（根据时间做的索引））

2.读数据的流程

消费者的offset是一个针对分区的全局offset

可以根据这个offset找到segment段

接着需要将全局offset转换成segment的局部offset

根据局部offset，就可以从（.index稀疏索引）找到对应的数据位置

开始顺序读取

3.Oozie的概念

        Oozie是用来管理Hadoop生态圈Job的工作流调度系统，运行于Java Servlet容器上的一个Java Web应用，Oozie是按照DAG（有向无环图）的顺序调度一系列的Map/Reduce或者Hive等任务。Oozie由hPDL（Hadoop Process Definition Language）定义（XML格式的语言）。使用场景包括：需要按照顺序进行一系列任务；并行处理的任务；定时和周期触发的任务；可视化作业流运行过程；运行结果或异常的通报。

4.Oozie的架构

Oozie Client：提供命令行（CLI），Java API，rest等方式，对Oozie的工作流流程的提交，启动，运行等操作。

Oozie Web：Oozie Server，本质是一个Java应用，可以使用内置的Web容器，也可以使用外置的Web容器。

Hadoop Cluster：底层执行Oozie编排流程的各个Hadoop生态圈组件。

Oozie各种任务的提交底层都是依赖于MR程序。

5.Oozie的基本原理

        Oozie对于工作流的编排，是基于workflow.xml文件来完成的。用于预先将工作流执行规则定制于workflow.xml文件中，并在job.properties配置相关的参数，然后由Oozie Server向MR提交job来启动工作流。

流程节点：

ControlFlowNodes：控制工作流执行路径，包括start，end，kill，decision，fork，join。

Action Nodes：决定每个操作执行的任务类型，包括MapReduce，Java，hive，shell等。

举例：

6.Oozie工作流类型：

1）WorkFlow：规则相对简单，不涉及定时，批处理的工作流。顺序执行节点

缺点：没有定时和条件触发功能。

2）Coordinator

        Coordinator将多个工作流Job组织起来，成为Coordinator Job，并制定触发时间和频率，还可以配置数据集，并发数等，类似于在工作流外部增加了一个协调器来管理这些工作流的工作流Job的运行。

3）Bundle

        针对coordinator的批处理工作流。Bundle将多个coordinator管理起来，这样我们只需要一个Bundle提交即可。

7.Oozie官方自带了许多案例，里面封装了各种类型任务的配置模板

所以后续可以根据官方给的这些配置模板进行修改就好。

8.感觉很多中间件的使用就是配置好配置文件即可。在使用层面组件帮我们做了很多事

9.Oozie调度流程

1）根据官方自带的示例编写配置文件

job.properties  workflow.xml

2）把任务配置信息连同依赖的资源一起上传到hdfs指定的路径，这个路径在配置中有

3）利用Oozie的命令进行提交

10.Oozie任务串联

        在实际工作中，肯定会存在多个任务需要执行，并且存在上一个任务的输出的结果作为下一个任务的输入数据这样的情况，所以我们需要在workflow.xml配置文件当中配置多个action，实现多个任务之间的相互依赖关系。

比如：先执行一个shell脚本，执行完了之后再执行一个MR的程序，最后再执行一个hive程序。

其实就是依靠workflow.xml配置文件来控制好节点的流程。

11.Oozie定时调度

        主要是通过coordinator来实现任务的定时调度，Coordinator模块主要通过xml来配置即可。

有两种调度方式：1）基于时间的定时任务调度；2）基于数据的任务调度。

12.Hue集成Oozie

背景：Oozie本身的开发不是很友好，不论是调度Hive程序还是调度MapReduce程序，都要编写大量的配置文件，然后做上传提交，再执行，比较麻烦。

Hue可以实现鼠标拖拽的办法来实现Oozie所支持的所有功能。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Flink

13.Flink支持所有的流式计算

14.Flink的发展

第 1 代：Hadoop MapReduc 批处理 Mapper、Reducer 2；

第 2 代：DAG 框架（Oozie 、Tez），Tez + MapReduce 批处理 1 个 Tez = MR(1) + MR(2) + ... + MR(n) 相比 MR 效率有所提升；

第 3 代：Spark 批处理、流处理、SQL 高层 API 支持 自带 DAG 内存迭代计算、性能较之前大幅提；

第 4 代：Flink 批处理、流处理、SQL 高层 API 支持 自带 DAG 流式计算性能更高、可靠性更高。

15.什么是Flink

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

16.什么是批处理和流处理

        批处理的特点是有界、持久、大量，批处理非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。流处理的特点是无界、实时，流处理方式无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。

        在 Spark 生态体系中，对于批处理和流处理采用了不同的技术框架，批处理由 SparkSQL 实现，流处理由 Spark Streaming 实现，这也是大部分框架采用的策略，使用独立的处理器实现批处理和流处理，而 Flink 可以同时实现批处理和流处理。

        Flink 是如何同时实现批处理与流处理的呢？答案是，Flink 将批处理（即处理有限的静态数据）视作一种特殊的流处理。

        上图为 Flink 技术栈的核心组成部分，值得一提的是，Flink 分别提供了面向流式处理的接口（DataStream API）和面向批处理的接口（DataSet API）。因此，Flink 既可以完成流处理，也可以完成批处理。Flink 支持的拓展库涉及机器学习（FlinkML）、复杂事件处理（CEP）、以及图计算（Gelly），还有分别针对流处理和批处理的 Table API。

17.Flink的四种运行模式

1）local模式

原理：在本地模拟多线程去模拟Flink中的各个角色。

2）StandAlone独立集群模式

原理：

3）Standalone-HA高可用集群模式

原理：

前面的架构中存在Job Manager有单点故障的风险，Job Manager担任任务调度和资源分配，它出现故障很危险。因此：

4）Flink-On-Yarn

原理：

为什么使用flink on yarn：

a.公司资源有限，大多数有Hadoop系统，节约资源；

b.yarnd的资源可以按需使用，提高集群的资源利用率；

c.yarn的任务有优先级，根据优先级运行作业；

d.基于yarn调度系统，能够自动化的处理各个角色的failover（容错）：

        d.1） JobManager进程和TaskManagerj进程都由Yarn NodeManager 监控

        d.2） 如果JobManager进程异常退出，则Yarn RecourseManager 会重新调度JobManager到其他机器

        d.3） 如果TaskManager 进程异常退出，JobManager 会收到消息并重新向Yarn RecourseManager 申请资源，重新启动TaskManager。

18.Flink on yarn的两种模式

1）Session模式（Session会话模式）：在Yarn集群中启动了一个Flink集群，并重复使用该集群

特点：需要事先申请资源，启动JobManager和TaskManager

优点：不需要每次提交作业申请资源，而是使用已经申请好的资源,，从而提高执行效率

缺点：作业执行完之后，资源不会被释放，因此会一直占用系统资源

应用场景：适合作业提交比较频繁的场景，小作业比较多的场景

2）Per-Job模式（Job分离模式）（用的多）：针对每个Flink任务都去启动一个独立的Flink集群，用完就关，不能重复使用该集群

特点：每次提交作业都需要申请一次资源

优点：作业运行完成，资源会立即释放,，不会一直占用系统资源

缺点：每次提交作业都需要申请资源，会影响执行效率，因为申请资源需要消耗时间

应用场景：适合作业比较少，大作业的场景。

19.Flink应用程序的编程模型

eg：

18.Flink中应用编程使用DataStream API，弃用DataSet API。

注意：在Flink1.12中，DataSteam既支持流处理也支持批处理。在后续开发中，把一切的数据源看作流即可。（批也可以看成流）

Flink保姆级教程，超全五万字，学习与面试收藏这一篇就够了_flink 教程-CSDN博客