Kun

Kun

IT学徒、技术民工、斜杠青年,机器人爱好者、摄影爱好 PS、PR、LR、达芬奇潜在学习者

共 243 篇文章

链接

Kun's Blog

　　本篇主要内容为分布式计算框架Hadoop

Hadoop

https://chu888chu888.gitbooks.io/hadoopstudy/content/Content/12/chapter12.html

Hadoop是一个开源的框架，可编写和运行分布式应用处理大规模数据，是专为离线和大规模数据分析而设计的，并不适合那种对几个记录随机读写的在线事务处理模式。Hadoop=HDFS（文件系统，数据存储技术相关）+ Mapreduce（数据处理），Hadoop的数据来源可以是任何形式，在处理半结构化和非结构化数据上与关系型数据库相比有更好的性能，具有更灵活的处理能力，不管任何数据形式最终会转化为key/value，key/value是基本数据单元。用函数式变成Mapreduce代替SQL，SQL是查询语句，而Mapreduce则是使用脚本和代码，而对于适用于关系型数据库，习惯SQL的Hadoop有开源工具hive代替。

Hadoop就是一个分布式计算的解决方案.

hadoop的工作

hadoop擅长日志分析，facebook就用Hive来进行日志分析，2009年时facebook就有非编程人员的30%的人使用HiveQL进行数据分析；淘宝搜索中的自定义筛选也使用的Hive；利用Pig还可以做高级的数据处理，包括Twitter、LinkedIn上用于发现您可能认识的人，可以实现类似Amazon.com的协同过滤的推荐效果。淘宝的商品推荐也是！在Yahoo！的40%的Hadoop作业是用pig运行的，包括垃圾邮件的识别和过滤，还有用户特征建模。

历史演进

Hadoop1.0被称为第一代Hadoop，由分布式文件系统HDFS和分布式计算框架MapReduce组成，其中，HDFS由一个NameNode和多个DataNode组成，MapReduce由一个JobTracker和多个TaskTracker组成，对应Hadoop版本为0.20.x、0.21.X，0.22.x和Hadoop 1.x。其中0.20.x是比较稳定的版本，最后演化为1. x，变成稳定版本。0.21.x和0.22.x则增加了NameNode HA等新特性。

​ 第二代Hadoop被称为Hadoop2.0，是为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题而提出的，对应Hadoop版本为Hadoop 0.23.x和2.x。

​ 针对Hadoop1.0中NameNode HA不支持自动切换且切换时间过长的风险，Hadoop2.0提出了基于共享存储的HA方式，支持失败自动切换切回。

​ 针对Hadoop 1.0中的单NameNode制约HDFS的扩展性问题，提出了HDFS Federation机制，它允许多个NameNode各自分管不同的命名空间进而实现数据访问隔离和集群横向扩展。

​ 针对Hadoop 1.0中的MapReduce在扩展性和多框架支持方面的不足，提出了全新的资源管理框架YARN，它将JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现。其中，ResourceManager负责所有应用程序的资源分配，而ApplicationMaster仅负责管理一个应用程序。相比于 Hadoop 1.0，Hadoop 2.0框架具有更好的扩展性、可用性、可靠性、向后兼容性和更高的资源利用率以及能支持除了MapReduce计算框架外的更多的计算框架，Hadoop 2.0目前是业界主流使用的Hadoop版本。

使用场景

数据整合

称之为“企业级数据中心”或“数据湖”，这个想法是你有不同的数据源，你想对它们进行数据分析。这类项目包括从所有来源获得数据源（实时或批处理）并且把它们存储在hadoop中。有时，这是成为一个“数据驱动的公司”的第一步；有时，或许你仅仅需要一份漂亮的报告。“企业级数据中心”通常由HDFS文件系统和HIVE或IMPALA中的表组成。未来，HBase和Phoenix在大数据整合方面将大展拳脚，打开一个新的局面，创建出全新的数据美丽新世界。

​ 销售人员喜欢说“读模式”，但事实上，要取得成功，你必须清楚的了解自己的用例将是什么（Hive模式不会看起来与你在企业数据仓库中所做的不一样）。真实的原因是一个数据湖比Teradata和Netezza公司有更强的水平扩展性和低得多的成本。许多人在做前端分析时使用Tabelu和Excel。许多复杂的公司以“数据科学家”用Zeppelin或IPython笔记本作为前端。

专业分析

许多数据整合项目实际上是从你特殊的需求和某一数据集系统的分析开始的。这些往往是令人难以置信的特定领域，如在银行领域的流动性风险/蒙特卡罗模拟分析。在过去，这种专业的分析依赖于过时的，专有的软件包，无法扩大数据的规模经常遭受一个有限的功能集（大部分是因为软件厂商不可能像专业机构那样了解的那么多）。

​ 在Hadoop和Spark的世界，看看这些系统大致相同的数据整合系统，但往往有更多的HBase，定制非SQL代码，和更少的数据来源（如果不是唯一的）。他们越来越多地以Spark为基础。

