如何确定Databricks中Spark作业时长并优化100TB JSON入湖任务？

一、如何确定作业完成时长 #

• 查看Databricks作业监控面板：在作业运行详情页，找到已处理数据量、每秒处理速率（如MB/s或记录数/秒），用总数据量（100TB）除以稳定运行后的平均速率，就能估算剩余时间。注意排除启动、Schema解析等前期耗时阶段，取平稳阶段的速率计算更准确。
• 检查Checkpoint目录：查看/mnt/_checkpoint/cloudFiles下的元数据文件，里面记录了已扫描的文件列表和处理进度，对比总文件数/总文件大小，算出完成比例，再结合已用时间反推总时长。
• 分析Spark UI指标：进入作业对应的Spark UI，查看Input Size / Records统计，结合Duration里的阶段耗时，计算各阶段的处理效率，进而预估整体剩余时间。

二、优化方法 #

1. 数据读取与解析优化 #

• 调整CloudFiles参数：添加option("cloudFiles.maxFilesPerTrigger", "1000")（数值根据集群规模调整），避免单次触发加载过多文件导致内存溢出；开启option("cloudFiles.useIncrementalListing", "true")，减少Blob Storage的文件列表扫描开销，尤其适合文件数量多的场景。
• 优化JSON解析：如果是多行JSON文件，添加option("multiline", "true")；如果存在大量小文件，先合并后再处理，降低文件IO的开销。
• 简化Schema配置：你已经手动指定了Schema，这能避免Spark自动推断Schema的额外耗时，建议关闭cloudFiles.schemaLocation选项（不需要自动演化Schema），减少元数据读写操作。

2. 集群资源优化 #

• 调整集群规格：使用更大配置的Worker节点（增加CPU核数、内存），或者增加Worker节点数量，提升并行处理能力。针对100TB的数据，建议至少用8-16个Worker的集群，节点选内存优化型或计算优化型，根据数据是CPU密集还是内存密集来选。
• 启用动态资源分配：打开集群的动态资源分配功能，让Spark根据作业负载自动增减节点，避免资源浪费或不足。
• 调优Spark参数：设置spark.sql.shuffle.partitions为集群总核数的2-3倍（比如64核集群设为128-192），避免shuffle阶段数据倾斜；设置spark.executor.memoryOverhead为executor内存的10%-20%，防止内存溢出。

3. Delta Lake写入优化 #

• 优化分区与文件大小：如果数据包含时间字段，按时间分区写入Delta表，减少后续查询的扫描范围；设置option("maxRecordsPerFile", "1000000")，控制输出文件大小在1GB左右，避免生成过多小文件，提升后续查询性能。
• 关闭不必要选项：如果预定义Schema已经完整，不需要动态合并，建议关闭mergeSchema选项，减少写入时的Schema检查开销。
• 导入后优化表结构：初始导入完成后，执行OPTIMIZE main.auditlogs.Customer_Logs ZORDER BY (authenticationMechanismId)，合并小文件并按高频查询字段排序，提升后续查询效率。

4. 存储层优化 #

• 确保同区域部署：Blob Storage与Databricks集群放在同一Azure区域，避免跨区域数据传输的延迟和额外成本，提升读取速度。
• 升级存储性能层：如果是高IO场景，改用Azure Blob Storage的Premium性能层，它的吞吐量和IOPS更高，能显著提升文件读取效率。

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