kettle开发-超好用自定义数据处理组件

简介: kettle开发-超好用自定义数据处理组件

前言:


       上节我们讲到使用主键+索引的方式来处理数据的新增,但是对会对历史数据进行增删改的操作就不好处理了。因此我们需要一种区别于现有功能的高效历史数据DML的操作。目前kettle在处理数据方面,常用组件,分别为“表输入”、“表输出”、“插入更新”、“执行SQL脚本”、“Java 代码”、“JavaScript代码”等。其中“表输入”就是用于读取数据,就不做过多的阐述。今天主要集中讲述,怎么优化“表输出”和“插入更新”组件的问题。

表输出每秒可以处理2万条记录左右

插入更新每秒只能处理400条记录左右


一、半斤八两,都不太行


1、表输出,速度快,但不稳妥


       从上面我们可以看到,表 输出的速度还是很nice的,但是我们只能使用裁剪表的形式来处理。就是非常暴力的把历史数据全面删除再全部插入进去,即我们常说的全量更新。 这种处理方式在万级数据下还是很好用,因为处理的时间很短,效率很高,前端用户也感觉不到影响。但如下图所示,当历史数据较多时,比如20万条,处理的时间会在30s左右,这种情况大概率会影响前端使用,在用户的眼里就是,哎怎么突然没有数据?哎,怎么我刚刚查有6条,怎么现在只有2条数据了?等等,数据不是少了就没有的数据真空期,我们也叫数据等待期。显然,我们针对超2万左右的历史数据,我们应该采用增量更新的方式。


2、稳的一批,但是慢的像蜗牛


       前面我们讲到,表输出虽然效率是插入更新的50倍,但是它再怎么快,也需要一定的运行时间,就会出现数据等待期。 数据等待期造成的后果就是影响前端用户使用。


  前面我们提到采用增量更新的方式来处理,因此我们深入 剖析下插入更新这个组件,使用插入更新有个大的前提就是需要一个主键,不管是单纯的主键id,还是联合主键iid。这个组件需要一个更新的关键字。

  当然,对于大多数的业务场景来说,我们都能找到唯一性的主键,因此这也不是大问题。现在我们来剖析下,插入更新,在性能层面的问题。


       如前言中,所说,插入更新每秒只能处理400条数据左右,效率只有表输入的1/50。因此插入更新能保证不影响前端使用,但是更新数据的时间成本较高。因此体现在前端的用户体验就是,哎,我们的数据一个小时了,怎么还没更新呢?哎,我们能不能实时显示数据呢?这种表现我们通常叫做数据延迟。对于医疗、零售等高响应式行业来说是不太能接受。因此,插入更新虽说能保证数据的完整、可用,但是效率跟不上。因此我们急需一种高效、稳的一批的组件用于企业数据处理。


二、各诉衷肠,合作共赢


1、表输出,高效数据插入


       表输出处理效率非常高的原因是,它不需对历史数据进行对比,耗时主要集中在表输入的数据读取时间+数据写入时间。因此速度堪比高铁,但高铁再怎么快,从长沙到上海也得几个小时呀。因此数据量大了,必然需要一定的处理耗时。但对业务来说是不能接受,不能接受在使用的时候缺数据或者少数据,或者数据前后不一致。


       当然我们不能说表输入就一文不值了,比如我们针对生产类的数据,比如机器运转数据,数据是跟着时间跑的,不存在历史数据的变动,此时我们就可以采用表输入,一直更新数据至数仓、数据湖等。就像一个水龙头,一直放水至蓄水池,水龙头的水永远是新的。当然,怎么去控制水龙头里面的水都是新的呢,我们可以参考我上一节的内容。

https://blog.csdn.net/qq_29061315/article/details/129011372