Hadoop作为一种服务

在“专业分析”项目的任何大型组织（讽刺的是，一个或两个“数据整理”项目）他们会不可避免地开始感觉“快乐”（即，疼痛）管理几个不同配置的Hadoop集群，有时从不同的供应商。接下来，他们会说，“也许我们应该整合这些资源池，”而不是大部分时间让大部分节点处于资源闲置状态。它们应该组成云计算，但许多公司经常会因为安全的原因（内部政治和工作保护）不能或不会。这通常意味着很多Docker容器包。

流分析

很多人会把这个“流”，但流分析是不同的，从设备流。通常，流分析是一个组织在批处理中的实时版本。以反洗钱和欺诈检测：为什么不在交易的基础上，抓住它发生而不是在一个周期结束？同样的库存管理或其他任何。

​ 在某些情况下，这是一种新的类型的交易系统，分析数据位的位，因为你将它并联到一个分析系统中。这些系统证明自己如Spark或Storm与Hbase作为常用的数据存储。请注意，流分析并不能取代所有形式的分析，对某些你从未考虑过的事情而言，你仍然希望分析历史趋势或看过去的数据。

复杂事件处理

在这里，我们谈论的是亚秒级的实时事件处理。虽然还没有足够快的超低延迟（皮秒或纳秒）的应用，如高端的交易系统，你可以期待毫秒响应时间。例子包括对事物或事件的互联网电信运营商处理的呼叫数据记录的实时评价。有时，你会看到这样的系统使用Spark和HBase——但他们一般落在他们的脸上，必须转换成Storm，这是基于由LMAX交易所开发的干扰模式。

​ 在过去，这样的系统已经基于定制的消息或高性能，从货架上，客户端-服务器消息产品-但今天的数据量太多了。我还没有使用它，但Apex项目看起来很有前途，声称要比Storm快。

ETL

有时你想捕捉流数据并把它们存储起来。这些项目通常与1号或2号重合，但增加了各自的范围和特点。（有些人认为他们是4号或5号，但他们实际上是在向磁盘倾倒和分析数据。），这些几乎都是Kafka和Storm项目。Spark也使用，但没有理由，因为你不需要在内存分析。

更换或者增加SAS

SAS是精细，是好的但SAS也很贵，我们不需要为你的数据科学家和分析师买存储你就可以“玩”数据。此外，除SAS可以做或产生漂亮的图形分析外，你还可以做一些不同的事情。这是你的“数据湖”。这里是IPython笔记本（现在）和Zeppelin（以后）。我们用SAS存储结果。

​ 当我每天看到其他不同类型的Hadoop，Spark，或Storm项目，这些都是正常的。如果你使用Hadoop，你可能了解它们。几年前我已经实施了这些项目中的部分案例，使用的是其它技术。 如果你是一个老前辈太害怕“大”或“做”大数据Hadoop，不要担心。事情越变越多，但本质保持不变。你会发现很多相似之处的东西你用来部署和时髦的技术都是围绕Hadooposphere旋转的。

基本概念

hadoop中的构建模块

  • NameNode(名字节点)
  • DataNode(数据节点)
  • Secondary NameNode(次名字节点)
  • JobTracker(作业跟踪节点)
  • TaskTracker(任务跟踪节点)

HDFS系统的文件特征

  • 存储极大数目的信息（terabytes or petabytes），将数据保存到大量的节点当中。支持很大单个文件。
  • 提供数据的高可靠性，单个或者多个节点不工作，对系统不会造成任何影响，数据仍然可用。
  • 提供对这些信息的快速访问，并提供可扩展的方式。能够通过简单加入更多服务器的方式就能够服务更多的客户端。
  • HDFS是针对MapReduce设计的，使得数据尽可能根据其本地局部性进行访问与计算。

缺陷

  • 低延迟数据访问

    比如毫秒级 比如低延迟与高吞吐

  • 小文件存取

    占用NameNode大量内存 寻道时间超过读取时间

  • 并发写入/文件随机修改

    一个文件只能有一个写者 仅支持append

NameNode

NameNode是Hadoop守护进程中最重点的一个,Hadoop在分布式计算与分布式存付中都采用了主/从(Master/slave)结构.分布式存储系统被称为Hadoop文件系统,或简单称为HDFS.NameNode位于HDFS的主端,它指导DataNode执行底层的IO任务. 运行NameNode消耗大量的内存与IO资源.因此,为了减轻机器的负载,驻留NameNode的服务器通常不会存储用户数据或者执行MapReduce程序的计算任务.这意味着NameNode服务器不会同时是DataNode或者TaskTracker.

​ 不过NameNode的重要性也带来一个负面影响-Hadoop集群的失效.

DataNode

