Kettle中ETL的效率优化

背景

Kettle是什么?

Kettle是一款开源的ETL工具,目前由Pentaho公司在管理。该工具包含一个可视化界面,可以用来设计、运行、调试ETL,被很多公司广泛采用。

Github 传送门

Community 传送门

ETL是什么?

ETL(Extract、Transform、Load)即抽取、转换、加载,是对异构数据源进行数据处理的一个部分。

ETL的主要功能

数据抽取

从源数据源系统抽取目的数据源系统需要的数据;

数据转换

将从源数据源获取的数据按照业务需求,转换成目的数据源要求的形式,并对错误、不一致的数据进行清洗和加工。

数据加载

将转换后的数据装载到目的数据源。 ETL 原本是作为构建数据仓库的一个环节,负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中,成为联机分析处理、数据挖掘的基础。现在也越来越多地将ETL应用于一般信息系统中数据的迁移、交换和同步。

本文要解决的问题

目前ETL有一些中文的资料,但大多数都是怎么使用等基础文章,相对深入的一些如性能优化方面的资料相对较少。我结合前段时间的工作经验,以及查阅的官网文档、官方论坛及圈内知名人士的博客,总结了Kettle中ETL效率优化的文档,供大家学习和参考

ETL效率优化

开启数据库日志记录及性能监控

如果我们想要优化一个ETL(KTR或者KJB)的性能,我们首先需要知道的就是它的瓶颈在哪里。而这些信息一般只能在ETL运行的步骤度量中看到,并且是不会持久化的。如果你希望把一些数据记录下来,帮助以后进行查阅,那么可以开启数据库日志和性能监控。

作业

Edit -> Settings -> Log

具体设置过程就不细讲了,很简单。

转化

Edit -> Settings -> Logging

这时开启了日志记录,还需要设置性能监控

Edit -> Settings -> Monitoring

勾选 Enable step performance monitoring(开启性能监控),下面的两个选项分别是:

Step performance measurement interval(ms) (对每一步进行性能监测的度量间隔):这一个选项的大小会影响你在数据库记录的详细程度,一般以运行总时长的十分之一左右的数值即可,这样对于每一步可以记录10组左右的数据,足够做一些基本的分析,注意单位是毫秒。

Maximum number of snapshots in memory(在内存中保存的最大的快照数量):这一个选项在我们系统的内存不是很足够时可以使用,但是太小可能会导致无法分析出来,和上面的选项搭配使用。

转化的错误日志输出

我们在运行过程中会输出大量日志,这样我们在定位问题的时候需要去日志里找出错的位置在哪里。Kettle中可以对KTR单独配置日志,如果我们把KTR的错误日志直接输出出来,那么在定位问题的时候就会非常方便,设置的方法如下:

在Job中,选择需要输出错误日志的步骤(经常出错或者可能出错的步骤),编辑,选择Logging,勾选Specfify Logfile(指定日志文件),选择路径、后缀,日志级别选择错误日志(调试时可以选详细或者行级)。
后面的选项:
Append logfile(追加到日志文件):该选项是指日志输出到已有文件中。
Create parent folder(创建父文件夹):该选项是指如果给定的路径中有不存在的文件夹会自动创建。
Include date in logfile:日志中包含日期。
Include time in logfile:日志中包含时间。

数据库优化

因为ETL就是对异构数据库中数据的处理,因此绝大部分性能问题都是和数据库相关,本节内容从数据库配置、ETL优化、SQL优化等方面进行讲解

数据库配置

连接池配置

数据库连接池在业务数据量比较多,而且短连接很多的时候适合配置。在这个时候,每次数据库连接建立和断开所花费的时间远长于进行数据库操作的时间,配置连接池可以更好的利用网络资源,将连接建立和断开的开销降低到最小。因此在大多数情况下,配置Kettle数据库连接池均可提高ETL的性能,如果没有配置连接池,那么在数据量大时候很容易出现Error Connecting Database Error。

该设置主要是在创建及管理连接的部分:

数据库连接 -> 连接池 -> 使用连接池
设置连接池的大小及相应参数,这些参数需要根据数据库实际情况及使用情况进行配置,可以咨询DBA。
数据库参数设置

在数据库连接的面板中,选择“选项”,(上面两个是普通和高级),在参数列表中,根据情况添加以下参数:

defaultRowPrefetch = 200; (default = 10) 

这个参数是修改每次从数据库取回的记录的行数,默认为10,修改为200后可以减少从数据库取值的次数。

(Oracle Only) readTimeout = 60;  

这个参数是修改从数据库读数据时的超时时间,单位是秒,将这个值改大一点可以防止大量数据读取时的超时问题

(Mysql Only) useServerPrepStmts=false;
rewriteBatchedStatements=true ; useCompression=true ;

