企业官网建设流程全解析

简介：这是一份面向大数据初学者打造的综合性实践资源，围绕Hadoop生态与Spark实时计算整理出完整学习路径，涵盖HDFS、集群搭建、电商日志分析、流处理与数据可视化等典型场景，从环境配置、基础语法到项目实战循序渐进，帮助零基础读者快速建立从理论到实操的认知。压缩包约5.23MB，共224个文件，以Java和Scala源码为主（分别约98个和69个），同时包含XML、Properties等配置文件、Python辅助脚本、HTML/JS可视化页面及CSV/Data数据集，其中源码对应各项目核心逻辑，配置与脚本负责环境与数据处理，可视化文件则用于结果展示，覆盖数据采集、处理、展示多个环节。已有80人学习。资源内含电商日志分析、Spark实时流处理、集群搭建教程和可视化案例，配套可运行的数据集与ECharts展示页面，能从环境部署、代码调试到结果呈现提供完整实操演练，适合按路径逐步攻克大数据入门难点，也适合作为课程设计与毕业设计的参考资料。

1. 这一份大数据项目集合，先把学习顺序理清再动手

解压这份大数据学习与实践项目集合，新手最容易卡住的不是没资料，而是文件夹太多，不知道先双击哪一个。标题里其实已经把完整路线排好了：Hadoop 负责把集群和存储搭起来，HDFS 承接日志数据；电商日志分析是离线批处理的练兵场；Spark 实时流处理补上实时链路；最后用数据可视化把结果摆到页面上。这条路径恰好对应大数据开发岗位最常被问的四块：集群部署、HDFS 读写、离线计算、实时计算。

适合三类人：准备大数据毕业设计的在校生、投大数据开发岗的面试者、自学 Hadoop 和 Spark 但始终没跑通完整链路的新手。我的建议是先搭集群、再存数据、后写计算、最后做展示，这个顺序不要乱。集群起不来，后面所有分析都是空中楼阁。

2. Hadoop 集群搭建手册：从伪分布式到 3 节点的落地路径

2.1 伪分布式、完全分布式还是 docker 镜像：先按目标选型

搭建集群是所有后续环节的地基，这里先花几分钟把方案选对，能省下后面一整天的排错时间。常见做法有三种：伪分布式、完全分布式、docker 镜像。伪分布式指在一台机器上同时跑 NameNode、DataNode、SecondaryNameNode 三个进程，Hadoop 伪分布式搭建教程大多从这里起步，因为能花最少资源把「上传—存储—读取」这条链路完整走通。完全分布式才是生产形态，角色分散到多台机器，副本数、容错、负载均衡都按真实集群来。docker 镜像是折中方案：宿主机资源够的话，一条命令起多个容器模拟多节点，比虚拟机轻，也比伪分布式更接近真实部署。

选型要看你的目标和机器。如果目标是第一遍跑通 HDFS 常用命令、让示例分析能出结果，伪分布式足够，4G 内存的笔记本就能跑。如果目标是面试时能把大数据集群部署策略讲清楚，或者毕设需要截图多节点架构图，那就上 3 节点完全分布式，三台虚拟机或者三个 docker 容器都行。我一般建议的顺序是：先用伪分布式跑通，再花半天把同样步骤复制到多节点上，这样踩坑最少，知识点还能复用。别一上来就开五台机器，配置出问题你根本分不清是网络、免密、还是角色分配的问题。

2.2 从零开始 Hadoop 安装与配置：伪分布式的最小命令集

伪分布式的安装与配置其实不需要太多文件，核心就三个动作：配环境变量、写两个 XML、格式化后启动。前置条件先确认 JDK 8 已装好，JAVA_HOME 没配的话后续脚本会直接报错。

# 环境变量追加到 ~/.bashrc，Hadoop 2.x/3.x 都适用 export HADOOP_HOME=/opt/hadoop export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin # 首次格式化文件系统，只在第一次部署时执行 hdfs namenode -format # 启动 HDFS 守护进程：NameNode、DataNode、SecondaryNameNode start-dfs.sh # 用 jps 确认三个进程都活着，缺一个都说明配置有问题 jps

