当前位置:   article > 正文

DataStage:DataStage Job优化指导原则(不定时更新中)_datastage无法改名job

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的使用。
        暂时也就想到以上几点,看起来简单,但是能将每一点使用到极致,却是件很难的事情!
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/神奇cpp/article/detail/755763
推荐阅读
相关标签
  

闽ICP备14008679号