Hadoop是一个由Apache基金会所开发的分布式系统基础架构，其核心设计包括分布式文件系统（HDFS）和MapReduce编程模型；Hadoop是一个开源的分布式计算框架，旨在帮助用户在不了解分布式底层细节的情况下，开发分布式程序。

它通过利用集群的力量，提供高速运算和存储能力，特别适合处理超大数据集的应用程序。

Hadoop生态圈是一个由多个基于Hadoop开发的相关工具、库、应用程序、平台和服务组成的生态系统。这个生态系统旨在解决大规模数据处理问题，为用户提供从数据存储、处理到分析的全面解决方案。以下是对Hadoop生态圈主要组成部分的清晰归纳：

HDFS（Hadoop Distributed File System）：Hadoop分布式文件系统，用于存储大规模数据集。HDFS将数据划分为多个块，并将这些块分布在集群中的多个节点上，以提供高可靠性和高可扩展性。

MapReduce：一种编程模型，用于处理和分析存储在HDFS中的大规模数据集。MapReduce将复杂的数据处理任务划分为两个阶段：Map阶段和Reduce阶段，从而实现并行处理。

资源管理器：

YARN（Yet Another Resource Negotiator）：YARN是Hadoop 2.x版本引入的资源管理器，用于管理集群中的资源（如CPU、内存等）。YARN允许用户在同一集群上运行不同类型的应用程序，如MapReduce、Spark等。

HBase：一个基于Hadoop的分布式、版本化的非关系型数据库，用于存储结构化数据。HBase提供类似于Bigtable的列式存储，并支持实时读写操作。

Hive：一个基于Hadoop的数据仓库工具，允许用户使用SQL语言查询HDFS中的数据。Hive将SQL查询转换为MapReduce作业，并在Hadoop集群上执行。

Spark：一个开源的大规模数据处理引擎，支持批处理、流处理、交互式查询和机器学习等多种应用场景。Spark基于内存计算，比MapReduce更加高效。

Pig：一个高级数据处理语言，允许用户编写简单的查询来处理大规模数据集。Pig将查询转换为MapReduce作业，并在Hadoop集群上执行。

分布式协调服务：

ZooKeeper：一个分布式协调服务，用于维护Hadoop集群的状态信息，如节点健康状态、数据块位置等。ZooKeeper还提供命名服务、配置管理等功能。

Flume：一个用于收集、聚合和传输大量日志数据的工具，可以将数据发送到HDFS、HBase等存储系统中。

Sqoop：一个用于在Hadoop和结构化数据存储（如关系型数据库）之间传输数据的工具。Sqoop可以将数据从关系型数据库导入到HDFS中，也可以将HDFS中的数据导出到关系型数据库中。

Hadoop生态圈通过整合这些组件和工具，为用户提供了一个完整的大数据解决方案。用户可以根据需求选择适合的组件来构建自己的大数据处理和分析系统。

Hadoop起源于Apache Nutch项目，始于2002年，是Apache Lucene的子项目之一。在受到Google的MapReduce论文的启发后，Doug Cutting等人开始尝试实现MapReduce计算框架，并将其与NDFS（Nutch Distributed File System）结合，最终发展成为Hadoop。

可靠性：假设计算元素和存储会失败，因此它维护多个工作数据副本，确保能够针对失败的节点重新分布处理。

高效性：以并行的方式工作，通过并行处理加快处理速度。它能够在节点之间动态地移动数据，并保证各个节点的动态平衡。

可伸缩性：可以在可用的计算机集簇间分配数据并完成计算任务，这些集簇可以方便地扩展到数以千计的节点中。

高容错性：能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。

低成本：依赖于社区服务，因此它的成本比较低，任何人都可以使用。

HDFS（分布式文件系统） -—— 实现将文件分布式存储在集群服务器上

MAPREDUCE（分布式运算编程框架） —— 实现在集群服务器上分布式并行运算

YARN（分布式资源调度系统） —— 帮用户调度大量的 MapReduce 程序，并合理分配运算资源（CPU和内存）

