.1、耗时卡点定位
先来看看这个让人头疼的慢节点，长什么样子 ？让我看看你是何方神圣 。
告辞告辞......
从DAG图怕是很难看出问题，还是先按照latency对各个节点做降序排列，看看到底是在什么地方耗时最多。
几个join任务都是时长杀手，动辄半小时以上。
接下来点进几个耗时top的join任务，有两个发现：
1、或多或少都有数据倾斜现象。
2、多个非倾斜节点运行时间也比较长（30min～1h不等）。
到此为止，我们可以给出初步结论：任务运行耗时过长，是数据倾斜 + join任务资源不足两个原因共同导致的。
2.2、快速止血方案
1、针对join任务资源不足：
提高join任务的资源分配
set odps.sql.joiner.instances = 6000; -- 从原来的2000个instances提到6000个
2、针对数据倾斜：
因为宽表代码中，主表是流量/成交/ipv等事实详单数据，join的右表都是标签类维表（主键唯一），所以可以判断倾斜一定是发生在左表上。对左表的关联key进行汇总统计。
按照用户id做汇总统计
倾斜热点主要是由空值带来的，这种情况比较好处理，直接对空值加随机值打散就好。
-- 原join关联代码select ...from ( select visitor_id, -- 用户id ... from 流量日志表 ) t1 left join t2 -- 标签维表on t1.visitor_id = t2.visitor_id
-- 加随机值打散joinselect ...from ( select coalesce(cast(user_id as string), concat('rand_saltvalue', substr(cast(rand() as string), 3, 5))) as visitor_id_salt, --空值用随机值填补 ... from 流量日志表 ) t1 left join t2 -- 标签维表on t1.visitor_id_salt = t2.visitor_id -- 避免Null值热点的影响
在完成这两步简单快速止血操作后，重跑任务可以发现，运行时间可以节省1h以上，已经初见成效了。但是只做到这些是远远不够的，想进一步提高产出效率，需要更深入地剖析代码，梳理可优化点。
三、代码结构梳理
3.1、主干链路梳理
想从DAG图里梳理清楚数据加工链路，已经是不现实的了，只能回到SQL代码里，看看实现了哪些逻辑，再来寻找切入点。我们忽略掉代码中关于指标加工/格式转化/字段拼接等部分，只看数据表的结构加工和数据流向，大概可以梳理出这样一条主干链路。
宽表任务主干链路
梳理清楚加工链路之后，可以看出来该任务整体上可以划分成两部分：
1、多张事实表的合并（union all），包括流量表/成交表/IPV表/互动点赞表等每日的活跃日志数据等。
2、合并后的事实表作为主表，依次关联（left join）不同维度的标签表，例如用户维表/商品维表/内容维表等。
3.2、存在问题
梳理完代码主干链路之后，可以看出来加工逻辑并不复杂，其实就是做了详单事实表和多张维度标签表的汇总拼接，产出一张字段较全的大宽表。接下来简单分析一下这个任务里存在哪些问题。
1、计算堆积
首先造成任务产出较晚的最直接的原因，就是计算堆积。该节点引用了不少外部空间视图，并且这些视图不是简单的 “select * from xxx;” 形式的的简单语句，而是包含了多张表进行join的逻辑。这就导致了，虽然视图相关的上游表早早就产出了，但视图DDL内包含的计算任务，却落到了该节点上，造成该节点计算量的堆积。
类似地，部分子查询中多表join的计算，也是同理。
2、数据倾斜
在定位耗时卡点的时候我们已经发现了空值带来的倾斜问题，并且做了加盐打散的方法来快速止血。但事实上，分析了多个日期分区的数据发现，除了空值以外，偶尔还会出现部分热点用户/热点主播/热点内容带来的数据倾斜（更要命的是，这些热点值每天都不相同）。虽然倾斜程度不如空值带来的影响严重，但仍然对计算任务造成了一定阻塞。
3、回刷成本高昂
除了上面两个比较明显的问题以外，我们翻看该节点的历史发布记录，可以发现140多个发布版本，有至少一半以上的变更内容是和埋点参数解析相关的。针对埋点解析正确性的验证，往往需要补数据回刷确认，单一节点动辄6、7个小时的回刷成本，给数据验证也带来了不小的麻烦。
四、优化方案
明确了任务中存在的问题，我们的优化目标就非常清晰了：
1、提早产出：越早越好
2、回刷方便：越快越好
3、节省资源：越少越好
