00:00
那么我们使用flink写库的时候,有一些内存的参数可以调整啊,那么主要有这么几个,我们先看一下,第一个呢是right task,它的最大内存,最大可用内存默认只有一个G啊,这个单位是兆啊,那么在这当中又分为两块,就实际上写使用的内存缓冲啊,就等于这个参数值减去compassion,呃,最大的内存,也就是说right task的内存要分两块,一块是他自己用啊,它用来write的一个缓冲,第二个呢,就是compassion要用的啊,所以呢,我们前面也提到了,呃,最好呢,就不要用在线compassion,你看他这不就占用资源了嘛,对吧,又影响效率啊,那么。这是1G,那那个我们如果数据量大,流速很快呢,很高的话,我们这个可以调大一点,那另外一个有两个,一个是BAT size,一个是log block size啊那么fli在写的时候并不是说,诶我现在有一条我直接就往外写了,他会先干嘛呢啊,他写的时候会先攒一下,攒一下批啊,这个就是批次的大小二百56,那么他写的时候是,呃,有一个。
01:15
在buffer里面啊。那么看啊,呃,它会按照bucket,也就是说呃,按照一个一个的跟分筒一样的啊,提前呢,缓冲数据,缓冲数据那在达到阈值之前会阈值缓存在内存当中,也就是说在这里面啊,当达到了它的设定的阈值之后,它才会将把这些数据传递给下面的什么right。由write呢,由write写出器啊,它去执行一个写出操作啊。那这边这个二五六指的不是条数啊,是兆啊,我们不是说它会在缓冲区当中啊,它在这边是按照一个一个的bucket去缓存数据的啊,每一个小方框都是一个bucket,那每个bucket的大小是多少呢?啊,就是256兆啊,就这个意思,256兆啊,这就是8K的啊的阈值,那一般这个东西咱们也不用去调啊,256兆是官方建议比较合适的一个参数了啊。
02:22
那另外一个是log block,也就是说咱们在写出Mo就写出点log文件的时候啊,呃,他也不会说马上flash啊,这个bucket完事之后要要给他嘛,给他去写嘛,那他写的时候也不是直接写,他是以什么啊日志快为单位往磁盘刷写数据的啊。它也是有一个展的过程,它这个时候会将数据以序列化字节的形式缓存在write内部,你看又缓存了一次啊,也就是说什么呢?啊,前面先过来先,我这里有一个bucket对吧,当我bucket是256兆满了之后呢,哎,我传递给write去用了,那这个时后呢,由writer去写,Writer写的时候啊,呃,他这个时候如果是写日志的话,写log的话,他这边也是会什么,呃,按照一个一个的什么呢?Log。
03:16
Block也就是128兆啊,而且呢是序列化的啊,以以这个为单位诶刷一次,以这个为单位刷一次啊这样子,那这个一般也不用去调啊,也不用去调,那还有一个呢,是merge,这个主要是用在cow表的时候啊,因为我们要写实拷贝合并嘛,对吧,Mo不用嘛啊对不对,呃,Mo是读时合并啊,那他这个时候Co有增量,还有基本文件pack文件有一个默举啊,那默举的时候,呃,增量的数据会缓存在内存的map结构里啊,这个是关键啊,增量数据缓存在内存的map里,那这个map是可切分可以溢写的啊,不是切分是溢写啊,这map是可以溢写,也就是说最多让你占这么多,如果超过这个,那就溢写了啊,那这个默认呢,就是100兆啊,这个一般也不用调,官方也不不一般建议不用调,那还有一个是compassion使用的最大内存默认100兆啊。
04:16
那如果是在线压缩呃,建议资源够的话调大一点啊,你可以调成一个G啊,但是总体建议还是不要用在线压缩会好一点。好了,这个是内存的几个参数,呃,综合看下来就是写的时候诶有个整总体的内存上限,其次呢啊,会有一个什么batch缓存,呃,缓存完事之后呢,如果是会有一个log快缓存啊,对吧?啊梦也好,压缩也好,也有一定的内存配置啊,就这样子,这些是可以去调的啊。那么接下来讲讲如果针对不同表,我们可以怎么去优化我们的内存啊,首先如果是Mo表呢,建议将状态后端换成RODB,你不要用flink默认的那个哈希map,基于内存的状态后端那个就是所有的状态里边的数据啊都存在内存当中,那这样的话对资源比较吃紧啊,那RODB呢,它是基于内存加磁盘的啊,所以它可以支撑的量会更大一点,并且呢,咱们RODB可以什么增量check啊,也也可以很有效的优化咱们flink的性能。
05:28
另外的话,如果咱们使用内存,呃,在线compassion的话,这个最大内存调大一点啊,一直在强调可以调到一个G啊,因为这个确实比较吃资源啊。呃,另外我们就是关注前面提到的几个参数啊,比如说TM分配给每个task right task的内存,保证每一个能够达到我们所配置的上限,什么意思呢?我举个例子啊,如果说咱们这个task上线,我给到呃两个G吧,但是我一个TM啊,假设咱们是四个slot啊。
06:09
啊,就一个吧,一个来看吧,咱们就看一个,别管那个多的只有一个slot,呃,那那这个时候right task是不是也会在这个slot里面呢?啊,咱们假设变形度一来执行的话,那这个时候如果我TM只给到了一个G,你看看呃,如果了解flink内存模型,大家知道弗link内存分为堆内堆外,对吧?呃,堆内的有task内存,还有框架内存,堆外的有也有框架task,还有什么呢?网络还有托管的。啊,也就是说你分配给TM的内存不可能全部都给task使用,对吧?啊,就算你这个时候T给到两个G,其实啊,一个task他也占不到两个G能啊,他占不到啊。啊是那这个时候你这个上限就永远达不到了,这个天花板,就像什么你生活中说诶啊,你平时比如说你高中的时候啊,平时都是呃考的都是连一呃一本线都都都上不了啊结果呢,你说哎我定我的目标,我要上哈佛啊,我要上清华啊这个就是你的设置的参数啊最大上限,但实际上呢,啊,可能你永远达不到对吧。
07:19
当然咱们只是开玩笑啊啊,你看这里也有,呃,比如一个T内存给到四个G,跑了两个right啊,那每个right分到两个G对吧?啊。尽量预留点八分对吧,还有其他77788的那些有吃内存啊。另外呢,就是关注compassion的内存啊。就是你要注意这个内存跟并发之间啊,怎么去分配啊,也是一样,你不要让你配置的这个最大内存永远达不到啊,就是这个一些小事情而已。
08:00
那这个是刚才提过的啊,预留给每个task的内存,如果是Co,那就是merge啊,那如果是Mo,那就是compassion啊,减去compassion啊,好啊,总结起来,Mor的优化,一改状态后端,呃,用RODB,然后开增量,第二,注意咱们配置的内存上限啊,调大之后啊,要考虑一下每个task能不能说是不是说永远达不到这个上限,那就没有意义了,是不是啊,就这个意思啊。好,再往下cow一样的状态后端换掉。第二一个呢?呃,几个上限可以调大啊,那比如说right task调成两个G,呃,Me呢,调成一个G,因为大家知道它是写实合并。啊,写实拷贝并且合并这个时候还是对内存的要求还是相对高一点的啊,另外一样关注给每一个写的task的一个内存,保证他们能说咱们那个上限不是说永远达不到啊,那样也不合适啊,一样的道理啊。
09:06
那这边呢,这个其实我应该改成上面改成compassion吧,因为这边讲的是Co Mr嘛。这样就不会造成一个误解,好,那这些是官方的一些建议啊。
我来说两句