大数据：Bigdata
大数据时代：大数据、云计算、物联网
大数据：技术方面，存储、计算、网络的发展，解决了海量数据的存储、处理、传输问题；数据产生方式方面：运营式系统产生（销售系统、ERP系统等）、用户原创（博客、微博、论坛等）产生、感知式系统产生（主要是物联网），特别是物联网的出现，如各种监控系统，数据无时无刻都在不停产生，并且数量巨大。
大数据具有四个典型特性，前面了解过，即4V：
Volume：大量化； Variety：多样化； Velocity：快速化； Value：价值密度低。
数据分类为：
结构化数据：有约束的，有元数据；
半结构化数据：有元数据；
非结构化数据：没有元数据；
大数据背景下的关键技术，主要包括分布式存储和分布式处理。分布式存储解决海量数据存储的问题。分布式处理解决了单台计算机无法满足实时处理需求的问题。都是使用分布式来解决问题，实际上，就是常说的横向扩展。
大数据的存储与处理技术，源于Google的三篇论文：
2003年：The Google File System,GFS，完成分布式存储；
2004年：MapReduce: Simplified Data Processing On Large Cluster，分布式并行处理；
2006年：BigTable：A Distributed Storage System for Structure Data，分布式数据库；
apache对上述论文的实现：
HDFS + MapReduce = Hadoop ， HBase --> BigTable
HDFS --> GFS , MapReduce --> MapReduce
Apache Hadoop是由Apache软件基金会开发的开源分布式计算框架，主要用于大规模数据集的存储与处理。其核心模块包括Hadoop Common基础工具库、HDFS分布式文件系统、YARN资源管理平台和MapReduce并行计算模型。
对于分布式并行处理，涉及大数据处理的计算模式，可以分为四种：批处理、流计算、图计算和查询分析计算。MapReduce就是一种批处理的计算模式产品。不同的计算模式，主要是用于处理不同领域的问题，因为不同领域的问题，对处理的要求不同，如批处理对实时性要求不高，处理的数量特别巨大，适用于事后的分析，如实时计算，则对处理的反应速度有很高的要求，强调时效性，如交互式计算，则对查询分析、人机交互有特别要求。
Hadoop的核心技术是分布式文件系统HDFS和分布式并行计算框架MapReduce。HDFS（分布式文件系统），负责存数据，把大文件切成默认128MB的数据块，分别存储到多台机器上，并默认复制3份副本，防止机器故障导致数据丢失。MapReduce（分布式计算框架）：负责算数据。采用"分而治之"的思路，把计算任务分给多台机器并行处理，再汇总结果。最初的MapReduce还是资源调度系统，负责管资源。后来将此功能进行了分离，产生了YARN资源调度系统，即Yet Another Resource Negotiator，又一个资源协商器。于是MapReduce专负责计算，YARN负责资源调度。
Hadoop的HDFS（包括GFS）是有中心节点的架构，有一个节点专门存储元数据，叫做NameNode，NN，其他节点存储数据，叫做DataNode，DN。
到今天，Hadoop已经发展了三个主要版本，分别是版本1.x，版本2.x和版本3.x，其中版本1和2的架构区别很大，2和3感觉架构相同，只是不同层上的改进。只针对版本1和2讨论。从粗粒度到细粒度的研究。
1.0版本主要分为两个层次，分别是HDFS层和MapReduce层，2.0版本则分为了三个层次，分别是HDFS层、YARN层和MapReduce层，1.0中的MapReduce功能包含了2.0版中的YARN功能，也就是资源管理的功能，导致其整体臃肿，效率不高，所以2.0中单独独立出来，好处是减轻了MapReduce的负担，提高MapReduce的效率，同时提高了资源管理的效率，还为功能扩展提供空间，因为资源管理单独出来，其不但可以调度MapReduce作业，还可以调度其他的作业/应用，所以2.0中，YARN上面不但有MapReduce层，还有其他应用层。
用大白话描述一下Hadoop的架构，就是说现在的数据量特别的巨大，不管是存储也好，处理也好，一台机器无论其性能怎么升级，都很难应付了，或者说即使能应付，付出的成本也高的离谱。从数据存储看，当前使用的存储盘容量一般是Tb级别的，数据中心可能用的是几十Tb至一百几十Tb容量的盘，但是现在的大数据数据量基本以Pb起步，很多都超Eb，1Pb=1000Tb，1Eb=1000Pb，Hadoop的HDFS就是来处理存储海量数据这个工作的，就是不增加单盘的容量，而是增加盘的数量，将大数据分散的保存到几百上千或上万台机器的磁盘中，这就形成了存储集群。数据存储解决了，但是在数据的处理上，一台机器要么无法处理这么大量的数据，要么就是处理起来慢的无法忍受，计算统计一个数据，要等上一两个月，这基本等于无用。所以解决的方法，同存储是一样的，就是将计算任务分配到多台机器/节点上，一个节点处理一部分，最后各节点结果再汇总，这就形成了处理/计算集群。数据分布存储在各节点，正好将计算也分布到对应数据所在节点，数据也无需再搬家，处理速度加快。
总体的思想就是水平/横向扩展，再进入每层，看其要解决哪些问题，最后形成本层解决方案。
对于存储，即HDFS，其对外要提供一个统一的访问点，数据分散保存到各个节点上，需要知道各个节点到底存了哪些数据块，于是，就形成了主从结构的存储系统，有一个节点作为master节点，其对外提供统一的储存/访问管理接口，对内要负责把要存储的数据分片（shard）、每片保存到哪个节点上，这些信息就是元数据信息，master负责保存这些信息，这个master节点叫做NameNode，名称节点，简称NN，存储具体数据块的节点，是slave节点，从节点，叫做DataNode，数据节点，简称DN。为了保证数据的安全，存储的数据块除了在一个DN上保存一个主版本，还会在其他DN上保存副本，HDFS默认保存三份，即一个DN保存主本，其他两个DN在各保存一份副本。因为master节点，也就是NN节点保存了所有数据的存储信息，其一旦出现问题，则整个存储数据将无法访问，所以为了安全，对master做一个热备份，即还有一个辅助节点，叫做SecondaryNameNode，第二名称节点，简称SNN。NN是一个内存文件系统，所有的元数据保存在内存中，操作也是在内存中完成，为了安全，需要将内存中的信息保存到磁盘上，即序列化，保存的文件叫做FSImage，FSImage并非NameNode运行时实时生成，而是通过Checkpoint机制定期合并EditLog后生成，避免NameNode直接将全量内存元数据频繁写入磁盘带来的性能损耗。NameNode的元数据持久化体系需要配套一个EditLog文件，它以追加写的方式实时记录所有元数据修改操作，本身不属于序列化镜像文件，仅作为事务日志存在，二者配合共同保障HDFS元数据的可靠性。
对于NN节点，2.0版本又发展了一个高可用架构：
对于MapReduce层，其实现也大体如HDFS，总体思想也是水平扩展，将一个计算任务，在Hadoop1.0中叫做一个作业，复制到多个节点同时运行，当然，每个节点处理的数据是不同的，但处理的程序是相同的，最后，每个节点的处理结果再汇总，得到最后的结果。
MapReduce1.0的架构图：
MapReduce1.0中，也是设计为主从架构的，即Master/Slave架构，有两类守护进程控制作业的执行过程，即一个JobTracker和多个TaskTracker。JobTracker，作业跟踪器，协调作业的运行，负责资源管理和作业调度；TaskTracker，任务跟踪器，定期向JobTracker汇报本节点的健康状况、资源使用情况、任务执行情况以及接受来自JobTracker的命令并执行。JobTracker是通过Task Scheduler完成任务的调度分配，其资源的分配，是以Slot为单位进行分配的。Slot是MapReduce1.0中的资源管理体系的核心抽象，是JobTracker分配集群计算资源的基本单位，
Slot 是 MapReduce 1.0 中对节点计算资源的静态逻辑划分单位，它将TaskTracker节点上的 CPU、内存等物理资源预先切分成固定数量的两类槽位：
Map Slot：专门用于运行 Map 任务的资源槽。
Reduce Slot：专门用于运行 Reduce 任务的资源槽。
每个Slot代表一个可被调度的计算配额，默认配置下单个Slot 通常对应1~2个CPU核心和2~4GB内存，集群管理员可在 mapred-site.xml 中通过参数自定义单节点的 Slot 总数。
Slot的运行机制，主要包括静态预分配、专属任务绑定、调度与心跳机制：
静态预分配：集群部署阶段，管理员就需要提前在每个TaskTracker节点配置 mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum两个参数，直接固定该节点上Map Slot和Reduce Slot的总数量，运行过程中无法动态调整。
专属任务绑定：Map Slot 只能运行 Map 任务，Reduce Slot 只能运行 Reduce 任务，两类槽位完全隔离，无法跨类型复用。即使节点上所有 Reduce Slot 都被占满，Map Slot 完全空闲，也不能用空闲的 Map Slot 运行 Reduce 任务。
调度与心跳机制：TaskTracker 定期向 JobTracker 发送心跳，上报当前节点的空闲 Slot 数量；JobTracker 收到心跳后，根据作业的任务调度需求，将待运行的 Map/Reduce 任务分配给拥有对应空闲 Slot 的 TaskTracker，任务启动后占用该 Slot，直到任务执行完成后 Slot 才会被释放，重新进入可调度池。
Slot 机制的固有缺陷：资源利用率极低、资源粒度僵化、扩展性瓶颈。
Slot的这些固有问题，直接推动了Hadoop 2.0 YARN 架构的诞生，用可动态定制资源规格的 Container模型替代了MapReduce 1.0 的静态 Slot 机制。
MapReduce1.0作业执行、资源调度的详细流程图：
具体流程：
1).客户端通过submit()方法提交作业；
2).submit()方法会创建一个内部的JobSummiter实例，并且调用submitJobInternal()方法提交作业，JobSummiter向JobTracker请求一个新的作业ID，该实例会检查本次作业是否可执行（比如：检查输出路径，计算作业的输入分片等），如果可执行会将运行所需要的作业资源（JAR、配置文件，分片信息等）上传到文件系统（HDFS）。分片信息是在客户端本地完成的，JobSubmitter 在作业提交前的预检查阶段，会主动调用 InputFormat.getSplits() 方法，遍历 HDFS 上的输入文件，按照预设的分片规则（默认与 HDFS Block 大小对齐）计算出所有逻辑分片。生成的分片信息不是实际数据，仅记录每个分片的起始偏移量、数据长度、所在节点位置等元数据，最终会序列化生成一个切片规划文件，上传到 HDFS 的作业 Staging 目录中。
3).JobTracker接受到提交任务请求后，会放到一个内部队列里中，交由作业调度器（Job Scheduler）进行调度并初始化任务，从文件系统中获取客户端已经准备好的输入分片（即切片规划文件），（每个分片计算一个map），reduce任务数量由setNumReduceTask()方法设置。
4).TaskTracker会定期向JobTracker发送"心跳"，表明TaskTracker是否存活，同时"心跳"是两者之间的消息通道，当TaskTracker空闲后，会通过"心跳"发送给JobTracker，然后JobTracker会为它分配新的任务。
5).TaskTracker接收到JobTracker分配的任务后，从分布式文件系统（即HDFS）中，将JAR文件复制到本地，开始运行任务。任务运行过程中TaskTracker会定期通过"心跳"会将任务的状态及运行情况告知JobTracker
6).JobTracker接收到最后一个任务已完成的通知后，Job会打印一条消息告知用户，然后从waitForCompletion()方法返回，同时Job的统计信息及计数值也会打印到控制台或其他设定的输出。
分布式文件系统的作用：除了进行分布式文件存储，还用来在其他实体间共享作业文件；
分片的使用方：
JobTracker：拿到作业提交请求后，读取 Staging 目录中的分片元数据，根据分片的总数量确定需要启动的Map Task总数，同时结合分片的节点位置信息，生成本地化调度策略，尽可能将 Map Task分配到分片数据所在的TaskTracker节点上，减少数据传输开销。
Map Task：TaskTracker 启动 Map 任务进程后，会从HDFS下载对应的分片元数据，根据分片记录的位置信息，直接读取对应HDFS Block上的实际数据，开始执行 Map 阶段的计算逻辑。
分片的生成和使用逻辑，是 MapReduce 实现数据本地化计算、并行拆分任务的核心基础。
MapReduce2.0中资源管理与调度功能被单独剥离出来，形成了YARN。YARN是一个纯粹的资源管理调度框架，而被剥离了资源管理调度功能的MapReduce变成了MRv2，MRv2是运行在YARN上的一个纯粹的计算框架。
YARN的提出并非仅仅为了解决MapReduce 1.0中存在的问题，YARN有着更加伟大的目标，即实现"一个集群多个框架"，也就是说在一个集群上部署一个统一的资源管理调度框架YARN，打造以YARN为核心的生态圈，在YARN之上除了可以部署MapReduce计算框架，还可以部署其他各种计算框架，如离线计算框架MapReduce（也称为批处理计算）、DAG计算框架Tez、流式计算框架Storm、内存计算框架Spark等，由YARN为这些计算框架提供统一的资源管理调度服务，并且能够根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩。
YARN架构图，YARN的组件及其功能
YARN中的重要概念：
ResourceManager （RM）：一个全局的资源管理器，负责整个系统的资源管理和分配。负责对各个NodeManager上的资源进行统一管理和调度。
NodeManager （NM）：节点管理器，在群集节点中创建和销毁容器来管理特定节点中的作业或工作流。
ApplicationMaster （AM/App Mstr）：应用程序管理器，负责管理一个具体作业的整个生命周期 ，向集群申请资源并协调任务执行 。具体功能包括申请资源、二次调度、任务管理、监控容错、状态汇报。常见的实现有：
MRAppMaster：YARN自带的MapReduce应用程序ApplicationMaster实现，管理MapReduce 作业生命周期 。
distributedshell：运行Shell命令或脚本的ApplicationMaster实现。
框架定制：Spark on YARN、Storm on YARN、Tez on YARN 等计算框架均可实现自己的 ApplicationMaster，适配不同的编程模型 。
Client ：客户
Container ：容器，资源的抽象
YARN 总体上仍然是 Master/Slave主从结构，在整个资源管理框架中，ResourceManager （RM）为 Master， NodeManager（NM） 为 Slave，RM负责对各个NM上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster（App Mstr），它负责向RM申请资源，并要求NM启动可以占用一定资源的任务。由于不同的 App Mstr被分布到不同的节点上，因此它们之间不会相互影响。所以，在MapReduce2.0中，客户端请求运行的程序不叫作业（Job）了，而是叫做一个应用（Application），RM不会管理具体的Application，而是在某个NM节点上生成一个App Mstr，来管理具体应用的执行，这个App Mstr也需要运行在一个Container中，其后在其他一个或多个NM中启动任务的工作也是由App Mstr完成。而执行应用的任务，如一个MapReduce应用，启动多个Map Task和Reduce Task，也是需要在Container中运行。
YARN主要包含四大模块：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）和Container。
ResourceManager ：RM主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager， ASM）。
调度器（Scheduler）： 根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
需要注意的是，该调度器是一个"纯调度器"，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的 ApplicationMaster 完成。
调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念"资源容器"（Resource Container，简称 Container）表示， Container 是一个动态资源分配单位，它将内存、 CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器， YARN 提供了多种直接可用的调度器，比如 FairScheduler 和 Capacity Scheduler 等。
应用程序管理器（Applications Manager）： 负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。
ApplicationMaster ：用户提交的每个应用程序均会包含一个 AM，在NM中启动一个叫做App Mstr的Container，主要功能包括：
与 RM 调度器协商以获取资源（用 Container 表示）；
将得到的任务进一步分配给内部的任务；
与 NM 通信以启动 / 停止任务；
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
当前 YARN 自带了两个 AM 实现，一个是用于演示 AM 编写方法的例程序 distributedshell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本 ；另一个是运行 MapReduce 应用程序的 AM---MRAppMaster，一些其他的计算框架也有对应的 AM，比如 Spark、Flink 等。
NodeManager ：NM（NodeManager） 是每个节点上的资源和任务管理器，一方面，它会定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态；另一方面，它接收并处理来自 AM 的 Container 启动/停止等各种请求。
Container ：Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当 AM 向 RM 申请资源时， RM 为 AM 返回的资源便是用 Container表示的。 YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。需要注意的是， Container 不同于 MRv1 中的 slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。当下， YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离 。
YARN 的工作流程分为以下几个步骤：
第 1 步： 用户向 YARN 中提交应用程序，其中包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
第 2 步： ResourceManager 为该应用程序分配第一个 Container，并与对应的 NodeManager 通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster。
第 3 步： ApplicationMaster 首先向 ResourceManager 注册，这样用户可以直接通过 ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤 4~7。
第 4 步： ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源。
第 5 步： 一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。
第 6 步： NodeManager 为任务设置好运行环境（包括环境变量、 JAR 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
第 7 步： 各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状态。
第 8 步： 应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。
上图中涉及到ContainerLauncher，它是Hadoop YARN NodeManager内部的核心组件，专门负责集群节点上YARN容器的启动执行，是连接NodeManager与实际计算进程的关键执行单元。
它是NodeManager中ContainerManager服务的核心子模块，可通过配置项yarn.nodemanager.containers-launcher.class指定自定义实现，默认使用官方自带的标准实现类。
它的核心功能包括：
容器进程启动：接收来自ApplicationMaster的容器启动指令，完成容器运行环境初始化、依赖文件本地化，最终拉起Map/Reduce等各类任务进程。
生命周期管控：配合ContainerManager完成容器的启动、运行状态跟踪、异常终止全流程管理，保障容器按YARN规范执行。
故障恢复支持：在NodeManager重启后，可从本地LevelDB中读取持久化的容器状态信息，恢复未完成的容器启动任务，避免节点故障后任务完全丢失。
资源隔离落地：依托YARN的资源抽象规范，将Container中封装的CPU、内存等多维度资源约束，映射为节点上实际进程的资源隔离规则，保障容器资源不被抢占。
在YARN的完整运行链路中，ApplicationMaster向RM申请到分配的Container后，会通过RPC通知对应节点的NodeManager，最终由ContainerLauncher完成容器的实际启动，让各类计算框架的任务进程能在分配好的资源空间内正常执行。
