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的使用。
暂时也就想到以上几点，看起来简单，但是能将每一点使用到极致，却是件很难的事情！
