kiba-etl模式将转换拆分成独立的管道

Question

Kiba是一个非常小的库，据我所知，它的大部分价值来自于实施小型独立转换的模块化架构。

然而，在我看来，一系列系列转换的模型并不适合我们面临的大多数ETL问题。为了解释这个问题，让我举一个人为的例子：

源生成具有以下结构的哈希

{ spend: 3, cost: 7, people: 8, hours: 2 ... }

我们首选的输出是一个散列列表，其中的一些键可能与源中的键相同，尽管值可能不同

{ spend: 8, cost: 10, amount: 2 }

现在，计算产生的开销需要进行一系列转换：ConvertCurrency, MultiplyByPeople等。计算成本：ConvertCurrencyDifferently, MultiplyByOriginalSpend。请注意，成本计算依赖于原始(未转换)支出值。

最自然的模式是在两个独立的管道中计算支出和成本，并合并最终输出。如果您愿意，可以使用map-reduce模式。我们甚至可以从并行运行管道中受益。

然而，在我的例子中，这实际上不是性能问题(因为转换非常快)。问题是，由于Kiba将所有转换应用为一系列步骤，因此成本计算将受到开销计算的影响，并且我们将得到错误的结果。

kiba有办法解决这个问题吗？我能想到的唯一一件事就是确保目标名称与源名称不相同，例如'originSpend‘和'finalSpend’。然而，这仍然困扰着我，我的开销计算管道必须确保传递每一步的全套关键字，而不是仅仅传递与其相关的关键字，然后最终合并到成本关键字中。或者可以定义两个独立的kiba作业，然后让一个主作业调用这两个作业并最终合并它们的结果？对于这个问题，最适合kiba的解决方案是什么？

将ETL管道拆分成多个并行路径似乎是大多数ETL工具的关键特性，所以我很惊讶kiba似乎不支持它？

Answer 1

我想我缺少额外的细节来恰当地回答你的主要问题。我将通过电子邮件联系这一轮，并可能稍后在这里发表评论，以供公众关注。

将一个ETL管道分成多个并行路径似乎是大多数ETL工具的一个关键特性，所以我很惊讶它似乎不是kiba支持的东西？

今天Kiba ETL的主要关注点是:组件重用、更低的维护成本、模块化以及具有强大的数据和过程质量的能力。

但是，通过不同的模式在一定程度上支持并行化。

使用Kiba Pro并行转换来运行姊妹作业

如果你的主要输入是一些你可以用少量的项目来“分区”的东西(例如数据库id范围，或者一个文件列表)，你可以像这样使用Kiba Pro parallel transform：

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，然后源将其用于输入负载分区。

但!

我非常确定，正如您所说的，您的问题更多的是关于工作流控制和声明&表达您需要做的事情的能力，而不是性能。

我会联系你的，我们会讨论这个。