feat: querier supports biz source

[xiaochaoren1]

This PR is for:

[xiaochaoren1]

@claude 审核代码，中文回答

[claude]

Claude finished @xiaochaoren1's task in 2m 52s —— View job

---

待办

• 收集 PR 上下文并查看变更
• 理解需求并识别潜在风险
• 输出中文审核结论

审核结论

整体看，这个 PR 的目标比较明确：为 alert_event 增加 biz_type 标签枚举支持，并补充 policy_app_type 的业务类枚举值，同时在查询翻译层补上 biz_type 的枚举解析能力。改动范围集中，和现有 querier 的实现风格基本一致。

做了什么

• 在 server/querier/db_descriptions/clickhouse/tag/event/alert_event:71 追加了 biz_type 字段定义，并同步补齐中英文展示名。
• 在 server/querier/db_descriptions/clickhouse/tag/enum/biz_type.ch:1、server/querier/db_descriptions/clickhouse/tag/enum/biz_type.en:1 新增 biz_type 枚举值定义。
• 在 server/querier/db_descriptions/clickhouse/tag/enum/policy_app_type.en:2 与对应中文文件中，补充了业务类告警策略枚举值。
• 在 server/querier/engine/clickhouse/tag/translation.go:2220 增加 biz_type 的 Tag 翻译与 enum 查询能力。

优点

• 实现路径是对的：描述文件、枚举文件、查询翻译三处都补到了，没有只改 UI 展示而漏掉查询层。
• biz_type 采用 flow_tag.int_enum_map 做枚举翻译，和 event_level、policy_type 的实现保持一致，后续维护成本低。
• 变更足够聚焦，没有引入无关改动。

建议关注

1. alert_record 可能也需要同步支持 biz_type
   目前 alert_event 已新增 biz_type，但 alert_record 仍没有这个字段：

   • server/querier/db_descriptions/clickhouse/tag/event/alert_event:71
   • server/querier/db_descriptions/clickhouse/tag/event/alert_record:70-78

   如果产品侧希望“告警事件”和“告警记录”在筛选维度上保持一致，那这里会形成能力不对齐：用户在一个数据集能按 biz_type 查，在另一个数据集不能。
   这不一定是 bug，但建议确认是否为有意设计。

2. 英文展示名风格和仓库现有文件略不一致
   例如：

   • server/querier/db_descriptions/clickhouse/tag/event/alert_event.en:71 使用了 BusinessType
   • 仓库里已有多处同类字段使用 Business Type，如 server/querier/db_descriptions/clickhouse/tag/flow_metrics/application.en:63

   这不会影响功能，但会让 querier 的英文展示风格不统一。建议统一为带空格的命名，除非告警事件这组字段本来就刻意采用驼峰式展示。

风险与验证建议

• 我没有看到这个 PR 附带测试或查询样例验证。对于这类描述/翻译层改动，至少建议手工验证以下场景：
  • alert_event 查询返回 biz_type 原始值。
  • alert_event 按 biz_type enum 过滤时能正确命中新加的 1/2 枚举。
  • policy_type enum 对 4/5 的翻译是否生效。
• 如果底层 alert_event 数据里并不稳定携带 tag_int_names/tag_int_values 的 biz_type 项，那么 translation.go 新逻辑虽然安全，但前端仍可能看到空值，需要联调确认数据链路。

结论

我没有看到明显的阻塞性问题，PR 主体实现是合理的，可以合并前再确认一下 alert_record 是否也要补齐，以及英文展示名是否要统一风格。