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

大数据工程师实战面试题及答案

1.HDFS实操题：生产环境中遇到HDFS块丢失，你会怎么处理？

答案：首先用hdfsfsck/命令定位丢失块的文件路径，从NameNode日志（默认在$HADOOP_HOME/logs）里看是副本未创建还是DataNode宕机导致。

如果是DataNode宕机，先检查该节点网络和磁盘状态，重启DataNode服务后，NameNode会自动触发副本复制；若节点无法恢复，就用hdfsdfs-setrep-w3/path/to/file手动增加副本（3是默认副本数，按实际配置改）。

如果是副本数配置不足，直接修改hdfs-site.xml里的dfs.replication，再执行上述手动复制命令。处理完后一定要再用fsck校验，同时把块丢失告警加到监控（比如Prometheus+Grafana）里，避免重复踩坑。

2.Spark优化题：Spark作业Shuffle阶段耗时过长，你会从哪些角度优化？

答案：先看SparkUI的ShuffleRead/Write数据量，再针对性调优：

调整分区数：默认spark.shuffle.partitions=200，如果是TB级数据，改成总数据量/128MB（比如10TB数据设8000），避免单分区数据过大；

数据预处理：Shuffle前用filter过滤无用数据，用coalesce合并小文件，减少Shuffle数据量；

序列化：把默认的Java序列化改成Kryo，在代码里加conf.set(spark.serializer,org.apache.spark.serializer.KryoSerializer)，能减少对象序列化后的大小；

内存配置：如果报OOM，适当提高spark.executor.memory，同时把spark.shuffle.memoryFraction从0.2调到0.4（别太高，留内存给计算）；

避免Shuffle操作：能用broadcastjoin代替普通join就用（小表100MB时），比如df1.join(broadcast(df2),key)，减少数据传输。

3.数据同步题：用Sqoop从MySQL导数据到Hive时，出现数据不一致怎么解决？

答案：先查不一致的原因，常见两种情况：

增量同步漏数据：Sqoop默认全量导，要是MySQL表有新增数据，得用--incrementalappend+--check-columnid（id是自增主键），下次导的时候只导id大于上次最大值的数据，还得在脚本里记录上次的最大值（比如存到HDFS或本地文件）；

导数据时MySQL表有更新：用--incrementallastmodified，指定--check-columnupdate_time（表得有更新时间字段），同时加--merge-keyid，把Hive里旧数据和新数据合并，避免重复；

最后一定要加校验步骤：导完后用selectcount(*)fromhive_table和MySQL表对比，再抽100条关键字段（比如订单号、金额）两边比对，不一致就重新导。

4.数据仓库题：设计数据仓库时，怎么选星型模型还是雪花模型？举个实际例子

答案：核心看业务查询效率和数据冗余的平衡：

星型模型适合查询频繁、维度层级少的场景，比如电商的“订单分析”：事实表是订单表（订单id、用户id、商品id、金额、时间），维度表直接挂用户表（用户id、姓名、地区）、商品表（商品id、名称、品类）、时间表，维度表不关联其他维度，查询时join少，速度快，但会有少量冗余（比如同一地区的用户重复存地区名）；

雪花模型适合维度层级多、想减少冗余的场景，比如“商品销售分析”：如果商品维度有“品类-子品类-品牌-商品”四层，星型模型会在商品表里重复存品类、子品类名，雪花模型就把品类、子品类拆成单独维度表，商品表只存子品类id，虽然查询时多join一次，但能省存储空间。实际工作中星型用得更多，因为业务更在意查询速度。

5.故障排查题：YARN上的Spark任务突然挂掉，日志没明显错误，怎么排查？

答案：按这个步骤查：

先看YARN的ResourceManager日志（$YARN_HOME/logs/yarn-*-resourcemanager-*.log），看是不是任务申请的资源超过队列上限，比如队列总内存100G，任务申请了120G，会被直接kill，这时要调小spark.executor.instances或executor.memory