简介这是一份面向大数据初学者与转行开发者的系统入门资料围绕Hadoop、Hive、Spark、Storm、Flink、HBase、Kafka、Zookeeper、Flume等主流组件展开覆盖学习路线、技术栈思维导图、常用软件安装指南以及环境搭建、命令实操、集群资源管理、分区、视图与数据查询等核心知识点帮助读者从零建立完整的大数据知识体系。资源包共629个文件以380张png截图、101个md笔记、69个java源码、25个xml配置及scala、properties、json、parquet等文件为主兼顾图文讲解、代码示例与配置参考压缩包约20.75MB目录结构清晰便于按模块检索学习。目前已有155人学习下载适合需要系统梳理技术栈、对照实操与查漏补缺的入门读者。1. 从一堆组件名到一条数据链路这套大数据栈到底怎么串起来很多人第一次看到 Hadoop、Hive、Spark、Storm、Flink、HBase、Kafka、Zookeeper、Flume 这九个名字排在一起第一反应是「这得学到什么时候」。我当年也一样抱着《Hadoop权威指南》啃了两周结果连一个完整的链路都跑不起来。后来才想明白这些组件不是九个独立的技术而是一条数据从产生到落地的完整流水线。Flume 负责把日志收进来Kafka 做缓冲和削峰HDFS 存原始数据Spark 或 Flink 做计算Hive 提供 SQL 查询入口HBase 支撑毫秒级随机读写Zookeeper 在背后协调分布式状态Storm 处理对延迟极度敏感的流。你不需要每个都精通但必须知道它们在链路里的位置否则面试被问「Kafka 和 Flume 有什么区别」就只能背概念。这篇笔记面向的是想把这套栈真正跑起来的人——不管你是刚接触大数据的在校生还是从后端转过来的工程师。我会按「先跑通最小链路再逐个补组件」的思路把伪分布式搭建、集群配置、组件整合、常见翻车点都过一遍。不追求覆盖每个 API但保证你照着做能搭出一套可用的环境并且知道每个参数改了会发生什么。2. 伪分布式起步用最小代价把 Hadoop 和 Zookeeper 跑起来2.1 为什么先搭伪分布式而不是直接上集群直接上三节点集群是新手最容易翻车的地方。网络配置、SSH 免密、时间同步、防火墙任何一个环节出问题都会让你卡半天而且报错信息往往指向错误的方向。伪分布式把所有角色塞在一台机器上用不同端口区分能让你先把配置文件的结构、启动顺序、日志位置搞清楚。等你理解了 NameNode 和 DataNode 怎么通信、Zookeeper 的选举是怎么回事再扩展到多节点就是改几行配置的事。我一般建议用 Docker 跑伪分布式环境隔离干净删掉重来成本极低。下面是一个最小化的 docker-compose 配置包含 Hadoop 和 Zookeeperversion: 3 services: hadoop: image: sequenceiq/hadoop-docker:2.7.1 container_name: hadoop-pseudo ports: - 50070:50070 # NameNode Web UI - 8088:8088 # YARN ResourceManager UI - 9000:9000 # HDFS RPC environment: - HADOOP_HOSTNAMEhadoop-pseudo volumes: - ./hadoop-data:/tmp/hadoop-data command: /etc/bootstrap.sh -d zookeeper: image: zookeeper:3.6 container_name: zk-pseudo ports: - 2181:2181 - 2888:2888 - 3888:3888 environment: ZOO_MY_ID: 1 ZOO_SERVERS: server.10.0.0.0:2888:3888这段配置的逻辑很直接Hadoop 容器暴露三个关键端口50070 是看 HDFS 状态的8088 是看 YARN 任务调度的9000 是客户端连 HDFS 的入口。Zookeeper 的 2181 是客户端连接端口2888 和 3888 分别是 follower 和 leader 选举用的。ZOO_MY_ID在伪分布式下写 1 就行多节点时才需要区分。启动之后先验证 HDFS 是否正常docker exec -it hadoop-pseudo bash hdfs dfsadmin -report如果看到Live datanodes (1)就说明 DataNode 注册成功了。如果显示 0 个节点大概率是core-site.xml里fs.defaultFS配的地址和 DataNode 实际绑定的不一致去/usr/local/hadoop/etc/hadoop/下检查。提示伪分布式环境下最容易忽略的是主机名解析。容器内如果hostname返回的字符串在/etc/hosts里找不到对应 IPNameNode 启动时会报UnknownHostException但日志可能只显示「启动失败」不会直接告诉你原因。2.2 Zookeeper 在 Hadoop HA 里的实际角色单机伪分布式用不到 Zookeeper但一旦你要做 NameNode 高可用Zookeeper 就是绕不开的。它的核心作用不是「存储数据」而是「协调状态」——具体到 Hadoop HA就是通过 ZKFCZookeeper Failover Controller在 Zookeeper 上抢一个临时节点谁抢到谁就是 Active NameNode。配置 HA 时需要在hdfs-site.xml里加这几项property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property nameha.zookeeper.quorum/name valuezk1:2181,zk2:2181,zk3:2181/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /propertyha.zookeeper.quorum填你 Zookeeper 集群的地址列表用逗号分隔。dfs.ha.fencing.methods是脑裂保护——当 Active 节点失联但实际还活着时需要一种机制把它「隔离」掉sshfence 是通过 SSH 登录过去把进程杀掉。生产环境更常用的是基于电源管理的 fencing但测试环境用 sshfence 就够了。这里有个血泪经验Zookeeper 集群的节点数必须是奇数3 个或 5 个。2 个节点的 ZK 集群在其中一个挂掉后无法形成多数派整个 HA 直接失效。我见过有人为了省机器搭了 2 节点 ZK结果比单点还脆弱。3. Hive 和 Spark 的配合从 SQL 到分布式计算的实际路径3.1 Hive 的定位不是数据库是 SQL 到 MapReduce/Spark 的翻译层很多人把 Hive 当 MySQL 用建完表就等查询结果发现一个简单查询跑十分钟。Hive 的本质是把 SQL 翻译成分布式作业它不存储数据数据在 HDFS 上也不做实时计算。理解这一点你才能理解为什么 Hive 要分区、分桶为什么小文件是它的天敌。Hive 的安装配置核心就三件事元数据库通常是 MySQL、HDFS 地址、计算引擎。下面是一个hive-site.xml的关键配置片段property namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://localhost:3306/hive_meta?createDatabaseIfNotExisttrue/value /property property namejavax.jdo.option.ConnectionDriverName/name valuecom.mysql.jdbc.Driver/value /property property namehive.execution.engine/name valuespark/value /property property namehive.exec.dynamic.partition.mode/name valuenonstrict/value /propertyhive.execution.engine改成 spark 后Hive 的查询会走 Spark 引擎而不是 MapReduce速度提升通常在三到五倍。hive.exec.dynamic.partition.mode设为 nonstrict 是开启动态分区写入的前提否则插入分区表时会报错。建表时最常见的 DDL 操作CREATE TABLE IF NOT EXISTS user_behavior ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, ts BIGINT ) PARTITIONED BY (dt STRING, hour STRING) STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY);PARTITIONED BY的字段不能出现在上面的列定义里这是新手常犯的错。STORED AS ORC配合 SNAPPY 压缩是当前比较均衡的选择——ORC 列式存储对分析型查询友好SNAPPY 解压速度快CPU 开销低。3.2 Hive 小文件问题的实际处理手段小文件是 Hive 最经典的性能杀手。每个小文件在 HDFS 上对应一个块NameNode 要维护元数据MapReduce 或 Spark 要为每个文件启动一个 task调度开销远大于实际计算。现象很直观hdfs dfs -count /user/hive/warehouse/xxx看到文件数几万但总大小才几百 MB。处理手段分三个层面。写入时控制SET hive.merge.mapfiles true; SET hive.merge.mapredfiles true; SET hive.merge.size.per.task 134217728; SET hive.merge.smallfiles.avgsize 134217728;这四个参数的含义分别是Map 输出后合并小文件、Reduce 输出后合并、每个合并任务的目标大小128MB、平均文件小于这个值就触发合并。注意这些是会话级参数需要在每次写入前设置或者配到hive-site.xml里全局生效。已经产生的小文件用ALTER TABLE ... CONCATENATE或重写INSERT OVERWRITE TABLE user_behavior PARTITION (dt2024-01-01) SELECT user_id, item_id, category_id, behavior_type, ts FROM user_behavior WHERE dt2024-01-01 DISTRIBUTE BY rand();DISTRIBUTE BY rand()让数据随机分布到不同 reducer避免数据倾斜同时控制输出文件数。这个方法比直接CONCATENATE更可控因为你可以通过SET mapred.reduce.tasksN指定输出文件数量。3.3 Spark 读写 Hive 表的实操配置Spark 和 Hive 整合的关键是把hive-site.xml放到 Spark 的conf目录下或者在代码里指定。用 Spark SQL 读 Hive 表from pyspark.sql import SparkSession spark SparkSession.builder \ .appName(HiveIntegration) \ .config(spark.sql.warehouse.dir, /user/hive/warehouse) \ .config(hive.metastore.uris, thrift://localhost:9083) \ .enableHiveSupport() \ .getOrCreate() df spark.sql(SELECT behavior_type, COUNT(*) AS cnt FROM user_behavior WHERE dt2024-01-01 GROUP BY behavior_type) df.show()hive.metastore.uris指向 Hive Metastore 服务地址端口默认 9083。enableHiveSupport()是必须的否则 Spark 不认识 Hive 表。如果报Table or view not found先检查 Metastore 服务是否启动再确认hive-site.xml是否在 Spark 的 classpath 里。写回 Hive 时注意分区字段的顺序df.write.mode(overwrite).partitionBy(dt, hour).format(orc).saveAsTable(user_behavior_agg)partitionBy的字段顺序要和 Hive 表定义的分区顺序一致否则数据会写到错误的分区目录下查询时找不到。4. Kafka、Flume、Flink 的流式链路从数据采集到实时计算4.1 Flume 采集日志到 Kafka 的配置要点Flume 的定位是「数据搬运工」它不处理数据只负责把数据从 A 搬到 B。典型场景是采集应用日志文件写到 Kafka 做缓冲。一个可用的flume-kafka.confa1.sources r1 a1.sinks k1 a1.channels c1 a1.sources.r1.type TAILDIR a1.sources.r1.filegroups f1 a1.sources.r1.filegroups.f1 /var/log/app/.*\.log a1.sources.r1.positionFile /var/lib/flume/taildir_position.json a1.channels.c1.type memory a1.channels.c1.capacity 10000 a1.channels.c1.transactionCapacity 1000 a1.sinks.k1.type org.apache.flume.sink.kafka.KafkaSink a1.sinks.k1.kafka.bootstrap.servers kafka1:9092,kafka2:9092 a1.sinks.k1.kafka.topic app-logs a1.sinks.k1.kafka.flumeBatchSize 500 a1.sinks.k1.kafka.producer.acks 1 a1.sources.r1.channels c1 a1.sinks.k1.channel c1TAILDIR比EXEC更可靠它记录文件读取位置到positionFile重启后从断点继续。capacity和transactionCapacity的比例建议 10:1太小会导致频繁刷写太大则故障时丢数据更多。acks1表示 leader 写入成功即返回兼顾吞吐和可靠性如果业务不能丢数据改成acksall。4.2 Flink 消费 Kafka 并写入 MySQL 的完整代码Flink 的 JDBC 连接器异常是热搜里高频出现的问题核心原因通常是驱动版本不匹配或连接池配置不当。下面是一个从 Kafka 读数据、做简单转换、写入 MySQL 的完整示例StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(); env.enableCheckpointing(5000); KafkaSourceString source KafkaSource.Stringbuilder() .setBootstrapServers(kafka1:9092) .setTopics(app-logs) .setGroupId(flink-consumer-group) .setStartingOffsets(OffsetsInitializer.latest()) .setValueOnlyDeserializer(new SimpleStringSchema()) .build(); DataStreamString stream env.fromSource(source, WatermarkStrategy.noWatermarks(), Kafka Source); DataStreamTuple2String, Integer counts stream .flatMap(new FlatMapFunctionString, Tuple2String, Integer() { Override public void flatMap(String value, CollectorTuple2String, Integer out) { for (String word : value.split(\\s)) { out.collect(Tuple2.of(word, 1)); } } }) .keyBy(t - t.f0) .sum(1); counts.addSink(JdbcSink.sink( INSERT INTO word_count (word, cnt) VALUES (?, ?) ON DUPLICATE KEY UPDATE cnt ?, (ps, t) - { ps.setString(1, t.f0); ps.setInt(2, t.f1); ps.setInt(3, t.f1); }, JdbcExecutionOptions.builder() .withBatchSize(1000) .withBatchIntervalMs(200) .withMaxRetries(3) .build(), new JdbcConnectionOptions.JdbcConnectionOptionsBuilder() .withUrl(jdbc:mysql://mysql-host:3306/test_db?useSSLfalse) .withDriverName(com.mysql.cj.jdbc.Driver) .withUsername(root) .withPassword(password) .build() )); env.execute(Kafka to MySQL Job);enableCheckpointing(5000)开启每 5 秒一次的检查点这是 Flink 保证 exactly-once 语义的基础。JdbcExecutionOptions里的batchSize和batchIntervalMs控制写入频率——太小会导致频繁连接数据库太大则延迟高且故障时重放数据多。withMaxRetries(3)是必须的网络抖动时没有重试会直接导致任务失败。JDBC 连接器最常见的异常是No suitable driver found原因几乎都是 MySQL 驱动 jar 没放到 Flink 的lib目录下。Flink 1.13 之后推荐用flink-connector-jdbc而不是自己写RichSinkFunction前者内置了连接池和重试逻辑。4.3 Spark Streaming 和 Flink 的选型边界两者都能做流处理但设计哲学不同。Spark Streaming 是微批micro-batch最小延迟在秒级Flink 是真正的流式延迟可以到毫秒级。选型时看三个维度延迟要求、状态管理复杂度、团队技术栈。如果延迟要求是分钟级比如每 5 分钟统计一次订单量Spark Streaming 完全够用而且能和 Spark SQL 共用代码。如果需要事件级处理比如实时风控、异常检测Flink 的事件时间和窗口机制更合适。状态管理方面Flink 的KeyedState和OperatorState比 Spark 的updateStateByKey更灵活但学习曲线也更陡。我一般建议新项目如果团队没有流处理经验先从 Spark Structured Streaming 入手API 更友好调试方便。等遇到延迟瓶颈或需要复杂事件处理时再迁移到 Flink。5. 避坑与排查那些让你加班到凌晨的配置问题5.1 HDFS 写入报错「Could not obtain block」现象客户端写 HDFS 时卡住日志显示Could not obtain block最终超时失败。原因DataNode 磁盘满了或者 DataNode 进程虽然活着但无法写入数据目录。也可能是dfs.datanode.du.reserved配置的保留空间过大导致实际可用空间为 0。解决先hdfs dfsadmin -report看各节点的剩余空间。如果是磁盘满清理/tmp或旧日志。如果是保留空间问题调小dfs.datanode.du.reserved默认 10GB小磁盘环境要改。改完配置需要重启 DataNode。5.2 Hive 查询报「Vertex failed, vertexNameMap 1」现象Hive on Tez 或 Hive on Spark 执行时任务卡在某个 vertex 然后失败。原因大概率是数据倾斜。某个 key 的数据量远超其他 key导致一个 task 处理了 90% 的数据内存溢出后失败。解决先看日志里哪个 task 耗时最长确认倾斜的 key。如果是 group by 导致的开启hive.groupby.skewindatatrueHive 会自动做两阶段聚合。如果是 join 导致的把大表放右边小表放左边或者用MAPJOIN提示。极端情况下需要手动拆分倾斜 key 单独处理。5.3 Kafka 消费者组 rebalance 导致重复消费现象Flink 或 Spark Streaming 任务运行中突然报CommitFailedException然后部分数据被重复处理。原因消费者处理单条消息时间超过了max.poll.interval.ms默认 5 分钟被协调者踢出组触发 rebalance。新加入的消费者从上次提交的 offset 开始消费导致重复。解决调大max.poll.interval.ms和max.poll.records减少单次拉取量。更根本的办法是优化处理逻辑避免单条消息处理时间过长。如果业务允许把 offset 提交方式改成异步提交减少提交等待时间。5.4 Flink 任务 Checkpoint 超时失败现象Flink Web UI 上 Checkpoint 一直显示In Progress最终超时失败任务不断重启。原因状态太大导致 Checkpoint 写入 HDFS 时间过长或者反压backpressure导致 barrier 对齐慢。也可能是 Checkpoint 目录权限问题。解决先看反压指标如果某个算子反压高说明下游处理不过来需要加并行度或优化逻辑。如果是状态太大考虑用 RocksDB 状态后端代替内存状态后端并开启增量 Checkpoint。权限问题检查state.checkpoints.dir目录是否对 Flink 运行用户可写。5.5 Spark 任务报「Container killed by YARN for exceeding memory limits」现象Spark on YARN 任务运行中 executor 被杀日志显示内存超限。原因spark.executor.memoryOverhead设置太小。Spark 的内存模型里executor 内存分堆内和堆外堆外用于 JVM 元空间、网络缓冲等。默认 overhead 是 executor 内存的 10%但实际使用中往往不够。解决把spark.executor.memoryOverhead调到 512MB 或 1GB。同时检查是否有数据倾斜导致单个 task 内存暴涨。如果是 PySparkPython 进程的内存也算在 overhead 里需要额外留余量。6. 用 DistCp 做跨集群迁移时我踩过的三个参数坑跨集群迁移数据是运维常态Hadoop 自带的 DistCp 是最常用的工具。但它的参数设计有些反直觉的地方我在这上面翻过车这里把经验摊开说。第一个坑是-m参数。默认 DistCp 会启动 20 个 map 任务很多人觉得调大能加速直接设成 100。结果目标集群的 NameNode 被大量并发写入打挂。-m控制的是同时运行的 map 数不是总任务数。合理值取决于目标集群的承载能力一般建议不超过目标集群 DataNode 数量的 2 倍。我现在的习惯是先跑一个小目录测试观察 NameNode 的 RPC 队列长度再决定-m的值。第二个坑是-delete和-update的组合。-update只复制源端比目标端新的文件-delete删除目标端有但源端没有的文件。这两个参数一起用可以实现增量同步但有个致命问题如果源端某个文件正在写入DistCp 复制到一半下次运行时该文件在源端已经更新-update会重新复制整个文件而-delete不会删除目标端的旧版本导致目标端出现两个版本的文件。正确做法是配合-append或者用-diff做快照对比。第三个坑是带宽控制。-bandwidth参数单位是 MB/s但它是 per-map 的。如果你设了-bandwidth 10并且-m 20总带宽就是 200MB/s。很多人只记得设-bandwidth忘了-m的影响结果把交换机端口打满影响其他业务。我一般会算一下总带宽上限除以-m得到每个 map 的带宽值。验证迁移是否完整不要只看 DistCp 的退出码。退出码为 0 只表示没有致命错误但可能有部分文件因为权限或磁盘问题被跳过。我习惯用hdfs dfs -count对比源端和目标端的文件数和总大小再用hdfs dfs -checksum对关键文件做校验。如果文件数不一致去 DistCp 的日志里搜SKIP或FAIL关键字。最后说一个习惯任何跨集群操作前先在目标集群建一个临时目录做小规模测试确认权限、网络、NameNode 负载都正常后再全量跑。这个习惯帮我省了至少三次回滚的麻烦。希望帮到你。本文还有配套的精品资源点击获取