Datastage效能優化

2021-08-21 02:43:59 字數 2528 閱讀 6974

1,sql自身的優化:調優,並行處理

2,stage的拆分與合併:實踐測試為準

如多個join的stage雙方都為大數量(幾百萬一般大於200w)則考慮合併。如大表但join的資料不大就不用合併。

如乙個stage中的兩個表都為大表且關聯很慢時考慮拆分為兩個stage作join(select後資料不大:小於40w)

3,選用合理的stage: 像sort,之類的盡量少用,在資料庫裡完成

4,大資料量(上千萬)上述方法都優化不明顯後 可考慮採用直接insert 語句 使用oracle後台處理,而非ds資源抽取插入。

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效能優化

state的拆分與合併 如兩個join的stage都為大數量 幾百萬 且主表是一樣的則考慮合併。如乙個stage中的兩個表都為大表且關聯很慢時考慮拆分為兩個stage作join。copy stage 在記憶體中操作的元件,建議1進多出用copy元件 tansformer stage 是內嵌的程式,一...

Datastage 許可權管理

乙個使用者id是分配套件角色可以登陸資訊伺服器日誌控制台。怎麼樣乙個使用者id是datastage的套房分配乙個元件的角色?如果使用者id是datastage的管理員分配的作用,那麼使用者將立即獲得datastage的管理員對所有專案的許可。如果使用者id被分配乙個datastage user 角色...

mysql效能優化 mysql效能優化

優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下,存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢,hash有利於精確查詢。btree用的更多一些。btree索引的常...