每一个集群上的从节点都会驻留一个DataNode守护进程,来执行分布式文件系统的繁重工作,将HDFS数据块读取或者写入到本地文件系统的实际文件中.当希望对HDFS文件进行读写时,文件被分割为多个块,由NameNode告知客户端每个数据块驻留在那个DataNode.客户端直接与DataNode守护进程通信,来处理与数据块相对应的本地文件.然而DataNode会与其他DataNode进行通信,复制这些数据块以实现冗余.

Secondary NameNode

​ SNN是一个监测HDFS集群状态的辅助守护进程,它通常独占一台服务器,该服务器不会运行其他DataNode或者TaskTracker守护进程.SNN与NameNode的不同在于它不接收或者记录HDFS的任何实时变化.相反它与NameNode通信,感觉集群所配置的时间间隔获取HDFS元数据的快照. ​ NameNode是Hadoop集群的单一故障点,而SNN的快照可以有助于减少停机的时间并降低数据丢失的风险.然而NameNode的失效处理需要人工的干预,即手动地重新配置集群,将SNN用作主要的NameNode.

JobTracker

JobTracker守护进程是应用程序和Hadoop之间的纽带.一旦提交代码到集群上,JobTracker就会确定执行计划,包括决定处理哪些文件,为不同的任务分配节点以及监控所有任务的运行.如果任务失败,JobTracker将自动重启任务,但所分配的节点可能会不同,同时受到预定义的重试次数限制. 每一个Hadoop集群只有一个JobTracker守护进程,它通常运行在服务器集群的主节点上.

TaskTracker

​ 与存储的守护进程一样,计算的守护进程也遵循主从架构:JobTracker作为主节点,监测MapReduce作业的整个执行过程,同时,TaskTracker管理各个任务在每个从节点上的执行情况. ​ TaskTracker的一个职责就是负责持续不断地与JobTracker通讯.如果JobTracker在指定的时间内没有收到来自TaskTracker的心跳,它会假定TaskTracker已经崩溃了,进而重新提交相应的任务到集群的其他节点中.

HDFS文件系统工作原理

Hadoop分布式文件系统(HDFS)是一种被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。它能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。要理解HDFS的内部工作原理，首先要理解什么是分布式文件系统。

分布式文件系统

多台计算机联网协同工作(有时也称为一个集群)就像单台系统一样解决某种问题，这样的系统我们称之为分布式系统。 分布式文件系统是分布式系统的一个子集，它们解决的问题就是数据存储。换句话说，它们是横跨在多台计算机上的存储系统。存储在分布式文件系统上的数据自动分布在不同的节点上。

分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理来自网络和其它地方的超大规模数据提供所需的扩展能力。

分离元数据和数据：NameNode和DataNode

存储到文件系统中的每个文件都有相关联的元数据。元数据包括了文件名、i节点(inode)数、数据块位置等，而数据则是文件的实际内容。

在传统的文件系统里，因为文件系统不会跨越多台机器，元数据和数据存储在同一台机器上。

为了构建一个分布式文件系统，让客户端在这种系统中使用简单，并且不需要知道其他客户端的活动，那么元数据需要在客户端以外维护。HDFS的设计理念是拿出一台或多台机器来保存元数据，并让剩下的机器来保存文件的内容。

NameNode和DataNode是HDFS的两个主要组件。其中，元数据存储在NameNode上，而数据存储在DataNode的集群上。NameNode不仅要管理存储在HDFS上内容的元数据，而且要记录一些事情，比如哪些节点是集群的一部分，某个文件有几份副本等。它还要决定当集群的节点宕机或者数据副本丢失的时候系统需要做什么。

存储在HDFS上的每份数据片有多份副本(replica)保存在不同的服务器上。在本质上，NameNode是HDFS的Master(主服务器)，DataNode是Slave(从服务器)。

HDFS写过程

NameNode负责管理存储在HDFS上所有文件的元数据，它会确认客户端的请求，并记录下文件的名字和存储这个文件的DataNode集合。它把该信息存储在内存中的文件分配表里。

例如，客户端发送一个请求给NameNode，说它要将“zhou.log”文件写入到HDFS。

过程：

第一步：客户端发消息给NameNode，说要将“zhou.log”文件写入。(如图1中的①)

第二步：NameNode发消息给客户端，叫客户端写到DataNode A、B和D，并直接联系DataNode B。(如图1中的②)

第三步：客户端发消息给DataNode B，叫它保存一份“zhou.log”文件，并且发送一份副本给DataNode A和DataNode D。(如图1中的③)

第四步：DataNode B发消息给DataNode A，叫它保存一份“zhou.log”文件，并且发送一份副本给DataNode D。(如图1中的④)

第五步：DataNode A发消息给DataNode D，叫它保存一份“zhou.log”文件。(如图1中的⑤)

第六步：DataNode D发确认消息给DataNode A。(如图1中的⑤)

第七步：DataNode A发确认消息给DataNode B。(如图1中的④)

第八步：DataNode B发确认消息给客户端，表示写入完成。(如图1中的⑥)