启动之前还要改两个文件。core-site.xml 里加fs.defaultFS，值设为hdfs://localhost:9000，这是客户端读写 HDFS 的入口地址。hdfs-site.xml 里把dfs.replication设为 1，因为伪分布式只有一台节点，副本数大于 1 会一直触发副本不足告警。格式化这条命令容易翻车，它会在 name 目录下生成current/VERSION文件，里面存着 clusterId，之后 DataNode 启动时要核对这个 ID。格式化只需要执行一次，第二次以后再用，很可能把元数据搞乱，具体表现和解决方式放到后面避坑章说。

start-dfs.sh会按顺序拉起 NameNode、DataNode、SecondaryNameNode 三个进程，看到jps输出里有这三项才算启动成功。只看到 NameNode 没有 DataNode，十有八九是格式化或数据目录配置出了问题；只看到 Java 进程名但没有具体角色，通常是环境变量没生效，logout 重进或者 source 一下.bashrc再试。

2.3 扩展到 3 节点完全分布式：workers 文件、免密登录与副本数调整

从伪分布式扩到完全分布式，不是把同样的配置复制三份就行，角色要重新划分。三台机器比较紧凑的分配方式如下：

常见做法是让 node1 当主节点，node2 和 node3 当从节点。机器数量多的话可以把 SecondaryNameNode 单独拆出去，三节点时放主节点上只是省机器，不影响学习。

# 1. 在 node1 上配置 workers 文件（Hadoop 3.x 叫 workers，2.x 叫 slaves） printf "node2\nnode3\n" >> $HADOOP_HOME/etc/hadoop/workers # 2. 配置免密登录：三台机器分别执行 ssh-keygen -t rsa -P "" ssh-copy-id node1 ssh-copy-id node2 ssh-copy-id node3 # 3. 首次连接会提示确认指纹，手动连一次顺便看看能不能通 ssh node2 hostname ssh node3 hostname # 4. 统一格式化前，先确认 node2/node3 的 data 目录是空的 hdfs namenode -format start-dfs.sh

workers 文件里写了谁，NameNode 启动时会尝试在这些机器上拉起 DataNode。注意不要写 node1，否则主节点上同时跑 NameNode 和 DataNode，架构上会很混乱。ssh-keygen 生成密钥后，ssh-copy-id会把公钥分发到目标机器的 authorized_keys 里，之后 start 脚本才能免密远程启动进程。第一次手动 ssh 连接很重要，它会帮你把 known_hosts 写对，跳过这一步，后面脚本可能因为指纹确认而卡住。

完全分布式格式化前必须确认所有节点的 data 目录都是空的。如果 node2 或 node3 之前跑过伪分布式，目录里残留了旧的 clusterId，启动时 DataNode 会报Incompatible clusterIDs，表现为 jps 里进程存在但集群状态异常，后面避坑章专门讲。dfs.replication在完全分布式里要改成 2，这样任何一台 DataNode 宕机，数据块还有另一份副本可以读。集群启动后可以用hdfs dfsadmin -report查看节点数量和容量，看到 2 个 live datanode 才算真正起来了。

不想开三台虚拟机的话，常见做法是用 docker 镜像，每个容器代表一个节点，容器之间用同一个 network 互通。有一个坑要注意：容器重启后元数据会丢，因为 namenode 和 datanode 的数据目录默认写在容器层里，容器一销毁数据就没了。启动时一定要用-v把 name 目录和 data 目录挂载到宿主机磁盘上，否则 stop 之后再 start，整个集群回到刚格式化的状态，之前的日志数据全消失。

3. HDFS 上跑通电商日志分析：目录规划、常用命令与第一个 MapReduce

3.1 HDFS 读写流程：上传慢和数据丢失都发生在哪一环

先把 HDFS 读写流程讲清楚，后面分析日志时你才知道数据是怎么落盘的，排查问题也有方向。写入流程大致是：客户端向 NameNode 发起写请求，NameNode 返回可用的 DataNode 列表和 block 分配方案；客户端按 pipeline 把第一个 block 发给第一个 DataNode，第一个 DataNode 边收边转发给第二个，第二个再转发给第三个；全部写完，逐级返回确认。所以三个副本不是由 NameNode 复制出来的，而是管道式串行转发，这也是大文件写慢的主要来源之一。读取流程更简单，客户端拿到 block 位置清单后，优先读本机或同机架的副本，这就是「就近读取」策略。

