跳到主要内容

看板加载慢排查

场景描述​

数据看板打开需要 20 秒以上，业务方投诉体验差，需要定位瓶颈并优化。

排查链路​

分层排查​

层级排查方法常见问题
前端Chrome DevTools Network请求过多、图表渲染慢
后端APM / 接口响应时间串行请求、无缓存
查询引擎EXPLAIN / 查询日志全表扫描、数据倾斜
存储磁盘 IO / 网络延迟冷数据未分层

优化方案​

1. 预计算 + 物化视图​

-- 将实时聚合改为预计算
-- 原始查询：每次请求实时聚合 10 亿行
SELECT channel, SUM(amount) FROM order_detail GROUP BY channel;

-- 优化：每日预计算到汇总表
CREATE TABLE dm_channel_daily AS
SELECT dt, channel, SUM(amount) AS total_amount, COUNT(*) AS order_cnt
FROM order_detail
GROUP BY dt, channel;

-- 看板查询：扫描汇总表，毫秒级
SELECT channel, total_amount FROM dm_channel_daily WHERE dt = '2024-01-15';

2. 查询缓存​

# BI 后端缓存策略
import redis
import hashlib
import json

r = redis.Redis()

def query_with_cache(sql, ttl=300):
    cache_key = f"bi:query:{hashlib.md5(sql.encode()).hexdigest()}"
    cached = r.get(cache_key)
    if cached:
        return json.loads(cached)
    result = execute_sql(sql)
    r.setex(cache_key, ttl, json.dumps(result))
    return result

3. 请求合并与并行​

改前：看板 10 个图表 → 10 个串行请求 → 总耗时 = 各请求之和
改后：看板 10 个图表 → 10 个并行请求 → 总耗时 ≈ 最慢的那个

4. 数据分层存储​

数据范围存储引擎查询速度
近 7 天ClickHouse 热数据< 1 秒
近 3 个月ClickHouse 温数据1-5 秒
历史归档HDFS / S3> 10 秒

常见面试问题​

Q1: BI 看板的合理加载时间是多少？​

答案：

  • 目标：首屏 3 秒内，全部图表 5 秒内
  • 可接受：10 秒内
  • 不可接受：20 秒以上（用户会放弃）

Q2: 如何在不改查询的情况下提升看板性能？​

答案：

  1. 加缓存：Redis 缓存高频查询，TTL 5-10 分钟
  2. 预计算：Airflow 定时预跑汇总结果
  3. 异步加载：图表分批渲染，先显示核心指标
  4. CDN：静态资源走 CDN

相关链接​