一、简答题

第1章 大数据概述

1. 简述大数据的4V特征及其含义

答：

• Volume（数据量大）：数据规模从TB级到PB、EB级持续增长
• Velocity（处理速度快）：要求实时或近实时处理，秒级甚至毫秒级响应
• Variety（数据类型多）：包括结构化数据、半结构化数据（JSON/XML）、非结构化数据（文本/图像/视频）
• Value（价值密度低）：海量数据中蕴含价值，但单位数据价值密度低，需要深度挖掘

2. 大数据技术栈主要包含哪些层次？各层次的核心技术是什么？

答：

• 数据采集层：Flume（日志采集）、Sqoop（数据库导入）、Kafka（消息队列）
• 数据存储层：HDFS（分布式文件）、HBase（列式数据库）、Redis（缓存数据库）
• 计算引擎层：MapReduce（离线批处理）、Spark（内存计算）、Flink（流处理）
• 数据分析层：Hive（数据仓库）、Presto（交互式查询）、Spark SQL
• 机器学习层：Spark MLlib（分布式机器学习）

3. 简述OLTP和OLAP的区别

答：

• OLTP（联机事务处理）：面向业务操作，高并发事务处理，数据量小，实时性要求高，如银行转账、订单系统
• OLAP（联机分析处理）：面向数据分析，复杂聚合查询，数据量大，实时性要求较低，如报表系统、数据仓库

第2章 Python大数据分析

4. 简述Pandas中DataFrame和Series的区别

答：

• Series：一维数据结构，类似数组，包含索引和值两部分
• DataFrame：二维表格型数据结构，类似Excel表格，由多个Series组成（每列是一个Series）
• DataFrame既有行索引也有列索引，Series只有一个维度的索引

5. Pandas处理缺失值的常用方法有哪些？

答：

• 删除法：dropna()删除包含缺失值的行或列
• 填充法：fillna()用指定值、均值、中位数、众数填充
• 插值法：interpolate()根据相邻值进行线性或时间序列插值
• 标记法：将缺失值作为特殊类别处理

6. NumPy数组和Python原生列表相比有哪些优势？

答：

• 内存效率高：相同数据量占用内存更小
• 运算速度快：向量化操作，避免Python循环开销
• 功能丰富：支持矩阵运算、广播、统计等科学计算
• 类型统一：数组元素类型一致，避免动态类型检查开销

7. 数据可视化在数据分析中的作用是什么？常用的Python可视化库有哪些？

答：

作用：探索数据分布、发现规律和异常、展示分析结果、辅助决策

常用库：

• Matplotlib：基础绘图库，灵活度高
• Seaborn：基于Matplotlib，统计可视化更友好
• Plotly：交互式可视化，支持Web展示
• Pyecharts：基于ECharts的Python接口

第3章 Kafka

8. 简述Kafka的核心组件及其作用

答：

• Producer：生产者，向Broker发送消息
• Consumer：消费者，从Broker拉取消息
• Broker：Kafka服务器节点，存储和处理消息
• Topic：主题，消息的逻辑分类
• Partition：分区，Topic的物理分片，提高并行度
• Offset：偏移量，消息在分区内的唯一标识
• Consumer Group：消费者组，实现负载均衡和广播消费

9. Kafka的ISR机制是什么？有什么作用？

答：

ISR（In-Sync Replicas）是同步副本集合

• Leader维护一个与自己保持同步的Follower副本列表
• 只有ISR中的副本才有资格被选举为新Leader
• ACKS=-1时需要ISR中所有副本都写入成功才确认
• 作用：在数据可靠性和可用性之间取得平衡，避免慢副本影响性能

10. Kafka如何保证分区内消息的顺序性？

答：

• 单个Partition内消息严格按写入顺序存储，Offset递增
• 生产者发送消息时可指定key，相同key的消息路由到同一个Partition
• 消费者按Offset顺序消费，单线程消费保证顺序
• 注意：Kafka只保证分区内有序，不保证全局有序

11. Kafka消费者组的Rebalance机制是什么？触发条件有哪些？

答：

Rebalance是消费者组内分区所有权重新分配的过程

触发条件：

• 消费者组成员数量变化（新增/离开）
• Topic分区数量变化
• 订阅的Topic数量变化
• 消费者超时未发送心跳
• 作用：实现负载均衡，保证分区被消费

第4章 数据存储

12. 简述HDFS的架构及各组件职责

答：

• NameNode：主节点，管理元数据（目录树、文件块映射、块位置），处理客户端请求
• DataNode：从节点，存储实际数据块，执行读写操作，定期向NameNode汇报
• SecondaryNameNode：辅助NameNode合并fsimage和editlog，不是热备
• 特点：主从架构、高容错、适合大文件存储

13. HDFS的副本放置策略是什么？

答：

默认3副本策略：

• 第一个副本：写入客户端所在的DataNode（客户端在集群外则随机选）
• 第二个副本：写入另一个机架的DataNode（机架容错）
• 第三个副本：写入与第二个副本同机架的不同DataNode（同机架网络快）
• 更多副本：随机放置
• 作用：兼顾数据可靠性和读写性能

14. HBase的数据模型是什么？各组成部分的含义？

答：

• RowKey：行键，唯一标识一行，二进制有序，按字典序排序
• Column Family：列族，表创建时指定，物理上分开存储，一个列族包含多个列
• Column Qualifier：列限定符，动态列，无需预定义
• Version：版本号，默认是时间戳，一个单元格可保存多个版本的值
• Cell：单元格，由RowKey+CF+CQ+Version唯一确定，存储具体值

15. HBase和传统关系型数据库的区别是什么？

