企业官网建设流程全解析

一、AI资源/算力/模型业务知识体系

1.1 AI资源全景认知

核心概念：

1. AI资源站点：统一管理GPU/TPU/NPU等算力资源、模型资产、训练/推理任务的数据平台
   你可以这样理解这四位“计算专家”的分工：
   a. CPU 是总经理，处理复杂决策和调度。
   b. GPU 是专家团队，能处理图形、科学计算、AI训练等各种大规模并行任务，是市场最广的“实力派”。
   c. TPU 是云端超级流水线，专为谷歌处理超大AI模型而生。
   d. NPU 是终端节能小助手，在手机、PC上高效省电地运行AI任务。

2. 资源池（Resource Pool）：将物理算力按业务/团队/优先级抽象为逻辑资源池，支持配额管理、弹性调度

3. 算力调度：基于Kubernetes+Volcano/YARN等框架，实现训练任务的GPU分配、拓扑感知调度、装箱优化（Bin Packing）

关键指标体系（必须背熟）：

1 资源池 （AI 算力池、训练集群、推理集群、服务器集群）

1. 总卡数、可用卡数、分配卡数（包括不同业务线资源占比）
2. GPU利用率 实际计算时间/总可用时间，区分设备级利用率 vs 任务级利用率
3. 显存利用率 已分配显存/总显存，关注显存碎片率

注：在AI训练中，显存要存放模型参数、训练数据批次（Batch）、中间计算结果（梯度）等。 在nvidia-smi中，同时看
Volatile GPU-Util（计算利用率）和 Memory-Usage（显存利用率）。
a. 如果计算利用率低，但显存利用率高（>95%），大概率是显存瓶颈（数据搬运不过来，核心在等待）。
b. 如果计算利用率高，显存利用率也高（>95%），说明显卡在满负荷高效运转，是很好的状态。
c. 如果计算利用率低，显存利用率也低（<50%），说明负载太轻，要么是任务太小，要么是代码并行度没起来。

4. 资源碎片率 因分配粒度导致的小块闲置资源占比
5. 资源排队时长 任务提交到开始执行的等待时间

2 分配 （谁申请了算力、分配了多少、占用了多久、是否超配、是否排队、是否浪费）

1. 资源分配率、任务排队时长、资源满足率、超配率、抢占率
2. 配额使用率 团队实际使用/分配配额，反映资源规划合理性
3. 任务抢占率 高优先级任务抢占低优先级任务的频率
4. 弹性伸缩响应时间 从触发扩缩容到资源就绪的耗时

3 消耗 (业务、算法、模型训练/推理实际用了多少算力)

1. GPU 小时(卡时，用掉多少资源时长)、训练任务时长、推理调用量、显存占用、算力消耗趋势。
2. 单位算力成本 每GPU小时或每Token的算力成本
3. 模型训练成本 单次训练总GPU小时 × 单价，含试错成本
4. 推理QPS成本 每千次请求/每百万Token的推理成本

4 效能

1. 训练吞吐（Throughput） 每秒处理的样本数/Samples per second
2. 推理延迟（Latency） TTFT（首Token时间）+ TPOT（每Token输出时间）
3. 模型服务可用性 推理服务SLA，通常要求99.9%+ (服务可用率 = 总有效请求时间 − 不可用故障时间 ÷ 总统计时间)
4. MFU（Model FLOPs Utilization） 实际算力利用率，衡量训练效率的核心指标

面试话术：
“AI资源站点的BI建设，核心是让算力资源’可观测、可决策’。资源池维度关注’有多少、剩多少’，分配维度关注’给谁、给多少’，消耗维度关注’花多少、值不值’，效能维度关注’快不快、稳不稳’。四个模块的指标必须形成闭环，比如资源碎片率高会导致排队时长增加，进而推高单位算力成本。”

1.2 模型训练与推理的成本分析

1. 训练成本拆解：

• 单次训练成本 = GPU卡数 × 训练小时 × 单价
• 总拥有成本（TCO） = 硬件成本 + 电费 + 机房成本 + 运维人力 + 试错成本（通常试错成本占总成本30-50%）
• 成本优化手段：混合精度训练（FP16/BF16）、梯度检查点、ZeRO优化、模型并行/流水线并行、断点续训减少重复计算

2. 推理成本拆解：

