作為Talend開發(fā)者，不管是入門新手還是資深人士，常常要處理同一個的問題：“在編寫這項作業(yè)時，哪種方式最好？”我們知道，通常應(yīng)當(dāng)高效、易讀易寫，并且尤其（多數(shù)情況下）要易于維護。我們也知道，Talend Studio好比自由形態(tài)的“畫布”，有全面而豐富的組件、存儲庫對象、元數(shù)據(jù)和鏈接選項，我們可以運用這些來“繪制”代碼。那么，如何確定在創(chuàng)建作業(yè)設(shè)計時使用的是最佳實踐？

作業(yè)設(shè)計模式

自Talend版本3.4起，在每次使用時我都體會到作業(yè)設(shè)計對我的重要性。起初我在開發(fā)作業(yè)時并未思考模式。之前我用過Microsoft SSIS和其他類似工具，所以像Talend這樣的可視化編輯器對我來說并不陌生。相反，我關(guān)注的主要是基本功能、代碼可重用性；其次是畫布布局；最后是命名規(guī)則。現(xiàn)如今，針對各種用例我已經(jīng)開發(fā)了數(shù)百項Talend作業(yè)，我發(fā)現(xiàn)代碼變得更加精巧，可重用性更高，一致性也更好，此時，模式的意義才逐漸顯露出來。