答：

• 数据模型：HBase是列式存储，稀疏多维映射；RDBMS是行式，二维表
• Schema：HBase列动态扩展；RDBMS Schema固定
• 索引：HBase只有RowKey索引；RDBMS支持多列索引
• 事务：HBase只支持单行事务；RDBMS支持跨行跨表ACID
• 扩展性：HBase水平扩展；RDBMS扩展困难
• 查询：HBase适合简单查询和范围扫描；RDBMS支持复杂SQL

16. Redis支持哪些数据类型？各自的应用场景是什么？

答：

• String：字符串/数字，缓存、计数器、分布式锁
• List：链表，消息队列、最新列表
• Set：无序集合，去重、交集并集运算、标签
• Hash：哈希表，存储对象、用户信息
• ZSet：有序集合，排行榜、带权重的队列
• 附加：Bitmap、HyperLogLog、Geo、Stream

17. Redis的两种持久化方式RDB和AOF的优缺点对比

答：

• RDB：定时快照，二进制文件，恢复快，文件小；缺点是可能丢失最后一次快照后的数据
• AOF：追加写命令，数据完整，可读性好；缺点是文件大，恢复慢
• 推荐：混合持久化，RDB全量+AOF增量，兼顾速度和完整性

18. Redis的过期键删除策略是什么？

答：

• 定期删除：每隔一段时间随机抽取部分过期键删除，CPU友好但内存不及时
• 惰性删除：访问键时才检查是否过期，内存友好但CPU不及时
• Redis采用：定期删除+惰性删除结合
• 内存不足时触发淘汰策略

第5章 图数据处理

19. 图数据库相比关系型数据库在处理关联数据的优势是什么？

答：

• 原生图存储：节点和关系作为一等公民，物理上相邻存储
• 免JOIN查询：关联查询通过指针跳转，无需昂贵的JOIN操作
• 深度遍历高效：多层关系查询性能稳定，不随深度指数下降
• 模型直观：实体-关系直接映射为节点-关系，符合业务直觉
• 适合场景：社交网络、推荐系统、知识图谱、金融风控

20. Cypher查询语言中MATCH、CREATE、WHERE、RETURN的作用是什么？

答：

• MATCH：匹配图模式，指定要查找的节点和关系结构
• CREATE：创建新的节点或关系
• WHERE：添加过滤条件，类似SQL的WHERE
• RETURN：指定返回结果，类似SQL的SELECT
• 示例：MATCH (p:Person)-[:FRIEND]->(f) WHERE p.age>20 RETURN p.name, f.name

21. Spark GraphX的核心抽象是什么？

答：

• Graph：图结构抽象，包含VertexRDD和EdgeRDD
• VertexRDD：顶点RDD，(VertexId, VD)键值对
• EdgeRDD：边RDD，包含源顶点ID、目标顶点ID和边属性
• Triplet：三元组，包含源顶点、边、目标顶点的完整信息
• 特点：基于RDD，分布式、容错、可并行计算

22. PageRank算法的核心思想是什么？

答：

• 基于链接分析的节点重要性评估算法
• 核心假设：重要节点会被其他重要节点链接
• 公式：PR(A) = (1-d) + d × Σ(PR(i)/C(i))

  - d是阻尼系数（一般0.85），表示随机跳转概率

  - C(i)是节点i的出链数

• 迭代计算直到收敛，值越高节点越重要
• 应用：网页排名、社交网络影响力分析

第6章 离线计算

23. MapReduce的编程模型及执行流程是什么？

答：

编程模型：

• Map阶段：输入分片→<key, value>对→处理→输出中间结果
• Reduce阶段：拉取Map输出→按key分组→聚合→输出最终结果

执行流程：

1. InputFormat：输入分片，创建RecordReader

2. Map任务：执行map函数，写入环形缓冲区

3. Shuffle阶段：分区、排序、Combiner、溢写、合并

4. Reduce任务：拉取数据、合并、排序、执行reduce函数

5. OutputFormat：写入输出文件

24. MapReduce中Shuffle阶段的作用是什么？包含哪些步骤？

答：

Shuffle是连接Map和Reduce的桥梁，将Map输出整理为Reduce输入

Map端Shuffle：

• 分区（Partitioner）：确定哪个Reduce处理
• 排序（Sort）：按key排序
• 合并（Combiner）：本地聚合，减少数据量
• 溢写（Spill）：内存满了写入磁盘
• 归并（Merge）：多个溢写文件合并

Reduce端Shuffle：

• 拉取（Fetch）：从各Map节点拉取数据
• 合并（Merge）：合并拉取的数据
• 排序（Sort）：最终排序

25. Spark RDD的五大特性是什么？

答：

• 分区（Partition）：数据集分片，并行计算的基础
• 计算函数（Compute）：每个分区的计算逻辑
• 依赖（Dependencies）：RDD间的血缘关系
• 分区器（Partitioner）：key-value RDD的分区策略
• 优先位置（Preferred Location）：计算任务的最优位置，数据本地化

26. Spark中宽依赖和窄依赖的区别是什么？

答：

• 窄依赖：父分区只对应一个子分区，无Shuffle，如map、filter、union
• 宽依赖：父分区对应多个子分区，发生Shuffle，如reduceByKey、groupByKey、join
• 区别标志：是否发生数据混洗（Shuffle）
• Stage划分：从后往前遇到宽依赖就划分新Stage

27. Spark的DAG调度流程是什么？

答：

1. Action算子触发Job提交

2. DAGScheduler：

   - 构建DAG图

   - 按宽依赖划分Stage

   - 生成TaskSet（每个Stage对应一组Task）

   - 提交TaskSet给TaskScheduler

