数据工程师

交代规模语境：日增数据量（TB/GB 级）、表数量、任务数、下游消费方（报表/特征/推荐）。讲架构分层：采集（CDC/日志/埋点）、传输（Kafka）、存储（数仓分层 ODS/DWD/DWS/ADS）、调度（依赖管理、基线）、质量监控。SLA：核心表就绪时间承诺与达成率。数据工程的资深度藏在细节里：分区策略、幂等回溯、迟到数据处理，准备好被逐层追问。

分层的本质是成本与复用的管理：ODS 原样落底（保留原始证据、可回溯）；DWD 明细层做清洗、维度退化、统一口径（一次清洗多处复用，避免烟囱式重复加工）；DWS 轻度汇总（常用维度组合预计算，用存储换时间）；ADS 面向应用（报表/接口的直接数据源）。边界判据：口径统一在 DWD 完成、跨业务复用沉淀在 DWS、应用特殊逻辑不下沉。反例警示：所有逻辑堆 ADS 导致口径漂移与重复开发。回答时结合一个真实主题域建模例子。

Lambda：批（准确、高延迟）与流（实时、可能不准）双链路，逻辑两套代码维护成本高；Kappa：只保留流链路，重算靠重放，架构简单但对乱序/迟到与回溯历史的要求高。流批一体的现代解法：统一计算引擎（Flink/Spark 同时覆盖）+统一存储（湖仓 Iceberg/Paimon），一套 SQL 语义两种执行模式，口径天然一致。选择依据：实时性需求、数据修正频率、团队能力。展示「架构选择是约束下的权衡」而非背概念。

体系：事前（任务级校验规则：行数波动、主键唯一、枚举值域、空值率）、事中（失败重试、阻断下游扩散——依赖调度把异常截断在当层）、事后（对账监控、告警值班）。事故案例按 STAR：现象（报表数字异常被业务质疑）→定位（上游埋点变更导致字段缺失，校验规则没覆盖）→止损（修数、重跑、通知下游）→改进（加规则、上游变更通知机制）。数据事故的教训永远落在「更早发现+更小扩散面」。

一致性：binlog 位点管理（offset 持久化、重启续传）、事务边界保留（不把一个事务拆散消费）、乱序处理（分区键按主键 hash 保序）。幂等：数仓侧用 Replacing MergeTree / merge-on-read 表引擎或 upsert 语义（按主键+版本合并），重放不产生重复。迟到与回溯：分区覆盖写（整分区重写）、全量+增量衔接（快照对齐 binlog 位点）。加分：谈 Flink CDC 的 exactly-once 语义与 checkpoint 机制的关系。