Hadoop1.x：由MapReduce（计算及资源调度）、HDFS（数据存储）和Common（辅助工具）组成

Hadoop2.x：由MapReduce（计算）、Yarn（资源调度）、HDFS（数据存储）和Common（辅助工具）组成

在Hadoop1.x版本的时代，Hadoop中的MapReduce同时要处理业务逻辑运算和资源的调度，耦合性较大，于是在2.X版本增加了Yarn，负责接管资源调度的工作。

HDFS是一个分布式文件系统，可以将大型数据集分成多个块，并将这些块存储在不同的计算机上，以提高数据的可靠性和可扩展性。

它具有高容错性的特点，设计用来部署在低廉的硬件上，并提供高吞吐量来访问应用程序的数据。

HDFS放宽了POSIX的要求，可以以流的形式访问文件系统中的数据。

（1）高容错性

        ①数据自动保存多个副本。它通过增加副本的形式，提高容错性。

        ②某一个副本丢失以后，它可以自动恢复。

（2）适合处理大数据

        ①数据规模：能够处理数据规模达到 GB 、 TB 、甚至 PB 级别的数据；

        ②文件规模：能够处理百万规模以上的文件数量，数量相当之大。

（3）可构建在廉价机器上，通过多副本机制，提高可靠性。

（1）不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。

（2）无法高效的对大量小文件进行存储。

        ①存储大量小文件的话，它会占用 NameNode 大量的内存来存储文件目录和块信息。这

样是不可取的，因为 NameNode 的内存总是有限的；

        ②小文件存储的寻址时间会超过读取时间，它违反了 HDFS 的设计目标。

（3）不支持并发写入、文件随机修改。

        ①一个文件只能有一个写，不允许多个线程同时写；

        ②仅支持数据 append ( 追加 ) ，不支持文件的随机修改。

（1） NameNode (nn) ：就是 Master ， 它是一个主管、管理者。

        ①管理 HDFS 的名称空间；

        ②配置副本策略；

        ③管理数据块(Block) 映射信息；

        ④处理客户端读写请求。

（2） DataNode ：就是 Slave 。 NameNode 下达命令， DataNode 执行实际的操作。

        ①存储实际的数据块；

        ③执行数据块的读/ 写操作。

（3） Client ：就是客户端。

        ①文件切分。文件上传 HDFS 的时候， Client 将文件切分成一个一个的 Block, 然后进行上传；

        ②与 NameNode 交互，获取文件的位置信息；

        ③与 DataNode 交互，读取或者写入数据；

        ④Client 提供一些命令来管理 HDFS, 比如 NameNode 格式化；

        ⑤Client 可以通过一些命令来访问 HDFS ，比如对 HDFS 增删查改操作；

（4） Secondary NameNode ：并非 NameNode 的热备。当 NameNode 挂掉的时候， 它并不能马上替换 NameNode 并提供服务。

        ①辅助 NameNode ，分 担其工 作量 ，比如 定期合 并 Fsimage 和 Edits, 并推送给NameNode ；

        ②在紧急情况下，可辅助恢复 NameNode 。

HDFS 中的文件在物理上是分块存储 (Block) ，块的大小可以通过配置参数 ( dfs.blocksize)来规定，默认大小在 Hadoop2.x 版本中是 128M ，老版本中是 64M 。

思考：为什么块的大小不能设置太小，也不能设置太大？

        (1) HDFS 的块设置太小，会增加寻址时间，程序一直在找块的开始位置；

        (2)如果块设置的太大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时，会非常慢。

总结 : HDFS 块的大小设置主要取决于磁盘传输速率。

MapReduce是一个分布式运算程序的编程框架，是用户开发“基于Hadoop的数据分析应用”的核心框架

MapReduce核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完的分布式运算程序，并发运行在一个Hadoop集群上

（1）MapReduce易于编程它简单的实现一些接口，就可以完成一个分布式程序，这个分布式程序可以分布到大量廉价的PC机器上运行。也就是说你写一个分布式程序，跟写一个简单的串行程序是一模一样的。就是因为这个特点使得MapReduce编程变得非常流行。

