目录
Namenode：接受客户端的请求，维护整个HDFS集群目录树，元数据信息的存储由namenode负责
Datanode：主要是负责数据块的存储，定期向namenode汇报block
SecondaryNamenode：SecondaryNamenode不是第二个namenode，当namenode宕机时，不能由SecondaryNamenode顶替
dfs.namenode.checkpoint.period=3600 #两次checkpoint的时间间隔
dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录
dfs.namenode.checkpoint.check.period=60 #检测的触发条件是否满足60s
dfs.namenode.checkpoint.max-retries=3 #最大的重试次数
上面配置只要有一个满足条件就会触发checkpoint机制
“将一个对象编码成一个字节流”称为序列化该对象（Serializing）；相反的处理过程称为反序列化（Deserializing）。
自定义bean对象想要序列化传输，必须实现序列化接口，注意反序列化的顺序和序列化的顺序完全一致。
one map task for each InputSpilt
每个切片都是由一个mapTask处理
切片数量决定了MapTask的数量
假设切片是跨block的，也就是说maptask读取数据的时候，会出现以下几种情况
1、最理想的情况：有数据低负载（最佳本地化读取）
2、折中的情况：没数据（本节点没有所需的数据，这个时候就需要跨节点读取，这个所跨的节点是同一机架的，换句话说，如果本节点没有数据，你就需要看同一个机架的其他节点是否有需要的数据）
3、最差的情况，带宽占有率会很高，尽量避免：跨机架（不要跨数据中心，如果同一个机架没有所需要的数据，那只能跨机架读取其他节点的数据）
假设Hadoop的拓扑结构如下：
1、HDFS的block3个
2、某个InputSplit包含3个block，大小分别是100，150和75
3、准备4个机架，每个机架2个节点，数据的分布如下图所示
按机架排序（rack2>rack1>rack3>rack4）
按机架内部的节点的数据量排（rack2:node4>node3）(rack1:node1>node2)
得出：node4>node3>node1>node2....
最佳的host列表{node4，node3，node1}
结论：当使用基于FileInputFormat实现InputFormat的时候，为了提高mapTask本地化读取数据，应该尽量使得InputSplit的大小和block相等。
1、Read阶段：MapTask通过用户编写的RecodReader去读取数据，从输入的InputSplit中解析出key/value键值对
2、Map阶段：这个阶段将解析的key/value交给用户编写的map()函数处理，并产生一系列的key/value键值对
3、Collect阶段：当用户编写的map()函数，处理完成之后，会调用OutputCollector.collect()输出结果，在该函数内部，它会生成key/value分片，并且写入到一个环形缓冲区，将来缓冲区的数据达到溢出值，内存中的数据就会刷入到磁盘。
4、Spill阶段：溢出阶段，当环形缓冲区满了，数据溢出到磁盘生成一些小文件。数据写入磁盘之前，先要对数据进行一次本地化的排序操作，分区操作，并且必要的时候，还要对数据进行合并、压缩操作
5、Combine阶段：当所有的数据处理完成之后，mapTask对所有的临时文件进行一次合并，以确保最终只会生成一个数据文件。
压缩可以说是mapreduce一种优化的策略
1、数据进入到map端的时候可以进行压缩
2、Map端的数据传输到reduce端的时候可以进行压缩
3、Reduce端将数据输出的时候可以选择压缩
1、Bzip2压缩率是最高的，这种压缩算法比较适合IO密集型的Job
2、在运算密集型的job的时候，优先考虑lzo
优点：压缩比比较高，而且解压和压缩速度也比较快，hadoop本身也是支持这种压缩算法，在应用处理当中，gzip格式文件就和处理普通文件是一样的，大部分的Linux系统都是自带gzip命令，使用方便
缺点：不支持切分（split逻辑切分）
应用场景：当你的文件压缩之后可以到（或者是小于等于一个blocksize大小）blocksize可以考虑使用它（或者说如果你的文件用gzip压缩之后文件大小在128M，我们就可以考虑使用这个gzip算法）
优点：支持split，具有很高的压缩比，hadoop本身也是支持这种算法，在linux系统里面，自带bzip2，使用方便。
缺点：压缩速度和解压速度都是很慢的，不支持native本地
应用场景：使用的场景针对那种速度要求不高、对压缩比要求高、对冷数据进行持久化存储的场景，即IO密集型场景
优点：压缩、解压缩速度都是比较快的，压缩率不会很高。本身不支持split，给Lzo压缩的文件加上索引，就支持分片了，它是hadoop当中较为流行的压缩格式，注意的是，linux服务器默认是不支持这个压缩格式，需要单独的安装
缺点：压缩比比gzip更低，hadoo本身不支持这个格式，需要额外的安装。代码还需要做特殊处理
应用场景：用于这种运算密集型的job
ResourceManager有两个重要的组件：Scheduler，Application Manager
Yarn结构里的核心角色ResourceManager，Application，Nodemanager
先进先出的策略，简单来说按照提交作业的先后顺序运行。Hadoop1.x默认的资源调度器是FIFO的方式。它按照作业的优先级高低，再按照到达时间的先后选择被执行的作业
支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO调度策略，为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定
公平调度是一种赋予作业（job）资源的方法，它的目的是让所有的作业随着时间的推移，都能平均的获得等同的共享资源。所有的job具有相同的资源，当单独一个作业在运行时，它将使用整个集群。
1.1.1 YARN的介绍 为克服Hadoop1.0中HDFS和MapReduce存在的各种问题⽽提出的，针对Hadoop1.0中的MapReduce在扩展性和多框架⽀持⽅⾯的不⾜，提出了全新的资源管理框架YARN. ApacheYARN（YetanotherResourceNegotiator的缩写）是Hadoop集群的资源管理系统，负责为计算程序提供服务器计算资源，相当于⼀个分布式的操作系统平台，⽽MapReduce等计算程序则相当于运⾏于操作系统之上的应⽤程序。 YARN被引⼊Hadoop2,最初是为了改善MapReduce的实现，但是因为具有⾜够的通⽤性，同样可以⽀持其他的分布式计算模
目录：一、简介二、HQL的执行流程三、索引四、索引案例五、Hive常用DDL操作六、Hive常用DML操作七、查询结果插入到表八、更新和删除操作九、查询结果写出到文件系统十、HiveCLI和Beeline命令行的基本使用十一、Hive配置一、简介Hive是一个构建在Hadoop之上的数据仓库，它可以将结构化的数据文件映射成表，并提供类SQL查询功能，用于查询的SQL语句会被转化为MapReduce作业，然后提交到Hadoop上运行。特点：简单、容易上手(提供了类似sql的查询语言hql)，使得精通sql但是不了解Java编程的人也能很好地进行大数据分析；灵活性高，可以自定义用户函数(UDF)和
云计算实验中要求我们在Linux系统安装Hadoop，故来做一个简单的记录。· 注：我的操作系统环境是Ubuntu-20.04.3，安装的JDK版本为jdk1.8.0_301，安装的Hadoop版本为hadoop2.7.1。（不确定其他版本是否会出现版本兼容问题）Hadoop安装步骤如下： 一、更新apt和安装vim编辑器 二、配置本机无密码登录SSH 三、安装JAVA环境 四、下载安装Hadoop 五、伪分布式搭建一、更新apt和安装vim编辑器1、更新aptsudoapt-getupdate2、安装vim
一、设置免密登录1、系统偏好设置-----共享----勾选远程登录，所有用户2、打开终端，输入命令ssh-keygen-trsa，一直回车即可2.查看生成的公钥和私钥 cd~/.ssh ls会看到~/.ssh目录下有两个文件：①私钥：id_rsa②公钥：id_rsa.pub3.将公钥内容写入到~/.ssh/authorized_keys中 cat~/.ssh/id_rsa.pub>>~/.ssh/authorized_keys4.测试在terminal终端输入 sshlocalhost如果出现以下询问输入yes，不需要输入密码就能登录，说明配置成功Areyousureyouw
文章目录实验二：HDFS+MapReduce数据处理与存储实验1.实验目的2.实验环境3.实验内容3.1HDFS部分3.1.1上传文件3.1.2下载文件3.1.3显示文件信息3.1.4显示目录信息3.1.5删除文件3.1.6移动文件3.2MapReduce部分3.2.0Mapreduce原理3.2.1合并和去重3.2.1.1编写Merge.java代码3.2.1.2编译执行3.2.2文件的排序3.2.2.1编写Sort.java代码3.2.2.2编译执行4.踩坑记录5.心得体会6.源码附录6.1Merge.java完整代码6.2Sort.java完整代码实验二：HDFS+MapReduce数据
我正在结合riak/riak-js开发nodejs应用程序并遇到以下问题:运行这个请求db.mapreduce.add('logs').run();正确返回存储在存储桶日志中的所有155.000个项目及其ID:['logs','1GXtBX2LvXpcPeeR89IuipRUFmB'],['logs','63vL86NZ96JptsHifW8JDgRjiCv'],['logs','NfseTamulBjwVOenbeWoMSNRZnr'],['logs','VzNouzHc7B7bSzvNeI1xoQ5ih8J'],['logs','UBM1IDcbZkMW4iRWdvo4W7zp6d
MapReduce序列化之统计各部门员工薪资总和文章目录MapReduce序列化之统计各部门员工薪资总和1.1实验目的1.2实验环境1.3需求描述1.4实验步骤1.4.1采用IDEA创建一个Maven工程1.4.2自己动手开发Java程序1.4.3使用maven生命周期package打jar包1.4.4通过xftp将jar包上传到linux系统1.4.5在hadoop环境运行jar包1.4.6查看输出结果1.5实验中遇到的问题总结1.5.1问题描述1.5.2问题分析1.5.3解决方法1.1实验目的通过MapReduce的序列化方法统计各个部门员工薪水总和。1.2实验环境搭建IDEA+Maven
博学之，审问之，慎思之，明辨之，笃行之🏂hiveonspark搭建好后，任务提交会有问题，因为通过hive会话提交的任务一直存在且不会结束（除非关掉这个hive会话），根本原因是这些任务提交到了Yarn的同一个队列中，前面的任务没有执行完毕后面的任务不会执行，所以解决办法是增加一个Yarn队列，指定任务提交的队列，这样就不会出现任务的阻塞。目录一、情景复现二、原因三、Yarn队列配置—增加队列1.情景复现：搭建好hiveonspark后，在命令行直接进入hive会话，提交任务后，在ResourceManager上jps查看进程可以看到有个进程ApplicationMaster一直存在，打开Re
目录SparkStreaming的核心是DStream一、DStream简介二．DStream编程模型三．DStream转换操作SparkStreaming的核心是DStream一、DStream简介1.Spark Streaming提供了一个高级抽象的流，即DStream(离散流)。2.DStream的内部结构是由一系列连续的RDD组成，每个RDD都是一小段由时间分隔开来的数据集。二．DStream编程模型三．DStream转换操作transform（）1．在3个节点启动zookeeper集群服务$zkServer.shstart2．启动kafka（3个节点都要）$/opt/module/k
目录基本语法一、上传二、下载三、其他增删改查操作3.1增3.2删3.3改3.4查基本语法hadoopfs和 hdfsdfs（hadoopfs和hdfsdfs命令等效。）-hdfs dfs只能操作HDFS文件系统-hadoopfs可操作任意文件系统，不仅仅是hdfs文件系统，使用范围更广[root@hadoop102hadoop-3.1.3]$bin/hadoopfs[-appendToFile...][-cat[-ignoreCrc]...][-chgrp[-R]GROUPPATH...][-chmod[-R]PATH...][-chown[-R][OWNER][:[GROUP]]PATH..
