0

在需要进一步处理之前,我的处理有一个“浓缩”步骤:

来源:各种用户的原始事件/分析日志。

Transform:根据 UserID 将每一行插入一个哈希中。

目标/输出:内存中的哈希,例如:

{ 
  "user1" => [event, event,...], 
  "user2" => [event, event,...] 
}

现在,我没有必要将这些用户组存储在任何地方,我只想继续处理它们。Kiba 是否有使用中间目的地的通用模式?例如

# First pass
source EventSource # 10,000 rows of single events
transform {|row| insert_into_user_hash(row)}
@users = Hash.new
destination UserDestination, users: @users

# Second pass
source UserSource, users: @users # 100 rows of grouped events, created in the previous step
transform {|row| analyse_user(row)} 

我正在挖掘代码,似乎文件中的所有转换都应用于源,所以我想知道其他人是如何处理这个的,如果有的话。我可以保存到中间存储并运行另一个 ETL 脚本,但希望有一种更清洁的方式——我们正在计划很多这些“浓缩”步骤。

4

1 回答 1

0

直接回答您的问题:您不能在同一个 Kiba 文件中定义 2 个管道。您可以有多个源或目标,但行都将通过每个转换,也通过每个目标。

也就是说,根据您的具体用例,在拆分为 2 个管道之前,您有很多选择。

我将通过电子邮件私下向您提出一些更详细的问题,以便稍后在此处正确回复。

于 2017-10-10T15:49:53.867 回答