我的负责范围

BI 后端需要把业务人员的分析配置翻译成查询，同时维护标签、分群、报表和看板之间的关系。我参与团队系统中的分析、资产迁移与数据治理模块。

自己的提交覆盖路径分析、属性分析、通用下钻、结果保存为分群、标签历史版本、看板预计算、资产箱、埋点验收、第三方集成和事件差异告警。这些工作共同考验的是对数据含义和生命周期的理解。

分析查询：先理解语义，再生成 SQL

路径分析先归一化时间、事件、分析主体与过滤条件，再通过 Planner / Builder 生成 StarRocks SQL。查询用 CTE 分段处理基础事件、排序、会话切分和路径展开，并对候选事件与过滤条件设置阈值。

后续提交继续处理列表分组、虚拟事件、时间戳排序、查询结果限制与下钻。保存结果为分群时，还需要区分页面预览与完整主体集合：预览 LIMIT 不能成为最终人群的边界，SQL 输出列也要符合主体要求。

这部分让我学到，复杂 SQL 的难点往往在输入语义。时间精度、事件身份、对象组展开和下钻条件，只要有一处理解偏差，SQL 能跑也可能算错。

资产箱：迁移的是一张依赖图

报表和看板会引用事件、属性、指标、主体、标签或分群。跨项目迁移不能照搬源 ID，也不能按表逐条复制。

资产箱将过程拆成依赖收集、冲突预览、计划确认和执行。执行计划需要区分“跳过”“复用已有资产”和“新建”，按依赖顺序导入，并把源引用转换成目标引用。

自己的后续修复涉及重复开箱、父子属性、维表关系、分析主体和缺失列结构。比如目标已存在可复用资产时，只是无需再创建它，下游仍应绑定正确目标，不能连带被跳过。

这类工作最能体现我对业务约束的梳理能力：数据结构相似，不代表身份相同；定义迁移成功，也不代表计算结果已经可用。

数据治理：把异常变成可处理的信息

埋点管理补充了批量导入、类型和子属性处理、数据验收、错误样例统计；第三方集成扩展了 AppLovin、Tenjin 的报表与回调链路。

事件条数差异告警进一步比较两个平台同一事件的数量，保留异常明细并提供查看入口。这让“数据好像不对”能够落到具体项目、事件和差异类型，而不是只有一条无上下文的通知。

我在项目里积累的能力

• 语义建模：解释页面配置如何影响 SQL、分群范围和最终结果。
• 依赖分析：识别对象身份、父子关系、跨项目 ID 和冲突传播。
• 链路思维：连接数据采集、元数据、查询、迁移与告警，检查每段的输入和输出。

AI 参与大量代码实现，我需要把这些业务约束表达清楚，检查生成方案是否覆盖相关入口，并针对实际失败补充验证场景。