{
  "id": "apache-spark-vs-google-cloud-dataflow",
  "ids": [
    "apache-spark",
    "google-cloud-dataflow"
  ],
  "title": "Apache Spark vs Google Cloud Dataflow: engine, runner and recovery",
  "heading": "Apache Spark vs Google Cloud Dataflow",
  "kicker": "Data engineering software comparison",
  "deck": "Compare Apache Spark and Google Cloud Dataflow for batch and streaming pipelines, programming models, runtime ownership, state recovery and the complete compute bill.",
  "description": "Compare Apache Spark and Google Cloud Dataflow for batch and streaming pipelines, programming models, runtime ownership, state recovery and the complete compute bill.",
  "answerHeading": "Which pipeline approach fits?",
  "answer": "Choose a Spark-based approach when its APIs, ecosystem and selected runtime fit the workload. Choose Dataflow when managed execution of an Apache Beam pipeline fits the Google Cloud architecture. Spark is an open-source processing engine; Dataflow is a paid managed service and Beam runner. Compare the whole deployment rather than treating open-source software as free compute or assuming a Spark application can run unchanged on Dataflow.",
  "checkedAt": "2026-10-15",
  "researchTag": "Pipeline scope, recovery and cost comparison",
  "researchLimit": "Official product and pricing documentation checked. The exercises below are proposed evaluation briefs, not completed tests, pipeline measurements or performance benchmarks.",
  "datasetDescription": "Seven architecture and buying differences, four pipeline evaluation briefs and four acceptance checks for Apache Spark vs Google Cloud Dataflow.",
  "type": "workflow-buying",
  "rows": [
    [
      "Product boundary",
      "Open-source distributed processing engine",
      "Managed Google Cloud processing service"
    ],
    [
      "Programming model",
      "Spark SQL, DataFrames and Structured Streaming",
      "Apache Beam pipelines executed by the Dataflow runner"
    ],
    [
      "Runtime supply",
      "Self-operated or a separately selected managed Spark service",
      "Google-managed execution resources"
    ],
    [
      "Batch processing",
      "Build the job with the supported Spark APIs",
      "Build or deploy a supported Beam pipeline or template"
    ],
    [
      "Streaming design",
      "Define state, checkpoints and supported source/sink semantics",
      "Define Beam windows, state and selected processing mode"
    ],
    [
      "Recovery responsibility",
      "Runtime operator and application own the agreed recovery design",
      "Managed runtime still needs correct application state and output design"
    ],
    [
      "Cost boundary",
      "Compute, storage, hosting and operating work are separate",
      "Worker or compute units plus applicable shuffle and connected resources"
    ]
  ],
  "scenarios": [
    {
      "name": "Nightly aggregation",
      "question": "Can the job produce the agreed totals from the same input?",
      "left": "Implement the transformation on the selected Spark runtime.",
      "right": "Implement the corresponding Beam transformation for Dataflow.",
      "note": "Use the same timestamps, null policy and decimal representation; compare reconciled outputs before execution speed."
    },
    {
      "name": "Late event",
      "question": "How does the pipeline handle an event arriving after its reporting window?",
      "left": "Define the Structured Streaming window and state policy.",
      "right": "Define the Beam window, watermark and late-data policy.",
      "note": "Write the required business result first; default settings need not express the same rule."
    },
    {
      "name": "Interrupted processor",
      "question": "What happens when a job restarts after partial output?",
      "left": "Review checkpoints, source offsets and sink commit behaviour.",
      "right": "Review the selected Dataflow processing mode and destination behaviour.",
      "note": "A processing guarantee does not automatically make an external API side effect exactly once."
    },
    {
      "name": "Continuous operation",
      "question": "What is the cost of keeping the workload running?",
      "left": "Estimate the chosen runtime’s provisioned and active resources.",
      "right": "Estimate the selected Dataflow resource or compute-unit model and related services.",
      "note": "Include state, storage, shuffle, network and a recovery run as applicable."
    }
  ],
  "exampleTable": {
    "caption": "Proposed evaluation checks; no measured product results are implied.",
    "headers": [
      "Requirement",
      "Proposed exercise",
      "Accept when"
    ],
    "rows": [
      [
        "Result equivalence",
        "Reconcile a bounded sample with edge cases",
        "The two implementations satisfy the same contract"
      ],
      [
        "Late data",
        "Inject an approved out-of-order event",
        "The documented business rule is followed"
      ],
      [
        "Restart",
        "Review and rehearse partial-output recovery",
        "Duplicates and omissions are accounted for"
      ],
      [
        "Operating cost",
        "Model the actual batch or continuous schedule",
        "Runtime and dependent-service costs are visible"
      ]
    ]
  },
  "sections": [
    {
      "id": "model",
      "title": "Choose the programming model deliberately",
      "navLabel": "Choose the programming model deliberately",
      "paragraphs": [
        "A Spark SQL or DataFrame application and an Apache Beam pipeline are different implementations. Beam has runners for multiple platforms, but that does not make arbitrary Spark code a Dataflow application. Record required connectors, libraries and runtime assumptions before proposing a migration.",
        "For a fair evaluation, choose one bounded transformation and one streaming rule. Specify data types, time zones, null behaviour and the expected destination representation. This helps separate a genuine architecture mismatch from an implementation error in an illustrative rewrite."
      ]
    },
    {
      "id": "state",
      "title": "Review state and side effects",
      "navLabel": "Review state and side effects",
      "paragraphs": [
        "Streaming jobs must define what happens to late events, state, checkpoints and destination writes after interruption. Review the actual source and sink rather than making a blanket exactly-once claim about the full business process. An external notification or payment API is not automatically protected by a processing-engine guarantee.",
        "Dataflow manages execution resources, while self-managed Spark requires an infrastructure operator; a managed Spark service changes that responsibility. Both still need application ownership. Price the chosen runtime and connected services over the intended operating schedule, including periods when a stream is quiet but the job remains active."
      ]
    }
  ],
  "faqs": [
    {
      "question": "Can Spark code run unchanged on Google Cloud Dataflow?",
      "answer": "Do not assume that. Dataflow executes Apache Beam pipelines. A Spark application needs a supported migration or rewrite and validation."
    },
    {
      "question": "Is Apache Spark free hosted compute?",
      "answer": "No. The upstream engine is free software, while infrastructure or a managed runtime has separate costs."
    },
    {
      "question": "Does exactly-once processing guarantee every external side effect happens once?",
      "answer": "No blanket guarantee follows. Check the processing mode, source, sink and external side-effect design together."
    }
  ],
  "sources": [
    {
      "url": "https://spark.apache.org/",
      "facts": "Spark APIs, processing scope and software boundary"
    },
    {
      "url": "https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html",
      "facts": "Structured Streaming documentation entry"
    },
    {
      "url": "https://docs.cloud.google.com/dataflow/docs/overview",
      "facts": "Managed Beam execution and processing modes"
    },
    {
      "url": "https://cloud.google.com/dataflow/pricing",
      "facts": "Worker, compute-unit, shuffle and connected-resource charging"
    }
  ],
  "relatedLinks": [
    {
      "path": "/categories/data-integration-engineering/",
      "title": "Explore data integration and engineering software"
    },
    {
      "path": "/compare/dbt-vs-apache-spark/",
      "title": "Compare a transformation framework with the Spark engine"
    },
    {
      "path": "/guides/data-ingestion-transformation-orchestration/",
      "title": "Understand ingestion, transformation and orchestration"
    }
  ],
  "downloads": [
    {
      "path": "/downloads/apache-spark-vs-google-cloud-dataflow-evaluation.csv",
      "title": "Download the pipeline checklist (CSV)",
      "description": "Four proposed checks with blank evidence and owner columns. Record the actual deployment, package, data volume and recovery requirements in your evaluation."
    }
  ]
}