• 在线推理：按QPS/Token计费，关键优化方向是Batching（动态批处理）、KV Cache复用、量化（INT8/INT4）
• 离线推理：按吞吐量计费，关注资源利用率和任务完成时间

面试追问准备：
• Q: DeepSeek声称训练成本仅600万美元，你怎么看？
• A:“600万美元是单次最终训练GPU成本，不含试错、研发、数据清洗成本。实际总成本可能数倍于此。但这个数字确实说明通过算法优化（如MLA、MoE架构）和工程优化（如高效并行策略）可以大幅降低算力需求，这对BI的意义是：我们需要建立更精细的成本归因体系，区分’有效算力’和’浪费算力’。”

1.3 算力资源调度与优化

调度策略：

• Bin Packing：将任务紧凑打包到最小节点集，减少资源碎片
• 拓扑感知调度：根据GPU互联拓扑（NVLink/InfiniBand）分配任务，减少通信开销
• 分时复用：MIG（Multi-Instance GPU）、MPS（Multi-Process Service）、Time-Slicing实现单卡多任务
• 抢占与回收：低优先级任务可被抢占，闲置任务自动检测并回收资源

面试话术：
“算力调度的BI分析要回答三个问题：资源够不够用（容量规划）、资源有没有浪费（效率分析）、资源分配公不公平（成本分摊）。比如通过监控GPU利用率发现某团队利用率长期低于30%，可以推动其使用分时复用或释放配额。”

二、BI体系搭建与可视化看板（从0到1，高频考点）

2.1 BI看板从0到1搭建全流程

标准流程（必须按此顺序回答）：

需求梳理 → 指标定义 → 数据建模 → 可视化设计 → 权限配置 → 发布运营 → 效果回收

各阶段要点：

① 需求梳理

• 明确看板受众：决策层（关注大盘趋势）、业务方（关注运营细节）、技术方（关注异常定位）
• 采用「用户画像+场景清单」法：列出每个角色的核心决策场景
• 输出需求文档：包含业务目标、核心问题、期望频率、决策动作

② 指标定义（最关键）

• 建立指标字典：指标名称、业务定义、计算公式、数据源、更新频率、负责人
• 区分北极星指标（唯一核心指标）和辅助指标
• 避免虚荣指标（Vanity Metrics）：如总下载量、页面浏览量等无法驱动行动的指标

③ 数据建模

• 采用数据仓库分层：ODS（贴源层）→ DWD（明细层）→ DWS（汇总层）→ ADS（应用层）
• 确定维度模型：星型模型/雪花模型，明确事实表与维度表
• 口径统一：同一指标在不同模块的计算逻辑必须一致

④ 可视化设计

• 布局原则：F型浏览路径，左上角放最关键指标
• 信息层级：总览（KPI卡）→ 趋势（折线图）→ 结构（饼图/柱状图）→ 明细（表格）
• 图表选择规范：
  趋势分析 → 折线图/面积图
  对比分析 → 柱状图/条形图
  占比分析 → 饼图/环形图/堆叠柱状图
  关联分析 → 散点图/热力图
  地理分析 → 地图
  流程分析 → 漏斗图

⑤ 权限与安全

• 行级权限：不同角色看到不同数据范围（如区域经理只看本区）
• 列级权限：敏感指标（如成本、利润率）仅对特定角色开放
• 数据脱敏：手机号、身份证号等PII字段脱敏展示

⑥ 发布与运营

• 建立使用机制：周会/晨会固定使用看板
• 设置反馈渠道：收集业务方意见持续迭代
• 监控看板活跃度：访问次数、停留时长、导出频率

⑦ 效果回收（闭环）

• 看板上线后追踪业务决策变化
• 量化看板价值：如因看板发现异常节省的成本、提升的效率

面试话术：
“从0到1搭建AI资源BI看板，我会先与资源运营团队、算法团队、财务团队进行三轮访谈，明确他们的核心决策场景。比如算法团队关心’我的任务排队多久能跑完’，财务团队关心’这个月的算力账单超没超预算’。然后围绕’资源全景-分配效率-消耗成本-服务效能’四大模块设计指标体系，每个模块3-5个核心指标，避免信息过载。数据层通过ODS→DWD→DWS→ADS四层建模，确保口径统一。可视化层采用’总览→趋势→结构→明细’的信息层级，支持下钻到团队/项目/任务粒度。最后建立周度Review机制，根据用户反馈迭代。”

