ETL的工具应用

ETL工具的典型代表有:Informatica、Datastage、OWB、微软DTS、Beeload、Kettle、久其ETL……

开源的工具有eclipse的etl插件:cloveretl

数据集成：快速实现ETL

ETL的质量问题具体表现为正确性、完整性、一致性、完备性、有效性、时效性和可获取性等几个特性。而影响质量问题的原因有很多，由系统集成和历史数据造成的原因主要包括:业务系统不同时期系统之间数据模型不一致；业务系统不同时期业务过程有变化；旧系统模块在运营、人事、财务、办公系统等相关信息的不一致；遗留系统和新业务、管理系统数据集成不完备带来的不一致性。

实现ETL，首先要实现ETL转换的过程。体现为以下几个方面：

1、空值处理：可捕获字段空值，进行加载或替换为其他含义数据，并可根据字段空值实现分流加载到不同目标库。

2、规范化数据格式：可实现字段格式约束定义，对于数据源中时间、数值、字符等数据，可自定义加载格式。

3、拆分数据：依据业务需求对字段可进行分解。例，主叫号 861082585313-8148，可进行区域码和电话号码分解。

4、验证数据正确性：可利用Lookup及拆分功能进行数据验证。例如，主叫号861082585313-8148，进行区域码和电话号码分解后，可利用Lookup返回主叫网关或交换机记载的主叫地区，进行数据验证。

5、数据替换：对于因业务因素，可实现无效数据、缺失数据的替换。

6、Lookup：查获丢失数据 Lookup实现子查询，并返回用其他手段获取的缺失字段，保证字段完整性。

7、建立ETL过程的主外键约束：对无依赖性的非法数据，可替换或导出到错误数据文件中，保证主键唯一记录的加载。

kettle是一个ETL工具，ETL（Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程）。

kettle中文名称叫水壶，该项目的主程序员MATT 希望把各种数据放到一个壶里，然后以一种指定的格式流出。

所以他的重心是用于数据

oozie是一个工作流，Oozie工作流是放置在控制依赖DAG（有向无环图 Direct Acyclic Graph）中的一组动作（例如，Hadoop的Map/Reduce作业、Pig作业等），其中指定了动作执行的顺序。

oozie工作流中是有数据流动的，但是重心是在于工作流的定义。

二者虽然都有相关功能及数据的流动，但是其实用途是不一样的。

查看帮助

列举出所有linux上的数据库

列举出所有Window上的数据库

查看数据库下的所有表

（1）确定mysql服务启动正常

查询控制端口和查询进程来确定，一下两种办法可以确认mysql是否在启动状态

办法1：查询端口

MySQL监控的TCP的3306端口，如果显示3306，证明MySQL服务在运行中

办法二：查询进程

可以看见mysql的进程

没有指定数据导入到哪个目录，默认是/user/root/表名

原因:

如果表中有主键,m的值可以设置大于1的值;如果没有主键只能将m值设置成为1;或者要将m值大于1,需要使用--split-by指定一个字段

设置了-m 1 说明只有一个maptask执行数据导入,默认是4个maptask执行导入 *** 作,但是必须指定一个列来作为划分依据

导入数据到指定目录

在导入表数据到HDFS使用Sqoop导入工具，我们可以指定目标目录。使用参数 --target-dir来指定导出目的地，使用参数—delete-target-dir来判断导出目录是否存在，如果存在就删掉

查询导入

提示：must contain '$CONDITIONS' in WHERE clause。

where id <=1 匹配条件

$CONDITIONS：传递作用。

如果 query 后使用的是双引号，则 $CONDITIONS前必须加转义符，防止 shell 识别为自己的变量。

--query时不能使用--table一起使用

需要指定--target-dir路径

导入到hdfs指定目录并指定要求

数据导出储存方式（数据存储文件格式---（ textfil parquet）--as-textfileImports data as plain text (default)--as-parquetfile Imports data to Parquet Files）

导入表数据子集到HDFS

sqoop导入blob数据到hive

对于CLOB，如xml文本，sqoop可以迁移到Hive表，对应字段存储为字符类型。

对于BLOB，如jpg，sqoop无法直接迁移到Hive表，只能先迁移到HDFS路径，然后再使用Hive命令加载到Hive表。迁移到HDFS后BLOB字段存储为16进制形式。

213导入关系表到Hive

第一步:导入需要的jar包

将我们mysql表当中的数据直接导入到hive表中的话，我们需要将hive的一个叫做hive-exec-110-cdh5140jar的jar包拷贝到sqoop的lib目录下

第二步:开始导入

导入关系表到hive并自动创建hive表

们也可以通过命令来将我们的mysql的表直接导入到hive表当中去

通过这个命令，我们可以直接将我们mysql表当中的数据以及表结构一起倒入到hive当中去

--incremental 增量模式。

append id 是获取一个某一列的某个值。

lastmodified “2016-12-15 15：47：35” 获取某个时间后修改的所有数据

-append 附加模式

-merge-key id 合并模式

--check-column 用来指定一些列，可以去指定多个列；通常的是指定主键id

