背景

在實際開發中，出於業務邏輯或者處理效率的考慮，在某一支job下，會涉及到並行執行多個transformation，等這些transformation執行完成後，再執行後續的transformation的情況。從流程的角度來看，就是分支 + 主幹的關係；從job的設計界面來看，呈現的是一個橄欖型結構，如圖： （其中，轉換1 xx和轉換2 xx是分支，轉換3 xx是主幹） 略違反直覺的是，這種含有++N+1個++分支transformation的job設計中，主幹transformation的執行次數為++N+1次++，而非一眼看上去的主幹會在所有分支執行完成後再執行一次。 此時，應當把每一條分支路線均理解為獨立的線路：分支n完成後，由於它自己還連了主幹，主幹勢必會執行，主幹執行次數等於傳遞到主幹本身的連線數（如無其他判斷條件）。

溯因 & 探討

接下來，我們實際運行一下這個job，查看他的log，不難發現，主幹transformation確實執行了4次。 那麼，這樣的job設計就和我們的初衷背道而馳了：我們需要的是等所有分支全部都執行完成後，在運行主幹，但現在，每一支分支執行完，主幹都會執行一次，會影響後續的業務邏輯。

方案

那麼，該如何對job設計進行修改呢？可參考站內博文： Kettle系列: Kettle並行執行Trans後的合併問題 利用生成文件以及等待文件組件生成一個表徵前序步驟已經執行完成的信號文件，保證所有分支全部執行完成後，再執行主幹。 其中，筆者認為，對於N+1個分支的job，只需創建N個信號文件即可，理由如下： 任選一個分支連線至主幹，這種情況下，要執行主幹，就需要知道其他N個分支的完成情況，對於一個分支而言，只有執行完成和執行未完成兩種情況，其餘的N個分支完成情況即為2^N種，由信息論的基本公式，我們可得出只需要log2^N(即N)個bit來標識這一信息，這也就意味着我們僅需N個信號文件，即可保證主幹是在所有分支執行完成後再執行。