（2）良好的扩展性

当你的计算资源不能得到满足的时候，你可以通过简单的增加机器来扩展它的计算能力。

（3）高容错性

MapReduce设计的初衷就是使程序能够部署在廉价的PC机器上，这就要求它具有很高的容错性。比如其中一台机器挂了，它可以把上面的计算任务转移到另外一个节点上运行，不至于这个任务运行失败，而且这个过程不需要人工参与，而完全是由Hadoop内部完成的。

（4）适合PB级以上海量数据的离线处理可以实现上千台服务器集群并发工作，提供数据处理能力。

（1）不擅长实时计算MapReduce无法像MySQL一样，在毫秒或者秒级内返回结果

（2）不擅长流式计算

流式计算的输入数据是动态的，而MapReduce的输入数据集是静态的，不能动态变化。这是因为MapReduce自身的设计特点决定了数据源必须是静态的不擅长DAG(有向图)计算

（3）多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。在这种情况下，MapReduce并不是不能做，而是使用后，每个MapReduce作业的输出结果都会写入到磁盘，会造成大量的磁盘IO，导致性能非常的低下

（1）分布式的运算程序往往需要分成至少 2 个阶段。

（2）第一个阶段的 MapTask 并发实例，完全并行运行，互不相干。

（3）第二个阶段的 ReduceTask 并发实例互不相干，但是他们的数据依赖于上一个阶段的

所有 MapTask 并发实例的输出。

（4） MapReduce 编程模型只能包含一个 Map 阶段和一个 Reduce 阶段，如果用户的业务

逻辑非常复杂，那就只能多个 MapReduce 程序，串行运行。

yarn是一种通用的资源管理系统和调度平台。

资源管理系统 ：管理集群内的硬件资源，和程序运行相关，比如内存，CPU等。

调度平台：多个程序同时申请计算资源时提供分配，调度的规则（算法）。

通用：不仅仅支持MapReduce程序，理论上支持各种计算程序如spark，flink。yarn不关系程序的计算内容，只关心程序所需的资源，在程序申请资源的时候根据调度算法分配资源，计算结束之后回收计算资源。使用yarn作为资源调度平台的计算框架自身需要提供ApplicationMaster来负责计算任务的调度。

（1）将资源管理和作业控制分离，减小JobTracker压力

（2）YARN的设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。

（3）老的框架中，JobTracker一个很大的负担就是监控job下的tasks的运行状况，现在，这个部分就扔给ApplicationMaster做了而ResourceManager中有一个模块叫做ApplicationsManager(ASM)，它负责监测ApplicationMaster的运行状况。

（4）能够支持不同的计算框架

（5）资源管理更加合理

（6）使用Container对资源进行抽象，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的，比之前以slot数目更合理。

（7）且使用了轻量级资源隔离机制Cgroups进行资源隔离。

（8）Container的设计避免了之前的map slot/reduce slot分开造成集群资源闲置的尴尬情况。

（1）各个应用无法感知集群整体资源的使用情况，只能等待上层调度推送信息。

（2）资源分配采用轮询、ResourceOffer机制（mesos)，在分配过程中使用悲观锁，并发粒度小。

（3）缺乏一种有效的竞争或优先抢占的机制。

（4）简化了双层调度器中的全局资源管理器，改为由一个Cell State来记录集群内的资源使用情况，这些使用情况都是共享的数据，以此来达到与全局资源管理器相同的效果。

（5）所有任务访问共享数据时，采用乐观并发控制方法。

①作业提交：客户端向ResourceManager中的ApplicationManager提交作业申请，并请求分配一个唯一的jobID。

②作业配置上传：ApplicationManager返回jobID以及HDFS上的临时作业目录路径（如hdfs://.../jobID）。客户端随后将作业的JAR包、配置文件等信息上传到该目录。

③作业启动请求：客户端成功上传文件后，向ApplicationManager发送启动作业的请求。

