企业官网建设流程全解析

简介：面向大数据开发、运维、云计算与数据治理岗位的面试题资料包，围绕Linux与Shell、Hadoop、Zookeeper、Flume、Kafka、Hive、HBase、Sqoop、Scala及Spark等核心知识域组织，适合初中级工程师系统梳理考点，也便于架构师查漏补缺。资源为1个docx文档，压缩包约491KB，按章节与知识点分层编排，目录清晰，便于按模块检索和专项复习。已有882人学习下载，具备一定参考热度。内容不仅罗列问题，还覆盖Hadoop端口与读写流程、MapReduce Shuffle与YARN提交流程、Flume事务与防丢失机制、Kafka分区与副本及数据重复处理、Hive内外表与窗口函数、HBase RowKey设计、Sqoop数据一致性，以及Spark部署模式、宽窄依赖、Stage划分、常用算子、缓存与checkpoint、共享变量和TopN实现等，可帮助读者建立从基础组件到调优排错的完整面试知识框架。

1. 大数据面试的知识地图：从采集到治理的六层链路

这套大数据面试题摊开看，目录本身就是一张数据链路图：最底下是 Linux&Shell 和 Hadoop 打地基，往上是 Zookeeper、Flume、Kafka 组成的协调与采集层，再往上是 Hive、HBase、Sqoop 的数仓工具层，然后是 Spark、Flink 的计算层，最上面压着数仓建模、指标分析、数据治理和项目经验。准备大数据开发、大数据运维、云计算、数据治理、大数据架构师这几类岗位的人，都能在这张图上找到自己的复习重心。反直觉的一点是：题目密度最高的不是某个算子怎么写，而是数据倾斜和项目经验——它们把前面所有组件串成一条能讲出口的链路。ETL 的每个环节、集群的每次抖动、云开发场景下的存储选型，最后都会落回“你为什么这么设计”。

2. 组件底座：Hadoop、Zookeeper、Flume、Kafka 的考点密度与参数

2.1 Linux 与 Shell：把命令挂到排障场景上

面试问 Linux，不是考你背 man 手册，而是给你一个故障现场，看你先敲哪条命令。大数据运维岗尤其吃这一套：集群起不来、任务卡住、磁盘告警，第一步永远是定位而不是重启。把常用命令按场景归类，比按字母顺序背有效得多。

Shell 侧的重点是变量、循环、条件、$?和单双引号。原文专门把“Shell 中单引号和双引号区别”单列一条，说明这是被很多人当成“太基础”而漏掉的点：单引号里一切原样输出，双引号里$、反引号、转义符才生效。写调度脚本时一个引号用错，变量就变成字面量，任务静默失败，这类问题查起来很费时间。

#!/bin/bash # 检查采集进程是否存活，不在则拉起 APP="flume-agent" PID=$(ps -ef | grep "$APP" | grep -v grep | awk '{print $2}') if [ -z "$PID" ]; then echo "$(date) $APP 未运行，准备重启" nohup flume-ng agent -n a1 -c conf -f conf/flume.conf > /dev/null 2>&1 & else echo "$(date) $APP 正常运行，PID=$PID" fi

grep -v grep是为了把 grep 自身的进程排除掉，awk '{print $2}'取第二列 PID，nohup ... &让进程脱离终端。原文还问了“进程号已经不知道了，但需要 kill 掉这个进程怎么办”，标准答案就是先用ps -ef | grep 脚本名反查，再kill -15发优雅终止信号，等几秒不退再kill -9。上来就-9会让正在写文件的任务留下半截数据，这是排障里最常见的二次伤害。

2.2 Hadoop：三条流程加一张参数表

HDFS 写流程要能一口气讲完：客户端向 NameNode 请求创建文件，NameNode 校验权限和目录后返回一批可写 DataNode（按副本数和机架感知排序），客户端与第一个 DataNode 建立 pipeline，按 packet 逐段写入，每个 packet 沿 pipeline 回传 ack，全部写完关闭流并汇报。读流程反过来：客户端拿块位置列表，优先选网络最近的 DataNode，顺序读并做校验和比对。重点不在流程本身，而在异常分支——pipeline 中某个 DataNode 写失败，客户端会剔除它、用剩余副本重建 pipeline，并把失败节点报告给 NameNode 后续补齐副本。

