前端数据工程面试题

本题库共收录 66 道面试题（基础 14 / 进阶 25 / 深入 18 / 架构 9）。本文件收录前端数据工程相关面试题，目标题量 150 道。题型覆盖：概念题、场景设计题、系统设计题、工程化题、性能优化题、安全题、软技能题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（8 道）

FB-36-CO-B-001：前端埋点与数据采集有哪些方式？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：埋点、数据采集、代码埋点、全埋点、可视化埋点 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明前端常见的数据采集方式及其优缺点。

参考答案：

常见方式：

代码埋点：
- 开发者在关键位置手动插入埋点代码。
- 优点：数据精确、可控。
- 缺点：工作量大、容易遗漏、需随业务迭代维护。
全埋点（无埋点）：
- SDK 自动采集所有点击、页面浏览、输入等事件。
- 优点：快速上线、覆盖全面。
- 缺点：数据量大、噪声多、缺少业务语义。
可视化埋点：
- 运营/产品在页面上圈选元素配置埋点。
- 优点：降低开发依赖、快速配置。
- 缺点：对动态内容、SPA 支持有限，易失效。
服务端埋点：
- 后端记录请求、业务事件。
- 优点：准确、防篡改。
- 缺点：缺少前端交互细节。

最佳实践：

核心业务用代码埋点，保证准确。
探索性分析用全埋点补充。
可视化埋点用于简单页面运营需求。
前后端埋点结合校验。

评分维度：

方式覆盖（50%）：代码、全埋点、可视化、服务端
优缺点（30%）：准确、成本、噪声
选型（20%）：结合业务

常见错误：

全站只用全埋点，导致关键指标口径不一致。
代码埋点与业务代码耦合严重，难以维护。

延伸追问：

如何防止埋点代码污染业务代码？
埋点数据丢失常见原因有哪些？

相关题目：

FB-36-CO-A-001 埋点方案选型
FB-36-SD-R-002 设计埋点与采集系统

参考资源：

GrowingIO 埋点方案

口头回答版：

前端埋点有代码埋点、全埋点、可视化埋点和服务端埋点。代码埋点精确但工作量大；全埋点覆盖广但噪声多；可视化埋点快速但易失效。核心指标用代码埋点，探索分析用全埋点，前后端结合校验。

FB-36-CO-B-002：数据清洗与格式化在前端数据工程中的作用是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：数据清洗、格式化、ETL、数据质量、校验 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明数据清洗与格式化的必要性，并列举常见操作。

参考答案：

必要性：

原始数据可能存在缺失、错误、重复、格式不一致。
清洗后数据才能用于分析、可视化和模型训练。
保证指标口径一致，避免错误决策。

常见操作：

去重：根据唯一标识去除重复事件。
缺失值处理：填充、丢弃或标记。
类型转换：字符串转数字、日期解析。
标准化：统一单位、格式、编码。
异常检测：剔除明显错误的数据（如负数金额）。
字段映射：把不同来源字段对齐。
脱敏：隐藏敏感字段。

前端场景：

埋点 SDK 上报前做字段校验和补全。
数据可视化前做聚合和归一化。
表单/导入数据做清洗提示。

评分维度：

必要性（30%）：质量、口径、决策
操作覆盖（50%）：去重、缺失、转换、标准化、异常
前端场景（20%）：埋点、可视化、表单

常见错误：

直接使用原始数据做分析，导致指标失真。
清洗规则没有文档，口径不一致。

延伸追问：

数据清洗应该在前端还是服务端做？
如何处理实时流数据中的乱序？

相关题目：

FB-36-CO-B-006 数据质量校验
FB-36-CD-A-001 前端 ETL 设计

参考资源：

Apache Beam Programming Guide

口头回答版：

数据清洗格式化是为了处理缺失、错误、重复、格式不一致，保证指标口径。常见操作有去重、缺失处理、类型转换、标准化、异常检测、字段映射、脱敏。前端埋点、可视化、表单导入都需要。

FB-36-CO-B-003：前端 ETL/ELT 是什么？有什么区别？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：ETL、ELT、数据管道、抽取、转换、加载 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释 ETL 和 ELT 的概念，并说明前端数据工程中的应用场景。

参考答案：

ETL（Extract-Transform-Load）：
- 先抽取数据，再转换，最后加载到目标存储。
- 适合结构化程度高、转换规则明确的场景。
- 转换在前，目标存储负载小。
ELT（Extract-Load-Transform）：
- 先抽取并加载到目标存储，再利用目标存储计算能力转换。
- 适合大数据量、灵活探索分析。
- 利用数仓/数据湖算力，转换可复用。

前端应用：

前端埋点数据先经过 ETL 清洗后入仓。
用户行为原始日志用 ELT 入湖，再在数仓中分析。
前端实时数据处理可先做轻量 ETL，再发往消息队列。

选择：

数据量小、规则固定：ETL。
数据量大、需灵活分析：ELT。

评分维度：

概念区分（50%）：转换时机
适用场景（30%）：规则固定 vs 灵活分析
前端应用（20%）：埋点、实时处理

常见错误：

认为 ETL 一定比 ELT 好，忽略数据量和灵活性。
在前端做大量转换，增加客户端负担。

延伸追问：

数据湖与数据仓库在 ELT 中分别扮演什么角色？
前端如何做轻量级 ETL？

相关题目：

FB-36-CO-B-002 数据清洗与格式化
FB-36-SD-R-001 设计前端数据平台

参考资源：

AWS ETL vs ELT

口头回答版：

ETL 是先抽取转换再加载；ELT 是先加载到目标存储再转换。规则固定数据量小用 ETL，大数据灵活分析用 ELT。前端埋点可以轻量 ETL 后入仓，原始日志用 ELT 入湖再分析。

FB-36-CO-B-004：数据管道与消息队列在前端数据工程中的作用是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：数据管道、消息队列、Kafka、RocketMQ、解耦 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明数据管道和消息队列在前端数据采集、处理、消费中的作用。

参考答案：

数据管道：

连接数据源（埋点、日志、业务事件）与数据目的地（数仓、数据库、BI）。
负责数据的抽取、传输、转换、加载。
保证数据有序、可靠、可扩展地流动。

消息队列作用：

解耦：生产者和消费者独立扩展。
削峰：应对埋点流量突发，避免下游被压垮。
异步：前端埋点异步上报，不阻塞业务。
可靠：消息持久化，支持重试和回溯。
多消费：同一份数据可被分析、监控、推荐多个系统消费。

常见队列：

Kafka、RocketMQ、Pulsar、RabbitMQ、AWS Kinesis。

前端应用：

埋点 SDK 将事件批量发送到网关，网关写入消息队列。
实时看板消费队列做流处理。

评分维度：

数据管道（30%）：连接源与目的地
消息队列作用（50%）：解耦、削峰、异步、可靠、多消费
前端应用（20%）：埋点、实时看板

常见错误：

埋点直接同步调用后端接口，影响性能和可靠性。
忽略消息队列的消息顺序和重复问题。

延伸追问：

如何保证埋点消息不丢失？
消息队列如何处理顺序和重复消费？

相关题目：

FB-36-SD-R-002 设计埋点与采集系统
FB-32-CO-A-005 实时消息队列设计

参考资源：

Kafka Documentation

口头回答版：

数据管道把埋点、日志等数据传输到数仓和 BI。消息队列解耦生产消费、削峰、异步、可靠、支持多消费。前端埋点异步批量发到网关，再写入队列。实时看板可以消费队列做流处理。

FB-36-CO-B-005：实时处理与批量处理有什么区别？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：实时处理、批量处理、流处理、批处理、Lambda 架构 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请比较实时处理和批量处理的特点、适用场景，以及如何结合使用。

参考答案：

维度	批量处理	实时/流处理
延迟	分钟到小时	毫秒到秒
吞吐量	高	中高
数据量	大	持续小批量
适用	报表、T+1 分析、历史数据	监控、推荐、实时看板
复杂度	相对低	高（乱序、状态、容错）

结合使用：

Lambda 架构：批量层（批处理全量）+ 速度层（流处理增量）+ 服务层（合并查询）。
Kappa 架构：统一用流处理，简化架构。

前端应用：

实时：在线人数、实时转化看板、异常监控。
批量：日报、周留存、用户画像全量计算。

评分维度：

对比（50%）：延迟、吞吐量、适用
架构（30%）：Lambda、Kappa
前端应用（20%）：实时看板、日报

常见错误：

所有分析都追求实时，增加不必要复杂度。
批处理结果和实时结果口径不一致。

延伸追问：

流处理中的 watermark 和窗口是什么？
前端如何展示批处理和实时处理的合并结果？

相关题目：

FB-36-CO-A-003 前端实时数据处理
FB-36-SD-R-004 设计实时数据看板

参考资源：

Streaming 101

口头回答版：

批量处理延迟高吞吐大，适合报表和 T+1；实时流处理延迟低，适合监控和实时看板。可以 Lambda 架构批处理加流处理，或 Kappa 统一用流。前端实时看板用流，日报用批。

FB-36-CO-B-006：数据质量校验有哪些方法？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：数据质量、校验、完整性、准确性、一致性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明数据质量的维度以及前端数据工程中常用的校验方法。

参考答案：

数据质量维度：

完整性：必填字段是否缺失。
准确性：数据是否在合理范围内。
一致性：不同来源的数据口径是否一致。
及时性：数据是否按时到达。
唯一性：是否存在重复记录。

校验方法：

Schema 校验：字段类型、必填、枚举值。
规则校验：范围、正则、业务逻辑。
跨表/跨源校验：埋点与后端日志对数。
异常检测：统计分布、同比环比、阈值。
采样审计：人工抽检数据。
自动化测试：对关键指标写断言。

前端应用：

埋点 SDK 上报前校验字段。
数据看板中对异常值标红或告警。
数据导入时实时提示错误。

评分维度：

质量维度（30%）：完整、准确、一致、及时、唯一
校验方法（50%）：Schema、规则、对数、异常检测
前端应用（20%）：SDK、看板、导入

常见错误：

只校验格式，不校验业务逻辑。
发现数据质量问题没有告警和修复流程。

延伸追问：

如何处理历史存量数据的质量问题？
数据质量告警如何避免误报？

相关题目：

FB-36-CO-B-002 数据清洗与格式化
FB-36-SD-R-005 设计数据质量监控体系

参考资源：

Great Expectations

口头回答版：

数据质量包括完整性、准确性、一致性、及时性、唯一性。校验方法有 Schema 校验、规则校验、跨源对数、异常检测、采样审计、自动化测试。前端埋点 SDK 上报前要校验，看板里异常值要告警。

FB-36-CO-B-007：数据隐私与匿名化在前端如何处理？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：数据隐私、匿名化、脱敏、GDPR、个人信息保护法 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端数据采集和展示中的隐私保护措施。

参考答案：

保护措施：

最小化采集：只采集业务必需字段，避免收集敏感个人信息。
用户同意：在采集前获取用户同意，尤其是分析/广告埋点。
数据脱敏：
- 前端展示时对手机号、身份证、银行卡做掩码。
- 埋点上报前对敏感字段哈希或删除。
匿名化：
- 移除可直接识别个人的标识符。
- 使用假名化（pseudonymization）替代真实 ID。
加密传输：HTTPS/TLS。
访问控制：数据查询权限分级。
日志脱敏：日志中不打用户敏感信息。
保留期限：按合规要求定期清理数据。

前端实践：

埋点 SDK 内置脱敏规则。
数据导出时自动脱敏。
用户可查看和删除自己的数据。

评分维度：

保护措施（60%）：最小化、同意、脱敏、匿名化、加密
前端实践（40%）：SDK 脱敏、导出脱敏、用户权利

常见错误：

把用户 ID、手机号明文上报。
认为前端只做展示，隐私保护是后端的事。