前两个参数会让数据库重排Insert语句,合并多条插入语句成为一条,提交插入效率。第三个参数表示在传输时开启数据压缩 ,提高传输效率。这些在使用table output的时候很有效,在配置充足且网络正常的情况下应该可以达到20k~80k的写入速度。

ETL优化

提高数据库操作中的Commit Size

在写入数据库的时候,有一个Commit size的选项,这个值在默认的情况下是1,我们可以根据服务器的性能,将这个值改大一些,通常会改为100以上的值。这个值在写入量比较大的时候可以显著提升数据库的性能,但是并不是越大越好,通常范围在100〜10000,需要根据实际情况进行配置,具体数值可以根据性能监控的记录来确定。

这个值从1调整到合适值性能大约可以翻倍,一般情况下也有20%左右的效率提升。

Insert/Update增加错误处理步骤分离Insert和Update

Kettle的原作者在他的博客中提到过,尽量不要使用Insert/Update组件,因为这个组件慢的他都受不了,正常情况下在几百条每秒(对比TableInsert几万的速度)。如果必须使用这个组件的时候,那么可以在Insert/Update中勾选Don't perform any updates(不做任何更新操作),然后把错误的数据指向一具数据库更新的操作,这要就把添加和更新分离了开来。根据官网描述,在少量更新大量插入的时候性能可以提高到原来的3倍左右,实测时达不到,可能和数据集有关。

数据库分组和排序优于ETL分组和排序

在ETL中减少排序和分组的操作,尽量使用数据库完成排序和分组。在KTR中,数据是使用流的方式在不同的步骤间传递数据,使用排序和分组的操作会在这一步阻塞KTR的执行,直到接收到前面所有步骤传过来的数据为止,导致ETL的运行时间增长,占用的内存增大。

使用Blocking Step也会将流阻塞到这一步,和以上情况类似。

调整步骤之间的缓存

KTR是一个流式的处理过程,步骤与步骤之间的数据传递是通过缓存来完成的,调整缓存的大小可以对KTR的运行产生明显的影响。

Edit  —> Settings —>  Miscellaneous —> Nr of rows in rowset (缓存的记录行数)

这个值的大小需要根据机器的配置来选择,如果可用内存足够,一般的设置是10000,也就是缓存10000行数据,如果内存比较紧张,可以将该值调小一些,保证不会占用过量内存。

在性能监测时,这也是一个用来找到瓶颈的核心参数。如果某一步的输入和配置的缓存大小接近,但是输出很小,那么这一步就是性能的瓶颈。如果缓存大小配置了10000,但是几乎所有步骤的输入输出都只有很低的一个值,比如50,那么,性能的瓶颈就是输入。

延迟转化

很多字段在读入到最后输出,实际上都没有被操作过,开启延迟转化可以让kettle在必要的时候再进行转化。这里的转化是指从二进制到字符串之间的转化,在输入和输出都是文本的时候更为明显。事实上,Select Values在转化的效率上也高于读取时直接转化。

使用复制并行处理某个步骤

现在的机器都是多核的,使用多CPU并行处理对CPU使用密集的步骤可以提升ETL的执行效率。

在需要并行处理的步骤上,选择Change Number of Copies to Start, 修改这个值为小于机器核心总数的一个值,一般2〜4就可以满足要求。

KTR中,尽量减少步骤的数量

步骤的数量会在影响KTR的执行效率,包含并行处理时复制的数量。KTR中步骤的数量为机器核心总数的3〜4倍最佳,如果超过这个范围,可以考虑通过减少步骤数量的方式以提高KTR的执行效率。

不要在Select Values的步骤删除某个字段

如果在Select Values的步骤删除某个字段,kettle会需要调整现有的存储结构,在可以不删除的时候尽量不要删除字段。

SQL优化

这部分和所有使用到数据库的地方一样,优化查询语句,优化表结构设计,添加合适的索引等。

其它优化

  • 使用Carte管理KJB和KTR减小内存消耗
  • 使用定时器定时处理
  • 使用集群并行运行
  • 使用数据仓库及缓慢更新进行同步增量更新

总结

总体来说,这部分的内容主要就是数据库配置的优化及ETL本身的优化,当然在提高效率的时候也要兼顾资源的使用情况,有的方法可以提高效率,但是会消耗更多资源。因此我们需要综合考虑,通过一些合理的方式既能充分的利用资源,又不会因压力过大影响业务的正常进行。

ETL可以看作是一个可视化的、数据处理领域的编程工具,因此,ETL编写过程不仅需要了解业务,还需要一些数据库方面的知识进行支持,如果写出来的ETL效率低下,运行时间长,吃资源多,那么,是时候需要考虑优化一下ETL了。.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容