DataStage：DataStage Job优化指导原则（不定时更新中）

使用DataStage也有一段时间了，在实际工作中也经常从同事处零星的获取一些优化技巧，网上也能找到一些Job优化的小技巧点。但总觉得没有一篇相对有水平且完整的从方法论的高度阐述Job优化的文章。本文根据本人长期的DataStage开发实际经验，从Job优化的方法论的指导原则的角度，阐述一些自己的愚见。希望能对奋斗在DataStage Job开发一线的朋友们有一定的实际帮助。另外由于实际能力所限，可能无法一次将所有要点一一罗列完整、准确，所以本文会持续更新、完善，还望理解。
DataStage Job优化指导原则之一：算法的优化。
任何程序的优化，第一点首先都是算法的优化。当然这一点并不仅仅局限于计算机程序的优化，实际生活中也处处可以体现这一点。条条大路通罗马，完成任何一件事，也同样有很多种方法。而方法当然有优有劣，有低效有高效。所以想提高完成任何一件事的效率，首先就是做事方法的优化。体现在计算机程序中，也就是算法的优化。也只有算法的优化，才可能使做事的效率有十倍、百倍，甚至上万倍的提升。
但是是在实际的Job开发过程中，绝大部分人都会忽略这一点。原因很简单，绝大部分人都认为Job开发是一种很低级的工作，最常用的Stage可能也就不到10种，熟练使用了这10种Stage不怕Job开发不好。的确，Job实际开发过程中，也许只会用到不超过10种Stage。最重要的无外乎ORACLE Stage、Lookup Stage、Join Stage、Transformer Stage等。但是，如何在适合的场景使用合适的Stage，如何平衡DataStage与数据库的负载均衡，如何确定与哪些表做关联，以及与这些表关联的顺序怎样才是最做优的等等，都是需要考虑的问题。开发一个JOB完成需求的功能并不难，难的是如何以更少的资源消耗，更有效率的完成需求指定的功能。
DataStage Job优化指导原则之二：尽量减少DS需要处理的数据量。
这一点，简单来说，主要指两点。一是尽量减少从数据库抽取至DS临时缓冲区的数据量（包括数据记录条数和数据字节数）；二是尽量避免在DS内部处理过程中，产生一些不必要的数据处理。
但是说起来容易，做起来难！随便打开一个JOB，80%的可能都会存在上述说的一个或两个问题。
首先对于第一点，经常发现JOB从数据源抽取了几十万甚至上百万的数据至DS，紧跟着跟一个小表（20W以内数据量）做内关联，关联之后的数据，可能只有从数据源抽取数据的三分之一甚至十分之一。那为什么不考虑将这两张表的内关联使用SQL在数据库中完成呢？这样做明显可以减少从源表抽取数据的数据量，减少了数据抽取至DS的时间，减少了DS服务器临时缓冲区空间的使用。
其次对于第二点，很典型的一个就是对Remove Duplicate Stage的使用。个人认为，所有凡是使用到这个Stage的Job都应该去认真仔细的检查一下，到底是不是真的有必要使用该Stage来完成数据的去重。首先该Stage的效率相当低下不说，重复的数据从何而来呢？是从源表抽取的时候，源表有数据重复？还是在Job处理过程中，通过关联导致数据重复？不管是哪一种重复，都应当从源头上避免将重复的数据抽取至DS中做处理。
DataStage Job优化指导原则之三：尽量减少使用的Stage数量。
在DS8.5中，Job运行时，会将每一个Stage对应生成一个线程或进程去处理。当大批量高并发的运行Job时，系统需要处理的线程或进程太多。
DataStage Job优化指导原则之四：尽量平衡DS服务器与数据库服务器的处理负担。
两张表或多张表关联时，是在DS服务器中完成呢，还是在数据库服务器中完成呢，这就需要根据DS服务器和数据库服务器的性能进行平衡。另外对于一些太复杂的多表关联，也可拆分，以便将数据抽取至DS中进行关联运算。
DataStage Job优化指导原则之五：充分发挥各Stage的长处。
每一种Stage都有其存在的合理性，否则IBM的工程师们何必大费周章的为DS开发如此多的Stage呢？
但是是不是所有的Stage都物尽其用了呢？实际也许未必。例如有多少人使用过Lookup Stage和一张小表做内关联呢？咦！Lookup Stage还能实现内关联？对，他真的可以！Lookup Stage能像Join Stage关联时那样，当关联的右表有重复时，关联出多条数据来呢？Lookup Stage真的可以！
DataStage Job优化指导原则之六：尽量使用更高效的Stage以及尽量减少低效Stage的使用。
当然这一点要看具体实现的功能。比如Lookup Stage和Join Stage应该使用哪个呢？因为Lookup Stage会将右表全部装入内存，所以在处理效率上要比Join Stage快的多。但是当关联的右表为大表时，将整张表的数据放入内存可能会占用大量的内存空间，甚至会导致内存不够用而Job运行失败。何为大表，何为小表呢，这就是一个经验值，不是一成不变的。当服务器的内存足够大时，1000W的数据量放入内存，也只是占据了内存空间的九牛一毛时，1000W的表也是小表。我们项目组使用的临界值是100W，右表超过100W的，尽量使用Join Stage。
另外像上面提到的Remove Duplicate Stage，就是一个相当低效的Stage，应当减少类似低效Stage的使用。
暂时也就想到以上几点，看起来简单，但是能将每一点使用到极致，却是件很难的事情！