延伸追问：

如何在保证分析价值的同时匿名化？
前端如何支持用户导出和删除个人数据？

相关题目：

FB-31-CO-P-003 隐私合规技术要求
FB-36-SD-R-001 设计前端数据平台

参考资源：

GDPR Official Text

口头回答版：

前端数据隐私要最小化采集、获取同意、脱敏展示和上报、匿名化处理、HTTPS 传输、日志脱敏、设保留期限。埋点 SDK 内置脱敏规则，用户可导出删除自己的数据。

FB-36-CO-B-008：数据驱动决策在前端团队如何落地？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：数据驱动、决策、指标、AB 测试、增长 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端团队如何通过数据支持产品决策和优化。

参考答案：

落地步骤：

定义目标：明确业务目标（转化率、留存、性能）。
指标体系：建立北极星指标和辅助指标。
埋点设计：围绕用户路径设计事件和属性。
数据采集：保证数据完整、准确、及时。
分析与洞察：
- 漏斗分析、留存分析、路径分析。
- 性能指标与业务指标关联。
实验验证：A/B 测试验证假设。
行动与迭代：根据数据结果优化产品，持续监控。

前端团队可关注：

页面加载性能对转化的影响。
交互路径中的流失点。
新功能的使用率和满意度。

文化建设：

用数据说话，避免拍脑袋决策。
建立数据 Review 机制。

评分维度：

步骤完整（50%）：目标、指标、埋点、采集、分析、实验、迭代
前端视角（30%）：性能、路径、功能使用
文化（20%）：数据驱动

常见错误：

只关注 PV/UV，缺乏行为深度分析。
数据采集后没有行动闭环。

延伸追问：

如何建立前端性能与业务指标的关联？
数据驱动与用户体验如何平衡？

相关题目：

FB-36-CO-A-002 用户行为分析
FB-36-CD-A-002 设计 AB 实验

参考资源：

Lean Analytics

口头回答版：

数据驱动要定义目标、建指标体系、设计埋点、采集、分析洞察、做 A/B 实验、行动迭代。前端关注性能对转化影响、路径流失、功能使用率。要建立用数据说话的文化。

进阶题（8 道）

FB-36-CO-A-001：埋点方案如何选型？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：埋点选型、代码埋点、全埋点、可视化埋点、自研 SDK 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请说明如何为项目选择合适的埋点方案，并分析自研与第三方的取舍。

参考答案：

选型维度：

数据精确度：代码埋点 > 可视化埋点 > 全埋点。
维护成本：全埋点/可视化埋点 < 代码埋点。
业务语义：代码埋点最能表达业务含义。
覆盖速度：全埋点最快。
隐私合规：自研更容易控制数据去向。

方案组合：

核心转化链路：代码埋点。
探索性分析：全埋点。
运营活动页：可视化埋点。

自研 vs 第三方：

维度	自研	第三方（神策/GrowingIO/GA）
数据主权	完全可控	依赖服务商
成本	开发维护成本高	按量付费
灵活度	高	受产品能力限制
功能	需自己实现	分析功能丰富
安全合规	易满足	需评估

选型建议：

中小型项目：第三方成熟方案。
大型/敏感数据：自研或混合。

评分维度：

选型维度（40%）：精确度、成本、语义、合规
自研 vs 第三方（40%）：对比清晰
建议（20%）：场景化

常见错误：

一刀切使用全埋点或代码埋点。
忽视数据安全和合规。

延伸追问：

如何评估第三方埋点 SDK 的性能影响？
自研埋点 SDK 需要哪些核心能力？

相关题目：

FB-36-CO-B-001 前端埋点方式
FB-36-SD-R-002 设计埋点与采集系统

参考资源：

神策数据埋点方案

口头回答版：

埋点选型看精确度、维护成本、业务语义和合规。核心链路用代码埋点，探索用全埋点，运营页用可视化埋点。自研可控但成本高，第三方功能丰富但要评估数据安全。中小项目用第三方，大型敏感业务自研或混合。

FB-36-CO-A-002：用户行为分析有哪些常用模型？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：用户行为分析、漏斗、留存、路径、归因 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请说明漏斗分析、留存分析、路径分析、归因分析的概念和应用。

参考答案：

漏斗分析：
- 把用户完成目标的步骤拆解，看每步转化率。
- 应用：注册漏斗、购买漏斗、表单提交漏斗。
留存分析：
- 观察用户在首次行为后第 N 天是否回访。
- 应用：次日留存、7 日留存、30 日留存。
路径分析：
- 分析用户在页面/功能间的流转顺序。
- 应用：发现常见路径和流失路径。
归因分析：
- 把转化功劳分配给不同触点（首次、末次、线性、时间衰减）。
- 应用：评估渠道和活动效果。
同期群分析（Cohort）：
- 按相同特征或时间段分组，对比行为差异。

实现要点：

事件需带用户 ID、时间戳、设备/来源属性。
会话（session）划分：通常 30 分钟无操作算新会话。

评分维度：

模型覆盖（50%）：漏斗、留存、路径、归因
应用理解（30%）：能解决什么问题
实现要点（20%）：事件字段、会话划分

常见错误：

漏斗步骤不基于用户实际行为，导致转化率失真。
留存计算口径不一致（活跃定义不同）。

延伸追问：

如何识别用户流失前的关键行为？
归因模型中首次点击和末次点击各适合什么场景？

相关题目：

FB-36-CO-B-008 数据驱动决策
FB-36-SD-R-003 设计用户行为分析系统

参考资源：

Amplitude Behavioral Analytics

口头回答版：

用户行为分析常用漏斗看步骤转化、留存看回访、路径看流转、归因看触点功劳、同期群对比分组。实现要记录用户 ID、时间、来源，划分会话。漏斗步骤要基于真实行为。

FB-36-CD-A-001：如何设计一个前端 A/B 实验？

题型：场景设计题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：A/B 测试、实验、指标、分组、显著性 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请设计一个前端 A/B 实验，包括分组、埋点、指标计算和结果判断。

参考答案：

设计步骤：

确定目标与假设：如“新按钮颜色提升点击率”。
选择指标：
- 核心指标：点击率、转化率。
- 护栏指标：页面加载时间、错误率。
分组：
- 按用户 ID 哈希分桶，保证同一用户稳定。
- 控制组与实验组流量比例（如 50/50）。
实验配置下发：
- 通过远程配置或 Edge 函数下发分组。
前端实现：
- 根据分组渲染不同 UI。
- 上报曝光和点击事件，带实验 ID、分组、用户 ID。
指标计算：
- 按实验分组聚合指标。
- 使用统计检验（t-test、卡方检验）判断显著性。
结果决策：
- 达到显著性且护栏指标无异常，才可全量。
收尾：
- 全量后清理实验代码和配置。

注意：

避免多个实验相互干扰（正交分层）。
确保样本量足够（power analysis）。
不要 peeking（提前看结果）。

评分维度：

实验设计（40%）：目标、指标、分组
前端实现（30%）：配置、渲染、埋点
统计分析（30%）：显著性、护栏、样本量

常见错误：

按设备或会话分组，导致用户体验不一致。
只看核心指标，忽略护栏指标。

延伸追问：

多实验并行时如何保证分组正交？
实验结果不显著怎么办？

相关题目：

FB-36-CO-B-008 数据驱动决策
FB-36-SD-R-004 设计 AB 实验平台

参考资源：

Netflix Experimentation

口头回答版：

A/B 实验先定目标和假设，选核心指标和护栏指标，按用户 ID 哈希稳定分组，远程配置下发，前端按分组渲染并上报曝光点击，最后统计显著性和护栏。要避免多实验干扰、确保样本量、不提前看结果。

FB-36-CO-A-003：前端实时数据处理有哪些方式？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：实时处理、WebSocket、SSE、流处理、Flink 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明前端实时数据处理的常见架构和技术选型。

参考答案：

实时数据流：

数据源 -> 消息队列（Kafka/Kinesis）-> 流处理引擎（Flink/Spark Streaming）-> API/WebSocket -> 前端。

前端接入：

WebSocket/SSE：实时推送更新。
轮询：简单但延迟高。
长轮询：折中方案。

前端处理：

数据缓冲与去重。
增量更新图表/列表。
背压处理：数据过快时采样或丢弃。
Web Worker：复杂计算不阻塞 UI。

场景：

实时在线人数、实时交易看板、实时监控告警。

选型：

低延迟推送：WebSocket/SSE。
大数据量聚合：后端 Flink 聚合后推送结果。
简单场景：轮询或 SSE。

评分维度：

数据流（30%）：采集、队列、流处理、前端
前端接入（30%）：WebSocket、SSE、轮询
处理策略（40%）：缓冲、去重、背压、Worker

常见错误：

前端直接消费原始高频数据，导致卡顿。
未处理消息乱序和重复。

延伸追问：

实时数据与离线数据口径不一致怎么办？
流处理中的窗口类型有哪些？

相关题目：

FB-32-CO-B-001 WebSocket SSE 长轮询
FB-36-SD-R-004 设计实时数据看板

参考资源：

Apache Flink

口头回答版：

前端实时处理通常后端用消息队列加 Flink 做流处理，再通过 WebSocket 或 SSE 推给前端。前端要做缓冲去重、增量更新、背压和 Web Worker。大数据量要在后端聚合后再推。

FB-36-CO-A-004：数据可视化报表如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：数据报表、可视化、BI、图表、交互 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明企业数据报表/看板的设计原则和前端实现要点。

参考答案：

设计原则：

明确受众：管理层看核心指标，运营看明细，分析师看多维下钻。
指标清晰：定义口径，避免歧义。
突出重点：用 KPI 卡、趋势图、对比图展示关键信息。
交互友好：支持筛选、下钻、联动、导出。
响应式：适配大屏、PC、移动端。

前端实现：

使用 ECharts/AntV/Tableau 等库。
数据按维度聚合，避免前端处理海量明细。
加载状态、空状态、错误状态处理。
权限控制：不同角色看到不同报表和数据范围。
缓存与性能：合理缓存、懒加载、分页。

可扩展：

拖拽式报表配置。
自定义 SQL/数据集。

评分维度：

设计原则（40%）：受众、指标、重点、交互
前端实现（40%）：库、聚合、状态、权限
扩展性（20%）：配置化、自定义

常见错误：

报表堆砌大量图表，信息过载。
指标口径不统一，导致决策错误。

延伸追问：

如何设计自助式 BI 报表？
报表权限如何做到行级控制？

相关题目：

FB-34-SD-R-001 设计 BI 可视化平台
FB-36-SD-R-004 设计实时数据看板

参考资源：

ECharts

口头回答版：

数据报表要明确受众、指标口径、突出重点、支持交互筛选下钻。前端用 ECharts 等库，后端聚合后返回，前端做加载空错误态、权限控制、缓存。可配置化支持自助 BI。

FB-36-PE-A-001：前端如何处理大数据量？

题型：性能优化题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：大数据量、Web Worker、Wasm、虚拟滚动、采样 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明前端在面对大量数据时的处理策略。

参考答案：

处理策略：

服务端聚合：
- 不要让前端处理原始海量数据，后端按维度聚合。
分页/分片：
- 列表分页、滚动加载、表格虚拟滚动。
采样与降维：
- 图表显示采样点（如 LTTB 算法）。
- 聚合时间窗口减少数据点。
Web Worker：
- 把排序、过滤、统计计算放到 Worker。
WebAssembly：
- 对计算密集型任务（如复杂算法、解析）用 Rust/C 编译为 WASM。
Canvas/WebGL：
- 大量图形用 GPU 渲染。
流式处理：
- 数据分块到达，边接收边处理。

避免：

一次性加载百万条数据到内存。
主线程做复杂计算导致页面卡顿。

评分维度：

