简历追问：监控 SaaS 大盘与 ClickHouse 可视化

关联：全栈工程师简历 > 全链路埋点与监控 SDK、15分钟：前端埋点与监控 SDK。

对应简历描述

利用 React 与 shadcn/ui 搭建了现代化的高颜值 SaaS 监控控制台，结合底层 ClickHouse 列式存储的查询优势，实现了海量监控数据的多维度可视化展示与实时大盘监控，为业务决策提供了精准的数据支撑。

面试官真正想确认

你是否知道监控大盘背后的指标口径、数据模型和查询设计，而不是只会画图表。

连续追问链

1. 大盘服务谁

• 这个控制台主要给研发、测试、产品、运营分别看什么？
• “业务决策”具体是哪类决策：转化漏斗、错误版本回滚、性能劣化、租户异常？
• 哪些指标是实时看，哪些指标允许 T+1 或分钟级延迟？

2. 数据模型

• 事件表如何设计：event_time、app_id、tenant_id、route、version、session_id、event_type？
• ClickHouse 的 partition key、order by、低基数字段如何选择？
• 高基数字段（userId、traceId、url query）如何避免拖垮查询？
• 业务事件、性能事件、异常事件是同一张宽表还是多表？为什么？

3. 查询与性能

• 计算 LCP p75、错误率、接口耗时 p95、TopN 路由分别怎么查？
• 是否使用物化视图、预聚合表、TTL、冷热分层？
• 实时大盘是 WebSocket、SSE、轮询还是定时刷新？如何避免用户一打开大盘就打爆 ClickHouse？

4. 可视化可信度

• shadcn/ui 只是 UI，真正难点在指标口径。你如何定义“活跃会话”“一次访问”“一次错误”？
• 数据缺失、采样、去重后，大盘如何提示口径？
• 多租户权限隔离怎么做？运营能不能看到其他租户数据？

场景推演题

要查询过去 24 小时按 app/version/route 分组的 LCP p75，并支持点击某个 route 查看错误样本。请设计 ClickHouse 表、查询和前端交互。

继续追：如果数据量上亿，查询从 300ms 变成 10s，你先怀疑哪里？

准备证据

• ClickHouse 表结构草案。
• 一两条典型 SQL。
• 指标口径文档。
• 大盘缓存与权限模型。

容易露馅的回答

• “ClickHouse 很快，所以不用设计。”
• “实时大盘就是前端轮询。”
• “高颜值大盘能说明数据价值。”
• “指标口径后端算，前端不用管。”