大数据etl工具有哪些

ETL是数据仓库中的非常重要的一环，是承前启后的必要的一步。ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。

下面给大家介绍一下什么是ETL以及ETL常用的三种工具——Datastage，Informatica，Kettle。

一、什么是ETL？

ETL，Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。

数据仓库结构

通俗的说法就是从数据源抽取数据出来，进行清洗加工转换，然后加载到定义好的数据仓库模型中去。目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。

ETL是BI项目重要的一个环节，其设计的好坏影响生成数据的质量，直接关系到BI项目的成败。

二、为什么要用ETL工具？

在数据处理的时候，我们有时会遇到这些问题：

▶ 当数据来自不同的物理主机，这时候如使用SQL语句去处理的话，就显得比较吃力且开销也更大。

▶ 数据来源可以是各种不同的数据库或者文件，这时候需要先把他们整理成统一的格式后才可以进行数据的处理，这一过程用代码实现显然有些麻烦。

▶ 在数据库中我们当然可以使用存储过程去处理数据，但是处理海量数据的时候存储过程显然比较吃力，而且会占用较多数据库的资源，这可能会导致数据资源不足，进而影响数据库的性能。

而上述遇到的问题，我们用ETL工具就可以解决。ETL工具具有以下几点优势：

1、支持多种异构数据源的连接。（部分）

2、图形化的界面 *** 作十分方便。

3、处理海量数据速度快、流程更清晰等。

三、ETL工具介绍

1、Datastage

IBM公司的商业软件，最专业的ETL工具，但同时价格不菲，适合大规模的ETL应用。

使用难度：★★★★

2、Informatica

商业软件，相当专业的ETL工具。价格上比Datastage便宜一点，也适合大规模的ETL应用。

使用难度：★★

3、Kettle

免费，最著名的开源产品，是用纯java编写的ETL工具，只需要JVM环境即可部署，可跨平台，扩展性好。

使用难度：★★

四、三种ETL工具的对比

Datastage、Informatica、Kettle三个ETL工具的特点和差异介绍：

1、 *** 作

这三种ETL工具都是属于比较简单易用的，主要看开发人员对于工具的熟练程度。

Informatica有四个开发管理组件，开发的时候我们需要打开其中三个进行开发，Informatica没有ctrl+z的功能，如果对job作了改变之后，想要撤销，返回到改变前是不可能的。相比Kettle跟Datastage在测试调试的时候不太方便。Datastage全部的 *** 作在同一个界面中，不用切换界面，能够看到数据的来源，整个job的情况，在找bug的时候会比Informatica方便。

Kettle介于两者之间。

2、部署

Kettle只需要JVM环境，Informatica需要服务器和客户端安装，而Datastage的部署比较耗费时间，有一点难度。

3、数据处理的速度

大数据量下Informatica与Datastage的处理速度是比较快的，比较稳定。Kettle的处理速度相比之下稍慢。

4、服务

Informatica与Datastage有很好的商业化的技术支持，而Kettle则没有。商业软件的售后服务上会比免费的开源软件好很多。

5、风险

风险与成本成反比，也与技术能力成正比。

6、扩展

Kettle的扩展性无疑是最好，因为是开源代码，可以自己开发拓展它的功能，而Informatica和Datastage由于是商业软件，基本上没有。

7、Job的监控

三者都有监控和日志工具。

在数据的监控上，个人觉得Datastage的实时监控做的更加好，可以直观看到数据抽取的情况，运行到哪一个控件上。这对于调优来说，我们可以更快的定位到处理速度太慢的控件并进行处理，而informatica也有相应的功能，但是并不直观，需要通过两个界面的对比才可以定位到处理速度缓慢的控件。有时候还需要通过一些方法去查找。

8、网上的技术文档

Datastage < Informatica < kettle,相对来说，Datastage跟Informatica在遇到问题去网上找到解决方法的概率比较低，kettle则比较多。

五、项目经验分享

在项目中，很多时候我们都需要同步生产库的表到数据仓库中。一百多张表同步、重复的 *** 作，对开发人员来说是细心和耐心的考验。在这种情况下，开发人员最喜欢的工具无疑是kettle，多个表的同步都可以用同一个程序运行，不必每一张表的同步都建一个程序，而informatica虽然有提供工具去批量设计，但还是需要生成多个程序进行一一配置，而datastage在这方面就显得比较笨拙。

