大数据理论知识合集

发表于 更新于 分类于

对于大数据理论方面知识进行搜集整理

Hadoop

1.HDFS的组成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1.NameNode：
    管理HDFS的名称空间；
    管理数据块的映射信息；
    配置副本策略；
    处理客户端的读写请求。
    Fsimage：
        存储了文件的基本信息，如文件路径，文件副本集个数，文件块的信息，文件所在的主机信息。
    Editslog：
        存了客户端对hdfs中各种写操作的日志（指令）。
2.DataNode：
    存储实际的数据块(Block，默认128M)；
    执行数据块的读写操作。
3.Secondary NameNode：
    是NameNode的冷备；
    辅助NameNode，分担其工作量；
    定期（每一小时，editslog大小超过64M）合并fsimage和fsedits，并推送给NameNode；
    在紧急情况下，可辅助恢复NameNode。
4.Client：
    文件切分；
    与NameNode交互，获取文件的位置信息；
    与DataNode交互，读取或者写入数据；
    Client提供一些命令来管理HDFS，比如启动或者关闭HDFS；
    Client可以通过一些命令来访问HDFS。

2.HDFS读写数据流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
读
    1.HDFS客户端开启分布式文件系统
    2.分布式文件系统向NameNode获取数据块信息
    3.HDFS客户端通过数据块信息创建文件系统数据输入流
    4.流通过数据块信息去各个DataNode读取信息
    5.HDFS客户端关闭流
写
    1.HDFS客户端开启分布式文件系统
    2.分布式文件系统创建NameNode
    3.HDFS客户端创建文件系统数据输出流
    4.通过流写入DataNode---逐步备份
    5.逐步返回ack---流检测ack是否成功
    6.HDFS客户端关闭流
    7.分布式文件系统向NameNode提交完成

3.MR的shuffle过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Map端Shuffle
Split切片,一般根据HDFS上的Block数量决定
频繁的磁盘I/O操作会严重降低效率,"中间结果"不会立马写入磁盘,而是写入一个环形缓冲区
在写入过程中进行分区,对于每个键值增加一个partition属性值
连同键值对一起序列化成字节数组写入缓冲区(默认100M)
当写入的数据量达到预先设置的阙值后(默认0.8)便会启动溢写
将缓冲区数据写到磁盘的临时文件中(可以压缩,默认不压缩),写入前根据Key进行排序(Sort)和合并(Combine,可选操作)
当整个Map操作完成溢写后,会对磁盘这个Map产生的所有临时文件进行归并(Merge),生成正式输出文件
此时的归并会将所有临时文件中相同partition合并到一起,并对每一个partition的数据再一次排序(Sort)

Reduce端Shuffle
不断拉取当前Job中每个MapTask的最终结果
从不同地方拉取过来的数据不断做Merge,合并成分区相同的大文件
对这个文件的键值对按Key进行Sort
排好序之后紧接着分组,分组完成后才将整个文件交给ReduceTask处理

注意
1.Combine和Merge的区别
    <a,1>,<a,1>变成<a,2>是Combine
    <a,1>,<a,1>变成<a,<1,1>>是Merge
2.Shuffle中的排序
    内存缓冲区使用的是快速排序
    文件合并阶段使用的归并排序

4.读取文件时,块损坏操作

1
2
3
Client读取DataNode上的块之后会进行checksum验证
将读取到本地的块与HDFS上原始块进行校验
如果不一致,Client通知NameNode,从下一个拥有该Block副本的DataNode读取

5.文件上传时,DataNode宕机

1
2
3
4
5
Client上传文件时与DataNode建立的文件流管道,管道正方向是Client向DataNode发送数据包
反向是DataNode向Client发送ack确认
当DN挂掉,Client收不到DN发送的ack确认,Client会通知NameNode
NN检查该块的副本与规定的不符,NN通知DN去复制副本
挂掉的DN作下线处理,不让它参与文件上传与下载

6.NameNode启动时操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
首次启动
    格式化文件系统,生成fsimage镜像文件
    NN启动
        读取fsimage,将文件内容加载到内容
        等待DN注册与发送block report
    DN启动
        向NN注册
        发送block report
        检查fsimage中记录的块数量和block report中的块总数是否相同
    Client对文件系统进行操作
        将文件系统的改变信息写入edits,edits存储文件系统元数据改变信息

