DataStage 的优化原则

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

时间: 2024-09-30 20:23:55

DataStage 的优化原则的相关文章

MySQL 索引优化原则

一.索引优化原则 1.最左前缀匹配原则,联合索引,mysql会从做向右匹配直到遇到范围查询(>.<.between.like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整. 2.=和in可以乱序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序,mysql的查询优化器会帮你优

js优化原则

首先,与其他语言不同,JS的效率很大程度是取决于JS engine的效率.除了引擎实现的优劣外,引擎自己也会为一些特殊的代码模式采取一些优化的策略.例如FF.Opera和Safari的JS引擎,都对字符串的拼接运算(+)做了特别优化.显然,要获得最大效率,就必须要了解引擎的脾气,尽量迎合引擎的口味.所以对于不同的引擎,所作的优化极有可能是背道而驰的. 而如果做跨浏览器的web编程,则最大的问题是在于IE6(JScript 5.6)!因为在不打hotfix的情况下,JScript引擎的垃圾回收的b

高效C#编码优化原则

本文汇总了高效C#编码常见的优化原则,对于进行C#程序设计来说有很大的参考借鉴作用.具体列出如下: 1.foreach VS for 语句 Foreach 要比for具有更好的执行效率 Foreach的平均花费时间只有for的30%.通过测试结果在for和foreach都可以使用的情况下,我们推荐使用效率更高的foreach 另外,用for写入数据时间大约是读取数据时间的10倍左右. 2.避免使用ArrayList ArrayList的性能低下任何对象添加到ArrayList中都要封箱为Syst

Flex内存泄露解决方法和内存释放优化原则

本文向大家简单介绍一下Flex内存泄露问题,主要包括Flex内存释放优化原则和Flex内存泄露解决方法两大部分内容,希望你会感兴趣. 作者:vipoyb来源:csdn.net|2010-07-29 14:08   你对Flex内存泄露的概念是否了解,这里和大家分享一下Flex内存释放优化原则和Flex内存泄露解决方法,希望本文的介绍能让你有所收获. Flex内存释放优化原则 1.被删除对象在外部的所有引用一定要被删除干净才能被系统当成垃圾回收处理掉: 2.父对象内部的子对象被外部其他对象引用了,

hbase表设计优化原则 ***** 生产环境中使用小结

2019/2/28 星期四 hbase表设计优化原则 https://www.cnblogs.com/qingyunzong/p/8696962.html表设计1.列簇设计 追求的原则是:在合理范围内能尽量少的减少列簇就尽量减少列簇. 最优设计是:将所有相关性很强的 key-value 都放在同一个列簇下,这样既能做到查询效率 最高,也能保持尽可能少的访问不同的磁盘文件. 以用户信息为例,可以将必须的基本信息存放在一个列族,而一些附加的额外信息可以放在 另一列族.2.RowKey 设计 HBas

数据库优化原则

最近数据库课程设计,我总结了一下数据库的优化方法,希望对有需要的人能有帮助: 1.对查询进行优化,尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from p where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from p where num=

SQL中的连接查询及其优化原则

连接查询是SQL的主要任务,只有很好的掌握了连接查询及其优化方法才算是掌握了SQL的精髓所在.最近在面试中遇到了有关连接查询的问题,感觉回答的不是很好,总结一下. 具体示例请参考:http://www.w3school.com.cn/sql/sql_join.asp 总结: 连接查询原理与代码优化:假如要对table1和table2两个表进行连接查询,则DBMS首先会在table1中找到第一个元组,然后从头开始扫描table2表,逐一查找与table1第一个元组相对应的table2的元组,找到后

(转)SQL优化原则

一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性. 在多数情况下,Oracle使用索

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.