基本信息
文件名称:大数据常见面试题及答案(实战版).docx
文件大小:20.5 KB
总页数:3 页
更新时间:2025-10-01
总字数:约3千字
文档摘要

大数据常见面试题及答案(实战版)

一、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连接源库,批