第二次启动
    读取fsimage和edits文件
    将fsimage和edits文件合并成新的fsimage文件
    创建新的edits文件,内容开始为空
    启动DN

7.Secondary NameNode工作机制

1
2
3
4
5
6
7
8
9
10
合并NameNode的edits到fsimage文件中
    SNN询问NN是否需要checkpoint
    SNN请求执行checkpoint
    NN滚动正在写的edits
    将滚动前的edits和fsimage拷贝到SNN
    SNN加载edits和fsimage到内存,进行合并生成新的fsimage.chkpoint文件
    拷贝fsimage.chkpoint到NN
    NN将fsimage.chkpoint重新命名成fsimage

SNN只能恢复一部分元数据信息,不是全部,NN正在写的edits没有拷贝给SNN,这些是恢复不了的

8.NameNode的HA

1
2
3
4
5
6
7
8
9
10
元数据信息同步在HA方案中采用共享存储
    每次写文件需要将日志同步写入共享存储,这个步骤成功才被认定写文件成功
    备份节点定期从共享存储同步日志,以便进行主备切换
NN状态采用Zookeeper监控
    两个NN的状态存放在ZK中,再分别利用一个进程监控程序(ZKFailoverController)实时读取ZK中NN的状态
    判断当前NN是不是挂掉,如果Standby节点的ZKFC发现Active节点挂掉
    强制给Active节点发送强制关闭请求,将Standby节点设置为Active

共享存储实现: QJM(Quorum Journal Manager)
共享存储保存在Editlog中,这也是分布式一致性的体现

9.HA的脑裂

1
2
3
4
5
6
7
8
上面HA的主备切换,依靠的ZKFC进行强制关闭,假如ZKFC假死,没有关闭成功
这意味着集群同时存在2个Active状态的节点,这就是脑裂

如何解决: Fencing(隔离)
首先尝试将旧Active NN节点转换为Standby,调用HAServiceProtocol接口的transitionToStandby方法
失败则执行Hadoop配置中预定义的隔离策略(默认sshfence)
    sshfence: 通过SSH登录目标机器,执行fuser将对应的进程杀死
    shellfence: 执行一个用户自定义的shell脚本将对应的进行隔离

10.小文件过多如何避免

1
2
3
4
5
6
HDFS元数据信息存储在NameNode内存,过多的小文件会压垮NN的内存

对已有的文件
    Hadoop Archive命令进行小文件归档
对将要上传的文件
    进行合并后上传

Yarn

1.Yarn的组成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1.ResourceManager
    主要由调度器和应用程序管理器组成
    处理客户端请求
    启动或监控ApplicationMaster
    监控NodeManager
    负责整个集群的资源管理和调度
2.NodeManager
    处理来自ResourceManager上的命令
    处理来自ApplicationMaster上的命令
    负责单个节点上的资源管理
3.ApplicationMaster
    负责数据切分
    为应用程序申请资源并分配给内部的任务
    负责应用程序相关的事务,比如任务调度,任务监控和容错等
4.Container
    资源抽象
    一个应用程序会分配一个Container,应用程序只能使用这个Container中描述的资源

2.Yarn执行流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
1.作业提交
    A.Client调用job.waitForCompletion方法，向集群提交MR作业；
    B.ResourceManager分配JobID；
    C.Client核实作业的输出，计算输入的Split，将作业的资源(Jar包，配置文件，Split信息等)拷贝给HDFS；
    D.调用ResourceManager的submitApplication()提交作业。
2.作业初始化
    A.ResourceManager收到请求，将请求发送给调度器（scheduler），调度器分配Container，然后ResourceManager在Container中启动ApplicationMaster，由NodeManager进行监控；
    B.ApplicationMaster通过bookkeeping对象来监控作业的进度，得到任务的进度和完成报告；
    C.通过HDFS得到Client计算好的Split，为每个输入Split创建Map任务，根据mapreduce.job.reduces创建Reduce任务对象。
3.任务分配
    A.如果作业小，ApplicationMaster会选择在自己的JVM中运行任务；
    B.如果作业大，ApplicationMaster会向ResourceManager请求Container来运行所有的map和reduce任务，请求通过心跳机制传输；
    C.调度器利用这些信息来调度任务，尽量将任务分配给存储数据的节点，或者退而分配给和存放Split的节点相同机架的节点。