④资源请求与分配：

ApplicationManager将作业资源请求转发给Scheduler。

Scheduler根据集群的当前状态和策略（如FIFO、Capacity Scheduler或Fair Scheduler）来调度资源，并将作业放置到相应的队列中。

当资源可用时，Scheduler通知ApplicationManager分配Containers。

⑤启动ApplicationMaster：

ApplicationManager指令NodeManager在具有足够资源的节点上使用分配的Container启动ApplicationMaster。

ApplicationMaster负责作业的生命周期管理。

⑥任务规划与提交：

ApplicationMaster从HDFS的临时作业目录中读取作业配置和代码。

根据作业的配置和数据分片信息，ApplicationMaster规划并创建Map和Reduce任务。

⑦资源申请与分配：

ApplicationMaster向Scheduler请求执行Map和Reduce任务所需的资源。

Scheduler根据集群状态和作业优先级返回资源分配结果。

⑧任务启动：

ApplicationMaster通知NodeManager在分配到的资源上启动Map和Reduce任务。

NodeManager在相应的节点上启动任务容器并执行任务。

⑨任务执行与监控：

Map和Reduce任务读取数据并执行计算逻辑。

ApplicationMaster监控任务的执行状态，并在任务失败时负责重启任务。

⑩资源释放：

当作业成功完成后，ApplicationMaster通知Scheduler释放之前分配的资源。

NodeManager释放任务容器和相关资源。

作业完成通知：

ApplicationMaster向ResourceManager报告作业完成状态，并可能向客户端发送完成通知。

  Yarn中有三种资源调度器：FIFO调度器（FIFO Scheduler）、容量调度器（Capacity Scheduler）、公平调度器（Fair Scheduler）。

FIFO调度器按照作业提交的顺序，依次分配资源给每个作业。简单地说，就是先来后到，排好队一个一个来。

        优点：

简单易用，不需要任何配置。

        缺点：

不适合共享集群，因为大的作业会占用集群的所有资源，导致其他作业长时间等待。

如果一个大作业持续运行，那么其他所有作业都必须等待它完成，这不利于集群的合理利用。

容量调度器支持多个队列，每个队列可以配置一定的资源量，并且队列内部使用FIFO调度策略。它允许不同的组织或用户共享一个Hadoop集群。

        优点：

通过设置多个队列，可以为小作业预留资源，确保小作业不会因为前面有大作业在执行而一直等待。

队列之间不会抢占资源，除非自己队列中的资源不能满足需求，而其他队列又有空闲资源。

缺点：

可能导致集群的整体资源利用率降低，因为为了给小作业预留资源，可能有一部分资源会长时间处于空闲状态。

大作业的执行时间可能会变长，因为它们不能独占整个集群的资源。

公平调度器的目标是确保所有作业都能公平地共享集群资源。它会根据作业的“缺额”（即请求的资源与实际获得的资源之间的差距）来动态分配资源。

        优点：

解决了FIFO调度器中大作业占满资源的问题，也解决了容量调度器中小作业队列空闲导致资源利用率降低的问题。

在多用户或多队列的场景下，能确保资源的公平分配。

        缺点：

可能存在延迟问题，因为后面的作业需要等待前面的作业释放资源。

在某些情况下，可能需要额外的配置来确保资源的公平分配。

FIFO调度器简单易用，但不适合共享集群。

容量调度器支持多队列和预留资源，但可能导致资源利用率降低。

公平调度器旨在确保资源的公平分配，但可能存在延迟问题。

在选择调度器时，需要根据集群的实际情况和需求进行权衡和选择。

HBase（Hadoop Database）是一个分布式、可扩展的、大数据存储的NoSQL数据库，它基于Hadoop的HDFS（Hadoop Distributed FileSystem）构建，提供高可靠性、高性能、列式、可伸缩、实时读写的数据库服务。

HBase的设计理念依据 Google的 BigTable论文，论文中对于数据模型的首句介绍 。

Bigtable 是一个 稀疏的 、 分布式的 、 持久的 多维排序 map 。

