数据开发工程师面试题及答案.docxVIP

数据开发工程师面试题及答案

一、基础技能题（考察SQL与数据基础）

问题：工作中遇到表内重复数据（如同一用户同一时间的重复行为记录），你会怎么处理？不同去重方式的适用场景是什么？

答案：首先得先明确“重复”的定义——是全字段重复还是核心字段（如user_id、action_time、event_id）重复。

若全字段重复：用DISTINCT或GROUPBY所有字段去重，适合小表或临时查询，比如取某天的unique行为记录做快速统计；但大数据量（千万级以上）不推荐DISTINCT，会触发全表扫描，效率低。

若核心字段重复（其他字段如日志id不同）：用开窗函数ROW_NUMBER()OVER(PARTITIONBY核心字段ORDERBY时间戳DESC)，给重复数据标序号，再取序号=1的记录（保留必威体育精装版一条），适合需要保留关键字段必威体育精装版状态的场景，比如用户必威体育精装版的会员等级、必威体育精装版的订单状态，而且能通过ORDERBY控制保留哪条，比DISTINCT灵活。

另外，还要考虑是否需要先定位重复原因：是上游数据重复写入还是采集bug？如果是常态化问题，会在ETL的清洗步骤里固定加去重逻辑，而不是每次查询都处理。

问题：左连接（LEFTJOIN）时，右表有多个匹配结果导致左表数据被“撑大”，怎么解决？

答案：这种情况常见于“一对多”关联，比如左表是订单表（1条订单），右表是订单明细（多条商品记录），关联后订单数据会被拆成多条。

先聚合右表再关联：如果只需要右表的汇总数据（如订单总金额、商品总数），先对右表按关联键（如order_id）做GROUPBY聚合，再和左表关联，避免数据膨胀；

用开窗函数过滤右表：如果需要右表的单条明细（如第一条商品记录），对右表用ROW_NUMBER()OVER(PARTITIONBY关联键ORDERBY明细排序字段)，取序号=1的记录，再和左表关联；

比如实际业务中，“订单表关联用户表+订单明细表”统计用户的订单数，若直接三表联查，订单数会被明细条数冲错，必须先聚合明细表再关联。

二、核心能力题（考察ETL与大数据框架）

问题：你用Hive/Spark做ETL时，遇到过数据倾斜吗？怎么定位和解决？

答案：肯定遇到过，比如统计“各省份用户下单量”，某省份（如广东）用户量占比30%，会导致处理该省份的Task卡住，其他Task很快跑完。

定位方法：看SparkUI（或Hive的任务日志），查看各Task的处理数据量和运行时间，若某Task处理数据量是其他Task的10倍以上，且运行时间远超平均，就是倾斜；再看SQL的GROUPBY、JOIN的关联键，大概率是关联键分布不均。

解决方法：

①小表广播：如果是JOIN倾斜，且其中一张表是小表（如100MB以内），用/*+BROADCAST(小表)*/hint，让小表广播到所有Executor，避免Shuffle；

②拆分倾斜键：如果是GROUPBY倾斜，把倾斜键（如广东）单独拎出来处理，其他键正常处理，最后合并结果；比如(SELECT省份,count(1)FROM表WHERE省份!=广东GROUPBY省份)UNIONALL(SELECT广东,count(1)FROM表WHERE省份=广东)；

③加盐打散：如果是大表JOIN大表倾斜，对倾斜的关联键加随机后缀（如给广东的user_id加_1到_10），右表也做同样处理，先关联后再去掉后缀，把倾斜的Task拆成多个小Task。

问题：怎么设计一个数据同步任务，把MySQL的订单表实时同步到Hive？需要考虑哪些问题？

答案：常用的方案是“CDC（变更数据捕获）+消息队列+计算引擎”，具体步骤：

同步工具选择：用Debezium（捕获MySQL的binlog）把订单表的新增/更新/删除操作实时推到Kafka，再用SparkStreaming/Flink消费Kafka数据，写入Hive（分区表，按天分区）；

要考虑的问题：

①数据一致性：binlog要开启row模式，确保能捕获到每一行的变更，避免statement模式下的SQL解析不全；同步过程中要记录偏移量（如Kafka的offset），万一任务挂了，重启能从断点续跑，不丢数据；

②延迟控制：如果业务需要准实时（如5分钟内），Kafka的topic分区数要和Spark/Flink的并行度匹配，避免消费能力不足；Hive表用ORC格式，写入时开启压缩，减少IO耗时；

③数据校验