4.任务运行
    A.当任务由ResourceManager的调度分配给Container后，ApplicationMaster通过联系NodeManager来启动Container；
    B.任务由一个主类为YarnChild的Java应用执行（YarnChild运行在一个专用的JVM中，Yarn不支持JVM重用）；
    C.在运行任务之前首先需要本地化任务需要的资源，比如作业配置，Jar包，以及分布式缓存的所有文件；
    D.运行Map或Reduce任务。
5.进度和状态更新
    A.Yarn中的任务将其进度和状态返回给ApplicationMaster；
    B.Client每秒向ApplicationMaster请求进度更新，展示给用户。
6.任务完成
    A.除了向ApplicationMaster请求作业进度外，Client每5分钟检查作业是否完成通过调用waitForCompletion()方法；
    B.作业完成之后，ApplicationMaster和Container会清理工作状态，OutputCommiter的作业清理方法也会被调用；
    C.作业的信息会被作业历史服务器存储以备用户核查。

3.Yarn的资源调度模型

1
2
3
4
5
6
7
FIFO
    先来先服务调度
Capacity(Hadoop默认)
    能力调度,专门的队列运行小任务
Fair(CDH默认)
    公平调度,当只有一个Job运行,获得所有集群资源,再提交一个时,会分配一半资源出来
    不过第二个任务分配资源可能延迟,需要等待第一个Job释放资源

Hive

1.Hive怎么解决数据倾斜的问题?

1
使map的输出数据更均匀的分布到reduce中去，是我们的最终目标

2.数据倾斜有哪些原因?

1
2
3
4
5
6
7
8
9
10
11
12
key分布不均匀
业务数据本身的欠缺性
建表设计方法不对
有些SQL难免会有一些数据倾斜不可避免

表现的形式:
    任务完成进度卡死在99%，或者进度完成度在100%
    但是查看任务监控，发现还是有少量（1个或几个）reduce子任务未完成
    因为其处理的数据量和其他reduce差异过大
    单一reduce的记录数与平均记录数差异过大
    通常可能达到3倍甚至更多
    最长时长远大于平均时长

3.Hive的工作过程

1
2
3
4
5
6
7
8
A.用户提交查询等任务给Driver；
B.编译器获得该用户的任务Plan；
C.编译器Compiler根据用户任务去MetaStore中获取需要的Hive的元数据信息；
D.编译器Compiler得到元数据信息，对任务进行编译，先将HQL转换为抽象语法树，然后将抽象语法树转换成查询块，将查询快转化为逻辑的查询计划，重写逻辑查询计划，将逻辑计划转化为物理计划（MapReduce），最后选择最优策略；
E.将最终的计划提交给Driver；
F.Driver将计划Plan转交给ExecutorEngine去执行，获取元数据信息，提交给JobTracker或者ResourceManager执行该任务，任务会直接读取HDFS中文件进行相应的操作；
G.获取执行的结果；
H.取得并返回执行结果。

4.Hive优化器的主要功能

1
2
3
4
5
6
7
A.将多Multiple Join合并为一个Muti-Way Join；
B.对Join，group by和自定义的MapReduce操作重新进行划分；
C.消减不必要的列；
D.在表的扫描操作中推行使用断言；
E.对于已分区的表，消减不必要的分区；
F.在抽样查询中，消减不必要的桶；
G.优化器还增加了局部聚合操作用于处理大分组聚合和增加再分区操作用于处理不对称的分组聚合。

5.ORC,Parquet列式存储优点

1
2
3
4
5
6
7
8
9
10
11
Parquet
    支持嵌套的数据模型,每一个数据模型的schema包含多个字段,每个字段有三个属性:重复次数,数据类型和字段名
    Parquet中没有Map,Array这样的复杂数据结构,可以通过repeated和group组合来实现
    Parquet文件以二进制方式存储,不可以直接读取和修改
    Parquet文件是自解析的,文件中包括该文件的数据和元数据

ORC
    ORC也是自解析的,元数据使用Protocol Buffers序列化
    ORC会尽可能合并多个离散区间减少I/O次数
    ORC使用了更精确的索引信息,读取数据时可以指定从任意一行开始读取
    支持BloomFilter,提升谓词下推效率

6.SortBy和OrderBy区别

1
2
order by全局排序
sort by局部排序