在分布式文件系统的设计中，挑战之一是如何确保数据的一致性。对于HDFS来说，直到所有要保存数据的DataNodes确认它们都有文件的副本时，数据才被认为写入完成。因此，数据一致性是在写的阶段完成的。一个客户端无论选择从哪个DataNode读取，都将得到相同的数据。

MPP与MapReduce

伴随着hadoop和MapReduce技术的流行，大数据的数据库中Hive和Spark等新型数据库脱颖而出；而另一个技术流派是基于传统的并行数据库技术演化而来的大规模并行处理（MPP）数据库比如GreenPlum和HAWQ 也在最近几年突飞猛进，这两种流派都有对应的比较知名的产品，他们都已得到了市场的认可。

MPP是一种海量数据实时分析架构，MPP作为一种不共享架构，每个节点运行自己的操作系统和数据库，节点之间信息交互只能通过网络连接实现，横向扩展是MPP数据库的主要设计目标，MPP数据库的核心仍是关系型数据库模型

MPP与Hadoop的区别与联系

其实MPP架构的关系型数据库与Hadoop的理论基础是极其相似的，都是将运算分布到节点中独立运算后进行结果合并。区别仅仅在于前者跑的是SQL，后者底层处理则是MapReduce程序。MPP也支持横向扩展，但是这种扩展一般是扩到100左右，而Hadoop一般可以扩展1000+，这也是主要区别之一。 原因可以从CAP理论上解释。因为MPP始终还是DB，一定要考虑C(Consistency)，其次考虑 A(Availability)，最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的，所有数据都是以文件存储，所以优先考虑的是P，然后是A，最后再考虑C。所以后者的可扩展性当然好于前者。

以下几个方面制约了MPP数据库的扩展

  • 高可用：MPP DB是通过Hash计算来确定数据行所在的物理机器(而Hadoop无需此操作)，对存储位置的不透明导致MPP的高可用很难办。
  • 并行任务：数据是按照Hash来切分了，但是任务没有。每个任务，无论大小都要到每个节点去走一圈。
  • 文件系统：数据切分了，但是文件数没有变少，每个表在每个节点上一定有一到多个文件。同样节点数越多，存储的表就越多，导致每个文件系统上有上万甚至十万多个文件。
  • 网络瓶颈：MPP强调对等的网络，点对点的连接也消耗了大量的网络带宽，限制了网络上的线性扩展(想象一台机器可能要给1000台机器发送信息)。更多的节点并没有提供更高的网络带宽，反而导致每个组节点间平均带宽降低。
  • 其他关系数据库的枷锁：比如锁、日志、权限、管理节点瓶颈等均限制了MPP规模的扩大。

但是MPP数据库有对SQL的完整兼容和一些事务处理功能，对于用户来说，在实际的使用场景中，如果数据扩展需求不是特别大，需要的处理节点不多，数据都是结构化数据，习惯使用传统RDBMS的很多特性的场景，可以考虑MPP如Greenplum/Gbase等。但如果有很多非结构化数据，或者数据量巨大，有需要扩展到成百上千个数据节点需求的，这个时候Hadoop是更好的选择。

Hadoop类型

生产环境中，hadoop的版本选择是一个公司架构之时，很重要的一个考虑因素。

Apache Hadoop：Apache Hadoop是一款支持数据密集型分布式应用并以Apache 2.0许可协议发布的开源软件框架。它支持在商品硬件构建的大型集群上运行的应用程序。Hadoop是根据Google公司发表的MapReduce和Google档案系统的论文自行实作而成。称为社区版Hadoop。

第三方发行版Hadoop：Hadoop遵从Apache开源协议，用户可以免费地任意使用和修改Hadoop，也正因此，市面上出现了很多Hadoop版本。其中有很多厂家在Apache Hadoop的基础上开发自己的Hadoop产品，比如Cloudera的CDH，Hortonworks的HDP，MapR的MapR产品等。

对比

Apache社区版本

  • 优点：

完全开源免费。 社区活跃 文档、资料详实

  • 缺点：

复杂的版本管理。版本管理比较混乱的，各种版本层出不穷，让很多使用者不知所措。 复杂的集群部署、安装、配置。通常按照集群需要编写大量的配置文件，分发到每一台节点上，容易出错，效率低下。 复杂的集群运维。对集群的监控，运维，需要安装第三方的其他软件，如ganglia，nagois等，运维难度较大。 复杂的生态环境。在Hadoop生态圈中，组件的选择、使用，比如Hive，Mahout，Sqoop，Flume，Spark，Oozie等等，需要大量考虑兼容性的问题，版本是否兼容，组件是否有冲突，编译是否能通过等。经常会浪费大量的时间去编译组件，解决版本冲突问题。

第三方发行版本（如CDH，HDP，MapR等）

  • 优点：

