本文主要记录个人学习笔记，引用了大量图片，侵权联系删
Hadoop狭义Hadoop：指的是HDFS,YARN,MAPREDUCE三大组件，值得注意的是2.x版本将原本负责资源管理和数据处理拆分位YARN 和 MR 两个组件，这样更加灵活，可以在2.0版本使用其他的数据处理组件比如Spark
广义Hadoop：指的是hadoop一系列的生态圈
Hadoop Distributed File System (HDFS)是一个分布式文件系统，与普通文件系统不同的是，HDFS的文件会被分为很多的Block分散存储在不同机器上，高容量，高吞吐，高容错。
1.1 NameNode与DataNode NameNode是HDFS的核心，架构中的主角色，Client访问入口，维护和管理文件系统元数据（包括名称空间目录树结构、文件和块的位置信息、访问权限等信息）
NameNode是基于内存和磁盘的，因为要速度快，所以会将元数据放于内存中，内存断点易失，所以需要持久化策略，采用基于快照叠加增量日志；其中磁盘上元数据文件包括 FileSystemImage和 Edits log（Journal），对元数据产生增删重命名会先往日志写，另外的节点周期EditLog向FileSystemImage合并，减小EditLog大小，减少NameNode启动时间（非HA使用SNN和HA使用StandbyNN）即New FileSystemImage= Old FileSystemImage+ EditsLog
注意点
NameNode不持久化存储块的位置信息，这些信息会在系统启动时由DataNode汇报重建保存在内存中，并且如果有某些块的副本数不足，不让节点复制出对应的块NameNode需要机器有大内存支持
DataNode：HDFS的文件会被分为很多的Block基于本地磁盘存储在一系列的DataNode中；保存block块的校验；与NameNode维持心跳汇报block列表状态；执行由NameNode下达的创建删除复制的Block操作
1.2 Block读写 HDFS客户端创建对象实例DistributedFileSystem， 该对象中封装了与HDFS文件系统操作的相关方法。调用DistributedFileSystem对象的create()方法，通过RPC请求NameNode创建文件。NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过，NameNode就会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据客户端通过FSDataOutputStream输出流开始写入数据。客户端写入数据时，将数据分成一个个数据包（packet 默认64k）, 内部组件DataStreamer请求NameNode挑选出适合存储数据副本的一组DataNode地址，默认是3副本存储。DataStreamer将数据包流式传输到pipeline的第一个DataNode,该DataNode存储数据包并将它发送到pipeline的第二个DataNode。同样，第二个DataNode存储数据包并且发送给第三个（也是最后一个）DataNode。传输的反方向上，会通过ACK机制校验数据包传输是否成功；客户端完成数据写入后，在FSDataOutputStream输出流上调用close()方法关闭。DistributedFileSystem联系NameNode告知其文件写入完成，等待NameNode确认。注意点：
DataNode所在机器需要大磁盘支持副本防治策略第一个副本：本机DN，集群外提交，随机挑选一台磁盘不太满，CPU不太忙的第二个副本：与第一副本不同机架第三个副本：与第二个副本同机架，不同服务器更多副本：随机节点
HDFS客户端创建对象实例DistributedFileSystem， 调用该对象的open()方法来打开希望读取的文件。DistributedFileSystem使用RPC调用namenode来确定文件中前几个块的块位置（分批次读取）信息。对于每个块，namenode返回具有该块所有副本的datanode位置地址列表，并且该地址列表是排序好的，与客户端的网络拓扑距离近的排序靠前DistributedFileSystem将FSDataInputStream输入流返回到客户端以供其读取数据。客户端在FSDataInputStream输入流上调用read()方法。然后，已存储DataNode地址的InputStream连接到文件中第一个块的最近的DataNode。数据从DataNode流回客户端，结果客户端可以在流上重复调用read（）当该块结束时，FSDataInputStream将关闭与DataNode的连接，然后寻找下一个block块的最佳datanode位置。这些操作对用户来说是透明的。所以用户感觉起来它一直在读取一个连续的流。客户端从流中读取数据时，也会根据需要询问NameNode来检索下一批数据块的DataNode位置信息。一旦客户端完成读取，就对FSDataInputStream调用close()方法 1.3 HDFS高可用注意点：
datanode之间采用pipeline线性传输，而不是拓扑式传输，这样的好处在于避免了网络瓶颈和高延迟的连接，利用了每个机器的带宽block分package传输，
为了pipeline传输的可靠性在用了pipeline上ack应答：pipeline反方向ack校验NameNode怎么才算确认成功呢？因为namenode已经知道文件由哪些块组成（DataStream请求分配数据块），因此仅需等待最小复制块即可成功返回。最小复制是由参数dfs.namenode.replication.min指定，默认是1.
主备的NameNode：主备需要节点间数据，以保证切换可以使得集群正常运行，所以主备节点都与一组称为"JournalNodes"（JN） 的单独守护程序进行通信，当 Active 节点执行任何命名空间修改时，它会持久地将Edit log记录到大多数这些 JN。Standby节点能够从 JN 读取Edit log，并不断监视它们对Edit log的更改，发生修改，它会将它们应用于自己的命名空间。在发生故障转移时，Standby 将确保在将自身提升为 active状态之前，它会确保 JournalNodes 读取了所有编辑内容。这可确保在发生故障转移之前，命名空间状态已完全同步；Standby节点还必须具有集群中块位置的最新信息，DataNode配置了所有NameNode的位置，并向所有NameNode发送块位置信息和检测信号。
2、MapReduce必须至少有 3 个 JournalNode 守护程序，因为Edit log修改必须写入大多数 JN。这将允许系统容忍单个计算机的故障。您也可以运行 3 个以上的 JournalNode，但为了实际增加系统可以容忍的故障数，您应该运行奇数个 JN（即 3、5、7 等）。请注意，当使用 N 个JN运行时，系统最多可以容忍 （N - 1） / 2 次故障并继续正常运行。
MapReduce 易于编程，良好扩展，适合海量数据离线计算，但实时计算差，不能流式计算
分而治之的思想，分为两个阶段 map ，reduce
第一阶段：把输入目录下文件按照一定的标准逐个进行逻辑切片，对input split 中的数据按照一定的规则读取解析返回 逻辑切片：即将一批数据分成几份处理，默认Split size = Block size（128M），得到多个input split，每一个切片由一个MapTask处理 第二阶段：调用Mapper类中的map方法处理数据。 第三阶段：Map输出的中间结果会先放在内存缓冲区中，按照一定的规则对Map输出的键值对进行分区partition。 默认不分区，因为只有一个reducetask。分区的数量就是reducetask运行的数量。 第四阶段：Map输出数据写入内存缓冲区，达到比例溢出到磁盘上。溢出spill的时候根据key进行排序sort。 默认根据key字典序排序。 第五阶段：对所有溢出文件进行最终的merge合并，成为一个文件 2.2 Reduce 第一阶段：ReduceTask会主动从MapTask复制拉取属于需要自己分区处理的数据。第二阶段：把拉取来数据，全部进行合并merge，即把分散的数据合并成一个大的数据。再对合并后的数据排序第三阶段：是对排序后的键值对调用reduce方法。键相等的键值对调用一次reduce方法。最后把这些输出的键值对写入到HDFS文件中 2.3 shuffle Map端Shuffle [收集-溢写-合并] Collect阶段：将MapTask的结果收集输出到默认大小为100M的环形缓冲区，保存之前会对key进行分区的计算， 默认Hash分区。 Spill阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数 据进行一次排序的操作，如果配置了combiner，还会将有相同分区号和key的数据进行排序。 Merge阶段：把所有溢出的临时文件进行一次合并操作，以确保一个MapTask最终只产生一个中间数据文件 Reduce端shuffle [拉去-合并-排序] Copy阶段： ReduceTask启动Fetcher线程到已经完成MapTask的节点上复制一份属于自己的数据。Merge阶段：在ReduceTask远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作Sort阶段：在对数据进行合并的同时，会进行排序操作，由于MapTask阶段已经对数据进行了局部的排序，ReduceTask只需保证Copy的数据的最终整体有效性即可。 Shuffle弊端 Shuffle是MapReduce程序的核心与精髓，是MapReduce的灵魂所在。Shuffle也是MapReduce被诟病最多的地方所在。MapReduce相比较于Spark、Flink计算引擎慢的原因，跟Shuffle机制有很大的关系。Shuffle中频繁涉及到数据在内存、磁盘之间的多次往复。 注意： Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的Hadoop资源管理器,YARN是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度 资源管理系统：集群的硬件资源，和程序运行相关，比如内存、CPU等。调度平台：多个程序同时申请计算资源如何分配，调度的规则（算法）。通用：不仅仅支持MapReduce程序，理论上支持各种计算程序。YARN不关心你干什么，只关心你要资源，在有的情况下给你，用完之后还我，正是因为YARN的包容，使得其他计算框架能专注于计算性能的提升 3.1 YARN 架构 YARN角色 物理资源管理角色： ResourceManager：YARN集群中的主角色，决定系统中所有应用程序之间资源分配的最终权限，即最终仲裁者，有如下核心组件 Resource Scheduler：负责根据application的要求分配资源ApplicationsManager：所有application的总负责人，负责接受client端的application NodeManager：YARN中的从角色，一台机器上一个，负责管理本机器上的计算资源。负责监容器资源（cpu，memory，disk，network）的使用，并报告给Scheduler MRAppMaster：每个app的负责人，用户提交的每个应用程序均包含一个AMMapTask ，Ruduce Task：会根据分配，分配到对应的Node上 资源管理独立出来 MR程序有三类进程： MRAppMaster：负责整个MR程序的过程调度及状态协调MapTask：负责map阶段的整个数据处理流程ReduceTask：负责reduce阶段的整个数据处理流程 第1步：用户通过客户端向YARN中ResourceManager提交应用程序（比如hadoop jar提交MR程序）；第2步：ResourceManager为该应用程序分配第一个Container（容器），并与对应的NodeManager通信，要求它在这个Container中启动这个应用程序的MRAppMaster第3步：MRAppMaster启动成功之后，首先向ResourceManager注册并保持通信，这样用户可以直接通过ResourceManage查看应用程序的运行状态（处理了百分之几）;第4步：MRAppMaster为本次程序内部的各个Task任务向RM申请资源，并监控它的运行状态;第5步：一旦 MRAppMaster申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。第6步：NodeManager 为任务设置好运行环境后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务第7步：各个任务通过某个 RPC 协议向 MRAppMaster汇报自己的状态和进度，以让 MRAppMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 hive 下载地址 https://dlcdn.apache.org/hive/hive-2.3.9/ 数据仓库（英语：Data Warehouse，简称数仓、DW）,是一个用于存储、分析、报告的数据系统，是一个集成化的专业的数据分析平台，方便决策 数仓本身并不产生数据，数据来自于外部系统，同时不消费数据，结果给其他外部应用使用。所以才叫仓库而不是工厂 联机事务处理系统（OLTP）正好可以满足上述业务需求开展, 其主要任务是执行联机事务处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理，并在很短的时间内给出处理结果，关系型数据库（RDBMS）是OLTP典型应用 为什么不在数据库里分析？数据分析也是对数据进行读取操作，会让读取压力倍增，OLTP仅存储数周或数月的数据，数据分散在不同系统不同表中，字段类型属性不统一 数仓特性： 面向主题：确定分析对象集成性：各个数据源需要集成到数仓，并且各个系统对某一主题内部的命名与格式不同，所以不同数据源到数仓时需要去除这些不一致，经过ETL（抽取，转换，加载）的操作非易变性：只分析，很少不修改内容时变性：离线分析往往分析过去的数据，数据会与时间有关，所以就有些T+1报表（第二天分析前一天） 4.2 HIVE Hive的存储用的HDFS，计算用的MR，本身并没有干什么，主要提供了一种SQL来进行数据分析的能力，Hive核心是将HQL转换为MapReduce程序，然后将程序提交到Hadoop群集执行 发请求给Driver源数据检查是否有元数据是否存在，不存在直接返回，有就编译优化生成jar，driver提jar给hadoop执行 CLI（Command Line Interface）：用户可以使用Hive自带的命令行接口执行Hive QL、设置参数等功能 JDBC/ODBC：用户可以使用JDBC或者ODBC的方式在代码中操作Hive Web GUI：浏览器接口，用户可以在浏览器中对Hive进行操作（2.2之后淘汰） Thrift : Thrift服务运行客户端使用Java、C++、Ruby等多种语言，通过编程的方式远程访问Hive Driver：Hive Driver是Hive的核心，其中包含解释器、编译器、优化器等各个组件，完成从SQL语句到MapReduce任务的解析优化执行过程 解释器：调用语法解释器和语义分析器将SQL语句转换成对应的可执行的java代码或者业务代码编译器：将对应的java代码转换成字节码文件或者jar包优化器：从SQL语句到java代码的解析转化过程中需要调用优化器，进行相关策略的优化，实现最优的 查询性能执行器：当业务代码转换完成之后，需要上传到MapReduce的集群中执行 metastore Hive的元数据存储服务，一般将数据存储在关系型数据库中，为了实现Hive元数据的持久化操作，Hive的安装包中自带了Derby内存数据库，但是在实际的生产环境中一般使用mysql来存储元数据 why：Derby 内存 元数据不可以持久化了，意外这每次重启都会有数据加载的过程；MYSQL 元数据可以持久化了 官方提供了两种方式实现元数据管理中心 第一种：元数据存储服务（metaStore Server）没有与HIVE分离第二种：元数据存储服务（metaStore Server）与HIVE核心分离 ，这个单独抽离的服务为Thrift，Thrift使得HIVE核心和元数据存储（metaStore）解耦，MYSQL可以变为Oracle；并且单独抽离出来的Thrift，可以给其他提供服务（比如spark-sql） 一般使用DataGrip和DBeaver这种可视化来方便开发
规则读取：默认是按行读取数据。key是每一行的起始位置偏移量，value是本行的文本内容。（TextInputFormat）
每读取解析出来的一个
3、YARN
App Master 没有资源管理，不是长启动任务调度
RPC 向 MRAppMaster查询应用程序的当前运行状态。第8步：应用程序运行完成后，MRAppMaster向 ResourceManager 注销并关闭自己 3.2 调度策略 FIFO Capactiy Fair Fair schedule易容配置，不适合有优先顺序的任多组织共享集群资源，每个组织分配专门的队列。，但容易产生浪费随着时间的流逝任务获取公平的资源
hive 文档： https://cwiki.apache.org/confluence/display/Hive/AdminManual
HIVE可以将存储在Hadoop文件中的结构化、半结构化数据文件映射为一张数据库表，基于表提供了一种类似SQL的查询模型，称为Hive查询语言（HQL），用于访问和分析存储在Hadoop文件中的大型数据集
HIVE也有局限性，结构化、半结构化的要求，无结构的图片，视频很难做映射。这种映射是需要存储，存储进去的往往就是一些元数据信息
4.4 HIVE 可用客户端