7.Hive小文件过多

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
concatenate命令,合并小文件(只支持RCFILE和ORC文件类型)
    #对于非分区表
    alter table A concatenate;
    #对于分区表
    alter table B partition(day=20001001) concatenate;

调整参数减少Map数量
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 默认
# 每个Map最大输入大小(决定了合并后文件的数量)
set mapred.max.split.size=256000000;   -- 256M
# 一个节点上split的至少大小(决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=100000000;  -- 100M
# 一个交换机下split的至少大小(决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack=100000000;  -- 100M

调整参数减少Reduce数量
# 设置reduce的数量有两种方式,第一种是直接设置reduce个数
set mapreduce.job.reduces=10;
# 第二种是设置每个reduce的大小,Hive会根据数据总大小猜测确定一个reduce个数
set hive.exec.reducers.bytes.per.reducer=5120000000; -- 默认是1G，设置为5G

利用Hadoop归档操作
# 用来控制归档是否可用
set hive.archive.enabled=true;
# 通知Hive在创建归档时是否可以设置父目录
set hive.archive.har.parentdir.settable=true;
# 控制需要归档文件的大小
set har.partfile.size=1099511627776;
使用以下命令进行归档：
ALTER TABLE A ARCHIVE PARTITION(dt='2000-10-01', hr='12');
对已归档的分区恢复为原文件：
ALTER TABLE A UNARCHIVE PARTITION(dt='2000-10-01', hr='12');
归档的分区可以查看,不可以INSERT OVERWRITE,必须先unarchive

HBase

1.HBase的系统架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1.Client
    包含了访问HBase的接口，Client维护着一些cache来加快对HBase的访问，比如Region的位置信息。
2.Zookeeper
    A.保证任何时候，集群中只有一个Master；
    B.存储所有Region的寻址入口，Root表在哪台服务器上；
    C.实时监控Region Server的状态，将Region Server的上线和下线信息实时通知给Master；
    D.存储HBase的Schema，包括有哪些table，每个table有哪些column family。
3.Master
    A.为Region Server分配Region；
    B.负责Region Server的负载均衡；
    C.发现失效的Region Server并重新分配其上的Region；
    D.HDFS上的垃圾文件回收；
    E.处理schema更新请求。
4.Region Server
    A.Region Server维护Master分配给它的Region，处理对这些Region的IO请求；
    B.Region Server负责切分在运行过程中变得过大的Region；
    C.Client访问HBase上数据的过程并不需要Master参与(寻址访问Zookeeper和Region Server，数据读写访问Region Server)
        Master仅仅维护table和Region的元数据信息，负载很低。

2.HBase的存储结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
1.基本结构
    A.Table中的所有行都按照rowKey的字典排列；
    B.Table在行的方向上分割为多个Region；
    C.Region按大小分割，每个表一开始只有一个Region，随着数据的不断插入，Region不断增大
        当增大到一个阈值的时候，Region就会等分成两个新的Region，当table中的行数不断增多，就会有越来越多的Region；
    D.Region是HBase中分布式存储和负载均衡的最小单元。
        最小单元表示不同的Region可以分布在不同的Region Server上，但是一个Region是不会拆分到不同的Region Server上的；
    E.Region虽然是分布式存储的最小单元，但并不是物理存储的最小单元。
2.MemStore与StoreFile
    A.Region由一个或者多个Store组成，每个Store保存一个column family；
    B.每个Store由一个MemStore和0至多个StoreFile组成；
    C.写操作先写入MemStore，当数据量达到一个阈值，Region Server启动flashcache进程写入StoreFile；
    D.当Store大小超过一定阈值，会把当前的Region分割成两个，并由Master分配给相应的Region Server（先下线Region，切割好之后加入Meta元信息，加入到原本的RegionServer中，最后汇报Master）；
    E.客户端检索数据时，先在MemStore找，找不到再找StoreFile；
    F.StoreFile以HFile的格式保存在HDFS上。
3.HFile
    A.Data Block段：保存表中的数据，可被压缩；
    B.Meta Block段：保存用户自定义的kv对，可被压缩；
    C.File Info段：HFile的元信息，不可压缩，用户也可以在这一部分添加自己的元信息；
    D.Data Block Index段：Data Block的索引；
    E.Meta Block Index段：Meta Block的索引；
    F.Trailer段：保存每一段的偏移量，读取一个HFile时，会首先读取Trailer。