之后对于映射的解释如下：

该映射由行 键、列键和 时间戳索引；映射中的每个值都是一个未解释的字节数组。

分布式：HBase不是将数据存储在单个服务器或计算机上，而是将数据分散存储在一个集群的多个服务器上。这种分布式的设计让HBase可以处理海量数据，而不用担心单台机器的资源限制。

可扩展：随着业务的发展和数据的增长，你可以通过添加更多的服务器到HBase集群中来扩展其存储和计算能力。

NoSQL：与传统的关系型数据库（如MySQL、Oracle）不同，HBase是一个NoSQL数据库。它不使用表格、行和列这样的关系型结构来存储数据，而是使用更灵活的数据模型。

列式存储：在HBase中，数据是按列而不是按行存储的。这意味着你可以只读取你需要的列，而不是整行数据。这种存储方式在处理大规模数据时非常高效，因为可以减少数据的读取和传输量。

高可靠性：HBase利用HDFS的副本机制来保证数据的可靠性。HDFS会在多个节点上存储数据的副本，以防止数据丢失。

高性能：HBase通过并行处理和分布式计算来提供高性能的数据访问。它可以在集群中的多个节点上同时处理数据，从而加快数据处理速度。

实时读写：HBase支持实时读写操作，这意味着你可以随时向HBase中写入数据，并立即读取这些数据。这使得HBase非常适合用于需要实时处理和分析数据的场景。

互联网应用：如搜索引擎、社交网络、电子商务等，这些应用需要处理大量的用户数据，HBase可以提供高性能的存储和查询服务。

大数据分析：HBase可以与其他大数据工具（如Spark、Hive等）结合使用，进行复杂的数据分析和挖掘。

物联网（IoT）：随着物联网的发展，需要存储和处理大量的传感器数据。HBase可以提供高效的存储和实时读写能力，满足IoT应用的需求。

未解释:数据没有经过反序列化，不能被直接读取。

最终HBase关于 数据模型和 BigTable的对应关系如下：

HBase 使用与 Bigtable 非常相似的数据模型。用户将数据行存储在带标签的表中。数据行具有可排序的键和任意数量的列。该表存储稀疏，因此如果用户喜欢，同一表中的行可以具有疯狂变化的列。

最终理解HBase数据模型的关键在于 稀疏、分布式、多维、排序 的映射。其中映射 map指代非关系型数据库的 key-Value结构。

稀疏的:Hbase是一种NoSql数据库，不像Mysql这样的关系型数据库；Mysql在建表时就已经为数据预留好位置，即使该字段数值为空，这个位置也不能被占用；Hbase为型数据库，不会存储空值。

物理存储结构

物理存储结构即为数据映射关系，而在概念视图的空单元格，底层实际根本不存储。

HBase数据存储依靠HDFS，HDFS存储数据具有一次写入，多次读取的特点，其不支持对数据进行修改，但是HBase存储数据为KV型，通过对相同的K再次写入，根据TimeStamp不可逆的特点，每次写入的数据的时间戳都比上一个数据的时间戳大，从而完成版本号的维护和数据的更新。

HBase底层使用KV数据类型存储，但是用户无需关心底层的存储逻辑，只需要了解其表结构的存储即可 ，其存储Key为(Row Key，Column Family，ColumnQualifier，Timestamp，Type)，因此在涉及表时RowKey的设定尤为重要

1）Name Space

命名空间，类似于关系型数据库的database 概念，每个命名空间下有多个表。HBase 两个自带的命名空间，分别是hbase 和default，hbase 中存放的是HBase 内置的表，default表是用户默认使用的命名空间。

2）Table

类似于关系型数据库的表概念。不同的是，HBase 定义表时只需要声明列族即可，不需要声明具体的列。因为数据存储时稀疏的，所有往HBase 写入数据时，字段可以动态、按需指定。因此，和关系型数据库相比，HBase 能够轻松应对字段变更的场景。

3）Row