2.2 专题分析方法论

专题分析标准框架：

问题定义 → 假设拆解 → 数据验证 → 根因定位 → 方案建议 → 效果预估 → 落地跟踪

AI资源方向专题案例：「GPU利用率下降分析」

1. 问题定义：某集群GPU周均利用率从75%下降至55%，需定位原因

2. 假设拆解：
   • 假设1：任务量减少（需求侧）
   • 假设2：任务排队增加但执行减少（调度侧）
   • 假设3：任务执行时间变长但GPU计算时间占比下降（任务侧）
   • 假设4：资源碎片增加导致无法调度大任务（资源侧）

3. 数据验证：
   • 验证假设1：对比同期任务提交量、GPU小时需求
   • 验证假设2：分析排队时长分布、调度成功率
   • 验证假设3：分析任务GPU计算时间/总运行时间比值
   • 验证假设4：分析资源碎片率、节点空闲GPU分布

4. 根因定位：发现因新增大量小模型推理任务，导致GPU显存碎片化，大训练任务无法调度

5. 方案建议：推动推理任务使用MIG共享GPU，大任务采用拓扑感知调度

6. 效果预估：预计碎片率从25%降至10%，利用率回升至70%+

7. 落地跟踪：每周监控碎片率和利用率变化

面试话术：
“专题分析不是简单的数据罗列，而是’用数据讲一个完整的故事’。面对GPU利用率下降，我会先用MECE原则穷尽所有可能假设，然后逐一用数据证伪或证实，最终定位到根因。关键是每个结论都要有数据支撑，每个建议都要有量化预期。”

三、指标体系设计（核心硬技能，必深挖）

3.1 指标体系设计方法论

OSM模型（Objective-Strategy-Measure）：

• O（业务目标）：AI资源站点的目标是「算力资源高效利用、成本可控、服务稳定」
• S（业务策略）：资源池化、智能调度、成本分摊、容量预警
• M（度量指标）：围绕策略设计可量化指标

AARRR模型（适用于资源运营）：

• Acquisition（获取）：资源申请量、新团队接入数
• Activation（激活）：资源首次使用率、任务启动率
• Retention（留存）：团队持续使用率、任务复跑率
• Revenue（收入/成本）：单位算力成本、预算执行率
• Referral（推荐）：内部满意度、跨团队推广率

MECE原则（Mutually Exclusive, Collectively Exhaustive）：

• 指标拆解时确保「相互独立、完全穷尽」
  • 例：算力成本 = 训练成本 + 推理成本；训练成本 = 人力成本 + 机器成本 + 试错成本

面试话术：
“指标体系设计的核心是’每个指标都有决策抓手’。我会用OSM模型对齐业务目标，用MECE原则确保拆解无遗漏，用AARRR模型覆盖资源全生命周期。最终输出’北极星指标+核心指标+观察指标’三级体系，北极星指标唯一且反映最终价值，核心指标5-8个驱动日常运营，观察指标用于下钻分析。”

3.2 AI资源方向指标体系实战

北极星指标候选：

• 集群整体GPU利用率（反映资源使用效率）
• 单位算力成本（反映成本控制）
• 任务满足率（资源申请量/实际分配量，反映供需平衡）

核心指标拆解示例：

【资源池模块】
├── 容量指标：总GPU卡数、总显存、总算力（TFLOPS）
├── 使用指标：GPU利用率、显存利用率、已分配率
└── 健康指标：故障卡数、待维修卡数、资源碎片率
【分配模块】
├── 效率指标：平均排队时长、调度成功率、任务等待率
├── 公平指标：配额使用率方差、团队资源满足率
└── 弹性指标：扩容响应时间、缩容释放率
【消耗模块】
├── 成本指标：总算力成本、单位GPU小时成本、单位Token成本
├── 分摊指标：团队成本占比、项目成本占比、人均算力成本
└── 预算指标：预算执行率、预算偏差率、超预算团队数
【效能模块】
├── 训练效能：训练吞吐（samples/sec）、MFU、收敛时间
├── 推理效能：QPS、P99延迟、TTFT、TPOT
└── 服务效能：可用性（uptime）、错误率、重试率

