【问题标题】:Cache a dataset in Dataflow在 Dataflow 中缓存数据集
【发布时间】:2017-09-02 00:22:52
【问题描述】:

我想知道是否可以直接在 Google Dataflow 平台中缓存数据集(例如在 Spark 中缓存 RDD)。

如果没有这样的功能,Dataflow 如何在应用程序中挑选热数据集,特别是如果您有多个热数据集,并且您希望根据数据集的重要性优先缓存?

【问题讨论】:

    标签: google-cloud-platform google-cloud-dataflow


    【解决方案1】:

    Dataflow 的执行模型与 Spark 截然不同。在 Spark 中,核心概念是 RDD,使用 RDD 的典型模式是以不可预知的方式交互查询它;因此,RDD 需要缓存,可能由用户控制。

    在 Dataflow (Apache Beam) 中,核心概念是 Pipeline,作为一个整体构建、优化和执行,其中 PCollection(最接近 RDD)只是管道中的一个逻辑节点。

    这两种方法各有优势,但通过 Dataflow 的方法,Dataflow 确切知道PCollection 将如何在管道中使用,因此不涉及不可预测性,也不需要缓存策略。

    Dataflow 目前在 Google Cloud Storage 上的临时文件中实现了一些中间 PCollections,并试图通过使用 fusion 尽可能避免实现。如果实现了PCollection,则处理此集合的管道阶段将需要从 Cloud Storage 中读取它;否则(如果 stage 与生成数据集的 stage 融合),它将在内存中处理数据集的元素,当它们被生成时,它们将位于生成它们的 worker 上。

    GroupByKey 操作和类似的操作(例如Combine)是特殊的:Dataflow 有多个GroupByKey 的实现,在批处理和流式管道之间有所不同;他们要么使用虚拟机上的本地磁盘来存储数据,要么使用high-performance Google internal infrastructure

    【讨论】:

    • 感谢尤金的回复。这是一个巨大的断言“不存在不可预测性……”;这使得该平台适用于实时系统。请告诉我是否可以在任何研究出版物(例如,Flume 或 Millwheel)中找到有关可预测性的更多信息。主要问题是我们对调优部分没有任何控制权,除了选择具有更大内存的实例类型。如何根据输入数据集创建成本模型?只是实验性的?如何让我的客户相信我的 Dataflow 模型经过优化且具有成本效益?谢谢。
    • 嗯,我的意思只是集合的访问模式是可预测的,就像 SQL 数据库在执行查询之前知道整个查询计划一样。还有很多其他不可预测性:数据大小和分布、用户代码处理持续时间等。“为什么光束几乎不暴露任何调整旋钮”是一个很好的问题,但超出了评论的范围,请随时提出单独的 SO 问题:)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-05
    • 1970-01-01
    • 2021-04-29
    • 2015-01-29
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多