【轉】Talend做業設計模式和最佳實踐-Part II

轉載地址：https://mp.weixin.qq.com/s?__biz=MzA3OTg1Mzk4Nw==&mid=2453261363&idx=1&sn=5674f1df83b833b0cb20368920c6a216&chksm=88604cffbf17c5e9e83ef06032f0b99004737e57b6f7eb110cdffa35bf2e276302cf17c764ef&mpshare=1&scene=1&srcid=#rd

做者：talend官方

做業設計入門

做爲有經驗的Talend開發者，我老是好奇他人如何建立做業。他們是否正確使用各項功能？用到的樣式我是否瞭解，抑或從未見過？想出的解決方案是否獨到而精巧？又或者，鑑於畫布/組件數據/工做流程自己的抽象性質，接下來是否愁雲滿面，不知所措…不管這些問題的答案如何，我以爲使用專門設計的工具都很是重要。爲此咱們着手研究「做業設計模式」及與之相關的最佳實踐。在我看來，即使已瞭解Talend的全部特性和功能，可是根本需求仍然不變，那就是探索構建做業的最佳方法。

從邏輯上講，「業務用例」是任何Talend做業的關鍵基本驅動因素。事實上，我在同一工做流程看到各類不一樣的狀況，也看到了各種不一樣工做流程。這些「用例」大多數從基本前提出發，即最簡單的數據集成做業形式是從某個源提取數據並進行處理；在此過程當中可能進行轉換，最終將其加載到某個目標位置。於是ETL/ELT代碼不可或缺，Talend開發者也正致力於此。這一點咱們就再也不贅述，接下來放寬眼界，擴大探討面。

奠基DI項目成功的三大基礎

咱們都認同圓凳須要三條腿才能站穩，對吧？軟件開發也是如此。構建並交付成功的數據集成項目須要三個基本要素：

l 用例 - 明肯定義的業務數據/工做流程要求

l 技術 - 建立、部署和運行解決方案的工具

l 方法 - 業界公認的行事方式

考慮這些要素，加上完善的「開發指南」文檔，咱們以此爲前提展開探討。

擴展基本理論

若是說Talend「做業」在「用例」工做流程中包含了技術，那麼「做業設計模式」就是構建它們的最佳實踐「方法」。我在這些博文中分享的其餘內容即使於您沒有價值，至少會讓您在做業構建方式上保持一致。若是您找到了更好的方法，認爲很是有效，那再好不過，沒必要作出改變。可是，若是您在性能、可重用性和可維護性方面備受困擾，或者須要反覆調整代碼以適應不斷變化的需求，那麼這些最佳實踐對Talend開發者大有裨益！

須要考慮的另外9個最佳實踐：

軟件開發生命週期 (SDLC)

億萬富翁馬庫斯·萊蒙尼斯 (Marcus Lemonis) 在CNBC財經網的「The Profit」（利潤）專欄中，將「人員、產品和流程」視爲決定任何業務成敗的三個關鍵因素。對此我很是贊同。SDLC流程對於任何軟件開發團隊都是殊爲關鍵的環節。正確處理很是重要，而忽視則可能致使項目嚴重受阻，甚至形成災難性後果。Talend的SDLC「最佳實踐指南」針對Talend開發人員可用的持續集成和部署功能，深刻研究相關概念、原則、規範和細節。強烈建議軟件開發團隊將SDLC最佳實踐歸入「開發指南」文檔，而後照此實施。

管理工做區

當您在筆記本電腦/工做站安裝Talend Studio時（假設您擁有管理員權限），一般會在本地磁盤驅動器上建立默認的「工做區」目錄，而且與許多軟件安裝同樣，此默認位置位於可執行文件所在的目錄中。我認爲這麼作確實不妥。爲何？

項目文件（做業和存儲庫元數據）的本地副本存儲在此「工做區」中，若是是經過Talend 管理中心 (TAC) 鏈接到源代碼控制系統（即SVN或GIT），當您打開項目和保存對象時，這些副本也會同步。我認爲應將這些文件放在易於查找和管理的位置，最好是在磁盤上的其餘位置（或者其餘本地盤）。