服务端策略（20%）：聚合
前端策略（60%）：分页、采样、Worker、WASM、GPU
性能意识（20%）：避免内存和主线程阻塞

常见错误：

把后端该做的聚合放到前端。
虚拟滚动实现不当导致滚动卡顿。

延伸追问：

Web Worker 与 WASM 如何选择？
大文件解析（如 CSV）如何流式处理？

相关题目：

FB-34-CO-B-006 大数据量渲染瓶颈
FB-36-CO-A-003 前端实时数据处理

参考资源：

Web Workers MDN

口头回答版：

前端处理大数据量要靠服务端聚合、分页虚拟滚动、采样降维、Web Worker 和 WASM 计算、Canvas/WebGL 渲染、流式处理。不要把海量原始数据放前端，避免主线程阻塞。

FB-36-CO-A-005：数据湖/数仓概念如何与前端数据工程衔接？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：数据湖、数据仓库、ETL、BI、前端数据 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请解释数据湖、数据仓库的概念，并说明前端埋点数据如何进入这些系统。

参考答案：

数据仓库（Data Warehouse）：
- 结构化、主题化、经过清洗的数据，面向 BI 和报表。
- 代表：Snowflake、BigQuery、Redshift、Hive。
数据湖（Data Lake）：
- 原始、半结构化、非结构化数据低成本存储。
- 面向数据科学、探索分析。
- 代表：S3、HDFS、Delta Lake、Iceberg。

前端埋点数据入湖/仓流程：

前端埋点 SDK 采集事件。
事件经网关进入消息队列（Kafka）。
实时：Flink/Spark 清洗后写入数仓 ODS 层或数据湖。
离线：定时批量 ETL 到数仓 DWD/DWS/ADS 层。
BI/报表查询数仓，数据科学从数据湖取数。

前端角色：

保证埋点字段规范、完整、及时上报。
消费数仓/BI 输出的指标做看板。

评分维度：

概念区分（30%）：数仓结构化 vs 数据湖原始
数据流（40%）：埋点 -> 队列 -> 清洗 -> 湖/仓
前端角色（30%）：埋点规范、消费指标

常见错误：

认为数据湖就是大数据仓库。
前端埋点字段随意，导致入仓困难。

延伸追问：

数据湖三剑客 Delta Lake、Iceberg、Hudi 有什么区别？
前端如何与数据团队约定埋点 Schema？

相关题目：

FB-36-CO-B-003 ETL/ELT
FB-36-SD-R-001 设计前端数据平台

参考资源：

AWS Data Lake

口头回答版：

数据仓库存储结构化清洗后数据，面向 BI；数据湖存原始半结构化数据，面向探索分析。前端埋点经 Kafka、Flink 清洗后入湖/仓。前端要保证埋点字段规范，再消费 BI 指标。

FB-36-CO-A-006：数据治理与元数据管理在前端如何体现？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：数据治理、元数据、数据字典、血缘、质量 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明数据治理和元数据管理的重要性，以及前端团队应如何参与。

参考答案：

数据治理：

保证数据质量、安全、合规、可用。
包括标准、流程、组织、技术工具。

元数据管理：

业务元数据：指标定义、口径、负责人。
技术元数据：表结构、字段类型、ETL 任务。
操作元数据：数据生成时间、来源、质量状态。
数据血缘：数据从哪来、经过哪些处理、到哪去。

前端参与：

维护埋点事件和字段的数据字典。
代码中埋点与元数据平台联动（如通过注解/配置）。
参与指标口径定义，避免前端单独计算。
对敏感字段做脱敏和访问控制。
定期审计埋点完整性和准确性。

工具：

Apache Atlas、DataHub、自研元数据平台。

评分维度：

治理理解（30%）：质量、安全、合规
元数据类型（30%）：业务、技术、操作、血缘
前端参与（40%）：数据字典、口径、脱敏、审计

常见错误：

前端埋点字段没有文档，口径混乱。
数据治理只由数据团队负责，前端不参与。

延伸追问：

如何实现埋点代码与元数据平台的联动？
数据血缘如何影响前端埋点变更？

相关题目：

FB-36-CO-B-006 数据质量校验
FB-36-CP-R-002 跨团队数据治理

参考资源：

Apache Atlas

口头回答版：

数据治理保证数据质量、安全、合规。元数据包括业务定义、技术结构、操作信息和血缘。前端要维护埋点数据字典、参与指标口径、敏感字段脱敏、定期审计。可通过注解或配置与元数据平台联动。

深入题（7 道）

FB-36-CD-P-001：如何设计一个前端埋点 SDK？

题型：场景设计题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：埋点 SDK、采集、上报、去重、队列 出现频率：高频 预计回答时长：7-10 分钟

题目描述：请设计一个可复用的前端埋点 SDK，覆盖采集、存储、上报、去重、采样等能力。

参考答案：

核心模块：

采集器：
- 代码埋点 API：track(event, props)。
- 全埋点：自动监听 click、pv、input 等。
- 页面上下文：URL、referrer、设备、用户 ID、会话 ID。
队列与缓冲：
- 事件先入本地队列（内存 + localStorage/IndexedDB）。
- 批量上报，减少请求数。
上报策略：
- 定时上报、达到阈值上报、页面卸载前上报（sendBeacon）。
- 失败重试，指数退避。
去重与采样：
- 事件唯一 ID，服务端/客户端去重。
- 按用户/事件采样，降低流量。
隐私合规：
- 根据 Consent 状态决定是否采集/上报。
- 敏感字段脱敏。
性能：
- 异步执行，不阻塞主线程。
- 控制上报频率，避免耗电。
调试：
- 开发模式打印日志，提供事件预览。

接口示例：

Tracker.init({ appId, endpoint, sampleRate });
Tracker.track('button_click', { button_id: 'submit' });
Tracker.setUser({ userId });

评分维度：

模块设计（40%）：采集、队列、上报、去重、采样
可靠性与性能（30%）：批量、Beacon、重试、异步
隐私与调试（30%）：Consent、脱敏、日志

常见错误：

每次事件都立即发请求，影响性能。
页面关闭时未发送队列中事件。

延伸追问：

如何保证埋点顺序和服务端一致？
多端（Web/App/小程序）埋点 SDK 如何统一？

相关题目：

FB-36-CO-A-001 埋点方案选型
FB-36-SD-R-002 设计埋点与采集系统

参考资源：

Segment Analytics.js

口头回答版：

埋点 SDK 要有采集 API 和全埋点、本地队列批量上报、定时和卸载前上报、失败重试、去重采样、按 Consent 开关、敏感字段脱敏、异步不阻塞主线程。页面关闭用 sendBeacon。

FB-36-CO-P-001：如何保证埋点数据的准确性与完整性？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：埋点准确性、完整性、对数、校验、监控 出现频率：高频 预计回答时长：7-10 分钟

题目描述：请说明前端埋点数据常见的准确性、完整性问题及保障手段。

参考答案：

常见问题：

漏报：页面关闭前事件未发送、网络异常、SDK 未初始化。
多报：重复触发、刷新重发、SPA 路由重复上报。
错报：事件名/属性错误、时机不对。
数据不一致：前后端统计口径不同。

保障手段：

SDK 层面：
- 页面卸载前 flush 队列（sendBeacon）。
- 本地持久化，失败重试。
- 事件唯一 ID 去重。
代码层面：
- 埋点与业务代码解耦，使用装饰器/Hook。
- 代码审查埋点变更。
Schema 校验：
- 上报前校验字段类型和必填。
- 服务端再次校验。
对数机制：
- 前后端关键事件对账（如订单创建）。
- 按小时/天对数，差异告警。
监控：
- 监控漏报率、重复率、延迟、异常。
- 灰度发布埋点，先验证再全量。

评分维度：

问题识别（30%）：漏报、多报、错报、不一致
SDK 保障（30%）：flush、持久化、去重
治理保障（40%）：Schema、对数、监控、灰度

常见错误：

只关注上报成功，不关注数据对数。
埋点变更不经测试直接全量。

延伸追问：

SPA 页面浏览事件如何避免重复上报？
前后端对数口径不一致怎么办？

相关题目：

FB-36-CD-P-001 设计埋点 SDK
FB-36-SD-R-005 设计数据质量监控体系

参考资源：

Tracking Plan Best Practices

口头回答版：

保证埋点准确完整要解决漏报、多报、错报和口径不一致。SDK 要卸载前 flush、本地持久化、去重；代码层与业务解耦、Code Review；Schema 校验；前后端对数；监控漏报率和延迟；灰度发布。

FB-36-CO-P-002：时序数据与漏斗分析在前端如何实现？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：时序数据、漏斗分析、事件序列、路径分析 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明前端如何采集和分析时序事件数据，以及漏斗分析的实现思路。

参考答案：

时序数据采集：

每个事件带 event_time、user_id、session_id、event_name、properties。
保证客户端时间与服务端时间一致性（可用服务端到达时间或校正）。
对事件排序时考虑乱序和延迟到达。

漏斗分析实现：

定义漏斗步骤事件（如 view_product、add_cart、checkout、pay）。
按用户/会话分组，按时间排序事件序列。
计算从第 1 步到第 N 步的转化率，允许跳过步骤或严格顺序。
支持时间窗口（如 7 天内完成）。
支持维度拆分（渠道、设备、地区）。

前端展示：

用 ECharts 绘制漏斗图、趋势图。
支持下钻查看每步流失用户。

性能：

漏斗计算通常在后端/数仓完成，前端只展示结果。
小规模数据可在前端用 JS 计算。

评分维度：

时序采集（30%）：时间戳、会话、排序
漏斗计算（40%）：步骤、分组、窗口、维度
前端展示（30%）：图表、下钻

常见错误：

漏斗步骤不按用户实际行为顺序，而是按全局事件计数。
忽略时间窗口，把很久之前的事件也算入漏斗。

延伸追问：

如何处理漏斗中的循环步骤（如重复加购）？
漏斗分析中如何定义“流失”？

相关题目：

FB-36-CO-A-002 用户行为分析模型
FB-36-SD-R-003 设计用户行为分析系统

参考资源：

Funnel Analysis

口头回答版：

时序数据采集要带 event_time、user_id、session_id。漏斗分析定义步骤事件，按用户分组排序，计算每步转化率，支持时间窗口和维度拆分。计算一般在后端做，前端展示漏斗图和下钻。

FB-36-CO-P-003：用户画像与标签体系如何设计？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：用户画像、标签体系、规则标签、模型标签、实时标签 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明用户画像标签体系的构建方法，以及前端如何利用标签。

参考答案：

标签分类：

基础属性：性别、年龄、地域、设备。
行为标签：浏览偏好、购买频次、活跃度。
规则标签：基于业务规则计算（如“高价值用户”）。
模型标签：通过算法预测（如流失概率、兴趣分）。
实时标签：基于最近行为即时更新（如“正在浏览手机”）。

构建流程：

数据采集：埋点、业务数据、第三方数据。
数据清洗与 ID Mapping：统一用户 ID。
特征计算：批量离线 + 实时流计算。
标签存储：宽表、标签库、图数据库。
标签服务：提供 API 查询用户标签。
应用：个性化推荐、精准营销、A/B 分组。

前端利用：

调用标签服务获取用户画像。
根据标签动态渲染内容、推荐、弹窗。
注意隐私合规和性能（异步获取）。

评分维度：

标签分类（30%）：基础、行为、规则、模型、实时
构建流程（40%）：采集、ID Mapping、计算、存储、服务
前端应用（30%）：个性化、合规、性能

常见错误：

标签口径不统一，不同业务各算各的。
实时标签更新延迟高，影响体验。

延伸追问：

如何处理多设备同一用户的 ID Mapping？
标签数据如何保护用户隐私？

相关题目：

