Talend「做業設計模式」和最佳實踐 - 第3部分

此前我發佈的同主題博文貌似反響不錯，這讓我深感榮幸，謹向諸位熱心讀者致以誠摯謝意。

若是您是初次來訪的新讀者，建議先行閱讀同一主題系列的前兩篇博文，也即《Talend「做業設計模式」和最佳實踐》第1部分和第2部分，而後再閱讀本篇後續內容。

接下來咱們將繼續討論主題，歡迎你們發表見解，提出問題乃至展開爭論，若能將討論擴展到Talend社區，也算是達成個人潛在心願。還記得「指南」並不是「標準」，對吧？衷心但願諸位踊躍發言，不吝分享本身的觀點，有您參與必定更精彩。

 

基於主題構建

 

此前咱們已經明確認識到，制定「開發人員指南」對於軟件生命週期取得成功不可或缺，Talend項目亦莫能外。咱們能夠確定地說，確立開發者指導原則、在團隊中予以推行，以及逐步培養紀律性是Talend實現卓越成效的關鍵。相信這麼說你們並沒有異議。構建Talend做業可能一波三折（我說的可不是新版中的曲線），理解「業務用例」、「技術」和「方法」基礎能夠顯著促進構建過程順利進行。我認爲花時間制定團隊指南很是值得，往後您會慶幸當初這麼作。

很多對Talend客戶構成挑戰的用例一般關乎某種形式的數據集成過程，這一環節是Talend的核心競爭力，涉及將數據從一個位置移動到另外一個位置。數據流有多種形式，其具體用途和處理方法都很是重要，其重要性無可置疑，能夠說是咱們建立每項做業時的核心要素。若是實際用例須要移動業務數據，而Talend是技術堆棧的組成部分，那麼該使用什麼方法？固然是咱們討論過的SDLC最佳實踐，不過除此以外，與數據相關的方法還包括數據建模，這是我很是樂於探討的內容。擔任數據庫架構師逾25年，我所設計和構建的數據庫解決方案不可勝數。在我看來，數據庫系統生命週期是很是實際的問題。不管是平面文件、EDI、OLTP、OLAP、STAR、Snowflake仍是數據保險庫模式，若是忽略數據及其相應模式從生成到消亡的過程，小則留下漏洞，大則形成災難。

數據建模方法並不是本篇博文的主題，但採用適當的數據結構設計和利用率很是重要。您能夠瀏覽個人博客中有關數據保險庫的篇目，並留意後續發佈的數據建模文章。咱們如今只需考慮字面意義而沒必要深挖，不過數據開發生命週期(DDLC) 無疑是最佳實踐。仔細思考，您會明白我所謂何意。

 

更多做業設計最佳實踐

 

言歸正傳，繼續來看Talend做業設計的「最佳實踐」。到目前爲止咱們介紹了16項最佳實踐，下面再介紹8項。這個系列還會有第4部分，本篇沒法涵蓋的內容留待下篇繼續，以避免諸位難以吸取…即刻開始吧！

 

 

 

 

可供考慮的更多最佳實踐：

代碼例程

有時Talend組件就是不能知足特定的編程需求，這不要緊。Talend畢竟是Java代碼生成器，沒錯，您還可使用Java組件，在畫布上將純java合併到流程和/或數據流中。要是這麼作還不夠，還能怎麼辦？不妨嘗試另一種有用的方法：代碼例程。這是一種實際Java方法，您能夠將其添加到項目存儲庫。本質上這是用戶定義的java函數，您能夠在整個做業的各個位置進行編碼和使用。

Talend提供大量java函數（您可能已經用過），例如：

- getCurrentDate()

- sequence(String seqName, int startValue, int step)

- ISNULL（對象變量）

當您考慮做業、項目和用例全局時，可使用代碼例程進行衆多操做。可重用代碼在個人博文中被反覆說起。若是您建立的實用代碼例程有助於以通用方式簡化做業，那就對了。選擇函數做爲「幫助」文本時，請確保在顯示時包含正確的註釋。

 

存儲庫模式

項目存儲庫的「元數據」部分有助於建立可重用對象，這是一項重要的開發指導原則，您還記得吧？針對在做業中建立可重用對象，存儲庫模式提供功能強大的技術，包括：

- 文件模式 - 用於映射各類平面文件格式，包括：

• 分隔

• 位置

• 正則表達式

• XML

• Excel

• JSON

- 通用模式 - 用於映射各類記錄結構

- WDSL 模式 - 用於映射Web服務方法結構

- LDAP 模式 - 用於映射LDAP結構（LDIF 亦可用）

- UN/EDIFACT - 用於映射各類EDI事務結構

建立模式時，您要提供相應的對象名稱、用途和說明，以及在做業代碼中引用的元數據對象名稱。默認狀況下，這稱爲「元數據」。請花時間爲這些對象定義命名慣例，或者代碼中全部內容採用一樣的名稱，好比不妨使用「md_{objectname}」。能夠參考咱們的示例。