須要說明，在Talend Studio中建立任何鏈接時都會使用工做區，包括「本地」及「遠程」鏈接，區別在於後者由TAC管理，而前者則不是。對於咱們的訂閱客戶，「遠程」鏈接一般是惟一使用的類型。

對於如何組織目錄結構，應在「開發指南」文檔中予以明確說明，並由整個團隊採行，以實現最佳合做和協做。關鍵是團隊要達成共識、培養紀律性並保持一致性。

參考項目

您是否使用參考項目？是否瞭解其具體內容？我發現不少客戶都不知道這項簡單而高效的功能。咱們都但願建立能夠跨項目共享的可重用、共用或通用代碼。我經常看到開發人員打開一個項目，複製代碼片斷，而後將其粘貼到單獨的（有時是同一個）項目或做業中。或者從一個項目中導出對象，而後將它們導入另外一個項目。說來慚愧，這兩種方式，我以前都實操過。雖然這些方式基本可行，但若是您曾陷入這些過程帶來的麻煩中，就能瞭解其弊端不少，存在不少潛在的維護問題。怎麼辦？能夠有更好的方法，那就是參考項目！這些項目的確讓人眼前一亮。

若是您用過TAC來建立項目，可能注意到一個名爲「參考」的不顯眼的複選框。有沒有想過這是用來作什麼的？其實，若是建立項目時選中該框，使其成爲「參考項目」，那麼該項目能夠「包含」或「連接」到任何其餘項目。在「參考項目」中建立的代碼隨後可用於連接的項目（只讀），於是具有高度可重用性。這在建立各種共用對象和共享代碼時十分適用。

可是，請將這些「參考項目」保持在最低限度；咱們建議僅保留1項做爲最佳實踐，不過在一些有爭議的案例中，也可酌情采用2-3項。注意：建立「參考項目」過多則可能失去其本來意義，所以須適可而止。謹慎管理很是重要，應在「開發指南」文檔中明確說明其用法和規則，並由整個團隊採行，以實現最佳合做和協做。

對象命名規則

「命名規則」確實十分重要，開發團隊都瞭解這一點，所以會制定相應的實踐。不管Talend對象名稱使用的時間、內容及方式如何，取得合理成功的核心仍然是一致性。對Talend對象命名規則，應在「開發指南」文檔中予以明確說明，並由整個團隊採行，以實現最佳合做和協做。

項目存儲庫

使用Talend Studio（基於Eclipse的IDE，即集成開發環境，簡言之就是您的做業編輯器）打開項目時，左側面板表明項目存儲庫。這是全部項目對象所在的位置。這裏有幾個很是重要的版塊。首先，您必需要了解「做業設計」版塊，以便適應能夠建立的3種不一樣類型的做業（即數據集成、批處理和流式傳輸）。此外，您還需瞭解和運用如下版塊。

l 上下文組（contexts） - 不是在內置做業建立上下文變量，而是在存儲庫中的上下文組中進行建立，並跨做業（以及參考項目中所包含的項目）予以重用；能夠實現各個組有效地保持一致；最佳作法是建立對應於不一樣環境的組：SBX/DEV/TEST/UAT/PROD，其中 DEV 爲默認值；刪除現有「默認」上下文；

注意我添加了一個上下文變量「SysENVTYPE」，其中包含選定環境中動態可編程性的值。換言之，我在做業中使用此變量來肯定運行時當前正在運行的環境，這樣就能以編程方式經過條件邏輯更改相應流程。

l 元數據（metadata） - 元數據以不一樣形式呈現，儘可全數利用，包括數據庫鏈接及其表格模式、各種平面文件佈局（csv、xml、json等），以及始終頗具用處的通用架構，這種架構可用於多種方式，在此不一一列出了，不然這篇博文內容會特別長

l 文檔 - 生成您本身的項目Wiki並將其發佈至團隊；此功能將生成一套完整的項目相關html文件，能夠輕鬆導航；此版塊十分有用，並且僅需幾分鐘便可搞定