--last -value 从哪个值开始增量

==注意:增量导入的时候,一定不能加参数--delete-target-dir 否则会报错==

第一种增量导入方式(不常用)

1Append方式

使用场景：有个订单表，里面每个订单有一个唯一标识的自增列id，在关系型数据库中以主键的形式存在。之前已经将id在0-1000之间的编号的订单导入到HDFS 中；如果在产生新的订单，此时我们只需指定incremental参数为append，--last-value参数为1000即可，表示只从id大于1000后开始导入。

（1）创建一个MySQL表

（2）创建一个hive表（表结构与mysql一致）

注意：

append 模式不支持写入到hive表中

2lastModify方式

此方式要求原有表有time字段，它能指定一个时间戳，让sqoop把该时间戳之后的数据导入到HDFS；因为后续订单可能状体会变化，变化后time字段时间戳也会变化，此时sqoop依然会将相同状态更改后的订单导入HDFS，当然我们可以只当merge-key参数为order-id，表示将后续新的记录和原有记录合并。

# 将时间列大于等于阈值的数据增量导入HDFS

使用 lastmodified 方式导入数据，要指定增量数据是要 --append（追加）还是要 --merge-key（合并）last-value 指定的值是会包含于增量导入的数据中。

第二种增量导入方式(推荐)

==通过where条件选取数据更加精准==

215从RDBMS到HBase

会报错

原因：sqoop146 只支持 HBase101 之前的版本的自动创建 HBase 表的功能。

解决方案：手动创建 HBase 表

导出前，目标表必须存在与目标数据库中

默认 *** 作是将文件中的数据使用insert语句插入到表中

数据是在HDFS当中的如下目录/sqoop/emp，数据内容如下

第一步：创建MySQL表

第二步：执行导出命令

通过export来实现数据的导出，将hdfs的数据导出到mysql当中去

全量导出

增量导出

更新导出

总结:

参数介绍

--update-key 后面也可以接多个关键字列名，可以使用逗号隔开，Sqoop将会匹配多个关键字后再执行更新 *** 作。

--export-dir 参数配合--table或者--call参数使用，指定了HDFS上需要将数据导入到MySQL中的文件集目录。

--update-mode updateonly和allowinsert。 默认模式为updateonly，如果指定--update-mode模式为allowinsert，可以将目标数据库中原来不存在的数据也导入到数据库表中。即将存在的数据更新，不存在数据插入。

组合测试及说明

1、当指定update-key，且关系型数据库表存在主键时：

A、allowinsert模式时，为更新目标数据库表存的内容，并且原来不存在的数据也导入到数据库表；

B、updateonly模式时，为更新目标数据库表存的内容，并且原来不存在的数据也不导入到数据库表；

2、当指定update-key，且关系型数据库表不存在主键时：

A、allowinsert模式时，为全部数据追加导入到数据库表；

B、updateonly模式时，为更新目标数据库表存的内容，并且原来不存在的数据也不导入到数据库表；

3、当不指定update-key，且关系型数据库表存在主键时：

A、allowinsert模式时，报主键冲突，数据无变化；

B、updateonly模式时，报主键冲突，数据无变化；

4、当不指定update-key，且关系型数据库表不存在主键时：

A、allowinsert模式时，为全部数据追加导入到数据库表；

B、updateonly模式时，为全部数据追加导入到数据库表；

实际案例:

(1)mysql批量导入hive

使用shell脚本：

笔者目前用sqoop把mysql数据导入到Hive中，最后实现命令行导入，sqoop版本147，实现如下

最后需要把这个导入搞成job，每天定时去跑，实现数据的自动化增量导入，sqoop支持job的管理，可以把导入创建成job重复去跑，并且它会在metastore中记录增值，每次执行增量导入之前去查询

创建job命令如下

创建完job就可以去执行它了

sqoop job --exec users

可以把该指令设为Linux定时任务，或者用Azkaban定时去执行它

hive导出到MySQL时，date类型数据发生变化？

问题原因：时区设置问题，date -R查看服务器时间，show VARIABLES LIKE "%time_zone"查看Mysql时间，system并不表示中国的标准时间，要将时间设置为东八区

（1）：对市面上最流行的两种调度器，给出以下详细对比，以供技术选型参考。总体来说，ooize相比azkaban是一个重量级的任务调度系统，功能全面，但配置使用也更复杂。如果可以不在意某些功能的缺失，轻量级调度器azkaban是很不错的候选对象。

（2）：功能：

两者均可以调度mapreduce,pig,java,脚本工作流任务；

两者均可以定时执行工作流任务；

（3）：工作流定义：

Azkaban使用Properties文件定义工作流；

Oozie使用XML文件定义工作流；

（4）：工作流传参：

Azkaban支持直接传参，例如${input}；

Oozie支持参数和EL表达式，例如${fs:dirSize(myInputDir)}；

（5）：定时执行：

Azkaban的定时执行任务是基于时间的；

Oozie的定时执行任务基于时间和输入数据；

（6）：资源管理：

