ETL作業調度工具TASKCTL的兩個重大突破

在傳統設計理念下，流程圖的可視化、作業流的定義設計功能，隨著作業量增加，越來越難用，越來越不適用是一個難以避免的問題。就這兩個問題，我給大家分享一下TASKCTL是如何轉變思路、如何突破、如何帶來一些更理想的效果。同時，我也希望通過此次分享，帶來一些拋磚引玉的效果，希望業界更多同仁，就批量調度技術更多的問題，敢於突破，使整個批量調度技術變得更完善、更易用。

第一部分：兩大問題的再分析

在傳統理念下，流程圖可視化與作業流程定義方式不適用這兩大問題，並不是孤立的，它們之間是相互影響，並相互惡化的。它們問題的核心都來源於一個共同的設計理念。

（一）傳統作業依賴關係組織方式是兩大問題的共同根源

（二）對作業設計方式的影響：對話框方式不如Excel方式

（1）對話框方式不如Excel方式的原因

首先，是對作業設計方式的影響。從信息組織的記錄特徵出發，我們很容易想到對話屬性框的設計方式。通過每個屬性框的輸入，完成作業各種屬性信息的定義。但當我們面臨大量作業信息的編輯時，很快就會發現對話框還不如直接編輯Excel。在Excel中，無論對更多信息的查看、編輯、拷貝、粘貼，都比對話框方便得多。

也許，你會說，我用的不是對話框方式，而是圖形拖拽方式設計，很直觀的。但實際上，拖拽編輯的直觀是表面現象，背後依然是繁瑣的對話框方式。這也是很多專業的調度軟體，在實際使用場景中，寧願選擇 Excel方式主要原因之一。使用拖拽，可能只有兩種情況，一是新手，二是唯一的設計方式（比如ETL工具），你沒有更良好的選擇。

（2）Excel帶來的新問題

如果我們只關注編輯管理效率，相比對話框方式，Excel顯然得到很大提升。但Excel的作業設計方式，又帶來以下兩個難以避免的問題：

第一個問題：離線方式，與系統不能實時互動。我們採用了excel方式，單從編輯的角度，是提高不少效率。但Excel畢竟是第三方軟體，不能與你的系統實時互動，它不能真實理解你每個屬性的含義，不能實時檢驗你的信息，比如重複性，合法性。這一切，可能只有在導入的時候才知道。這些需求需求，你可能說，我可以通過二次開發Excel完成。沒錯，你可以做到。但我只想說，早知如此，何必當初，你又何必在調度軟體里費那麼大的力氣，設計相應的對話框作業定義功能呢？

第二個問題：作業關係梳理很麻煩。採用excel，由於是離線的方式，在excel中，我們很難實時直觀的知道作業之間的關係，這對於作業間的依賴關係設計、修改，都變得非常困難。

（3）如果Excel方式是好的選擇，那我們就應該多點匠心，多點優化。

雖然Excel有以上兩個問題，但客觀上，它的編輯管理效率比單純的對話框方式，要高出很多。既然這樣，我們為什麼不多點匠心，將excel平面表格的方式集成到調度軟體當中，這至少會使用戶體驗度，得到大幅度的提升。

（三）對流程圖可視化的影響：線條大量交叉、排版混亂使流程圖缺失直觀性

（1）關係的自由組織，客觀上難以避免凌亂的關係

由於作業之間的依賴關係，採用屬性定義的方式，使你可自由定義作業間的多個依賴關係，但隨著作業數的增多，你就很難控制這些關係的實際形狀。一張蜘蛛網似的關係圖，可能就此誕生了。

（2）人工編輯圖形，同樣難以避免凌亂的關係線條

為了避免凌亂的線條，你可能會想到圖形編輯方式。畢竟在圖形的嚮導下，可避免一些複雜的線條。但隨著作業數的增多，首先是編輯變得異常困難，其次是在增刪改的過程當中，線條的重構，重新排版帶來的工作量也是你難以想像。也許,你會想到自動排版，但這種沒規則的關係，在作業數多的情況下，其效果可能比你想像的還要糟糕許多。

（四）兩個問題相互影響，相互惡化