面试追问准备：
• Q: 如何避免指标堆砌？
• A: “三个原则：① 每个指标必须对应一个明确的决策场景，如果不知道这个指标变了要做什么，就不放；② 指标数量控制在’7±2’法则内，人脑短期记忆容量有限；③ 建立指标分级，看板只展示核心指标，详细指标支持下钻。”

3.3 指标口径管理

口径统一核心机制：

• 指标字典：统一存储指标名称、定义、公式、数据源、负责人
• 版本控制：指标变更需审批，保留历史版本，确保报表口径可追溯
• 血缘追溯：通过数据血缘自动追踪指标计算链路，发现口径漂移
• 自动化校验：定期交叉核对不同模块的同一指标，差异超阈值自动告警

常见口径冲突场景：

• 「活跃任务数」：是提交状态还是运行状态？包含排队中的吗？
• 「GPU利用率」：是时间维度（有任务的时间/总时间）还是算力维度（实际FLOPS/峰值FLOPS）？
• 「训练成本」：只算成功任务还是包含失败重跑？

面试话术：
“口径不一致是BI站点最大的敌人。我的做法是：事前建立指标字典和审批流程，事中通过血缘监控自动发现口径变更，事后通过交叉核对定期校验。比如’GPU利用率’必须在字典中明确是’时间利用率’还是’算力利用率’，不同模块引用同一指标时必须关联字典中的标准定义。”

四、数据质量治理与血缘关系（技术深度考点）

4.1 数据质量六维评估标准

1. 完整性 数据记录和信息是否完整，无缺失 任务日志是否缺失关键字段（如GPU型号、运行时长）
2. 准确性 数据记录的信息是否正确，无异常 GPU利用率超过100%（明显错误）、成本金额为负
3. 一致性 多个系统间的公共数据保持一致 调度系统的任务状态与监控系统的任务状态是否一致
4. 及时性 数据能及时产出和更新 资源使用数据T+1还是实时？延迟是否影响调度决策
5. 唯一性 无重复记录 同一任务ID是否存在多条记录
6. 有效性 数据格式、值域符合预期 时间戳格式统一、GPU型号在枚举范围内

4.2 数据质量监控（DQC）机制

DQC（Data Quality Center）核心能力：

1. 规则配置：支持表级/字段级规则，如空值检查、唯一性检查、波动率检查、值域检查

2. 强弱规则：
   • 强规则：触发红色异常时阻塞下游任务，防止脏数据扩散
   • 弱规则：仅告警不阻塞，用于非关键字段监控
   • 告警升级：点对点告警 → 负责人未处理 → 升级至Leader → 升级至值班经理

AI资源场景DQC规则示例：

• 表行数较7天前波动率 > 50% → 红色异常（可能任务日志采集失败）
• GPU利用率字段最大值 > 100% → 红色异常（数据采集错误）
• 成本字段空值率 > 5% → 橙色异常（部分任务未正确归集成本）
• 任务状态枚举值出现未知值 → 红色异常（上游系统变更未同步）

面试话术：
“数据质量治理采用’事前预防+事中监控+事后复盘’三层体系。事前在ETL环节嵌入清洗规则，标准化字段格式；事中通过DQC配置强弱规则，强规则阻断脏数据，弱规则及时告警；事后建立质量评分卡，定期复盘问题根因。在AI资源场景中，特别要关注调度系统与监控系统的一致性，因为两个系统的任务状态口径不一致会直接导致利用率计算错误。”

4.3 数据血缘（Data Lineage）

血缘定义与价值：

• 数据血缘：追踪数据从来源、经过转换、到最终使用的全链路关系
• 向上血缘（Source-to-Target）：数据从哪里来，经过哪些处理
• 向下血缘（Target-to-Source）：数据被哪些下游报表/系统/任务使用

血缘三大核心价值：

• 问题溯源：报表字段错误时，快速定位上游问题表或ETL任务
• 影响分析：上游Schema变更时，评估对下游报表的影响范围
• 合规审计：证明敏感数据未被违规访问，满足审计要求

血缘粒度：

• 表级血缘：表A → 表B → 表C
• 字段级血缘：表A.字段1 → 表B.字段2 → 报表.指标X（更精细，实现难度更大）

血缘采集方式：

• 静态解析：通过SQL Parser解析ETL脚本，提取输入输出关系
• 动态Hook：在Hive/Flink/Spark执行时通过Hook捕获运行时血缘
• 人工登记：通过元数据平台手动维护业务血缘（适用于非SQL类任务）