DataStage：DataStage Job优化指导原则（不定时更新中）相关推荐

Uncertainty Modeling and Optimization-不确定性建模与优化-理论篇（高速更新中）
Uncertainty Modeling and Optimization-不确定性建模与优化目录 Uncertainty Modeling and Optimization-不确定性建模与优化 0 ...
网站正在建设中_网站建设中图像优化指导原则
作为专业的网页设计公司,深圳新龙始终追求为客户制作高性能高转化适合SEO的营销型网站.优化图像通常可以减少从网站下载的字节数并提高网站性能.那么新龙如何处理网站建设中的图像呢? 下面讨论我们对待网站图 ...
SQL优化建议（不定时更新添加）
1.临时表和非日志表的存储方式建议和基表相同.当基表为行存(列存)表时,临时表和非日志表也推荐创建为行存(列存)表,可以避免行列混合关联带来的高计算代价. 2.索引字段的总长度不超过50字节.否则,索 ...
C++设计原则——开闭原则（持续更新中）
系列文章目录 C++开闭原则 C++迪米特法则文章目录系列文章目录前言一.开闭原则到底有什么用? 二.开闭原则有什么特点前言在一个新人刚入编程这一行的时候,可能在正式参加到一个项目之前跟着 ...
mysql小结果集驱动大结果集_具体优化查询语句的指导原则小结果集驱动大结果集避免子查询...
原标题:具体优化查询语句的指导原则小结果集驱动大结果集避免子查询具体优化Query语句的指导原则 (1)多使用Profile:(2)永远用小结果集驱动大的结果集:(3)尽可能在索引中完成排序:(4) ...
[最佳实践]敏捷回顾活动“最高指导原则”
只有做好敏捷回顾,才能不断地改进,实现正反馈,如何做呢?不妨看看国外大师们.... 敏捷回顾活动"最高指导原则"的辩论设想邀请几位善于思考的聪明才智之士一起坐下来,一边喝茶一边讨 ...
医疗检测机构能力建设指导原则
一.编制目的医疗器械检验检测体系是医疗器械监管体系的重要组成部分.为加强医疗器械检验检测体系建设,提升医疗器械检验检测能力,根据<医疗器械监督管理条例>(国务院令第680号).<国 ...
皇室战争服务器维护,皇室战争问题修复与优化于10月17日强制更新中实装
皇室战争10月17日进行强制性更新,18点维护结束.这次维护对一些问题进行修复与优化,那么本次强制性更新中实装的问题与优化到底有哪些呢?今天小编就为大家带来这次优化的具体内容. 问题修复及优化 •进一 ...
Hadoop-Impala优化十大指导原则和最佳实践
1.1 Hadoop-Impala优化十大指导原则和最佳实践以下是性能准则和最佳做法.您可以使用在规划过程中实验,和hadoop集群一起进行impala的性能调整.所有这些信息也可在文档的其他地方 ...

DataStage：DataStage Job优化指导原则（不定时更新中）

DataStage：DataStage Job优化指导原则（不定时更新中）相关推荐

最新文章

热门文章