【大数据之路】数据管理篇 《二》计算管理 【搬运小结】

【大数据之路】数据管理篇 《二》计算管理

每天存储资源、计算资源消耗都很大。如何降低计算资源的消耗，提高任务执行的性能，提升任务产出的时间，是计算平台和ETL开发工程师孜孜追求的目标。

1 系统优化

HBO (History-Based Optimizer,基于历史的优化器）。在任务稳定的情况下，基于任务的历史执行情况进行资源评估。
CBO (Cost-Based Optimizer,基于代价的优化器）。Oracle的CBO,会根据收集到的表、分区、索引等统计信息来计算每种执行方式的代价(Cost) ,进而选择其中最优的执行方式。MaxCompute采用各种抽样统计算法，通过较少的资源获得大量的统计信息，基于先进的优化模型，具备了完善的CBO能力，与传统的大数据计算系统相比，性能提升明显。

1.1 HBO

HBO 是根据任务历史执行情况为任务分配更合理的资源，包括内
存、 CPU 以及 Instance 个数。HBO 是对集群资源分配的 种优化，概
括起来就是：任务执行历史＋集群状态信息＋优化规则→更优的
执行配置。
背景：
在默认的 Instance 算法下，小任务存在资源浪费，而大任务却资源不足。综上所述，需要有更合理的方法来进行资源分配，
HBO 应运而生。
HBO 的提出
通过数据分析，发现在系统中存在大量的周期性调度的脚本（物理计划稳定），且这些脚本的输入 般比较稳定，如果能对这部分脚本进行优化，那么对整个集群的计算资源的使用率将会得到显著提升。根据任务的执行历史为其分配更合理的计算资源，HBO一般通过自造应调整系统参数来达到控制计算资源的目的。

1.1.1 HBO原理

前提 ：最近7天内任务代码没有发生变更且任务运行4次。
Instance 分配逻辑：基础资源估算值＋加权资源估算值。
( 1 )基础资源数量的逻辑
Map Task ，系统需要初始化不同的输人数据量，根据期望的每个Map能处理的数据量，再结合用户提交任务的输入数据量，就可以估算出用户提交的任务所需要的Map数量。
Reduce Task，MaxCompute 使用最近7天Reduce对应Map的平均输出数据量作为Reduce 的输人数据量，用于计算Instance的数量。
( 2 )加权资源数量的逻辑
Map Task,系统需要初始化期望的每个Map能处理的数据量。通过该Map在最近一段时间内的平均处理速度与系统设定的期望值做比较，如果平均处理速度小于期望值，则按照同等比例对基础资源数量进行加权，估算出该Map的加权资源数量。
Reduce Task,方法同上。

1.1.2 HBO效果

（1） 提高CPU利用率
（2） 提高内存利用率
（3） 提高Instance并发数
（4） 降低执行时长

1.1.3 HBO改进与优化

数据量波动不大，工作良好。数据量暴涨的情况，HBO 计划就不适用了。
针对这个问题，HBO也增加了根据数据量动态调整 Instance数的功能，主要依据Map的数据量增长情况进行调整。

1.2 CBO

MaxCompute2.0引人了基于代价的优化器(CBO)，根据收集的统计信息来计算每种执行方式的代价，进而选择最优的执行方式。

1.2.1优化器原理

优化器有多个模块相互组合协调工作，包括Meta Manager（元数据）、Statistics（统计信息）、Rule set（优化规则集）、Volcano Planner core
〈1）Meta Manager
Meta模块主要提供元数据信息，包括表的元数据、统计信息元数据等。当优化器在选择计划时，需要根据元数据的一些信息进行优化。
（2） Statistics
Statistics主要是帮助优化器选择计划时，提供准确的统计信息，如表的count值、列的Distinct值、TOPN值等。优化器只有拥有准确的统计信息，才能计算出真正最优的计划。
（3） Rule Set
优化规则是根据不同情况选择不同的优化点，然后由优化器根据代价模型(cost Model)来选择启用哪些优化规则。
（4） Volcano Planner Core
Volcano Planner是整个优化器的灵魂，它会将所有信息(Meta信息、统计信息、规则）统一起来处理，然后根据代价模型的计算，获得一个最优计划。

1.2.2优化器新特性

优化器具有一些新特性，主要是重新排序Join (Join Reorder)和自动MapJoin（Auto MapJoin)。
重新排序Join,然后找到代价最小的一个排列。
自动 MapJoin充分利用优化器的代价模型进行估算，获得更优的MapJoin方式。

1.2.3优化器使用

对于重新排序Join和自动MapJoin,对应的标记分别是porj和hJ。 即如果想使用上述优化，则可以进行如下设置：
set odps.optimizer.cbo.rule.filter.white=pojr,hj;
注：优化规则之间请使用“，"分隔。

2 任务优化

2.1 Map倾斜

背景
（1）上游表文件的大小特别不均匀，并且小文件特别多，导致当前表
Map 端读取的数据分布不均匀，引起长尾。
（2） Map 端做聚合时，由于某些 Map Instance 读取文件的某个值特别
多而引起长尾，主要是指 Count Distinct 。
方案
（1）通过设置"set odps.sql. mapper.merge.limit.size=64"和
“ set odps.sql.mapper.split.size=256"两个参数来调节，其中第一个参数用于调节Map任务的Map Instance的个数；第二个参数用于调节单个Map Instance读取的小文件个数，防止由于小文件过多导致MapInstance读取的数据量很不均匀；两个参数配合调整。
（2）通过"distribute by rand()" 随机分布函数会将Map端分发后的数据重新按照随机值再进行一次分发。

2.2 Join倾斜

背景
Join Key相同的数据分发到同一个执行Instance上处理。如果某个 Key上的数据量比较大，则会导致该Instance执行时间较长。
方案
Join的某路输人比较小，可以采用MapJoin避免分发引起长尾。
Join的每路输人都较大，且长尾是空值导致的，可以将空值处理成随机值，避免聚集。
Join的每路输人都较大，且长尾是热点值导致的，可以对热点值和非热点值分别进行处理，再合并数据。

2.3 Reduce倾斜

背景
Reduce端负责的是对Map端梳理后的有序key-value键值对进行聚合，即进行count、sum、Avg等聚合操作，得到最终聚合的结果。
因为Distinct操作，数据无法在Map端的Shuffle阶段根据Group BY 先做一次聚合操作，以减少传输的数据量，而是将所有的数据都传输到 Reduce端，当key的数据分发不均匀时，就会导致Reduce端长尾。
（1）对同一个表按照维度对不同的列进行count Distinct操作，造成 Map端数据膨胀，从而使得下游的Join和Reduce出现链路上的长尾。
（2）Map端直接做聚合时出现key值分布不均匀，造成Reduce端长尾。
（3）动态分区数过多时可能造成小文件过多，从而引起Reduce端长尾。
（4）多个Distinct同时出现在一段SQL代码中时，数据会被分发多次，不仅会造成数据膨胀N倍，还会把长尾现象放大N倍。
方案
对于（2）热点key使用 通过"UnionAll"合并。
对于（3）使用 参数 set odps.sql reshuffle.dynam cpt=true;
如果目标分区数比较少闭这个功能：set Odps.sql.reshuffle.dynamicpt=false
对于（1），（4）目前Reduce端数据倾斜很多是由CountDistinct问题引起的，因此在ETL开发工作中应该予以重视CountDistinct问题，避免数据膨胀。对于一些表的Join阶段的Null值问题，应该对表的数据分布要有清楚的认识，在开发时解决这个问题。