00:00
我们前面也聊到伏迪它本身有一个特性,就可以自动管理小文件是吧,也是它可以帮我们管理文件的大小跟数量,那么它也有相应的参数可以控制,第一个呢,呃,就是它会避免像查询引擎暴露小文件,自动处理文件大小,那这个时候呢,它我们不管是做insert还是assert时。它都可以将文件大小维护在一个指定的文件大小,那么注意啊,只有log文件的大小可以做到准确的,就你配多少就是最大多少,那PA的文件值是,呃,大概的啊,就是允许超过一点或者小于它这东西这只是一个估算值,行,我们具体看一下吧,啊,首先看一下刚才聊到的日志的固定大小,那是这个。这个参数啊,Log fire max size,那这个呢,是log fire的最大大小,在滚动到下一版本之前允许的最大大小,也就是说一个上限啊,我一次commit你最多就这么多嘛,对不对啊。
01:04
那么。而且log大家知道是可以追加的,对吧?啊,你追加最多也就追加到这么多啊,不能再高了啊,那这个单位默认是字节啊,是这么大的一串数字,那简单理解就是一个G啊,你除一下1024,再除1024,再除1024啊好,那这个一般呢,我们不用动啊,我只是列出来让大家知道一下啊,最大默认是一个G,但一般来讲我们都达不到一个G,因为其他条件会影响你怎么影响呢?来注意看第一个呢,是pack的文件大小。啊,最大呢是120兆。如果超过这个大小,就会往新的fire group去写了啊。就不会在在这个里面继续了啊,这个是控制的一个pocket大小,第二一个呢是log文件转成PA的一个比率啊。那这个比例默认是0.35。
02:04
那第二第三一个呢,这个是很关键的一个参数。这个就是什么呢?在写入时啊,忽底会尝试先追加已存在的小文件,是不是该测参数设置的小文件的大小阈值小于该参数的文件被认为是什么呢?小文件也就是说小于它就能够继续追加,我们前面一直聊过,说有呃分区分有没有索引,能不能追加是不是?那flink是有索引的,那应该是log都能追加,但这边参数是什么?Perfect啊,Perfect好,那还有一个呢?根据预估的。大小。就是一个数据,一条数据的大小啊,会根据历史的提交去估算这条数据的大小啊。如果之前的提交当中有一个单次写入超过small fire,就是这个大小。
03:03
就以前呢,单次写入有曾经有一次你比如比如说你限制是一兆啊,结果你上次提交当中,一次提交就提交了两兆的数据啊,如果出现这种情况。啊。那如果没有碰到这个条件,那么呢啊,它就会使用这个参数来估算啊,就是说如果你碰上了之前的限制,那就是什么啊,它是动态估算。动态估算。那否则就按照这个来啊。这个默认是1K啊,也就是说前面这几个参数共同决定了什么,对于pack的一些动呃影响,而且是一种估算值,估算值。好,那可能这个刚才说的不是很明白,我再总结一下这个啊,这个就是估算的数据大小,这个是我们填的,也就是说如果正常情况下就按照这个参数来,哎,我估算你一条是1K啊,或者你可以改这个参数,那么如果之前的提交当中有一次。
04:16
呃,一条数据的大小超过了小文件的限制啊,小文件限制,那么就不会再以这个参数为准了,而是由他自己来动态估算,能理解这个意思吧?啊,也就是说没有特别大的数据没有超过这个限制,那就一直按这个参数来估算啊。然后这个是log的限制行,那下面呢,我们建一张T4啊,我们改一下哎,比如说的最大大小我改成了什么,这个单位是字节对吧,大概就是10K啊10K,那么这个可追加的小文件限制我是5K,也就是说小于5K,咱们可以继续往里追加啊,小于5K可以追加啊,就这个意思来拷贝一下。之后呢,咱们还是五秒钟插入一次吧,啊,慢慢的来观察啊T4啊好行,那接下来就观察HDFS啊退出啊T4。
05:11
注意看它的文件大小啊。嗯。好,现在一下子就10K了啊,这个LOG1010一下子就10K了。20斤。30K你看。然后紧接着就生成第二次log,就不继续往里追加了啊。啊,第三次。好,接下来看八回的。呀,卡了。
06:07
那我们怎么看跟之前的区别呢?啊,那我们回忆一下这个参数啊,我们说因为我这个最大大小是不是设的10K啊啊,大家很明显可以看到已经这些趴都400多K了吧,肯定超过了呀。呃,但是我们这边说一个什么呢。他说呀,最大可写入的,而且它是一个估算值,如果超过这个大小,那么就会用新的fire group,新的fire group就是新的fire ID,对不对,那你看嘛,这些是不是都是新的fire ID。啊,这个什么B1,然后你看紧接着又是一个新的ID。对吧,再往后又是一个新的发ID,因为他每一次什么都超过了啊,都超过了。啊,这个就大家简单就是了解一下就可以了。
07:00
第一次的,嗯,第一次有一个重复,这个正常啊,这是第一次的,那再往后就不会再有重复了。诶,还是有重复啊。所以这个呢,可能也跟这个并发有关系啊,也可能是因为我们设的太小了。是的,太小了,你看这边还是有点变化,还是有有有个别还是会重复的。那我们看一下T3之前没有做限制的时候吧,它的PA都是长啥样,你看之前这个T3,呃就对比对比在哪呢?你看啊,它都是呃接近一两兆了,对吧,肯定没超过那个大小,那你看他们的fire ID怎么样?这些的都一样啊,同学们。能看到吧。这个就是最明显的区别了,确实有在控制对吧?所以如果你不想让它生成大量的新的fair group,呃,那么你这个大小max值啊,就不要设的特别低,像我刚才就设的特别低嘛,对不对啊,所以这个咱们要对比着来看,你看这些park全部都是同一个啊,全部都是同一个,那么你也可以把compassion,为了准确啊,你这边把这个compassion,呃,并发设为一啊,这样可能更明显一点啊。
08:31
这样子啊。好,反正现在我们是看到现象的,对不对啊,那这个5K的我们肯定永远看不到了,都是大于5K啊,这只是做一个演示。那最后呢,还有一个哈杜参数,我们简单说吧,从一二版本才支持啊,因为有一些场景就是你要跨哈杜集群提交执行。那你就希望说,诶,我当前这个是,比如说我是哈杜集群一,咱们这不是一个雅安session嘛,对不对啊,这是在用的HDFFS也好,用的雅安也好,是哈杜普集群一的,那如果你的公司里面还有另外一个哈杜普集群,对吧,那你现在比如说要往这里去写数据。
09:16
要往哈杜啊,这个集群上面写数据,不是服务器啊,是集群啊,哈杜和集群,那这个时候你那个地址肯定不一样嘛,对吧,但是你这个时候怎么去指定呢?诶它就支持了,你可以去指定哈杜ER点啊,然后呢,就是哈杜参数了,就是带一个前缀哈杜就可以了啊。那这个就没什么好演示的,就你有有这个场景,你就这么来用就可以了啊。
我来说两句