基于Apache协议，100%开源。 版本管理清晰。比如Cloudera，CDH1，CDH2，CDH3，CDH4等，后面加上补丁版本，如CDH4.1.0 patch level 923.142，表示在原生态Apache Hadoop 0.20.2基础上添加了1065个patch。 比Apache Hadoop在兼容性、安全性、稳定性上有增强。第三方发行版通常都经过了大量的测试验证，有众多部署实例，大量的运行到各种生产环境。 版本更新快。通常情况，比如CDH每个季度会有一个update，每一年会有一个release。 基于稳定版本Apache Hadoop，并应用了最新Bug修复或Feature的patch 提供了部署、安装、配置工具，大大提高了集群部署的效率，可以在几个小时内部署好集群。 运维简单。提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确，使运维工作简单，有效。

  • 缺点：

涉及到厂商锁定的问题。（可以通过技术解决）

Cloudera：最成型的发行版本，拥有最多的部署案例。提供强大的部署、管理和监控工具。Cloudera开发并贡献了可实时处理大数据的Impala项目。

Hortonworks：不拥有任何私有（非开源）修改地使用了100%开源Apache Hadoop的唯一提供商。Hortonworks是第一家使用了Apache HCatalog的元数据服务特性的提供商。并且，它们的Stinger开创性地极大地优化了Hive项目。Hortonworks为入门提供了一个非常好的，易于使用的沙盒。Hortonworks开发了很多增强特性并提交至核心主干，这使得Apache Hadoop能够在包括Windows Server和Windows Azure在内的Microsft Windows平台上本地运行。

MapR：与竞争者相比，它使用了一些不同的概念，特别是为了获取更好的性能和易用性而支持本地Unix文件系统而不是HDFS（使用非开源的组件）。可以使用本地Unix命令来代替Hadoop命令。除此之外，MapR还凭借诸如快照、镜像或有状态的故障恢复之类的高可用性特性来与其他竞争者相区别。该公司也领导着Apache Drill项目，本项目是Google的Dremel的开源项目的重新实现，目的是在Hadoop数据上执行类似SQL的查询以提供实时处理。

Amazon Elastic Map Reduce（EMR）：区别于其他提供商的是，这是一个托管的解决方案，其运行在由Amazon Elastic Compute Cloud（Amazon EC2）和Amzon Simple Strorage Service（Amzon S3）组成的网络规模的基础设施之上。除了Amazon的发行版本之外，你也可以在EMR上使用MapR。临时集群是主要的使用情形。如果你需要一次性的或不常见的大数据处理，EMR可能会为你节省大笔开支。然而，这也存在不利之处。其只包含了Hadoop生态系统中Pig和Hive项目，在默认情况下不包含其他很多项目。并且，EMR是高度优化成与S3中的数据一起工作的，这种方式会有较高的延时并且不会定位位于你的计算节点上的数据。所以处于EMR上的文件IO相比于你自己的Hadoop集群或你的私有EC2集群来说会慢很多，并有更大的延时。

当我们决定是否采用某个软件用于开源环境时，通常需要考虑以下几个因素：

（1）是否为开源软件，即是否免费。

（2） 是否有稳定版，这个一般软件官方网站会给出说明。

（3） 是否经实践验证，这个可通过检查是否有一些大点的公司已经在生产环境中使用知道。

（4） 是否有强大的社区支持，当出现一个问题时，能够通过社区、论坛等网络资源快速获取解决方法。

综上所述，考虑到大数据平台高效的部署和安装，中心化的配置管理，使用过程中的稳定性、兼容性、扩展性，以及未来较为简单、高效的运维，遇到问题低廉的解决成本。

个人建议使用第三方发行版本。

Hive

即使像Hadoop这样强大的工具,也不能满足每个人的需求,许多项目如雨后春笋般涌现出来,为特定的扩展了Hadoop,那些比较突出的并且得到很好维护的项目已经正式成为Apache Hadoop项目下的子项目. Hive是Hadoop家族中一款数据仓库产品，Hive最大的特点就是提供了类SQL的语法，封装了底层的MapReduce过程，让有SQL基础的业务人员，也可以直接利用Hadoop进行大数据的操作。就是这一个点，解决了原数据分析人员对于大数据分析的瓶颈。 让我们把Hive的环境构建起来，帮助非开发人员也能更好地了解大数据。

介绍

Hive起源于Facebook，它使得针对Hadoop进行SQL查询成为可能，从而非程序员也可以方便地使用。Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，可以将SQL语句转换为MapReduce任务运行。

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。

Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

Hive是建立在Hadoop基础上的数据仓库软件包,在开始阶段,它被Facebook用于处理大量的用户数据和日志数据.它现在是Hadoop的子项目并有许多贡献者.其目标用户仍然是习惯SQL的数据分析师,他们需要在Hadoop规模的数据上做即席查询/汇总和数据分析.通过称为HiveQL的类SQL语言,你可以发起一个查询来实现与Hive的交互.