加入Talend后，我有很多機會看到由客戶開發(fā)的作業(yè)，得以證實自己的看法：對于每位開發(fā)者，每個用例都有多種解決方案。我認為這一點是不少人的問題所在。我們作為開發(fā)者的確都這么認為，但是在開發(fā)特定作業(yè)時，往往認為自己的方式是最佳或者唯一選擇，但實際上也知道“或許還有更好的方式”，這種聲音反復(fù)縈繞于耳際。在此情況下，我們期待或?qū)ひ捵罴褜嵺`，也就是作業(yè)設(shè)計模式！

制定基本規(guī)范

考慮實現(xiàn)最佳作業(yè)代碼所需元素時，通常用到一些基本法則。這些法則源于多年來從失敗中汲取的教訓(xùn)以及積累的成功經(jīng)驗。它們至關(guān)重要，為構(gòu)建代碼奠定堅實基礎(chǔ)。我個人認為應(yīng)該引起高度重視。我認為這些法則包括（重要程度不分先后）：

-可讀性：創(chuàng)建明白易懂的代碼

-可寫性：在最短時間內(nèi)創(chuàng)建簡潔明了的代碼

-可維護性：確定適當(dāng)?shù)膹?fù)雜性，同時最大限度減少變更帶來的影響

-功能性：創(chuàng)建滿足要求的代碼

-可重用性：創(chuàng)建可共享對象和原子工作單元

-符合性：創(chuàng)建跨團隊、項目、存儲庫和代碼的真正規(guī)則

-易適應(yīng)性：創(chuàng)建可以變通而不致破壞的代碼

-可擴展性：創(chuàng)建可根據(jù)需要調(diào)整吞吐量的彈性模塊

-一致性：確定所有內(nèi)容之間的共性

-效率：創(chuàng)建優(yōu)化的數(shù)據(jù)流和組件利用率

-分區(qū)：創(chuàng)建服務(wù)于單一目標(biāo)的原子化重點模塊

-優(yōu)化：使用最少代碼創(chuàng)建最多功能

-性能：創(chuàng)建提供最快吞吐量的有效模塊

重中之重是如何真正平衡這些法則，特別是前三條，因為這三者總是相互矛盾，滿足其中兩條往往要犧牲另外一條。如果可以，嘗試按重要性對這些法則進行排序。

指導(dǎo)原則并非硬性標(biāo)準，主要是為了有章可循！

在真正深入研究作業(yè)設(shè)計模式之前，結(jié)合剛剛闡述的基本法則，我們首先要確保了解一些其他值得考慮的細節(jié)。我發(fā)現(xiàn)很多時候標(biāo)準過于嚴苛，并未針對與其相悖的非預(yù)期場景留出足夠余量。而另外一些時候則相反。不同開發(fā)者如出一轍地遵循刻板粗糙、有失協(xié)調(diào)的規(guī)范，更有甚者在作業(yè)設(shè)計中不連貫、缺乏規(guī)劃甚至毫無章法，形成不良風(fēng)氣。坦率說來，我認為這樣過于草率并會造成誤導(dǎo)，其實想要避免這些并不困難。

出于上述以及其他相當(dāng)明顯的原因，首先要制定成文的“指南”，而非建立“標(biāo)準”。

其中包含基本法則并隨附細則。參與SDLC（軟件開發(fā)生命周期）過程的所有團隊創(chuàng)建并采用“開發(fā)指南”文檔之后，這些基本法則即可為開發(fā)中的結(jié)構(gòu)、定義和上下文方面提供支持。對這一環(huán)節(jié)的投入具有長遠意義，日后所有相關(guān)人員都將從中獲益。

以下建議要點，您可根據(jù)自身情況予以采納（僅作指導(dǎo)參考，歡迎自行修改擴充）。

1. 方法：其中應(yīng)詳細說明希望如何構(gòu)建

1. 數(shù)據(jù)建模

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

2. 數(shù)據(jù)庫、NoSQL、EDW、文件

2. SDLC流程控制

1. 瀑布式或敏捷式/Scrum

2. 要求和規(guī)范

3. 錯誤處理和審計

4. 數(shù)據(jù)治理與管理

2. 技術(shù)：其中應(yīng)列出各種工具（內(nèi)部工具和外部工具）以及各工具間如何相互關(guān)聯(lián)

1. 操作系統(tǒng)和基礎(chǔ)架構(gòu)拓撲

2. 數(shù)據(jù)庫管理系統(tǒng)

3. NoSQL系統(tǒng)

4. 加密和壓縮

5. 第三方軟件集成

6. Web服務(wù)接口

7. 外部系統(tǒng)接口

3. 最佳實踐：其中應(yīng)說明要遵循特定指南的內(nèi)容和時間

1. 環(huán)境 (DEV/QA/UAT/PROD)

2. 命名規(guī)則

3. 項目、作業(yè)和小作業(yè)

4. 存儲庫對象

5. 記錄、監(jiān)測和通知

6. 作業(yè)返回代碼

7. 代碼 (Java) 例程

8. 上下文組和全局變量

9. 數(shù)據(jù)庫和NoSQL連接

10. 源/目標(biāo)數(shù)據(jù)和文件架構(gòu)

11. 作業(yè)切入和退出點

12. 作業(yè)工作流程和布局

13. 組件利用率

14. 并行化

15. 數(shù)據(jù)質(zhì)量

16. 父/子任務(wù)和小作業(yè)

17. 數(shù)據(jù)交換協(xié)議

18. 持續(xù)集成和部署

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

2. 發(fā)布管理和版本控制

3. 自動化測試

4. 項目存儲庫和提升

19. 管理與運營

1. 配置

2. 用戶安全和授權(quán)

3. 角色和權(quán)限

4. 項目管理

5. 作業(yè)任務(wù)、計劃和觸發(fā)器

20. 存檔和災(zāi)難恢復(fù)

我認為應(yīng)當(dāng)開發(fā)和維護的一些其他文件包括：

-模塊庫：描述所有可重用的項目、方法、對象、小作業(yè)和上下文組

-數(shù)據(jù)字典：描述所有數(shù)據(jù)模式和相關(guān)的存儲過程

-數(shù)據(jù)訪問層：描述與連接和操作數(shù)據(jù)相關(guān)的所有事項

誠然，創(chuàng)建這樣的文檔需要時間，但與之在整個生命周期中發(fā)揮的價值相比，這些成本物超所值。文檔應(yīng)盡可能簡明扼要、直截了當(dāng)并與時俱進（不必具有聲明性質(zhì)），它將有助于大幅減少開發(fā)錯誤（否則日后會為此付出高昂代價），為您所有的項目取得成功大有助益。

是時候探討作業(yè)設(shè)計模式了吧？

當(dāng)然！但首先還要說明一點。我認為，每位開發(fā)者在編寫代碼時都可能形成或好或壞的習(xí)慣。所以培養(yǎng)良好的習(xí)慣至關(guān)重要。可以從一些簡單的習(xí)慣開始，比如為每個組件添加標(biāo)簽。這會讓代碼更具可讀性，并且便于理解（我們的基本法則之一）。人人都養(yǎng)成這樣的習(xí)慣后，確保所有作業(yè)都有序組織到存儲庫文件夾中，并且使用的名稱對項目有一定意義（也即符合性）。然后讓每個人都采用相同的日志記錄消息樣式，比方說對于System.out.PrintLn()函數(shù)采用通用方法封裝器，并且對于作業(yè)代碼建立共同的切入/退出點標(biāo)準（其中包含替代要求選項）。這兩者都有助于快速實現(xiàn)多個法則。隨著時間的推移，由于開發(fā)團隊采用并充分利用定義明確的開發(fā)指南，項目代碼將變得更易讀寫，并且可由團隊中任何人進行維護（這也是我最期望的效果）。

作業(yè)設(shè)計模式和最佳實踐

在我看來，Talend作業(yè)設(shè)計模式可為我們提供建議的模板或框架布局，其中涉及關(guān)注特定用例的重要和/或必需的元素。模式通常可重用于類似作業(yè)創(chuàng)建，如此一來，我們可以快速啟動代碼開發(fā)作業(yè)。如您預(yù)期，多個不同用例也可引入通用模式，經(jīng)過正確識別和實施，能夠增強整體代碼庫、壓縮作業(yè)量并減少重復(fù)或相似的代碼。我們下面就此展開探討。

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

畫布工作流程和布局

可通過多種方法在作業(yè)畫布上放置組件，并將這些組件相互關(guān)聯(lián)。我偏好的做法大體是首先“自上而下”，然后“從左至右”，其中左側(cè)邊界流程通常是錯誤路徑，右側(cè)邊界和/或下方邊界流程則為期望的或正常的路徑。理想情況下應(yīng)盡可能避免連線交叉，自6.0.1版開始引入巧妙的弧線連接，很好地體現(xiàn)了這種策略。

我自己不太認同“之”字型模式，也就是組件按順序“從左到右”放置，到達最右邊界后即向下排列，隨后再返回到左側(cè)邊界，依次類推。感覺這種模式既不方便也不好維護，不過的確容易編寫。如果必須要用這種模式，執(zhí)行的作業(yè)可能較之前會增多，并且可能無法得以正確組織。

原子作業(yè)模塊 ~ 父/子作業(yè)

簡言之，包含大量組件的大型作業(yè)很難理解和維護。要避免這種情況，建議盡可能將大型作業(yè)分解為較小作業(yè)或工作單元。之后以子作業(yè)形式執(zhí)行（使用tRunJob組件），其目的即對他們加以控制和執(zhí)行。這么做也便于更好地處理錯誤和后續(xù)事件。請記住，雜亂的作業(yè)可能難以理解，難以調(diào)試/修復(fù)，并且?guī)缀鯚o法維護。而簡單的小型作業(yè)具有明確目的，通過畫布即可確定意圖，絕大多數(shù)易于調(diào)試/修復(fù)，維護也相對輕而易舉。

創(chuàng)建嵌套的父/子作業(yè)層次結(jié)構(gòu)雖然完全可以接受，但需要考慮實際限制。根據(jù)作業(yè)內(nèi)存利用率、傳遞的參數(shù)、測試/調(diào)試問題以及并行化技術(shù)（如下所述），良好的作業(yè)設(shè)計模式不應(yīng)超過3級嵌套tRunJob父/子調(diào)用。嵌套再深可能更安全，但我有充分理由認為，對于任何用例5級足矣。

tRunJob與小作業(yè)

確定子作業(yè)與使用小作業(yè)之間的簡單區(qū)別在于，子作業(yè)是從作業(yè)中“調(diào)用”，而小作業(yè)“包含”在作業(yè)中。兩者都提供創(chuàng)建可重用和/或通用代碼模塊的機會，在任何作業(yè)設(shè)計模式中結(jié)合使用兩者都是一種非常有效的策略。

切入和退出點

所有Talend作業(yè)都需要在某個地方開始和結(jié)束。Talend提供兩個基本組件，即tPreJob和tPostJob，目的是幫助控制執(zhí)行作業(yè)內(nèi)容前后發(fā)生的情況。在我的代碼中，“初始化”和“收卷”步驟相當(dāng)于這兩個組件。如您預(yù)期，首先執(zhí)行tPreJob，然后執(zhí)行實際代碼，最后執(zhí)行tPostJob代碼。請注意，無論代碼正文中是否存在設(shè)計的退出（例如tDie組件，或者組件復(fù)選框選項“錯誤結(jié)束"），都將執(zhí)行tPostJob代碼。

關(guān)于作業(yè)切入和退出點，也應(yīng)考慮使用tWarn和tDie組件。這些組件提供對作業(yè)完成位置和方式的可編程控制，還支持改進錯誤處理、日志記錄和恢復(fù)機會。

在作業(yè)設(shè)計模式中，我常使用tPreJob初始化上下文變量，建立連接并記錄重要信息。對于tPostJob，則關(guān)閉連接和其他重要清理以及更多記錄。相當(dāng)簡單對嗎？您是這么做的吧？

錯誤處理和日志記錄

這一項非常重要，或者說至關(guān)重要，如果可以正確創(chuàng)建通用的作業(yè)設(shè)計模式，幾乎所有項目都能建立高度可重用的機制。我的作業(yè)模式是針對任何作業(yè)可能包含的具有一致性和可維護性的記錄處理器，創(chuàng)建“logPROCESSING”小作業(yè)，再附加包含具有符合性、可重用性和高效性的明確定義的“返回代碼”。其中的附加項易于編寫、易于閱讀且易于維護。我相信，如果您能以自己獨有的成熟方式來處理和記錄項目作業(yè)的錯誤，則必將收獲事半功倍的喜悅。建議合理借鑒，善加利用！

最新版Talend增加了對Log4j和日志服務(wù)器使用的支持。只需啟用“項目設(shè)置> Log4j”菜單選項，然后在TAC中配置Log Stash服務(wù)器即可。強烈建議您在作業(yè)中納入這項基本功能，實踐證明其效果卓越。

“On SubJob正常/錯誤”與“On Component正常/錯誤”（及Run If）組件鏈接

有時候，Talend開發(fā)人員對于“On SubJob”或“On Component”鏈接之間的差異心存一絲困惑。“正常”與“錯誤”的區(qū)別顯而易見，那么這些“觸發(fā)連接”差異何在，如何影響作業(yè)設(shè)計流程？

組件之間的”觸發(fā)連接”可定義處理序列和數(shù)據(jù)流，其中組件之間的依賴關(guān)系存在于子作業(yè)中。子作業(yè)的特點是所用組件有一個或多個組件與其鏈接，從而處理當(dāng)前數(shù)據(jù)流。單個作業(yè)中可能存在多個子作業(yè)，默認情況下所有相關(guān)子作業(yè)組件周圍帶有藍色高亮方框（可在工具欄予以開啟/關(guān)閉）。

子作業(yè)中的所有組件完成處理后，“On SubJob正常/錯誤”觸發(fā)器將繼續(xù)處理下一個“鏈接”子作業(yè)。僅可從該子作業(yè)中的起始組件處使用。在該特定組件完成處理后，“On Component正常/錯誤”觸發(fā)器將繼續(xù)處理下一個“鏈接”組件。如果繼續(xù)處理的下一個“鏈接”組件基于可編程java表達式，則“Run If”觸發(fā)器會非常有用。

何為作業(yè)循環(huán)？

對于幾乎每種作業(yè)設(shè)計模式，代碼中的“主循環(huán)”和“輔助循環(huán)”都非常重要。這些點用于控制作業(yè)執(zhí)行的潛在退出位置。“主循環(huán)”通常表現(xiàn)為數(shù)據(jù)流結(jié)果集的最頂層處理，完成主循環(huán)之后，作業(yè)即告完成。“輔助循環(huán)”嵌套在更高階循環(huán)中，且通常需借助重要控制才可確保作業(yè)正確退出。我每次會確定“主循環(huán)”并確保向控制組件添加tWarn和tDie組件。tDie通常設(shè)置為立即退出JVM（但請注意，即便如此tPostJob代碼也會執(zhí)行）。這些頂層出口點使用簡單的代碼，“0”表示成功，“1”表示失敗返回，不過遵循自己制定的“返回代碼”指南再好不過了。“輔助循環(huán)”（以及流程中的其他關(guān)鍵組件）中十分適合納入其他tWarn和tDie組件（其中tDie未設(shè)置為“立即退出 JVM”）。

上面討論的大多數(shù)作業(yè)設(shè)計模式最佳實踐如下圖所示。請注意我用到了實用的組件標(biāo)簽，不過仍對組件放置規(guī)則稍作變通。無論如何，最終結(jié)果是作業(yè)具有高度可讀性、可維護性并易于編寫。

結(jié)語

至此，雖說并未悉數(shù)解答您關(guān)于作業(yè)設(shè)計模式的疑問（實際上也不可能），但這總歸是良好的開端。我們介紹了一些基礎(chǔ)知識，提供了方向，并作了小結(jié)。希望這些有所幫助，并且能為諸位讀者帶來一些有益的啟示。

總結(jié)

以上是生活随笔為你收集整理的Talend“作业设计模式”和最佳实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。