0

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 支持的东西？

4

1 回答 1

1

我想我缺乏额外的细节来正确回答你的主要问题。我将通过电子邮件与本轮联系，稍后可能会在此处发表评论以供公众查看。

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

但！

正如您所说，我很确定您的问题更多是关于工作流控制和声明以及表达您需要完成的工作的能力，而不是性能。

我会联系，我们会讨论这个问题。

于 2021-05-08T08:08:53.187 回答