4.HLog(（WAL Log）
    A.类似MySQL的binlog，做灾难恢复，记录数据的所有变更；
    B.每个Region Server维护一个HLog；
    C.如果Region Server下线，需要对其上的HLog进行拆分，分发到其他Region Server进行恢复。

3.Compact操作

1
2
3
4
5
6
7
8
Minor
    做部分文件的合并操作以及包括minVersion=0并且设置ttl的过期版本清理
    不做任何删除数据,多版本数据的清理工作
Major
    对Region下的HStore下的所有StoreFile执行合并操作
    最终的结果是整理合并出一个文件
    
Compact操作会对写操作加锁,阻塞更新操作,导致更新服务不可用

Spark

1.SparkSQL和SparkStreaming哪个比较熟?

1
2
3
都还行，SparkSQL的DataFrame或者DataSet和SparkStreaming的DStream都是基于SparkCore的;
最终都会转化为SparkTask执行;
我们可以交流一下本质的东西SparkCore，而SparkCore的核心又是RDD。

2.说一下SparkShuffle

1
2
3
4
5
6
7
8
9
Spark的shuffle也是一处理问题的思想：分而治之。
Shuffle一般称为洗牌，一般会有Shuffle Write阶段和Shuffle Read阶段。
在Spark中实现Shuffle的方式有两种，一种是HashShuffle(2.0弃用)，一种是SortShuffle。
Shuffle的性能是影响Spark应用程序性能的关键。
Shuffle发生在stage之间，stage中用的pipline的计算模式。

决定Shuffle后数据属于哪个分区,主要由分区器决定(HashPartitioner,RangePartitioner)
Hash: 由于Hash碰撞的存在,极端情况下可能出现数据倾斜
Range: 划分范围,分区与分区之间是有序的,分区内不保证顺序

3.SparkShuffle的调优点?

1
2
3
4
Shuffle的选择
缓冲区的大小
拉取的数据量的大小
间隔时间重试次数

4.缓存这块熟悉吗,介绍缓存级别

1
2
3
4
5
6
7
8
9
10
11
12
Spark的缓存机制是Spark优化的一个重要点；
它将需要重复使用或者共用的RDD缓存在内存中，可以提高Spark的性能。
Spark的底层源码中使用StorageLevel来表示缓存机制，
其中包括：
    使用内存，使用磁盘，使用序列化，使用堆外内存
在他的半生对象中基于这几种方式提供了一些实现：
    不使用缓存，Memory_Only，Disk_only，OffHeap
分别都有相应的序列化，副本，组合的实现提供选择。
持久化的级别StorageLevel可以自定义，但是一般不自定义。
如何选择RDD的缓存级别的本质是在内存的利用率和CPU的利用率之间的权衡。
一般默认选择的是Memory_only, 其次是Memery_only_Ser, 再次是Memory_only_and_Dis
至于怎么选择你得自己权衡。

5.说一下cache和checkpoint的区别

1
2
3
4
5
6
7
8
catche是将共用的或者重复使用的RDD按照持久化的级别进行缓存
checkpoint是将业务场景非常长的逻辑计算的中间结果缓存到HDFS上
ck的实现原理是:
    首先找到stage最后的finalRDD，然后按照RDD的依赖关系进行回溯
    找到使用了checkPoint的RDD
    然后标记这个使用了checkPoint的RDD
    重新的启动一个线程来将checkPoint之前的RDD缓存到HDFS上面
    最后将RDD的依赖关系从checkPoint的位置切断

6.Spark运行模式local、local[]和local[*]分别是什么?

1
2
3
4
5
该模式被称为Local[N]模式，是用单机的多个线程来模拟Spark分布式计算
通常用来验证开发出来的应用程序逻辑上有没有问题
其中N代表可以使用N个线程，每个线程拥有一个core。
如果不指定N，则默认是1个线程（该线程有1个core）。
如果是local[*]，则代表Run Spark locally with as many worker threads as logical cores on your machine(在本地运行Spark，与您的机器上的逻辑内核一样多的工作线程)。

7.Spark怎么设置垃圾回收机制?

1
2
3
4
5
6
Spark中各个角色的JVM参数设置:
Driver的JVM参数
    GC方式，如果是yarn-client模式，默认读取的是spark-class文件中的JAVAOPTS；
    如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的参数值。
Executor的JVM参数
    GC方式，两种模式都是读取的是spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。

8.一台节点上以root用户执行一个spark程序，以其他非root用户也同时在执行一个spark程序，这时以spark用户登录，这个节点上，使用Jps会看到哪些线程？

1
单独的用户只能看自己的进程

9.Spark运行流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SparkContext向资源管理器注册并申请运行Executor
资源管理器分配Executor并启动
Executor发送心跳给资源管理器
SparkContext构建DAG给DAGScheduler
DAGScheduler将DAG分解成Stage再拆为TaskSet发送给TaskScheduler
Executor向SparkContext申请Task
TaskScheduler将TaskSet发送给Executor运行
Executor执行Task后释放所有资源

详细可以参考这两篇
OnYarn
https://jxeditor.github.io/2017/11/21/Spark%E4%BB%BB%E5%8A%A1%E7%94%9F%E6%88%90%E5%92%8C%E6%8F%90%E4%BA%A4%E8%BF%87%E7%A8%8B%E4%B9%8BOnYarn
OnStandAlone
https://jxeditor.github.io/2017/11/21/Spark%E4%BB%BB%E5%8A%A1%E7%94%9F%E6%88%90%E5%92%8C%E6%8F%90%E4%BA%A4%E8%BF%87%E7%A8%8B%E4%B9%8BOnStandAlone

10.ReduceByKey和GroupByKey

1
2
3
4
5
6
ReduceByKey
    类似于Combiner,发送至RedUC而之前会进行本地Merge
    减少数据量,加快计算
GroupByKey
    将value值聚合形成一个序列(Iterator)
    数据量大的话,emm会OOM

11.DAG

1
2
3
4
5
6
7
8
9
10
DAG,有向无环图,指数据转换执行的过程

DAG原因(达到并行计算目的)
    一个业务逻辑如果有shuffle,意味着前面阶段产生结果后,后续操作才能执行
    所以按宽依赖就可以将DAG划分成多个Stage,同一个会有多个算子操作
    这些算子操作就可以并行计算

怎么划分DAG
回溯算法,从后往前回溯,遇到窄依赖加入Stage,遇见宽依赖进行切分
SparkCore从触发Action操作的RDD开始从后往前推

12.OOM问题

1
2
3
4
5
6
7
8
9
10
11
12
13
Map类型算子内存溢出
    map端产生大量对象导致内存溢出
    增加堆内内存,不增加内存的情况下减少Map端Task处理数据量
    调用reparation,分区成更小的块传入map

Shuffle内存溢出
    Shuffle后单个文件过大导致
    修改spark.default.parallelism默认RDD分区数
    这个只对HashPartitioner有效,其他的分区器就得重写分区器代码

Driver内存溢出
    用户在Driver端生成大对象,导致内存溢出
    转换为Executor加载,sc.textfile,或者加大Driver端内存

Flink

1.Flink中TM内存管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Total Process Memory 总内存(设置多少就是多少)
    Total Flink Memory 总Flink使用内存
        JVM Heap 堆内内存
            Framework Heap 框架堆内内存,默认128M
            Task Heap 任务堆内内存,总Flink使用内存-框架堆内内存-管理内存-网络内存
        Off-Heap Memory 堆外内存
            Managed Memory 管理内存,总Flink使用内存的0.4
            Direct Memory
                Framework Off-Heap 框架堆外内存,默认128M
                Task Off-Heap 任务的堆外内存,默认0
                Network 网络缓存大小,总Flink使用内存的0.1
    JVM Metaspace 默认占用256M
    JVM Overhead  默认值1GB

注意:JVM Metaspace和Overhead也属于堆外内存

FrameWork Heap是Task Executor本身占用的堆内内存大小,不用于执行Task.
FrameWork Off-Heap是Task Executor保留的堆外内存大小.
Task Heap是专门用来执行Task的堆内内存.
Task Off-Heap是Task的堆外内存,在Flink程序中有调用Native方法,可以配置.
Managed Memory主要用于排序,哈希表和中间结果缓存,RocksDB的Backend.
Network Memory用于Task之间的数据交换.
JVM Metaspace是JVM的元数据空间大小
JVM Overhead是保留给JVM其他内存开销,GC,ThreadStack,code cache等.