FB-36-CO-A-002 用户行为分析模型
FB-36-SD-R-001 设计前端数据平台

参考资源：

User Profile Design

口头回答版：

用户画像标签分基础属性、行为、规则、模型、实时标签。构建流程是采集数据、ID Mapping、特征计算、标签存储、标签服务。前端调用标签服务做个性化渲染，注意隐私和异步性能。

FB-36-SE-P-001：前端数据隐私合规有哪些深度措施？

题型：安全题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：数据隐私、合规、匿名化、差分隐私、数据最小化 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请深入说明前端数据工程在 GDPR、个保法等合规要求下的技术措施。

参考答案：

深度措施：

数据分类分级：
- 识别敏感字段，制定不同保护级别。
数据最小化：
- 只采集必要字段，避免过度收集。
同意管理（Consent）：
- 分类管理必要/分析/营销埋点。
- 未同意前不加载第三方分析脚本。
匿名化与假名化：
- 去除直接标识符，使用哈希后的假名 ID。
- 差分隐私：对聚合结果加噪，防止个体推断。
数据脱敏：
- 展示和日志中掩码处理敏感信息。
访问控制：
- 行级/列级权限，最小可见原则。
审计与追溯：
- 记录数据采集、使用、导出日志。
用户权利支持：
- 提供导出、删除、更正入口。
跨境传输：
- 按法律评估数据出境，签署 SCC 等协议。

评分维度：

分类与最小化（20%）
同意与匿名化（30%）：Consent、假名化、差分隐私
脱敏与权限（20%）
审计与用户权利（30%）

常见错误：

认为只要后端合规，前端无所谓。
差分隐私参数设置不当，导致数据失去分析价值。

延伸追问：

差分隐私的 ε 参数如何选择？
前端如何实现用户一键撤回同意？

相关题目：

FB-31-CO-P-003 隐私合规技术要求
FB-36-CO-B-007 数据隐私与匿名化

参考资源：

GDPR Official Text

口头回答版：

前端数据合规要做数据分类分级、最小化采集、Consent 管理、匿名化假名化、差分隐私、脱敏、访问控制、审计日志、支持用户导出删除。数据出境要评估。前端不能只靠后端。

FB-36-CO-P-004：实时与离线数据口径不一致怎么办？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：口径一致性、实时、离线、Lambda、Kappa 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请分析实时数据和离线报表结果不一致的原因，并给出解决方案。

参考答案：

不一致原因：

数据来源不同：实时读 Kafka，离线读数据库/日志。
时间窗口不同：实时按事件时间，离线按处理时间或分区时间。
清洗规则不同：离线有完整清洗，实时只做简单过滤。
去重策略不同：实时可能重复消费，离线按天去重。
计算逻辑不同：实时近似计算，离线精确计算。
延迟到达：实时窗口关闭后仍有数据到达。

解决方案：

统一数据源：
- 使用同一原始日志，实时和离线分别处理。
统一口径文档：
- 定义指标口径、维度、时间窗口。
统一计算逻辑：
- Lambda 架构中批量结果修正实时结果。
- Kappa 架构统一用流处理，减少双套逻辑。
对齐时间窗口：
- 使用事件时间，设置 watermark。
离线对账：
- 定时对比实时与离线结果，差异告警。
展示区分：
- 看板明确标注“实时估算”与“离线确认”。

评分维度：

原因分析（40%）：来源、窗口、清洗、去重、逻辑
解决方案（50%）：统一口径、Kappa/Lambda、对账
展示（10%）：标注差异

常见错误：

发现不一致后直接以离线为准，不查根因。
实时和离线使用完全不同的埋点事件。

延伸追问：

Kappa 架构真的能完全消除口径差异吗？
如何向业务解释实时数据与日报的差异？

相关题目：

FB-36-CO-B-005 实时与批量处理
FB-36-SD-R-004 设计实时数据看板

参考资源：

Lambda Architecture

口头回答版：

实时离线不一致常因为数据来源、时间窗口、清洗去重、计算逻辑不同。解决要统一数据源和口径文档，Lambda 用离线修正实时，Kappa 统一流处理，对齐事件时间和 watermark，定期对账，看板标注差异。

FB-36-CO-P-005：数据血缘与影响分析在前端数据工程中的作用是什么？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：36 前端数据工程标签：数据血缘、影响分析、元数据、埋点变更 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请解释数据血缘的概念，以及它如何帮助前端埋点和指标管理。

参考答案：

数据血缘：

描述数据从源头到最终使用的完整链路。
包括：数据从哪产生、经过哪些转换、被哪些报表/模型/产品使用。

作用：

变更影响分析：
- 修改埋点字段前，自动找出受影响的报表和指标。
问题定位：
- 指标异常时，沿血缘向上追溯数据来源。
合规审计：
- 追踪敏感数据流向。
资产梳理：
- 识别无用报表和冗余埋点。

前端应用：

埋点事件 -> 数仓表 -> BI 报表/算法模型/前端看板。
埋点 SDK 元数据与血缘平台对接。
代码提交变更时触发血缘告警。

工具：

Apache Atlas、DataHub、OpenLineage。

评分维度：

概念（30%）：数据链路
作用（40%）：影响分析、问题定位、合规、资产
前端应用（30%）：埋点 -> 报表 -> 看板

常见错误：

埋点变更后不知道影响了哪些报表。
血缘只覆盖后端表，不覆盖前端埋点。

延伸追问：

如何实现埋点事件级别的血缘？
数据血缘如何保证实时更新？

相关题目：

FB-36-CO-A-006 数据治理与元数据
FB-36-CP-R-002 跨团队数据治理

参考资源：

OpenLineage

口头回答版：

数据血缘是数据从产生到使用的完整链路。它能做变更影响分析、问题定位、合规审计和资产梳理。前端埋点事件到数仓表再到报表和看板，SDK 元数据可与血缘平台对接，变更时告警。

架构题（43 道）

FB-36-SD-R-001：如何设计一个前端数据平台？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：前端数据平台、埋点、分析、BI、数据治理 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个支撑多业务的前端数据平台，覆盖采集、处理、分析、应用和治理。

参考答案：

平台架构：

采集层：
- 统一埋点 SDK（Web/App/小程序）。
- 支持代码埋点、全埋点、可视化埋点。
传输层：
- 埋点网关 -> 消息队列（Kafka）。
- 实时流与离线批量双通道。
处理层：
- 实时：Flink/Spark Streaming 清洗、 enrichment。
- 离线：Spark/Hive 做 T+1 计算。
- 数据入湖/仓。
分析层：
- 事件分析、漏斗、留存、路径、归因。
- 自助式 BI 报表。
应用层：
- 数据看板、A/B 实验、用户画像、个性化推荐。
治理层：
- 埋点管理、元数据、数据质量、权限、合规。

关键能力：

统一事件 Schema 和埋点规范。
多租户、按业务隔离。
实时 + 离线一体化。
数据血缘和口径管理。

评分维度：

分层完整（40%）：采集、传输、处理、分析、应用、治理
关键能力（30%）：Schema、多租户、实时离线一体
可扩展性（30%）：新事件、新业务接入

常见错误：

各业务独立埋点，无法统一分析。
只建看板，不做数据治理。

延伸追问：

如何评估前端数据平台的 ROI？
平台与业务团队的职责边界是什么？

相关题目：

FB-36-SD-R-002 设计埋点与采集系统
FB-36-SD-R-003 设计用户行为分析系统

参考资源：

Apache Kafka

口头回答版：

前端数据平台分采集层统一 SDK、传输层消息队列、处理层实时 Flink 和离线 Spark、分析层事件分析和 BI、应用层看板实验画像、治理层 Schema 质量权限。要统一事件规范、多租户、实时离线一体、数据血缘。

FB-36-SD-R-002：如何设计一个埋点与采集系统？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：埋点系统、采集、SDK、网关、消息队列 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个高可用、可扩展的前端埋点采集系统。

参考答案：

系统组成：

SDK：
- 统一 API、全埋点、代码埋点、上下文管理。
- 队列、批量、重试、去重、采样。
采集网关：
- 接收埋点请求，做鉴权、限流、格式校验。
- 写入消息队列，失败时降级。
消息队列：
- Kafka/RocketMQ，削峰解耦。
处理层：
- 实时清洗、ID Mapping、补全字段。
- 分发到数仓/数据湖/实时计算。
埋点管理平台：
- 事件注册、Schema 管理、审批、变更影响分析。
监控：
- 上报成功率、延迟、漏报率、队列积压。

高可用：

网关多节点、队列多副本。
SDK 本地缓存，网络恢复后重传。
限流防止单业务拖垮系统。

可扩展：

按业务/事件 topic 分片。
SDK 插件化，支持新业务快速接入。

评分维度：

系统组成（40%）：SDK、网关、队列、处理、平台
高可用（30%）：缓存、重试、限流、多副本
可扩展（30%）：分片、插件、新业务接入

常见错误：

SDK 直接写数据库，无法扩展。
没有埋点管理平台，事件口径混乱。

延伸追问：

如何应对埋点流量突发 10 倍？
埋点 Schema 变更如何平滑升级？

相关题目：

FB-36-CD-P-001 设计埋点 SDK
FB-36-CO-P-001 埋点准确性完整性

参考资源：

Apache Kafka

口头回答版：

埋点采集系统包括统一 SDK、采集网关、消息队列、实时处理、埋点管理平台。网关做鉴权限流校验，队列削峰，处理层清洗和 ID Mapping。要高可用多副本、SDK 本地缓存重传、限流；可扩展按 topic 分片和插件化。

FB-36-SD-R-003：如何设计一个用户行为分析系统？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：用户行为分析、漏斗、留存、路径、事件分析 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个支持事件分析、漏斗、留存、路径分析的用户行为分析系统。

参考答案：

数据流：

埋点数据 -> 消息队列 -> 实时清洗 -> 数仓 ODS/DWD/DWS 层。
预聚合表：按事件、用户、会话、维度预计算。

事件分析：

按事件名、属性、时间筛选，统计 PV/UV/人均次数。
支持 group by 维度和时间粒度。

漏斗分析：

预定义漏斗步骤。
按用户/会话分组，计算每步转化和流失。
支持窗口期和严格/宽松顺序。

留存分析：

cohort 表：首次行为日期 × 后续回访日期。
预计算 N 日留存矩阵。

路径分析：

构建用户行为序列图。
使用桑基图或树图展示流转。

前端：

查询 DSL 或拖拽式配置。
图表与表格结合，支持下钻和导出。

性能：

预聚合 + 物化视图加速查询。
大数据量下限制明细查询。

补充说明：

在实际落地设计一个用户行为分析系统时，建议结合用户行为分析、漏斗、留存的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

数据流（30%）：ODS/DWD/DWS、预聚合
分析模型（40%）：事件、漏斗、留存、路径
前端与性能（30%）：查询配置、图表、预聚合

常见错误：

每次查询都扫描原始明细，性能差。
漏斗定义不灵活，无法满足业务需求。

延伸追问：

如何支持自定义事件属性筛选？
用户路径爆炸如何聚合？

相关题目：

FB-36-CO-A-002 用户行为分析模型
FB-36-CO-P-002 时序数据与漏斗

参考资源：

Amplitude Architecture

口头回答版：

用户行为分析系统埋点数据入仓后做 ODS/DWD/DWS 分层和预聚合。事件分析按维度统计；漏斗按用户分组计算转化；留存用 cohort 矩阵；路径用桑基图。前端支持拖拽配置和下钻，大数据用预聚合加速。

FB-36-SD-R-004：如何设计一个 A/B 实验平台？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：A/B 平台、实验、分组、指标、统计分析 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个支持多业务、多实验并行的 A/B 实验平台。

参考答案：

核心模块：