3. TaskScheduler：

   - 分配Task到Executor

   - 考虑数据本地化

   - 监控Task执行，失败重试

4. Executor执行Task，返回结果

28. **RDD、DataFrame、DataSet三者的区别和联系？**

答：

• RDD：无Schema，类型安全，面向对象API，编译期检查，优化少
• DataFrame：有Schema，Spark SQL Catalyst优化，性能好，无类型安全
• DataSet：结合两者优点，有Schema+类型安全，只有Scala/Java支持
• 联系：DataFrame是DataSet[Row]的别名，三者可互相转换
• 性能：DataFrame/DataSet > RDD，因为有 Catalyst优化和Tungsten执行引擎

Spark MLlib & OLAP

29. 机器学习流水线Pipeline包含哪些核心组件？

答：

• DataFrame：ML的数据结构，存储特征和标签
• Transformer：转换器，输入DataFrame输出新DataFrame，如特征处理
• Estimator：评估器，fit()方法训练模型，输出Transformer（模型）
• Evaluator：评估器，评估模型性能，如准确率、AUC
• Pipeline：按顺序组装多个Stage，形成完整机器学习工作流

30. 数据仓库的维度建模中星型模型和雪花模型的区别？

答：

• 星型模型：事实表直接连接多个维度表，维度表不拆分，查询简单，冗余大
• 雪花模型：维度表规范化，拆分为多层，冗余小，查询复杂，JOIN多
• 选择：数据仓库一般优先星型模型，查询性能更好，开发简单
• 星座模型：多个事实表共享维度表，更复杂的业务场景

二、分析题（共20道）

存储与架构分析

1. 某企业数据量快速增长，需要设计存储方案。请分析HDFS、HBase、Redis分别适合什么场景？如何组合使用？

答：

适用场景分析：

• HDFS：适合存储海量原始数据、日志文件、历史归档，大文件顺序访问，高吞吐低成本
• HBase：适合海量结构化数据的随机读写、实时查询、稀疏数据，如用户画像、订单明细
• Redis：适合热数据缓存、计数器、会话存储、低延迟访问，全内存高性能

组合方案：

• 原始数据：采集后写入HDFS，作为数据湖存储
• 实时查询：HDFS数据ETL后导入HBase，提供在线随机查询
• 热点加速：HBase高频访问数据缓存到Redis，降低HBase压力
• 数据流向：Kafka→HDFS（原始）→Spark ETL→HBase（服务）→Redis（缓存）

2. 分析HDFS小文件问题的成因、影响及解决方案

答：

成因：

• 流式数据逐条写入，生成大量小文件
• MapReduce/Spark任务分区过多，输出大量小文件
• 实时计算微批输出，每个批次一个文件

影响：

• NameNode内存压力：每个文件元数据约150字节，1亿文件占用15GB内存
• Map任务过多：一个小文件一个Map，资源浪费调度开销大
• 寻址开销大：大量小文件寻址时间超过读取时间

解决方案：

• 写入端：合并后再写入HDFS，SequenceFile/HAR归档
• 计算端：CombineTextInputFormat合并输入分片
• 服务端：Hive自动合并、定时任务合并小文件
• 替代方案：小文件存入HBase，不直接存HDFS

3. 分析Redis缓存穿透、缓存击穿、缓存雪崩的区别、成因及解决方案

答：

缓存穿透：

• 现象：查询不存在的数据，请求直接打到数据库
• 成因：恶意攻击、参数错误
• 方案：布隆过滤器过滤不存在的key、缓存空值、接口层校验

缓存击穿：

• 现象：热点key过期瞬间，大量请求击穿到数据库
• 成因：热点数据过期时间集中
• 方案：热点key永不过期、互斥锁（分布式锁）、后台异步更新

缓存雪崩：

• 现象：大量key同时过期，数据库压力骤增
• 成因：过期时间相同、缓存服务宕机
• 方案：过期时间加随机值、多级缓存、缓存集群高可用、服务降级熔断

4. 分析HBase RowKey设计的重要性及设计原则，举例说明

答：

重要性：

• RowKey是HBase唯一索引，决定查询性能
• 决定数据分布，影响Region负载均衡
• 设计不好导致热点问题、查询性能低下

设计原则：

1. 唯一性：必须唯一标识一行

2. 散列性：避免连续RowKey写入同一Region造成热点

   - 方法：哈希前缀、反转、加盐

   - 反例：时间戳开头，所有数据写入最新Region

3. 有序性：便于范围扫描，相关数据RowKey前缀相同

4. 长度原则：尽量短，建议10-100字节，过长占用存储空间

示例：用户行为表

• 差设计：timestamp + user_id → 热点问题
• 好设计：hash(user_id) + user_id + timestamp → 散列+有序
• 效果：同一用户数据连续存储，便于范围查询，同时散列避免热点

5. 分析Kafka消息积压的原因、排查方法及解决方案

答：

原因分析：

• 消费能力不足：消费者处理逻辑慢、消费者数量少
• 分区数不足：分区数限制并行消费能力
• 消息突增：业务峰值、流量洪峰
• 异常阻塞：消费线程阻塞、死锁、外部依赖超时

排查方法：

• 监控Consumer Lag：查看积压速率
• 监控消费者CPU/内存：是否资源瓶颈
• 查看消费者日志：是否报错或超时
• 查看Topic消息流入速率：是否流量突增

解决方案：

1. 扩容：增加消费者数量（不超过分区数）、增加分区数

2. 优化：消费逻辑异步化、批量处理、跳过非重要消息