建議在「開發指南」文檔中爲團隊添加一些最佳實踐，並在團隊中堅持使用。可根據須要進行調整，但要讓團隊中的每一個人都參與進來。

版本控制（分支和標記）

您可能已經注意到，每一個做業屬性選項卡都有一個設置主要 (M) 和次要 (m) 版本編號方案的位置。此外，您還能夠設置本身的建立狀態，其中默認的可能狀態包括「開發」、「測試」和「生產」。注意：Talend Open Studio (TOS) 等專爲單一開發者設計，沒法利用SVN/GIT存儲庫進行合做開發和源代碼控制 (SCC)。您須要知道的是，每當碰到這些內部做業屬性，都會在本地工做區中建立做業的完整副本，並與SCC系統同步。我見過一些項目，其中的做業副本由十幾個內部版本展轉生成。系統會複製該做業的全部副本，致使全部與SCC同步的從屬文件迅速增長，項目所以尾大不掉，每次打開和關閉項目時會形成嚴重的性能問題。若是遇到這種狀況，須要先執行導出，而後，從新導入僅最高版本的做業，以便清理工做區。雖然繁瑣，但這麼作頗有必要。

所以，在全部付費訂閱環境中，版本控制的最佳作法是使用源生SCC分支和標記機制。這始終是管理項目版本發佈的最佳方式，由於SCC只對於每一個做業保存的增量信息予以維護。這麼作能夠顯著減小特定做業歷史記錄所需的空間。使用數字、日期或有用的內容來設計版本管理方案，在「開發指南」文檔中予以詳細說明，並且整個團隊都採用該流程（造成一套正確的程序）。

內存管理

您但願運行做業嗎？是否考慮過做業的內存需求？數據流是否要在tMap中處理數百萬行和/或衆多列和/或多項查找？您是否考慮過看成業在「做業服務器」上運行時，其餘做業可能也在同時運行？有沒有想過「做業服務器」有多少核心/運存？您是如何配置tMap鏈接的？「一次性加載」仍是「逐行」進行？您的做業是調用子做業，仍是由父做業調用，涉及多少級嵌套做業？子做業是否在單獨的JVM中運行？若是編寫ESB做業，您知道正在建立多少條路由嗎？您是否使用並行化（見下文）技術？好吧...這些問題您是否考慮過？有嗎？我打賭沒有 …

默認設置旨在爲可配置的設置提供基本值。做業具備若干設置，包括內存的分配。但默認值並不是必定正確，事實上也可能存在錯誤。您的「用例做業設計」、「操做生態系統」和「實時JVM線程計數」決定了使用的內存量，須要對此進行管理。

您能夠在項目一級或者特定做業中指定JVM內存設置（如上所述）：

首選項 > Talend > 運行

作到這一點很重要，不然會產生嚴重後果。內存管理經常被忽視，可是做爲一個團隊，不管是在開發仍是在操做方面，都應當詳細記錄相應的指導原則並切實遵循。

動態SQL語法

許多數據庫輸入組件須要在其「基本設置」選項卡中包含正確的SQL語法。固然，能夠直接在tMyDBInput（7.0新叫法，例如tmssqlinput/output等）組件中輸入語法，這麼作一樣可行；但也要考慮相應的要求，若是在運行時須要根據做業（或其父做業）控制下的某些邏輯來動態地構建複雜SQL查詢，能夠經過至關直接的方法來解決這個問題。爲SQL查詢的基本結構建立「上下文變量」，到達tMyDBInput組件以前在工做流程中進行設置，而後使用上下文變量代替硬編碼查詢。

例如，我在「引用」項目存儲庫中開發了「上下文組」，稱之爲「SystemVARS」，其中包含各類有用且可重用的變量。對於動態SQL範式，我定義如下初始化爲「null」的「字符串」變量：

根據須要在tJava組件中設置這些變量，而後將它們一併拼接到tMyDBInput查詢字段中，以下所示：

