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

原文地址：https://mp.weixin.qq.com/s?__biz=MzA3OTg1Mzk4Nw==&mid=2453261363&idx=2&sn=e0f42602271d4bb0415b174dfad9963b&chksm=88604cffbf17c5e9b4a48daf5ec09341f34e0d4a44bba9e31501cbb1701bd8d995a5d173e3e8&mpshare=1&scene=1&srcid=0111PXlXmg0GVBeIsITB7zl5#rd

原文做者：talend官方

做爲Talend開發者，無論是入門新手仍是資深人士，經常要處理同一個的問題：「在編寫這項做業時，哪一種方式最好？」咱們知道，一般應當高效、易讀易寫，而且尤爲（多數狀況下）要易於維護。咱們也知道，Talend Studio比如自由形態的「畫布」，有全面而豐富的組件、存儲庫對象、元數據和連接選項，咱們能夠運用這些來「繪製」代碼。那麼，如何肯定在建立做業設計時使用的是最佳實踐？

做業設計模式

自Talend版本3.4起，在每次使用時我都體會到做業設計對個人重要性。起初我在開發做業時並未思考模式。以前我用過Microsoft SSIS和其餘相似工具，因此像Talend這樣的可視化編輯器對我來講並不陌生。相反，我關注的主要是基本功能、代碼可重用性；其次是畫布佈局；最後是命名規則。現現在，針對各類用例我已經開發了數百項Talend做業，我發現代碼變得更加精巧，可重用性更高，一致性也更好，此時，模式的意義才逐漸顯露出來。

加入Talend後，我有不少機會看到由客戶開發的做業，得以證明本身的見解：對於每位開發者，每一個用例都有多種解決方案。我認爲這一點是很多人的問題所在。咱們做爲開發者的確都這麼認爲，可是在開發特定做業時，每每認爲本身的方式是最佳或者惟一選擇，但實際上也知道「或許還有更好的方式」，這種聲音反覆縈繞於耳際。在此狀況下，咱們期待或尋覓最佳實踐，也就是做業設計模式！

制定基本規範

考慮實現最佳做業代碼所需元素時，一般用到一些基本法則。這些法則源於多年來從失敗中汲取的教訓以及積累的成功經驗。它們相當重要，爲構建代碼奠基堅實基礎。我我的認爲應該引發高度重視。我認爲這些法則包括（重要程度不分前後）：

l 可讀性：建立明白易懂的代碼

l 可寫性：在最短期內建立簡潔明瞭的代碼

l 可維護性：肯定適當的複雜性，同時最大限度減小變動帶來的影響

l 功能性：建立知足要求的代碼

l 可重用性：建立可共享對象和原子工做單元

l 符合性：建立跨團隊、項目、存儲庫和代碼的真正規則

l 易適應性：建立能夠變通而不致破壞的代碼

l 可擴展性：建立可根據須要調整吞吐量的彈性模塊

l 一致性：肯定全部內容之間的共性

l 效率：建立優化的數據流和組件利用率

l 分區：建立服務於單一目標的原子化重點模塊

l 優化：使用最少代碼建立最多功能

l 性能：建立提供最快吞吐量的有效模塊

重中之重是如何真正平衡這些法則，特別是前三條，由於這三者老是相互矛盾，知足其中兩條每每要犧牲另一條。若是能夠，嘗試按重要性對這些法則進行排序。

指導原則並不是硬性標準，主要是爲了有章可循！

在真正深刻研究做業設計模式以前，結合剛剛闡述的基本法則，咱們首先要確保瞭解一些其餘值得考慮的細節。我發現不少時候標準過於嚴苛，並未針對與其相悖的非預期場景留出足夠餘量。而另一些時候則相反。不一樣開發者一模一樣地遵循刻板粗糙、有失協調的規範，更有甚者在做業設計中不連貫、缺少規劃甚至毫無章法，造成不良風氣。坦率說來，我認爲這樣過於草率並會形成誤導，其實想要避免這些並不困難。

出於上述以及其餘至關明顯的緣由，首先要制定成文的「指南」，而非創建「標準」。

其中包含基本法則並隨附細則。參與SDLC（軟件開發生命週期）過程的全部團隊建立並採用「開發指南」文檔以後，這些基本法則便可爲開發中的結構、定義和上下文方面提供支持。對這一環節的投入具備長遠意義，往後全部相關人員都將從中獲益。

如下建議要點，您可根據自身狀況予以採納（僅做指導參考，歡迎自行修改擴充）。

1. 方法：其中應詳細說明但願如何構建

1. 數據建模

1. 總體/概念/邏輯/物理

2. 數據庫、NoSQL、EDW、文件

2. SDLC流程控制

1. 瀑布式或敏捷式/Scrum

2. 要求和規範

3. 錯誤處理和審計

4. 數據治理與管理