3. 限流：生产者端限流、削峰填谷

4. 应急：临时增加消费线程、消息丢弃/降级处理

Spark & 计算引擎分析

6. 分析Spark数据倾斜的现象、原因及解决方案

答：

现象：

• Spark UI中某个Stage任务执行时间远长于其他任务
• 某个Task处理的数据量远大于平均值
• 作业长时间卡在某个Stage，最后OOM

原因：

• key分布不均匀，少数key对应大量数据
• 业务数据本身倾斜，如某些热门商品、大V用户
• Shuffle算子：groupByKey、reduceByKey、join等

解决方案：

1. 过滤异常key：过滤null或无效key

2. 两阶段聚合：先加盐局部聚合，再去盐全局聚合

3. Map端Join：小表广播，避免Shuffle

4. 调整并行度：增加shuffle.partitions

5. 动态加盐：大key拆分处理，小key正常处理

6. 倾斜Join：大表拆分，小表扩容后Join

7. 分析Spark cache()和persist()的区别及存储级别选择策略

答：

区别：

• cache() = persist(MEMORY_ONLY)，默认只存在内存
• persist()可指定存储级别，更灵活

存储级别：

• MEMORY_ONLY：只存内存，序列化Java对象，最快，内存占用大
• MEMORY_ONLY_SER：内存+序列化，省空间，CPU序列化开销
• MEMORY_AND_DISK：内存不够溢写到磁盘
• MEMORY_AND_DISK_SER：序列化+溢写磁盘
• DISK_ONLY：只存磁盘

选择策略：

• 数据小、频繁访问：MEMORY_ONLY
• 数据大：MEMORY_ONLY_SER，节省空间
• 计算昂贵：MEMORY_AND_DISK，避免重算
• 注意：缓存不是越多越好，占用内存影响其他任务，不用时unpersist()

8. 分析Spark作业运行慢的排查思路及优化方向

答：

排查思路：

1. 查看Spark UI：哪个Stage慢？哪个Task慢？

2. 查看资源使用：CPU/内存/磁盘IO是否瓶颈？

3. 查看Shuffle数据量：是否Shuffle过大？

4. 查看数据倾斜：是否有Task执行时间异常？

5. 查看GC：是否频繁GC？

优化方向：

1. 资源优化：合理设置Executor数量、内存、CPU核数

2. 算子优化：

   - 避免Shuffle：用reduceByKey替代groupByKey

   - 用mapPartitions替代map，减少初始化次数

   - 广播小表，用MapJoin替代ReduceJoin

3. 数据倾斜优化：加盐、过滤、调整并行度

4. 序列化：Kryo序列化，比Java序列化快体积小

5. 缓存：常用数据cache/persist

6. GC优化：调整Executor内存比例，CMS/G1垃圾回收

9. 分析MapReduce和Spark的区别及各自适用场景

答：

架构区别：

• MapReduce：磁盘计算，Map+Reduce两阶段，中间结果落盘
• Spark：内存计算，DAG引擎，中间结果在内存，迭代计算快

性能对比：

• Spark比MapReduce快10-100倍（内存计算）
• 迭代计算（机器学习、图计算）Spark优势明显
• 简单批处理差距不大

适用场景：

• MapReduce：超大规模批处理、稳定性要求高、资源紧张的场景
• Spark：迭代计算、交互式查询、流处理、机器学习
• 选择：数据量特别大（PB级）且不需要迭代，可选MapReduce；其他优先Spark

10. 分析Spark的宽窄依赖对容错和性能的影响

答：

对容错的影响：

• 窄依赖：某分区丢失只需重算对应父分区，恢复开销小，可并行恢复
• 宽依赖：某分区丢失需要重算所有父分区，恢复开销大
• 设计：Lineage容错机制，宽依赖开销大，所以宽依赖会自动写Checkpoint

对性能的影响：

• 窄依赖：无Shuffle，Pipeline执行，性能好
• 宽依赖：Shuffle开销大（磁盘IO、网络IO、序列化）
• 优化：尽量减少宽依赖，调整宽依赖的并行度

架构与业务分析

11. 分析Lambda架构和Kappa架构的原理、优缺点及适用场景

答：

Lambda架构：

• 原理：批处理层+速度层+服务层，批流分开计算，结果合并
• 优点：成熟稳定，批处理准确，流处理低延迟
• 缺点：两套逻辑维护成本高，结果合并复杂，最终一致性
• 适用：对准确性要求高，批流结果需要融合的场景

Kappa架构：

• 原理：以流处理为核心，批处理是流的特例，历史数据重放
• 优点：一套代码，维护简单，架构统一
• 缺点：历史数据重放开销大，流处理引擎要求高
• 适用：实时性要求高，数据量大，希望简化架构的场景

选择：

• 传统数仓、对准确性要求极高：Lambda
• 实时数仓、流处理为主：Kappa（主流趋势）

12. 分析数据仓库建模中星型模型设计的步骤及注意事项

答：

设计步骤：

1. 选择业务过程：确定分析主题，如订单、支付、登录

2. 声明粒度：每行数据代表什么，如一个订单、一次浏览

3. 确定维度：分析角度，如时间、用户、商品、地区

4. 确定事实：度量指标，如订单金额、数量、PV/UV

注意事项：

• 维度表：主键、维度属性，尽量退化，避免雪花化
• 事实表：外键关联维度表，指标可加性
• 日期维度：必须有，年/季/月/日/周等属性
• 缓慢变化维：处理维度属性变化，SCD1/SCD2/SCD3
• 避免大宽表：维度过多影响性能和维护

