乐趣区

利用ABAP-740的新关键字REDUCE完成一个实际工作任务

ABAP 740 从 2013 年发布至今已经过去很长的时间了,下面这张图来自 SAP 社区博客:

ABAP News for Release 7.40 – What is ABAP 7.40?

图中的 ABAP 8.0, 即现在的 SAP Cloud for Customer 和 Business By Design 后台使用的 ABAP 版本 NGAP – Next Generation ABAP Platform,里面存在不少只在 8.0 版本可用的关键字和语言特性。

因为 C4C 和 BYD 的 ABAP 后台,客户和 partners 们是无法访问的,所以咱们回到 ABAP 740 这个版本。从该版本开始,ABAP 支持了很多新的关键字和语法特性,“看起来有点不像传统的 ABAP 编程语言了”。

本文咱们就来看一个具体的例子:ABAP 740 里的一个新关键字 REDUCE. 这个关键字的作用和在大规模数据集并行计算领域里广泛使用的 ”Map-Reduce” 编程模型中的 Reduce 操作类似,可以按照字面意思理解为“归约”。

下图是 Map Reduce 框架的工作步骤,统计一个海量输入数据集 (比如大于 1TB) 中的单词出现次数。作为 ABAP 开发人员,我们没必要了解 Map Reduce 框架的每个执行步骤,只需紧盯框架的输入,以及执行结果就行了。

回到 Jerry 接受的实际工作任务。德国同事让 Jerry 在某个 CRM 测试系统上做个统计,列出在数据库表 CRM_JSTO 里,OBTYP(Object Type)和 STSMA(Status Schema)这两列拥有相同值的内表行的个数。大家可以把 ”OBTYP 和 STSMA 两列具有相同值的内表行 ” 类比成上图中重复出现的单词。

下图是 CRM_JSTO 的部分行:

下图是 Jerry 完成的任务: 测试系统上内表一共有 55 多万行,其中有 90279 行,只维护了 OBTYP 为 TGP,而没有维护 STSMA. 排名第二的是 COH 和 CRMLEAD 的组合,出现了 78722 次。

稍稍做过一些 ABAP 开发的朋友们,一定会立即写出下面的代码:

利用 SELECT COUNT 直接在数据库层完成统计工作。这也是 SAP 推荐的做法,所谓 Code pusudown 准则,即能放到 HANA 数据库层面进行的操作,就尽量放进去,以充分利用 HANA 强大的计算能力。在数据库能够完成计算逻辑的前提下,尽量避免把计算逻辑放到 Netweaver ABAP 应用层去做。

不过,我们也需要注意到这种方式的局限性。Jerry 之前曾经引用过 SAP CTO 的名言:

  • There is no future with ABAP alone
  • There is no future in SAP without ABAP

未来的 ABAP 会走向开放,互联的道路。回到这个需求本身,假设待检索的输入数据不是从 ABAP 数据库表中来,而是来自 HTTP 请求,或者第三方系统发过来的 IDOC,此时我们无法再使用 OPEN SQL 本身的 SELECT COUNT 操作,而只能在 ABAP 应用层解决这个问题。

所谓技多不压身,Jerry 这里介绍两种用 ABAP 完成这个需求的方式。

第一种方式比较传统,实现在方法 get_result_traditional_way 里:

ABAP 的 LOOP AT GROUP BY 这个关键字组合简直就像是为这个需求量身定做一般:给 GROUP BY 指定 obtyp 和 stsma 这两列,然后 LOOP AT 会自动将输入内表的行记录根据这两列的值进行分组,每组行记录的个数通过关键字 GROUP SIZE 自动计算出来,每组各自的 obtyp 和 stsma 的值,以及组内行记录的条目数,存储在 REFERENCE INTO 指定的变量 group_ref 里。ABAP 顾问需要做的事情,只是简单地把这些结果存储到输出内表即可。

第二种办法,就是本文标题所述,使用 ABAP 740 新的 REDUCE 关键字:

上面的代码乍一看可能觉得有点晦涩,但仔细阅读后发现这种方式本质上也采用了和方法一 LOOP AT GROUP BY 同样的分组策略——根据 obtyp 和 stsma 分组,这些子组通过变量 <group_key> 标识,然后通过第 10 行的 REDUCE 关键字,通过累加的方式,手动计算这个组的条目数——把一个大的输入集根据 GROUP BY 指定的条件归约成一个个规模更小的子集,然后分别针对子集进行计算——这就是 REDUCE 关键字通过字面含义传递给 ABAP 开发人员的处理思想。

总结和比较一下这三种实现方式:当待统计的数据源为 ABAP 数据库表时,一定优先选用 OPEN SQL 的方式,使计算逻辑在数据库层完成,以获得最佳的性能。

当数据源并非 ABAP 数据库表,而分组统计的需求为简单的计数操作 (COUNT) 时, 优先用 LOOP AT … GROUP BY … GROUP SIZE,使得计数操作通过 GROUP SIZE 在 ABAP kernel 完成,以获得较好的性能。

当数据源并非 ABAP 数据库表,而分组统计的需求为自定义的逻辑时,用本文介绍的第三种 REDUCE 解法,将自定义统计逻辑写在第 11 行的 NEXT 关键字后。

这三种解法的性能依次递减,不过适用的场合和灵活程度依次递增。

LOOP AT … GROUP BY … GROUP SIZE,在 Jerry 的服务器上处理 55 万条记录,用了 0.3 秒,而 REDUCE 则需花费 0.8 秒。

本文提到的所有 ABAP 代码均可从我的 SAP 博客获得:

A real case to use REDUCE to finish a task in daily work

感谢阅读。

要获取更多 Jerry 的原创文章,请关注公众号 ” 汪子熙 ”:

退出移动版