关于java:数据批处理速度慢不妨试试这个

6次阅读

共计 3480 个字符，预计需要花费 9 分钟才能阅读完成。

业务零碎产生的明细数据通常要通过加工解决，依照肯定逻辑计算成须要的后果，用以反对企业的经营流动。这类数据加工工作个别会有很多个，须要批量实现计算，在银行和保险行业经常被称为跑批，其它像石油、电力等行业也常常会有跑批的需要。

大部分业务统计都会要求以某日作为截止点，而且为了不影响生产零碎的运行，跑批工作个别会在夜间进行，这时候能力将生产零碎当天产生的新明细数据导出来，送到专门的数据库或数据仓库实现跑批计算。第二天早上，跑批后果就能够提供给业务人员应用了。

和在线查问不同，跑批计算是定时主动执行的离线工作，不会呈现多人同时拜访一个工作的状况，所以没有并发问题，也不用实时返回后果。然而，跑批必须在规定的窗口工夫内实现。比方某银行的跑批窗口工夫是早晨 8:00 到第二天早上 7:00，如果到了早上 7:00 跑批工作还没有实现，就会造成业务人员无奈失常工作的严重后果。

跑批工作波及的数据量十分大，很可能用到所有的历史数据，而且计算逻辑简单、步骤泛滥，所以跑批工夫常常是以小时计的，一个工作两三小时是粗茶淡饭，跑到十个小时也难能可贵。随着业务的倒退，数据量还在一直减少。跑批数据库的累赘快速增长，就会产生整晚都跑不完的状况，重大影响用户的业务，这是无奈承受的。

要解决跑批工夫过长的问题，必须仔细分析现有的零碎架构中的问题。

跑批零碎比拟典型的架构大抵如下图：

从图上看，数据要从生产数据库取出，存入跑批数据库。跑批数据库通常是关系型的，编写存储过程代码实现跑批计算。跑批的后果个别不会间接应用，而是再从跑批数据库中导出，采纳接口文件的形式提供给其余零碎，或者再导入其余零碎数据库。这是比拟典型的架构，图中的生产数据库也可能是某个地方数据仓库或者 Hadoop 等。个别状况下，生产库和跑批库不会是同一种数据库，它们之间往往通过文件的形式传递数据，这样也比拟有利于升高耦合度。跑批计算实现后，后果要给多个利用零碎应用，个别也都是以文件形式传递。

跑批很慢的第一个起因，是用来实现跑批工作的关系数据库入库、出库太慢。因为关系数据库的存储和计算能力具备封闭性，数据的进出要做过多的束缚检查和平安解决，当数据量较大时，写入读出的效率非常低，耗时会十分长。所以，跑批数据库导入文件数据的过程，以及跑批计算结果再导出文件的过程都会很慢。

跑批很慢的第二个起因，是存储过程性能差。因为 SQL 的语法体系过于古老，存在诸多限度，很多高效的算法无奈施行，所以存储过程中的 SQL 语句计算性能很不现实。而且，业务逻辑比较复杂的时候很难用一个 SQL 实现，常常要分成多个步骤，用十几甚至几十个 SQL 语句能力实现。每个 SQL 的两头后果，都要存入长期表给后续步骤的 SQL 应用。长期表数据量较大时就必须落地，会造成大量的数据写出。而数据库的写出要比读入性能差很多，会重大拖慢整个存储过程。

对于更简单的计算，甚至很难用 SQL 语句间接实现，须要用数据库游标遍历取出数据，循环计算。但数据库游标遍历计算性能又要比 SQL 语句差很多，个别也都不间接反对多线程并行计算，很难利用多 CPU 核的计算能力，会让计算性能更加蹩脚。

那么，是否能够思考用分布式数据库来代替传统关系数据库，通过减少节点数量的方法，来进步跑批工作的速度呢？

答案依然是不可行。次要起因是跑批计算的逻辑相当简单，即便是用传统数据库的存储过程，也经常要写几千甚至上万行代码，而分布式数据库的存储过程计算能力还比拟弱，很难实现这么简单的跑批计算。

而且，当简单计算工作不得不分成多个步骤时，分布式数据库也面临两头后果落地的问题。因为数据可能在不同的节点上，所以前序步骤将两头后果落地，后续步骤再读取的时候，都会造成大量跨网络的读写操作，性能很不可控。

这时，也不能采纳分布式数据库依附数据冗余来晋升查问速度的方法。这是因为，查问之前能够事后筹备好多份冗余数据，然而，跑批的两头后果是长期生成的，如果冗余的话就要长期生成多份，整体的性能只会变得更慢。

