所以-当tez选择要运行的Map器数量时，它会查看可以并行运行的容器数量（可用插槽）、波形因子、数据的机架位置、fileinputformat最大拆分大小、tez最大分组大小、可以进入拆分的条带，要获取的列的未压缩总数据大小等—它不查看tez容器大小。
因此，计算Map器的数量会得到每个Map器的输入狭缝长度字节数（在运行作业之前）。
但是-如何估计处理该输入拆分所需的总容器大小（内存）？
我知道所需的记忆将取决于
输入原始分割长度（字节）
压缩（百分比？）
将应用于记录的任何自定义项（可能可以忽略不计）
矢量化（如果使用）（布尔值）
Map连接（如果需要）（布尔）
如果需要排序（布尔值）
写入磁盘前使用的缓冲区（百分比？）
但是-如何根据输入拆分字节估计容器大小，或者更确切地说是容器内所需的堆空间？
一种方法是在一次运行后查看Map程序任务的提交堆字节。
但是，是否有任何公式可以根据上述因素或任何其他因素从输入\u split \u length \u字节估算提交的\u heap \u字节？
1条答案
按热度按时间7kqas0il1#
我不认为每个Map器的输入分割长度直接影响tez容器的大小。这只是意味着分割将由一个Map器处理，但并不意味着整个分割将立即加载到内存中。因此分割长度可能比运行Map器的tez容器大得多。
作为一般准则，
将tez容器大小设置为与yarn容器大小yarn.scheduler.minimum-allocation-mb相同或小的倍数（1或2倍），但不能超过yarn.scheduler.maximum-allocation-mb。你想要有足够的空间让多个容器旋转起来。
详见本文件。