13. 分析实时数仓和离线数仓的区别及技术选型

答：

区别：

• 延迟：离线T+1，实时秒级/分钟级
• 计算引擎：离线Spark/MapReduce，实时Flink/Spark Streaming
• 存储：离线HDFS/Hive，实时Kafka/HBase/ClickHouse
• 建模：离线维度建模，实时宽表为主

技术选型：

• 采集：Fluentd/Logstash → Kafka
• 计算：Flink（流处理）+ Spark（批处理）
• 存储：ODS(Kafka)、DWD(Kafka/HDFS)、DWS(ClickHouse/Doris)、ADS(MySQL/Redis)
• 查询：Presto/ClickHouse

架构：

• Kappa架构，流批一体
• 分层：ODS→DWD→DWS→ADS，每层实时化

14. 分析机器学习中过拟合和欠拟合的现象、原因及解决方法

答：

过拟合：

• 现象：训练集效果好，测试集效果差，模型太"聪明"
• 原因：模型太复杂、训练数据太少、噪声太多
• 解决：增加训练数据、正则化（L1/L2）、Dropout、早停、简化模型

欠拟合：

• 现象：训练集和测试集效果都差，模型太"笨"
• 原因：模型太简单、特征太少、训练不足
• 解决：增加特征、增加模型复杂度、增加训练轮数

诊断方法：

• 学习曲线：训练误差和验证误差随样本量变化
• 验证曲线：不同超参数下的训练/验证误差

15. 分析推荐系统中协同过滤算法的原理、分类及优缺点

答：

原理：

• 物以类聚，人以群分，相似用户喜欢相似物品

分类：

1. 基于用户（UserCF）：找相似用户，推荐他们喜欢的物品

   - 优点：推荐新颖，社会化，适合用户少物品多

   - 缺点：用户兴趣变化快，稀疏性问题，冷启动

2. 基于物品（ItemCF）：找相似物品，推荐用户喜欢物品的相似品

   - 优点：物品相似度稳定，可预计算，解释性好

   - 缺点：热门物品相似度高，推荐多样性差

3. 基于模型（ModelCF）：矩阵分解、机器学习模型

   - 优点：性能好，可处理稀疏数据，泛化能力强

   - 缺点：解释性差，训练复杂

选择：

• 电商：ItemCF为主（物品稳定）
• 社交：UserCF为主（社交关系）

16. 分析图计算在社交网络分析中的应用场景及优势

答：

应用场景：

1. 社交关系发现：好友推荐、二度人脉

2. 影响力分析：PageRank计算用户影响力

3. 社区发现：连通分量、Louvain算法发现社群

4. 异常检测：金融反欺诈、传销识别

5. 路径分析：最短路径、关联度计算

优势：

1. 模型直观：用户是节点，关注/好友是关系

2. 查询高效：多层关系查询无需JOIN

3. 算法丰富：社区发现、标签传播、中心性计算

4. 并行计算：Spark GraphX/Neo4j分布式处理

示例：

• 好友推荐：共同好友数+Jaccard相似度
• 谣言传播：图传播算法模拟传播路径

17. 分析Redis和Kafka作为消息队列的区别及选型

答：

Redis消息队列：

• 实现：List结构（LPUSH+BRPOP）、Pub/Sub、Stream
• 优点：轻量、低延迟、部署简单
• 缺点：不保证不丢、无回溯、堆积能力弱
• 适用：简单队列、即时通知、非关键路径

Kafka消息队列：

• 优点：高吞吐、持久化、回溯消费、堆积能力强、高可用
• 缺点：部署复杂、延迟稍高、重量级
• 适用：大数据场景、日志采集、解耦系统、可靠消息

选型：

• 大数据链路、可靠传输：Kafka
• 简单业务、低延迟、数据量小：Redis
• 注意：Redis 5.0+ Stream功能增强，但仍不如Kafka专业

18. 分析Hive、Spark SQL、Presto的区别及查询场景选型

答：

Hive on MR/Tez/Spark：

• 特点：稳定、成熟、适合大规模ETL
• 延迟：分钟级
• 适用：T+1离线批处理、数据清洗转换

Spark SQL：

• 特点：内存计算、速度快、兼容Hive元数据
• 延迟：秒级到分钟级
• 适用：交互式查询、中等规模ETL、混合处理

Presto：

• 特点：MPP架构、纯内存计算、多数据源联邦查询
• 延迟：亚秒级到秒级
• 适用：Ad-hoc查询、多数据源关联、BI报表

选型建议：

• 大规模离线ETL：Hive
• 数据探索、交互式分析：Spark SQL
• BI报表、即席查询：Presto/ClickHouse

19. 分析数据质量监控的重要性及监控维度

答：

重要性：

• 垃圾进垃圾出，数据质量决定分析可信度
• 数据问题发现越晚，修复成本越高
• 影响业务决策，甚至造成损失

监控维度：

1. 完整性：数据是否完整，是否丢失

   - 监控：数据量波动、主键非空、关联匹配

2. 一致性：同一数据不同来源是否一致

   - 监控：多源校验、主键重复、枚举值合法

3. 准确性：数据是否正确

   - 监控：数值范围、格式校验、业务规则

4. 及时性：数据是否按时产出

   - 监控：任务完成时间、延迟告警

5. 唯一性：数据是否重复

   - 监控：主键去重、唯一索引

实现：

• 规则引擎+告警通知
• 数据质量报告+SLA

20. 分析大数据平台高可用设计的关键点

答：

组件高可用：

• HDFS：NameNode HA（Active/Standby）、ZKFC自动故障转移
• YARN：ResourceManager HA
• HBase：HMaster HA、RegionServer故障转移
• Kafka：多Broker、副本机制、Controller选举
• Redis：主从+哨兵、Cluster集群