Azkaban有较严格的权限控制，如用户对工作流进行读/写/执行等 *** 作；

Oozie暂无严格的权限控制；

（7）：工作流执行：

Azkaban有两种运行模式，分别是solo server mode(executor server和web server部署在同一台节点)和multi server mode(executor server和web server可以部署在不同节点)；

Oozie作为工作流服务器运行，支持多用户和多工作流；

（8）：工作流管理：

Azkaban支持浏览器以及ajax方式 *** 作工作流；

Oozie支持命令行、>

两个工程师的发展方向不同，主要是侧重的方向不同：

etl工程师，主要技术发展方向侧重与数据库、或大批量数据处理方向，

今后可以向数据库开发工程师、数据库架构师、数据分析师等方面发展。

java工程师，主要侧重软件开发方向，就是程序编程，也可以逐步发展为高级程序员、系统架构师等。

但是发展不是绝对的，主要看个人的机会和发展环境，不能绝对的说哪个好，哪个不好。

不包括数据审核。

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

大学计算机专业数据库方向：

1、数据库应用开发(applicationdevelopment)

除了基本的SQL方面的知识，还要对开发流程，软件工程，各种框架和开发工具等等

数据库应用开发这个方向上的机会最多，职位最多。

2、数据建模专家(datamodeler)

除了基本的SQL方面的知识，非常熟悉数据库原理，数据建模负责将用户对数据的需求转化为数据库物理设计和物理设计，这个方向上在大公司（金融，保险，研究，软件开发商等）有专门职位，在中小公司则可能由程序员承担。

3、商业智能专家(business-BI)

主要从商业应用，最终用户的角度去从数据中获得有用的信息，涉及OLAP(onlineanalyticalprocessing)，需要使用SSRS,cognos,crystalreport等报表工具，或者其他一些数据挖掘，统计方面的软件工具。

4、ETL开发(ETLDeveloper)

使用ETL工具或者自己编写程序在不同的数据源之间对数据进行导入，导出，转换，所接触的数据库一般数据量非常大，要求进行的数据转换也比较复杂和数据仓库和商业智能的关系比较密切。在一些数据库应用规模很大的公司里面有专门的职位，中小公司里面则可能由程序员或者DBA负责这方面的工作。

5、数据构架师(DataArchitect)

主要从全局上制定和控制关于数据库在逻辑这一层的大方向，也包括数据可用性，扩展性等长期性战略，协调数据库的应用开发，建模，DBA之间的工作。这个方向上在大公司（金融，保险，研究，软件开发商等）有专门职位，在中小公司或者没有这个职位，或者由开发人员，DBA负责。

6、数据库管理员(database-DBA)

数据库的安装，配置，调优，备份/恢复，监控，自动化等，协助应用开发（有些职位还要求优化SQL，写存储过程和函数等）。这个方向上的职位相对少一些，但一般有点规模的公司还是会有这样的职位

7、数据仓库专家(datawarehouse-DW)

应付超大规模的数据，历史数据的存储，管理和使用，和商业智能关系密切，很多时候BI和DW是放在一个大类里面的，但是我觉得DW更侧重于硬件和物理层上的管理和优化。

8、存储工程师(storageengineer)

专门负责提供数据存储方案，使用各种存储技术满足数据访问和存储需求，和DBA的工作关系比较密切。对高可用性有严格要求（比如通信，金融，数据中心等）的公司通常有这种职位，这种职位也非常少。

9、性能优化工程师(performanceengineer)

专长数据库的性能调试和优化，为用户提供解决性能瓶颈方面的问题。也有专门的性能优化工程师，负责为其数据库产品和关键应用提供这方面的技术支持。对数据库性能有严格要求的公司（比如金融行业）可能会有这种职位。因为针对性很强，甚至要求对多种数据库非常熟悉，所以职位极少。

10、高级数据库管理员(seniorDBA)

在DBA的基础上，还涉及上面3种职位的部分工作，具体包括下面这些：对应用系统的数据（布局，访问模式，增长模式，存储要求等）比较熟悉。对性能优化非常熟悉，可以发现并优化从SQL到硬件I/O，网络等各个层面上的瓶颈，对于存储技术相对熟悉，可能代替存储工程师的一些工作，对数据库的高可用性技术非常熟悉（比如MSSQL的集群，ORACLERAC/FailSafe,IBM的DPF,HADR等），对大规模数据库有效进行物理扩展（比如表分区）或者逻辑扩展（比如数据库分区，联合数据库等）。熟悉各种数据复制技术，比如单向，双向，点对点复制技术，以满足应用要求。灾难数据恢复过程的建立，测试和执行。这种职位一般只在对数据库要求非常高并且规模非常大（比如金融，电信，数据中心等）的公司需要，而且这种公司一般有一个专门独立负责数据库的部门或组。这种职位非常少。

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，我们的做法是先读取的数据库中的这个时间存到文件，然后主程序运行的时候指定这个文件为参数文件，也可以得到同样的效果

对于做过 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的工具应用、调度工具（ETL+任务流）、JAVA工程师与ETL工程师哪个前景好等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！