实验管理：
- 创建实验、配置分组、流量比例、目标指标、护栏指标。
- 实验状态：草稿、运行中、暂停、全量、归档。
分组服务：
- 按用户 ID 哈希分桶，保证稳定。
- 支持正交分层，多实验互不干扰。
配置下发：
- 远程配置中心或 Edge 函数下发分组。
埋点上报：
- 事件带实验 ID 和分组，用于指标计算。
指标计算：
- 实时/离线统计各组指标。
- 显著性检验、置信区间、样本量校验。
报告与决策：
- 可视化实验结果，推荐胜出版本。
- 异常告警、自动停止负向实验。

扩展性：

多业务隔离，权限控制。
支持灰度发布、Feature Flag。

补充说明：

在实际落地设计一个 A/B 实验平台时，建议结合 A/B 平台、实验、分组的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

模块完整（40%）：实验管理、分组、配置、埋点、计算、报告
统计科学性（30%）：显著性、样本量、护栏
扩展与安全（30%）：正交分层、权限、灰度

常见错误：

实验分组不稳定，用户体验不一致。
多实验相互干扰，无法归因。

延伸追问：

如何保证实验分组在跨端一致？
实验指标不显著时如何决策？

相关题目：

FB-36-CD-A-001 设计前端 A/B 实验
FB-33-CP-P-001 多语言 A/B 测试

参考资源：

Twitter Experimentation Platform

口头回答版：

A/B 平台包括实验管理、分组服务、配置下发、带实验 ID 的埋点、指标计算与统计检验、报告决策。分组要按用户 ID 哈希稳定，多实验正交分层。支持灰度和自动停止负向实验。

FB-36-SD-R-005：如何设计一个数据质量监控体系？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：数据质量、监控、告警、对数、血缘 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一套覆盖前端埋点到后端数仓的数据质量监控体系。

参考答案：

监控维度：

完整性：字段缺失率、事件丢失率。
准确性：异常值、类型错误、业务规则校验。
一致性：前后端对数、实时离线口径。
及时性：数据到达延迟、处理延迟。
唯一性：重复事件率。

监控手段：

Schema 校验：入仓前自动校验字段。
规则引擎：配置业务规则，自动检测异常。
对数平台：关键事件前后端按小时/天对账。
数据探查：统计分布、同比环比。
血缘追踪：变更影响分析，快速定位问题。

告警与响应：

按严重程度分级，通知相关owner。
自动降级或补数流程。
数据质量 Dashboard 和趋势。

前端参与：

SDK 上报质量指标。
埋点 Schema 与质量平台联动。

评分维度：

维度覆盖（30%）：完整、准确、一致、及时、唯一
监控手段（40%）：Schema、规则、对数、探查、血缘
响应机制（30%）：告警、降级、补数

常见错误：

只监控后端表，不监控前端埋点质量。
告警过多导致团队麻木。

延伸追问：

数据质量异常时如何快速止血？
如何量化数据质量对业务的影响？

相关题目：

FB-36-CO-B-006 数据质量校验
FB-36-CO-P-001 埋点准确性完整性

参考资源：

Great Expectations

口头回答版：

数据质量监控覆盖完整性、准确性、一致性、及时性、唯一性。手段有 Schema 校验、规则引擎、前后端对数、数据探查、血缘追踪。要分级告警、自动降级补数、Dashboard 趋势。前端 SDK 也要上报质量指标。

FB-36-CP-R-001：跨团队数据治理如何推进？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：数据治理、跨团队、规范、埋点、指标口径 出现频率：中频 预计回答时长：10-15 分钟

题目描述：作为前端数据工程负责人，你如何推动产品、运营、数据、前端多团队做好数据治理？

参考答案：

治理框架：

统一规范：
- 埋点事件命名、字段命名、数据类型、版本管理。
- 指标口径定义文档，明确计算方式。
统一平台：
- 埋点管理平台、指标平台、BI 平台、元数据平台。
角色职责：
- 产品/运营：定义业务指标和分析需求。
- 前端：埋点实现、SDK 维护、数据质量。
- 数据团队：数仓、ETL、口径校验。
- QA：埋点测试、对数。
流程嵌入：
- 需求评审加入埋点评审。
- 代码评审检查埋点变更。
- 上线前埋点验收。
治理工具：
- Schema 校验、对数平台、血缘分析、质量评分。
培训与考核：
- 埋点最佳实践培训。
- 将数据质量纳入团队 OKR。

推动策略：

从核心指标和痛点入手。
用数据说话，展示治理带来的决策效率提升。
建立数据质量红黑榜。

评分维度：

治理框架（40%）：规范、平台、职责、流程
工具与考核（30%）：Schema、对数、OKR
推动策略（30%）：痛点、数据、红黑榜

常见错误：

数据治理仅由数据团队推动，前端和产品不参与。
规范过于复杂，业务团队抵触。

延伸追问：

如何处理业务为赶进度跳过埋点评审？
如何平衡治理规范与创新速度？

相关题目：

FB-36-CO-A-006 数据治理与元数据
FB-36-SD-R-001 设计前端数据平台

参考资源：

Data Governance Framework

口头回答版：

跨团队数据治理要统一埋点和指标规范、统一平台、明确产品运营前端数据 QA 职责，把埋点评审嵌入需求代码评审和上线验收。用 Schema 校验、对数、血缘工具，培训并纳入 OKR。从核心指标痛点入手，用数据说话。

FB-36-CP-R-002：如何评估前端数据工程的 ROI？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：ROI、数据价值、成本、收益、度量 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请说明如何衡量前端数据工程投入（埋点、平台、分析）带来的业务价值。

参考答案：

收益维度：

业务增长：
- 通过 A/B 实验优化转化率、留存率。
- 用数据发现增长机会和流失点。
效率提升：
- 自助分析减少数据团队重复取数。
- 自动化报表替代人工统计。
风险降低：
- 数据质量监控减少错误决策。
- 合规数据治理降低法律风险。
成本节约：
- 精准营销降低获客成本。
- 发现并下线无用埋点和报表，降低存储和计算。

成本维度：

人力：数据开发、前端 SDK、分析师。
基础设施：存储、计算、消息队列、BI 工具。
维护：埋点迭代、对数、质量修复。

评估方法：

建立基线，对比治理/实验前后的关键指标。
计算具体实验带来的增量收益。
量化自助分析节省的人天。
定期进行成本审计。

评分维度：

收益识别（40%）：增长、效率、风险、成本
成本识别（30%）：人力、基础设施、维护
评估方法（30%）：基线、实验、审计

常见错误：

只算成本不算收益。
把数据工程的收益全部归因到单一项目。

延伸追问：

如何向非技术管理层解释数据治理的长期价值？
数据平台的建设和维护成本如何分摊？

相关题目：

FB-36-CO-B-008 数据驱动决策
FB-36-CP-R-001 跨团队数据治理

参考资源：

Lean Analytics

口头回答版：

评估前端数据工程 ROI 要看业务增长、效率提升、风险降低、成本节约。成本包括人力、基础设施、维护。通过基线对比、实验增量、自助分析人天节省、成本审计来量化。不能只算成本不算收益。

FB-36-SD-R-006：如何设计一个实时数据看板？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：36 前端数据工程标签：实时看板、流处理、可视化、缓存、性能 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个面向业务的实时数据看板，覆盖数据采集、处理、展示和稳定性。

参考答案：

数据流：

埋点/业务事件 -> Kafka -> Flink 聚合 -> 结果写入 Redis/时序数据库/API。
前端通过 WebSocket/SSE 拉取实时聚合结果。

处理层：

按时间窗口聚合（如 1 分钟、5 分钟）。
预计算核心指标，减少前端计算。
对异常值检测和告警。

展示层：

使用 ECharts/AntV 展示 KPI、趋势、漏斗。
支持筛选、下钻、对比历史。
断线重连和最近数据补推。

稳定性：

后端多副本、限流、降级。
前端节流渲染、背压处理。
离线时显示最近缓存数据。

扩展性：

指标配置化，新指标无需改代码。
多业务隔离，权限控制。

补充说明：

在实际落地设计一个实时数据看板时，建议结合实时看板、流处理、可视化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

数据流（30%）：Kafka、Flink、Redis、前端推送
处理与展示（30%）：聚合、图表、交互
稳定性（20%）：限流、降级、缓存
扩展性（20%）：配置化、权限

常见错误：

把原始明细推给前端聚合。
实时看板没有降级方案，后端故障时白屏。

延伸追问：

实时看板和离线报表口径如何统一？
如何保证看板数据低延迟且不重不漏？

相关题目：

FB-36-CO-A-003 前端实时数据处理
FB-34-SD-R-002 设计实时数据大屏

参考资源：

Apache Flink

口头回答版：

实时看板数据流是埋点进 Kafka，Flink 按窗口聚合后写入 Redis，前端用 WebSocket/SSE 拉取。后端预计算指标，前端用 ECharts 展示，支持筛选下钻。要限流降级、断线补推、配置化指标、业务权限。

FB-36-CO-B-009：埋点有哪些类型？各举一个前端例子。

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 前端数据工程标签：埋点、ETL、数据质量、校验、流处理 出现频率：中频 预计回答时长：3-5 分钟

题目描述：埋点有哪些类型？各举一个前端例子。。

参考答案：

点击埋点：按钮点击。
曝光埋点：广告进入可视区。
页面埋点：页面 PV/UV。
自定义事件：加入购物车、提交订单。

补充说明：

在实际落地埋点有哪些类型各举一个前端例子。时，建议结合埋点、ETL、数据质量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

类型覆盖（60%）
例子恰当（40%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

点击埋点：按钮点击。 - 曝光埋点：广告进入可视区。 - 页面埋点：页面 PV/UV。 - 自定义事件：加入购物车、提交订单。

FB-36-CO-B-010：AB 实验为什么要随机分流？

题目描述： AB 实验为什么要随机分流。

参考答案：

随机分流保证对照组和实验组在统计学上可比，排除混杂因素影响，使实验结果具有因果推断效力。

补充说明：

在实际落地 AB 实验为什么要随机分流时，建议结合埋点、ETL、数据质量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

随机性意义（50%）
排除偏差（30%）
统计显著性（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

随机分流保证对照组和实验组在统计学上可比，排除混杂因素影响，使实验结果具有因果推断效力。

FB-36-CO-B-011：什么是北极星指标？

题目描述：什么是北极星指标。

参考答案：

北极星指标是最能反映产品核心价值和长期成功的单一指标，所有团队优化方向都应围绕它展开。

补充说明：

在实际落地北极星指标时，建议结合埋点、ETL、数据质量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

定义（50%）
作用（30%）
举例（20%）

二、进阶题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

北极星指标是最能反映产品核心价值和长期成功的单一指标，所有团队优化方向都应围绕它展开。

FB-36-SD-A-001：如何设计一个科学的 AB 实验？

题型：系统设计题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：埋点、ETL、数据质量、校验、流处理 出现频率：中频 预计回答时长：5-8 分钟

题目描述：如何设计一个科学的 AB 实验。

参考答案：

明确假设和核心指标。
确定样本量和实验时长。
随机分流，保证用户级一致。
设置护栏指标。
运行实验并计算统计显著性。
得出结论并全量或回滚。

补充说明：

在实际落地设计一个科学的 AB 实验时，建议结合埋点、ETL、数据质量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 补充说明：

在实际落地设计一个科学的 AB 实验时，建议结合埋点、ETL、数据质量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

假设与指标（25%）
样本量（20%）
分流（20%）
护栏指标（15%）
决策（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

明确假设和核心指标。 - 确定样本量和实验时长。 - 随机分流，保证用户级一致。 - 运行实验并计算统计显著性。

FB-36-CO-A-007：埋点口径不一致会带来什么问题？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：36 前端数据工程标签：埋点、ETL、数据质量、校验、流处理 出现频率：中频 预计回答时长：5-8 分钟