MapReduce 的 Shuffle 是必问项。map 端先把结果写进环形缓冲区（默认 100MB，溢写阈值 0.8），溢写前做分区、排序，可选 combiner 预聚合，多次溢写后 merge 成大文件；reduce 端先 copy 再 merge，最后归并排序交给 reduce 函数。这里容易翻车的是 combiner 的适用条件：求和、求最大值可以用，求平均值直接套会算错，因为 combiner 会改变参与平均的样本数。

YARN 提交流程：客户端提交应用到 ResourceManager，RM 分配一个 Container 启动 ApplicationMaster，AM 再向 RM 申请资源，RM 通知 NodeManager 拉起 Container 跑任务，AM 负责监控和汇报，结束后注销。调度器对比要能张口就来：

优化这块，压缩、小文件、集群参数、数据倾斜四条线要分开答。LZO 压缩单独被原文列成项目经验，原因很实际：LZO 要建索引才能支持切分，不建索引就是一个大文件进一个 map，压缩率省下的 IO 全被并行度抵消。小文件用 har 归档、CombineFileInputFormat 或写入前 merge；集群参数围绕 map/reduce 内存、并行度、JVM 复用展开。

常见端口可以整理成一张排障速查表：

提示：端口以实际配置文件为准，不同发行版默认值会变。面试时说“我环境里配的是多少，写在哪个配置文件里”，比干背数字更可信。

2.3 Zookeeper 与 Flume：选举、事务与“不丢”的边界

Zookeeper 的选举机制要讲清三个状态：LOOKING、LEADING、FOLLOWING。节点投票时先比事务 ID（zxid），zxid 大的优先；zxid 相同再比服务器 ID（myid）。获得过半票数即当选。为什么集群配奇数台，答案藏在容错公式里：n 台节点最多容忍 (n-1)/2 台挂掉，4 台和 3 台的容错能力一样，多出来那台只是浪费。常用命令ls、get、create、set、delete、stat要熟，stat能看到版本号和事务 ID，排查“节点被谁改了”时很有用。

Flume 的核心是三个组件加两个事务。Source 把事件写入 Channel 走 Put 事务：doPut、doCommit，失败则 doRollback；Sink 从 Channel 取事件走 Take 事务：doTake、doCommit，失败回滚。这套事务保证的是 Channel 内部的可靠性，不等于端到端不丢。原文专门问了“Flume 采集数据会丢失吗”，标准答法是分 Channel 类型说：内存 Channel 在进程崩溃或机器掉电时数据直接没了，File Channel 落盘才能扛住；再叠加 sink 重试、batchSize、监控告警，才构成完整的不丢组合。这个点血泪经验很多，一句“Flume 可靠”带过去，追问一句就露底。

FileChannel 的优化方向是：dataDirs指向多块磁盘分摊写压力，checkpointDir单独放一块盘，capacity和transactionCapacity按实际吞吐调，checkpointInterval权衡恢复时间和写放大。HDFS Sink 的小文件问题靠rollInterval、rollSize、rollCount、batchSize四个参数一起调，再配合 Hive 侧的合并参数。拦截器负责过滤和打标，Channel 选择器决定一条事件进哪个 Channel（复制还是多路），监控器上报指标。拦截器里不要做重逻辑，它跑在 Source 线程上，一慢就把整条采集链路拖住。

2.4 Kafka：分区、副本与“不丢不重”的三端链路

Kafka 架构用一句话概括：Producer 写 Broker 上的 Topic，Topic 按 Partition 切分，每个 Partition 有多个 Replica，Leader 负责读写、Follower 负责同步，Consumer Group 内每个分区只被一个消费者消费。Controller 负责分区 Leader 的选举。

容量估算是面试里最能体现工程感的部分：分区数约等于目标吞吐除以单分区吞吐，副本数一般 2 到 3，磁盘总量等于日均消息量乘以副本数再乘以保留天数，最后留 30% 左右冗余。机器数量按磁盘容量和网卡带宽倒推，而不是拍脑袋。原文把“机器数量、日志保存时间、硬盘大小、分区数、副本数、多少个 Topic”并列，本质是同一道容量题的六个面。

