你真的需要ETL工具嗎？
阿新 • • 發佈：2019-01-30
不管是大資料領域，還是傳統的基礎資料領域，為了解決資料的流轉問題，都需要各種型別，適應異構環境的小程式來做支撐，通常我們稱之為ETL作業。
一想到做資料倉庫專案，大家的第一反應就是去選型各種ETL工具。我個人覺得並不是所有的應用場景都需要ETL工具。之前接觸過一個銀行的資料倉庫專案。他們是採用datastage做文字抽取，用oracle 儲存過程做資料轉換，還有一部分shell指令碼做檔案到達、磁碟清理和控制邏輯轉發的功能。然後用datastage的 sequence job 做業務翻牌控制。
這樣來看，他們的作業型別就相對單一。但datastage本身不太穩定，也滿足不了他們的排程控制邏輯需求。所以他們採用了shell指令碼來做一部分比較複雜的排程控制。
到最後datastage只作了一個文字抽取的功能。隨著該銀行業務系統的不斷擴建和增加，作業數規模越來越大。更主要的矛盾表現在ETL作業本身的管理成本上。
他們意識到，能不能管理好這麼多系統的作業，才是這些資料專案成功實施的關鍵。因此他們選用了國內的一款專業的ETL排程工具，來管理十幾個系統和上萬個作業。至於datastage的文字抽取作業，都被逐步改造為shell指令碼來做了。
到最後￥80w採購的datastage基本上就閒置了。 實際上就是十幾個系統和上萬個shell指令碼程式、oracle儲存過程以及ftp作業，的排程監控管理問題。
所以，我覺得如果作業型別單一、環境簡單的場景，就沒有必要用專門的ETL工具。作業數上規模的情況下，採購一款專業的ETL排程工具才是必要的。
如果企業內部作業型別過多、異構環境複雜、技術人員水平參差不齊的情況下，採用專業的ETL工具就有必要了，因為它降低了技術門檻。也許簡單的拖拽就能完成複雜的功能。
另外說一句，作業型別多、異構環境多從另一方面說明企業的IT管理不夠規範（或許是歷史原因）！在我看來ETL工具如同雞肋 “食之無肉，棄之有味”
一想到做資料倉庫專案，大家的第一反應就是去選型各種ETL工具。我個人覺得並不是所有的應用場景都需要ETL工具。之前接觸過一個銀行的資料倉庫專案。他們是採用datastage做文字抽取，用oracle 儲存過程做資料轉換，還有一部分shell指令碼做檔案到達、磁碟清理和控制邏輯轉發的功能。然後用datastage的 sequence job 做業務翻牌控制。
這樣來看，他們的作業型別就相對單一。但datastage本身不太穩定，也滿足不了他們的排程控制邏輯需求。所以他們採用了shell指令碼來做一部分比較複雜的排程控制。
到最後datastage只作了一個文字抽取的功能。隨著該銀行業務系統的不斷擴建和增加，作業數規模越來越大。更主要的矛盾表現在ETL作業本身的管理成本上。
他們意識到，能不能管理好這麼多系統的作業，才是這些資料專案成功實施的關鍵。因此他們選用了國內的一款專業的ETL排程工具，來管理十幾個系統和上萬個作業。至於datastage的文字抽取作業，都被逐步改造為shell指令碼來做了。
到最後￥80w採購的datastage基本上就閒置了。 實際上就是十幾個系統和上萬個shell指令碼程式、oracle儲存過程以及ftp作業，的排程監控管理問題。
所以，我覺得如果作業型別單一、環境簡單的場景，就沒有必要用專門的ETL工具。作業數上規模的情況下，採購一款專業的ETL排程工具才是必要的。
如果企業內部作業型別過多、異構環境複雜、技術人員水平參差不齊的情況下，採用專業的ETL工具就有必要了，因為它降低了技術門檻。也許簡單的拖拽就能完成複雜的功能。
另外說一句，作業型別多、異構環境多從另一方面說明企業的IT管理不夠規範（或許是歷史原因）！在我看來ETL工具如同雞肋 “食之無肉，棄之有味”