一、AI资源/算力/模型业务知识体系1.1 AI资源全景认知核心概念AI资源站点统一管理GPU/TPU/NPU等算力资源、模型资产、训练/推理任务的数据平台你可以这样理解这四位“计算专家”的分工a. CPU 是总经理处理复杂决策和调度。b. GPU 是专家团队能处理图形、科学计算、AI训练等各种大规模并行任务是市场最广的“实力派”。c. TPU 是云端超级流水线专为谷歌处理超大AI模型而生。d. NPU 是终端节能小助手在手机、PC上高效省电地运行AI任务。资源池Resource Pool将物理算力按业务/团队/优先级抽象为逻辑资源池支持配额管理、弹性调度算力调度基于KubernetesVolcano/YARN等框架实现训练任务的GPU分配、拓扑感知调度、装箱优化Bin Packing关键指标体系必须背熟1 资源池 AI 算力池、训练集群、推理集群、服务器集群总卡数、可用卡数、分配卡数包括不同业务线资源占比GPU利用率 实际计算时间/总可用时间区分设备级利用率 vs 任务级利用率显存利用率 已分配显存/总显存关注显存碎片率注在AI训练中显存要存放模型参数、训练数据批次Batch、中间计算结果梯度等。 在nvidia-smi中同时看Volatile GPU-Util计算利用率和 Memory-Usage显存利用率。a. 如果计算利用率低但显存利用率高95%大概率是显存瓶颈数据搬运不过来核心在等待。b. 如果计算利用率高显存利用率也高95%说明显卡在满负荷高效运转是很好的状态。c. 如果计算利用率低显存利用率也低50%说明负载太轻要么是任务太小要么是代码并行度没起来。资源碎片率 因分配粒度导致的小块闲置资源占比资源排队时长 任务提交到开始执行的等待时间2 分配 谁申请了算力、分配了多少、占用了多久、是否超配、是否排队、是否浪费资源分配率、任务排队时长、资源满足率、超配率、抢占率配额使用率 团队实际使用/分配配额反映资源规划合理性任务抢占率 高优先级任务抢占低优先级任务的频率弹性伸缩响应时间 从触发扩缩容到资源就绪的耗时3 消耗 (业务、算法、模型训练/推理实际用了多少算力)GPU 小时(卡时用掉多少资源时长)、训练任务时长、推理调用量、显存占用、算力消耗趋势。单位算力成本 每GPU小时或每Token的算力成本模型训练成本 单次训练总GPU小时 × 单价含试错成本推理QPS成本 每千次请求/每百万Token的推理成本4 效能训练吞吐Throughput 每秒处理的样本数/Samples per second推理延迟Latency TTFT首Token时间 TPOT每Token输出时间模型服务可用性 推理服务SLA通常要求99.9% (服务可用率 总有效请求时间 − 不可用故障时间 ÷ 总统计时间)MFUModel FLOPs Utilization 实际算力利用率衡量训练效率的核心指标面试话术“AI资源站点的BI建设核心是让算力资源’可观测、可决策’。资源池维度关注’有多少、剩多少’分配维度关注’给谁、给多少’消耗维度关注’花多少、值不值’效能维度关注’快不快、稳不稳’。四个模块的指标必须形成闭环比如资源碎片率高会导致排队时长增加进而推高单位算力成本。”1.2 模型训练与推理的成本分析训练成本拆解单次训练成本 GPU卡数 × 训练小时 × 单价总拥有成本TCO 硬件成本 电费 机房成本 运维人力 试错成本通常试错成本占总成本30-50%成本优化手段混合精度训练FP16/BF16、梯度检查点、ZeRO优化、模型并行/流水线并行、断点续训减少重复计算推理成本拆解在线推理按QPS/Token计费关键优化方向是Batching动态批处理、KV Cache复用、量化INT8/INT4离线推理按吞吐量计费关注资源利用率和任务完成时间面试追问准备• Q: DeepSeek声称训练成本仅600万美元你怎么看• A:“600万美元是单次最终训练GPU成本不含试错、研发、数据清洗成本。实际总成本可能数倍于此。但这个数字确实说明通过算法优化如MLA、MoE架构和工程优化如高效并行策略可以大幅降低算力需求这对BI的意义是我们需要建立更精细的成本归因体系区分’有效算力’和’浪费算力’。”1.3 算力资源调度与优化调度策略Bin Packing将任务紧凑打包到最小节点集减少资源碎片拓扑感知调度根据GPU互联拓扑NVLink/InfiniBand分配任务减少通信开销分时复用MIGMulti-Instance GPU、MPSMulti-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利用率下降分析」问题定义某集群GPU周均利用率从75%下降至55%需定位原因假设拆解• 假设1任务量减少需求侧• 假设2任务排队增加但执行减少调度侧• 假设3任务执行时间变长但GPU计算时间占比下降任务侧• 假设4资源碎片增加导致无法调度大任务资源侧数据验证• 验证假设1对比同期任务提交量、GPU小时需求• 验证假设2分析排队时长分布、调度成功率• 验证假设3分析任务GPU计算时间/总运行时间比值• 验证假设4分析资源碎片率、节点空闲GPU分布根因定位发现因新增大量小模型推理任务导致GPU显存碎片化大训练任务无法调度方案建议推动推理任务使用MIG共享GPU大任务采用拓扑感知调度效果预估预计碎片率从25%降至10%利用率回升至70%落地跟踪每周监控碎片率和利用率变化面试话术“专题分析不是简单的数据罗列而是’用数据讲一个完整的故事’。面对GPU利用率下降我会先用MECE原则穷尽所有可能假设然后逐一用数据证伪或证实最终定位到根因。关键是每个结论都要有数据支撑每个建议都要有量化预期。”三、指标体系设计核心硬技能必深挖3.1 指标体系设计方法论OSM模型Objective-Strategy-MeasureO业务目标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 数据质量六维评估标准完整性 数据记录和信息是否完整无缺失 任务日志是否缺失关键字段如GPU型号、运行时长准确性 数据记录的信息是否正确无异常 GPU利用率超过100%明显错误、成本金额为负一致性 多个系统间的公共数据保持一致 调度系统的任务状态与监控系统的任务状态是否一致及时性 数据能及时产出和更新 资源使用数据T1还是实时延迟是否影响调度决策唯一性 无重复记录 同一任务ID是否存在多条记录有效性 数据格式、值域符合预期 时间戳格式统一、GPU型号在枚举范围内4.2 数据质量监控DQC机制DQCData Quality Center核心能力规则配置支持表级/字段级规则如空值检查、唯一性检查、波动率检查、值域检查强弱规则• 强规则触发红色异常时阻塞下游任务防止脏数据扩散• 弱规则仅告警不阻塞用于非关键字段监控• 告警升级点对点告警 → 负责人未处理 → 升级至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/P99SELECT 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 aJOIN small_table b ON a.key b.key;– 热点Key加盐打散SELECTCONCAT(a.key, ‘_’, CAST(RAND()*10 AS INT)) as salted_key,a.FROM skewed_table a;面试话术“SQL是数据分析的基石。在AI资源场景中我常用窗口函数计算资源使用的滑动平均和同比环比用CTE构建复杂的数据处理链路用递归查询实现血缘追溯。对于任务日志大表会特别注意数据倾斜问题比如某些热门团队的任务量占90%Join时需要采用广播Join或加盐打散策略。”6.2 数据仓库建模分层设计• ODSOperational Data Store贴源层原始数据几乎不变保留历史快照• DWDData Warehouse Detail明细层数据清洗、标准化、轻度汇总• DWSData Warehouse Summary汇总层按业务主题汇总如团队日维、集群小时维• ADSApplication Data Store应用层面向具体看板/报表的宽表建模方法• 维度建模星型模型事实表维度表适合BI查询• Data Vault适合超大规模、多源异构场景• 宽表模型ADS层常用通过预Join减少查询复杂度面试话术“AI资源BI站点的数仓采用经典四层架构。ODS层直接对接调度系统、监控系统、财务系统的原始数据DWD层进行数据清洗统一时间格式、标准化GPU型号枚举值、过滤异常记录DWS层按’团队×时间×资源类型’等维度构建汇总表ADS层面向具体看板生成宽表。这种分层设计确保口径统一同时ADS宽表能支撑秒级BI查询。”七、Python数据分析技术基础7.1 核心库与场景Pandas 数据清洗、转换、分析 任务日志处理、资源使用统计NumPy 数值计算、矩阵运算 利用率矩阵计算、成本分摊Matplotlib/Seaborn 静态可视化 趋势图、分布图绘制Plotly 交互式可视化 看板原型、下钻分析Scikit-learn 机器学习基础 异常检测、资源需求预测7.2 高频代码场景异常检测Isolation Forestfrom 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(contamination0.05, random_state42) 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, trendadd, seasonaladd, seasonal_periods7) fit model.fit() forecast fit.forecast(steps7)成本归因分析基于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结构背景与目标业务痛点、预期解决的问题用户画像目标用户、使用场景、使用频率指标体系核心指标、口径定义、数据来源数据模型事实表/维度表设计、ETL逻辑可视化设计页面布局、图表类型、交互逻辑权限设计行级/列级权限、数据脱敏规则性能要求查询响应时间、数据刷新频率验收标准功能验收、数据准确性验收、性能验收效果回收指标上线后如何评估价值面试话术“数据产品方案是连接业务与技术的桥梁。我输出方案时会包含完整的指标体系定义、数据模型设计、可视化原型和权限规则确保开发团队拿到方案就能执行。同时会明确效果回收指标比如看板上线后’资源利用率提升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: “首先理解业务方要这个指标的真实目的是什么——是监控风险还是评估效果还是向上汇报然后提供替代方案如果实时计算不可行是否T1可满足如果精确值不可行是否采样估算可满足同时坦诚说明技术限制和实现成本让业务方在’精度’和’时效’之间做知情选择。最终目标是找到满足业务核心诉求且技术可落地的方案。”Q: 如何保证你建设的数据看板真正被用起来A: “三个手段① 需求阶段就让业务方深度参与确保看板解决的是他们的真实痛点而不是我想象的痛点② 设计阶段遵循’少即是多’聚焦核心指标避免信息过载③ 上线后建立运营机制比如每周五发送看板摘要邮件每月组织数据Review会将看板使用纳入业务方KPI考核。如果看板没人用不是业务问题是产品设计问题。”十、面试自测清单在背诵完上述内容后用以下问题自测确保每个问题都能流畅回答3分钟以上业务理解• [ ] 请设计一套AI算力资源的指标体系并说明北极星指标是什么• [ ] GPU利用率下降15%请做专题分析给出完整思路• [ ] 如何衡量一个AI资源BI站点的建设效果技术能力• [ ] 写SQL计算每个团队连续3天GPU利用率超过80%的时间段• [ ] 写SQL找出本月成本环比增长超过50%的团队并列出其资源使用明细• [ ] 如何从0到1设计一个数据质量监控方案• [ ] 数据血缘在AI资源场景中有哪些具体应用软技能• [ ] 描述一次你从模糊需求到数据产品落地的完整经历• [ ] 业务方和技术方对指标口径有争议你如何处理• [ ] 如何推动不同团队使用你搭建的BI看板场景题• [ ] 设计一张给CTO看的AI资源全景看板你会放哪些指标为什么• [ ] 新上线一个大模型训练任务如何评估其对整体资源池的影响• [ ] 年终要做算力成本复盘你会从哪些维度分析输出什么结论背诵建议先通读全文建立知识框架对每个模块用自己的话复述核心概念准备2-3个与AI资源/算力相关的项目案例用STAR法则串联所有知识点 AI资源数据产品/开发/BI面试指南
一、AI资源/算力/模型业务知识体系1.1 AI资源全景认知核心概念AI资源站点统一管理GPU/TPU/NPU等算力资源、模型资产、训练/推理任务的数据平台你可以这样理解这四位“计算专家”的分工a. CPU 是总经理处理复杂决策和调度。b. GPU 是专家团队能处理图形、科学计算、AI训练等各种大规模并行任务是市场最广的“实力派”。c. TPU 是云端超级流水线专为谷歌处理超大AI模型而生。d. NPU 是终端节能小助手在手机、PC上高效省电地运行AI任务。资源池Resource Pool将物理算力按业务/团队/优先级抽象为逻辑资源池支持配额管理、弹性调度算力调度基于KubernetesVolcano/YARN等框架实现训练任务的GPU分配、拓扑感知调度、装箱优化Bin Packing关键指标体系必须背熟1 资源池 AI 算力池、训练集群、推理集群、服务器集群总卡数、可用卡数、分配卡数包括不同业务线资源占比GPU利用率 实际计算时间/总可用时间区分设备级利用率 vs 任务级利用率显存利用率 已分配显存/总显存关注显存碎片率注在AI训练中显存要存放模型参数、训练数据批次Batch、中间计算结果梯度等。 在nvidia-smi中同时看Volatile GPU-Util计算利用率和 Memory-Usage显存利用率。a. 如果计算利用率低但显存利用率高95%大概率是显存瓶颈数据搬运不过来核心在等待。b. 如果计算利用率高显存利用率也高95%说明显卡在满负荷高效运转是很好的状态。c. 如果计算利用率低显存利用率也低50%说明负载太轻要么是任务太小要么是代码并行度没起来。资源碎片率 因分配粒度导致的小块闲置资源占比资源排队时长 任务提交到开始执行的等待时间2 分配 谁申请了算力、分配了多少、占用了多久、是否超配、是否排队、是否浪费资源分配率、任务排队时长、资源满足率、超配率、抢占率配额使用率 团队实际使用/分配配额反映资源规划合理性任务抢占率 高优先级任务抢占低优先级任务的频率弹性伸缩响应时间 从触发扩缩容到资源就绪的耗时3 消耗 (业务、算法、模型训练/推理实际用了多少算力)GPU 小时(卡时用掉多少资源时长)、训练任务时长、推理调用量、显存占用、算力消耗趋势。单位算力成本 每GPU小时或每Token的算力成本模型训练成本 单次训练总GPU小时 × 单价含试错成本推理QPS成本 每千次请求/每百万Token的推理成本4 效能训练吞吐Throughput 每秒处理的样本数/Samples per second推理延迟Latency TTFT首Token时间 TPOT每Token输出时间模型服务可用性 推理服务SLA通常要求99.9% (服务可用率 总有效请求时间 − 不可用故障时间 ÷ 总统计时间)MFUModel FLOPs Utilization 实际算力利用率衡量训练效率的核心指标面试话术“AI资源站点的BI建设核心是让算力资源’可观测、可决策’。资源池维度关注’有多少、剩多少’分配维度关注’给谁、给多少’消耗维度关注’花多少、值不值’效能维度关注’快不快、稳不稳’。四个模块的指标必须形成闭环比如资源碎片率高会导致排队时长增加进而推高单位算力成本。”1.2 模型训练与推理的成本分析训练成本拆解单次训练成本 GPU卡数 × 训练小时 × 单价总拥有成本TCO 硬件成本 电费 机房成本 运维人力 试错成本通常试错成本占总成本30-50%成本优化手段混合精度训练FP16/BF16、梯度检查点、ZeRO优化、模型并行/流水线并行、断点续训减少重复计算推理成本拆解在线推理按QPS/Token计费关键优化方向是Batching动态批处理、KV Cache复用、量化INT8/INT4离线推理按吞吐量计费关注资源利用率和任务完成时间面试追问准备• Q: DeepSeek声称训练成本仅600万美元你怎么看• A:“600万美元是单次最终训练GPU成本不含试错、研发、数据清洗成本。实际总成本可能数倍于此。但这个数字确实说明通过算法优化如MLA、MoE架构和工程优化如高效并行策略可以大幅降低算力需求这对BI的意义是我们需要建立更精细的成本归因体系区分’有效算力’和’浪费算力’。”1.3 算力资源调度与优化调度策略Bin Packing将任务紧凑打包到最小节点集减少资源碎片拓扑感知调度根据GPU互联拓扑NVLink/InfiniBand分配任务减少通信开销分时复用MIGMulti-Instance GPU、MPSMulti-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利用率下降分析」问题定义某集群GPU周均利用率从75%下降至55%需定位原因假设拆解• 假设1任务量减少需求侧• 假设2任务排队增加但执行减少调度侧• 假设3任务执行时间变长但GPU计算时间占比下降任务侧• 假设4资源碎片增加导致无法调度大任务资源侧数据验证• 验证假设1对比同期任务提交量、GPU小时需求• 验证假设2分析排队时长分布、调度成功率• 验证假设3分析任务GPU计算时间/总运行时间比值• 验证假设4分析资源碎片率、节点空闲GPU分布根因定位发现因新增大量小模型推理任务导致GPU显存碎片化大训练任务无法调度方案建议推动推理任务使用MIG共享GPU大任务采用拓扑感知调度效果预估预计碎片率从25%降至10%利用率回升至70%落地跟踪每周监控碎片率和利用率变化面试话术“专题分析不是简单的数据罗列而是’用数据讲一个完整的故事’。面对GPU利用率下降我会先用MECE原则穷尽所有可能假设然后逐一用数据证伪或证实最终定位到根因。关键是每个结论都要有数据支撑每个建议都要有量化预期。”三、指标体系设计核心硬技能必深挖3.1 指标体系设计方法论OSM模型Objective-Strategy-MeasureO业务目标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 数据质量六维评估标准完整性 数据记录和信息是否完整无缺失 任务日志是否缺失关键字段如GPU型号、运行时长准确性 数据记录的信息是否正确无异常 GPU利用率超过100%明显错误、成本金额为负一致性 多个系统间的公共数据保持一致 调度系统的任务状态与监控系统的任务状态是否一致及时性 数据能及时产出和更新 资源使用数据T1还是实时延迟是否影响调度决策唯一性 无重复记录 同一任务ID是否存在多条记录有效性 数据格式、值域符合预期 时间戳格式统一、GPU型号在枚举范围内4.2 数据质量监控DQC机制DQCData Quality Center核心能力规则配置支持表级/字段级规则如空值检查、唯一性检查、波动率检查、值域检查强弱规则• 强规则触发红色异常时阻塞下游任务防止脏数据扩散• 弱规则仅告警不阻塞用于非关键字段监控• 告警升级点对点告警 → 负责人未处理 → 升级至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/P99SELECT 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 aJOIN small_table b ON a.key b.key;– 热点Key加盐打散SELECTCONCAT(a.key, ‘_’, CAST(RAND()*10 AS INT)) as salted_key,a.FROM skewed_table a;面试话术“SQL是数据分析的基石。在AI资源场景中我常用窗口函数计算资源使用的滑动平均和同比环比用CTE构建复杂的数据处理链路用递归查询实现血缘追溯。对于任务日志大表会特别注意数据倾斜问题比如某些热门团队的任务量占90%Join时需要采用广播Join或加盐打散策略。”6.2 数据仓库建模分层设计• ODSOperational Data Store贴源层原始数据几乎不变保留历史快照• DWDData Warehouse Detail明细层数据清洗、标准化、轻度汇总• DWSData Warehouse Summary汇总层按业务主题汇总如团队日维、集群小时维• ADSApplication Data Store应用层面向具体看板/报表的宽表建模方法• 维度建模星型模型事实表维度表适合BI查询• Data Vault适合超大规模、多源异构场景• 宽表模型ADS层常用通过预Join减少查询复杂度面试话术“AI资源BI站点的数仓采用经典四层架构。ODS层直接对接调度系统、监控系统、财务系统的原始数据DWD层进行数据清洗统一时间格式、标准化GPU型号枚举值、过滤异常记录DWS层按’团队×时间×资源类型’等维度构建汇总表ADS层面向具体看板生成宽表。这种分层设计确保口径统一同时ADS宽表能支撑秒级BI查询。”七、Python数据分析技术基础7.1 核心库与场景Pandas 数据清洗、转换、分析 任务日志处理、资源使用统计NumPy 数值计算、矩阵运算 利用率矩阵计算、成本分摊Matplotlib/Seaborn 静态可视化 趋势图、分布图绘制Plotly 交互式可视化 看板原型、下钻分析Scikit-learn 机器学习基础 异常检测、资源需求预测7.2 高频代码场景异常检测Isolation Forestfrom 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(contamination0.05, random_state42) 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, trendadd, seasonaladd, seasonal_periods7) fit model.fit() forecast fit.forecast(steps7)成本归因分析基于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结构背景与目标业务痛点、预期解决的问题用户画像目标用户、使用场景、使用频率指标体系核心指标、口径定义、数据来源数据模型事实表/维度表设计、ETL逻辑可视化设计页面布局、图表类型、交互逻辑权限设计行级/列级权限、数据脱敏规则性能要求查询响应时间、数据刷新频率验收标准功能验收、数据准确性验收、性能验收效果回收指标上线后如何评估价值面试话术“数据产品方案是连接业务与技术的桥梁。我输出方案时会包含完整的指标体系定义、数据模型设计、可视化原型和权限规则确保开发团队拿到方案就能执行。同时会明确效果回收指标比如看板上线后’资源利用率提升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: “首先理解业务方要这个指标的真实目的是什么——是监控风险还是评估效果还是向上汇报然后提供替代方案如果实时计算不可行是否T1可满足如果精确值不可行是否采样估算可满足同时坦诚说明技术限制和实现成本让业务方在’精度’和’时效’之间做知情选择。最终目标是找到满足业务核心诉求且技术可落地的方案。”Q: 如何保证你建设的数据看板真正被用起来A: “三个手段① 需求阶段就让业务方深度参与确保看板解决的是他们的真实痛点而不是我想象的痛点② 设计阶段遵循’少即是多’聚焦核心指标避免信息过载③ 上线后建立运营机制比如每周五发送看板摘要邮件每月组织数据Review会将看板使用纳入业务方KPI考核。如果看板没人用不是业务问题是产品设计问题。”十、面试自测清单在背诵完上述内容后用以下问题自测确保每个问题都能流畅回答3分钟以上业务理解• [ ] 请设计一套AI算力资源的指标体系并说明北极星指标是什么• [ ] GPU利用率下降15%请做专题分析给出完整思路• [ ] 如何衡量一个AI资源BI站点的建设效果技术能力• [ ] 写SQL计算每个团队连续3天GPU利用率超过80%的时间段• [ ] 写SQL找出本月成本环比增长超过50%的团队并列出其资源使用明细• [ ] 如何从0到1设计一个数据质量监控方案• [ ] 数据血缘在AI资源场景中有哪些具体应用软技能• [ ] 描述一次你从模糊需求到数据产品落地的完整经历• [ ] 业务方和技术方对指标口径有争议你如何处理• [ ] 如何推动不同团队使用你搭建的BI看板场景题• [ ] 设计一张给CTO看的AI资源全景看板你会放哪些指标为什么• [ ] 新上线一个大模型训练任务如何评估其对整体资源池的影响• [ ] 年终要做算力成本复盘你会从哪些维度分析输出什么结论背诵建议先通读全文建立知识框架对每个模块用自己的话复述核心概念准备2-3个与AI资源/算力相关的项目案例用STAR法则串联所有知识点