2. 技術：其中應列出各類工具（內部工具和外部工具）以及各工具間如何相互關聯

1. 操做系統和基礎架構拓撲

2. 數據庫管理系統

3. NoSQL系統

4. 加密和壓縮

5. 第三方軟件集成

6. Web服務接口

7. 外部系統接口

3. 最佳實踐：其中應說明要遵循特定指南的內容和時間

1. 環境 (DEV/QA/UAT/PROD)

2. 命名規則

3. 項目、做業和小做業

4. 存儲庫對象

5. 記錄、監測和通知

6. 做業返回代碼

7. 代碼 (Java) 例程

8. 上下文組和全局變量

9. 數據庫和NoSQL鏈接

10. 源/目標數據和文件架構

11. 做業切入和退出點

12. 做業工做流程和佈局

13. 組件利用率

14. 並行化

15. 數據質量

16. 父/子任務和小做業（joblet）

17. 數據交換協議

18. 持續集成和部署

1. 集成源代碼控制 (SVN/GIT)

2. 發佈管理和版本控制

3. 自動化測試

4. 項目存儲庫和提高

19. 管理與運營

1. 配置

2. 用戶安全和受權

3. 角色和權限

4. 項目管理

5. 做業任務、計劃和觸發器

20. 存檔和災難恢復

我認爲應當開發和維護的一些其餘文件包括：

l 模塊庫：描述全部可重用的項目、方法、對象、小做業和上下文組

l 數據字典：描述全部數據模式和相關的存儲過程

l 數據訪問層：描述與鏈接和操做數據相關的全部事項

誠然，建立這樣的文檔須要時間，但與之在整個生命週期中發揮的價值相比，這些成本物超所值。文檔應儘量簡明扼要、直截了當並與時俱進（沒必要具備聲明性質），它將有助於大幅減小開發錯誤（不然往後會爲此付出高昂代價），爲您全部的項目取得成功大有助益。

是時候探討做業設計模式了吧？

固然，但首先還要說明一點。我認爲，每位開發者在編寫代碼時均可能造成或好或壞的習慣。因此培養良好的習慣相當重要。能夠從一些簡單的習慣開始，好比爲每一個組件添加標籤。這會讓代碼更具可讀性，而且便於理解（咱們的基本法則之一）。人人都養成這樣的習慣後，確保全部做業都有序組織到存儲庫文件夾中，而且使用的名稱對項目有必定意義（也即符合性）。而後讓每一個人都採用相同的日誌記錄消息樣式，比方說對於 System.out.PrintLn() 函數採用通用方法封裝器，而且對於做業代碼創建共同的切入/退出點標準（其中包含替代要求選項）。這二者都有助於快速實現多個法則。隨着時間的推移，因爲開發團隊採用並充分利用定義明確的開發指南，項目代碼將變得更易讀寫，而且可由團隊中任何人進行維護（這也是我最指望的效果）。

做業設計模式和最佳實踐

在我看來，Talend做業設計模式可爲咱們提供建議的模板或框架佈局，其中涉及關注特定用例的重要和/或必需的元素。模式一般可重用於相似做業建立，如此一來，咱們能夠快速啓動代碼開發做業。如您預期，多個不一樣用例也可引入通用模式，通過正確識別和實施，可以加強總體代碼庫、壓縮做業量並減小重複或類似的代碼。咱們下面就此展開探討。

如下是要考慮的7項最佳實踐：

畫布工做流程和佈局

可經過多種方法在做業畫布上放置組件，並將這些組件相互關聯。我偏好的作法大致是首先「自上而下」，而後「從左至右」，其中左側邊界流程一般是錯誤路徑，右側邊界和/或下方邊界流程則爲指望的或正常的路徑。理想狀況下應儘量避免連線交叉，自6.0.1版開始引入巧妙的弧線鏈接，很好地體現了這種策略。

我本身不太認同「之」字型模式，也就是組件按順序「從左到右」放置，到達最右邊界後即向下排列，隨後再返回到左側邊界，依次類推。感受這種模式既不方便也很差維護，不過的確容易編寫。若是必需要用這種模式，執行的做業可能較以前會增多，而且可能沒法得以正確組織。

原子做業模塊 ~ 父/子做業

簡言之，包含大量組件的大型做業很難理解和維護。要避免這種狀況，建議儘量將大型做業分解爲較小做業或工做單元。以後以子做業形式執行（使用tRunJob組件），其目的即對他們加以控制和執行。這麼作也便於更好地處理錯誤和後續事件。請記住，雜亂的做業可能難以理解，難以調試/修復，而且幾乎沒法維護。而簡單的小型做業具備明確目的，經過畫布便可肯定意圖，絕大多數易於調試/修復，維護也相對垂手可得。