通用模式尤爲重要，由於您能夠藉此建立針對特定需求的數據結構。以數據庫鏈接爲例（如同一示例所示），該鏈接採用來自物理數據庫鏈接的反向工程表模式。「accounts」表包含12列，下方定義的匹配通用模式則有16列。額外的列用於將值元素添加到「accounts」表中，以及在做業數據流進程中用於併入其餘數據。相反，數據庫表也可能超過100列，而特定做業數據流只須要10列。可爲這10列定義通用模式，用於對具備匹配10列的表執行查詢。這項功能很是有用。所以我建議使用通用模式，除了可能僅有1列的結構，這在多數狀況下都適用，只需簡單內嵌便可。

請注意，其餘鏈接類型（如 SAP、Salesforce、NoSQL和Hadoop羣集）都可包含模式定義。

 

Log4J

Talend自6.0.1版開始支持Apache Log4J，並提供強大的Java日誌記錄框架。現在，全部Talend組件徹底支持Log4J服務，這改進了我先前博文中談到的錯誤處理方法。相信你們都已將這些最佳實踐歸入到自身項目當中，至少我但願如此。如今可使用Log4J進行進一步完善。

要使用Log4J，必須先啓用該服務，在「項目屬性」部分執行此操做。您還可在此調整團隊日誌記錄指導原則，爲控制檯(stderr/stdout)和LogStash追加器提供一致的消息傳遞範式。在單一位置定義這些追加器，經過這種簡單的方法，將Log4J功能歸入Talend做業中。請注意，Log4J語法中包含的級別值對應於咱們熟悉的INFO/WARN/ERROR/FATAL優先級。

建立做業運行任務時，可在Talend管理控制檯(TAC)啓用Log4J將要記錄的優先級。確保爲DEV/TEST和PROD環境正確設置此項。最佳作法是將DEV/TEST設置爲INFO級別，UAT設置爲WARN，PROD設置爲ERROR。更高級別也將包括在內。

Log4J與tWarn和tDie組件以及新日誌服務器結合使用，能夠真正強化對做業執行的監測和跟蹤。您可使用該功能，併爲團隊制定一項指導原則。

 

活動監控臺 (AMC)

Talend提供集成附加工具用於加強對做業執行的監測，進而可將詳細處理信息的收集活動合併到數據庫中。其中包括圖形界面，可從Studio和TAC予以訪問。該工具備助於開發者和管理員瞭解組件和做業交互，防止意外故障，並支持重要的系統管理決策。不過，您須要安裝 AMC數據庫和Web應用程序，這是一項可選功能。「Talend活動監控臺用戶指南」提供有關AMC組件安裝的詳細信息，此處再也不贅述。咱們重點來看與其使用相關的最佳實踐。

AMC數據庫包含三個表，分別爲：

- tLogCatcher - 捕獲從 Java 異常或tWarn/tDie組件發送的數據

- tStatCatcher - 捕獲從各個組件的tStatCatcher統計信息複選框發送的數據

- tFlowMeterCatcher - 捕獲從tFlowMeter組件發送的數據

這些表會存儲AMC UI的數據，基於這些數據提供做業活動的穩健可視化。請確保在「項目首選項」選項卡上選擇正確的日誌優先級設置，並仔細考慮對每種環境 (DEV/TEST/PROD) 的做業執行所施加的任何數據限制。在將版本推送到PROD環境以前，使用「主圖表」視圖來幫助識別和分析做業設計中的瓶頸。查看「錯誤報告」視圖，分析在指定時間段內發生的錯誤比例。

這一點很實用。但這些表的用途不只限於此。因爲它們確實是數據庫中的表，於是可編寫SQL查詢以從外部提取有價值的信息。使用腳本工具進行設置，若是某些條件發生並記錄在AMC數據庫中，能夠編制自動查詢和通知。在做業設計模式系列博文的第1部分中提到了既定「返回代碼」方法，藉助這種方法，這些查詢可以以編程方式執行自動化操做，經證實這一點很是有用。

 

恢復檢查點

若是您有一項長期運行做業，可能涉及多個關鍵步驟。若是某一特定步驟出錯，從新開始代價太大了。在發生錯誤以前，若是能儘可能減小在做業流指定點從新啓動做業所需的做業量和時間，固然再好不過。TAC提供做業遇到錯誤時專門執行恢復的工具。從策略性和前瞻性角度來看，使用這些「恢復檢查點」設計的做業無需重啓便可恢復執行並繼續處理。

發生故障時，可以使用TAC「錯誤恢復管理」選項卡來肯定錯誤，並在此啓動做業以繼續處理，這種方法很不錯，對吧？

 

小做業

咱們以前討論了小做業的概念，這類可重用做業代碼能夠根據須要「包含」在一項或多項做業中，但其本質上是什麼？小做業用例其實並很少，如有幸遇到，請善加利用。可經過不一樣方式構建和使用小做業，咱們如今就來看看吧。

新建小做業時，輸入/輸出組件會自動添加到畫布中。經過此快速啓動功能，您可使用小做業來分配出入做業工做流的模式。小做業的典型應用是經過其進行數據傳遞，內部執行的內容則由您決定。在下面的示例中，先傳入一行數據，隨即更新數據庫表，記錄到 stdout，而後將相同的行保持不變（在本例中）傳出。

