0

我正在考虑在 kiba 中编写我们的 ETL（或类似 ETL）流程，我想知道如何构建它。我的主要问题是整体架构。该过程大致如下：

  1. 从 HTTP 端点获取数据。
  2. 对于从该 API 返回的每个项目，再进行一次 HTTP 调用
  3. 对从第 2 步返回的每个项目进行一些转换
  4. 将每个项目发送到其他地方

现在我的问题是：如果只有第一步是 asource并且直到最后的任何东西都是 a ，这可以transform吗？source或者以某种方式让每个 HTTP 调用成为 a然后以某种方式组合它们会更好，也许使用多个作业？

4

1 回答 1

1

确实最好使用单个source，您将使用它来获取数据的主要流。

一般建议：尽可能多地分批工作（例如，在源代码中分页，但如果 API 在步骤 2 中支持，还可以批量 HTTP 查找）。

源部分

例如，在您的情况下，源可能是分页 HTTP 资源。

实现它的第一个选项是编写一个专用类，如文档中所述。

第二种选择是像这样使用Kiba::Common::Sources::Enumerable（https://github.com/thbar/kiba-common#kibacommonsourcesenumerable）：

source Kiba::Common::Sources::Enumerable, -> {
  Enumerator.new do |y|
    # do your pagination & splitting here
    y << your_item
  end
}
# then
transform Kiba::Common::Transforms::EnumerableExploder

加入辅助 HTTP 源

可以这样做：

transform do |r|
  # here make secondary HTTP query
  result = my_query(...)
  # then merge the result
  r.merge(secondary_data: ...)
end

ParallelTransform通过 Kiba Pro （https://github.com/thbar/kiba/wiki/Parallel-Transform ）支持该步骤中的查询并行化：

parallel_transform(max_threads: 10) do |r|
  # this code will run in its own thread
  extra_data = get_extra_json_hash_from_http!(r.fetch(:extra_data_url))
  r.merge(extra_data: extra_data)
end

还必须注意的是，如果您可以构造您的 HTTP 调用以一次处理 N 行（如果 HTTP 后端足够灵活），事情将会更快。

第 3 步不需要具体建议。

将每个项目发送到其他地方

我很可能会为此实现一个目标（但它实际上也可以作为转换实现，并且parallel_transform如果需要仍然可以并行化）。

于 2021-03-12T13:54:47.577 回答