Apache Beam vs Spark 2026: So Sánh Pipeline Hợp Nhất và Câu Hỏi Phỏng Vấn

Apache Beam và Spark là hai framework xử lý dữ liệu phổ biến nhất trong năm 2026. Beam 2.76 (Tháng 8 năm 2026) và Spark 4.2 (Tháng 7 năm 2026) đều xử lý workload batch và streaming, nhưng triết lý thiết kế của chúng khác nhau cơ bản. Beam trừu tượng hóa execution engine, trong khi Spark cung cấp runtime tích hợp chặt chẽ.

Mô Hình Di Động của Beam vs Engine Hợp Nhất của Spark

Apache Beam tách biệt mô hình lập trình khỏi thực thi. Một định nghĩa pipeline duy nhất có thể chạy trên Google Cloud Dataflow, Apache Flink, Apache Spark, hoặc các runner khác mà không cần thay đổi code. Sự trừu tượng này đến từ Beam SDK tạo ra biểu diễn pipeline di động mà bất kỳ runner tương thích nào cũng có thể diễn giải.

Spark 4.2 áp dụng cách tiếp cận ngược lại. DataFrame API, Structured Streaming, và MLlib chia sẻ cùng Catalyst optimizer và Tungsten execution engine. Sự tích hợp chặt chẽ này cho phép các tối ưu hóa như Adaptive Query Execution điều chỉnh kế hoạch thực thi tại runtime dựa trên thống kê dữ liệu thực tế.

# beam_pipeline.py
import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

# Code tương tự chạy trên Dataflow, Flink, hoặc Spark runner
options = PipelineOptions([
    '--runner=DataflowRunner',  # Chuyển sang FlinkRunner hoặc SparkRunner
    '--project=my-project',
    '--region=us-central1',
    '--temp_location=gs://my-bucket/temp'
])

with beam.Pipeline(options=options) as pipeline:
    (pipeline
     | 'ReadEvents' >> beam.io.ReadFromPubSub(topic='projects/p/topics/events')
     | 'ParseJSON' >> beam.Map(lambda x: json.loads(x))
     | 'FilterValid' >> beam.Filter(lambda e: e.get('status') == 'valid')
     | 'WindowByMinute' >> beam.WindowInto(beam.window.FixedWindows(60))
     | 'CountPerWindow' >> beam.combiners.Count.Globally()
     | 'WriteToBQ' >> beam.io.WriteToBigQuery('project:dataset.table'))

Phiên bản Spark tương đương gắn trực tiếp với Spark runtime:

# spark_streaming.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, window

spark = SparkSession.builder \
    .appName("EventProcessing") \
    .config("spark.sql.adaptive.enabled", "true") \
    .getOrCreate()

# Spark 4.2: Chế độ ANSI được bật mặc định, kiểm tra type nghiêm ngặt hơn
events = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "events") \
    .load()

processed = events \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .filter(col("data.status") == "valid") \
    .groupBy(window(col("data.timestamp"), "1 minute")) \
    .count()

processed.writeStream \
    .format("bigquery") \
    .option("table", "project.dataset.table") \
    .outputMode("append") \
    .start()

Tính di động của Beam cho phép kiến trúc cloud-agnostic nhưng thêm một lớp translation. Thực thi trực tiếp của Spark thường cho thấy độ trễ thấp hơn cho các thao tác tương đương trên cùng phần cứng.

So Sánh Windowing và Xử Lý Event-Time

Cả hai framework đều xử lý ngữ nghĩa event-time, nhưng API của chúng phản ánh di sản khác nhau. Mô hình windowing của Beam xuất phát từ Dataflow Model paper (2015), coi window như phần tử pipeline hạng nhất. Spark điều chỉnh windowing cho Structured Streaming, tích hợp nó với DataFrame API.

Session windows thể hiện rõ nhất sự khác biệt. Beam coi session như chiến lược windowing native:

# beam_sessions.py
from apache_beam import window

# Session gap 30 phút, chấp nhận dữ liệu trễ đến 1 giờ
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # Gap 30 phút đóng session
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # Chấp nhận dữ liệu trễ đến 1 giờ
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark yêu cầu xử lý stateful cho sessions:

# spark_sessions.py
from pyspark.sql.streaming import GroupState, GroupStateTimeout

def update_session(key, events, state: GroupState):
    # Quản lý session thủ công với state API
    session_data = state.getOption() or {"count": 0, "start": None, "end": None}
    
    for event in events:
        ts = event.timestamp
        if session_data["end"] and (ts - session_data["end"]).seconds > 1800:
            # Gap vượt quá 30 phút, emit session trước
            yield session_data
            session_data = {"count": 0, "start": ts, "end": ts}
        
        session_data["count"] += 1
        session_data["end"] = ts
        if not session_data["start"]:
            session_data["start"] = ts
    
    state.update(session_data)
    state.setTimeoutDuration(30 * 60 * 1000)  # Timeout 30 phút

# Spark 4.2 Arbitrary State API v2
result = events \
    .groupByKey(lambda e: e.user_id) \
    .flatMapGroupsWithState(
        update_session,
        outputMode="append",
        stateType=session_schema,
        timeoutConf=GroupStateTimeout.ProcessingTimeTimeout
    )

Để chuẩn bị phỏng vấn về các chủ đề này, xem module câu hỏi phỏng vấn Apache Beam và Dataflow.

Hiệu Suất: Dữ Liệu Benchmark 2026

So sánh trực tiếp cần thiết lập cẩn thận vì Beam chạy trên Spark như một tùy chọn runner. So sánh có liên quan là Beam-on-Dataflow vs native Spark.

