轉載地址：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！