参数上需要盯两个值。block 默认 128M，超过 128M 的文件会被切成多个 block 分布在不同节点；dfs.replication控制每个 block 的副本数。新手最容易踩的坑是小文件问题：一个空文件也要占一条元数据记录，NameNode 的堆内存是按文件数和 block 数估的，几百万个小文件能直接把内存吃满。所以后面建日志目录时，我特意按天分区，而不是按小时建一堆小文件目录。

写入失败的常见现象是上传报错但本机磁盘还有空间，这种情况多半是副本数大于 DataNode 数量，或者某个 DataNode 写满了。用hdfs dfsadmin -report先看节点状态，再去看对应节点的 datanode 日志，比盲目调参有用得多。

3.2 用 HDFS 常用命令组织电商日志目录：先分区再上传

日志数据落到 HDFS 之前，先规划目录层级。常见做法是按/logs/ecommerce/日期建目录，日期可以精确到天，因为电商日志的分析维度基本都到天或小时。目录层级就是后续 Hive 分区表或 Spark 分区读取的物理基础，按天建目录的好处是查询可以只扫某一天的数据，不用全表扫描，要压着整份压缩包里的学习路径走，这个习惯从第一天就要养成。

# 建立日期分区目录，按天存日志 hdfs dfs -mkdir -p /logs/ecommerce/2025/03/10 # 上传当天日志，注意本机路径要写对 hdfs dfs -put /tmp/access_20250310.log /logs/ecommerce/2025/03/10/ # 验证文件是否真的写进去了，看大小和块分布 hdfs dfs -ls -R /logs/ecommerce/2025/03/10 hdfs dfs -du -h /logs/ecommerce/2025/03/10 # 检查某个路径下的块健康状态 hdfs fsck /logs/ecommerce/2025/03/10 -files -blocks

这些 HDFS 常用命令里，mkdir -p和put是每天都要用的。du -h用来确认上传后的实际大小，如果上传前后大小不一致，先检查是不是在客户端做了压缩。fsck可以看到每个文件的 block 分布和副本状态，适合用来验证 3 节点集群的副本是否真的生效。

fsck 有一个常见报错是权限不足，普通用户执行会提示 Access denied。原因是 fsck 属于 NameNode 内部操作，默认只有 hdfs 超级用户或配置了对应权限的用户才能执行。解决方式是切换到 hdfs 用户执行，或者把当前用户加进 supergroup 用户组；如果你用的是某些云发行版，还需要在 hdfs-site.xml 里确认相关鉴权参数没被改成强制校验。新手阶段用hdfs dfsadmin -report也能看节点状态，没必要死磕 fsck。

3.3 电商日志分析的核心指标与 MapReduce 最小实现：PV、UV 一个 job 算完

日志分析先定指标。电商场景最基础的两个指标是 PV 和 UV，PV 是总访问次数，一行日志算一次；UV 是去重后的用户数，按 user_id 去重。这里约定日志格式为timestamp|user_id|item_id|action，例如2025-03-10 10:00:01|u1001|p2002|view。

用 MapReduce 实现时，思路是 mapper 做字段切分，reducer 做聚合。mapper 输出user_id → 1，因为 MapReduce 的 shuffle 阶段会按 key 排序并分组，相同 user_id 的行会连续进入同一个 reducer，所以 reducer 里只需要判断「当前 user_id 和上一个 user_id 是否相同」，就能把 UV 算出来。

# mapper.py：把日志切成字段，输出 user_id 加计数 import sys for line in sys.stdin: parts = line.strip().split("|") if len(parts) < 4: continue # 脏数据直接跳过 ts, user_id, item_id, action = parts print(f"{user_id}\t1")

# reducer.py：按 user 聚合，统计 PV 和 UV import sys pv = 0 # 总访问次数 uv = 0 # 去重用户数 last_user = None # 记录上一个 user_id for line in sys.stdin: line = line.strip() if not line: continue user_id, _ = line.split("\t") pv += 1 # 每行访问计一次 PV if user_id != last_user: # 遇到新用户则 UV 加一 uv += 1 last_user = user_id print(f"PV\t{pv}") print(f"UV\t{uv}")

