「集成架構」Talend ETL 性能調優寶典
- 2019 年 10 月 25 日
- 筆記
作為Talend的客戶成功架構師，我花了大量時間幫助客戶優化他們的數據集成任務——不管是在Talend數據集成平台還是大數據平台上。雖然大多數時候開發人員都有一個健壯的解決方案工具包來處理不同的性能調優場景，但我注意到一個常見的模式是，沒有定義良好的策略來解決性能問題的根本原因。有時沒有策略會修復一些直接的問題，但從長遠來看，相同的性能問題會重新出現，因為原始設計中的核心問題沒有得到解決。這就是為什麼我建議客戶使用結構化方法來調優數據集成任務的性能。擁有策略的一個關鍵好處是它是可重複的——不管您的數據集成任務是做什麼，它們是多麼簡單還是多麼複雜，以及作為集成的一部分而移動的數據量。
瓶頸在哪裡?
性能調優策略的第一步是確定瓶頸的來源。在設計的各個步驟中可能存在瓶頸。我們的目標不是同時解決所有的瓶頸，而是一次解決一個瓶頸。策略是首先確定最大的瓶頸，找出產生瓶頸的根本原因，找到解決方案並實現它。一旦實現了解決方案，我們就尋找下一個最大的瓶頸並解決它。我們不斷迭代所有的瓶頸，直到找到最優的解決方案。
這裡有一個例子來幫助你理解。您有一個Talend數據集成標準作業，它從Oracle OLTP數據庫中讀取數據，在tMap中進行轉換，並將其加載到Netezza數據倉庫中。
如果這個任務沒有達到你的性能要求，我的建議是把這個任務分成三個不同的部分:
- 從Oracle
- 在Talend中進行轉換
- 寫信給Netezza
上面列出的一個或多個任務可能會導致您的進程變慢。我們的目標是一次解決一個問題。找出瓶頸的一個簡單方法是創建三個測試Talend作業來複制一個Talend作業的功能。大概是這樣的:
1.作業1 -從Oracle讀取:該作業將使用tOracleInput從Oracle讀取，並使用tFileOutputDelimited寫入到Talend作業服務器的本地文件系統中的一個文件。運行此作業並捕獲吞吐量(行/秒)。如果吞吐量數字看起來不合理，那麼來自Oracle source的查詢就是瓶頸之一。
2. 作業2 -轉換:使用tFileInputDelimited讀取作業1中創建的文件，應用tMap轉換，然後使用tFileOutputDelimited將另一個文件寫到相同的本地文件系統中。吞吐量數字看起來如何?與作業1相比，它們是快得多還是慢得多，還是一樣?
3.向Netezza寫入:讀取在Job2中創建的文件，並將其加載到Netezza數據庫中，然後查看吞吐量。它們與工作1和工作2相比如何?
在運行這些作業時，您需要注意以下幾點:
- 首先，這些測試作業應該對本地文件系統進行讀寫操作——這是為了確保消除任何可能的網絡延遲。
- 第二件事—吞吐量(讀取/轉換/寫入數據的速率)—是比運行時間更準確的性能度量。我們的目標是減少運行時間，並通過在數據集成管道的每個階段增加吞吐量來解決這個問題。
讓我們假設這是運行我們的測試的結果:
Job
Description
Throughput
Job 1
Read from Oracle
20000 rows/sec
Job 2
tMap transformation
30000 rows/sec
Job 3
Write to Netezza
250 rows/sec
基於上面的場景，我們可以很容易地指出Netezza是我們場景中的瓶頸，因為它具有最低的吞吐量*。
如果結果如下所示，我們可以得出這樣的結論:從Oracle讀取和從Netezza寫入都存在瓶頸，我們需要同時解決這兩個問題*。
Job
Description
Throughput
Job 1
Read from Oracle
500 rows/sec
Job 2
tMap transformation
30000 rows/sec
Job 3
Write to Netezza
250 rows/sec
*在我上面的簡單用例中，我假設整個管道的行長度不變，也就是說，如果我們從Oracle讀取10列，同樣的10列通過轉換和寫作業傳遞。然而，在實際場景中，我們確實需要添加或刪除列作為管道的一部分，我們需要選擇吞吐量的替代度量，比如MBs/sec。
讓我們消除這些瓶頸
在前一節中，我討論了確定瓶頸的「位置」。在本節中，我們將對如何消除不同類型的瓶頸進行總結。
源的瓶頸
如果源是關係數據庫，則可以與數據庫管理員合作，以確保根據最佳查詢計劃優化和執行查詢。它們還可以提供優化器提示來提高查詢的吞吐量。它們還應該能夠為具有GROUP BY或ORDER BY子句的查詢添加新索引。
對於Oracle和其他一些數據庫，Talend允許您在t輸入組件中配置游標大小。游標大小定義了結果集的獲取大小。一旦從數據庫中檢索到結果集，就將其存儲在內存中，以便更快地處理。理想的大小由您的數據集和需求定義。您還可以與數據庫管理員一起增加網絡數據包的大小，從而允許在同一時間通過網絡傳輸更大的數據包。
對於非常大的讀操作，使用多個具有非重疊where子句的t輸入組件將並行讀分區創建為多個子作業。選擇為where子句建立索引的列——這將使數據能夠在多次讀取之間均勻分佈。通過在作業屬性中啟用「多線程執行」，每個子作業都可以並行運行
對於存儲在網絡共享存儲上的文件源，請確保運行Talend作業服務器的服務器與承載文件的文件系統之間沒有網絡延遲。理想情況下，文件系統應該專門用於存儲和管理數據集成任務的文件。在我的一次任務中，存儲源文件的文件系統與郵件服務器備份共享—因此，當運行夜間郵件備份時，我們對文件系統的讀取將顯著減慢。與存儲架構師一起消除所有這些瓶頸。
目標的瓶頸
大多數現代關係數據庫支持批量加載。使用散裝裝載器，Talend繞過數據庫日誌，從而提高了性能。對於某些數據庫，我們還提供了使用帶有外部加載器的命名管道的選項。這消除了將中間文件寫入磁盤的需要。
有時在加載之前刪除索引和鍵約束有助於提高性能。您可以在成功完成加載之後重新創建索引和約束
對於更新，將數據庫索引放在與在t輸出組件中定義為鍵的列相同的列上將提高性能
對於網絡共享存儲上的文件目標，請遵循上面關於存儲在網絡共享存儲上的源文件的指導原則
轉換瓶頸
通過消除管道中不必要的行和列來減少Talend正在處理的數據量。可以通過使用tFilterRows和tFilterColumns組件來實現這一點
對於一些內存密集型組件，如tMap和tSortRow, Talend提供了將中間結果存儲在磁盤上的選項。建議使用作業服務器本地的快速磁盤。這減少了在數據量增長時添加更多內存的需求。
有時，轉換瓶頸的出現是因為一個試圖同時做許多事情的大型單片作業。將如此大的作業分解為更高效的數據處理小作業。
有一些額外的優化技術解決瓶頸在工作層面上(如並行化,英語教學,內存優化等)不討論這個博客的一部分,但你可以找到他們的信息和其他技術工作Talend的設計模式和最佳實踐——第1部分、第2部分,第3部分和第4部分。
結論
成功地優化作業以獲得最佳性能的關鍵因素是識別和消除瓶頸。性能調優的第一步是確定瓶頸的來源。是的，它確實涉及到創造額外的測試工作。但不要氣餒，你必須付出額外的努力和時間來建立這些。根據我20多年的經驗，這些努力是值得的。戰略性的、可重複的性能和調優方法比戰術的試錯方法要有效得多。您還可以將學到的經驗教訓融入到您的過程中，並隨着時間的推移進行改進。我希望本文能讓您開始性能調優之旅，並祝您一切順利。
原文：https://www.talend.com/blog/2018/12/26/talend-performance-tuning-strategy/
本文：https://pub.intelligentx.net/node/789/