题目描述：埋点口径不一致会带来什么问题。

参考答案：

不同团队对同一指标理解不同。
数据报表相互矛盾。
决策依据不可靠。
修复成本高，需要重新清洗历史数据。

补充说明：

在实际落地埋点口径不一致会带来什么问题时，建议结合埋点、ETL、数据质量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题描述（50%）
业务影响（30%）
治理成本（20%）

三、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

不同团队对同一指标理解不同。 - 数据报表相互矛盾。 - 决策依据不可靠。 - 修复成本高，需要重新清洗历史数据。

FB-36-CO-B-012：前端数据工程要解决什么问题

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 数据工程标签：数据工程、ETL、数据质量、可视化、前端 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端视角下数据工程涉及的主要问题。

参考答案：

核心思路如下：

数据采集：埋点、日志、用户行为
数据清洗与转换：格式化、补全、去重
数据存储：本地缓存、IndexedDB、服务端仓库
数据传输：批量、压缩、安全
数据消费：图表、报表、分析
数据质量：完整性、准确性、时效性

需要避免的典型误区：

只关注展示不管数据质量
采集所有数据无目的
数据口径不一致

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据采集、数据清洗与转换等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只关注展示不管数据质量
采集所有数据无目的
数据口径不一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据采集；数据清洗与转换；数据存储；数据传输；数据消费；数据质量。同时要避免只关注展示不管数据质量。

FB-36-CO-A-008：ETL 与 ELT 的区别

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：ETL、ELT、数据仓库、转换、加载 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请比较 ETL 和 ELT 的适用场景。

参考答案：

核心思路如下：

ETL：先抽取转换再加载，适合结构化、严格治理
ELT：先加载到仓库再转换，灵活，适合大数据、云仓
前端应用：轻量 ETL 可在浏览器或 BFF 完成
ELT 依赖目标端计算能力
选择：数据量、复杂度、合规要求

需要避免的典型误区：

前端做重型 ETL
混淆两种模式
忽略数据治理

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：ETL、ELT 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端做重型 ETL
混淆两种模式
忽略数据治理

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

ETL；ELT；前端应用；ELT 依赖目标端计算能力；选择。同时要避免前端做重型 ETL。

FB-36-SC-A-001：如何设计前端埋点数据模型

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：埋点、数据模型、事件、属性、规范 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请设计一个标准化的前端埋点事件模型。

参考答案：

核心思路如下：

事件名：模块_页面_动作，如 click_home_banner
公共属性：用户、设备、时间、版本、页面路径
事件属性：与具体动作相关的字段
用户属性：登录态、会员等级
预置事件 vs 自定义事件
版本管理：schema 变更兼容

需要避免的典型误区：

事件名随意无规范
缺少公共属性
属性类型不统一

补充说明：

在实际落地设计前端埋点数据模型时，建议结合埋点、数据模型、事件的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：事件名、公共属性等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

事件名随意无规范
缺少公共属性
属性类型不统一

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

事件名；公共属性；事件属性；用户属性；预置事件 vs 自定义事件；版本管理。同时要避免事件名随意无规范。

FB-36-CO-A-009：什么是数据血缘，前端如何应用

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：数据血缘、溯源、影响分析、ETL、质量 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释数据血缘及其在前端数据工程中的价值。

参考答案：

核心思路如下：

数据血缘描述数据从产生到消费的链路
价值：问题定位、影响分析、合规审计
前端应用：埋点 -> 清洗 -> 指标 -> 报表
记录字段来源和转换规则
变更时评估影响范围

需要避免的典型误区：

数据链路无文档
口径变更不知影响面
血缘只在数据仓库维护

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据血缘描述数据从产生到消费的链路、价值等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

数据链路无文档
口径变更不知影响面
血缘只在数据仓库维护

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据血缘描述数据从产生到消费的链路；价值；前端应用；记录字段来源和转换规则；变更时评估影响范围。同时要避免数据链路无文档。

FB-36-SC-P-001：前端如何做数据清洗与校验

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据清洗、校验、Schema、类型、脏数据 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端在数据采集和消费时的清洗校验策略。

参考答案：

核心思路如下：

Schema 校验：使用 zod/yup/joi 定义数据形状
类型转换：字符串数字、日期解析
缺失值处理：默认值、过滤、标记
异常值检测：范围、枚举、重复
清洗日志：记录丢弃和修正

需要避免的典型误区：

完全信任后端数据
清洗逻辑散落
异常数据静默忽略

补充说明：

在实际落地前端如何做数据清洗与校验时，建议结合数据清洗、校验、Schema 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Schema 校验、类型转换等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

完全信任后端数据
清洗逻辑散落
异常数据静默忽略

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Schema 校验；类型转换；缺失值处理；异常值检测；清洗日志。同时要避免完全信任后端数据。

FB-36-CO-P-006：数据湖、数据仓库、数据库的区别

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据湖、数据仓库、数据库、结构化、非结构化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请比较三种数据存储方式。

参考答案：

核心思路如下：

数据库：面向事务、结构化、行存储
数据仓库：面向分析、主题化、历史数据
数据湖：存储原始结构化和非结构化数据
前端直接接触的通常是数仓聚合后的结果
现代架构：湖仓一体

需要避免的典型误区：

把数据库当数仓用
数据湖变成数据沼泽
前端直连数据湖

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据库、数据仓库等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把数据库当数仓用
数据湖变成数据沼泽
前端直连数据湖

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据库；数据仓库；数据湖；前端直接接触的通常是数仓聚合后的结果；现代架构。同时要避免把数据库当数仓用。

FB-36-SC-A-002：如何设计前端实时数据看板

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：数据看板、实时、ETL、缓存、可视化 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请设计一个业务数据实时看板的前端数据流程。

参考答案：

核心思路如下：

数据源：业务系统、埋点、日志
采集：埋点 SDK、API 拉取、消息订阅
处理：实时聚合（Flink）、分钟级预计算
存储：时序数据库或缓存
前端：WebSocket/SSE 消费，可视化展示
缓存与降级：近实时数据兜底

需要避免的典型误区：

所有数据实时计算
前端直接聚合大数据
不处理数据延迟

补充说明：

在实际落地设计前端实时数据看板时，建议结合数据看板、实时、ETL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据源、采集等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有数据实时计算
前端直接聚合大数据
不处理数据延迟

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据源；采集；处理；存储；前端；缓存与降级。同时要避免所有数据实时计算。

FB-36-CO-A-010：什么是数据治理，前端如何参与

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：数据治理、口径、质量、安全、合规 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明数据治理的核心内容，前端应承担哪些责任。

参考答案：

核心思路如下：

数据治理：质量、安全、口径、生命周期、合规
前端责任：埋点规范、数据安全、口径对齐
避免前端随意定义业务指标
参与指标和事件模型评审
敏感数据脱敏和权限控制

需要避免的典型误区：

认为数据治理只是数据团队的事
前端指标口径与 BI 不一致
埋点随意导致数据不可用

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据治理、前端责任等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为数据治理只是数据团队的事
前端指标口径与 BI 不一致
埋点随意导致数据不可用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据治理；前端责任；避免前端随意定义业务指标；参与指标和事件模型评审；敏感数据脱敏和权限控制。同时要避免认为数据治理只是数据团队的事。

FB-36-SC-P-002：前端如何处理大数据表格

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：大数据、表格、分页、虚拟化、排序、筛选 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计一个展示百万级数据的表格方案。

参考答案：

核心思路如下：

后端分页/游标，避免前端全量加载
前端虚拟滚动
排序筛选优先由后端处理
聚合统计：后端预计算
导出异步生成文件
大数据下前端只做展示

需要避免的典型误区：

前端加载全部数据
前端做全量排序
一次性导出大数据

补充说明：

在实际落地前端如何处理大数据表格时，建议结合大数据、表格、分页的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：后端分页/游标，避免前端全量加载、前端虚拟滚动等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端加载全部数据
前端做全量排序
一次性导出大数据

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

后端分页/游标，避免前端全量加载；前端虚拟滚动；排序筛选优先由后端处理；聚合统计；导出异步生成文件；大数据下前端只做展示。同时要避免前端加载全部数据。

FB-36-CO-P-007：什么是指标口径与维度

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：指标、口径、维度、OLAP、数据分析 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释数据分析中的指标、口径、维度。

参考答案：

核心思路如下：

指标：衡量业务的数值，如 DAU、GMV
口径：指标的计算规则，如活跃定义、去重方式
维度：观察角度，如时间、地区、渠道
口径不一致导致数据打架
前端展示需明确口径说明

需要避免的典型误区：

不同页面同一指标口径不同
只看数值不看口径
维度过多导致图表混乱

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：指标、口径等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

不同页面同一指标口径不同
只看数值不看口径
维度过多导致图表混乱

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

指标；口径；维度；口径不一致导致数据打架；前端展示需明确口径说明。同时要避免不同页面同一指标口径不同。

FB-36-SC-A-003：如何设计埋点数据的质量校验

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：埋点、质量、校验、监控、事件 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何保证前端埋点数据的完整和准确。

参考答案：

核心思路如下：

Schema 约束：事件名、属性类型、必填项
自动化测试：验证事件触发时机
线上监控：事件量突降/突增告警
采样抽查与人工校验
埋点版本管理与灰度

需要避免的典型误区：

埋点代码上线后不验证
事件名或属性随意改
缺失关键属性无告警

补充说明：

在实际落地设计埋点数据的质量校验时，建议结合埋点、质量、校验的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Schema 约束、自动化测试等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

埋点代码上线后不验证
事件名或属性随意改
缺失关键属性无告警

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Schema 约束；自动化测试；线上监控；采样抽查与人工校验；埋点版本管理与灰度。同时要避免埋点代码上线后不验证。

FB-36-CO-A-011：数据管道中的流处理与批处理

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：流处理、批处理、实时、离线、Flink 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请比较流处理和批处理的特点。

参考答案：

核心思路如下：

批处理：按批次处理历史数据，吞吐高、延迟高
流处理：实时处理每条数据，延迟低
前端看板通常基于流处理或近实时预计算
批处理适合报表、T+1 分析
Lambda/Kappa 架构

需要避免的典型误区：

所有场景都流处理
前端直接消费流数据
忽略数据一致性

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：批处理、流处理等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有场景都流处理
前端直接消费流数据
忽略数据一致性

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

批处理；流处理；前端看板通常基于流处理或近实时预计算；批处理适合报表、T+1 分析；Lambda/Kappa 架构。同时要避免所有场景都流处理。

FB-36-SC-P-003：前端如何做数据导出与下载

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据导出、CSV、Excel、异步、大文件 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计一个大数据量导出功能。

参考答案：

核心思路如下：

小数据：前端直接生成 CSV/Excel 下载
大数据：服务端异步生成，前端轮询或 SSE 通知
流式下载：分块返回，前端展示进度
数据权限校验
文件格式：CSV、Excel、Parquet

需要避免的典型误区：

前端导出百万行数据
无权限校验
大文件阻塞浏览器

补充说明：

在实际落地前端如何做数据导出与下载时，建议结合数据导出、CSV、Excel 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：小数据、大数据等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端导出百万行数据
无权限校验
大文件阻塞浏览器

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

小数据；大数据；流式下载；数据权限校验；文件格式。同时要避免前端导出百万行数据。

FB-36-CO-P-008：什么是数据质量六性

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据质量、完整性、准确性、一致性、及时性 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请说明数据质量的六个维度。

参考答案：

核心思路如下：

完整性：数据是否缺失
准确性：数据是否正确
一致性：不同系统口径是否一致
及时性：数据是否按时产出
唯一性：是否重复
有效性：格式和范围是否合规

需要避免的典型误区：