Hive是基于Hadoop的数据仓库平台，由Facebook贡献，其支持类似SQL的结构化查询功能。Facebook设计开发Hive的初衷就是让那些熟悉sql编程方式的人也可以更好的利用hadoop，hive可以让数据分析人员只关注于具体业务模型，而不需要深入了解Map/Reduce的编程细节，但是这并不意味着使用hive不需要了解和学习Map/Reduce编程模型和hadoop，复杂的业务需求和模型总是存在的，对于Hive分析人员来说，深入了解Hadoop和Hive的原理和Mapreduce模型，对于优化查询总有益处。

Hive不是一个完整的数据库.Hadoop以及HDFS的设计本身约束和局限性地限制了Hive所能胜任的工作.其中最大的限制就是Hive不支持记录级别的更新/插入/删除操作.但是用户可以通过查询生成新表或者将查询结果导入到文件中.同时,因为Hadoop是一个面向批处理的系统,而MapReduce任务(job)的启动过程需要消耗较长时间,所以Hive查询延迟比较严重.传统数据库中在秒级别可以完成的查询,在Hive中,即使用数据集比较小,往往也需要执行更长的时间,最后需要说明的是Hive不支持事务.

因此Hive不支持联机事务处理OLTP,所需要的关键功能,而更接近一个OLAP联机分析技术工具.但是我们将会看到由于HADOOP本身的时间开销巨大,并且HADOOP所被设计用来处理的数据规模非常大,因此提交查询和返回结果是可能有非常大的延迟的,所以HIVE并没有满足OLAP中的联机部分.至少目前并没有满足.

因此Hive最适合数据仓库应用程序,其可以维护海量数据,而且可以对数据进行挖掘,然后形成意见和报告等.

hive优点：成本低，可以通过类sql语句快速实现简单或复杂的MapReduce统计。借助于Hadoop和HDFS的大数据存储能力，数据仍然存储于Hadoop的HDFS中，Hive提供了一种类SQL的查询语言：HiveQL（HQL），对数据进行管理和分析，开发人员可以近乎sql的方式来实现逻辑，从而加快应用开发效率。

HQL经过解析和编译，最终会生成基于Hadoop平台的Map Reduce任务，Hadoop通过执行这些任务来完成HQL的执行。Hive的设计体风出它是一个管理和查询结构化数据的系统.通过专注结构化数据,Hive可以实现MapReduce一般所不具备的某些优化和可用性功能.受到SQL影响的Hive语言让用户可以脱离MapReduce一般所不具备的某些优化和可用性功能.受到SQL影响的Hive语言让用户可以脱离MapREduce编程的复杂性.它沿用了关系数据库的常见概念,如表/行/列/Schema,以便于学习.此外,虽然Hadoop天生支持平坦文件,但Hive可以使用目录结构来划分数据,以提高某些查询的性能.为支持这些额外的功能,Hive有一个全新且重要的组件,它就是用于存储schema信息的metastore.这个metastore通常只有在关系型数据库中才有的.

Hive的组件总体上可以分为以下几个部分：用户接口（UI）、驱动、编译器、元数据（Hive系统参数数据）和执行引擎。

  1. 对外的接口UI包括以下几种：命令行CLI，Web界面、JDBC/ODBC接口；
  2. 驱动：接收用户提交的查询HQL；
  3. 编译器：解析查询语句，执行语法分析，生成执行计划；
  4. 元数据Metadata：存放系统的表、分区、列、列类型等所有信息，以及对应的HDFS文件信息等；
  5. 执行引擎：执行执行计划，执行计划是一个有向无环图，执行引擎按照各个任务的依赖关系选择执行任务（Job）。

需要注意的是，元数据库一般是通过关系型数据库MySQL或者支持JDBC驱动的关系型数据库来存储。元数据维护了库信息、表信息、列信息等所有内容，例如表T包含哪些列，各列的类型等等。因此元数据库十分重要，需要定期备份以及支持查询的扩展性。

读时验证机制

与传统数据库对表数据进行写时严重不同，Hive对数据的验证方式为读时模式，即只有在读表数据的时候，hive才检查解析具体的字段、shema等，从而保证了大数据量的快速加载。 既然hive采用的读时验证机制，那么 如果表schema与表文件内容不匹配，会发生什么呢？

答案是hive会尽其所能的去读数据。如果schema中表有10个字段，而文件记录却只有3个字段，那么其中7个字段将为null；如果某些字段类型定位为数值类型，但是记录中却为非数值字符串，这些字段也将会被转换为null。简而言之，hive会努力catch读数据时遇到的错误，并努力返回。

既然Hive表数据存储在HDFS中且Hive采用的是读时验证方式，定义完表的schema会自动生成表数据的HDFS目录，且我们可以以任何可能的方式来加载表数据或者利用HDFS API将数据写入文件，同理，当我们若需要将hive数据写入其他库（如oracle），也可以直接通过api读取数据再写入目标库。在实际生产环境中，当需要数据仓库之间的迁移时，就可以直接利用api将源库的数据直接写入hive库的表文件中，包括淘宝开源的datax数据交换系统都采用类似的方式来交换跨库数据。

