先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）
正文
resourcemanager：集群资源管理者
nodemanager：单机资源管理者
任务计算层面：
applicationmaster：单任务管理者（如任务失败重启、任务资源分配、任务工作调度）
task：单任务执行者
saprk角色
master：集群资源管理者
worker：单机资源管理者
driver：单任务管理者
executor：单任务计算
正常executor干活，特殊场景下（local）driver除了管理也可以干活
小结：
解决问题
针对海量数据进行离线批处理和实时流计算
模块
spark core、spark sql、spark streaming、graphX、MLlib
特点
快、简单、通用、多模式运行
运行模式
- 本地模式
- 集群模式（standalone、yarn、kubernetes）
- 云模式
运行角色
master；worker；driver；executor
spark环境搭建-local
实验服务器环境
node1：master和worker
node2：worker
node3：worker和hive
- hadoop3以上
- jdk1.8
- centos7（7.6）
基本原理
本质
启动一个JVM process进程（一个进程有多个线程），执行任务task
- local模式可以限制spark集群环境的线程数量，即local[N]或local[*]
- N代表可以使用N个线程，每个线程拥有1个cpu core；如果不指定N，默认1个线程；通常几核cpu就指定几个线程，最大化利用计算能力
- local[*]表示按最多的cppu核心数设置线程数
角色分布
资源管理：
master：local进程本身
worker：local进程本身
任务执行：
driver：local进程本身（driver可以理解为有时候做管理（local），有时候做工人）
executor：不存在，由local进程内的线程提供计算能力（executor可以理解为纯工人）
local模式只能运行一个spark程序，如果执行多个spark程序，需要多个相互独立的local进程执行
搭建
centos装好系统
anaconda、hadoop、spark、jdk
安装anaconda
bash Miniconda-tab
source .bashrc
conda create -n pyspark python=3.8 -y
安装spark、hadoop、spark
tar -zxvf spark-tab -C /export/server
tar -xvf hadoop-tab -C /export/server
tar -xvf jdk-tab -C /export/server
ln -s spark-tab spark
配置环境变量
vim /etc/profile
export JAVA_HOME=/export/server/jdk
export SPARK_HOME=/export/server/spark
export HADOOP_HOME=/export/server/hadoop
export PYSPARK_PYTHON=/root/miniconda3/envs/pyspark
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
export PATH=$JAVA_HOME/bin:$HADOOP_HOME/bin:HADOOP_HOME/sbin:$PATH
vim ~/.bashrc
export JAVA_HOME=/export/server/jdk
export PYSPARK_PYTHON=/root/miniconda3/envs/pyspark
启动spark
# 在spark的bin目录下
# 1. 启动spark的python版本pyspark
./pyspark
# 2. 带参数启动pyspark
./pyspark --master local[\*]
# 3. 启动spark-shell
./spark-shell
# 4. 执行简单命令
sc.parallelize(Array(1,2,3,4,5)).map(x => x \*10).collect()
# 5. 执行spark-submit
./spark-submit --master local[\*] /export/server/spark/examples/src/main/python/pi.py 10
# 执行圆周率的实例程序，迭代10次
| 功能名称 | bin/spark-submit | bin/pyspark | bin/spark-shell |
|---|---|---|---|
| 功能 | 提交java\scala\python代码到spark中运行 | 提供一个python | |
| 解释器环境用来以python代码执行spark程序 | 提供一个scala | ||
| 解释器环境用来以scala代码执行spark程序 | |||
| 特点 | 提交代码用 | 解释器环境 写一行执行一行 | 解释器环境 写一行执行一行 |
| 使用场景 | 正式场合, 正式提交spark程序运行 | 测试\学习\写一行执行一行\用来验证代码等 | 测试\学习\写一行执行一行\用来验证代码等 |
local模式小结
运行原理
一个独立进程配合内部线程完成spark运行时环境；
local模式可以通过spark-shell/pyspark/spark-submit等开启
bin/pyspark是什么程序
是一个交互式解释器执行环境，启动后得到一个local spark环境，运行python代码来进行spark计算
不同于python解释器，pyspark可以调用spark api完成spark计算
spark的4040端口
spark任务启动后，driver所在机器绑定4040端口，提供当前任务的监控页面；
任务结束，则4040解绑；
多个任务，则分别绑定到多个不同端口
spark环境搭建-standalone
standalone架构
local通过一个进程内的线程模拟spark运行环境
standalone是spark自带的一种集群环境，不同于local模拟，standalone真实地在多个机器之间搭建spark集群环境，可用于实际大数据处理
standalone是完整的spark（分布式）运行环境
master以master进程存在（可多个master），worker以worker进程存在（可多个worker）
driver运行时存在master进程内，executor运行于worker进程内
主要3类进程
- 主节点master进程：master角色，管理整个集群资源，托管运行各任务的driver
- 从节点worker：worker角色，管理每个机器的资源，分配对应资源（memory、cpu cores）来运行executor
- 历史服务器HistoryServer（可选）：spark application运行完成后，保存事件日志数据到hdfs，启动HistoryServer可查看应用运行相关内容
master集群
driver任务
worker单机资源
executor某任务执行
standalone部署
- 三台服务器（虚拟机，三台均如local配置部署即可）
node1\ node2\ node3
node1运行: Spark的Master进程 和 1个Worker进程
node2运行: spark的1个worker进程
node3运行: spark的1个worker进程
整个集群提供: 1个master进程 和 3个worker进程
- 修改配置文件
# 切换到hadoop用户
chown -R hadoop:hadoop spark\*
su - hadoop
cd conf # /export/server/spark/conf
# 配置workers文件
mv workers.template workers
vim workers
# 指定workers
node1
node2
node3
# 配置spark-env.sh文件
mv spark-env.sh.template spark-env.sh
vim spark-env.sh
# 追加以下内容
JAVA_HOME=/export/server/jdk
HADOOP_CONF_DIR=/export/server/hadoop/etc/hadoop
YARN_CONF_DIR=/export/server/hadoop/etc/hadoop
export SPARK_MASTER_HOST=node1 # 指定master
export SPARK_MASTER_PORT=7077 # 指定master的通讯端口
SPARK_MASTER_WEBUI_PORT=8080 # 指定master webui端口
SPARK_WORKER_CORES=1 # 可用cpu核心数
SPARK_WORKER_MEMORY=1g # 可用内存大小
SPARK_WORKER_PORT=7078 # worker工作通讯端口
SPARK_WORKER_WEBUI_PORT=8081 # worker webui端口
# 配置历史服务器：将spark程序运行的历史日志存到hdfs的/sparklog文件夹中
SPARK_HISTORY_OPTS="-Dspark.history.fs.logDirectory=hdfs://node1:8020/sparklog/ -Dspark.history.fs.cleaner.enabled=true"
# 在hadoop中查看是否存在sparklog文件夹
hadoop fs -ls /
# 如果没有sparklog文件夹，则需要在hdfs上创建
hadoop fs -mkdir /sparklog
hadoop fs -chmod 777 /sparklog
# 配置spark-defaults.conf
mv spark-defaults.conf.template spark-defaults.conf
# 追加以下内容
spark.eventLog.enabled true # 开启spark的日期记录功能
spark.eventLog.dir hdfs://node1:8020/sparklog/ # 设置spark日志记录的路径
spark.eventLog.compress true # 设置spark日志是否启动压缩：减小体积，提升网络IO
# 配置log4j.properties文件 [可选: 因为spark日志输出太多，看任务需求]
mv log4j.properties.template log4j.properties
vim log4j.properties
log4j.rootCategory=WARN, console # 将INFO修改为WARN
# 在其他node上也安装spark
scp -r spark-3.1.2-bin-hadoop3.2 node2:/export/server/
scp -r spark-3.1.2-bin-hadoop3.2 node3:/export/server/
# 设置软链接
ln -s /export/server/spark-3.1.2-bin-hadoop3.2 /export/server/spark
- 启动历史服务器
sbin/start-history-server.sh # node1
jps # 显示所有Java进程的pid
xxx JobHistoryServer # hadoop yarn的历史记录服务器
xxx HistoryServer # spark的历史纪录服务器
- 启动spark的master和worker进程
# 启动全部master和worker
sbin/start-all.sh
# 或者一个个启动:
# 启动当前机器的master
sbin/start-master.sh
# 启动当前机器的worker
sbin/start-worker.sh
# 停止全部
sbin/stop-all.sh
# 停止当前机器的master
sbin/stop-master.sh
# 停止当前机器的worker
sbin/stop-worker.sh
- 查看master的webui
默认设置为8080，如果被占用则向后顺延
日志中查看到:Service 'MasterUI' could not bind on port 8080. Attempting port 8081.
通过master的webui界面，可以检查spark集群启动是否正常
测试
cd /export/server/spark/bin
pyspark
在master的webui界面查看通讯地址
./pyspark --master spark://node1:7077连接到集群
sc.parallelize([1,2,3,4,5]).map(lambda x: x*10).collect() # 运行简单的命令
任务结束后，driver结束，但master和worker仍在
spark-submit
./spark-submit --master spark://node1:7077 /export/server/spark/examples/src/main/python/pi.py 100100次迭代计算圆周率
任务执行完成后，driver生命周期结束，通过历史服务器HistoryServer查看运行情况
历史服务器端口：18080
node1:18080中查看历史运行记录
spark应用架构（层次结构）
一些监控页面
4040
是一个运行着的application在运行过程中临时绑定的端口，用以查看当前任务的状态
4040是一个临时端口，程序运行完成后即被注销（driver用）
8080
默认standalone下master的web端口，用以查看master集群的状态
18080
默认历史服务器的端口，用以回看某个程序的历史运行状态
历史服务器长期稳定运行
层级
一个应用程序
若干子任务
每个子任务的若干阶段
每个阶段由不同Task（线程）完成
standalone模式小结
standalone原理
master和worker角色以独立进程形式存在，组成spark运行环境(集群 )
standalone中spark角色分布
master角色：master进程
worker角色：worker进程
driver角色：以线程运行在master中
executor角色：以线程运行在worker中
standalone提交spark应用
bin/spark-submit --master spark://server:7077 xxx
4040 8080 18080
4040：单个程序（driver）运行时的临时端口
8080：master的webui端口
18080:历史服务器
job state task
job下若干state
state下若干task
一个spark程序会分为多个子任务（job），每个子任务会分为多个阶段（state），每个阶段会分成多个线程（task）来执行具体的任务
spark环境搭建-standalone-ha
standalone集群是master-slaves架构的集群模式，存在单点故障问题（SPOF）
master宕机，则集群崩溃，所以要多个master来保证集群的资源分配
高可用HA
spark解决单点故障问题的两种方案：
- 基于文件系统的单点恢复（Single-Node Recovery with Local File System）：只限开发或测试
- 基于zookeeper的standby masters（standby masters with zookeeper）：可用于生产
zookeeper提供leader election机制，保证集群中虽然有多个master，但只有一个保持活跃（active），其他都是standby。当活跃master出现故障时，standby master顶替。集群信息（worker，driver，application）都已持久化到文件系统，因此切换过程（有时间开销）只会影响job提交，正在进行的job不受任何影响。
基于zookeeper实现HA
启动zookeeper和hdfs
cd /export/server/spark/conf
vim spark-env.sh
# 修改为注释
# export SPARK\_MASTER\_HOST=node1 # 为了使用zookeeper动态切换master
# 追加
SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=node1:2181,node2:2181,node3:2181 -Dspark.deploy.zookeeper.dir=/spark-ha"
standalone ha原理
基于zookeeper做状态维护，开启多个master，当活跃master宕机时，standby master能及时接管
spark环境搭建-spark on yarn
按前面方式部署，最优为standalone ha；
但企业服务器紧张，且不管什么业务基本都有Hadoop集群，也就是yarn集群；
standalone集群和yarn集群复用一套服务器资源利用率低，不如只使用yarn集群；
spark直接运行在yarn内，接受yarn调度；
对于spark on yarn，无需部署spark集群，只需一台服务器充当spark客户端，即可提交任务到yarn集群中运行
spark on yarn本质
master角色由yarn的resourceManager担任
worker角色由yarn的nodeManager担任
driver角色运行在yarn容器内，或提交任务的客户端进程中
executor运行在yarn提供的容器内
核心：让spark计算任务运行在yarn容器内部，资源管理交由resourceManager和nodeManager代替
spark on yarn的需求：
- yarn集群
- spark客户端，如spark-submit，将spark程序提交到yarn中
- 被提交的代码，如pi.py等
spark on yarn环境配置
确保HADOOP_CONF_DIR YARN_CONF_DIR在spark-env.sh中配置了环境变量即可
bin/pyspark --master yarn --deploy-mode client|cluster
# yarn中独有 --deploy-mode
# 交互式环境pyspark和spark-shell只能运行客户端模式
deployMode部署模式
cluster模式和client模式
spark on yarn两种运行模式：Cluster集群模式、Client客户端模式
两种模式区别在于driver运行位置
cluster模式：driver运行在yarn内部，和applicationManager在同一个容器内部
client模式：driver运行在客户端进程中，如driver运行在spark-submit程序的进程中
cluster模式
client模式
cluster模式：
- 效率高，直接在容器内通信，集群通信成本低
- 查看日志困难，日志也是容器内日志
- 集群模式下driver运行在applicationMaster节点上，由yarn管理，出现问题yarn会重启applicationMaster（driver）
client模式（方便，但性能低稳定差，生产不推荐）：
- 容易看日志，日志是客户端日志
- 效率低，需要跨容器通信，通信成本高
client模式测试
# 客户端模式
bin/spark-submit --master yarn --deploy-mode client --driver-memory 512m --executor-memory 512m --num-executors 3 --total-executor-cores 3 /export/server/spark/examples/src/main/python/pi.py 100
# 集群模式
bin/spark-submit --master yarn --deploy-mode cluster --driver-memory 512m --executor-memory 512m --num-executors 3 --total-executor-cores 3 /export/server/spark/examples/src/main/python/pi.py 100
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
eploy-mode client --driver-memory 512m --executor-memory 512m --num-executors 3 --total-executor-cores 3 /export/server/spark/examples/src/main/python/pi.py 100
集群模式
bin/spark-submit --master yarn --deploy-mode cluster --driver-memory 512m --executor-memory 512m --num-executors 3 --total-executor-cores 3 /export/server/spark/examples/src/main/python/pi.py 100
**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
[外链图片转存中...(img-nWQD2VaB-1713747815753)]
**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**