只看数据量
忽略口径一致性
不及时发现数据问题

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：完整性、准确性等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只看数据量
忽略口径一致性
不及时发现数据问题

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

完整性；准确性；一致性；及时性；唯一性；有效性。同时要避免只看数据量。

FB-36-SC-A-004：如何设计前端数据采集 SDK

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：采集 SDK、埋点、队列、上报、采样 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请设计一个前端数据采集 SDK。

参考答案：

核心思路如下：

事件定义与注册机制
队列：本地缓存，批量上报
上报策略：实时/定时/页面卸载
采样与去重
错误处理与重试
隐私合规：敏感字段过滤

需要避免的典型误区：

所有事件实时上报
队列无上限
不上报公共属性

补充说明：

在实际落地设计前端数据采集 SDK 时，建议结合采集 SDK、埋点、队列的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：事件定义与注册机制、队列等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有事件实时上报
队列无上限
不上报公共属性

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

事件定义与注册机制；队列；上报策略；采样与去重；错误处理与重试；隐私合规。同时要避免所有事件实时上报。

FB-36-CO-A-012：数据仓库的分层模型

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：数据仓库、ODS、DWD、DWS、ADS 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释数据仓库常见的 ODS、DWD、DWS、ADS 分层。

参考答案：

核心思路如下：

ODS：原始数据层
DWD：明细数据层，清洗后
DWS：汇总数据层，按主题聚合
ADS：应用数据层，面向前端/BI
分层好处：复用、治理、口径统一

需要避免的典型误区：

前端直接用 ODS 数据
分层混乱
ADS 口径不一致

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：ODS、DWD 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端直接用 ODS 数据
分层混乱
ADS 口径不一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

ODS；DWD；DWS；ADS；分层好处。同时要避免前端直接用 ODS 数据。

FB-36-SC-P-004：前端如何支持多维分析（OLAP）

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：OLAP、多维分析、透视表、钻取、聚合 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计前端多维分析报表的交互与数据方案。

参考答案：

核心思路如下：

维度选择器：时间、地区、品类
指标选择器：GMV、订单量
透视表或交叉表展示
下钻和上卷交互
后端预计算聚合结果
前端缓存查询条件

需要避免的典型误区：

前端聚合大数据
每次交互全量查询
维度过多导致性能差

补充说明：

在实际落地前端如何支持多维分析（OLAP）时，建议结合 OLAP、多维分析、透视表的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：维度选择器、指标选择器等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端聚合大数据
每次交互全量查询
维度过多导致性能差

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

维度选择器；指标选择器；透视表或交叉表展示；下钻和上卷交互；后端预计算聚合结果；前端缓存查询条件。同时要避免前端聚合大数据。

FB-36-CO-P-009：什么是数据产品化

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据产品、自助分析、BI、指标、平台 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释数据产品化的概念及前端在其中的角色。

参考答案：

核心思路如下：

数据产品化：让用户能自助使用数据
形式：BI 平台、数据看板、分析工具
前端角色：可视化、交互、低代码配置
指标中心：统一定义和管理指标
权限与数据安全

需要避免的典型误区：

把报表当数据产品
指标口径不统一
过度技术化忽略用户

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据产品化、形式等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把报表当数据产品
指标口径不统一
过度技术化忽略用户

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据产品化；形式；前端角色；指标中心；权限与数据安全。同时要避免把报表当数据产品。

FB-36-SC-A-005：如何保障报表数据的实时性

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：报表、实时、缓存、刷新、数据流 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明业务报表如何平衡实时性和性能。

参考答案：

核心思路如下：

区分实时、近实时、离线指标
实时指标用流计算 + 缓存
离线指标预计算
前端设置刷新策略和手动刷新
数据延迟提示

需要避免的典型误区：

所有报表都要求秒级实时
缓存过短导致数据库压力大
不提示数据延迟

补充说明：

在实际落地保障报表数据的实时性时，建议结合报表、实时、缓存的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：区分实时、近实时、离线指标、实时指标用流计算 + 缓存等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有报表都要求秒级实时
缓存过短导致数据库压力大
不提示数据延迟

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

区分实时、近实时、离线指标；实时指标用流计算 + 缓存；离线指标预计算；前端设置刷新策略和手动刷新；数据延迟提示。同时要避免所有报表都要求秒级实时。

FB-36-CO-B-013：前端常见的数据格式与序列化

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 数据工程标签：JSON、CSV、Parquet、Protocol Buffers、序列化 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请比较前端常用数据格式。

参考答案：

核心思路如下：

JSON：通用、可读、体积较大
CSV：表格数据、轻量
Parquet：列式存储，适合大数据，浏览器解析需库
Protobuf：二进制、体积小、需 schema
前端展示多用 JSON，传输大数据可用 Protobuf

需要避免的典型误区：

所有场景都用 JSON
大数据用 JSON 传输
不压缩

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：JSON、CSV 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有场景都用 JSON
大数据用 JSON 传输
不压缩

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

JSON；CSV；Parquet；Protobuf；前端展示多用 JSON，传输大数据可用 Protobuf。同时要避免所有场景都用 JSON。

FB-36-SC-P-005：如何设计数据权限在前端的体现

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据权限、报表、行级、列级、角色 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计报表系统的数据权限控制。

参考答案：

核心思路如下：

行级权限：用户只能看所属区域/部门数据
列级权限：敏感字段隐藏
权限由服务端控制，前端仅展示
前端根据权限动态渲染菜单和字段
审计日志记录数据访问

需要避免的典型误区：

前端隐藏字段就以为安全
权限规则散落在前端
服务端无权限校验

补充说明：

在实际落地设计数据权限在前端的体现时，建议结合数据权限、报表、行级的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：行级权限、列级权限等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端隐藏字段就以为安全
权限规则散落在前端
服务端无权限校验

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

行级权限；列级权限；权限由服务端控制，前端仅展示；前端根据权限动态渲染菜单和字段；审计日志记录数据访问。同时要避免前端隐藏字段就以为安全。

FB-36-CO-A-013：什么是数据湖仓一体

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：湖仓一体、数据湖、数据仓库、分析 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请解释湖仓一体的概念。

参考答案：

核心思路如下：

结合数据湖的灵活性和数据仓库的治理能力
统一存储，支持结构化和非结构化分析
降低数据孤岛
支持 AI/ML 和 BI 统一平台
前端消费层获取统一视图

需要避免的典型误区：

把概念当产品
前端直接操作湖仓
治理跟不上

补充说明：

在实际落地数据湖仓一体时，建议结合湖仓一体、数据湖、数据仓库的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：结合数据湖的灵活性和数据仓库的治理能力、统一存储，支持结构化和非结构化分析等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把概念当产品
前端直接操作湖仓
治理跟不上

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

结合数据湖的灵活性和数据仓库的治理能力；统一存储，支持结构化和非结构化分析；降低数据孤岛；支持 AI/ML 和 BI 统一平台；前端消费层获取统一视图。同时要避免把概念当产品。

FB-36-SC-R-001：设计一个前端自助分析平台

题型：场景设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：36 数据工程标签：自助分析、BI、拖拽、指标、可视化 出现频率：低频 预计回答时长：15-30 分钟

题目描述：请设计一个让业务人员能拖拽生成报表的平台。

参考答案：

核心思路如下：

数据集管理：选择数据源、维度、指标
拖拽画布：图表、过滤器、布局
查询生成：将配置转为 SQL/查询请求
权限：数据行级/列级控制
分享与调度：导出、定时邮件
性能：查询缓存与限流

需要避免的典型误区：

所有查询实时执行
无权限控制
过度灵活导致性能问题

补充说明：

在实际落地设计一个前端自助分析平台时，建议结合自助分析、BI、拖拽的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据集管理、拖拽画布等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有查询实时执行
无权限控制
过度灵活导致性能问题

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据集管理；拖拽画布；查询生成；权限；分享与调度；性能。同时要避免所有查询实时执行。

FB-36-CO-P-010：数据工程中的隐私与合规

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：隐私、合规、GDPR、数据脱敏、保留 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端数据工程中的隐私合规要求。

参考答案：

核心思路如下：

不上传 PII 明文
用户同意与授权
数据最小化原则
保留期限与删除
可审计与可追溯

需要避免的典型误区：

埋点采集敏感信息
无用户授权
数据保留无限期

补充说明：

在实际落地数据工程中的隐私与合规时，建议结合隐私、合规、GDPR 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：不上传 PII 明文、用户同意与授权等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

埋点采集敏感信息
无用户授权
数据保留无限期

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

不上传 PII 明文；用户同意与授权；数据最小化原则；保留期限与删除；可审计与可追溯。同时要避免埋点采集敏感信息。

FB-36-PE-A-002：前端大数据可视化的性能策略

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：大数据、可视化、聚合、采样、性能 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端展示大数据图表时的性能策略。

参考答案：

核心思路如下：

后端预聚合，前端展示汇总
按缩放级别采样
前端 Web Worker 处理数据
使用 Canvas/WebGL
分页/虚拟化展示明细

需要避免的典型误区：

前端接收原始明细
不做聚合
SVG 渲染百万点

补充说明：

在实际落地前端大数据可视化的性能策略时，建议结合大数据、可视化、聚合的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：后端预聚合，前端展示汇总、按缩放级别采样等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端接收原始明细
不做聚合
SVG 渲染百万点

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

后端预聚合，前端展示汇总；按缩放级别采样；前端 Web Worker 处理数据；使用 Canvas/WebGL；分页/虚拟化展示明细。同时要避免前端接收原始明细。

FB-36-SC-A-006：如何做埋点事件的归因分析

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：归因、埋点、漏斗、转化、分析 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计前端埋点支持用户行为归因分析。

参考答案：

核心思路如下：

事件携带 session_id、user_id、trace_id
关键路径埋点：曝光、点击、转化
归因窗口期定义
支持首次点击、末次点击、线性归因
与后端订单数据关联

需要避免的典型误区：

只有点击无曝光
归因窗口过长
前后端数据无法关联

补充说明：

在实际落地做埋点事件的归因分析时，建议结合归因、埋点、漏斗的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：事件携带 session_id、user_id、trace_id、关键路径埋点等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只有点击无曝光
归因窗口过长
前后端数据无法关联

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

事件携带 session_id、user_id、trace_id；关键路径埋点；归因窗口期定义；支持首次点击、末次点击、线性归因；与后端订单数据关联。同时要避免只有点击无曝光。

FB-36-CO-A-014：什么是数据目录

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：数据目录、元数据、发现、治理、资产 出现频率：低频 预计回答时长：3-5 分钟

题目描述：请解释数据目录的作用。

参考答案：

核心思路如下：

数据目录是数据资产的统一索引
记录表、字段、口径、Owner、血缘
帮助用户发现和理解数据
支持权限和合规
前端可消费数据目录做指标说明

需要避免的典型误区：

数据目录与实际数据脱节
无人维护
只给技术人员用

补充说明：

在实际落地数据目录时，建议结合数据目录、元数据、发现的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据目录是数据资产的统一索引、记录表、字段、口径、Owner、血缘等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

数据目录与实际数据脱节
无人维护
只给技术人员用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据目录是数据资产的统一索引；记录表、字段、口径、Owner、血缘；帮助用户发现和理解数据；支持权限和合规；前端可消费数据目录做指标说明。同时要避免数据目录与实际数据脱节。

FB-36-SC-P-006：前端数据异常如何自动发现

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：36 数据工程标签：数据异常、监控、告警、波动、质量 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计前端数据异常检测机制。

参考答案：

核心思路如下：

监控核心指标波动
同比环比阈值告警
异常检测算法：3-sigma、孤立森林
事件量突降/突增告警
归因下钻：按维度拆分定位

需要避免的典型误区：

阈值过严告警疲劳
只看总量不看维度
发现异常不处理

补充说明：