非典型應用包括刪除輸入和/或輸出組件，以提供特殊案例數據/流程處理。在如下示例中，沒有任何內容傳入或傳出此小做業。相反，tLogCatcher組件會監控各類選定的異常狀況以進行後續處理（以前咱們在錯誤處理最佳實踐中已經看到過這種情形）。

顯然，使用小做業能夠顯著提升代碼的可重用性，這正是其初衷。可將這些小做業放入參考項目，使其惠及更多項目，持續發揮做用。

 

組件測試用例

若是您使用的還是6.0.1以前的Talend舊版，能夠忽略這項最佳實踐，或者不如直接升級！我最喜歡的新功能之一是在做業中建立測試用例。如今這些並不徹底是「單元測試」，而是組件測試；實際做業關聯至父做業，特別是正在測試的組件。並不是全部組件都支持測試用例。若是組件接受數據流輸入並將其送出，則可使用測試用例。

要建立組件測試用例，只需右鍵單擊所選組件，而後在底部的「建立測試用例」中找到菜單選項。選擇此選項後，將生成新做業，並打開該測試用例的功能模板。被測組件與內置的輸入和輸出組件一併由數據流打包，該數據流會直接讀取「輸入文件」，處理其中的數據並將記錄傳遞到被測組件，該組件隨後執行相應操做並將結果寫入新的「結果文件」。完成後，將該文件與預期結果或「參考文件」進行比較，根據匹配與否，斷定是否合格。- 簡單吧？咱們下面來看看。

如下是咱們以前見過的一項做業，採用tJavaFlex組件處理數據流，將其傳遞至下游以便進行進一步處理。

已建立一個測試用例做業，以下所示：無需做出修改（不過我稍稍清理了畫布）。

重要的是應瞭解，雖然您能夠修改測試用例做業代碼，但更改被測組件僅可在父做業中進行。比方說須要更改模式，在父做業（或存儲庫）中做出更改，測試用例將繼承該更改。它們以不可分割的方式鏈接，從而依照其模式進行耦合。

請注意，一旦建立了測試用例「實例」，就能夠建立多個「輸入」和「引用」文件來運行同一測試用例做業。這樣一來，不管測試數據好壞、大小和/或是否專用，都可進行測試。我建議不只要仔細評估待測試內容，還要評估待使用的測試數據。

最後，若是利用了Nexus項目存儲庫，並將測試用例做業及其父做業一塊兒存儲在該庫中，可使用諸如Jenkins的工具來自動執行這些測試，進而肯定做業是否適於推動至下一個環境。

 

數據流「迭代」

您確定已經注意到，在完成Talend代碼開發後，可使用「觸發器」進程或「行」數據流鏈接器將組件關聯在一塊兒。經過右鍵單擊起始組件並將連接「行」鏈接到下一個組件，能夠創建此關聯。進程流連接爲「OnSubJobOk/ERROR」、「OnComponentOK/ERROR」或「RunIF」，咱們在以前的博文中介紹過這些內容。鏈接時，數據流連接被動態命名爲「row {x}」，其中「x」是一個數字，由 Talend 動態分配以建立惟一的對象/行名稱。這些數據流連接固然能夠採用自定義名稱（命名約定最佳實踐），但創建此連接實質上會將數據模式從一個組件映射到另外一個組件，並會表示出經過其傳遞數據的「管道」。運行時經過此連接傳遞的數據一般被稱爲數據集。根據下游組件，完整數據集在封裝的子做業中進行端到端處理。

並不是全部數據集處理均可以像這樣一次完成，有時須要直接控制數據流，經過控制「逐行」處理或「迭代」來完成。來看下方圖中的無心義代碼：

請注意組件tIterateToFlow和tFlowToIterate。經過這些專用組件，您能夠逐行迭代數據集來控制數據流處理。這種「基於列表」的處理在須要時很是有用。但要注意的是，在許多狀況下，將數據流分解爲逐行迭代以後，您可能必須將其從新收集回完整數據集，而後才能繼續處理（例如所示的tMap）。這是因爲要求某些組件強制處理「行」數據集流，而且沒法處理「迭代」數據集流。另請注意，t{DB}Input組件在行菜單上提供「主」和「迭代」數據流選項。

請看示例場景：將數據流轉換爲列表，以及將文件列表轉換爲「Talend幫助中心和組件參考指南」中的數據流。這些場景有助於解釋如何使用此功能。能夠視須要使用此功能，並確保提供可讀標籤來描述您的目的。

 

 

 

結語

請將以上內容融會貫通！該專題的講解即將接近尾聲。本系列博文的第4部分將介紹最後一組做業設計模式和最佳實踐，確保爲構建良好的Talend代碼奠基堅實基礎。應以前的承諾，我會和你們探討「示範用例」。我認爲在開始論及抽象應用前，將全部這些最佳實踐融入已有經驗將大有助益。一如既往歡迎你們分享見解、提出問題乃至發表異議，爲本系列錦上添花！