ETL-kettle 核心执行逻辑

一、大数据下的ETL工具是否还使用Kettle

kettle 作为通用的ETL工具,非常成熟，应用也很广泛，这里主要讲一下 目前我们如何使用kettle的？

在进行大数据处理时，ETL也是大数据处理的主要场景之一。 针对大数据下的ETL, 在大数据研究之初，曾经花费很大精力去寻找大数据下比较成熟的ETL工具，但是不多。主要分类如下：

• • 开源的图形界面 类似 kettle 的nifi
  • 命令形式的 如 sqoop、DataX
  • 还有使用Spark 自定义开发ETL框架的

大数据下的ETL处理过程和传统关系型数据库下的ETL处理过程，我的理解本质还是一样的，要说区别 可能是大数据下需要ETL处理的数据速度足够快，这就要求可以充分利用分布式的能力，比如利用分布式的资源进行分布式的的计算。

基于使用经验和产品成熟度，在大数据下我们针对一些对数据处理速度不是非常之高的场景，我们仍然使用kettle。 这里我为什么不说数据量，因为对于一个ETL过程，说数据量是无意义的，好的ETL工具的核心引擎一定是一个类似现在的流式计算

也就是说数据向水一样的流动，流动的过程中做数据处理。也可kettle本身的含义类似。

基于个人的理解，任务kettle的优势主要体现在以下几点

1. 设计时：

• • 提供了成熟的图形界面，相比命令行形式的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 核心数据流处理的核心过程。分享给大家