# 用 Hadoop Streaming 提交 Python 脚本到集群执行 hadoop jar $HADOOP_HOME/share/hadoop/tools/lib/hadoop-streaming-*.jar \ -input /logs/ecommerce/2025/03/10 \ -output /output/pv_uv_20250310 \ -mapper "python3 mapper.py" \ -reducer "python3 reducer.py" \ -file mapper.py -file reducer.py

Streaming 模式下，-file会把脚本分发到每个 NodeManager 的本地工作目录，没有这个参数，节点上找不到 mapper 和 reducer 文件，任务会直接失败。-input指向目录时会递归读取目录下所有文件，-output目录必须不存在，否则会报AlreadyExists错误，跑第二次前先删掉上次输出。

mapper 里len(parts) < 4的过滤很重要，日志里经常有空行或字段缺失的记录，不过滤的话 reducer 端会因为解包失败而报错。reducer 的统计逻辑依赖一个前提：相同 user_id 的行必然连续到达，这是 MapReduce 分组机制保证的。你不需要在 reducer 里维护一个大 HashMap 去重，这是 MapReduce 和普通 Python 脚本最大的思维差异。

跑完后去 HDFS 上 cat 输出文件：hdfs dfs -cat /output/pv_uv_20250310/part-00000，看到两行结果就说明这个电商日志分析的最小链路通了。生产上这些指标更多用 Hive SQL 写，一行count(distinct user_id)就结束了，MapReduce 的价值在于让你理解分组和聚合发生在哪个阶段，面试被问到hadoop 电商日志分析项目时，能把这个过程讲清楚比背 SQL 有用得多。

4. Spark 实时流处理：从内存计算到 Streaming 最小案例

4.1 Spark 集群搭建和内存模型：为什么学了 Hadoop 还要学 Spark

MapReduce 最大的痛点是每个 stage 的中间结果都要落盘，遇到迭代式计算，每轮都要重新读写磁盘，性能损耗很大。Spark 基于 RDD 和 DataFrame 的 lineage 机制，同一份数据可以在内存里反复计算，只有真正需要 shuffle 或落盘时才碰磁盘。所以这份项目集合里既有 Hadoop 又有 Spark，是典型的分工：HDFS 负责存储，Spark 负责计算和实时流处理。

Spark 集群搭建最常见的是 Standalone 模式，不需要依赖 YARN 的复杂配置。conf 目录下改spark-env.sh，设置SPARK_MASTER_HOST和SPARK_EXECUTOR_MEMORY，然后配好 workers 文件，start-all.sh就能把 master 和 worker 拉起来。很多教程默认用local[N]模式起步，本地模式只有一个 JVM 进程，适合验证逻辑，但面试时你最好能说清 Standalone 和 YARN 两种部署方式的区别。

内存参数是新手最容易忽略的。spark.executor.memory默认只有 1G，本地处理稍大的数据集时很容易 OOM；spark.sql.shuffle.partitions默认 200，本地测试数据量小的时候建议调成 8 到 16，否则每个 task 只处理几条记录，大部分时间耗在任务调度上，白白浪费时间。这两个参数的调法没有标准答案，按数据量试就行，任务跑起来后去 Spark UI 看每个 stage 的 task 数和处理时间，比瞎猜靠谱。

4.2 本地跑通 Spark 实时流处理最小案例：socket 流统计词频

实时流处理不需要一开始就上 Kafka，本地用 socket 就能模拟一个实时数据源。下面这个案例会启动一个流作业，监听 9999 端口，把你手动输入的每一行日志按字段切分后实时统计。

# streaming_wordcount.py from pyspark.sql import SparkSession from pyspark.sql.functions import split, explode spark = SparkSession.builder \ .appName("EcommerceStream") \ .getOrCreate() # 读 socket 文本流，一行一条数据 lines = spark.readStream.format("socket") \ .option("host", "localhost") \ .option("port", 9999) \ .load() # 按 "|" 切分后展开成单词，这里为了演示简单直接按词频统计 words = lines.select(explode(split(lines.value, "\\|")).alias("word")) counts = words.groupBy("word").count() # 把结果打印到控制台，生产环境会换成 Kafka 或 JDBC sink query = counts.writeStream.outputMode("complete") \ .format("console") \ .option("truncate", "false") \ .start() query.awaitTermination()

