数据工程师面试题及答案.docx

数据工程师面试题及答案

一、基础概念与数据建模（考察落地认知）

问题：数据仓库为什么要分ODS、DWD、DWS层？实际项目里你怎么设计各层的表？

答案：分层主要是为了“解耦”和“复用”——ODS层存原始数据，避免源系统变动影响下游；DWD层做清洗整合，给业务方提供“干净的明细数据”；DWS层做聚合，支撑快速查询。

举个电商项目的例子：ODS层直接同步MySQL的订单表，字段和源库一致，甚至保留删除的无效订单（用is_delete标记）；DWD层会过滤掉is_delete=1的记录，补全用户手机号脱敏、关联省份字典表补全“省份名”（源表只有省份编码），按“日期+用户ID”分区；DWS层就做“各省份日销售额”聚合，按“日期+省份”分区，后续报表直接查这层，不用每次扫明细。

问题：星型模型和雪花模型怎么选？你之前项目里用的哪种，为什么？

答案：核心看“查询效率”和“维护成本”。星型模型维度表不关联，查的时候join少，速度快，但维度表会有冗余（比如省份表和城市表合并成“地域维度表”，字段重复）；雪花模型维度表会多层关联（比如城市表关联省份表），冗余少但join多，查起来慢。

我们之前做零售报表，选的星型模型——因为业务方要实时看“各门店各品类销量”，查询频率高，宁可维度表多存点数据，也得保证报表点开不超过3秒。如果是后台分析类、查询频率低的场景，雪花模型更省存储。

二、ETL开发与优化（考察实操能力）

问题：增量抽取数据常用什么方式？有什么坑？怎么解决？

答案：常用三种：时间戳、日志同步（比如Binlog）、CDC工具（比如Debezium）。

坑太多了：比如用时间戳抽，源表有“同一时间戳的多条数据”，第一次漏抽一条，下次就永远补不上；还有CDC同步，遇到源表“改主键”，同步工具会把旧主键数据当删除、新主键当新增，导致数据重复。

我们之前解决时间戳问题的办法是：加“主键+时间戳”双重条件，比如wherecreate_time=2024-05-01andid10000（上次最大id是10000）；CDC改主键的问题，是在目标表加“历史主键”字段，同步时记录旧主键，后续用“业务唯一键”（比如订单号）去重。

问题：ETL跑批失败了，怎么排查？举个你遇到过的例子。

答案：先看“失败日志”，再定位“失败环节”——是抽取、清洗还是加载？

之前遇到过一次：Hive的DWD表跑批后，数据量比前一天少了30%。第一步看抽取日志，发现Sqoop从MySQL抽数据时，有个分区的连接超时了，只抽了一半；第二步查MySQL源表，那个分区的数据没问题；第三步改Sqoop参数，把--fetch-size从1000改成500（减少单次拉取数据量），再加--retries3（失败重试），重新跑批就好了。

三、分布式框架（考察工具实战）

问题：Spark作业跑慢，你怎么调优？说一个你实际调优过的案例。

答案：先看SparkUI，重点看“Stage里的Task耗时”——如果大部分Task快，少数Task特别慢，大概率是数据倾斜；如果所有Task都慢，可能是资源不够或Shuffle太多。

之前有个用户行为分析的作业，一个Stage跑了40分钟。看UI发现有个Task处理了1.2GB数据，其他Task只处理200MB，是join的时候数据倾斜了。原因是小表（用户标签表，100MB）没广播，导致大表（用户行为表，100GB）做了Shuffle。后来加了broadcast()函数，把小表广播到Executor，作业直接降到8分钟。

问题：用Flink做实时同步，怎么保证“Exactly-Once”语义？实际配置时要注意什么？

答案：核心是“三要素”：数据源支持重放（比如Kafka的offset可回溯）、Flink状态持久化（用RocksDB）、Sink端支持幂等或事务。

之前做实时订单同步，Sink到HBase，配置时踩过坑：一开始没开事务，Flink重启后重复写了数据。后来改成“两阶段提交”——先把数据写到HBase的预写日志（WAL），Flinkcheckpoint成功后，再确认提交；另外把HBase的RowKey设为“订单号”（唯一），就算重复写，后写的也会覆盖前写的，保证幂等。

四、数据质量与监控（考察责任意识）

问题：怎么保证数据“不丢不重”？比如从Kafka消费数据写入Hive，可能出什么问题？

答案：重点在“链路监控”和“幂等设计”。

可能出的问题：Kaf