用途：tophog 是摄取管道的重键追踪器，worker 在内存中累计按 key 的聚合值（计数、计时），定期通过 Kafka（clickhouse_tophog 主题）刷入 tophog ClickHouse 表，用于回答“哪个行为者负责”这类 Prometheus 指标无法回答的问题（distinct_id、session_id 等标签基数无界）。数据仅存于 ClickHouse，保留 30 天。
访问：生产 ClickHouse 含客户数据，Grafana 中刻意不提供 ClickHouse 数据源。应用内部 Metabase，以工程师本人 SSO 会话访问。登录需用户自行执行：hogli metabase:login --region eu（或 us）。macOS 可能提示 “Chrome Safe Storage”，为 browser_cookie3 解密浏览器 cookie，一次性允许即可。数据库 id 不稳定，需先用 hogli metabase:databases --region eu 查得，选 “PostHog ClickHouse PROD Data Tier”（数据层而非查询层）。查询命令：hogli metabase:query --region eu --database-id <id> <<'SQL' ... SQL。
模式：表 tophog（分布式于 sharded_tophog），排序键 (pipeline, lane, metric, timestamp, key)，按天分区。列为 timestamp（DateTime64(6)，刷窗时间，务必限定范围）、metric、type（聚合语义 sum/max/avg）、key（Map，通过 key['team_id'] 等访问）、value、count、pipeline、lane、labels。一行是一个 worker 对某 (metric, key) 的一个刷窗，读取时须聚合：max 取 max(value)，avg 取 sum(value*count)/sum(count)，其余取 sum(value)。
指标清单应现场发现，勿信固定列表：SELECT metric, type, count() AS rows, sum(count) AS observations FROM tophog WHERE timestamp > now() - INTERVAL 1 HOUR GROUP BY metric, type ORDER BY metric。维度受部署门控，行不可变，需先检查数据是否含该维度。
核心思路是成本与量的对比：按 timer 总和排名找慢行为者，并按每事件毫秒比判断模式——高事件数、正常 ms/event 为热点键（可溢出/再平衡）；低事件数、高 ms/event 为昂贵行为者（扩容无益）。技能提供若干固定查询：按人员处理成本排名、限定某滞后分区、合并风暴、按类型的通用 top-10。
限制：distinct_id 与 session_id 属客户 PII（常为邮箱），仅限内部排障，切勿粘贴到公开 PR、issue 或提交信息；务必限定 timestamp；查询以工程师 Metabase 身份运行并记入查询历史。