计算高可用：

• Spark：Application Master重试、Speculative Execution推测执行
• 任务重试机制、失败告警

数据高可用：

• 多副本：HDFS 3副本、Kafka副本
• 跨机房同步、定期备份
• 数据校验：CRC、MD5

监控告警：

• 全链路监控：主机、组件、任务、业务
• 多级告警、值班机制、应急预案

容灾备份：

• 冷备：定期快照
• 热备：双机房同步
• 灾备演练

三、设计题（共10道）

1. 设计一个日增10TB的用户行为日志采集和存储方案

要求：基于PPT涉及的技术，考虑高吞吐、可靠性、扩展性

设计方案：

技术选型：

• 采集端：Filebeat（轻量日志采集）+ Flume（汇聚）
• 消息队列：Kafka（解耦、削峰、高吞吐）
• 存储层：HDFS（原始日志）+ HBase（用户明细）+ Redis（实时统计）

架构设计：

1. 接入层：

   - 应用服务器部署Filebeat，实时采集本地日志文件

   - Filebeat输出到Kafka，Topic按业务划分

   - 流量大的Topic增加分区数，提高并行度

2. 缓冲层：

   - Kafka集群3副本，ACKS=1保证性能和可靠性平衡

   - 消息保留7天，支持回溯消费

   - 监控Consumer Lag，及时扩容

3. 消费层：

   - 实时消费：Flink/Spark Streaming实时清洗、统计、告警

   - 离线消费：定时批量导入HDFS，按日期分区存储

   - 双消费链路，互不影响

4. 存储层：

   - 原始数据：HDFS，按天分区，Parquet列式存储，Snappy压缩

   - 明细数据：清洗后写入HBase，RowKey=hash(uid)+uid+timestamp

   - 统计数据：Redis实时计数器、分钟级统计结果

优化点：

• Kafka分区数=消费者数，最大化消费能力
• HDFS小文件定时合并
• HBase预分区避免热点
• 端到端监控，数据质量校验

2. 设计一个电商用户画像系统的技术架构

要求：支持标签加工、标签存储、标签查询

设计方案：

整体架构：

数据源 → 数据加工 → 标签存储 → 标签应用

1. 数据源层：

• 用户行为数据：浏览、点击、加购、购买日志
• 用户属性数据：注册信息、人口属性
• 业务数据：订单、支付、客服数据

2. 数据加工层：

• 事实标签：统计类标签，Spark SQL批量计算（T+1）

  - 例：近30天购买次数、客单价、活跃天数

• 模型标签：算法标签，Spark MLlib训练

  - 例：用户价值分层、流失概率、性别预测

• 实时标签：Flink实时计算

  - 例：实时活跃度、实时意向商品

3. 标签存储层

• HBase：用户标签宽表，RowKey=user_id，列族=标签类别

  - 支持随机查询、批量扫描

• Elasticsearch：标签索引，支持组合条件筛选人群

  - 支持多维组合查询、人群圈选

• Redis：热点用户标签缓存，低延迟查询

4. 标签应用层：

• 人群圈选：按标签组合筛选目标用户
• 个性化推荐：用户标签+物品标签匹配
• 精准营销：营销系统调用标签接口
• 数据分析：用户画像分析、标签分布统计

关键设计：

• 标签生命周期管理：标签上线、下线、版本
• 标签质量监控：覆盖率、准确率、稳定性
• 接口服务：RESTful API，支持高并发查询

3. 设计一个高并发秒杀系统的数据层架构

要求：基于Redis、Kafka、MySQL等技术，支持10万QPS

设计方案：

分层架构：

1. 流量控制层：

• 前端：CDN静态化、按钮置灰、验证码防刷
• Nginx：限流、IP黑白名单
• 应用层：令牌桶限流、降级开关

2. 缓存层（Redis）：

• 库存预热：活动开始前将商品库存载入Redis
• 分布式锁：SETNX+Lua脚本原子扣减库存
• 结果缓存：秒杀结果缓存，防重复查询
• 用户限流：用户维度频率控制
• 设计：Redis Cluster集群，主从+哨兵高可用

3. 异步层（Kafka）：

• 扣减库存成功后，发送创建订单消息到Kafka
• 消费者异步创建订单、扣减数据库库存
• 解耦前端请求和后端处理，提高吞吐量
• 消息重试+幂等，保证订单不丢不重

4. 数据库层（MySQL）：

• 主从架构，读写分离
• 订单表分库分表，按用户ID哈希
• 库存行锁优化，避免超卖
• 最终一致性：Redis+DB最终一致，定时对账

5. 状态查询层：

• 用户轮询秒杀结果，优先查Redis
• 订单创建成功后异步更新Redis状态
• 长连接/WebSocket主动通知结果

关键优化：

• 热点隔离：秒杀商品单独集群
• 异步处理：能异步不同步
• 降级机制：非核心功能降级
• 容量预估：压测+扩容预案

4. 设计一个企业级实时数仓架构

要求：基于Kappa架构，支持实时ETL、实时指标、实时报表

设计方案：

Kappa架构分层设计：

ODS层（原始数据层）：

• 数据采集：Fluentd采集业务日志、Canal采集Binlog
• 消息队列：Kafka，按数据源分Topic
• 保留策略：3天原始数据，支持重放

DWD层（明细数据层）：

• 计算引擎：Flink SQL流处理
• 处理逻辑：数据清洗、格式转换、维度关联、数据脱敏
• 输出：清洗后明细数据写回Kafka，同时落盘HDFS
• 特点：实时ETL，一次清洗多处使用

