大数据常见面试题及答案（实战版）.docx

大数据常见面试题及答案（实战版）

一、Hadoop生态基础

问：NameNode和DataNode的核心作用，以及NameNode如何避免单点故障？

答：NameNode相当于“文件目录管理员”，只存元数据（文件名、路径、块分布），不存实际数据；DataNode是“数据存储节点”，负责存具体数据块（默认128MB），并定期向NameNode汇报心跳。

单点故障靠HA（高可用）解决：部署两个NameNode（Active+Standby），用JournalNode集群同步元数据日志（edits文件），当Active挂了，ZooKeeper会触发Failover，Standby无缝切换成Active，实际项目里还会配Fencing防止“脑裂”。

问：MapReduce的Shuffle过程是怎样的？实际优化时会注意哪些点？

答：Shuffle是“从Map输出到Reduce输入的中间过程”，分三步：

①Map端：输出先写环形缓冲区（默认100MB，80%时溢写），溢写前会按Key排序、分区；

②溢写文件合并：多个溢写文件合并成大文件，期间会做排序和Combiner（预聚合，减少数据量）；

③Reduce端：拉取（Fetch）属于自己分区的数据，再合并、排序，最后给Reduce处理。

优化点：调大环形缓冲区（减少溢写次数）、用Combiner（比如统计PV时先在Map端聚合）、设置合理的Reduce数（一般是集群CPU核数的1.5-2倍，避免太少导致数据倾斜，太多浪费资源）。

二、Spark核心与实操

问：RDD、DataFrame、DataSet的区别，实际项目中怎么选？

答：三者都是Spark的分布式数据集，核心区别在“数据结构”和“优化能力”：

RDD：无结构化（只存对象），无Schema，不支持SQL，适合底层操作（比如自定义算法）；

DataFrame：有结构化Schema（像数据库表），支持SQL和Catalyst优化，但类型不安全（编译时不检查类型）；

DataSet：结合两者优点，有Schema且类型安全，编译时能查错，还支持面向对象操作。

实际选：做简单数据清洗、SQL分析用DataFrame（快）；复杂业务逻辑（比如需强类型校验）用DataSet；写自定义算子（比如机器学习特征工程）用RDD。之前做电商用户画像，用DataSet处理用户行为数据，能提前发现类型错误，避免线上出问题。

问：Spark遇到数据倾斜怎么办？举个你处理过的例子。

答：数据倾斜本质是“某几个Key的数据量远超其他Key，导致对应Task卡壳”，一般分三步解决：

①先定位倾斜Key：用countByKey()看各Key的数量，或在SparkUI的Stage页面看Task运行时间（倾斜的Task会跑很久）；

②处理方案：

小表广播：如果是Join倾斜，且其中一张表很小（比如100MB以内），用broadcast()广播小表，避免Shuffle；

Key拆分：比如倾斜Key是“null”，把它拆成“null_1”“null_2”…多个子Key，和另一张表的对应Key也拆分后Join，最后合并；

例子：之前做日志分析，某接口的错误日志Key（“error_500”）占比80%，导致ReduceTask卡了1小时，后来把这个Key拆成10个（“error_500_01”到“error_500_10”），对应的数据也拆分，最后Reduce跑了5分钟就结束了。

三、数据仓库与同步

问：星型模型和雪花模型的区别，OLAP场景选哪个？

答：都是数据仓库的表结构设计：

星型模型：中心是事实表（比如订单表，存交易金额、数量），周围是维度表（用户、商品、时间，直接关联事实表），维度表不关联其他维度表，优点是查询快、易理解；

雪花模型：维度表会再拆分（比如商品维度表拆成“商品表”和“品牌表”，品牌表再关联商品表），优点是省存储，但查询要多表Join，速度慢。

OLAP场景（比如报表分析、多维度钻取）肯定选星型模型，因为OLAP看重查询效率，比如电商的“月度各品类销售额”报表，星型模型直接用“订单事实表+商品维度表+时间维度表”Join，比雪花模型快很多。

问：Sqoop和FlinkCDC都能同步数据，怎么选？

答：核心看“同步场景是离线还是实时”：

Sqoop：适合离线批量同步（比如每天凌晨同步昨天的MySQL数据到HDFS），原理是通过JDBC连接源库，批