Hadoop 3.0.0 （单机版）安装与配置与基础使用
吐槽一下：我相信每年还是会有很多非计算机专业的学生像我一样，选了大数据这个听起来就十分高大上的相关选修课，但是呢，一点电脑基础都没有。以为是个水课，混混就过去了，没想到碰到硬茬了，在学习这门选修课，我是真的要没有一点基础，网上教程又都是上几十个小时的课程，可它只是一门1学分的选修课，我不可能为了它花这么多时间。还好最后老师放水了，不用伪分布式，只要求学生把单机版hadoop随便玩玩就行了，不然我直接就挂科了。
由于我真的不太了解hadoop这个玩意，下面我说的内容（我的结课报告，这里面有很多的内容，特别是理论方面，是复制粘贴的，但由于年代久远，忘了是从哪复制粘贴来的了，基本上只有吐槽是我自己写的，如有侵权，立马删除）可能会有明显的知识错误，望大佬指出。
大数据技术概述
什么是大数据
就是数据很大很大呗！看似是一个外行人肤浅的想法，但老实说这还真的就是大数据的本质。大数据本身就是一个比较抽象的概念，所以网络上对大数据的定义都有部分差异。就以百度百科为例，百度百科对“大数据”的定义为：“大数据”（Big Data），或称巨量资料，指的是无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。
大数据的五V特性
大数据的应用
- 辅助决策
- 数据驱动服务
- 实时反馈决策
- 效率优化，提升效率
这是大数据常见的几个应用方面，但往往大数据的应用涉及的技术层又广又深。无法深入阐释。鉴于我的上一个选修课论文方向是电力系统和智能电网，就以大数据在智能电网中的应用做一个简单的例子。智能电网是以基本的物理电网为基础，通过应用目前的现代信息技术、通信技术以及计算机处理技术等，同时和传感测量技术、控制技术进行结合进而形成的一种高度集成的电网。而各种传感器的数据已经无法是人脑能够实时分析的了，这时大数据技术可以将设备监测数据进行数据储存与分析，之后将有价值的数据人性化展示给相关的监测人员（这段瞎编的）。
分布式文件系统---GFS及Hadoop概述
绝大多数内容参考于该视频（因为我根本就不会找谷歌这篇GFS的论文）：解读Google分布式文件系统GFS（合集）_哔哩哔哩_bilibili
什么是分布式文件系统
在进行这个问题的探讨前，首先得理解啥是文件系统，文件系统是操作系统用于明确存储设备或分区上的文件的方法和数据结构；即在存储设备上组织文件的方法。操作系统中负责管理和存储文件信息的软件机构称为文件管理系统，简称文件系统。文件系统由三部分组成：文件系统的接口，对对象操纵和管理的软件集合，对象及属性。从系统角度来看，文件系统是对文件存储设备的空间进行组织和分配，负责文件存储并对存入的文件进行保护和检索的系统。长话短说就是一个管理文件的软件，只不过这个软件的权限特别高，能进行许多高权限级别操作。Windows文件系统有FATFS、VFATFS、NTFS等。除了Windows外，Linux也有ext、vfs等等文件系统，像这种一台计算机，单个存储节点、一个操作系统，一个具体的文件系统的场景称之为一般文件系统。
而分布式文件系统又与一般文件系统有什么不同呢？一般文件系统的访问方式是系统总线IO，这一特点也造成了一般文件系统只能进行小量数据的存储，我不怎么了解电脑行情，但我在购买笔记本电脑时发现，大部分笔记本存储容量多在256G-2TB之间，即使是再接个机械硬盘也只能是TB级的储存容量，而大数据上个PB级别不是啥罕见的事。
因此在大数据领域，分布式文件系统的意义也就显现出来。分布式系统通过采用网络IO的访问方式，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。
什么是GFS（Google File System）
GFS是一个为Google内部设计的大数据分布式存储框架，由2003年Google发表的论文提出，用来满足 Google 不断扩展的数据处理需求。不过Google并没有将其开源， GFS 为大型网络和连接的节点提供了较好的容错性、可靠性、可扩展性、可用性和性能。GFS 由多个由低成本商品硬件组件构建的存储系统组成。它经过优化以适应 Google 的不同数据使用和存储需求，例如其搜索引擎会生成大量必须存储的数据。这个系统最大的亮点有两个，一个是使用集群的概念，将硬件设施连接起来共同进行文件存储任务；另外一个是充分利用了现成服务器的优势，同时最大限度地减少了硬件弱点。
那么谷歌没有开源，为什么还要了解GFS，对于学习分布式文件系统来说，谷歌发表的论文简直就是经典中的经典，现在市面上许多的分布式文件系统就是基于GFS设计理念的类GFS文件系统。包括后面谷歌基于GFS方向的技术栈MapReduce、BigTable也是为分布式文件系统的设计开拓了思路。
GFS由单个主服务器和多个数据块服务器组成，并由多个客户端访问。文件被分成固定大小的64MB数据块。每一个数据块都有一个不可变且全局唯一的快处理程序，由主控服务器在创建块的时候分配的。默认情况下，每个文件块都会被复制到3个不同的块服务器上。对于GFS的特点，这里只谈我感知比较深的几点。
第一点：用户是怎样访问到需求数据的？
用户通过GFS客户端，也就是通过应用程序输入需求，首先客户端会在已缓存列表中寻找此需求的元数据，若有此需求的元数据，那么就可跳过主服务器，直接去访问chunkserver 服务器获取数据。若客户端里没有该需求元数据，那么就去主服务器（GFS master）索要元数据，缓存到客户端后，再进行数据获取，以此尽可能减少主服务器的运作压力。
第二点：为什么要把一个文件分成若干个chunk,一个chunk的大小为何设定为64M，一个文件的chunk要被分布在多个chunkserver中？
其实第一个问题还是比较好理解的，当文件过大时，若将它作为一个整体进行储存会十分依靠硬件提供的储存空间，所以要进行文件分块处理。而chunk的大小（文件偏移量的单位大小）决定着一个文件能被分成多少块，也就是多少个chunk。那为何chunk大小被设置成64M，要知道在当时的硬件情况下64M可不是一个小数目，但当时谷歌设计GFS的初衷就是为了处理GB级以上的文件，如果chunk设计过小，会使一个大文件被分成特别多个的chunk储存在不同的chunkserver中，而chunk在不同的chunkserver的位置是需要在主服务器中记载的，会对主服务器的内存造成不必要的浪费，chunk过大对chunkserver的硬件性能有较高要求，总的来说，chunk过小，对主服务器的性能要求会更高，chunk过大，对数据块服务器的性能要求更高，而64M相对来说是一个综合主服务器性能与分布式服务器较好的chunk大小。那为什么要将一个文件的chunk分布在不同的chunkserver中呢？假设我们将一个文件的chunk全部储存在一个chunkserver中，只有这个chunkserver满了以后，才将这一个文件剩余的chunk放在下一个chunkserver中,这样的话会出现一个chunkserver负载不均衡的问题，有些chunkserver被挤得满满的，而一些chunkserver中却只有几个chunk孤苦伶仃。因此谷歌设计了同一文件chunk被均匀分配在不同的chunkserver中，分配方法由主服务器决定以达到负载均衡，一般情况下，各个chunkserver的chunk数量差不会超过两个。
第三点：GFS的副本机制
对于一个分布式系统来说，高可靠性是在设计时必须考虑的一个因素。在长时间，多数据块储存情景下，很容易发生某个数据块服务器宕机导致数据暂时不能读取或者数据丢失，所以GFS建立了一附二的备份机制，即一个chunk会有两个副本储存在其他的chunkserver中，这样即使有两个储存相同文件数据块的chunkserver宕机，还是有一个能对其进行数据恢复。有时一些比较重要的数据会被要求储存在不同机架的服务器上，甚至不同机房的服务器上来确保数据不会损失，同时说明一下这里的三个chunk备份没有主次之分，还会有一个就近访问机制也是依赖于GFS副本机制，比如说三个相同的chunk分别被储存在北京、上海、广州的服务器中，那么北京用户访问数据，就会优先访问北京机房的服务器。在考虑主服务器宕机的可能性，谷歌也有一个类似于数据库的主备机制，以保证数据安全。
HDFS（Hadoop Distributed File Syetem）
什么是Hadoop？
Hadoop是一个由Apache基金会所开发的分布式系统基础架构，主要解决的是海量数据的储存和海量数据的分析计算，广义上hadoop生态圈不止是hadoop，还有hive，hbase等，它是对于GFS设计理念的开源实现 。
Hadoop优势
Hadoop组成
我学的时候hadoop都3版本了，但我没找到相关资源
HDFS架构概述
- NameNode（nn）存储文件元数据，如文件名，文件目录结构，文件属性（生成时间，副本数，文件权限），以及每个文件的块列表和块所在的DataNode等。
- DataNode（dn）在本地文件系统存储文件块数据，以及块数据的校验。
- Secondary NameNode（2nn）每隔一段时间对DataNode元数据备份。
-
YARN架构概述
Yet Another Resource Negotiator 简称YARN 另一种资源协调者，是Hadoop的资源管理器
（1）ResourceManager（RM）整个集群资源的主导者
（2）NodeManeger（NM）单个节点服务器的主导者
（3）ApplicationMaster（AM）单个任务的主导者
（4）Container 容器
-
Hadoop 3.0.0的安装部署（本地模式，系统为win11）
-
第一步：配置java环境变量
-
这个由于是后面老师要求用java实现基本操作才去用java的，我也不知道其他语言可不可以用hadoop，环境变量的配置网上教程多的是，这里就不赘述了。
-
第二步：下载hadoop的压缩包
-
下载链接：http://archive.apache.org/dist/hadoop/core/hadoop-3.0.0/hadoop-3.0.0.tar.gz
-
我试着想把压缩包上传上去，结果CSDN说已有资源，但我去已有资源去找吧，它又说无数据，把压缩包上传到阿里云盘去分享链接，它又说该文件格式可能含违法内容，这个链接的下载速度有时候会非常慢，有时候又是正常水平
-
当时我是直接用学校网盘里的资源，根本没考虑自己该咋样下载，
-
第三步：解压缩包
个人建议如果也是选修了解一下这个东西的话，解压到C盘以外的盘，以后删除简单一点
这里我解压到了D盘的hadoop文件夹中
第四步：配置相关文件
首先进入到hadoop 3.0.0的文件夹，然后进入etc目录
（1）：配置core-site.xml文件，红框为配置内容
（2）在hadoop3.0.0的目录下创建data文件夹,然后在data文件夹里创建namenode（名称节点）与datanode（数据节点）文件夹，还可以再创建一个tmp（临时目录）文件夹，我这里已经创建了一遍了，只需要创建文件夹就行了，不需要文件
（3）配置hdfs-site.xml文件（注意配置时要改为自己的文件夹路径）
（4）配置yarn-site.xml文件
（5）配置hadoop-env.cmd（好像叫命令脚本，如果电脑里没有notepad软件啥的，无法直接打开.cmd文件或者说闪退,我的土办法是先改为.xml文件修改后再改为.cmd文件）,修改JAVA_HOME为绝对路径，一定要对应环境变量里的文件路径
（6）配置mapred-site.xml文件
第五步：下载winuntils压缩包，选择对应版本将解压后的bin目录覆盖hadoop3.0.0的bin目录，这个资源相对来说好找一些，github里面也有
最好将winutil.exe再复制到Windows\system 32的目录下
（补充：最好将bin目录下hadoop.dll复制到C:\Windows\System32目录下，网上说的）
就是这个玩意
第六步：配置hadoop相关的环境变量
还有path里面的
第七步：以管理员身份运行cmd(命令提示符窗口)
（1）检查hadoop安装是否成功（这个倒不需要管理员身份）
（2）在管理员身份下打开cmd进行格式化（这里很容易报错，要看最后几行里有没有successfully~~的语句），一旦报错，老师冷酷地告诉我删掉hadoop文件夹，重新再来。我好像弄了三四遍
（3）在hadoop-3.0.0\sbin的路径下以管理员身份运行start-all.cmd和stop-all.cmd
出现四个有名字的窗口就基本完成hadoop在windows的安装了
注意，这里不要直接关闭这几个窗口，最好用命令行来操作，不然会被老师骂的，ε=(´ο｀*)))唉
不过私底下我想咋关就咋关，O(∩_∩)O哈哈~
第八步：查看web界面
（注意：在之前的版本中文件管理的端口是50070，在3.0.0中替换为了9870端口，这个跟文件配置有关，乱撞就是了反正经典访问端口也就那么几个）
如果是第一次无法访问原因可能是防火墙没关闭，或者浏览器不适配，最好把校园VPN也关了
注意要在hadoop还在运行时才能打开，不然直接打开啥也没有，web界面的内容只不过是数据映射而已。
（1）访问http://localhost:9870/查看文件管理界面
（2）访问http://127.0.0.1:8088/查看所有节点状态
HDFS的基本使用 （命令行方式）
1. hadoop fs -help 显示Hadoop 命令指导帮助
2. hadoop fs -ls [-h][-R] 显示文件目录
-
[-h]：人性化显示文件大小
[-R]：递归查看指定目录以及子目录，就是把该路径下所有文件以及文件夹都显示出来
-
3. hadoop fs -mkdir [-p]
创建文件夹 -
:要创建的文件夹所在路径 [-p]:创建父目录，就是说要创建一个文件夹，本来是先创建user文件夹，然后再在user文件夹里创建test文件夹，用了-p 后你可以直接一次性创建出user里的test文件夹。
不用-p的命令创建test过程：
hadoop fs -mkdir /user
hadoop fs -mkdir /user/test
用了-p后创建test 过程：
hadoop fs -mkdir -p /user/test
4. hadoop fs -touchz 创建文件
5. hadoop fs -rm 删除文件或删除空白文件夹
6. hadoop fs -put [-f][-p] 上传文件
[-f]：覆盖目标文件（文件已存在的情况下）
[-p]：保留访问和修改时间、所有权和权限
：本地系统待上传文件或文件夹路径
：hdfs文件系统路径
7. hadoop fs -moveFromLocal 这个是上传后同时删除本地系统文件的操作
8. hadoop fs -cat 查看文件具体内容
9. hadoop fs -get [-f][-p] 获取HDFS上的文件
<-f>：覆盖目标文件（文件已存在的情况下）
[-p]：保留访问和修改时间、所有权和权限
：本地系统待下载预存放文件或文件夹路径
：hdfs文件系统路径
10. hadoop fs -df [-h] []
<-h>：人性化显示（原本用字节显示）
11. Hadoop fs -du [-s] [-h]
[-s]:显示指定路径文件长度汇总摘要而不是单个文件的路径摘要
[-h]:人性化显示文件大小
12. hadoop fs -mv 移动文件（也可附带重命名操作）
：文件原路径
：目的路径
这里进行的是重命名操作
13. hadoop fs -checksum 查看校验码信息(我的水平还用不上这种操作，我复制粘贴过来的)
hdfs为了保证数据的一致性，每次写文件时，针对io.bytes.per.checksum字节，都会创建一个单独的校验和。默认值为512字节，因为crc-32校验是4字节，存储开销小于1%。而客户端读取数据时，默认会验证数据的crc校验和。除此之外，每个数据节点还会在后台线程运行一个数据块检测程序，定期检查存储在数据节点上的所有块。当块和对应的crc校验匹配不上，由于hdfs存储着块的副本，它可以复制正确的副本替换出错的副本
hadoop设计的应用场景就是离线数据的分布式计算，所以这些数据会保存很久，而数据保存这么久，那么物理存储介质由于中位衰减，会造成数据损坏，这对一个大文件来说，很容易导致一个块由于时间关系，硬盘错位，最终导致整个文件都是错误的，这对离线处理来说是不可以接受的，hadoop就是为了离线处理的应用场景，才设计出crc校验。
14. hadoop fs -count [-q][-h][-v] 显示路径下的目录、文件和字节数
[-q]:控制显示的列
[-v]：显示标题行
15. hadoop fs -copyFromLocal 与put上传命令效果相同，从本地拷贝文件
：本地文件系统需上传的文件地址
：上传至HDFS的路径
16. Hadoop fs -copyToLocal 拷贝文件到本地，命令类似于get，不同的是拷贝目标地址必须为本地文件系统
17. Hadoop fs -find 查找目录文件
< expression>说明：
-name pattern 查找的文件名
-iname pattern 忽略大小查找文件名
-print 打印（默认值）（不写这个也行）
-print0 打印在一行（比如说同名异父目录的文件，默认情况下是逐行打印，用这个就会打印在一行）
HDFS基本操作（2）（编程方式）
这里由于代码全是老师给的，我压根就没写过，所以直接糊弄完事了，当初连java基础都不会，跟别说这些代码了，反正它最后给就是一个统计测试，给一个五百万个单词，普通程序需要很久，但hadoop花的时间少的多，不过我是在一个电脑上运行的，估计是并行起到的作用。
第一步：
安装eclipse插件，随后创建一个map/reduce项目,配置好项目主机名和端口，便会出现HDFS文件目录展示（前提是节点已启动）
第二步：
创建一个map/reduce项目，在项目下创建一个包，在这个包里去创建类（注意编写该代码要引进Hadoop相关的包）
第三步：
修改代码里的文件路径进行实操，增删改查就那几个操作
总结
虽然这些东西连大数据门槛都摸不到，但至少不是那种我想在下面玩手机的垃圾水课，还是不错的。