DWS层（汇总数据层）：

• 计算引擎：Flink窗口计算
• 处理逻辑：多维度聚合、指标计算
• 窗口类型：滚动窗口（分钟/小时）、滑动窗口、会话窗口
• 输出：ClickHouse/Doris，列式存储+MPP查询

ADS层（应用数据层）：

• 实时指标：写入MySQL/Redis，供接口查询
• 实时报表：ClickHouse提供BI报表查询
• 实时大屏：Flink聚合后推送到WebSocket

关键设计：

• 流批一体：同一套SQL，实时离线逻辑一致
•  Exactly Once：Flink两阶段提交+事务Sink
• 维表关联：广播维表+定时更新
• 数据质量：实时校验、异常告警

5. 设计一个海量图片存储和检索系统的存储方案

要求：支持10亿级图片存储、毫秒级检索

设计方案：

存储方案：

1. 原始图片存储：HDFS

• 小文件问题解决方案：

  - 图片文件按批次打包成SequenceFile

  - 文件名+偏移量作为图片唯一标识

  - 索引单独存储在HBase

• 优点：节省NameNode内存，高吞吐存储
• 冷热分离：热数据存SSD，冷数据存SATA

2. 图片元数据存储：HBase

• RowKey设计：md5(图片内容) + 时间戳
• 列族：basic（基本信息）、feature（特征向量）、meta（业务属性）
• 支持：按MD5去重、按时间范围查询、按属性筛选

3. 图片特征检索：Redis + 向量引擎

• 特征提取：CNN模型提取图片特征向量
• 检索方案：

  - 小规模：Redis缓存相似图片

  - 大规模：Milvus/FAISS向量搜索引擎

  - 召回：局部敏感哈希（LSH）快速召回候选

  - 精排：余弦相似度精确计算

4. 图片缓存：Redis + CDN

• 热点图片缓存到Redis，LRU淘汰
• 访问图片走CDN，回源到应用服务器
• 多级缓存，降低HDFS访问压力

访问流程：

上传：应用→HDFS→HBase写元数据→提取特征

下载：CDN→Redis→HBase查位置→HDFS读文件

检索：上传图片→提取特征→向量检索→返回相似图

6. 设计一个Spark作业性能优化方案

要求：针对典型Spark作业，从资源、代码、数据三个维度优化

设计方案：

一、资源层面优化

1. 资源参数配置：

--num-executors 50        # Executor数量

--executor-cores 4        # 每个Executor CPU核数

--executor-memory 16G     # 每个Executor内存

--driver-memory 8G        # Driver内存

--conf spark.default.parallelism=400    # 默认并行度

--conf spark.sql.shuffle.partitions=400 # Shuffle分区数

• 原则：CPU:内存 = 1:4~1:8
• 并行度 = 总CPU核数 × 2~3

2. 序列化配置：

--conf spark.serializer=org.apache.spark.serializer.KryoSerializer

--conf spark.kryo.registrationRequired=true

• Kryo序列化比Java快10倍，体积小
• 注册自定义类，避免自动检测开销

二、代码层面优化

1. 算子优化：

• 用reduceByKey/aggregateByKey替代groupByKey
• 用mapPartitions替代map，减少初始化次数
• 用foreachPartition替代foreach，批量写数据库
• 避免Shuffle：小表broadcast后map-side join

2. 缓存优化：

• 多次使用的RDD/DataFrame cache/persist
• 选择合适存储级别：MEMORY_ONLY_SER
• 及时unpersist释放内存

三、数据层面优化

1. 数据倾斜处理：

• 过滤异常key：过滤null或无效key
• 两阶段聚合：加盐局部聚合→去盐全局聚合
• 倾斜Join：大key拆分，小key正常处理

2. 输入输出优化：

• 输入：小文件合并，列式存储（Parquet/ORC）
• 输出：压缩（Snappy/Gzip），合理分区数

四、Shuffle优化：

--conf spark.shuffle.file.buffer=64k

--conf spark.reducer.maxSizeInFlight=96m

--conf spark.shuffle.io.maxRetries=5

• 增加Shuffle缓冲区，减少溢写
• 调整重试次数，避免网络波动失败

7. 设计一个推荐系统的召回层架构

要求：支持多路召回、融合排序，基于Spark MLlib

设计方案：

召回层架构：多路召回→粗排→精排

一、多路召回策略（百级→千级）

1. 热门召回：

• 全局热门、分类热门、趋势热门
• 适用：新用户、冷启动
• 实现：Spark统计T+1热门，Redis缓存

2. 协同过滤召回：

• ItemCF：基于物品相似度召回

  - 模型：余弦相似度、共现矩阵

  - 更新：T+1离线计算相似度矩阵

• UserCF：基于用户相似度召回

  - 适用：社交属性强的场景

3. 内容召回：

• 基于标签：用户标签匹配物品标签
• 基于向量：用户Embedding匹配物品Embedding
• 实现：ANN向量检索（Faiss/Milvus）

4. 行为召回：

• 浏览历史相似、购买历史相似
• 序列召回：DIN/Transformer用户行为序列

二、粗排层（千级→百级）

• 轻量级模型：LR、GBDT
• 特征少、速度快
• 过滤明显低质物品
• 平衡性能和精度

三、精排层（百级→十量级）

• 复杂模型：深度神经网络（Wide&Deep、DIN）
• 丰富特征：用户特征、物品特征、上下文特征、交叉特征
• 目标：CTR/CVR预估
• 实现：TensorFlow/PyTorch训练，TensorFlow Serving在线服务