Benchmark gần đây từ Databricks và Google Cloud cho thấy:

Cải thiện hiệu suất của Spark 4.2 đến từ nhiều tính năng:

• Chế độ ANSI mặc định: ngữ nghĩa SQL nghiêm ngặt hơn bắt lỗi sớm hơn
• Kiểu dữ liệu VARIANT: xử lý dữ liệu bán cấu trúc native
• Adaptive Query Execution: tối ưu hóa kế hoạch tại runtime
• Hỗ trợ Java 21: virtual threads giảm overhead

Beam 2.76 cung cấp:

• Hỗ trợ Flink 2.0 runner: stateful streaming production-grade
• CDC offset persistence: DebeziumIO FileSystemOffsetRetainer
• Tích hợp ADK: hỗ trợ Google Agent Development Kit trong Python SDK

Câu Hỏi Phỏng Vấn Thường Gặp: Beam vs Spark

Phỏng vấn kỹ thuật cho vị trí data engineering thường so sánh hai framework này. Đây là các câu hỏi xuất hiện trong phỏng vấn năm 2026, với độ sâu câu trả lời được mong đợi.

Q1: Khi nào nên chọn Beam thay vì native Spark?

Các điểm câu trả lời mong đợi:

• Triển khai multi-cloud hoặc hybrid nơi code pipeline phải chạy không thay đổi
• Môi trường Google Cloud nơi Dataflow cung cấp cơ sở hạ tầng được quản lý
• Ngữ nghĩa event-time phức tạp cần session windows hoặc custom triggers
• Nhóm có chuyên môn Beam từ nền tảng Dataflow

Câu trả lời cờ đỏ: "Beam luôn tốt hơn vì di động." Tính di động có chi phí overhead.

Q2: Trừu tượng runner của Beam ảnh hưởng đến debugging như thế nào?

Các điểm câu trả lời mong đợi:

• Stack trace tham chiếu cả Beam SDK và triển khai runner
• Tối ưu hóa cụ thể runner có thể hoạt động khác nhau (checkpoint Flink vs checkpoint Spark)
• Metrics API cung cấp monitoring hợp nhất, nhưng dashboard runner hiển thị chi tiết khác
• Testing với DirectRunner trước khi deploy lên production runner

Q3: Giải thích ngữ nghĩa exactly-once trong cả hai framework.

Câu trả lời mong đợi:

# Beam: exactly-once qua đảm bảo runner
# Dataflow cung cấp exactly-once cho cả sources và sinks
# SDK xử lý khử trùng lặp và phối hợp checkpoint

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # Đọc exactly-once
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # Ghi exactly-once với retry
    )

# Spark: exactly-once qua checkpointing và idempotent sinks
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # Phục hồi state
    .foreachBatch(idempotent_write)  # Khử trùng lặp cấp ứng dụng
    .start()

Để xem thêm chủ đề phỏng vấn streaming, tham khảo module PySpark.

Q4: Làm thế nào để migrate Spark batch job sang Beam?

Câu hỏi này kiểm tra hiểu biết về cả hai API. Các điểm chính:

1. Map các thao tác DataFrame sang PCollections và transforms
2. Thay thế spark.read bằng Beam I/O connector phù hợp
3. Chuyển đổi UDF thành hàm beam.Map hoặc beam.ParDo
4. Xử lý partitioning khác (Reshuffle của Beam vs repartition của Spark)
5. Test với DirectRunner trước khi deploy lên production runner

Chọn Công Cụ Phù Hợp: Ma Trận Quyết Định

Lựa chọn phụ thuộc vào bối cảnh tổ chức hơn là khả năng kỹ thuật. Cả hai framework đều xử lý hầu hết workload data engineering một cách hiệu quả.

Để quyết định pattern ETL/ELT, hãy xem xét khối lượng dữ liệu và yêu cầu độ trễ trước khi chọn framework.

Kiến Trúc Thực Tế: Cách Tiếp Cận Hybrid

Nhiều tổ chức sử dụng cả hai framework. Mô hình phổ biến:

[Streaming Ingestion]     [Batch Processing]     [ML Training]
        |                        |                    |
   Beam/Dataflow           Spark trên Databricks    Spark MLlib
        |                        |                    |
        v                        v                    v
    BigQuery  <----- dbt -----> Delta Lake -----> Model Registry

Beam xử lý streaming ingestion nơi autoscaling của Dataflow phù hợp với các pattern traffic. Spark xử lý batch workload nơi kinh tế cluster có lợi cho compute liên tục. Cả hai đổ vào data warehouse hợp nhất.

Kiến trúc này được thảo luận trong tutorial Apache Spark với chi tiết triển khai.

Kết Luận Lựa Chọn Beam vs Spark

• Beam 2.76 cung cấp tính di động runner trên Dataflow, Flink 2.0, và Spark, đánh đổi hiệu suất cho sự linh hoạt triển khai
• Spark 4.2 mang lại tích hợp chặt chẽ hơn giữa SQL, streaming, và ML workload với các tính năng như kiểu VARIANT và Adaptive Query Execution
• Session windows và trigger phức tạp phù hợp hơn với mô hình windowing native của Beam
• Hiệu suất batch trên phần cứng tương đương thường tốt hơn với Spark nhờ tối ưu hóa Catalyst/Tungsten
• Câu hỏi phỏng vấn tập trung vào đánh đổi thay vì tuyên bố một framework vượt trội
• Kiến trúc hybrid sử dụng cả hai framework phổ biến trong môi trường production
• So sánh chi phí phụ thuộc vào pattern workload: pricing per-GB của Dataflow vs cấp phát cluster Spark