数据湖怎么监控？——关键指标和告警
先说结论
核心监控指标：表级指标文件数量、文件大小、数据跳过率；查询级指标查询耗时、Shuffle数据量、Task时间分布；系统级指标NameNode内存、Driver内存、Executor GC。
告警策略：小文件告警文件平均大小小于64MB、查询慢告警查询时间超过阈值、数据质量告警行数异常、存储告警增长过快。
监控工具：Spark UI、Prometheus+Grafana、Delta Lake's Table History、自定义指标采集。
最佳实践：设置分级告警Warning Critical、定期回顾告警有效性、监控指标可视化、建立告警响应流程.
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这道题面试官问得很多，因为数据湖监控是生产环境稳定运行的保障。我在某出海硬件品牌搭建过完整的监控体系，成功提前发现多个潜在问题。很多人只知道查询慢了才处理，但说不清楚怎么提前预警。面试官想听的是你能说清楚监控指标、告警策略和实战经验。
真实案例：监控提前发现数据异常
2023年在某知名出海硬件品牌，我们通过监控发现用户行为表的数据量异常。
监控指标：我们每天检查表的行数，正常情况下每天约1亿行。
# 每日数据量检查脚本
#!/bin/bash
COUNT=$(spark-sql -e "SELECT COUNT(*) FROM user_behavior WHERE dt='$(date +%Y-%m-%d)'" | tail -1)
if [ $COUNT -lt 50000000 ]; then
echo "WARNING: Low row count: $COUNT"
# 发送告警
fi发现异常：某天监控报警，行数只有1000万，远低于正常值1亿。
排查原因：上游任务失败了，数据没有写入。因为监控及时，我们在业务发现前就修复了问题。
改进效果：如果没有监控，业务部门第二天发现报表数据不对才会排查，影响更大。
表级监控指标
文件统计：文件数量、文件大小分布、小文件比例。DESCRIBE TABLE EXTENDED可以查看。
-- 查看表统计
DESCRIBE EXTENDED user_behavior;
-- 关键指标：
-- numFiles: 文件数量
-- sizeInBytes: 总大小
-- lastModified: 最后修改时间分区统计：分区数量、分区大小分布。分区数量过多需要合并，分区大小不均需要重新均衡。
数据跳过率：Z-Ordering表的跳过率。低于80%需要重新OPTIMIZE。
事务日志：事务日志大小、增长速度。日志过大需要VACUUM清理。
# 事务日志监控
LOG_SIZE=$(du -sh /data/user_behavior/_delta_log | awk '{print $1}')
if [ ${LOG_SIZE%G} -gt 10 ]; then
echo "WARNING: Transaction log too large: $LOG_SIZE"
fi查询级监控指标
查询耗时：总体耗时、各阶段耗时。duration超过阈值需要告警。
Stage耗时：找出慢Stage，定位瓶颈。某Stage占比超过50%需要优化。
Task耗时分布：数据倾斜检查。某Task耗时是平均值的10倍以上说明有倾斜。
Shuffle数据量：Shuffle Read/Write数据量。超过表大小50%说明Shuffle过多。
Spark SQL指标：通过Spark UI查看。dataSkewed、numRows、sizeInBytes等。
-- 查询监控
val df = spark.sql("SELECT * FROM user_behavior WHERE dt='2024-03-20'")
df.queryExecution.executedPlan.foreach { p =>
println(s"${p.nodeName}: ${p.metrics}")
}监控指标汇总表
| 类别 | 指标 | 阈值 | 告警 |
|---|---|---|---|
| 表级 | 文件平均大小 | < 64MB | 需要OPTIMIZE |
| 表级 | 文件数量 | > 10万 | 需要合并小文件 |
| 表级 | 分区数量 | > 10万 | 需要重新设计分区 |
| 表级 | 事务日志大小 | > 10GB | 需要VACUUM |
| 查询级 | 查询耗时 | > 正常值2倍 | 需要优化 |
| 查询级 | 数据跳过率 | < 80% | 需要重新Z-Ordering |
| 查询级 | Task最大耗时 | > 平均值10倍 | 数据倾斜 |
| 系统级 | NameNode内存使用 | > 80% | 需要扩容 |
告警策略设计
分级告警：Warning告警提示注意、Critical告警需要立即处理、Emergency告警需要电话通知。
告警抑制：相同告警5分钟内只发一次、告警确认后暂时抑制、维护窗口暂停告警。
告警路由：表级告警发送给数据owner、查询级告警发送给开发团队、系统级告警发送给运维团队。
告警响应：建立告警响应SLA、Critical告警15分钟内响应、Emergency告警立即响应。
# 告警脚本示例
#!/bin/bash
METRIC_VALUE=$(get_metric_value)
THRESHOLD_WARNING=100
THRESHOLD_CRITICAL=200
if [ $METRIC_VALUE -gt $THRESHOLD_CRITICAL ]; then
send_alert "CRITICAL: Value is $METRIC_VALUE"
elif [ $METRIC_VALUE -gt $THRESHOLD_WARNING ]; then
send_alert "WARNING: Value is $METRIC_VALUE"
fi监控工具选型
| 工具 | 用途 | 优点 | 缺点 |
|---|---|---|---|
| Spark UI | 查询监控 | 实时、详细信息 | 需要手动查看、无历史 |
| Delta History | 表变更监控 | 内置、易用 | 仅Delta Lake |
| Prometheus+Grafana | 综合监控 | 可视化、告警 | 需要配置metrics |
| 自定义脚本 | 灵活监控 | 完全自定义 | 需要维护 |
面试高频追问
追问一：监控指标太多，哪些是最重要的？
三个核心指标：1）文件平均大小，判断是否需要OPTIMIZE；2）查询耗时，判断性能是否正常；3）数据跳过率，判断Z-Ordering是否有效。其他指标是这三个的补充。
追问二：告警太多会产生告警疲劳，怎么解决？
三种方法：1）优化告警阈值，只告真正重要的问题；2）告警聚合，同类告警合并发送；3）告警抑制，相同告警短时间内只发一次。我们遇到过告警疲劳，通过优化阈值减少了80%的告警。
追问三：数据质量怎么监控？
四个维度：完整性行数检查、唯一性主键检查、准确性范围检查、及时性延时检查。例如user_id必须唯一、amount必须大于0、数据必须在每天8点前到达。这些都是数据质量监控的关键指标。
实战踩坑：告警漏配导致故障
2023年在某出海硬件品牌，我们因为缺少监控导致一次生产故障。
背景：我们监控了查询耗时，但没有监控文件数量。
问题：某张表的文件数量逐渐增加到100万个，单个查询打开了太多文件，Driver OOM失败。
原因：高频写入导致小文件越来越多，但我们没有监控文件数量指标。
解决方案：我们增加了文件数量和平均文件大小的监控告警。
# 新增监控：文件数量
#!/bin/bash
TABLE_PATH=/data/user_behavior
FILE_COUNT=$(hdfs dfs -count $TABLE_PATH/* | awk '{sum+=$1} END {print sum}')
AVG_SIZE=$(hdfs dfs -du -s $TABLE_PATH/* | awk '{sum+=$1; count++} END {print sum/count}')
if [ $FILE_COUNT -gt 100000 ]; then
send_alert "CRITICAL: Too many files: $FILE_COUNT"
fi
if [ $AVG_SIZE -lt 67108864 ]; then # 64MB
send_alert "WARNING: Average file size too small: $(($AVG_SIZE/1024/1024))MB"
fi改进效果：增加监控后，我们提前发现并处理了3次小文件问题，避免了生产故障。
总结
数据湖监控是生产环境稳定运行的保障。核心监控指标包括：表级文件数量和大小、查询级耗时和数据跳过率、系统级内存和GC。告警策略要分级、设置合理的阈值、避免告警疲劳。监控工具选择Spark UI、Prometheus、自定义脚本组合。最佳实践是：建立完整的监控体系、定期回顾告警有效性、建立告警响应流程。面试时能说清楚监控指标、告警策略、实战经验，就很稳.
下一篇聊一个综合案例：从Hive迁移到数据湖实战——完整迁移方案和踩坑经验
你们生产环境有哪些监控？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长