HBase 表中的每行数据都由一个RowKey 和多个Column（列）组成，数据是按照RowKey的字典顺序存储的，并且查询数据时只能根据RowKey 进行检索，所以RowKey 的设计十分重要。

4）Column

HBase 中的每个列都由Column Family(列族)和Column Qualifier（列值）进行限定，例如info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。

5）Time Stamp

用于标识数据的不同版本（version），每条数据写入时，系统会自动为其加上该字段，其值为写入HBase 的时间。

6）Cell

由{rowkey, column Family：column Qualifier, timestamp} 唯一确定的单元。cell 中的数据全部是字节码形式存贮。

7）Region

HBase按照Split策略将一张表横向切分成多个Region，每个Region实际上是一个文件夹，每个Region包含一定范围的Row Key，Region之间互不相交，从而实现表的分布式存储。

8）Store

HBase将每个Region按照列族进一步细分，分区Region中包含0或多个Store,一个Store包含一个列族。HBase中创建多个列族,则会形成多个Store,保存在Region中,如果Store数量大小过多,Region将会进行拆分,形成多个Region。

1）Master

实现类为HMaster，负责监控集群中所有的 RegionServer 实例。主要作用如下：

（1）管理元数据表格hbase:meta，接收用户对表格创建修改删除的命令并执行。

（2）监控region 是否需要进行负载均衡，故障转移和region 的拆分。

通过启动多个后台线程监控实现上述功能：

①LoadBalancer 负载均衡器

周期性监控region 分布在regionServer 上面是否均衡，由参数hbase.balancer.period 控制周期时间，默认5 分钟。

②CatalogJanitor 元数据管理器

定期检查和清理hbase:meta 中的数据。

③MasterProcWAL master 预写日志处理器

把master 需要执行的任务记录到预写日志WAL 中，如果master 宕机，让backupMaster读取日志继续干。

WAL预写日志技术，先将操作记录持久化，防止在操作过程中宕机，之后再进行实际操作。

2）Region Server

Region Server 实现类为HRegionServer，主要作用如下:

（1）负责数据cell 的处理，例如写入数据put，查询数据get 等

（2）拆分合并region 的实际执行者，有master 监控，有regionServer 执行。

RegionServer是HBase中的数据存储节点，它们负责处理客户端的读写请求。每个RegionServer通常包含多个Region，每个Region负责管理一张表的一部分数据。

3) Zookeeper

HBase通过 Zookeeper来做 master的高可用、 记录 RegionServer的 部署信息 、 并且存储

有 meta表的位置信息 。

HBase对于数据的读写操作时直接访问 Zookeeper的，在 2.3版本 推 出 Master Registry模式，客户端可以直接访问 master。 使用此功能，会加大对 master的压力，减轻对 Zookeeper的压力。

4) HDFS

HDFS为 Hbase提供最终的底层数据存储服务，同时为 HBase提供高 容错 的支持。

Hive是由Facebook(脸书)开发的后来贡献给了Apache的一套数据仓库管理工具，针对海量的结构化数据提供了读、写和管理的功能。

Hive本身是基于Hadoop，提供了类SQL(Hive Query Language，简称为HQL)语言来操作HDFS上的数据，而底层实际上是将用户书写的SQL转化为了MapReduce程序来执行，因此效率相对较低，更适合于离线批处理的场景。

之所以Facebook开发了Hive这个项目，是因为Facebook在使用Hadoop过程中发现了一些问题：

1)Hadoop只提供了MapReduce这一种用于数据处理方案，但是当需要大量的数据进行处理的时候，就需要编写大量的MapReduce，这种方式效率较低，逻辑复杂度较高，难度较大。

2)早期的时候，Hadoop只支持Java语言(即使现在，Hadoop也只支持C/C++，Java，Python，Scala这几门语言)，那么就导致其他开发者如果想要使用Hadoop，尤其是MapReduce，那么需要学习Java语言，极大地增加了学习和使用成本。