建立嵌套的父/子做業層次結構雖然徹底能夠接受，但須要考慮實際限制。根據做業內存利用率、傳遞的參數、測試/調試問題以及並行化技術（以下所述），良好的做業設計模式不該超過3級嵌套tRunJob父/子調用。嵌套再深可能更安全，但我有充分理由認爲，對於任何用例5級足矣。

tRunJob與小做業

肯定子做業與使用小做業之間的簡單區別在於，子做業是從做業中「調用」，而小做業「包含」在做業中。二者都提供建立可重用和/或通用代碼模塊的機會，在任何做業設計模式中結合使用二者都是一種很是有效的策略。

切入和退出點

全部Talend做業都須要在某個地方開始和結束。Talend提供兩個基本組件，即tPreJob和tPostJob，目的是幫助控制執行做業內容先後發生的狀況。在個人代碼中，「初始化」和「收卷」步驟至關於這兩個組件。如您預期，首先執行tPreJob，而後執行實際代碼，最後執行tPostJob代碼。請注意，不管代碼正文中是否存在設計的退出（例如tDie組件，或者組件複選框選項「錯誤結束"），都將執行tPostJob代碼。

關於做業切入和退出點，也應考慮使用tWarn和tDie組件。這些組件提供對做業完成位置和方式的可編程控制，還支持改進錯誤處理、日誌記錄和恢復機會。

在做業設計模式中，我常使用tPreJob初始化上下文變量，創建鏈接並記錄重要信息。對於tPostJob，則關閉鏈接和其餘重要清理以及更多記錄。至關簡單對嗎？您是這麼作的吧？

錯誤處理和日誌記錄

這一項很是重要，或者說相當重要，若是能夠正確建立通用的做業設計模式，幾乎全部項目都能創建高度可重用的機制。個人做業模式是針對任何做業可能包含的具備一致性和可維護性的記錄處理器，建立「logPROCESSING」小做業，再附加包含具備符合性、可重用性和高效性的明肯定義的「返回代碼」。其中的附加項易於編寫、易於閱讀且易於維護。我相信，若是您能以本身獨有的成熟方式來處理和記錄項目做業的錯誤，則必將收穫事半功倍的喜悅。建議合理借鑑，善加利用！

最新版Talend增長了對Log4j和日誌服務器使用的支持。只需啓用「項目設置 > Log4j」菜單選項，而後在TAC中配置Log Stash服務器便可。強烈建議您在做業中歸入這項基本功能，實踐證實其效果卓越。

「OnSubJobOK /Error」與「OnComponentOK/Error」（及Run If）組件連接

有時候，Talend開發人員對於「OnSubJob」或「OnComponent」連接之間的差別心存一絲困惑。「OK」與「Error」的區別顯而易見，那麼這些「觸發鏈接」差別何在，如何影響做業設計流程？

組件之間的」觸發鏈接」可定義處理序列和數據流，其中組件之間的依賴關係存在於子做業中。子做業的特色是所用組件有一個或多個組件與其連接，從而處理當前數據流。單個做業中可能存在多個子做業，默認狀況下全部相關子做業組件周圍帶有藍色高亮方框（可在工具欄予以開啓/關閉）。

子做業中的全部組件完成處理後，「OnSubJobOk /Error」觸發器將繼續處理下一個「連接」子做業。僅可從該子做業中的起始組件處使用。在該特定組件完成處理後，「OnComponenOK/Error」觸發器將繼續處理下一個「連接」組件。若是繼續處理的下一個「連接」組件是須要基於可編程java表達式（true|false斷定執行的狀況），則「Run If」觸發器會很是有用。

何爲做業循環？

對於幾乎每種做業設計模式，代碼中的「主循環」和「輔助循環」都很是重要。這些點用於控制做業執行的潛在退出位置。「主循環」一般表現爲數據流結果集的最頂層處理，完成主循環以後，做業即告完成。「輔助循環」嵌套在更高階循環中，且一般需藉助重要控制纔可確保做業正確退出。我每次會肯定「主循環」並確保向控制組件添加tWarn和tDie組件。tDie一般設置爲當即退出JVM（但請注意，即使如此tPostJob代碼也會執行）。這些頂層出口點使用簡單的代碼，「0」表示成功，「1」表示失敗返回，不過遵循本身制定的「返回代碼」指南再好不過了。「輔助循環」（以及流程中的其餘關鍵組件）中十分適合歸入其餘tWarn和tDie組件（其中tDie未設置爲「當即退出 JVM」）。

上面討論的大多數做業設計模式最佳實踐以下圖所示。請注意我用到了實用的組件標籤，不過仍對組件放置規則稍做變通。不管如何，最終結果是做業具備高度可讀性、可維護性並易於編寫。

結語

至此，雖然說並未悉數解答您關於做業設計模式的疑問（實際上也不可能），但這總歸是良好的開端。咱們介紹了一些基礎知識，提供了方向，並做了小結。但願這些有所幫助，而且能爲諸位讀者帶來一些有益的啓示。

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