Azure Databricks扫描1.5TB诊断日志的集群规格选型咨询

选型前提说明 #

你的场景属于典型的半结构化日志批处理/交互式查询场景，数据存储在Azure Storage Account，当前单批次扫描量1.5TB，后续最大扫描量会到6TB（60天*100GB/天），作业以日志过滤、规则匹配、基础聚合为主，没有复杂迭代计算、机器学习类需求，选型核心优先平衡IO吞吐、作业稳定性和成本，不用盲目追高配置。

分场景推荐配置 #

场景1：固定周期定时扫描（比如合规审计、每日日志巡检，成本优先） #

这类场景不需要集群常驻，优先选作业集群，跑完自动释放资源，成本比常驻交互式集群低60%以上：

• 运行时版本：Databricks Runtime 13.3 LTS，长期支持版稳定性有保障，内置Azure Storage访问优化、JSON/CSV类日志解析加速，不用自己折腾基础性能调优
• 驱动节点：Standard_D8s_v5（8 vCPU，32GB内存），足够承载作业调度、元数据管理压力，日志扫描场景驱动不会成为瓶颈，没必要上更高配
• 工作节点：
  • 实例选型：Standard_D16s_v5（16 vCPU，64GB内存，自带100GB本地NVMe SSD），这是同类场景实测下来IO吞吐/成本比最高的通用型实例，单节点直连Storage的持续读吞吐能到1.2GB/s，比同价位的内存优化、计算优化实例实际扫描速度快30%以上
  • 自动缩放规则：最小2节点，最大12节点。满配12节点时，1.5TB日志完成扫描+规则匹配+结果输出大概1小时跑完，6TB满周期日志扫描耗时大概3.5-4小时，完全满足常规定时作业的时间窗口要求
• 必开优化配置：
  • 开启作业集群自动终止，空闲超时设为10分钟，避免资源空跑计费
  • 开启ABFS客户端本地缓存，缓存路径挂节点本地SSD，缓存大小配50GB，重复扫描同周期日志时速度能提3-5倍
  • 每个工作节点附加2块256GB Premium SSD托管磁盘，避免大Shuffle阶段本地磁盘空间不足报错
  • 如果你的作业支持失败自动重试，工作节点可以配70%比例的Spot实例，整体成本能再降70%，注意驱动节点不要用Spot实例，避免调度节点掉线导致整个作业失败

场景2：交互式即席查询（比如安全排障、日志实时检索，响应速度优先） #

这类场景需要随时提交查询，优先保障查询响应速度，选通用交互式集群：

• 运行时版本：Databricks Runtime 13.3 LTS Photon，自带矢量化执行引擎，半结构化日志的过滤、聚合查询速度比普通运行时快2-3倍
• 驱动节点：Standard_D16s_v5（16 vCPU，64GB内存），承载多用户同时提交查询的调度压力
• 工作节点：
  • 实例选型：Standard_D32s_v5（32 vCPU，128GB内存，自带200GB本地NVMe SSD）
  • 自动缩放规则：最小4节点，最大20节点，1.5TB日志的即席查询响应时间能控制在10分钟内，6TB满周期查询响应时间控制在30分钟内
• 必开优化配置：
  • 开启查询结果缓存，重复查询直接返回缓存结果，不用重复扫数据
  • 自动终止空闲时间设为60分钟，兼顾使用便利性和成本
  • 开启Delta Cache，把高频访问的近7天日志缓存到节点本地SSD，日常排障查近期日志的速度能提升一个数量级

落地注意事项 #

• 先把Storage Account里的日志按yyyy/MM/dd层级做日期分区，扫描时直接按时间范围剪枝，不要扫全量目录，实际扫描的数据量能降80%以上，作业速度和成本表现都会好很多，这步比集群升配的收益大得多
• 不要选8vCPU以下的小规格实例，这类实例单网卡带宽上限低，堆再多节点整体IO吞吐也上不去，还会增加分布式调度的额外开销
• 后续如果日志量上涨，直接调大自动缩放的最大节点数就行，不用换实例类型，这个规格的横向扩展兼容性很好
• 首次跑作业如果碰到任务倾斜（Spark UI里看到个别节点运行时间远高于其他节点），加个repartition按日志来源、时间字段打散数据就行，不用盲目升配
• 不用买GPU实例、超大内存实例这类高端配置，纯日志扫描场景下这类配置的性价比极低，钱花了速度提不了多少

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