大数据开发面试题

GaussDB（华为高斯数据库）核心定位是替代 Oracle （关系型数据库 / 企业级数据库），不是替代 Hadoop（分布式大数据平台）

Oracle：OLTP（核心交易）+ OLAP（数据仓库），强事务。被 GaussDB 等国产数据库替代

Hadoop：被 FusionInsight、星环 TDH 等国产大数据平台替代

Hive是关系型数据库吗？

结论先行：Hive 绝对不是关系型数据库。

虽然 Hive 长得像数据库（有数据库、表、字段概念），也能用 SQL 语句查询，但它的本质是一个 **"建立在 Hadoop 之上的数据仓库工具"**。

为了让你彻底理解，我们可以从以下三个维度来对比：

一、核心本质的区别（最关键）

维度	关系型数据库 (如 MySQL/Oracle)	Hive
本质	数据库管理系统 (DBMS)	Hadoop 的客户端工具 / MapReduce 封装器
数据存储	存储在本地磁盘（Block），有自己的存储引擎（如 InnoDB）	存储在 HDFS 上，Hive 本身不存数据，只存表结构（元数据）
执行引擎	自己解析 SQL 并执行（多线程 / 进程）	将 SQL 翻译成 MapReduce / Tez / Spark 任务去执行
运行模式	在线事务处理 (OLTP)	离线分析处理 (OLAP)

通俗比喻：

MySQL 就像一个 **"全能管家"**：他既负责把你的东西（数据）锁在柜子里（存储），又负责帮你找东西（查询），动作非常快。
Hive 就像一个 **"翻译官"**：你不会说 Hadoop 的语言（Java/MapReduce），你用英语（SQL）跟翻译官说话。翻译官把你的话翻译成 Hadoop 能听懂的指令，让 Hadoop 去干活。Hive 自己不干活，也不负责保管东西。

三、Hive 不具备关系型数据库的哪些能力？

不支持事务 (Transaction) ：早期的 Hive 完全不支持 INSERT INTO ... VALUES 这种单行插入，也不支持 UPDATE 和 DELETE（虽然 Hive 0.14 后引入了事务支持，但配置极其繁琐，且性能极差，极少使用）。Hive 主要用于批量加载 （Load）和全表扫描。
不支持实时查询：Hive 的查询延迟很高，通常用于处理 TB/PB 级的历史数据，生成报表。它无法支撑像电商网站那样高并发、低延迟的实时订单查询。
不支持索引 (Index) ：MySQL 可以建 B+Tree 索引加速查询。Hive 虽然也有索引概念，但由于数据量太大，建索引成本极高，通常不建索引，而是靠分区 (Partition) 和 分桶 (Bucket) 来优化。

Hive 是数据仓库 (Data Warehouse)，不是数据库。
Hive 是 SQL 接口，底层是 MapReduce/Spark。
Hive 管理的是 HDFS 上的文件，而不是磁盘上的记录。

什么时候用 MySQL？ 当你需要快速增删改查，处理用户订单、账户信息时。

什么时候用 Hive？ 当你有几亿条日志文件存在 HDFS 上，想分析 "过去一年用户的访问习惯" 时。

关系型数据库遵循的ACID事务特性？

遵循 ACID 事务特性：确保数据操作的安全性和一致性（尤其适用于转账、订单提交等关键场景）：

A（原子性）：事务要么全执行，要么全回滚；
C（一致性）：事务执行前后数据状态合法；
I（隔离性）：多个事务并行执行不相互干扰；
D（持久性）：事务提交后数据永久保存。

明明知道计算的中间结果存储到磁盘上（频繁的IO操作）是很浪费时间的，不如直接存在内存中节省时间，为什么一开始设计MapReduce还是选择把中间过程放到磁盘上？

内存成本与容量的硬限制（最关键）

2000 年代初，内存价格极高且容量极小：当时单 GB 内存价格超过千元（是现在的几十倍），一台服务器的内存普遍只有几 GB（甚至几百 MB），而大数据处理的中间结果往往是 TB 级。如果把中间数据存内存，要么内存完全不够用，要么硬件成本高到企业无法承受。

反观磁盘，当时已经是成熟的大容量存储介质，TB 级硬盘价格远低于内存，且容量可横向扩展，是 "低成本存储海量数据" 的唯一选择。

2.设计目标：面向 "海量离线数据" 的稳定处理 MapReduce 的核心设计目标是「处理 PB 级离线数据」，++优先保证 "稳定性" 和 "可扩展性"，而非 "极致速度"++：

