Hadoop 基础 一
Hadoop是业界公认的一套行业大数据标准开源软件，在分布式环境下Hadoop能提供海量数据的处理能力。几乎所有主流厂商都围绕Hadoop技术开发工具、开源软件、商业化工具和技术服务。许多大型IT公司，如EMC、Microsoft、Intel、Teradata、Cisco都明显增加了Hadoop方面的投入。
hadoop擅长日志分析，facebook就用Hive来进行日志分析，2009年时facebook就有非编程人员的30%的人使用HiveQL进行数据分析；淘宝搜索中的自定义筛选也使用的Hive；利用Pig还可以做高级的数据处理，包括Twitter、LinkedIn 上用于发现您可能认识的人，可以实现类似Amazon.com的协同过滤的推荐效果。淘宝的商品推荐也是！在Yahoo！的40%的Hadoop作业是用pig运行的，包括垃圾邮件的识别和过滤，还有用户特征建模。
Hadoop 是一个由 Apache 基金会所开发的分布式系统基础架构。Hadoop具有可靠、高效、可伸缩的特点，主要用来解决海量数据的存储和海量数据的分析计算问题。利用Hadoop技术，用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。
总的来说Hadoop适合应用于大数据存储和大数据分析的应用，适合于服务器几千台到几万台的集群运行，支持PB级的存储容量。
Hadoop典型应用有：搜索、日志处理、推荐系统、数据分析、视频图像分析、数据保存等。
HDFS的设计特点是：
- 大数据文件，非常适合上T级别的大文件或者一堆大数据文件的存储，如果文件只有几个G甚至更小就没啥意思了。
- 文件分块存储，HDFS会将一个完整的大文件平均分块存储到不同计算器上，它的意义在于读取文件时可以同时从多个主机取不同区块的文件，多主机读取比单主机读取效率要高得多得都。
- 流式数据访问，一次写入多次读写，这种模式跟传统文件不同，它不支持动态改变文件内容，而是要求让文件一次写入就不做变化，要变化也只能在文件末添加内容。
- 廉价硬件，HDFS可以应用在普通PC机上，这种机制能够让给一些公司用几十台廉价的计算机就可以撑起一个大数据集群。
- 硬件故障，HDFS认为所有计算机都可能会出问题，为了防止某个主机失效读取不到该主机的块文件，它将同一个文件块副本分配到其它某几个主机上，如果其中一台主机失效，可以迅速找另一块副本取文件。
Hadoop的特点
- 扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。
- 成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。
- 高效率（Efficient）：通过分发数据，hadoop可以在数据所在的节点上并行地（parallel）处理它们，这使得处理非常的快速。
- 可靠性（Reliable）：hadoop能自动地维护数据的多份副本，并且在任务失败后能自动地重新部署（redeploy）计算任务。
Hadoop的核心是YARN,HDFS和Mapreduce
- HDFS: Hadoop Distributed File System 分布式文件系统
- YARN: Yet Another Resource Negotiator 资源管理调度系统
- Mapreduce：分布式运算框架
Hadoop生态圈
广义上来说，HADOOP 通常是指一个更广泛的概念——HADOOP 生态圈
说明：
HDFS（Hadoop分布式文件系统）
- 源自于Google发表于2003年10月的GFS论文，HDFS是GFS克隆版。
- HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。
- HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。
- HDFS提供了一次写入多次读取的机制，数据以块的形式，同时分布在集群不同的物理机器上。
Mapreduce（分布式计算框架）
- 源自于google发表于2004年12月的MapReduce论文，Hadoop MapReduce是google MapReduce 克隆版。
- MapReduce是一种分布式计算模型，用于进行大数据量的计算。它屏蔽了分布式计算框架细节，将计算抽象成map和reduce两部分。其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。
- MapReduce非常适合在大量计算机组成的分布式并行环境里进行数据处理。
Yarn(分布式资源管理器）
- YARN是下一代MapReduce，即MRv2，是在第一代MapReduce基础上演变而来的，主要是为了解决原始Hadoop扩展性较差，不支持多计算框架而提出的。
- Yarn是下一代 Hadoop 计算平台，yarn是一个通用的运行时框架，用户可以编写自己的计算框架，在该运行环境中运行。
用于自己编写的框架作为客户端的一个lib，在运用提交作业时打包即可。该框架为提供了以下几个组件：- 资源管理：包括应用程序管理和机器资源管理
- 资源双层调度
- 容错性：各个组件均有考虑容错性
- 扩展性：可扩展到上万个节点
HBASE（分布式列存数据库）
- 源自Google的Bigtable论文，发表于2006年11月，HBase是Google Bigtable克隆版
- HBase是一个建立在HDFS之上，面向列的针对结构化数据的可伸缩、高可靠、高性能、分布式和面向列的动态模式数据库。
- HBase采用了BigTable的数据模型：增强的稀疏排序映射表（Key/Value），其中，键由行关键字、列关键字和时间戳构成。
- HBase提供了对大规模数据的随机、实时读写访问，同时，HBase中保存的数据可以使用MapReduce来处理，它将数据存储和并行计算完美地结合在一起。
Zookeeper（分布式协作服务）
- 源自Google发表于2006年11月的Chubby论文，Zookeeper是Chubby克隆版
- 解决分布式环境下的数据管理问题：统一命名，状态同步，集群管理，配置同步等。
- Hadoop的许多组件依赖于Zookeeper，它运行在计算机集群上面，用于管理Hadoop操作。
HIVE（数据仓库）
- 由facebook开源，最初用于解决海量结构化的日志数据统计问题。
- Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行。通常用于离线分析。
- HQL用于运行存储在Hadoop上的查询语句，Hive让不熟悉MapReduce开发人员也能编写数据查询语句，然后这些语句被翻译为Hadoop上面的MapReduce任务。
Pig(ad-hoc脚本）
- 由yahoo!开源，设计动机是提供一种基于MapReduce的ad-hoc(计算在query时发生)数据分析工具
- Pig定义了一种数据流语言—Pig Latin，它是MapReduce编程的复杂性的抽象,Pig平台包括运行环境和用于分析Hadoop数据集的脚本语言(Pig Latin)。
- Pig编译器将Pig Latin翻译成MapReduce程序序列，将脚本转换为MapReduce任务在Hadoop上执行。通常用于进行离线分析。
Sqoop(数据ETL/同步工具）
- Sqoop是SQL-to-Hadoop的缩写，主要用于传统数据库和Hadoop之前传输数据。数据的导入和导出本质上是Mapreduce程序，充分利用了MR的并行化和容错性。
- Sqoop利用数据库技术描述数据架构，用于在关系数据库、数据仓库和Hadoop之间转移数据。
Flume（日志收集工具）
- Cloudera开源的日志收集系统，具有分布式、高可靠、高容错、易于定制和扩展的特点。
- Flume是一个可扩展、适合复杂环境的海量日志收集系统，当然也可以用于收集其他类型数据
- Flume将数据从产生、传输、处理并最终写入目标的路径的过程抽象为数据流，在具体的数据流中，数据源支持在Flume中定制数据发送方，从而支持收集各种不同协议数据。
- Flume数据流提供对日志数据进行简单处理的能力，如过滤、格式转换等。此外，Flume还具有能够将日志写往各种数据目标（可定制）的能力。
Mahout（数据挖掘算法库）
- Mahout起源于2008年，最初是Apache Lucent的子项目，它在极短的时间内取得了长足的发展，现在是Apache的顶级项目。
- Mahout的主要目标是创建一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。
- Mahout现在已经包含了聚类、分类、推荐引擎（协同过滤）和频繁集挖掘等广泛使用的数据挖掘方法。
- 除了算法，Mahout还包含数据的输入/输出工具、与其他存储系统（如数据库、MongoDB 或Cassandra）集成等数据挖掘支持架构。
Kafka（分布式消息队列）
- Kafka是Linkedin于2010年12月份开源的消息系统，它主要用于处理活跃的流式数据。
- 活跃的流式数据在web网站应用中非常常见，这些数据包括网站的pv、用户访问了什么内容，搜索了什么内容等。
- 这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。
Spark(内存DAG计算模型)
- Spark是一个Apache项目，它被标榜为“快如闪电的集群计算”。它拥有一个繁荣的开源社区，并且是目前最活跃的Apache项目。
- 最早Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架。
- Spark提供了一个更快、更通用的数据处理平台。和Hadoop相比，Spark可以让你的程序在内存中运行时速度提升100倍，或者在磁盘上运行时速度提升10倍
GraphX(图计算模型）
Spark GraphX最先是伯克利AMPLAB的一个分布式图计算框架项目，目前整合在spark运行框架中，为其提供BSP大规模并行图计算能力。
MLib（机器学习库）
Spark MLlib是一个机器学习库，它提供了各种各样的算法，这些算法用来在集群上针对分类、回归、聚类、协同过滤等。
Streaming（流计算模型）
Spark Streaming支持对流数据的实时处理，以微批的方式对实时数据进行计算
Giraph(图计算模型)
- Apache Giraph是一个可伸缩的分布式迭代图处理系统， 基于Hadoop平台，灵感来自 BSP (bulk synchronous parallel) 和 Google 的 Pregel。
- 最早出自雅虎。雅虎在开发Giraph时采用了Google工程师2010年发表的论文《Pregel：大规模图表处理系统》中的原理。后来，雅虎将Giraph捐赠给Apache软件基金会。
- 目前所有人都可以下载Giraph，它已经成为Apache软件基金会的开源项目，并得到Facebook的支持，获得多方面的改进。
Oozie(工作流调度器）
- Oozie是一个可扩展的工作体系，集成于Hadoop的堆栈，用于协调多个MapReduce作业的执行。它能够管理一个复杂的系统，基于外部事件来执行，外部事件包括数据的定时和数据的出现。
- Oozie工作流是放置在控制依赖DAG（有向无环图 Direct Acyclic Graph）中的一组动作（例如，Hadoop的Map/Reduce作业、Pig作业等），其中指定了动作执行的顺序。
- Oozie使用hPDL（一种XML流程定义语言）来描述这个图。
Mesos（分布式资源管理器）
- Mesos诞生于UC Berkeley的一个研究项目，现已成为Apache项目，当前有一些公司使用Mesos管理集群资源，比如Twitter。
- 与yarn类似，Mesos是一个资源统一管理和调度的平台，同样支持比如MR、steaming等多种运算框架。
Tachyon（分布式内存文件系统）
- Tachyon诞生于UC Berkeley的AMPLab。
- Tachyon（/'tæki:ˌɒn/ 意为超光速粒子）是以内存为中心的分布式文件系统，拥有高性能和容错能力，能够为集群框架（如Spark、MapReduce）提供可靠的内存级速度的文件共享服务。
Tez(DAG计算模型)
- Tez是Apache最新开源的支持DAG作业的计算框架，它直接源于MapReduce框架，核心思想是将Map和Reduce两个操作进一步拆分，即Map被拆分成Input、Processor、Sort、Merge和Output， Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等，这样，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的DAG作业。
- 目前hive支持mr、tez计算模型，tez能完美二进制mr程序，提升运算性能。
Phoenix（hbase sql接口）
Apache Phoenix 是HBase的SQL驱动，Phoenix 使得Hbase 支持通过JDBC的方式进行访问，并将你的SQL查询转换成Hbase的扫描和相应的动作。
ranger(安全管理工具）
Apache ranger是一个hadoop集群权限框架，提供操作、监控、管理复杂的数据权限，它提供一个集中的管理机制，管理基于yarn的hadoop生态圈的所有数据权限。
knox（hadoop安全网关）
Apache knox是一个访问hadoop集群的restapi网关，它为所有rest访问提供了一个简单的访问接口点，能完成3A认证（Authentication，Authorization，Auditing）和SSO（单点登录）等
falcon（数据生命周期管理工具）
Apache Falcon 是一个面向Hadoop的、新的数据处理和管理平台，设计用于数据移动、数据管道协调、生命周期管理和数据发现。它使终端用户可以快速地将他们的数据及其相关的处理和管理任务“上载（onboard）”到Hadoop集群。
Ambari（安装部署配置管理工具）
Apache Ambari 的作用来说，就是创建、管理、监视 Hadoop 的集群，是为了让 Hadoop 以及相关的大数据软件更容易使用的一个web工具。
Hadoop架构
- Hadoop1.0版本两个核心：HDFS+MapReduce
- Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce
- Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。
主从结构
- 主节点， namenode
- 从节点，有很多个: datanode
namenode负责：
- 接收用户操作请求
- 维护文件系统的目录结构
- 管理文件与block之间关系，block与datanode之间关系
datanode负责：
- 存储文件
- 文件被分成block存储在磁盘上
- 为保证数据安全，文件会有多个副本
Secondary NameNode负责：
- 合并fsimage和edits文件来更新NameNode的metedata
核心概念
rack
机架
client
客户端，凡是通过API或指令操作的一端都可以看做是客户端
blockSize
数据块。Hadoop1.0：64MB。Hadoop2.0 ：128MB。
fsimage、edits
fsimage 文件，记录元数据信息的文件
edits文件，记录元数据信息改动的文件。只要元数据发生变化，这个edits文件就会有对应记录。
fsimage和edits文件会定期做合并，这个周期默认是3600s。fsimage根据edits里改动记录进行元数据更新。
元数据信息如果丢失，HDFS就不能正常工作了。
hadoop namenode -format 这个指令实际的作用时，创建了初始的fsimage文件和edits文件。
NameNode
简介
名字节点。要管理元数据信息（Metadata），注意，只存储元数据信息。
namenode对于元数据信息的管理，放在内存一份，供访问查询，也会通过fsimage和edits文件，将元数据信息持久化到磁盘上。Hadoop1.0版本利用了SecondaryNamenode做fsimage和edits文件的合并，但是这种机制达不到热备的效果。Hadoop1.0的namenode存在单点故障问题。
namenode是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。接收用户的操作请求。
管理元数据信息，文件名，文件大小，文件块信息等。
namdenode把元数据信息存到内存里，为了快速查询，此外为了应对服务宕机而引起的元数据丢失，也要持久化到本地文件里。
namdenode不存储具体块数据，只存储元数据信息；datanode用于负责存储块数据。
文件包括：
- fsimage：元数据镜像文件。存储某一时段NameNode内存元数据信息。
- edits：操作日志文件。
- fstime：保存最近一次checkpoint的时间。
工作特点
NameNode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，NameNode首先会写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，并且向客户端返回。
Hadoop会维护一个fsimage文件，也就是NameNode中metedata的镜像，但是fsimage不会随时与NameNode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。Secondary NameNode就是用来合并fsimage和edits文件来更新NameNode的metedata的。
checkpoint的时机
fs.checkpoint.period：指定两次checkpoint的最大时间间隔，默认3600秒。
fs.checkpoint.size：规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。
namenode工作职责：
1.要知道管理有哪些机器节点，即有哪些datanode。比如ip信息等。
2.要管理文件信息，文件名、文件多大、文件被切成几块、以及每一块的存贮位置信息（存在哪个datanode节点上了），即管理元数据信息。
3.要有一个机制要知道集群里datanode节点的状态变化。可以rpc心跳机制来做到。
4.namenode存在单点故障问题，可以再引入一台管理者节点。
5.datanode挂掉后，可能数据就丢失，文件就不完整了，要有一个备份机制，一般来说，一个文件块，有3个备份，本机一份，同一机架的其他datanode有一份，另外一机器的机器上有一份。
SecondaryNameNode
简介
HA的一个解决方案。但不支持热备。配置即可。
执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage.
默认在安装在NameNode节点上，但这样…不安全！
负责将fsimage文件定期和edits文件做合并，合并之后，将合并后的元数据文件fsimage传给namenode。这个SN相当于namenode辅助节点。
Hadoop集群最开始启动的时候，创建Fsimage和edits文件，这个namenode做的，此外，namenode会做一次文件合并工作，这么做的目的是确保元数据信息是最新的，以为上次停集群的时候，可能还没来的及做合并。但以后的合并工作，就交给SN去做了。这种SN机制是Hadoop1.0的机制。
结论:Hadoop1.0的SN达不到热备效果，达不到元数据的实时更新，也就意味着了当namenode挂了的时候，元数据信息可能还会丢失，所以，Hadoop1.0版本的namenode还是单点故障问题。
工作流程
（1）secondary通知namenode切换edits文件；
（2）secondary从namenode获得fsimage和edits(通过http)；
（3）secondary将fsimage载入内存，然后开始合并edits；
（4）secondary将新的fsimage发回给namenode；
（5）namenode用新的fsimage替换旧的fsimage；
DataNode
数据节点。用于存储文件块。为了防止datanode挂掉造成的数据丢失，对于文件块要有备份，一个文件块有三个副本。
提供真实文件数据的存储服务。
文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block.
dfs.block.size
不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间;
Replication:多复本。默认是三个。