不丢数据要按三端答。生产端acks=all加retries加enable.idempotence=true；Broker 端min.insync.replicas至少 2，unclean.leader.election.enable=false，避免落后副本当 Leader 导致数据回退；消费端关闭自动提交，处理完业务再手动提交 offset。三端缺一，链条就断。

Properties props = new Properties(); props.put("bootstrap.servers", "broker1:9092,broker2:9092"); props.put("acks", "all"); // 所有 ISR 确认才算写成功 props.put("retries", 3); // 网络抖动时重试 props.put("enable.idempotence", true); // 幂等，防重试造成重复 props.put("max.in.flight.requests.per.connection", 5); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

acks=all必须和 Broker 端的min.insync.replicas配合才有意义，否则 ISR 只剩一个副本时照样写成功；开启幂等后，max.in.flight建议不超过 5，有序性由幂等机制自身保证。不重复的另一半在消费端：业务表加唯一键、写去重表，或者用事务把“消费 + 提交 offset”绑在一起。

ISR 是与 Leader 保持同步的副本集合，落后超过replica.lag.time.max.ms就被踢出，Leader 挂了只从 ISR 里选新 Leader，这是“不丢”的底层依据。分区分配策略有 Range、RoundRobin、Sticky、CooperativeSticky 几种，Sticky 在均衡的同时尽量减少分区迁移，CooperativeSticky 把再均衡改成增量式，避免全量暂停。消息积压的处理顺序是：先看消费者是不是卡在某个慢逻辑，再看分区数够不够，加消费者不能超过分区数，最后才考虑临时降级非核心处理。Kafka 高效读写靠顺序追加、页缓存、零拷贝和批量压缩，这四个词要能各自展开一句。

3. 数仓工具链：Hive、HBase、Sqoop 的对比、参数与 SQL 手感

3.1 Hive：架构、表类型与 4 个 By 的分工

Hive 架构分四块：客户端（CLI、JDBC）、MetaStore（生产上换成 MySQL）、HDFS 存数据、执行引擎（MR、Tez、Spark）。MetaStore 是整条链路的单点，它挂了所有查询都起不来，所以原文把“元数据备份”放进项目经验里，这不是可选项而是保命项。

Hive 和传统数据库的差别，用一张表说清比背定义快：

内部表和外部表的区别在 drop 行为：内部表删元数据也删数据，外部表只删元数据。外部表适合原始数据和多引擎共享，分区表还要会msck repair table修元数据。4 个 By 是高频题，用表对比最清楚：

窗口函数的执行时机晚于 where 和 group by，所以不能直接写在 where 里过滤，要用子查询包一层。UDF 一进一出、UDTF 一进多出、UDAF 多进一出，这个分类要能各举一个例子。动态分区的底层是按分区字段做目录分发，每个分区一个目录，分区一多就是小文件灾难，所以hive.exec.dynamic.partition.mode=nonstrict之外还要配合并参数。

分隔符的问题很能区分“用过”和“背过”。Hive 默认分隔符是\001（Ctrl-A），用\t是因为可读、和多数导出工具默认一致。字段里本身含\t时，三条路：清洗阶段替换掉、换成多字符分隔符、或者改用支持引号转义的 SerDe。分隔符选错不会报错，只会整列错位，ETL 链路里这种错最难查，因为数据看起来“有值”，只是值不对。

-- 最近 7 天内连续 3 天活跃的用户 with t1 as ( select user_id, dt, date_sub(dt, row_number() over(partition by user_id order by dt)) as grp from dws_user_active_d where dt between date_sub(current_date, 6) and current_date group by user_id, dt ) select user_id from t1 group by user_id, grp having count(1) >= 3;

核心技巧是“日期减行号”：连续日期减去递增行号会得到同一个分组键，断一天分组键就变。先去重再开窗，否则同一天多条记录会把行号顶乱，连续天数就算错。这个模板稍作改动就能答“连续 3 周活跃”“沉默用户”“本周回流”。

3.2 HBase：存储结构与 RowKey 设计

HBase 的存储层级是 Table 按 RowKey 范围切成 Region，Region 内按列族分 Store，每个 Store 由 MemStore 和若干 StoreFile（HFile）组成，写先落 WAL 再进 MemStore，MemStore

本文还有配套的精品资源，点击获取