面试话术：
“数据血缘是数据治理的GPS导航。在AI资源BI站点中，血缘至少要做到表级，理想情况下做到字段级。比如当’GPU利用率’指标异常时，通过血缘可以追溯到它来自DWS层的哪张汇总表，再追溯到DWD层的任务日志表，最终追溯到ODS层的采集任务。如果上游采集任务逻辑变更，血缘也能自动识别所有受影响的下游报表，提前通知相关方。”

4.4 数据资产文档

数据资产文档核心内容：

• 技术元数据：表结构、字段类型、分区信息、存储位置、更新频率
• 业务元数据：指标定义、业务口径、使用场景、负责人、数据质量评分
• 管理元数据：数据安全等级、访问权限、生命周期（创建/归档/销毁时间）

数据资产目录价值：

• 让业务方像查字典一样快速找到所需数据
• 降低数据发现成本，提升数据复用率
• 支撑自助分析，减少重复提数

面试话术：
“数据资产文档是BI站点的’产品说明书’。每张表、每个指标都必须有完整的元数据登记，包括’是什么、从哪来、怎么用、谁负责’。我会推动建立数据资产目录，将技术元数据自动采集，业务元数据人工维护，并通过血缘关联形成全景视图。目标是让新业务方能在10分钟内找到所需数据并理解其口径。”

五、跨模块数据核对与一致性保障（岗位特色考点）

5.1 跨模块数据核对机制

核对场景：

AI资源站点涉及多个模块（资源池、分配、消耗、成本、效能），每个模块有独立的数据源和计算逻辑，极易出现口径不一致。
核对框架：
【事前】口径对齐会议 → 指标字典定义 → 统一计算逻辑
↓
【事中】每日交叉核对 → 差异自动告警 → 差异定位工具
↓
【事后】差异根因分析 → 规则修复 → 沉淀核对SOP

核对方法：

• 总分核对：模块A的汇总值应等于模块B的明细值之和
• 例：资源池模块的「总GPU小时」= 分配模块的「各团队使用GPU小时之和」
• 交叉验证：同一指标用不同数据源独立计算，对比差异
• 例：「任务运行时长」从调度系统取 vs 从GPU监控取，差异应<5%
• 逻辑校验：指标间应满足业务逻辑关系
• 例：「已分配GPU」≤「总GPU」，「成功任务数」+「失败任务数」=「总任务数」

面试话术：
“跨模块核对的核心是’同一事实，多个视角验证’。我会建立三层核对机制：第一层是指标字典层面的口径对齐，确保各模块对同一指标的定义一致；第二层是ETL层面的数据校验，通过DQC规则自动比对；第三层是报表层面的交叉验证，比如资源池的总量必须与分配模块的各团队用量之和相等。发现差异后，通过血缘工具快速定位是哪个模块的ETL逻辑出现了漂移。”

5.2 数据漂移（Data Drift）与链路断点

数据漂移类型：

• Schema漂移：上游表新增/删除/修改字段，下游未同步
• 分布漂移：数据值的统计分布发生变化（如GPU型号占比突变）
• 语义漂移：业务含义变化但字段名未变（如「任务成功」的定义从’运行完成’变为’运行完成且结果正确’）

链路断点类型：

• 采集断点：数据采集任务失败，导致ODS层数据缺失
• 传输断点：跨系统数据传输超时或丢包
• 计算断点：ETL任务OOM或逻辑错误，导致DWS层数据未更新
• 调度断点：任务依赖配置错误，导致下游任务未触发

检测与应对：

• Schema变更监控：通过元数据监控自动感知上游Schema变化
• 分布监控：对关键字段配置统计量监控（均值、方差、分位数），异常波动告警
• 链路健康度监控：监控每个ETL节点的输入输出记录数、处理时长、失败率
• 断点自动修复：对可重试的失败任务自动重跑，对不可重试的立即告警

面试话术：
“数据漂移和链路断点是数据质量的隐形杀手。Schema漂移通过元数据变更监控自动发现；分布漂移通过统计量阈值监控识别，比如某集群GPU型号分布突然从A100为主变为H100为主，可能意味着资源扩容未同步；链路断点通过DAG监控每个节点的输入输出记录数，如果某节点输入100万条但输出0条，立即触发断点告警。我的原则是’监控到每一个ETL节点，不遗漏任何一个断点’。”