在做增量表的时候，每次运行后都需要把将最新的一条数据 *** 作时间存到数据库中，下次运行我们就取大于这个时间的数据。Kettle有控件可以直接读取数据库中的这个时间置为变量；对于没有类似功能控件的informatica，我们的做法是先读取的数据库中的这个时间存到文件，然后主程序运行的时候指定这个文件为参数文件，也可以得到同样的效果

一、 引言

信息是现代企业的宝贵资源，是企业运用科学管理、决策分析的基础。目前，大多数企业花费大量的资金和时间来构建联机事务处理(OLTP)的业务系统和办公自动化系统，从而记录事务处理的业务数据。遗憾的是，业务系统产生的数据增长很快，一般情况下，两到三年的时间，数据量就会成倍增长，这些丰富的、蕴含巨大商业价值的数据，所关注的通常只占在总数据量的2%到4%。从而企业将会失去有价值的客户、失去提高客服质量的指引、无法制定出最佳的营销手段和策略、等等。无论何种性质的企业，没有最大化的利用已存在的数据资源，都将浪费更多的时间和资金，也失去制定关键商业决策的最佳契机。

商业智能(BI,Business Intelligence) 就是为企业把数据转换为信息、知识，相应蕴育而出的IT技术。企业级BI的基础就是一个完整的、准确的、统一视角的数据平台，即DW(Data warehousing),而本文则要详细论述构建DW关键过程ETL的简介及必要性。

二、 术语描述

ETL：Extract-Transform-Load的缩写，数据抽取（Extract）、转换（Transform）、装载（Load）的过程。

DW：Data Warehousing，根据BillInmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”。

Metadata：元数据。描述数据的数据，指在数据仓库建设过程中所产生的有关数据源定义，目标定义，转换规则等相关的关键数据。

三、 ETL是数据仓库建立的核心过程

数据仓库系统先天不足，是在业务系统的基础上发展而来的，其内部存储的数据来自于事务处理的业务系统和外部数据源。而企业内各源数据缺少统一的标准，因企业的业务系统是在不同时期、不同背景、面对不同应用、不同开发商等各种客观前提下建立的，其数据结构、存储平台、系统平台均存在很大的异构性。因而其数据难以转化为有用的信息，原始数据的不一致性导致决策时其可信度的降低。

ETL是BI/DW的核心和灵魂，按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL规则设计和实施则是工作量最大的，其工作量要占整个项目的60%-80%，这是国内外从众多实践中得到的普遍共识。

四、 ETL过程的主要目的

就是以最小代价(包括对日常 *** 作的影响和对技能的要求) 将针对日常业务 *** 作的数据转化为针对数据仓库而存储的决策支持型数据

对于做过 BI 开发的朋友，ETL 并不陌生，只要涉及到数据源的数据抽取、数据的计算和处理过程的开发，都是 ETL，ETL 就这三个阶段，Extraction 抽取，Transformation 转换，Loading 加载。

从不同数据源抽取数据 EXTRACTION ，按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION，最后处理完成的输出到目标数据表中也有可能是文件等等，这个就是 LOADING。

再通俗一点讲，ETL 的过程就跟大家日常做菜一样，需要到菜市场的各个摊位买好菜，把菜买回来要摘一下，洗一洗，切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源，做好的菜就是最终的输出结果，中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。

在开发的时候，大部分时候会通过 ETL 工具去实现，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等，在结合基本的 SQL 来实现整个 ETL 过程。

也有的是自己通过程序开发，然后控制一些数据处理脚本跑批，基本上就是程序加 SQL 实现。

哪种方式更好，也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的，碰到数据类项目会比较喜欢用程序控制跑批，这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发，当然也有一上来就写程序脚本的，这类 BI 开发人员的师傅基本上是程序人员转过来的。

用程序的好处就是适配性强，可扩展性强，可以集成或拆解到到任何的程序处理过程中，有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求，经验转移和可复制性不够。

用 ETL 工具的好处，第一是整个 ETL 的开发过程可视化了，特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候，各种数据源、数据库的链接协议已经内置了，直接配置就可以，不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用，起到简化的代替一部分 SQL 的开发，不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则，高度配置化，这个也不需要写代码实现。

所以在大多数通用的项目中，在项目上使用 ETL 标准组件开发会比较多一些。

ETL 从逻辑上一般可以分为两层，控制流和数据流，这也是很多 ETL 工具设计的理念，不同的 ETL 工具可能叫法不同。