# 终端一：启动一个 nc 在 9999 端口发数据 nc -lk 9999 # 终端二：提交 Spark 作业，local[2] 表示本地起 2 个线程 spark-submit --master local[2] streaming_wordcount.py

local[2]至少要有 2 个线程，Structured Streaming 内部需要一个线程接收数据，另一个线程做计算，只写local[1]的话作业能提交但可能一直不出结果，这是不少新手第一次跑流处理时遇到的怪现象。outputMode("complete")表示每次触发都把全量聚合结果输出一遍，因为这里没有 watermark 和状态清理，用append模式启动时会直接报错。

在 nc 终端里输入几行模拟日志，终端二的控制台会周期性刷新统计结果。这个案例虽然简单，但把流处理的核心链路走通了：数据源 → 无界表 → 聚合 → sink。生产上把format("socket")换成format("kafka")，再配上 topic 和 bootstrap.servers 就能接真实数据。你也可以用 Spark 实时流处理来做实时热门商品排行，原理一模一样，把groupBy("word")换成groupBy("item_id")就行。

4.3 流计算结果的落点：写出到外部存储与 spark 读取 json 的坑

流计算结果只打到控制台肯定不够，真实项目里要落到外部存储供业务系统读取。常见做法是writeStream输出到 Kafka、JDBC 或文件系统，比如按天输出 parquet 文件到 HDFS，或者写入 MySQL 供数据可视化后端查询。写入 MySQL 时要注意 JDBC 链接参数，url里要带useSSL=false和characterEncoding=utf8，否则中文日志写进去会乱码。

Spark 读取 json 是新手绕不过去的一道坎。日志流里最常见的场景是 value 字段是一整段 JSON 字符串，直接用df.select("value")拿到的不是结构化字段，需要配合from_json解析：

from pyspark.sql.functions import from_json, col # 手动定义 schema，字段名和类型必须和日志一致 schema = "ts string, user_id string, item_id string, action string" # 把 value 字符串解析成结构体，再展开成列 logs = lines.select(from_json(col("value"), schema).alias("log")) logs = logs.select("log.*")

这里最大的坑是 schema 推断。如果日志里的字段名和定义对不上，Spark 不会报错，而是把对应字段悄悄置成 null，你检查数据时只看到一片空值，很难定位到底是解析问题还是数据问题。流处理里这种「静默 null」最让人头疼，因为作业不报错，监控也不告警，数据却全丢了。经验是：解析 json 前，先抽样几条原始数据，肉眼确认字段名和类型，再写死 schema。黑匣子一样的静默失败，别指望日志帮你排查。

5. 新手避坑与常见问题排查：集群起不来、任务挂住的 5 个检查点

5.1 集群搭建阶段的三个高频坑

坑一：格式化后发现 DataNode 起不来。

现象：start-dfs.sh后jps看不到 DataNode，查看日志报Incompatible clusterIDs。原因：之前伪分布式或单节点模式跑过，格式化操作执行了多次，导致 NameNode 和 DataNode 各自持有不同的 clusterId。解决：先把集群停掉，删除dfs.namenode.name.dir和dfs.datanode.data.dir指向的目录，用rm -rf清掉旧数据，再执行一次hdfs namenode -format，最后重新 start。记住格式化命令只跑一次，之后别再手痒执行，这是 Hadoop 集群搭建里最常见的翻车点。

坑二：节点间 SSH 免密失效，脚本静默跳过从节点。

现象：start 脚本只在主节点上成功，node2 和 node3 的进程没起来，控制台也不报错。原因：ssh-copy-id之后直接跑启动脚本，known_hosts 里没有目标节点的指纹，SSH 交互式确认卡住了脚本。解决：先手动执行ssh node2 hostname和ssh node3 hostname，确认能免密登录，再跑start-dfs.sh。另外检查~/.ssh/authorized_keys的权限是否被改过，权限必须是 600 或 644，权限过宽会导致 SSH 直接拒绝用这个文件。

坑三：docker 容器重启后，HDFS 数据全部丢失。

现象：docker 方式搭建的集群，stop 之后再 start，hdfs dfs -ls /变成空目录，或者 NameNode 直接起不来。原因：namenode 和 datanode 的数据目录写在容器层，容器销毁后数据跟着没了。解决：启动容器时用-v把 name 目录和 data 目录挂载到宿主机磁盘，例如-v /data/hdfs/name:/opt/hadoop/data/name。格式化之前先确认挂载成功，否则格式化写到容器层，重启照样丢。