六、SQL与数据处理（技术基础，必考实操）

6.1 SQL核心考点

窗口函数（必考）：

– 计算7日滑动平均GPU利用率

SELECT date, cluster_id, avg_gpu_util, AVG(avg_gpu_util) OVER ( PARTITION BY cluster_id ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW ) as util_7d_ma FROM daily_cluster_metrics;

– 计算任务执行时长的分位数（P50/P90/P99）

SELECT task_type, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY duration) as p50, PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY duration) as p90, PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY duration) as p99 FROM task_execution_log GROUP BY task_type;

– 计算连续N天资源使用率超过阈值的天数（连续登录/连续高负载）

WITH daily_usage AS ( SELECT team_id, date, CASE WHEN gpu_util > 0.8 THEN 1 ELSE 0 END as high_util_flag, ROW_NUMBER() OVER (PARTITION BY team_id ORDER BY date) as rn, ROW_NUMBER() OVER (PARTITION BY team_id, CASE WHEN gpu_util > 0.8 THEN 1 ELSE 0 END ORDER BY date) as grp_rn FROM team_daily_usage ) SELECT team_id, COUNT() as consecutive_days FROM daily_usage WHERE high_util_flag = 1 GROUP BY team_id, (rn - grp_rn) HAVING COUNT() >= 3;

CTE与递归查询：

– 血缘层级查询（向上追溯3层）

WITH RECURSIVE lineage AS ( -- 锚点：目标表 SELECT table_name, parent_table, 1 as level FROM table_lineage WHERE table_name = 'ads_gpu_util' UNION ALL -- 递归：向上追溯 SELECT tl.table_name, tl.parent_table, l.level + 1 FROM table_lineage tl JOIN lineage l ON tl.table_name = l.parent_table WHERE l.level < 3 ) SELECT * FROM lineage;

数据倾斜处理：

– 大表Join小表，小表广播避免倾斜
SELECT /*+ BROADCAST(b) */ *
FROM big_table a
JOIN small_table b ON a.key = b.key;
– 热点Key加盐打散
SELECT
CONCAT(a.key, ‘_’, CAST(RAND()*10 AS INT)) as salted_key,
a.
FROM skewed_table a;

面试话术：
“SQL是数据分析的基石。在AI资源场景中，我常用窗口函数计算资源使用的滑动平均和同比环比，用CTE构建复杂的数据处理链路，用递归查询实现血缘追溯。对于任务日志大表，会特别注意数据倾斜问题，比如某些热门团队的任务量占90%，Join时需要采用广播Join或加盐打散策略。”

6.2 数据仓库建模

分层设计：

• ODS（Operational Data Store）：贴源层，原始数据几乎不变，保留历史快照
• DWD（Data Warehouse Detail）：明细层，数据清洗、标准化、轻度汇总
• DWS（Data Warehouse Summary）：汇总层，按业务主题汇总（如团队日维、集群小时维）
• ADS（Application Data Store）：应用层，面向具体看板/报表的宽表

建模方法：

• 维度建模：星型模型（事实表+维度表），适合BI查询
• Data Vault：适合超大规模、多源异构场景
• 宽表模型：ADS层常用，通过预Join减少查询复杂度

面试话术：
“AI资源BI站点的数仓采用经典四层架构。ODS层直接对接调度系统、监控系统、财务系统的原始数据；DWD层进行数据清洗，统一时间格式、标准化GPU型号枚举值、过滤异常记录；DWS层按’团队×时间×资源类型’等维度构建汇总表；ADS层面向具体看板生成宽表。这种分层设计确保口径统一，同时ADS宽表能支撑秒级BI查询。”

七、Python数据分析（技术基础）

7.1 核心库与场景

1. Pandas 数据清洗、转换、分析 任务日志处理、资源使用统计
2. NumPy 数值计算、矩阵运算 利用率矩阵计算、成本分摊
3. Matplotlib/Seaborn 静态可视化 趋势图、分布图绘制
4. Plotly 交互式可视化 看板原型、下钻分析
5. Scikit-learn 机器学习基础 异常检测、资源需求预测

7.2 高频代码场景

异常检测（Isolation Forest）：

