Kiba是一个非常小的库，据我所知，它的大部分价值都来自于实施小型独立转换的模块化架构。
然而，在我看来，一系列串行转换的模型并不适合我们面临的大多数ETL问题。为了解释这个问题，让我举一个人为的例子：
源产生具有以下结构的散列
{ spend: 3, cost: 7, people: 8, hours: 2 ... }
我们首选的输出是一个散列列表，其中一些密钥可能与源密钥相同，尽管值可能不同
{ spend: 8, cost: 10, amount: 2 }
现在，计算结果支出需要一系列转换：ConvertCurrency, MultiplyByPeople等。计算成本也是如此：ConvertCurrencyDifferently, MultiplyByOriginalSpend。。请注意，成本计算取决于原始(未转换(支出值。
最自然的模式是计算两个独立管道的支出和成本，并合并最终输出。一个地图缩小模式，如果你愿意的话。我们甚至可以从并行运行管道中受益。
然而，在我的情况下，这实际上不是性能问题(因为转换非常快(。问题是，由于Kiba将所有转换应用为一组串行步骤，成本计算将受到支出计算的影响，我们最终会得到错误的结果。
木叶有办法解决这个问题吗？我唯一能想到的就是确保目的地名称与源名称不相同，例如"originalSpend"one_answers"finalSpend"。然而，我仍然感到困扰的是，我的支出计算管道必须确保为每个步骤传递全套密钥，而不仅仅是传递与之相关的密钥，然后最终合并成本密钥。或者，可以定义两个独立的kiba作业，并让主作业调用这两个作业，最终合并它们的结果？对此，最常用的kiba解决方案是什么？
将ETL管道拆分为多个并行路径似乎是大多数ETL工具的一个关键功能，所以我很惊讶kiba似乎不支持它？
我想我缺少额外的细节来正确回答您的主要问题。这一轮我将通过电子邮件联系，稍后可能会在这里发表评论，以提高公众知名度。
将ETL管道拆分为多个并行路径似乎是大多数ETL工具的一个关键功能，所以我很惊讶kiba似乎不支持它？
Kiba ETL目前的主要关注点是：组件复用、更低的维护成本、模块化和具有强大数据和功能的能力；工艺质量。
不过，通过不同的模式，在一定程度上支持并行化。
使用Kiba Pro并行转换运行姐妹作业
如果你的主要输入是你可以设法"；分区"；对于少量项目(例如数据库id范围或文件列表(，您可以使用Kiba Pro并行转换，如下所示：
source ... # something that generate list of work items
parallel_transform(max_threads: 10) do |group_items|
Kiba.run(...)
end
如果姐妹工作的目的地根本没有产出，或者产出不多，那么这种方法效果很好。
这与线程一起工作；叉子"；这里提供额外的性能。
使用进程分区
以类似的方式，可以以每个进程只处理输入数据的子集的方式来构建他们的作业。
通过这种方式，可以启动4个进程(通过cron作业，或通过父工具进行监控(，并传递SHARD_NUMBER=1,2,3,4，然后由源用于输入负载分区。
但是
我敢肯定，正如你所说，你的问题更多的是关于工作流控制；声明&表达自己需要做什么的能力，而不是表现。
我会联系的，我们会讨论的。