1

寻找一些关于如何最好地架构/设计和构建我们的管道的建议。

经过一些初步测试,我们没有得到预期的结果。也许我们只是在做一些愚蠢的事情,或者我们的期望太高了。

我们的数据/工作流程:

  • Google DFP 将我们的广告服务器日志(CSV 压缩)直接写入 GCS(每小时)。
  • 这些日志一天的价值在 30-7000 万条记录范围内,一个月大约有 1.5-20 亿条记录。
  • 对其中的 2 个字段执行转换,并将行写入 BigQuery。
  • 转换涉及对其中 2 个字段执行 3 次 REGEX 操作(由于增加到 50 个操作),这会产生新的字段/列。

到目前为止,我们已经运行了什么:

  • 构建了一个从 GCS 读取文件一天(31.3m)的管道,并使用 ParDo 执行转换(我们认为我们会从一天开始,但我们的要求也是处理数月和数年)。
  • DoFn 输入是一个字符串,它的输出是一个 BigQuery TableRow。
  • 管道在云中以实例类型“n1-standard-1”(1vCPU)执行,因为我们认为每个工作人员 1 个 vCPU 就足够了,因为转换不是过于复杂,也不是 CPU 密集型,即只是字符串到字符串的映射.

我们使用几种不同的工作器配置运行了该作业,以查看它的执行情况:

  1. 5 名工作人员(5 个 vCPU)耗时约 17 分钟
  2. 5 个工作人员(10 个 vCPU)花费了大约 16 分钟(在这次运行中,我们将实例提升到“n1-standard-2”以获得双倍的内核,看看它是否提高了性能)
  3. 自动缩放设置为“BASIC”(50-100 个 vCPU)的 50 分钟和最多 100 个工作人员花费了大约 13 分钟
  4. 自动缩放设置为“BASIC”(100-150 个 vCPU)的 100 分钟和 150 个最大工作人员花费了大约 14 分钟

这些时间是否符合您对我们的用例和管道的期望?

4

2 回答 2

2

您还可以将输出写入文件,然后使用命令行/控制台将其加载到 BigQuery。您可能会节省一些美元的实例正常运行时间。这是我在遇到 Dataflow/BigQuery 接口问题后一直在做的事情。此外,根据我的经验,启动实例并将其拆除会产生一些开销(可能需要 3-5 分钟)。您是否也将这段时间包括在您的测量中?

于 2015-02-17T16:33:44.127 回答
1

BigQuery 的写入限制为每张表每秒 100,000 行或每分钟 6M。在 3100 万行的输入中,这将需要大约 5 分钟的完全写入时间。当您添加回每个元素的离散处理时间和图表的同步时间(从 GCS->dispatch->... 读取)时,这看起来是正确的。

我们正在开发一个表分片模型,这样您就可以跨一组表进行写入,然后在 BigQuery 中使用表通配符来跨表聚合(典型 BigQuery 流用例的通用模型)。我知道 BigQuery 的人也在考虑增加表流限制,但没有任何官方可以分享。

Net-net 增加的实例现在不会为您带来更多的吞吐量。

另一种方法——在我们致力于改进 BigQuery 同步的同时——将通过 TextIO 使用模式匹配对您的读取进行分片,然后针对 X 个表运行 X 个单独的管道。可能是一个有趣的实验。:-)

说得通?

于 2015-02-17T04:07:00.427 回答