数据实时处理架构：Apache Kafka + Spark 实战解析

1. 引言：为什么选择 Kafka + Spark？

在广告点击流分析、IoT设备监控等实时大数据场景下，传统批处理（如Hadoop MapReduce）已无法满足低延迟需求。我们曾用Kafka+Spark Streaming替换原有Lambda架构，使数据处理延迟从小时级降至秒级。

关键对比（表1）：

2. Kafka 核心优化：突破吞吐量瓶颈

2.1 生产端配置陷阱

某次日志采集项目中，Kafka生产者默认配置导致数据丢失：

// 错误示范（未ACK+无重试）
props.put("acks", "0");  
props.put("retries", "0");

// 正确配置（权衡可靠性与吞吐）
props.put("acks", "1");  // Leader确认即可  
props.put("retries", 3);  
props.put("compression.type", "snappy");  // 压缩提升吞吐

2.2 分区数计算公式

目标吞吐量 10万条/秒，每条消息1KB，单个分区吞吐≈5MB/s：

分区数 = ceil(总吞吐 / 单分区吞吐) 
       = ceil(10万×1KB / 5MB) 
       = 20分区

实测性能（表2）：

3. Spark 流处理：状态管理与容错

3.1 Structured Streaming 优势

# 从Kafka读取+窗口聚合
df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "user_clicks") \
    .load()

# 按1分钟窗口统计点击量
windowed_counts = df.groupBy(
    window(col("timestamp"), "1 minute"),
    col("product_id")
).count()

对比（表3）：

3.2 常见故障与解决

• 问题1：Small file problem（HDFS海量小文件）
  方案：设置spark.sql.shuffle.partitions=200 控制输出文件数
• 问题2：Consumer lag飙升
  方案：动态调整maxOffsetsPerTrigger

4. 端到端实时监控方案

4.1 监控指标看板（Grafana示例）

4.2 日志关联分析（ELK实战）

// 日志样例：Kafka生产者异常
{
  "timestamp": "2024-03-20T14:23:01Z",
  "level": "ERROR",
  "message": "Failed to send after 3 retries",
  "metadata": {
    "topic": "payment_events",
    "partition": 7,
    "offset": 142857
  }
}

5. 总结与踩坑记录

1. Kafka调优：
   • 分区数并非越多越好，建议每Broker≤200分区
   • 使用linger.ms=50 减少小包传输
2. Spark最佳实践：
   • 避免collect()操作，改用foreachPartition
   • 启用动态资源分配（spark.dynamicAllocation.enabled=true）
3. 监控必做项：
   • Kafka消费者Lag监控
   • Spark堆积批次检测

“我们曾因没限制max.poll.records导致OOM——你的团队踩过哪些坑？”