Spark流写入DeltaTable性能优化与24小时数据留存方案问询

一、是否需要执行Vacuum？会中断流写入吗？ #

• 必须执行Vacuum：你设置的deletedFileRetentionDuration = "interval 24 hours"仅标记可删除的旧文件，Delta不会自动清理这些文件，只有执行Vacuum才能真正删除超过留存期的文件，否则旧数据会持续占用存储，导致表无限膨胀。
• 不会中断流写入任务：Vacuum是只读清理操作，只会删除已标记为废弃且超过留存期的文件，不会触碰当前流任务正在写入或使用的文件。执行时需指定RETAIN 24 HOURS（与你的配置匹配），避免误删有效数据。建议在低峰期定时执行（比如用Airflow或Azure Automation），或在流任务的微批间隙触发。

二、实现类似Kafka的24小时数据留存机制 #

结合你的需求（仅保留24小时数据、无需版本控制、使用ADLS Gen1），可按以下配置操作：

• 调整Delta表核心配置：
  • 缩短日志留存：设置deltaTable.logRetentionDuration = "interval 1 hours"（无需版本控制，日志无需长时间留存）
  • 保持deletedFileRetentionDuration = "interval 24 hours"，标记24小时外的文件为可清理
  • 关闭变更数据捕获：设置delta.enableChangeDataFeed = false（默认关闭，明确配置避免额外日志生成）
• 定时执行Vacuum：
  • 每天定时运行VACUUM your_delta_table RETAIN 24 HOURS，先通过DRY RUN参数验证要删除的文件，确认无误后正式执行
• 配合分区目录清理：
  • 由于表按date、hour、minute分区，可通过Azure CLI脚本定时删除ADLS Gen1上超过24小时的分区目录（比如az dls fs delete --account-name <your-adls-account> --path /path/to/table/date=20240501），与Vacuum形成互补，更快释放存储

三、确保Spark流写入时间恒定的优化 #

在数据量、特征不变的前提下，从分区、资源、自动优化三方面调整：

• 优化重分区策略：
  • 明确指定重分区数量，避免依赖自动分区。比如根据流吞吐量设置固定分区数：df.repartition(64, "date", "hour", "minute", "col1")，让每个分区的文件大小控制在1GB-2GB（Delta最优文件大小）
  • 若col1基数极大，可考虑减少分区层级（比如去掉minute分区，或对col1做哈希分区），避免生成过多小文件拖慢写入
• 调整自动优化参数：
  • 配置delta.autoOptimize.maxFileSize = "1g"，让自动合并后的文件大小更可控
  • 提高delta.autoCompact.minNumFiles至10（默认4），减少不必要的后台合并操作，避免占用写入资源
• 固定流任务资源配置：
  • 给Spark流任务分配固定的Executor数量、内存和CPU，比如--num-executors 16 --executor-memory 8g --executor-cores 4，避免资源波动导致写入延迟
  • 采用固定间隔的微批触发：trigger(Trigger.ProcessingTime("5 minutes"))，让每个微批的数据量稳定，避免突发大批次拉长写入时间
• ADLS Gen1写入优化：
  • 启用Spark连接器的ADLS写入优化：设置spark.hadoop.dfs.adls.write.optimize.enable = true，提升大文件写入效率
  • 避免小文件生成：通过重分区和自动优化严格控制文件大小，减少ADLS Gen1的小文件处理开销

内容的提问来源于stack exchange，提问作者Dariusz Krynicki