背景
用java编写的典型monolith etl批处理应用程序有一系列的步骤，这些步骤一个接一个地运行。通常，一步的输出变成下一步的输入；但是，也有这样的用例，其中一些步骤对输入数据执行聚合，并使用聚合的结果来重新充实每个单独的输入记录。
在我几周前发布的这个问题中，我提供了一个用例，在这个用例中，monolith批处理应用程序跨整个输入数据集派生聚合量，然后使用这些聚合量在每个记录级别重新派生属性。这个例子只涵盖了monolith批处理应用程序所做的一小部分计算。实际上，这种性质的步骤还有很多，因此每一步都依赖于前一步的结果来履行其职责。
我将把巨大的整体式批处理应用程序分解成更小的批处理应用程序，这样每个单独的批处理步骤都可以在kubernetes pod中独立运行。为了促进这种体系结构，我正在尝试添加一个消息代理（kakfa、rabbitmq等），它可以促进从一个批处理步骤到另一个批处理步骤的数据交换，第一步在消息到达输入主题/队列时开始。messagebroker允许我分离不同批处理步骤之间的交互。它还允许我为每个批处理步骤添加更多的pod。
问题定义：
虽然中间使用MessageBroker允许我将系统分解为多个部分，但它引入了一个我在使用单个进程monolith时不必担心的问题：
“如何计算跨越整个数据集的运行总计（例如，总事务量）以及将这些聚合结果存储在何处？”
由于输入数据（事务）现在正在跨多个pod进行处理，因此需要一个集中的位置，在这里可以计算和存储运行总量（事务总量）。
到目前为止我试过的
从链接的问题中可以看到，我尝试了Kafka流和ktable。然而，这种体系结构很快就会遇到一些问题，比如当聚合的键与输入源（topic）使用的键不同时，需要在磁盘上重新划分数据。对于一个不太关心实时处理的批处理应用程序来说，仅仅为了能够执行不同类型的聚合而重新划分数百万条记录似乎是一个巨大的性能开销。
我有什么选择
这就是我问问题的地方。我计算运行总数的选项是什么？以前有人遇到过这个用例吗？您是如何解决的？
对于monolith应用程序，是否可以使用nosql数据库来代替简单的hashmap？但是，计算运行总数需要大量的读写操作，所以数据库真的是正确的选择吗？
我不知所措。