Flink1.10-一些使用的记录

Flink1.10使用过程中的一些认知

关于TaskManager/Slot/JobMangaer的认知

上节说过，Flink的3种部署模式。我们选择了Flink on YARN。但是经常听小伙伴抱怨说job不稳定，崩溃，有时候提交任务失败等等；
所以，今天专门针对于基本概念重新认识一下Flink；

脚本

我们的脚本类似于下面这种。没有任何附加参数：

nohup bin/flink run -m yarn-cluster   -s hdfs:///flink/savepoints/savepoint-* -c *.* jars/**** test > Flink-RealtimeDAU.log 2>&1 &

运行到yarn中之后的效果：

下面这3个，使用了2个Containers，Allocated Memory是4G的就是了。
但是，我们的Job很简单，而且也不存在大量的内存计算一说，所以，这个很显然比较浪费。

于是先从Yarn入手，这个Container是干啥的？可以有多少个？

在linux服务器节点上，可直接通过如下命令查看相关配置：
	• 查看物理CPU个数
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l
	• 查看每个物理CPU中core的个数(即核数)
cat /proc/cpuinfo| grep "cpu cores"| uniq
	• 查看逻辑CPU的个数
cat /proc/cpuinfo| grep "processor"| wc -l

在申请/分配/启动container时，如果单个container申请资源4G，1core，则单节点只能分配 max(128/4,16/1)=16个container 引起半数（128-16*4）的内存浪费
yarn引入了Vcore的概念作为对cpu core的逻辑封装，将节点的"设置"为32 Vcore（由于这里不是真正的Core，因此使用Vcore这个名字，通常Vcore的个数赢设置为cpu core总数的1-5倍），在申请/分配/启动container时，使用Vcore代替core，单container申请资源为4，1Vcore， 则单节点可以分配max(128/4,32/1)=32个container，则不造成资源的浪费
节点资源	管理/分配资源的单位	container申请资源	可启动container数目	container使用资源	无法真正管理的资源的资源
128G，16 Core	内存，core	4G，1Core	min(128/4,16/1)=16	64 G，16Core	64G，0Core
128G，32V Core	内存，Vcore	4G，1VCore	min(128/4,32/1)=32	128 G，32 Vcore	0G，0Vcore


32G，16Core  可启动的container（32/4，16/1） = 8；

可以看到，是于内存和CPU有关系的。我们的服务器配置1C，16核，24G内存，所以，有48个vCore还是可以的；

yarn.nodemanager.resource.memory-mb
集群中某个计算节点分配给nodemanager的最大可用内存，这个最大可用内存不是该节点最大内存，而是该节点最大内存划分出来的给nodemanager使用的内存，
yarn.nodemanager.vmem-pmem-ratio
	• 虚拟内存的比例，默认是2.1，即每使用1G物理内存，分配2.1的虚
arn.scheduler.minimum-allocation-mb
这个配置时用来指定单个容器(container)可申请的最小内存资源，
如果申请的内存资源小于这个配置项的值，则按最小值分配。（有的商业版禁止申请小于这个值的内存资源）
这个配置是会影响到单个节点上container个数的，所以比较重要。有下面的经验推荐值：
Total RAM per Node	Recommended Minimum Container Size
Less than 4 GB	256 MB
Between 4 GB and 8 GB	512 MB
Between 8 GB and 24 GB	1024 MB
Above 24 GB	2048 MB
参考来自：https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.6.0/bk_installing_manually_book/content/rpm-chap1-11.html
注：但毕竟是推荐值，其实还是要根据实际情况，比如说这个推荐值的前提是计算节点就是计算节点，跑的其他进程少，可以这么干，像我们这次是单节点，整个集群所有服务都在一个节点上，即使是8G，也肯定不能用1024，512都有压力…

 yarn.scheduler.maximum-allocation-mb
单个容器(container)可申请的最大内存资源，应用在运行时申请的内存不能超过这个配置项值，
因为这个配置项是指定一个container最大的内存，实际分配内存时并不是按照这个配置项分配，所以这个配置项可以配置成和nodemanager的可用内存(yarn.nodemanager.resource.memory-mb)一样即可，这样的话，意味着只要这个节点的nodemanager可用内存哪怕只够跑一个container，这个container也是可以启动的。
如果这个参数配置的比nodemanager的可用内存(yarn.nodemanager.resource.memory-mb)小，那么可能出现这个节点总内存即使足够提供所需内存的，但却无法启动container的情况。

既然container没有问题，那么Flink如何优化呢？降低资源的使用率：

taskManager是用来管理slot的，如果我们的服务并行度比较高，就需要更多的taskmanager，同时也会占用更多的yarn容器。所以，目前，根据资源的情况，设置成1个是一种比较好的做法，我们目前的项目并没有太多并行度很高的需求。

https://www.jianshu.com/p/b58988bcfb48

https://www.jianshu.com/p/aa00be723f23
注意： Per job模式提交作业时并不像session模式能够指定拉起多少个TaskManager，TaskManager的数量是在提交作业时根据并发度动态计算。
首先，根据设定的operator的最大并发度计算，例如，如果作业中operator的最大并发度为10，则 Parallelism/numberOfTaskSlots为向YARN申请的TaskManager数。
例如：如下作业，Parallelism为10，numberOfTaskSlots为1，则TaskManager为10。


https://blog.csdn.net/qq_31866793/article/details/99778158

就是每次提交Flink任务都会创建一个新的Flink集群，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。（生产推荐使用，比较灵活）
nohup bin/flink run -m yarn-cluster -yn 7  -s hdfs:///flink/savepoints/savepoint-* -c *.* jars/**** test > Flink-RealtimeDAU.log 2>&1 &

其中的-yn是指TaskManager的个数，必须指定。

比较关键的几个参数：yn，yjm，ytm

参考这个博客里的操作方式：