所以在这种背景下，Facebook就想对Hive尤其是MapReduce模块进行封装，且封装好之后使用的结构最好与语言无关(即不绑定某一门编程语言的语法)，所以最后选定了SQL作为封装结构，由此，Hive也就诞生了。

Hive和数据库的比较如下：

1) 查询语言：由于SQL的易学特性，因此被广泛的应用在数据仓库中。Hive专门设计了类SQL的查询语言HQL，使得熟悉SQL开发的开发者可以很方便的使用Hive进行开发。

2)数据存储位置：Hive是建立在Hadoop之上的，因此Hive中的数据是存储在HDFS上的。而数据库则可以将数据保存在块设备或者本地文件系统中。

3)数据更新：Hive一般是针对历史数据进行处理，因此数据一般是不可修改的。而数据库中的数据通常是需要经常进行修改的。

4)索引：Hive在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此不会主动针对数据建立索引。Hive要访问数据中满足条件的特定值时，需要暴力扫描整个数据，因此访问延迟较高。由于MapReduce的引入，Hive可以并行访问数据，因此即使没有索引，对于大数据量的访问，Hive仍然可以体现出优势。而在数据库中，通常会针对一个或者几个列建立索引，因此对于少量的特定条件的数据的访问，数据库可以有很高的效率，较低的延迟。

5)执行引擎：默认情况下，Hive通过Hadoop提供的MapReduce来实现数据处理的，当然，Hive支持将执行引擎替换为Tez或者是Spark。而数据库通常有自己的执行引擎，例如MySQL的执行引擎为innodb。

6)执行延迟：Hive在查询数据的时候，由于没有索引，需要扫描整个表，因此延迟较高。另外一个导致Hive执行延迟高的因素是MapReduce框架。由于MapReduce本身就具有较高的延迟，因此在利用MapReduce执行Hive查询时，也会有较高的延迟。相对的，数据库的执行延迟较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。

7)可扩展性：由于Hive是建立在Hadoop之上的，因此Hive的可扩展性是和Hadoop的可扩展性是一致的(现在很多公司的Hadoop集群的规模超过了10000个节点)。而数据库由于ACID语义的严格限制，扩展行非常有限。目前最先进的并行数据库Oracle在理论上的扩展能力也只有100台左右。

8)数据规模:由于Hive建立在集群上并可以利用MapReduce进行并行计算，因此可以支持很大规模的数据，实际开发过程中一般是GB起步，可以达到PB级别及以上；相应的，数据库由于规模较小，因此可以支持的数据规模较小，一般单张表中能存储百万条数据(最新版的MySQL经过优化，单表中可以存储千万条或者上亿条数据，即使是一亿条数据，也就10GB大小，且此时效率会非常低)。

1)操作接口采用类SQL语法，用户只要熟悉SQL语法即可快速转化(简单、学习成本低、容易上手)；

2)避免书写MapReduce，减少开发人员的学习成本以及维护成本；

3)对于大量数据，Hive能够进行分布式处理，从而节省了数据的处理时间；

4)Hive支持用户自定义函数，用户可以根据自己的需求来实现自己的函数，从而提高了灵活性，能够更好的应对复杂业务。

1)基于HQL的方式导致表达能力有限：首先Hive中迭代式算法无法表达；其次Hive不擅长数据挖掘，由于MapReduce数据处理流程的限制，效率更高的算法却无法实现。

2)Hive的效率比较低：首先Hive的执行延迟比较高，因此Hive常用离线分析，适用于对实时性要求不高的场合；其次HQL自动编译生成MapReduce作业，通常情况下不够智能化；然后，由于MapReduce本身的特点，导致Hive对小文件的处理不占优势。

3)Hive调优比较困难，粒度较粗。

4)Hive对于数据更新操作支持性不好：一般用Hive处理的是离线的历史数据，因此默认情况下Hive是不支持对数据进行修改的。而如果需要对数据进行修改(update、delete)，那么需要改变Hive中数据文件的存储格式，且此时效率非常非常低。

这三者共同构成了大数据处理和分析的生态系统，各自扮演着不同的角色，协同工作以处理和分析大规模数据集。