一、大數據下的ETL工具是否還使用Kettle
kettle 作為通用的ETL工具,非常成熟，應用也很廣泛，這里主要講一下 目前我們如何使用kettle的？
在進行大數據處理時，ETL也是大數據處理的主要場景之一。 針對大數據下的ETL, 在大數據研究之初，曾經花費很大精力去尋找大數據下比較成熟的ETL工具，但是不多。主要分類如下：
-
- 開源的圖形界面 類似 kettle 的nifi
- 命令形式的 如 sqoop、DataX
- 還有使用Spark 自定義開發ETL框架的
大數據下的ETL處理過程和傳統關系型數據庫下的ETL處理過程，我的理解本質還是一樣的，要說區別 可能是大數據下需要ETL處理的數據速度足夠快，這就要求可以充分利用分布式的能力，比如利用分布式的資源進行分布式的的計算。
基於使用經驗和產品成熟度，在大數據下我們針對一些對數據處理速度不是非常之高的場景，我們仍然使用kettle。 這里我為什么不說數據量，因為對於一個ETL過程，說數據量是無意義的，好的ETL工具的核心引擎一定是一個類似現在的流式計算
也就是說數據向水一樣的流動，流動的過程中做數據處理。也可kettle本身的含義類似。
基於個人的理解，任務kettle的優勢主要體現在以下幾點
- 設計時：
-
- 提供了成熟的圖形界面，相比命令行形式的etl工具，更容易被推廣應用
- 提供了豐富的各種數據庫類型的插件，數據轉換插件，涵蓋場景眾多
2.運行時
- 控制流和數據流的設計思想的划分
- 真正意義的數據流驅動的數據處理引擎，這一點也認為是同ESB等控制流產品不同的地方
- 通過多線程執行插件實例和分布式執行，提升執行速度
- 和目前大數據主流的數據庫進行集成，當然這個地方主要還是集成調用
3.可擴展性
-
- 良好的插件架構，保證了設計時和運行時的可擴展性
4.待完善點
- kettle 任務定義多了，當數據結構發生變化時，需要修改較多，最好有統一的數據對象管理
- kette的圖形化設計器雖然好用，但是web 化的設計器更容易多人使用，提升設計效率
目前kettle 的定位：
-
- 傳統關系型數據庫和大數據庫之間數據導入導出
- 基於關系型數據庫和大數據庫由數據驅動的簡單數據流任務
-
目前針對kettle做的擴展開發
-
插件開發
-
-
- 基於ES的sdk 開發ES的 input和output插件
- 封裝支撐Druid 數據導出的input 插件
- 封裝支持redis的插件
- 封裝支持調用Kylin build job的插件
- 封裝支持調用Tidb sql的插件
- 優化基於Azure wasb存儲的hbase input 和output 插件
- 調度集成
- 大數據下的調度主要使用的Ooize，界面上主要使用HUE，通過擴展開發HUE 的插件的形式 調用Kettle的web服務進行調度集成
- 待完善點
- kettle的商業版中包含了元數據管理，下一步需要將kettle中使用的表和字段，和大數據的數據治理集成
- kettle處理日志通過ELK將日志采集到ES進行進一步的分析
- kettle web 提高kettle任務的定義效率
-
- 二、核心執行邏輯
kettl的數據流處理過程，充分體現了其引擎對數據的流式處理過程。這里主要通過展現kettle 源碼序列圖的方式進行體現，希望大家可以通過這里的序列圖了解其執行的基本原理，也就方便進行插件的擴展開發和日常問題的解決。
2.2 數據流處理核心邏輯
2.2 數據流處理的核心序列
2.2.1 任務的執行頂層序列
-
2.2.2步驟的初始化
- 2.2.3 步驟的執行
每個步驟隊列的分配過程
數據放入隊列
- 2.2.4 具體步驟 -table input
2.2.5 table out put
以上 是kettle 核心數據流處理的核心過程。分享給大家