四、重排层

• 业务规则：打散、去重、多样性
• 上下文：位置偏差、时效性
• 探索与利用：EE策略，推新

技术实现：

• 离线：Spark训练模型、计算相似度
• 存储：Redis存召回结果、HBase存特征
• 在线：召回服务→粗排→精排→重排→返回

8. 设计一个多租户大数据平台的资源隔离方案

要求：支持多部门共享集群，资源隔离不互相影响

设计方案：

一、计算资源隔离（YARN）

1. 队列隔离：

• 按部门划分YARN队列：root.data、root.algorithm、root.bi
• 配置队列容量：

  ```xml

  <name>yarn.scheduler.capacity.root.data.capacity</name>

  <value>40</value>

  ```

• 最大容量：允许弹性共享，如max-capacity=60
• 访问控制：ACL控制哪些用户可以提交到队列

2. 资源限制：

• 每个用户最大应用数
• 每个队列最大资源占比
• 任务优先级配置

二、存储资源隔离（HDFS）

1. 目录隔离：

• 按部门划分HDFS目录：/user/data/、/user/bi/
• 目录权限：700，只有部门用户可访问
• HDFS Quota：空间配额+文件数配额

  ```bash

  hdfs dfsadmin -setSpaceQuota 100T /user/data

  hdfs dfsadmin -setQuota 1000000 /user/data

  ```

2. HBase租户隔离：

• 按部门命名空间：namespace data_ns
• 表级权限：grant权限控制
• RegionServer分组：重要部门独占RegionServer

三、查询资源隔离

1. Hive权限：

• Ranger/Sentry权限控制
• 库、表、列级权限
• 行级过滤、列级脱敏

2. 查询限流：

• Presto/Spark SQL资源组
• 每个用户最大并发查询数
• 大查询自动kill

四、监控与计费

• 资源使用监控：CPU、内存、存储
• 计量计费：按资源使用量计费
• 超用告警、资源调整
• 租户SLA保障

9. 设计一个金融风控的实时特征计算架构

要求：支持毫秒级特征计算、特征回溯、特征一致性

设计方案：

一、实时特征分层架构

1. 特征数据源：

• 实时事件：交易、登录、行为事件→Kafka
• 维表数据：用户信息、设备信息→MySQL/HBase
• 历史数据：用户历史行为→HDFS

2. 实时计算层（Flink）：

• 窗口特征：

  - 滚动窗口：近5分钟/1小时交易次数

  - 滑动窗口：近24小时交易金额

  - 会话窗口：用户会话内行为统计

• 累计特征：

  - 历史累计交易次数、金额

  - 注册至今行为统计

• 复杂特征：

  - 序列特征、交叉特征、统计特征

3. 特征存储层：

• 在线特征：Redis Cluster，毫秒级查询

  - Key：user_id + feature_name

  - TTL：特征自动过期

• 离线特征：HDFS，Parquet存储，用于模型训练
• 特征仓库：Feature Store，特征管理和共享

二、关键技术点

1.  Exactly Once保证：

• Flink Checkpoint
• Kafka源幂等
• Redis Sink两阶段提交

2. 特征回溯：

• 离线回溯：Flink批处理重跑历史数据
• 时间旅行：按时间点回溯特征值

3. 特征一致性：

• 流批一体：同一套特征计算逻辑
• 特征校验：实时离线特征值对比
• 版本管理：特征版本化，可回滚

三、特征服务

• 特征服务接口：REST/gRPC
• 高并发：万级QPS，毫秒级响应
• 特征拼接：自动拼接用户所有特征
• 缓存：热点特征缓存

应用：

• 实时风控决策：交易时拉取特征→模型打分→决策
• 离线模型训练：批量特征导出

10. 设计一个数据中台的数据集成方案

要求：支持多源数据接入、统一元数据、数据血缘

设计方案：

一、数据接入层

1. 批量数据接入：

• 关系型数据库：MySQL/Oracle → DataX/Sqoop → HDFS
• 文件数据：FTP/OSS → 定时同步 → HDFS
• 增量同步：CDC方式，Canal采集Binlog

2. 实时数据接入：

• 日志数据：Filebeat/Fluentd → Kafka
• 业务事件：SDK埋点 → Kafka
• 数据库变更：Canal → Kafka

3. 接入方式：

• 可视化配置：Web界面配置同步任务
• 统一调度：Airflow定时调度
• 监控告警：同步状态、数据量、延迟

二、元数据管理

1. 元数据采集：

• 技术元数据：库表结构、字段类型、存储位置
• 业务元数据：业务含义、负责人、标签
• 操作元数据：读写权限、访问频率

2. 元数据服务：

• 数据地图：全局数据搜索、表详情
• 数据血缘：表级/字段级血缘关系
• 数据词典：业务术语统一
• 数据质量：质量报告、SLA

三、数据开发层

1. 统一计算引擎：

• 离线计算：Spark SQL
• 实时计算：Flink SQL
• 交互式查询：Presto

2. 开发工具：

• SQL编辑器：在线写SQL、语法检查
• 任务调度：DAG依赖配置
• 版本管理：SQL版本、回滚
• 调试测试：测试环境、数据采样

四、数据服务层

1. 数据API：

• 表自动生成API
• SQL查询API
• 支持分页、条件过滤

2. 数据输出：

• 推送到业务库：MySQL/Elasticsearch
• 数据订阅：Kafka消息推送
• 文件导出：Excel/CSV下载

核心价值：

• 数据统一接入，避免烟囱式开发
• 元数据统一管理，数据可发现可理解
• 开发效率提升，自助式数据分析