在实际落地前端数据异常如何自动发现时，建议结合数据异常、监控、告警的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：监控核心指标波动、同比环比阈值告警等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

阈值过严告警疲劳
只看总量不看维度
发现异常不处理

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

监控核心指标波动；同比环比阈值告警；异常检测算法；事件量突降/突增告警；归因下钻。同时要避免阈值过严告警疲劳。

FB-36-CO-B-014：什么是数据管道

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：36 数据工程标签：数据管道、ETL、数据流、采集、处理 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释数据管道的概念和作用。

参考答案：

核心思路如下：

数据管道是把数据从源移动到目的地的流程
包含采集、处理、转换、加载
前端埋点数据需要管道进入仓库
可批处理或流处理
保证数据质量和可追溯

需要避免的典型误区：

没有数据管道靠手动导出
管道无监控
数据口径在管道中丢失

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据管道是把数据从源移动到目的地的流程、包含采集、处理、转换、加载等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

没有数据管道靠手动导出
管道无监控
数据口径在管道中丢失

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据管道是把数据从源移动到目的地的流程；包含采集、处理、转换、加载；前端埋点数据需要管道进入仓库；可批处理或流处理；保证数据质量和可追溯。同时要避免没有数据管道靠手动导出。

FB-36-SC-A-007：前端埋点数据采集设计

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：36 数据工程标签：埋点、采集、SDK、队列、上报 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计前端埋点数据的采集和上报流程。

参考答案：

核心思路如下：

事件触发后写入本地队列
批量压缩后上报
页面卸载前 flush
失败重试与本地持久化
采样和隐私脱敏

需要避免的典型误区：

实时单条上报
队列无上限
页面关闭丢失数据

补充说明：

在实际落地前端埋点数据采集设计时，建议结合埋点、采集、SDK 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：事件触发后写入本地队列、批量压缩后上报等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

实时单条上报
队列无上限
页面关闭丢失数据

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

事件触发后写入本地队列；批量压缩后上报；页面卸载前 flush；失败重试与本地持久化；采样和隐私脱敏。同时要避免实时单条上报。

前端数据工程面试题 ​

目录 ​

基础题（8 道） ​

FB-36-CO-B-001：前端埋点与数据采集有哪些方式？ ​

FB-36-CO-B-002：数据清洗与格式化在前端数据工程中的作用是什么？ ​

FB-36-CO-B-003：前端 ETL/ELT 是什么？有什么区别？ ​

FB-36-CO-B-004：数据管道与消息队列在前端数据工程中的作用是什么？ ​

FB-36-CO-B-005：实时处理与批量处理有什么区别？ ​

FB-36-CO-B-006：数据质量校验有哪些方法？ ​

FB-36-CO-B-007：数据隐私与匿名化在前端如何处理？ ​

FB-36-CO-B-008：数据驱动决策在前端团队如何落地？ ​

进阶题（8 道） ​

FB-36-CO-A-001：埋点方案如何选型？ ​

FB-36-CO-A-002：用户行为分析有哪些常用模型？ ​

FB-36-CD-A-001：如何设计一个前端 A/B 实验？ ​

FB-36-CO-A-003：前端实时数据处理有哪些方式？ ​

FB-36-CO-A-004：数据可视化报表如何设计？ ​

FB-36-PE-A-001：前端如何处理大数据量？ ​

FB-36-CO-A-005：数据湖/数仓概念如何与前端数据工程衔接？ ​

FB-36-CO-A-006：数据治理与元数据管理在前端如何体现？ ​

深入题（7 道） ​

FB-36-CD-P-001：如何设计一个前端埋点 SDK？ ​

FB-36-CO-P-001：如何保证埋点数据的准确性与完整性？ ​

FB-36-CO-P-002：时序数据与漏斗分析在前端如何实现？ ​

FB-36-CO-P-003：用户画像与标签体系如何设计？ ​

FB-36-SE-P-001：前端数据隐私合规有哪些深度措施？ ​

FB-36-CO-P-004：实时与离线数据口径不一致怎么办？ ​

FB-36-CO-P-005：数据血缘与影响分析在前端数据工程中的作用是什么？ ​

架构题（43 道） ​

FB-36-SD-R-001：如何设计一个前端数据平台？ ​

FB-36-SD-R-002：如何设计一个埋点与采集系统？ ​

FB-36-SD-R-003：如何设计一个用户行为分析系统？ ​

FB-36-SD-R-004：如何设计一个 A/B 实验平台？ ​

FB-36-SD-R-005：如何设计一个数据质量监控体系？ ​

FB-36-CP-R-001：跨团队数据治理如何推进？ ​

FB-36-CP-R-002：如何评估前端数据工程的 ROI？ ​

FB-36-SD-R-006：如何设计一个实时数据看板？ ​

FB-36-CO-B-009：埋点有哪些类型？各举一个前端例子。 ​

FB-36-CO-B-010：AB 实验为什么要随机分流？ ​

FB-36-CO-B-011：什么是北极星指标？ ​

二、进阶题 ​

FB-36-SD-A-001：如何设计一个科学的 AB 实验？ ​

FB-36-CO-A-007：埋点口径不一致会带来什么问题？ ​

三、高级题 ​

FB-36-CO-B-012：前端数据工程要解决什么问题 ​

FB-36-CO-A-008：ETL 与 ELT 的区别 ​

FB-36-SC-A-001：如何设计前端埋点数据模型 ​

FB-36-CO-A-009：什么是数据血缘，前端如何应用 ​

FB-36-SC-P-001：前端如何做数据清洗与校验 ​

FB-36-CO-P-006：数据湖、数据仓库、数据库的区别 ​

FB-36-SC-A-002：如何设计前端实时数据看板 ​

FB-36-CO-A-010：什么是数据治理，前端如何参与 ​

FB-36-SC-P-002：前端如何处理大数据表格 ​

FB-36-CO-P-007：什么是指标口径与维度 ​

FB-36-SC-A-003：如何设计埋点数据的质量校验 ​

FB-36-CO-A-011：数据管道中的流处理与批处理 ​

FB-36-SC-P-003：前端如何做数据导出与下载 ​

FB-36-CO-P-008：什么是数据质量六性 ​

FB-36-SC-A-004：如何设计前端数据采集 SDK ​

FB-36-CO-A-012：数据仓库的分层模型 ​

FB-36-SC-P-004：前端如何支持多维分析（OLAP） ​

FB-36-CO-P-009：什么是数据产品化 ​

FB-36-SC-A-005：如何保障报表数据的实时性 ​

FB-36-CO-B-013：前端常见的数据格式与序列化 ​

FB-36-SC-P-005：如何设计数据权限在前端的体现 ​

FB-36-CO-A-013：什么是数据湖仓一体 ​

FB-36-SC-R-001：设计一个前端自助分析平台 ​

FB-36-CO-P-010：数据工程中的隐私与合规 ​

FB-36-PE-A-002：前端大数据可视化的性能策略 ​

FB-36-SC-A-006：如何做埋点事件的归因分析 ​

FB-36-CO-A-014：什么是数据目录 ​

FB-36-SC-P-006：前端数据异常如何自动发现 ​

FB-36-CO-B-014：什么是数据管道 ​

FB-36-SC-A-007：前端埋点数据采集设计 ​

前端数据工程面试题

目录

基础题（8 道）

FB-36-CO-B-001：前端埋点与数据采集有哪些方式？

FB-36-CO-B-002：数据清洗与格式化在前端数据工程中的作用是什么？

FB-36-CO-B-003：前端 ETL/ELT 是什么？有什么区别？

FB-36-CO-B-004：数据管道与消息队列在前端数据工程中的作用是什么？

FB-36-CO-B-005：实时处理与批量处理有什么区别？

FB-36-CO-B-006：数据质量校验有哪些方法？

FB-36-CO-B-007：数据隐私与匿名化在前端如何处理？

FB-36-CO-B-008：数据驱动决策在前端团队如何落地？

进阶题（8 道）

FB-36-CO-A-001：埋点方案如何选型？

FB-36-CO-A-002：用户行为分析有哪些常用模型？

FB-36-CD-A-001：如何设计一个前端 A/B 实验？

FB-36-CO-A-003：前端实时数据处理有哪些方式？

FB-36-CO-A-004：数据可视化报表如何设计？

FB-36-PE-A-001：前端如何处理大数据量？

FB-36-CO-A-005：数据湖/数仓概念如何与前端数据工程衔接？

FB-36-CO-A-006：数据治理与元数据管理在前端如何体现？

深入题（7 道）

FB-36-CD-P-001：如何设计一个前端埋点 SDK？

FB-36-CO-P-001：如何保证埋点数据的准确性与完整性？

FB-36-CO-P-002：时序数据与漏斗分析在前端如何实现？

FB-36-CO-P-003：用户画像与标签体系如何设计？

FB-36-SE-P-001：前端数据隐私合规有哪些深度措施？

FB-36-CO-P-004：实时与离线数据口径不一致怎么办？

FB-36-CO-P-005：数据血缘与影响分析在前端数据工程中的作用是什么？

架构题（43 道）

FB-36-SD-R-001：如何设计一个前端数据平台？

FB-36-SD-R-002：如何设计一个埋点与采集系统？

FB-36-SD-R-003：如何设计一个用户行为分析系统？

FB-36-SD-R-004：如何设计一个 A/B 实验平台？

FB-36-SD-R-005：如何设计一个数据质量监控体系？

FB-36-CP-R-001：跨团队数据治理如何推进？

FB-36-CP-R-002：如何评估前端数据工程的 ROI？

FB-36-SD-R-006：如何设计一个实时数据看板？

FB-36-CO-B-009：埋点有哪些类型？各举一个前端例子。

FB-36-CO-B-010：AB 实验为什么要随机分流？

FB-36-CO-B-011：什么是北极星指标？

二、进阶题

FB-36-SD-A-001：如何设计一个科学的 AB 实验？

FB-36-CO-A-007：埋点口径不一致会带来什么问题？

三、高级题

FB-36-CO-B-012：前端数据工程要解决什么问题

FB-36-CO-A-008：ETL 与 ELT 的区别

FB-36-SC-A-001：如何设计前端埋点数据模型

FB-36-CO-A-009：什么是数据血缘，前端如何应用

FB-36-SC-P-001：前端如何做数据清洗与校验

FB-36-CO-P-006：数据湖、数据仓库、数据库的区别

FB-36-SC-A-002：如何设计前端实时数据看板

FB-36-CO-A-010：什么是数据治理，前端如何参与

FB-36-SC-P-002：前端如何处理大数据表格

FB-36-CO-P-007：什么是指标口径与维度

FB-36-SC-A-003：如何设计埋点数据的质量校验

FB-36-CO-A-011：数据管道中的流处理与批处理

FB-36-SC-P-003：前端如何做数据导出与下载

FB-36-CO-P-008：什么是数据质量六性

FB-36-SC-A-004：如何设计前端数据采集 SDK

FB-36-CO-A-012：数据仓库的分层模型

FB-36-SC-P-004：前端如何支持多维分析（OLAP）

FB-36-CO-P-009：什么是数据产品化

FB-36-SC-A-005：如何保障报表数据的实时性

FB-36-CO-B-013：前端常见的数据格式与序列化

FB-36-SC-P-005：如何设计数据权限在前端的体现

FB-36-CO-A-013：什么是数据湖仓一体

FB-36-SC-R-001：设计一个前端自助分析平台

FB-36-CO-P-010：数据工程中的隐私与合规

FB-36-PE-A-002：前端大数据可视化的性能策略

FB-36-SC-A-006：如何做埋点事件的归因分析

FB-36-CO-A-014：什么是数据目录

FB-36-SC-P-006：前端数据异常如何自动发现

FB-36-CO-B-014：什么是数据管道

FB-36-SC-A-007：前端埋点数据采集设计