2、插入更新,一个都不能少


       通常我们在使用插入更新的时候,是为了保证数据的完整性,这样我们没必要去担心,我们数仓里面的数据会存在异常数据。通过主键来保证,每条数据都会被保存至数仓,当然也包括被删除的数据,通过我们在删除的操作是通过删除标识,比如dr等,当dr=0的时候是未删除的状态,当dr=1的时候,我们就证明数据被删除,虽然保证了数据的完整性。但是,速度确实忒慢了,但是为啥会这么慢呢?其实是因为每一条插入更新的数据都要和历史数据去做对比,看数据库是否存在,然后再进行插入,当历史数据较多时候,比较的耗时就会比较长。因此此时,数据的耗时就表现在表输入数据读取时间+数据对比时间+数据更新插入时间。


       因此相比较,表输入,插入更新的耗时较多表现在数据对比耗时和更新数据耗时。这也是为啥插入更新的效率是表输入的1/50。


       因此插入更新常用于,基础档案数据方面和历史数据增量较小的场景。


       总的来说,我们需要一种表输出组件的高效和插入更新的完整性,因为我们有没有办法,通过组件的整合来达到这个目的呢?


三、表输入的高效+插入更新的完整性


1、思路


       前面我们讲到了,我们需要表输出的高效,又需要插入更新的完整性。因此我们需要定位数据耗时较长的环节。在传统的插入更新场景中,我们是一条一条的数据去对比,然后更新插入的。那我们能不能先一次性完成数据的对比,再一次性把数据进行插入呢。这时候我们的耗时有了保障,而且准确完整性也达到了要求。具体实现的作业思路如下图所示。

        因此我们的作业最后包括,数据对比+数据插入。下面我们详细讲解下这两个组件。


2、数据对比


在这里,我们应用到合并记录的功能,我们用新旧数据合并,来标记对应数据是被删除、更新、新增、还是没变的来标记数据的状态。对应转换如下图所示。

合并记录的应用场景可以参考我的历史文章:

https://blog.csdn.net/qq_29061315/article/details/129401286


最后我们保持到数据库的效果是这样的。用另外一个表来保持对应每条记录的状态。

这一步相当于我们将需要处理的数据,都整理好了


3、数据插入


此时我们再利用,插入更新组件来处理少量的数据即可。这样在保证数据完整性的同时也保证了速度。    


4、效果查看


       如下图所示,我们一共比较了4万多条数据,真正要处理的数据就55条左右,整个过程耗时在5秒左右, 平均时速是8000条/s,效率是插入更新的20倍,可以满足企业大部分的应用场景了。当然这些场景的基础都是能找到唯一性主键,如果我们是没有唯一性主键的情况,我们又该怎么去组合处理呢?下一节将讲解,另一种自定义必杀技。

相关文章
|
8月前
|
数据可视化 索引
可视化拖拽组件库一些技术要点原理分析(二)
可视化拖拽组件库一些技术要点原理分析(二)
73 0
|
8月前
|
数据可视化 JavaScript
可视化拖拽组件库一些技术要点原理分析(二)(上)
可视化拖拽组件库一些技术要点原理分析(二)
51 1
|
8月前
|
数据可视化 API
可视化拖拽组件库一些技术要点原理分析(三)(二)
可视化拖拽组件库一些技术要点原理分析(三)(二)
68 0
|
8月前
|
数据可视化 JavaScript 前端开发
可视化拖拽组件库一些技术要点原理分析(一)
可视化拖拽组件库一些技术要点原理分析(一)
146 0
|
8月前
|
存储 编解码 数据可视化
可视化拖拽组件库一些技术要点原理分析(三)
可视化拖拽组件库一些技术要点原理分析(三)
66 0
|
8月前
|
数据可视化 API
可视化拖拽组件库一些技术要点原理分析(三)(一)
可视化拖拽组件库一些技术要点原理分析(三)
45 0
|
8月前
|
数据可视化 前端开发 JavaScript
可视化拖拽组件库一些技术要点原理分析(四)(下)
可视化拖拽组件库一些技术要点原理分析(四)(下)
46 0
|
8月前
|
JSON 数据可视化 前端开发
可视化拖拽组件库一些技术要点原理分析(二)(下)
可视化拖拽组件库一些技术要点原理分析(二)(下)
78 0
|
8月前
|
数据可视化 JavaScript
可视化拖拽组件库一些技术要点原理分析(四)(上)
可视化拖拽组件库一些技术要点原理分析(四)
53 0
可视化拖拽组件库一些技术要点原理分析(四)(上)
|
8月前
|
数据可视化 API 索引
可视化拖拽组件库一些技术要点原理分析(三)(三)
可视化拖拽组件库一些技术要点原理分析(三)(三)
100 0

热门文章

最新文章