再次注意，加载或者写入的数据内容要和表定义的schema一致，否则将会造成字段或者表为空。

Hive的数据模型

从数据仓库的角度看，Hive是建立在Hadoop上的数据仓库基础架构，可以方便的ETL操作。Hive没有专门的数据存储格式，也没有为数据建立索引，用于可以非常自由的组织Hive中的表，只需要在创建表的时候定义好表的schema即可。Hive中包含4中数据模型：Tabel、ExternalTable、Partition、Bucket。

  • Table：类似与传统数据库中的Table，每一个Table在Hive中都有一个相应的目录来存储数据。例如：一个表t，它在HDFS中的路径为：/user/hive/warehouse/t。
  • Partition：类似于传统数据库中划分列的索引。在Hive中，表中的一个Partition对应于表下的一个目录，所有的Partition数据都存储在对应的目录中。例如：t表中包含ds和city两个Partition，则对应于ds=2014，city=beijing的HDFS子目录为：/user/hive/warehouse/t/ds=2014/city=Beijing； 需要注意的是，分区列是表的伪列，表数据文件中并不存在这个分区列的数据。
  • Buckets：对指定列计算的hash，根据hash值切分数据，目的是为了便于并行，每一个Buckets对应一个文件。将user列分数至32个Bucket上，首先对user列的值计算hash，比如，对应hash=0的HDFS目录为：/user/hive/warehouse/t/ds=2014/city=Beijing/part-00000；对应hash=20的目录为：/user/hive/warehouse/t/ds=2014/city=Beijing/part-00020。
  • External Table指向已存在HDFS中的数据，可创建Partition。Managed Table创建和数据加载过程，可以用统一语句实现，实际数据被转移到数据仓库目录中，之后对数据的访问将会直接在数据仓库的目录中完成。删除表时，表中的数据和元数据都会删除。External Table只有一个过程，因为加载数据和创建表是同时完成。数据是存储在Location后面指定的HDFS路径中的，并不会移动到数据仓库中。

与其他数据库的区别

由于 Hive 采用了 SQL 的查询语言 HQL，因此很容易将 Hive 理解为数据库。其实从结构上来看，Hive 和数据库除了拥有类似的查询语言，再无类似之处。 本文将从多个方面来阐述 Hive 和数据库的差异。数据库可以用在 Online 的应用中，但是Hive 是为数据仓库而设计的，清楚这一点，有助于从应用角度理解 Hive 的特性。

Hive与数据库的比较

  1. 查询语言。由于 SQL 被广泛的应用在数据仓库中，因此，专门针对 Hive 的特性设计了类 SQL 的查询语言 HQL。熟悉 SQL 开发的开发者可以很方便的使用 Hive 进行开发。
  2. 数据存储位置。Hive 是建立在 Hadoop 之上的，所有 Hive 的数据都是存储在 HDFS 中的。而数据库则可以将数据保存在块设备或者本地文件系统中。
  3. 数据格式。Hive 中没有定义专门的数据格式，数据格式可以由用户指定，用户定义数据格式需要指定三个属性：列分隔符（通常为空格、”\t”、”\x001″）、行分隔符（”\n”）以及读取文件数据的方法（Hive 中默认有三个文件格式 TextFile，SequenceFile 以及 RCFile）。由于在加载数据的过程中，不需要从用户数据格式到 Hive 定义的数据格式的转换，因此，Hive 在加载的过程中不会对数据本身进行任何修改，而只是将数据内容复制或者移动到相应的 HDFS 目录中。而在数据库中，不同的数据库有不同的存储引擎，定义了自己的数据格式。所有数据都会按照一定的组织存储，因此，RDBMS数据库加载数据的过程会比较耗时。
  4. 数据更新。由于 Hive 是针对数据仓库应用设计的，而数据仓库的内容是读多写少的。因此，Hive 中不支持对数据的改写和添加，所有的数据都是在加载的时候中确定好的。而数据库中的数据通常是需要经常进行修改的，因此可以使用 INSERT INTO ... VALUES 添加数据，使用 UPDATE ... SET 修改数据。
  5. 索引。之前已经说过，Hive 在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些 Key 建立索引。Hive 要访问数据中满足条件的特定值时，需要暴力扫描整个数据，因此访问延迟较高。由于 MapReduce 的引入， Hive 可以并行访问数据，因此即使没有索引，对于大数据量的访问，Hive 仍然可以体现出优势。数据库中，通常会针对一个或者几个列建立索引，因此对于少量的特定条件的数据的访问，数据库可以有很高的效率，较低的延迟。由于数据的访问延迟较高，决定了 Hive 不适合在线数据查询。
  6. 执行。Hive 中大多数查询的执行是通过 Hadoop 提供的 MapReduce 来实现的（类似 select * from tbl 的查询不需要 MapReduce）。而数据库通常有自己的执行引擎。
  7. 执行延迟。之前提到，Hive 在查询数据的时候，由于没有索引，需要扫描整个表，因此延迟较高。另外一个导致 Hive 执行延迟高的因素是 MapReduce 框架。由于 MapReduce 本身具有较高的延迟，因此在利用 MapReduce 执行 Hive 查询时，也会有较高的延迟。相对的，数据库的执行延迟较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive 的并行计算显然能体现出优势。hive执行延迟高，只有在数据规模达到一定程度后，其查询的高效才能弥补其高延迟的劣势。
  8. 可扩展性。由于 Hive 是建立在 Hadoop 之上的，因此 Hive 的可扩展性是和 Hadoop 的可扩展性是一致的（世界上最大的 Hadoop 集群在 Yahoo!，2009年的规模在 4000 台节点左右）。而数据库由于 ACID 语义的严格限制，扩展行非常有限。目前最先进的并行数据库 Oracle 在理论上的扩展能力也只有 100 台左右。
  9. 数据规模。由于 Hive 建立在集群上并可以利用 MapReduce 进行并行计算，因此可以支持很大规模的数据；对应的，数据库可以支持的数据规模较小。