from sklearn.ensemble import IsolationForest import pandas as pd # 检测异常GPU利用率记录 df = pd.read_csv('gpu_metrics.csv') features = ['gpu_util', 'memory_util', 'temperature', 'power_draw'] model = IsolationForest(contamination=0.05, random_state=42) df['anomaly'] = model.fit_predict(df[features]) # -1 表示异常，1 表示正常 anomalies = df[df['anomaly'] == -1]

资源需求预测（时间序列）：

from statsmodels.tsa.holtwinters import ExponentialSmoothing #预测下周GPU需求 ts = df.set_index('date')['gpu_hours'] model = ExponentialSmoothing(ts, trend='add', seasonal='add', seasonal_periods=7) fit = model.fit() forecast = fit.forecast(steps=7)

成本归因分析：

基于Shapley值的成本公平分摊（简化版）

import numpy as np def shapley_cost_allocation(total_cost, individual_usages): # 将总成本按各团队使用量公平分摊 n = len(individual_usages) shapley_values = np.zeros(n) for i in range(n): # 计算团队i的边际贡献 marginal = 0 for subset in generate_subsets(n, i): with_i = cost_function(subset + [i], individual_usages, total_cost) without_i = cost_function(subset, individual_usages, total_cost) marginal += (with_i - without_i) * len(subset) * (n - len(subset) - 1) shapley_values[i] = marginal / math.factorial(n) return shapley_values

面试话术：
“Python是我日常分析的主力工具。用Pandas处理任务日志和监控数据，用Scikit-learn做资源使用的异常检测，用Statsmodels做容量需求的时序预测。比如在成本分析中，我会用Python实现成本归因模型，确保多团队共享集群时的成本分摊公平合理。”

八、跨团队协作与需求管理（软技能，定级关键）

8.1 需求转化方法论

需求转化流程：

模糊需求 → 业务访谈 → 问题定义 → 指标拆解 → 数据产品方案 → 技术评审 → 开发落地 → 效果回收

模糊需求转化技巧：

• 5W2H追问法：
• What：要看什么数据？
• Why：看这个数据要解决什么问题？
• Who：谁来看？多久看一次？
• When：什么时间范围的数据？
• Where：数据粒度到什么层级？
• How：希望以什么形式呈现？
• How much：数据量多大？性能要求？

需求优先级评估：

• ICE模型：Impact（影响范围）× Confidence（信心度）× Ease（实现难度）
• RICE模型：Reach（覆盖人数）× Impact（影响深度）× Confidence（信心度）/ Effort（工作量）

面试话术：
“面对业务方’我想看看资源使用情况’这种模糊需求，我会用5W2H法追问：是谁看？多久看一次？要解决什么问题？是关注效率还是成本？通过追问将模糊需求转化为’为算法团队负责人设计一张周度团队GPU利用率趋势看板，支持下钻到项目粒度，用于识别低效团队并推动优化’这样清晰的需求。”

8.2 数据产品方案设计

数据产品方案文档（PRD）结构：

1. 背景与目标：业务痛点、预期解决的问题
2. 用户画像：目标用户、使用场景、使用频率
3. 指标体系：核心指标、口径定义、数据来源
4. 数据模型：事实表/维度表设计、ETL逻辑
5. 可视化设计：页面布局、图表类型、交互逻辑
6. 权限设计：行级/列级权限、数据脱敏规则
7. 性能要求：查询响应时间、数据刷新频率
8. 验收标准：功能验收、数据准确性验收、性能验收
9. 效果回收指标：上线后如何评估价值

面试话术：
“数据产品方案是连接业务与技术的桥梁。我输出方案时会包含完整的指标体系定义、数据模型设计、可视化原型和权限规则，确保开发团队拿到方案就能执行。同时会明确效果回收指标，比如看板上线后’资源利用率提升X%‘或’成本异常发现时间从周级缩短到天级’。”

8.3 效果回收与闭环

效果回收方法：

• 定量评估：看板访问量、决策引用次数、因数据洞察产生的成本节约/效率提升
• 定性评估：用户满意度调研、访谈收集反馈
• A/B测试：对同一问题，对比使用看板前后的决策质量

面试话术：
“BI建设不是一锤子买卖，必须形成闭环。看板上线后，我会追踪两个层面的效果：一是使用层面，监控DAU、停留时长、导出次数；二是业务层面，量化因看板产生的实际价值。比如通过利用率看板推动3个团队优化任务配置，使整体GPU利用率从60%提升到75%，年化节省算力成本XX万元。”

