2025年网易大数据测试题及答案

2025年网易大数据测试题及答案一、基础概念题1.简述大数据场景下“数据倾斜”的定义、常见表现及根本原因。答案：数据倾斜指分布式计算中，部分节点处理的数据量远大于其他节点，导致整体任务耗时增加甚至失败。常见表现为任务长时间卡在某几个reduce或shuffle阶段，部分节点内存溢出（OOM）。根本原因是数据分布不均，如key的频率差异大（如某用户行为事件的key出现次数是其他key的数百倍）、关联操作中某张表的特定值占比过高（如大表join时小表的某条记录重复关联）。2.对比离线计算（如Hive）与实时计算（如Flink）在数据处理模型、延迟要求、适用场景上的核心差异。答案：数据处理模型：离线计算基于批处理，将数据按固定时间窗口（如每日）分批处理；实时计算基于流处理，逐条或微批处理数据。延迟要求：离线计算通常为小时级或天级，实时计算要求毫秒级到秒级。适用场景：离线计算用于历史数据统计、深度分析（如月度用户画像）；实时计算用于实时监控（如直播弹幕热度）、实时推荐（如电商页面商品实时排序）。3.描述HDFS的NameNode与DataNode的核心职责，以及HDFS如何保证数据可靠性。答案：NameNode管理文件元数据（如文件目录、块位置），协调客户端与DataNode的交互；DataNode存储实际数据块，执行读写操作并向NameNode汇报状态。数据可靠性通过三副本机制（默认3个副本存储在不同机架）、心跳检测（NameNode定期检测DataNode状态，副本丢失时自动复制）、校验和（存储和读取时校验数据完整性）实现。4.解释Kafka中ISR（In-SyncReplicas）的作用，以及ISR收缩/扩张的触发条件。答案：ISR是与Leader副本保持同步的Follower副本集合，用于保证消息的持久化和一致性。当Follower副本落后Leader的时间或消息数超过阈值（由参数replica.lag.time.max.ms和replica.lag.max.messages控制），会被移出ISR；当落后的Follower追上Leader后，会被重新加入ISR。ISR的最小数目由min.insync.replicas参数控制，若ISR大小低于该值，写入操作会抛出异常，避免数据丢失。二、SQL编程题（基于Hive/SparkSQL）1.某电商用户行为表（user_behavior）包含字段：user_id（用户ID）、item_id（商品ID）、behavior_type（行为类型，'pv'浏览，'cart'加购，'fav'收藏，'buy'购买）、event_time（事件时间，格式'2025-01-0112:00:00'）。要求计算2025年1月每个用户的“购买转化率”（购买次数/浏览次数），并筛选转化率Top100的用户（需处理分母为0的情况）。答案：```sqlWITHpv_buy_statsAS(SELECTuser_id,SUM(CASEWHENbehavior_type='pv'THEN1ELSE0END)ASpv_cnt,SUM(CASEWHENbehavior_type='buy'THEN1ELSE0END)ASbuy_cntFROMuser_behaviorWHEREevent_timeBETWEEN'2025-01-0100:00:00'AND'2025-01-3123:59:59'GROUPBYuser_id)SELECTuser_id,COALESCE(buy_cnt/NULLIF(pv_cnt,0),0)ASconversion_rateFROMpv_buy_statsORDERBYconversion_rateDESCLIMIT100;```关键点：使用CASEWHEN统计不同行为类型次数，NULLIF处理分母为0（避免除零错误），COALESCE将NULL转为0。2.日志表（log_table）包含字段：user_id、login_time（登录时间，时间戳），要求计算每个用户2025年1月的“最长连续登录天数”（连续指自然日连续，如1月1日、1月2日登录视为连续2天）。答案：```sqlWITHdaily_loginAS(SELECTuser_id,DATE(login_time)ASlogin_dateFROMlog_tableWHERElogin_time>='2025-01-01'ANDlogin_time<'2025-02-01'GROUPBYuser_id,DATE(login_time)-去重同一天多次登录),ranked_loginAS(SELECTuser_id,login_date,-计算当前日期与排序后的前N天的差值，用于判断连续login_dateROW_NUMBER()OVER(PARTITIONBYuser_idORDERBYlogin_date)ASgrpFROMdaily_login)SELECTuser_id,MAX(COUNT())OVER(PARTITIONBYuser_id,grp)ASmax_consecutive_daysFROMranked_loginGROUPBYuser_id,grpORDERBYuser_id;```关键点：通过ROW_NUMBER提供连续序号，用日期减序号得到分组标识（grp），同一grp内的日期连续，最后统计每组的天数取最大值。3.订单表（order）字段：order_id、user_id、order_time（下单时间）、amount（金额）；用户表（user）字段：user_id、city（城市）。要求计算2025年Q1每个城市的“GMV（总金额）”、“订单数”、“用户数”（独立用户），并按GMV降序排列。答案：```sqlSELECTu.city,SUM(o.amount)ASgmv,COUNT(DISTINCTo.order_id)ASorder_cnt,COUNT(DISTINCTo.user_id)ASuser_cntFROMorderoJOINuseruONo.user_id=u.user_idWHEREo.order_time>='2025-01-01'ANDo.order_time<'2025-04-01'GROUPBYu.cityORDERBYgmvDESC;```关键点：使用COUNT(DISTINCT)去重订单和用户，JOIN关联用户城市，日期过滤Q1范围。三、Hadoop/Spark原理题1.简述SparkShuffle的执行流程，并说明如何优化Shuffle性能。答案：Shuffle是将相同key的数据分发到同一Reducer的过程，流程分为三个阶段：Map端：每个Mapper将数据按key分区，写入本地磁盘的分区文件（由ShuffleWriter处理）；网络传输：Reducer通过BlockManager拉取对应分区的数据（由ShuffleReader处理）；Reduce端：将拉取的数据合并（排序或聚合）后供后续计算。优化方法：减少Shuffle数据量：使用map-side聚合（如reduceByKey替代groupByKey）、过滤无关数据；调整分区数（spark.sql.shuffle.partitions）：避免分区过多（增加任务数）或过少（数据倾斜）；优化磁盘IO：使用本地磁盘（而非NFS）、开启压缩（press）；内存调优：增加executor内存（spark.executor.memory），避免Shuffle数据落盘。2.对比RDD、DataFrame、Dataset的核心区别及适用场景。答案：RDD（弹性分布式数据集）：低阶API，以不可变的JVM对象存储，支持任意类型，无结构信息，适合需要细粒度控制的复杂计算（如自定义分区器）；DataFrame：高阶API，以Row对象存储，带schema（列名和类型），支持类似关系表的操作（如SQL查询），优化了执行计划（Catalyst优化器），适合结构化数据处理；Dataset：结合RDD的类型安全与DataFrame的schema，通过caseclass定义强类型，支持lambda表达式，适合需要类型安全且结构化的场景（如复杂业务对象处理）。适用场景：RDD用于需要底层控制的算法（如机器学习自定义迭代）；DataFrame用于ETL、报表统计；Dataset用于需要类型安全的业务逻辑（如用户行为分析中的对象操作）。3.描述Hive中“分区（Partition）”与“分桶（Bucket）”的设计目的及使用场景。答案：分区用于将数据按业务维度（如时间、地区）划分成目录，查询时通过分区裁剪（PartitionPruning）减少扫描数据量，适合高频过滤的字段（如dt=20250101）。分桶通过哈希函数将数据分散到多个文件（桶），支持基于桶的JOIN（减少shuffle）和采样（TABLESAMPLE），适合等值连接的字段（如user_id分桶后，JOIN时直接按桶匹配）。四、数据仓库与ETL题1.设计一个电商用户行为数据仓库的分层架构（需说明各层命名、存储内容及核心作用）。答案：ODS层（OperationalDataStore）：命名ods_，存储原始日志/业务库同步数据（如埋点日志、MySQL订单表全量），保留原始格式（JSON/CSV），作用是数据归档，保证可追溯；DWD层（DataWarehouseDetail）：命名dwd_，存储清洗后的明细数据（去重、补全空值、统一时间格式），如dwd_user_behavior_di（每日增量），作用是提供一致的基础数据；DWS层（DataWarehouseSummary）：命名dws_，存储轻度聚合数据（如用户每日行为统计dws_user_behavior_daily），作用是减少后续计算复杂度；ADS层（ApplicationDataService）：命名ads_，存储业务主题结果（如首页GMV看板ads_homepage_gmv_daily），直接对接应用，作用是快速响应查询。2.某ETL任务需将MySQL的订单表（每日新增1000万条）同步到Hive，设计完整的同步方案（需考虑增量抽取、数据校验、异常处理）。答案：增量抽取：通过MySQL的binlog（如Canal工具）捕获变更，或基于订单表的update_time字段（每日抽取update_time>前一天的记录），避免全量同步；数据校验：同步后对比MySQL的count()与Hive的count()，校验字段长度（如金额是否为正数）、唯一性（order_id是否重复），使用Checksum对比关键字段；异常处理：同步失败时记录错误日志（如网络中断），触发告警（邮件/企业微信），支持断点续传（记录最后同步的binlog位置或update_time）；性能优化：使用并行读取（分库分表时按分片同步）、压缩存储（Hive使用ORC+SNAPPY压缩）。五、性能调优与场景题1.某Spark作业处理100GB数据时，出现“ExecutorLostFailure”（Executor频繁退出），可能的原因及解决方法？答案：可能原因及解决：内存不足：Executor内存过小导致OOM，通过spark.executor.memory增大内存（如从8G调至16G），或减少并行任务数（spark.sql.shuffle.partitions调小）；磁盘IO瓶颈：Shuffle数据写入本地磁盘慢，检查磁盘是否满（清理临时文件），或使用更快的磁盘（SSD）；数据倾斜：某Partition数据过大，导致单个Executor压力大，通过抽样分析key分布，对倾斜key加随机前缀，聚合后去前缀；资源竞争：YARN队列资源不足，调整队列优先级或增加集群资源（如增加NodeManager节点）。2.设计一个实时数据监控系统，用于检测用户行为数据的“缺失率”（如某时间段应有100万条数据，实际只有80万条）和“延迟”（事件时间与采集时间的差值超过5分钟的比例），需说明使用的技术栈及核心指标计算逻辑。答案：技术栈：Kafka（接收实时数据流）、Flink（实时计算）、Prometheus+Grafana（监控指标存储与展示）；缺失率计算：基于Kafka的时间窗口（如10分钟滚动窗口），统计实际接收数据量；预期数据量通过历史同期均值（如前7