Sqoop

Apache Sqoop（SQL-to-Hadoop） 项目旨在协助 RDBMS 与 Hadoop 之间进行高效的大数据交流。用户可以在 Sqoop 的帮助下，轻松地把关系型数据库的数据导入到 Hadoop 与其相关的系统 (如HBase和Hive)中；同时也可以把数据从 Hadoop 系统里抽取并导出到关系型数据库里。除了这些主要的功能外，Sqoop 也提供了一些诸如查看数据库表等实用的小工具。

理论上，Sqoop 支持任何一款支持 JDBC 规范的数据库，如 DB2、MySQL 等。Sqoop 还能够将 DB2 数据库的数据导入到 HDFS 上，并保存为多种文件类型。常见的有定界文本类型，Avro 二进制类型以及 SequenceFiles 类型。在本文里，统一用定界文本类型。

Sqoop中一大亮点就是可以通过hadoop的mapreduce把数据从关系型数据库中导入数据到HDFS。Sqoop架构非常简单，其整合了Hive、Hbase和Oozie，通过map-reduce任务来传输数据，从而提供并发特性和容错。

首先这两个版本是完全不兼容的，其具体的版本号区别为

1.4.x为sqoop 1，1.99x为sqoop

sqoop1和sqoop2在架构和用法上已经完全不同。在架构上，sqoop1仅仅使用一个sqoop客户端，sqoop2引入了sqoopserver，对connector实现了集中的管理。

其访问方式也变得多样化了，其可以通过REST API、JAVA API、WEB UI以及CLI控制台方式进行访问。另外，其在安全性能方面也有一定的改善，在sqoop1中我们经常用脚本的方式将HDFS中的数据导入到mysql中，或者反过来将mysql数据导入到HDFS中，其中在脚本里边都要显示指定mysql数据库的用户名和密码的，安全性做的不是太完善。在sqoop2中，如果是通过CLI方式访问的话，会有一个交互过程界面，你输入的密码信息不被看到，同时Sqoop2引入基于角色的安全机制。

两个不同的版本，完全不兼容 版本号划分区别.

Apache版本： 1.4.x(Sqoop1); 1.99.x(Sqoop2)

CDH版本 : Sqoop-1.4.3-cdh4(Sqoop1) ; Sqoop2-1.99.2-cdh4.5.0

  • sqoop1优点：架构部署简单
  • sqoop1缺点：命令行方式容易出错，格式紧耦合，无法支持所有数据类型，安全机制不够完善，例如密码暴漏， 安装需要root权限，connector必须符合JDBC模型
  • sqoop2优点：多种交互方式，命令行，web UI，rest API，conncetor集中化管理，所有的链接安装在sqoop server上，完善权限管理机制，connector规范化，仅仅负责数据的读写
  • sqoop2缺点：架构稍复杂，配置部署更繁琐

Hbase

Hbase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写操作，同时Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。

HBase建立在HDFS之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。它介于NoSQL和RDBMS之间，仅能通过行键(row key)和行键序列来检索数据，仅支持单行事务(可通过Hive支持来实现多表联合等复杂操作)。主要用来存储非结构化和半结构化的松散数据。与Hadoop一样，HBase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

HBase表一般有这样的特点：

  • 大：一个表可以有上亿行，上百万列
  • 面向列：面向列(族)的存储和权限控制，列(族)独立检索。
  • 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。

HBase的服务器体系结构遵循简单的主从服务器架构。它由HRegion Server和HMaster组成，HMaster负责管理所有的HRegion Server，HBase中所有的服务器都通过ZooKeeper来协调。

HBASE的二类数据模型是指从逻辑模型与物理模型来了解Hbase的数据模型,表是HBase表达数据的逻辑组织方式,而基于列的存储则是数据在底层的组织方式.

如果你觉得我的文章对你有帮助的话，希望可以推荐和交流一下。欢迎關注和 Star 本博客或者关注我的 Github。