所以，事实的跑批业务通常依然是应用大型单体数据库进行，计算强度太大时会采纳相似 ExaData 这样的一体机（ExaData 是多数据库，但被 Oracle 专门优化过，能够看成是个超大型单体数据库）。尽管很慢，然而临时找不到更好的抉择，只有这类大型数据库有足够的计算能力，所以只能用它来实现跑批工作了。

开源的业余计算引擎 SPL 提供了不依赖数据库的计算能力，间接利用文件系统计算，能够解决关系数据库出库入库太慢的问题。而且 SPL 实现了更优算法，性能远远超过存储过程，能显著进步单机计算效率，非常适合跑批计算。

利用 SPL 实现的跑批零碎新架构是上面这样的：

在新架构中，SPL 解决了造成跑批慢的两大瓶颈问题。

首先来看数据的入库、出库问题。SPL 能够间接基于生产库导出的文件计算，不用再将数据导入到关系数据库中。实现跑批计算后，SPL 还能将最终后果间接存储成文本文件等通用格局，传递给其余利用零碎，防止了原有跑批数据库的出库操作。这样一来，SPL 就省去了关系数据库迟缓的入库、出库过程。

上面再来看计算的过程。SPL 提供了更优的算法（有许多是业界独创），计算性能远远超过存储过程和 SQL 语句。这些高性能算法包含：

这些高性能算法能够利用于跑批工作中的常见 JOIN 计算、遍历、分组汇总等，能无效晋升计算速度。例如，跑批工作经常要遍历整个历史表。有些状况下，对一个历史表还要遍历好屡次，来实现多种业务逻辑的计算。历史表数据量个别都很大，每次遍历都要耗费很多的工夫。此时咱们能够利用 SPL 的 遍历复用 机制，仅对大表遍历一次，就能够同时实现多种计算，能够节俭大量工夫。

SPL 的 多路游标 能做到数据的并行读取和计算，即便是很简单的跑批逻辑，也能够利用多 CPU 核实现多线程并行运算。而数据库游标是很难并行的，这样一来，SPL 的计算速度经常能够达到存储过程的数倍。

SPL 的 提早游标 机制，能够在一个游标上定义多个计算步骤，之后让数据流按程序顺次实现这些步骤，实现 链式计算 ，可能无效缩小两头后果落地的次数。在数据必须落地的状况下，SPL 也能够将两头后果存成内置的高性能数据格式，供下一个步骤应用。SPL 高性能存储基于文件，采纳 有序压缩存储、自在列式存储、倍增分段、自有压缩编码 等技术，缩小了硬盘占用，读写速度要远远好于数据库。

SPL 在技术架构上突破了关系型跑批数据库存在的两大瓶颈，在理论利用中也获得了十分好的成果。

L 银行跑批工作采纳传统架构，以关系数据库作为跑批数据库，用存储过程编程实现跑批逻辑。其中，贷款协定存储过程须要执行 2 个小时，而且是很多其余跑批工作的前序工作，耗时这么久，对整个跑批工作造成了重大影响。

采纳 SPL 后，应用 高性能列存、文件游标、多线程并行、小后果内存分组、游标复用 等高性能算法和存储机制，将原来 2 个小时的计算工夫缩短为 10 分钟，性能进步 12 倍。

而且，SPL 代码更简洁。原存储过程 3300 多行，改为 SPL 后，仅有 500 格语句，代码量减少了 6 倍多，大大提高了开发效率。

P 保险公司的车险业务中，须要用今年历史保单来关联新的保单，在跑批中称为历史保单关联工作。原来也采纳关系数据库实现跑批，存储过程计算 10 天的新增保单关联历史保单，运行工夫 47 分钟；30 天则须要 112 分钟，靠近 2 小时；如果日期跨度更大，运行工夫就会长的无法忍受，根本就变成不可能实现的工作了。

采纳 SPL 后，利用了 高性能文件存储、文件游标、有序归并分段取出、内存关联 和遍历复用 等技术，计算 10 天新增保单仅需 13 分钟；30 天新增保单只须要 17 分钟，速度进步了近 7 倍。而且，新算法执行的工夫随着保单天数的增长并不是很大，并没有像存储过程那样成正比的增长。

从代码总量来看，原来存储过程有 2000 行代码，去掉正文后还有 1800 多行，而 SPL 的全副代码只有不到 500 格，不到原来的 1 /3。

T 银行通过互联网渠道发放贷款的明细数据，须要每天执行跑批工作，统计汇总指定日期之前的所有历史数据。跑批工作采纳关系数据库的 SQL 语句实现，运行总工夫 7.8 小时，占用了过多的跑批工夫，甚至影响了其余的跑批工作，必须优化。

采纳 SPL 后，利用了 高性能文件、文件游标、有序分组、有序关联、提早游标、二分法 等技术，原来须要 7.8 小时的跑批工作，单线程仅需 180 秒，2 线程仅需 137 秒，速度进步了 204 倍。