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

目录

前言:

一、半斤八两,都不太行

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

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

二、各诉衷肠,合作共赢

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

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

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

        1、思路

        2、数据对比

        3、数据插入

         4、效果查看

前言:

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

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

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

一、半斤八两,都不太行

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

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

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

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

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

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

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

二、各诉衷肠,合作共赢

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

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

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

kettle开发-Day37-SQ索引优化_他们叫我技术总监的博客-CSDN博客说是kettle开发优化,不如说是SQ的优化或者说是思路的优化,我们在走路的同时记得抬头看天。https://blog.csdn.net/qq_29061315/article/details/129011372

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

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

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

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

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

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

        1、思路

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

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

        2、数据对比

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

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

kettle开发篇-合并记录-Day26_kettle合并记录_他们叫我技术总监的博客-CSDN博客前言: 昨天我们讲了数据库相关操作,流查询,通过流查询我们进行等值查询,从而实现类似数据库内连接的效果,今天我们来讲一个类似的组件,叫合并记录,合并记录顾名思义就是将数据进行合并,具体来讲就是将两个不同来源的数据合并,这两个来源的数据分别为旧数据和新数据,该步骤将旧数据和新数据按照指定的关键字匹配、比较、合并。一、合并记录今天我们讲的连接是转换里面的第八个分类。连接是结果集通过关键字进行连..._kettle合并记录https://blog.csdn.net/qq_29061315/article/details/129401286        最后我们保持到数据库的效果是这样的。用另外一个表来保持对应每条记录的状态。

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

        3、数据插入

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

         4、效果查看

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

本文链接:https://my.lmcjl.com/post/1241.html

展开阅读全文

4 评论

留下您的评论.