控制流就是控制每一个数据流与数据流处理的先后流程，一个控制流可以包含多个数据流。比如在数据仓库开发过程中，第一层的处理是ODS层或者Staging 层的开发，第二层是 DIMENSION维度层的开发，后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。

数据流就是具体的从源数据到目标数据表的数据转换过程，所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节，目标数据表的链接，这两个直接通过 ETL 控件配置就可以了。中间转换的环节，这个时候就可能有很多的选择了，调 SQL 语句、存储过程，或者还是使用 ETL 控件来实现。

有的项目上习惯使用 ETL 控件来实现数据流中的转换，也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。

我们通常讲的BI数据架构师其实指的就是ETL的架构设计，这是整个BI项目中非常核心的一层技术实现，数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流，每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章，大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计，还有很深的ETL项目管理和规范性控制器思想，包括后期的运维，基于BI的BI分析，ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL，框架的顶层设计就很重要。

显然不对。

百度百科可以看下ETL定义：ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。

这个源端到目的端不是说数据库之间的抽取才叫源端到目的端。数据库内部的数据加工也是啊，贴源层的数据到明细层也是，明细层到汇总层也是。而且你理解的ODS层之前的ETL过程实际就是抽取的过程，那么还有转换和清洗呢？清洗不仅仅是脏数据的清洗，也包括业务逻辑上的清洗，转换也是一样，不仅仅是映射关系的转换，也包含了业务逻辑的整合汇总等等。

实际上把抽过来的数据最终整合成使用方可方便使用的数据的整个过程都可以叫做ETL。

而目前的市场上来说职位上叫ETL或者数仓已经没有很明显的区分了，特别是互联网行业。我招一个ETL实际上就是干数仓的活，招一个数仓那你实际上也包含了ETL的能力。

准确的来说，商业智能BI不仅仅包含前端可视化分析、报表展现的能力，更包含了底层数据仓库的建设过程。

Gartner 在上世纪九十年代就已经提到了商业智能 Business Intelligence，它更多的认为BI是一种数据类的技术解决方案，将许多来自不同企业业务系统的数据提取有分析价值的数据进行清洗、转换和加载，就是抽取Extraction、转换 Transformation、加载Loading 的ETL过程，最终合并到一个数据仓库中，按照一定的建模方式例如Inmon 的3NF 建模、Kimball 的维度建模或者两者都有的混合式架构模型，最终在这个基础上再利用合适的分析展现工具来形成各种可视化的分析报表为企业的管理决策层提供数据决策支撑。

所以，可以从这里能够看到数据仓库Data Warehouse 的位置是介于可视化报表和底层业务系统数据源之间的这一层，在整个BI项目解决方案中起到的是一个承上启下的作用。所以，BI在前端可视化分析层面要玩出各类精彩的动作，没有数据仓库这个核心力量的支撑是很难做到的。

那大家也会问到，市面上不是有很多直接链接数据源就可以拖拉拽分析的BI工具产品吗，不也一样可以做BI分析报表吗？这种独立的、单独的面向前端的BI分析工具，他们更多的定位是部门级和个人级的BI 分析工具，对于深层次的需要复杂数据处理、集成、建模等很多场景是无法解决的。最好的方式就是底层构建一套完整的数据仓库，把很多分析模型标准化，再利用这些前端BI分析工具结合起来，这样才能真正的把前端BI分析能力给释放出来。

很多企业认为只要买一个前端BI分析工具就可以解决企业级的BI所有问题，这个看法实际上也不可行的。可能在最开始分析场景相对简单，对接数据的复杂度不是很高的情况下这类BI分析工具没有问题。但是在企业的BI项目建设有一个特点，是一个螺旋式上升的建设过程。因为对接的业务系统可能会越来越多，分析的深度和广度会越来越多，数据的复杂度也会越来越有挑战性，这个时候没有一个很好的数据仓库架构支撑，光靠前端BI分析工具基本上是无法搞定的。

所以在企业中，我们需要明确我们的BI建设是面向企业级的还是个人和部门的分析工作。如果是个人数据分析师，使用这类前端BI分析工具就足够了。如果是需要构建一个企业级的BI项目，就不能只关注前端可视化分析能力这个层面，更应该关注到底层数据架构的构建，也就是数据仓库这个层面。

以上就是关于大数据etl工具有哪些全部的内容，包括:大数据etl工具有哪些、etl 的含义和介绍、ETL是什么,形象的介绍一下等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！