保证稳定性：磁盘存储天然支持数据持久化，即使节点宕机，中间结果不会丢失，可重新计算（内存断电 / 宕机即丢失，当时的容错技术无法支撑大规模内存容错）；
不追求极致的速度：离线处理场景对 "实时性" 要求低（比如 T+1 出报表），磁盘 IO 的延迟可接受，而 "能处理海量数据" 比 "处理得快" 更重要。

3.当时的技术生态限制

2000 年代初，分布式内存管理、容错机制、序列化框架等技术还不成熟：

没有高效的分布式内存共享方案，跨节点内存数据传输成本极高；
内存数据的容错（如节点故障后如何恢复中间结果）没有成熟方案，而磁盘数据的容错可通过副本机制轻松实现。

二、Spark 选内存存储的核心原因（2012 年前后的技术演进）

内存成本大幅下降，容量显著提升2010 年后，内存价格进入 "下降通道"，单 GB 内存价格降至百元内，服务器普遍可配置几十 GB 甚至上百 GB 内存，让 "中间结果存内存" 的硬件成本变得可控。此时，"用内存换速度" 的性价比大幅提升，成为技术上可行、商业上划算的选择。
**计算需求从 "离线" 转向 "准实时 / 迭代计算"**随着大数据应用普及，企业不再满足于 T+1 的离线分析，开始需要：
- 迭代计算（如机器学习算法，需反复读写中间结果）；
- 交互式查询（如分析师实时探索数据）；
- 流处理（如实时监控数据）。这些场景中，MapReduce 的 "磁盘 IO 瓶颈" 被无限放大（比如迭代计算需反复读写磁盘，速度比内存慢几十倍），而 Spark 的内存存储恰好解决了这个痛点。
技术生态的成熟支撑

2012 年前后，分布式内存管理、容错机制、序列化技术已日趋成熟：

Spark 的 "弹性分布式数据集（RDD）" 设计，通过 " lineage（血缘）" 机制实现内存数据的高效容错（无需像磁盘那样存完整副本，只需记录计算路径，故障后可快速重算）；

高效的序列化框架（如 Kryo）减少了内存占用，跨节点内存数据传输效率大幅提升

三、关键结论：不是 "不知道"，而是 "时代选择"

MapReduce 的 "磁盘存储"：是「当时硬件成本、技术生态、业务需求」共同决定的 "最优解"------ 设计者必然知道内存更快，但在 2004 年，"用磁盘换容量、稳定性、低成本" 是处理海量数据的唯一现实选择；
Spark 的 "内存存储"：是「硬件降价、需求升级、技术成熟」后的 "迭代优化"------ 站在 MapReduce 的肩膀上，解决了其在新场景下的性能瓶颈，而非否定其设计逻辑。

简单说：MapReduce 是 "能用"（解决了海量数据处理的从 0 到 1），Spark 是 "好用"（解决了海量数据处理的从 1 到 10），两者都是特定时代背景下的最佳选择。

我在用sqoop迁移数据的过程中，一开始写的是mapreduce的个数是1，成功从MySQL迁移数据到了HDFS上，后来换成了4，就什么数据都迁移不过去了。每个表50条数据，27张表

Sqoop并行化工作原理

当 -m > 1 时，Sqoop需要：

选择一个分割列 （通常是主键，或通过 --split-by 指定）
查询该列的最小值和最大值
将数据范围均匀分配给多个Map任务并行迁移

为什么 -m 1 能成功？

单Map任务不需要分割数据，直接全表扫描迁移
不需要考虑数据分布均衡问题

为什么 -m 4 会失败？

最可能的原因：

场景A：表没有主键，也没有明确指定分割列

复制代码

# 当表没有主键且未指定 --split-by 时，Sqoop无法自动选择分割列
sqoop import \
  --connect jdbc:mysql://host/db \
  --table your_table \
  -m 4  # 失败！

场景B：分割列的数据分布不均或包含NULL值

如果分割列有很多NULL值
如果分割列的值不是均匀分布（如全是0或1）

场景C：分割列的数据类型不适合分割

文本类型的列可能不适合作为分割列
日期类型在某些配置下可能有问题

解决方案

复制代码

sqoop import \
  --connect jdbc:mysql://host/db \
  --table table_name \
  --split-by id \  # 明确指定分割列，通常是主键或整数列
  -m 4

Sqoop 迁移数据（如从 MySQL 到 HDFS/Hive）本质是仅启动 Map 任务，无 Reduce 任务 （除非用--reduce强制，但极少用），Map 任务的作用是：

将源数据库的数据分片，每个 Map 任务处理一部分数据；
单个 Map 任务对应一个数据库连接，并行读取 / 写入数据。

关键结论：Sqoop 的 Map 数 = 数据分片数 = 并行任务数，配置的核心是「让每个 Map 任务处理的数据量适中，同时不压垮源数据库 / 集群」。