摘要：关于阿里云大数据数仓建造功用优化而言，首要可以从调度优化、模型优化、同步优化以及使命优化这四个方面着手。其实，关于功用优化而言，终究仍是会归结到“资源”之上，所以资源是否满意，分配是否合理也是咱们在进行功用优化时有必要考虑的要害所在。
本文将首要环绕以下四个方面进行介绍：调度优化、模型优化、同步优化以及使命优化。关于调度优化而言，将共享使命调度怎么进行优化，以及怎么看到调度的瓶颈点，以及在开端进行建造和运用数据仓库的使命之后，关于使命怎么进行调整来满意事务的时刻要求。关于模型优化而言，首要包含一些优化相关的主意、主张以及技能的优化点。关于数据同步优化而言，也是我们在建造数据仓库的过程中常常遇到的问题，也就是将数据从其他数据库同步过来或许向其他数据库进行数据同步的时分，常常会遇到一些像某些使命运转过慢或许影响其他使命的状况。关于使命优化而言，首要指的是核算使命，也可以了解为MaxCompute的SQL使命，这部分将与我们共享怎么去优化这部分的使命。
一、调度优化
在数据仓库建造的过程中，我们都会需求跑一些使命，那么这些使命怎么进行装备才会是最优的呢？假如呈现了瓶颈点或许事务第二天所需求的数据并没有给到，那么很大一部分的状况需求从调度方面来考虑，是不是有些使命的时刻点设置的不合理？或许是不是有些使命的优先级设置的不合理？这些可能是在调度层面，我们需求优先考虑的一个点。
调度优化方法
调度优化的首要方法如下图所示，依照道理前三点应该在规划初期提早想到或许提早规划好的。而现在大部分客户仍是用了一段时刻的数据仓库的时分，才发现存在一些问题，当第二天需求出报表的时分才想到去优化这些点。
第一点就是关于大使命而言，需求将其预订处理的时刻提早，这儿的大使命也就是耗时比较长的使命，假如使命已经在跑了，那么很好评价，在DataWorks里边可以看到哪些使命跑得慢。此外还有一个评价方法就是在第一次树立数仓的时分，表的数据量很大那么也必定是大使命。关于这些大使命而言，需求将其守时的时刻提早，也就是将其优先级提早。第二点就是将要害节点的守时时刻提早，这儿所谓的要害节点并不是说其数据量大，而是事务很重要的使命。第三点就是需求做到使命的阻隔，这儿首要指的是在运用DataWorks的时分会用到一些调度资源，不管是运转SQL也好仍是运转同步使命也好，这些使命都需求跑在DataWorks的调度资源里边，那么假如将这些使命都放在一个项目就会呈现问题，比方某个同步使命设置了10个并发，这样就占有了10多个调度资源，这样就可能将资源悉数占满了，这样就会导致其他使命需求等候，这儿不是指的MaxCompute资源不行，而是DataWorks的调度资源不行了。因而，一方面需求将开发和出产阻隔开，防止由于开发暂时启动了测验使命导致出产环境受到影响，因而要尽量将DataWorks里边的开发项目和出产项目分脱离。此外，假如出产项目也很大，可能就需求依照数仓的分层或许不同事务拆分红不同的项目，这也是防止资源呈现抢占，防止影响其他事务的一种方法。当然，这样的做法有利也有弊，由于这样做会使得杂乱度添加，关于企业而言，后续的运维本钱也会高一些，因而这需求看我们应该怎么评价，假如数据量到达了必定的规划其实可以分拆出来的，可是假如数据量不是很大，那么就可以先不考虑分拆。第四点就是削减使命层级的依靠，我们在进行调度的时分，都会在DataWorks里边看到依靠的上一层或许下流依靠哪一些使命，而使命相互依靠的层级应该是越少越好的，可是依照数仓分层，依靠至少需求三层，这三层依靠是必定存在的，除此之外还会有一些中心表，这样就会有四层或许五层，可是尽量不要呈现10层以上乃至20层的依靠，这样杂乱的使命依靠会使得后期去排查使命的依靠本钱升高。假如在数仓建造的初期或许建造的过程中发现了一些问题就可以从以上四个点出发进行考虑。
二、模型优化
关于模型优化而言，有必要要依照什么方法进行规划以及模型有必要是什么姿态的，其实没有一个定性的定论。这儿也仅仅给出一些主张和主意。
关于数仓的建模而言，其实可以分为3NF建模和维度建模等，而引荐运用维度建模方法，可以依照星型模型或许雪花型架构的方法去建模。3NF建模方法或许实体建模方法的运用型会差一点，在许多时分其功用也会差一点，可是3NF在许多时分都会防止数据的冗余，其扩展性会好一些。而维度建模会有必定的数据冗余，并且冗余程度会很高，可是关于上层运用者而言，其易用性要好许多，并且其查询的功用也会好许多，尽管可扩展性会稍微差一些，可是依然处于可接受的规模之内。之所以在MaxCompute这边引荐我们运用维度建模，是由于其特色之一就是会存在数据冗余，可是数据冗余关于MaxCompute这种离线数据仓库来说，存储本钱并不是很高，由于其都归于SATA盘的存储，这样的存储本钱是很低的，而传统的数据仓库比方运用Oracle等其他的联系型数据库构建的数据仓库，我们往往会挑选3NF的建模方法，这是由于其数据冗余存储本钱会很高，磁盘很贵。
总归，在MaxCompute上引荐我们运用维度建模，运用星型建模或许雪花型建模的方法，这不管关于后续的运维仍是后续关于数据的运用而言，都是比较便当的，并且功用也会好一些。星型模型其实就是中心一个现实表，周边环绕着一堆维度表，其结构会简略一些，运用比较便利，功用也比较好；关于雪花模型而言，维度表可能还会持续相关其他的维度表，这种方法就是雪花模型，它会稍微比星型模型杂乱一些。其实星型模型也可以了解为较为简略的雪花模型。这儿引荐我们运用星型模型，当然假如事务十分杂乱，有必要要运用雪花型也可以运用。这是由于星型模型尽管有数据冗余，可是其结构比较简略，简略了解，并且运用起来只需求A传给B就可以了，不需求再相关一个C。
除了上述两个较大的要害点之外，还有一些值得注意的小点，比方中心表的运用，在这部分首要是将数仓分为三层，第一层做缓冲，第二层做整合，第三层做运用。可是并不是严格地只能分为三层，中心仍是会有一些中心表的，假如可以运用好中心表则会增强数仓的易用性以及全体的功用。其首要是在数仓的第二层里边，由于需求整合一些数据，可是整合之后的数据依旧是明细的，可能有几百亿乃至几千亿的量级，关于这些表而言，数据量往往很大，并且下流使命以及依靠于这个表的报表使命有许多，因而可以做一些轻度的汇总，也就是做一些公共的汇总的中心表，这样运用好了可以节省许多的核算量和本钱的。尽管主张我们运用中心表，可是也不主张运用太多的中心表，这仍是由于中心表越多，依靠的层级也会越多。
在某些状况下还需求进行拆表，比方某一个大表字段比较多，可是可能其间某两三个字段的产出比较慢，产出很慢可能是由于其加工逻辑很杂乱或许数据量比较大导致的，而其他字段产出却是很快的，此刻就可以将数据表拆开，将过慢的字段拆出来，并将本来正常的字段留在本来的表，这样就可以防止由于两个过慢的字段影响其他事务，拆表的场景尽管比较常见，可是可能不会在数仓建造初期就呈现。
还有一种场景及就是合表，这与拆表是相对的，当我们运用数仓一段时刻之后会发现A事务部门出了一些表，B事务部门也出了一些表，而这些表或许数据可能是堆叠的，也可能事务意义是相同的，只不过字段不相同。关于这些表而言是可以进行兼并的，由于在兼并之后可以做全体批量加工的SQL，这样要比多个表批量加工的SQL杂乱度要低许多，并且功用要好许多。关于分区的场景而言，也要合理地设置MaxCompute的分区。
此外还有拉链算法，这在传统数仓里边也会用到，我们往往会需求运用拉链算法来记载前史改动状况。而拉链算法会使得核算本钱变得比较高，尤其在MaxCompute里边或许离线数仓Hive里边，这是由于其没有Update的操作，因而需求遍历全表，需求比照昨日的全量和今日的增量，乃至是比较昨日的全量和今日的全量，才干得到所想要的拉链算法的成果，这样的核算本钱关于MaxCompute而言要高许多。假如数据量不大，每天做全量的拉链算法也是没有问题的，只需求考虑保存多久前史数据的问题。而实际上，有些事务不会关怀这些前史数据的改动问题，关于这样的事务其实可以只保存最近多少天的前史数据就可以了。其实是由于MaxCompute这边的数据存储本钱很低，假如不运用拉链算法，那么就意味着数据冗余会高许多，所以其实我们可以核算一下每天增量数据的存储本钱有多少，再比照一下数据的核算本钱，依据自己的事务进行均衡。可是假如每天增量数据到达百亿这种等级，保存全量数据必定是不现实的，那么就仍是去做拉链算法。
模型优化-合理规区分区
MaxCompute分区的功用必定要合理运用，这关于功用会发生很大的影响，一级分区一般都是依照天区分的，主张我们一天一个增量或许一天一个全量来做。二级分区的挑选反而会多一些，首要我们可以挑选是否树立二级分区，其次我们可以挑选二级分区的树立方法。二级分区比较适合于在where句子中常常运用到的字段，并且这个字段应该是可枚举的，比方“男”和“女”这样的。这儿还有一个条件，就是假如这个字段的值的散布是十分不均匀的，那么就不太主张做二级分区。
如下图中的比方所示，登录表每天会有9个亿的数据，而其间的一个字段是“是否登录成功”，成功可能有4亿，失利可能有5亿，这就比较适合做二级分区，由于比较均衡。第二个比方是用户拜访表，每天新增20亿数据，其间一个字段是“页面拜访状况”，成功拜访“202”是18亿，而失利“203”只要0.5亿，其他就更少了，这样的字段就不适合做二级分区。在数量级不大的状况下，不主张做二级分区，由于几百万的数据在MaxCompute里边扫描起来也会很快，在数据量大了之后可以再考虑二级分区，由于MaxCompute自身关于分区有一个上限就是6万，也就是一级分区乘以二级分区的个数不能超越6万个。
三、同步使命优化
同步使命优化可以从下图所示的这样几个点进行考虑。正如下面的这张PPT中图所示。数据同步其实就是源库经过网络进入到DataWorks或许自定义的调度资源里，再从DataWorks里边同步到MaxCompute里边，或许反过来从MaxCompute同步到源库，可是不管怎么说同步就是分为这样的几个点：源库、网络1、DataWorks调度资源、网络2以及MaxCompute，呈现瓶颈的当地也就在这几部分中，假如同步使命运转缓慢，那么瓶颈点就只能呈现在这几个点中。最常见的状况就是从其他数据库向MaxCompute抽取数据，一般状况下的瓶颈点就在源库这部分，呈现问题我们可以优先在源库处寻觅。在网络层面，从DataWorks到MaxCompute之间的网络2我们一般不必关怀，由于这部分是由阿里云担任的，可是从源库到DataWorks调度的网络1这一段需求由用户自己确保，公网、内网和专线，不同的网络环境中同步的速度也是不相同的。
再回到同步优化的几个要害点，首要中心同步使命需求守时优先考虑，假如表的数据量比较大或许事务的优先级比较高，那么这些肯定需求提早考虑，由于假如这样的使命不提早，那么排在这以后面的使命就会受到影响。第二点就是网路关于同步功用的影响，公网、内网或许专线关于功用也会有必定的影响。第三点就是DataWorks调度资源关于同步使命的影响，我们在DataWorks里边进行同步都是运用默许的调度资源，假如同步使命设置的并发过高，就会导致某一个使命会影响其他使命，比方处理一百万数据启动了20个并发，显着这是没有必要的，可是这样就占掉了悉数的同步使命，导致后续运转SQL以及其他的同步使命都跑不起来了，这是由于DataWorks的调度资源不行了。所以数据同步的并发肯定不是越多越好的，当处理一两百万数据的时分，仅需求2到3个并发就满意了。此外，还有就是怎么判别源库和方针库哪个是瓶颈点。数据同步首要运用的是数据集成，当离线使命运转完结之后都会发生这样的一个日志，在日志的最后会显现开端时刻、结束时刻以及写入速度等。在图中有标红的两个点，别离是Task WaitWriterTime和Task WaitReaderTime。假如是从RDS往MaxCompute同步，那么Reader指的就是读取RDS等候的时刻，那Writer指的就是写入MaxCompute的等候的时刻，哪一边的时刻更长就意味着哪一边存在瓶颈点，假如读的方面时刻更长，那么就需求从RDS或许网络1下手，也就是经过两方面的时刻来判别瓶颈点终究在哪一部分。
核算使命优化
在核算使命优化部分部分，也只与我们共享在SQL部分开发者应该怎么进行优化。我们平常在进行数据处理、数据清洗、数据变换、数据加工等过程中都会运用到SQL。关于SQL的优化而言，首要会集在这样的两个大方面进行：削减数据输入和防止数据歪斜。削减数据输入是最中心的一点，假如数据输入量太大，包含许多无效的数据，那么就会占用许多的核算资源。而数据歪斜是在离线的数仓里边常常会遇到的，简直每个人都会遇到，数据歪斜也分为好几种，需求对应地进行优化。接下来就为我们翻开进行论说。
在正式翻开之前还需求解说一下LogView的用法，由于想要判别问题终究是由于什么导致都需求从剖析LogView下手。每一个SQL履行的时分都会发生一个LogView，如下图中的网址所示，我们可以直接在浏览器翻开，之后就能翻开汇总的页面，再翻开Detail就能看到如下图所示的明细页面。关于明细页面而言，首要需求重视左面的履行计划，也就是分为了多少个Map、Reduce以及Join节点。其次需求重视TimeLine可以看到哪一个Map运转的时刻长，这是寻觅数据歪斜的依据。当点击每一个Map就能看到下面的明细，比方某一个Map有10个节点在跑，那么就会有10个点。关于明细而言，要点需求重视的也是TimeLine，需求重视在分红10个的节点里边，终究哪一个跑得快，哪一个跑得慢。下图中就存在显着的歪斜，也就是0号节点跑得很慢，而其他的节点跑得就比较快，这样就是一个十分显着Map阶段的歪斜。而运用Long-Task则可以快速定位到跑得慢的节点，协助进行快速定位。
当然现在也有了比较好用的东西——MaxCompute Studio，其关于LogView的支撑愈加强壮。在这儿面可以直接将方才的网址张贴过来，也可以直接衔接MaxCompute的项目找到Instance，然后直接点击Instance检查其履行日志，乃至可以将LogView保存在本地或许在本地翻开，而网页版别过期之后就无法翻开了。MaxCompute Studio最好用的当地在于其时序图功用，时序图可以列出某一个时刻段，哪一个节点跑得快，哪一个节点跑得慢，做一个全体地罗列出来，愈加便利地定位到Map、Reduce以及里边小的节点。还有一个剖析功用，可以直接为用户供给成果，提示用户哪一个节点跑得慢，哪里呈现长尾等问题。
分区的合理运用
前面叙述了分区应该怎么规划，这儿侧重解说分区应该怎么运用。假如表存在一级分区，那么将分区的挑选放到了条件里边就是一种过错的写法，有可能导致全表扫描。最好的写法就是像下图右侧所示的相同，把Table1的PT先进行挑选做一个子查询，再把Table2的也做一个分区先挑选了作为t2，之后将它们两个Join在一同再加上一个where条件，这样就能防止全表扫描。关于PT而言，假如运用了体系自带的函数，应该会做分区裁剪，而假如运用了自定义的函数关于PT进行加工，并放到了where条件里就有可能导致全表扫描，而现在DataWorks里边也会有体系提示，也便于我们进行判别。
多路输入
在MaxCompute里边支撑多路输入，可以读取一个表的数据并将其一同写入到两个当地，这样就确保了只做了一次查询，而可以直接生成两个成果表。下图是一个电商的比方，大约就是在出售订单表里边有卖家和买家，别离核算了卖家和买家的数量别离是多少，曾经可能需求拆分红两个SQL，而现在可以用一个SQL一同核算两者的数量，只需求读取一次原表就可以了，既可以节省时刻，也可以节省本钱。
慎用SELECT*
由于MaxCompute里边是列式存储，所以同一列的数据都是存储在一同的，乃至于由于列内容类似都会有一些紧缩算法在里边。而SELECT*查询全列与直接查询两个字段的功用距离是十分大的，所以作为数据开发的标准，不管数据量巨细都必定不要运用SELECT*就好了。
先过滤JOIN，REDUCE，UDF
还有一个削减数据量的方法就是在运用Join、Reduce或许UDF的时分，先做过滤在做详细的核算或许Join。
合表
合表也是削减数据输入的一种方法，它其实是从事务的视点切入考虑的。比方有一个事务别离用到了T1和T2的两列，别的一个事务别离用到了T1和T3的两列，而这两个事务其实是可以兼并到一同的，可是却放到了两个表，而这样就可以将这两个表兼并到一同，这样只做一次核算就完结了。
Map歪斜
在LogView里边有一个Map的时序，可以看到每个Map里边有多少个Instance，里边的哪一个耗时比较长就是发生了数据歪斜。相同的，在LogView里边也能找到Map的均匀履行时刻以及最大履行时刻，假如两者相差很大，那么必定呈现了歪斜。关于这样的问题，从事务层面进行处理一般是修正上游数据，让上游依照均衡的KV值进行从头散布。假如事务层面无法躲避，那么可以调整Map的个数，也就是加大Map的核算节点，在默许状况下是每256M数据切一个节点，可以将其调小，也就加大了Map处理节点的个数，使得数据分割得愈加均匀一些。
Join歪斜
Join阶段的歪斜也是比较常见的，这一现象的发现与Map歪斜根本相同，也是可以经过LogView判别。可是其处理计划却需求分为几种状况进行处理：
-状况1：假如为大表与小表（加载到内存不超越512M)，则对小表加MAPJOIN HINT
-状况2：两个大表Join，KEY值呈现数据歪斜，歪斜值为NULL，则需对NULL进行随时值处理
-状况3：两个大表Join，可以尽量先去重后再Join
-状况4：两个大表Join，事务层面考虑优化，检查事务的必要性
下图展示的是Join歪斜的几个详细比方，可以剖析详细形成歪斜的状况做出相应的处理。
Reduce歪斜
Reduce歪斜现象的检查方法和前面的Map以及Join检查的方法相同，可以从TimeLine看到。可能的状况首要有以下四种：
-状况1：GROUP BY 某个KEY歪斜严峻（1. 是否可以过滤 2. 写法改动，见图）
-状况2：DISTINCT引起的歪斜（打标+GROUPBY)
-状况3：动态分区引起的歪斜，尽量防止运用动态分区
-状况4：窗口函数引起的歪斜，尽量防止运用窗口函数，要视详细状况而定
Reduce歪斜-DISTINCT
假如是由于DISTINCT形成的数据歪斜，有一种处理方法就是打标+GROUPBY，比方在下图的比方中就是关于求IP段，求美国IP段、我国IP段以及总的IP段一共有多少个，左面这种图简略的写法，当呈现IP Key的歪斜就会使得作业比较慢，那么就可以将其打散，先求解这条ID的记载是美国的仍是我国的，在子查询里先做这一步，在外面再去求解总的Count或许Sum，从本来Map-Reduce两个阶段的处理改成了Map-Reduce-Reduce三个阶段处理，这种计划也能处理数据歪斜问题。
总结一下，功用调优归根到底仍是资源不行了或许资源运用的不合理，或许是由于使命分配的欠好，使得某些资源分配和运用不合理。我们需求依据本文的内容考虑怎么将自己的使命打散，确保使命在规则的时刻内可以履行结束，一同可以确保本钱的节省。当然了，我们不只需求考虑MaxCompute的核算资源，也需求考虑DataWorks的调度资源，所以功用优化终究仍是在和资源作斗争，看资源是否满意，分配是否合理。
作者：萌萌怪兽
本文为云栖社区原创内容，未经答应不得转载。
