走进大数据 ETL-性能分析

ETL过程中难免遇到性能问题,运行很慢是一件较常见的事情,遇到这些问题时,我们该如何分析,解决呢?首先我们要找到问题出在哪里,也就是系统的瓶颈在哪.

确定环境是否有瓶颈:检查资源是否有效配置,也就是要确定是由CPU、内存、I/O和网络等产生的瓶颈，还是由ETL处理过程产生的瓶颈。

根据数据特征,确定分区分桶:

分区字段选择:一般原则为根据系统的业务类型来分则分区字段。通常来讲事实表是数据都包含时间属性，而报表业务也多在一定的时间范围内做统计分析，那么根据时间字段进行分区是常用的选择。而如果业务更多按照部门做统计分析，那么更适合按照部门代码，地域代码进行分区。所以贴近业务的特点选择分区是第一要素。

分区个数:分区个数的选择需要综合考量数据的特性，在选择好分区字段后，我们需要根据数据的特点确定分区个数的可选择区间。分区个数不宜太少，需要根据业务特点来确定，并保证分区里面不会太多的冷热数据混合。譬如SQL业务大部分都是操作2~3个月的数据，那么我们就尽量按照3个月做一个分区，如果我们选择1年做一个分区的话，每个SQL业务实际执行的时候就会多读取前面9个月的数据，这这部分的资源和IO开销都是没有必要的。

实际情况中我们看到的更多的DDL设计都是分区数量过多，譬如单个分区的数据量不超过1GB，或者按照天来分区，这些都是不合适的设计。分区过多的坏处是会导致过多的系统资源占用。

分桶字段选择:一般遵循的原则为，选择离散度高的字段进行分桶。可以通过收集的数据特征，如Distinct Value来做参考，值越大的可以优先作为考虑对象。分桶字段选择时，注意尽量使记录分布均匀，避免数据倾斜。

分桶个数:针对不同的存储类型，分桶个数的标准稍微有所差别。以ORC表举例，对于普通ORC表，单分桶大小可以在200M以内；对于ORC事务表，标准适当降低，文件大小限制在100M以内，记录条数限制在几百万条左右。在考虑分桶个数的时候，同时要考虑是否已经分过区。对于已经分过区的表，要按照单区的大小和条数进行桶数的估计，而不是依照原始表。例如某运行商项目中，我们发现某些表进行分区分桶后，分桶数量过大，导致每个桶的文件大小仅仅为几十K，这样就会使单个Task的执行效率很低，同时总体任务数过大也对系统资源造成极大浪费，并发度上不去。调整方案是根据实际情况，将原桶数降低数量级。

依次分析抽取、计算、查找表、聚集、过滤、加载等环节的处理操作.

先将抽取部分隔离出来，去掉转换和交付，可以将数据直接抽取到文件中。如果这一步效率很差，基本确定是抽取SQL的问题。

针对全抽取，在ETL处理中进行过滤的处理方式而言。在ETL处理中做过滤处理有时会产生瓶颈。可以先将过滤去掉，如果确定为这个原因，可以考虑在抽取时进行数据过滤。

参照数据在ETL处理过程中通常会加载到内存中，目的是做代码和名称的查找替换，也称查找表。有时查找表的数据量过大也会产生瓶颈。可以逐个隔离查找表，来确定是否是这里出现问题。

排序和聚集操作都是非常费资源的操作。对这部分隔离，来判断是否因为它们引起性能问题。如果确定是因为这个，需要考虑是否可以将排序和聚集处理移出数据库和ETL工具，移到操作系统中来处理。

有时转换过程中的处理操作也会引起ETL工作的性能。逐步隔离移除它们来判断哪里出了问题。要注意观察像默认值、数据类型转换等操作。

更新操作在数据量非常大时是性能非常差的。隔离这部分，看看是否这里出了问题。如果确定是因为大批量更新出了性能问题。应该考虑将insert、update和delete分开处理。

如果前面各部分都没有问题，最后需要检测是目标数据库的性能问题。可以找个文件代替数据库，如果性能提高很多，需要仔细检测目标数据库的加载过程中的操作。例如是否关闭了所有的约束，关闭了所有的索引，是否使用了批量加载工具。如果性能还没有提高，可以考虑使用并行加载策略。

结合Task运行情况做监控帮助分析问题.

观察task数量是否存在Task数量过多或者过少的情况,这一般是有上面说的分区分通不合理导致的.

Task倾斜导致拖尾,一般是计算或聚集环节不当操作导致.

通过观察同时并发执行的stage数量确保执行的合理性.