九、阿里文化与面试技巧（加分项）

9.1 阿里数据文化关键词

• “让数据说话”：所有结论必须有数据支撑，避免主观判断
• “数据可信、可追溯、可解释”：JD中明确要求，面试中必须提及
• “从0到1”：强调建设能力，而非仅维护现有系统
• “跨团队协作”：阿里强矩阵组织，强调横向协同能力

9.2 面试应答结构（STAR法则升级版）

Situation（情境）：

“在XX公司负责AI平台数据建设时，面临资源利用率不透明、成本分摊争议大的问题…”

Task（任务）：

“我的目标是从0到1搭建AI资源BI体系，实现资源全景可观测、成本公平可分摊…”

Action（行动）：

“具体做了四件事：① 建立指标体系，定义GPU利用率、单位算力成本等核心指标；② 搭建四层数仓，统一口径；③ 设计可视化看板，支持团队/项目/任务三级下钻；④ 建立DQC监控，保障数据质量…”

Result（结果）：

“最终整体GPU利用率从55%提升至78%，成本分摊争议减少80%，资源申请响应时间从3天缩短至4小时…”

Reflection（反思，阿里特别看重）：

“如果重新做，我会在初期更深入地调研算法团队的实际工作流，因为发现部分指标（如MFU）对算法同学更有说服力，而业务方更关注成本…”

9.3 高频行为面试题准备

Q: 描述一次你处理数据口径不一致的经历
A: “在XX项目中，财务系统和运营系统对’训练成本’的定义不一致，财务包含硬件折旧，运营只算直接GPU租赁费。导致两个部门汇报的成本差异达40%。我的处理方式是：① 召集双方对齐口径，明确’直接成本’和’全成本’两个指标；② 在指标字典中清晰定义，分别服务于不同决策场景；③ 在报表中同时展示两个口径，并标注差异原因。最终双方达成共识，消除了数据争议。”

Q: 如果业务方坚持要一个技术上难以实现的指标，你怎么处理？
A: “首先理解业务方要这个指标的真实目的是什么——是监控风险？还是评估效果？还是向上汇报？然后提供替代方案：如果实时计算不可行，是否T+1可满足？如果精确值不可行，是否采样估算可满足？同时坦诚说明技术限制和实现成本，让业务方在’精度’和’时效’之间做知情选择。最终目标是找到满足业务核心诉求且技术可落地的方案。”

Q: 如何保证你建设的数据看板真正被用起来？
A: “三个手段：① 需求阶段就让业务方深度参与，确保看板解决的是他们的真实痛点，而不是我想象的痛点；② 设计阶段遵循’少即是多’，聚焦核心指标，避免信息过载；③ 上线后建立运营机制，比如每周五发送看板摘要邮件，每月组织数据Review会，将看板使用纳入业务方KPI考核。如果看板没人用，不是业务问题，是产品设计问题。”

十、面试自测清单

在背诵完上述内容后，用以下问题自测，确保每个问题都能流畅回答3分钟以上：
业务理解
• [ ] 请设计一套AI算力资源的指标体系，并说明北极星指标是什么
• [ ] GPU利用率下降15%，请做专题分析，给出完整思路
• [ ] 如何衡量一个AI资源BI站点的建设效果？
技术能力
• [ ] 写SQL：计算每个团队连续3天GPU利用率超过80%的时间段
• [ ] 写SQL：找出本月成本环比增长超过50%的团队，并列出其资源使用明细
• [ ] 如何从0到1设计一个数据质量监控方案？
• [ ] 数据血缘在AI资源场景中有哪些具体应用？
软技能
• [ ] 描述一次你从模糊需求到数据产品落地的完整经历
• [ ] 业务方和技术方对指标口径有争议，你如何处理？
• [ ] 如何推动不同团队使用你搭建的BI看板？
场景题
• [ ] 设计一张给CTO看的AI资源全景看板，你会放哪些指标？为什么？
• [ ] 新上线一个大模型训练任务，如何评估其对整体资源池的影响？
• [ ] 年终要做算力成本复盘，你会从哪些维度分析？输出什么结论？

背诵建议：

1. 先通读全文，建立知识框架
2. 对每个模块，用自己的话复述核心概念
3. 准备2-3个与AI资源/算力相关的项目案例，用STAR法则串联所有知识点