5.2 数据处理阶段的三个高频坑

坑四：磁盘明明有空间，上传文件却报空间不足。

现象：hdfs dfs -put时报NotEnoughReplication或空间不足，但df -h看磁盘还有很多空闲。原因：HDFS 校验的剩余空间不是简单看磁盘总量，dfs.datanode.du.reserved参数会保留一部分空间给系统进程，或者副本数大于当前可用 DataNode 数量。解决：先用hdfs dfsadmin -report看每个 DataNode 的剩余空间和配置的副本数，再确认dfs.replication是否大于节点数。伪分布式集群副本数设为 1 就不会报这个错，三节点集群副本数设为 2 是下限。

坑五：Spark 流作业能提交，但控制台一直不出结果。

现象：spark-submit提交成功，Sparks UI 里能看到作业，但 console sink 没有任何输出。原因一：local[N]的 N 设为 1，接收线程和计算线程抢同一个线程，数据进来了但没资源处理。原因二：socket 数据源没连上，nc 没启动或端口不一致。解决：local[2]是最低配置；先确认 nc 在监听，用nc -lk 9999启动后在终端输入数据，再看流作业日志里有没有收到数据的记录。这个坑特别容易让人怀疑代码写错了，实际上就是线程数和数据源的问题。

坑六：spark 读取 json 全部变成 null。

现象：from_json解析后，.select("log.*")展开的字段全为 null，流作业不报错。原因：schema 里声明的字段名和实际日志里的 key 对不上，比如日志里是user_id，schema 里写成userid。Spark 遇到不匹配不会抛异常，而是按 null 处理。解决：先用spark.read.json读一份原始数据，.printSchema()看推断结果，再照着写死 schema。血的教训：写流处理时，先花两分钟确认输入数据的 schema，能省掉两小时的无效排查。

6. 把 Spark Streaming 结果接进 ECharts：一个最小可视化和数据口径验证闭环

6.1 最小闭环：MySQL 落库 + Flask 出 JSON + ECharts 出柱状图

数据可视化案例落到项目里，最常见的技术方案是 ECharts 加后端接口，不需要自己画 canvas。整体套路是：Spark 流计算结果周期性写入 MySQL，后端只负责读库转 JSON，前端 fetch 之后渲染图表。下面给一个最小实现，前端用一个柱状图展示 PV 和 UV。

<!-- echarts 最小柱状图 --> <div id="chart" style="width: 800px; height: 400px;"></div> <script src="https://cdn.jsdelivr.net/npm/echarts@5"></script> <script> fetch("/api/pv_uv") .then(r => r.json()) .then(data => { const chart = echarts.init(document.getElementById("chart")); chart.setOption({ xAxis: { type: "category", data: ["PV", "UV"] }, yAxis: { type: "value" }, series: [{ type: "bar", data: [data.pv, data.uv] }] }); }); </script>

# 可视化后端接口：只读库，不做任何计算 from flask import Flask, jsonify import pymysql app = Flask(__name__) @app.route("/api/pv_uv") def pv_uv(): conn = pymysql.connect( host="localhost", user="root", password="123456", db="bigdata", charset="utf8mb4" ) cur = conn.cursor() cur.execute("select metric, value from t_pv_uv where dt=current_date()") data = {k: v for k, v in cur.fetchall()} conn.close() return jsonify(data)

这个接口只服务可视化，不要在接口层做聚合计算，UV 和 PV 必须在离线层或流处理层算好，接口越薄越好。刷新频率上，大屏展示一般 5 秒到 1 分钟拉一次接口就够，不需要 websocket 推送；如果数据量大会频繁全量刷新，可以在后端加一层简单缓存，把最近一次查询结果存内存，减少数据库压力。

最后讲讲数据口径的教训。我曾在一个项目里把清洗后的日志和原始日志混在一起统计，导致大屏上的 PV 和数据库里的数字对不上，业务方追问时非常被动。后来约定所有指标只从一张结果表读取，流处理和离线批处理共用同一个指标表，前端展示的口径才稳定下来。做数据可视化也好，做大屏也好，最重要的不是图好看，而是数字经得起追问。这条经验希望帮到你。

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