「select 」 + Context.sqlCOLUMNS + Context.sqlFROM + Context.sqlWHERE

請注意，變量值末尾始終包含一個「空格」，以便造成乾淨的串聯。在須要進一步控制的位置，我也利用了「sqlSYNTAX」變量，並有條件地控制串聯SQL語法子句的方式，而後直接將Context.sqlSYNTAX放到tMyDBInput查詢字段中。大功告成。從數據庫主機角度來看，這並不是動態SQL，但這是針對您的做業動態生成的SQL！

綜上所述，記錄這條指導原則，以便每一個人都能遵循相同的處理方式。

並行化選項

Talend提供幾種支持代碼並行化的機制。正確、高效地使用這些機制，並認真考慮對CPU核心和RAM利用率的潛在影響，就能建立高性能做業設計模式。咱們來看選項堆棧：

l 執行計劃 - 可將多個做業/任務配置爲從TAC並行運行，在plan配置的頁面。

l 多個工做流程 - 可在共用相同線程的單個做業中啓動多個數據流；當它們之間不存在依賴關係時，這多是罕見用例場景的技巧，我通常避免這麼作，而更傾向於建立單獨的做業

l 父/子做業 - 使用tRunJob組件調用子做業時，您能夠選中「使用獨立進程運行子做業」複選框，以創建單獨的JVM堆/線程來運行子做業；雖然這並不是徹底意義上的並行化

l 組件 - tParallelize組件連接多個數據流以供執行；tPartitioner、tDepartitioner、tCollector和tRecollector組件提供對數據流的並行線程數的直接控制

l 數據庫組件 - 大多數數據庫輸入/輸出組件提供高級設置，以在特定SQL語句上啓用並行化線程計數；這些能夠高效進行，但設置數字太高可能會拔苗助長；設爲2-5是最佳作法

可將全部這些並行化方法相互結合使用，按原樣嵌套（但建議謹慎行之）；應瞭解您的內存利用率堆棧。要很是清楚做業設計模式的執行流程。請注意，這些並行化選項僅做爲高級功能出如今Talend平臺產品。從文檔中排除並行化指導原則：請務必避免！

成功Talend做業的祕訣

但願這些做業設計模式最佳實踐有助於您想出建立Talend做業的最佳方式。從根本上來講，構建成功的做業有賴於指導原則、紀律性和一致性。只需制定決策，而後遵循便可。在咱們將代碼繪製到數據/工做流程畫布上時，請謹記：

「行動是通向全部成功的基本要訣。」- 巴勃羅·畢加索

最後，我準備了一份「宜與忌」準則清單，其中包含我認爲構建成功的Talend做業所需的祕訣：

l 同時使用tPreJob和tPostJob組件

l 避免組件分類過密，建議在畫布上分散排列

l 合理佈置代碼，自上而下、從左至右

l 初次編寫代碼時沒必要急於求成

l 明確主做業循環並控制退出點

l 不可忽略錯誤處理技巧

l 普遍而明智地使用上下文組 (DEV/QA/UAT/PROD)

l 請勿建立大量單一做業佈局

l 建立原子做業模塊

l 化繁爲簡，避免複雜

l 隨時使用通用模式（值得商榷的例外是單列模式）

l 記得命名對象

l 在適當位置使用小做業（可能只有少數幾處）

l 不要過分使用tJavaFlex組件；tJava或tJavaRow可能足矣

l 完成後生成/發佈項目文檔

l 不要跳過運行時內存堆設置步驟

結語

好，感受如何，是否知足？但願您仍然意猶未盡，由於後續我計劃就這個系列作進一步講解，再介紹一些「示範用例」。今天的博文豐富了以前的基礎理論，並引入了更高一級的概念，敬請您予以考量，但願對您有用。以上僅爲拋磚引玉，也歡迎你們暢所欲言，在評論中談談本身遵循的一些最佳作法。期待下次再會。

若是您以爲此文章對您有幫助，請點擊右下方【推薦】讓更多人看到，thanks！