總之，在這種信息組織理念下，如果採用圖形拖拽，對話框方式，也許會減少很多凌亂的線條，使關係變得清晰一些，但這種方式又帶來巨大的編輯工作量。如果採用Excel方式以提高編輯工作效率，那一定會給你帶來難以接受的關係圖。這兩種矛盾，在目前設計理念下，是難以協調的。

第二部分：TASKCTL的突破

在TASKCTL理念框架下，不論作業數多少，作業間的關係線條，始終是無交叉、清晰、直觀的，而且還沒有圖形編輯的繁瑣。在IDE環境下，設計再多的作業，也比Excel似的設計，更為快捷、更為高效。而TASKCTL這些突破性的變化，更為理想的效果，主要是因兩大理念的轉換所帶來的。

（一）作業依賴關係組織理念突破

（1）從自由組織理念到結構化組織理念

傳統作業間的關係信息組織是自由的，但在TASKCTL中是結構化的，通過串並組的方式組織作業之間的依賴並行關係。

一個傳統表達方式：

同樣的關係在TASKCTL中的表達方式：

（2）TASKCTL流程圖本質上是一張有序無環圖

TASKCTL採用這種串並組結構化組織，本質上就不可能具備交叉現象，是一張有序無環圖。

以下是一張TASKCTL流程圖示例。

（3）TASKCTL對有序無環圖缺陷的彌補

對於有序無環圖這種圖形關係表達理念，在大數據領域比較普遍。無論是底層基於資源的任務調度邏輯，還是OOZIE（一款大數據領域的作業流調度工具）業務工作流調度邏輯，都是採用有序無環的關係表達理念。但同時，我們也要知道，這種邏輯管理組織理念，有一種缺陷，就是無法做到一些交叉關係表達。比如以下關係：

在任何一門計算機語言當中，可能都有類似GOTO這樣的語句，實現一些靈活的關係跳轉。但我們都知道，為了增強信息的可管理型、可讀性，盡量採用結構化語句編寫，而GOTO，盡量避免。在TASKCTL中，LEAN就像GOTO一樣，作業關係我們盡量用結構化串並組嵌套方式表達，而LEAN這種靈活的表達方式，還是少用為好。

（二）作業整體信息組織理念的突破

（1）從單純記錄信息到結構化，規則化的「代碼」信息

在傳統作業信息組織方式下，是以每個作業為一個獨立的設計單位，而在TASKCTL中，是以一個結構或多個結構為設計單位；傳統的焦點是每個作業個體，而TASKCTL更傾向於一個更大的整體。TASKCTL站在一個整體特徵的角度，設計了相應的規則，並以XML格式進行表達。實際上，TASKCTL的設計信息更像具有一定語法規則的代碼，並引入了很多代碼語法理念，比如if語句、各種函數、屬性繼承、重載以及自由注釋等。

（2）從配置理念到開發理念

傳統作業信息組織是記錄式表達，而TASKCTL是用具有一定語法規則的結構化代碼來表達。記錄採用配置概念，而代碼顯然採用開發概念。傳統為了方便記錄的配置，設計了相應的對話框；而TASKCTL，為了方便文本代碼的開發，設計了相應的IDE環境。

傳統方式，之所以更願意選擇Excel對更多記錄的配置，其核心原因是Excel是一個平面文件。相比一個個對話框，平面文件更便於信息瀏覽、查看、編輯。而TASKCTL信息本身就採用格式代碼的方式，本身就是一個平面文件。IDE設計的目的，只是為了更好的管理、設計開發TASKCTL的代碼文件。

如果站在另一個緯度，傳統Excel方式配置和TASKCTL代碼方式開發，都是為了產出一個有規則的文件的話，一個是採用普通文件編輯器編輯，而另一個是採用針對這種規則設計的特殊編輯器（IDE）進行編輯。

我們知道，JAVA程序的設計，是可以直接通過簡單的記事本來完成，但我們還是要採用更強大的eclipes進行開發設計，中間的差距，不言而喻。

文章摘自博客園

更多精彩推薦

IT教育專業培訓：http://www.ujiuye.com/?wt.bd=lsw

IT職業在線教育：http://xue.ujiuye.com/

互聯網營銷集訓營：http://www.ujiuye.com/zt/zsjz/?wt.bd=lsh11tt

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！