大数据技术架构_大数据架构技术

一、hadoop

1、基础知识

1.1、概念

①Hadoop集群特点：高可靠性、高效性、高可拓展性、高容错性、成本低、运行在Linux操作系统上、支持多种编程语言

②Hadoop的由来：

③四种计算模式：

④分布式文件系统HDFS的特点：透明性、高可用性、支持并发访问、可拓展性

1.2、区分

①计算模式 vs 计算架构

计算模型：抽象结构+计算范式+算法；计算模型针对领域问题提出技术解决方案的基础模型、数据结构及算法

计算架构：系统架构+软件设计+实现方法；计算架构提出基于上述模型、在特定计算平台上实现的技术方案框架（系统架构、软件架构和模块、数据流与数据接口、实现原理及方法）

计算模式：通常指的是Hadoop的运行方式和部署方式。Hadoop支持多种计算模式，如单机模式、伪分布式模式和集群模式。单机模式主要用于开发和调试；伪分布式模式在单个节点上模拟分布式环境，常用于测试；而集群模式则是用于生产环境，由多个节点组成真正的Hadoop集群，用于处理大规模数据

计算模式关注的是Hadoop的运行和部署方式，计算模型关注的是数据处理的核心逻辑和方式，而计算架构则关注的是Hadoop的整体系统架构和组件之间的关系

②HDFS vs 传统文件系统

可扩展性：HDFS是为大规模数据处理而设计的，可以轻松地扩展到成百上千台服务器。

数据存储：HDFS采用数据块的方式存储数据，将文件切分成多个小的数据块，并分散存储在不同的服务器上，以实现高吞吐量和并行处理能力。

容错性：HDFS采用了数据冗余机制，将数据块复制到不同的服务器上，保证了数据的可靠性。当某个服务器发生故障时，系统可以自动从其他副本中恢复数据。而传统文件系统可能不具备这种高度的容错性。

高效的数据访问：HDFS通过移动计算而不是移动数据的方式来提高性能。它将数据块存储在就近的服务器上，并利用网络拓扑结构来减少数据传输的距离，从而实现快速的数据访问。而传统文件系统可能更注重数据的本地访问性。

适应大数据处理：HDFS适用于处理大规模的数据集。它通过分布式计算和并行处理来提高处理效率，可以在短时间内处理大量的数据。而传统文件系统可能更适用于用户交互式应用和小规模数据处理。

不支持随机写入：与传统文件系统不同，HDFS不支持随机写入操作。它主要用于一次写入、多次读取的场景，适合于批处理和大数据分析任务。

③开源 vs 商用

2、体系结构

2.1、核心组件

①HDFS

②HBase

③MapReduce

④Hive

2.2、功能

①Namenode：元数据操作（元数据保存在内存），管理文件系统的命名空间、集群配置信息等；

②Datanode：文件块生成、删除、复制及执行NameNode的指令，周期性地将块信息发送给NameNode

③Secondary Namenode（一般独立部署在一台机器上）：辅助NameNode的守护进程；保存名称节点对HDFS元数据信息的备份；减少名称节点重启的时间。合并编辑日志（Edit Log）和镜像文件（FsImage）；帮助恢复数据（不能作为热备份）；提高系统可靠性和稳定性

2.3、总体架构

①软件架构组成：基于HDFS/HBase的数据存储系统；基于YARN/Zookeeper的管理调度系统；支持不同计算模式的处理引擎

②数据存储系统组成：分布式文件系统HDFS（Hadoop Distributed File System）；分布式非关系型数据库Hbase；数据仓库及数据分析工具Hive和Pig；用于数据采集、转移和汇总的工具Sqoop和Flume； HDFS文件系统构成了Hadoop数据存储体系的基础

③管理调度系统： Zookeeper：提供分布式协调服务管理；Oozie：负责作业调度；Ambari：提供集群配置、管理和监控功能；Chukwa：大型集群监控系统； YARN：集群资源调度管理系统

④Hadoop采用主从架构，Master/Slave架构，集群中只设置一个主节点

⑤主从架构的优点：简化了系统设计；元数据管理和资源调配更容易

⑥主从架构的缺点：命名空间的限制；性能的瓶颈；单点失效（SPOF）问题

⑦针对缺点的改进：高可用机制（HA，HA分为各个组件的HA机制）解决单点失效问题、联邦机制解决性能瓶颈问题（系统扩展性、整体性能、隔离性）

⑧HA机制（谁来做？）：为了整个系统的可靠性，我们通常会在系统中部署两台或多台主节点，多台主节点形成主备的关系，但是某一时刻只有一个主节点能够对外提供服务，当某一时刻检测到对外提供服务的主节点“挂”掉之后，备用主节点能够立刻接替已挂掉的主节点对外提供服务，而用户感觉不到明显的系统中断。这样对用户来说整个系统就更加的可靠和高效。

⑨联邦机制

3、架构原理

3.1、工作原理

①HDFS读文件的流程：打开文件；获取块信息；读取请求；读取数据；读取下一个数据块；关闭文件

②HDFS写文件的流程：创建文件； 建立文件元数据；写入请求；写入数据包；接收确认包；关闭写入流；结束过程，通知名称节点关闭文件

③HDFS的容错与恢复机制——>实现了分布式高可用

多副本方式进行冗余存储（加快数据传输速度、容易检查数据错误、保证数据可用性）

机架感知副本存放策略（改进数据的可靠性、可用性和网络宽带的利用率、防止某一机架失效时数据丢失、利用机架内的高带宽特性提高数据读取速度）

错误检测和恢复机制（包括NameNode故障、DataNode故障和数据错误）

④

⑤

⑥HDFS文件错误检测和恢复机制：NameNode故障：第二名称节点；DataNode故障：心跳检测；数据错误：CRC循环校验

3.2、使用场景及优缺点

①HDFS的优点：

高容错性：HDFS 提供了容错和恢复机制，比如某一个副本丢失了可以通过其他副本来自动恢复。

适合大数据处理：能够处理GB、TB、甚至PB级别的数据规模；能够处理百万规模以上的文件数量；能够达到10000个节点以上的集群规模。

流式文件访问：HDFS的设计建立在更多地响应“一次写入、多次读写”任务的基础上，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

可构建在廉价的机器上：对硬件需求比较低，只需运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器。

②HDFS的缺点：

不适合低延时数据访问：比如毫秒级别的数据响应时间，这种场景HDFS是很难做到的。HDFS更适合高吞吐率的场景，就是在某一时间内写入大量的数据。

不适合大量小文件的存储：如果有大量小文件需要存储，这些小文件的元数据信息会占用NameNode大量的内存空间。这样是不可取的，因为NameNode的内存总是有限的。如果读取小文件的寻道时间超过文件数据的读取时间，它就违反了HDFS大数据块的设计目标。

不适合并发写入、文件随机修改：一个文件只能有一个写操作，不允许多个线程同时进行写操作；仅支持数据的append（追加）操作，不支持文件的随机修改

4、集群搭建

4.1、搭建模式

①Hadoop三种搭建模式——单机模式：

Hadoop的默认模式，无需运行任何守护进程（daemon），所有程序都在单个JVM上执行。在这种模式下，Hadoop使用本地文件系统，而不是分布式文件系统。它主要用于开发和调试MapReduce程序，方便在本机上进行测试和验证

②Hadoop三种搭建模式——伪分布模式:

在这种模式下，Hadoop在一台主机上模拟多主机环境，Hadoop的守护程序在本地计算机上运行，模拟集群环境，并且是相互独立的Java进程。该模式使用分布式文件系统，各个作业也由JobTraker服务来管理。它允许检查内存使用情况、HDFS输入输出以及其他的守护进程交互。这种模式常用于开发和测试Hadoop程序的执行是否正确

③Hadoop三种搭建模式——完全分布模式:

在这种模式下，Hadoop的守护进程运行在由多台主机搭建的集群上，是真正的生产环境。所有的主机上都需要安装JDK和Hadoop，并组成相互连通的网络

4.2、搭建步骤

Hadoop伪分布搭建步骤：

①新建用户并赋予root权限

②解压Hadoop压缩包

③配置Hadoop文件：hadoop-env.sh；core-site.xml；hdfs-site.xml；mapred-site.xml；yarn-site.xml

④执行sudo vi /etc/profile，把hadoop的安装目录配置到环境变量中

⑤使用source /etc/profile使配置文件生效

⑥使用Java-version验证Java环境

4.3、启动

①启动命令——hdfs：start-dfs.sh

②启动命令——yarn：start-yarn.sh

4.4、验证

①HDFS：Namenode、Datanode、SecondaryNamenode

②YARN：ResourceManager、NodeManager

5、平台编程

二、Hbase

1、基础知识

1.1、概念

①特性：

规模大：一个表可以有上亿行，上百万列。

面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。

稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。

无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。

扩展性：HBase底层文件存储依赖HDFS，它天生具备可扩展性。

高可靠性：HBase提供了预写日志(WAL)和副本(Replication)机制，防止数据丢失。

数据多版本：我们在创建表时可以自定义多个VERSION（版本）。

数据类型单一：HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串。

②数据模型：{row key, column family：column qualifier, timestamp} → value

1.2、区分

①HBase vs 传统关系型数据库

2、体系结构

2.1、核心组件

①Client（客户端）：客户端包含访问HBase的接口。客户端获得Region的存储位置信息后，直接从Region服务器上读取数据。同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程。

②Master（HMaster）：管理运行不同的Region服务器，也为客户端操作HBase的所有元数据提供接口，同时负责RegionServer的故障处理和Region的切分。在HBase集群中可以有多个Master。

③Region和Region服务器：Region是HBase中分布式存储和负载均衡的最小单元，即不同的Region可以分别在不同的Region服务器上，但同一个Region是不会拆分到多个Region服务器上的。Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。

④Store（HStore）：Region服务器是HBase的核心模块，而Store则是Region服务器的核心。每个Store对应了表中的一个列族的存储。每个Store包含了一个MemStore缓存和若干个StoreFile文件。

⑤HLog：（一种预写式日志）来应对MemStore缓存中的数据会掉电全部丢失这种突发情况。

⑥Zookeeper服务器：Zookeeper是一个很好的集群管理工具，被大量用于分布式计算，提供配置维护、域名服务、分布式同步、组服务等。Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题

2.2、功能

①HLog（Write-Ahead-Log）：HBase采用HLog保证数据的一致性和实现回滚操作

HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（WriteAhead Log）

用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。

Region服务器每次启动都检查Hlog文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务。

只有当操作写入Hlog之后，commit()调用才会将其返回给客户端

2.3、总体架构

使用zookeeper管理集群，使用HDFS作为底层存储，在架构层面上由HMaster和多个HRegionServer组成，同样遵从主从服务器架构

3、架构原理

3.1、工作原理

①HBase三层访问结构：

寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器

三层结构可以保存的用户数据表的Region数目的计算方法是：（例题）

（-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的Region可以寻址的用户数据表的Region个数）

②HBase读写机制：

读：

client访问Zookeeper，查找-ROOT-表，获取.META.表信息。

从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer。

通过HRegionServer获取需要查找的数据。

HRegionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求将先到MemStore中查数据，如果无法查询到就会转到BlockCache，再查询不到就会到StoreFile，并把读的结果放入BlockCache。

写：

用户写入数据时，Client通过Zookeeper的调度，向HRegionServer发出写数据请求，在HRegion中写数据。

用户数据首先被写入到HRegion的MemStore中，系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记

每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件

③HBase容错机制：

Master容错：在实际生产环境中，HBase一般配置多个Master，当对外提供服务的Master挂掉之后，Zookeeper会重新选举一个新的Master。无Master过程中，数据读取仍照常进行，只是Region切分、负载均衡等无法进行。

RegionServer容错：定时向Zookeeper汇报心跳，如果一段时间内未出现心跳，Master会将该RegionServer上的Region重新分配到其他RegionServer上。失效服务器上的"预写"日志，由主服务器进行分割并派送给新的RegionServer。

Zookeeper容错：Zookeeper可以为HBase提供一个可靠的服务，一般配置3、5、7等奇数个实例，自身是高可用。

3.2、使用场景及优缺点

①使用场景

1. 需要高并发的实时数据读写操作：HBase提供了高性能、低延迟、随机访问的数据读写能力，能够满足海量数据的实时操作需求。

2. 需要存储非结构化或半结构化的数据：相对于传统关系型数据库，HBase的数据模型更为灵活，支持动态添加列族以及列，可以存储非结构化或半结构化的数据类型，如JSON等。

3. 需要可扩展性和高可用性：HBase具备横向可扩展性能力，支持集群多节点部署，同时，HBase还提供了数据副本和主从切换等机制，确保高可用性，以避免单点故障和数据丢失的问题。 总之，HBase适合处理大规模非结构化数据和需要高并发实时访问的场景，而不是针对小型数据应用或者临时存储数据应用的场景

4、集群搭建

4.1、搭建模式

4.2、搭建步骤

4.3、启动

4.4、验证（JPS）

①HMaster（主节点）

②HregionServe（从节点）

③ZooKeeper

5、平台编程

三、MapReduce

1、基础知识

1.1、概念

①设计思想：

大数据划分：MapReduce采用了这种“分而治之”的设计思想，对相互间不具有或者有较少数据依赖关系的大数据，用一定的数据划分方法对数据分片，然后将每个数据分片交由一个节点去处理，最后汇总处理结果。

MapReduce任务划分：Map 函数主要负责对一组数据记录进行某种映射处理，而Reduce函数主要负责对Map的中间结果进行某种进一步的结果整理和输出。

统一计算框架：MapReduce提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节，程序员只需要集中于应用问题和算法本身，而不需要关注其他系统层的处理细节，大大减轻了程序员开发程序的负担

1.2、区分

①MapReduce V1 vs Yarn:

2、体系结构

2.1、核心组件

①MapReduce V1组件：

Client是用户编写的MapReduce程序与JobTracker交互的桥梁。每一个 Job 都会在用户端通过 Client 类将应用程序以及配置参数 Configuration 打包成Jar文件存储在HDFS，并把路径提交到JobTracker的Master服务，然后由Master创建每一个Task将它们分发到各个TaskTracker 服务中去执行。

JobTracker负责资源监控和作业调度。JobTracker 监控所有TaskTracker 与Job的健康状况，如果发现有故障，JobTracker就会将相应的任务转分配给其他节点去完成

TaskTracker会周期性地通过HeartBeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker发送过来的命令并执行相应的操作

Task分为MapTask和Reduce Task两种，均由TaskTracker启动。对于MapReduce而言，其处理单位是Split

②Yarn组件：

YARN的基本思想就是将经典调度框架中JobTracker的资源管理和任务调度/监控功能分离成两个单独的组件，ResourceManager 和ApplicationMaster

ResourceManager负责整个系统资源的管理和分配，主要包含一个资源调度器（Scheduler）和一个全局应用程序管理器。而ApplicationMaster则负责单个应用程序的资源管理。

一个全局的资源管理器ResourceManager ResourceManager的每个节点代理NodeManager 表示每个应用的ApplicationMaster。 每一ApplicationMaster拥有多个Container，在NodeManager上运行

2.2、功能

①Combiner：

Combiner是一个本地化的Reduce操作，它是Map运算的后续操作，主要是在Map计算出中间文件前做一个简单的合并重复key值的操作。

②Partitioner：

2.3、总体架构

①MapReduce V1的局限：

扩展性差：在MRv1 中，JobTracker 同时兼备了资源管理和作业控制两个功能，成为系统的一个最大瓶颈，严重制约了Hadoop 集群扩展性。

可靠性差：MRv1 采用了master/slave 结构，其中，master 存在单点故障问题，一旦出现故障将导致整个集群不可用。

资源利用率低：MRv1 采用了基于槽位Slot的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源。Map Slot 和Reduce Slot之间不允许共享，常常会导致一种槽位资源紧张而另外一种闲置。

无法支持多种计算框架

②Yarn的改进：

1. 更好的资源管理和调度：Yarn基于集群的资源管理和调度，能够更加灵活地分配资源，提高资源利用率。

2. 支持多种计算模型：相较于MapReduce的固定计算模型，Yarn通过支持多种计算框架（比如MapReduce、Spark、Storm等），能够更好地支撑不同的业务场景和需求。

3. 更广泛的数据处理：Yarn支持更广泛的数据处理，如实时流数据处理、图计算等，MapReduce只适合批处理场景。

4. 更高效的任务处理：Yarn优化了任务处理流程，减少了整个任务的调度时间，提高了任务处理的效率。

5. 更好的容错处理：Yarn引入了更好的容错机制，使得在节点故障等异常情况下，能够更好地处理任务，保证任务的正确性。

   （通过Application Master来解决Job Tracker的瓶颈问题。每当新的job提交进来后，Resource Manager会在恰当的节点启动一个新的Application Master。 ApplicationMaster与RM协商为应用程序申请资源，并与节点管理器合作，负责协调运行MapReduce作业的任务，进行任务的监控与容错）

3、架构原理

3.1、工作原理

①MapReduce的工作流程（文字）：

②MapReduce的工作流程（实例分析）：

③MapReduce的容错机制：

MapReduce是一种通用的计算框架,有着非常健壮的容错机制

Yarn：

任务容错：当application master被告知一个任务尝试失败后，它将重新调度该任务的执行。application master会试图避免在之前失败过的NodeManager上重新调度该任务。此外，如果一个任务失败数超过4次，该任务将不会再尝试执行。

Application Master容错：application master向ResourceManager发送周期性的心跳，当application master失败时，ResourceManager将检测到该失败，并在一个新的容器中重新启动一个application master实例。对于新的application master来说，它将使用作业历史记录来恢复失败的应用程序所运行任务的状态，所以这些任务不需要重新运行。

NodeManager容错：如果一个NodeManager节点因中断或运行缓慢而失败，那么它就会停止向ResourceManager发送心跳信息（或者发送频率很低）。默认情况下，如果ResourceManager在10分钟内没有收到一个心跳信息，它将会通知停止发送心跳信息的NodeManager，并且将其从自己的节点池中移除。在这台死机的节点上已经完成运行的 Map任务及正在运行中的 Map和 Reduce任务都将被调度重新执行,同时在其他机器上正在运行的 Reduce任务也将被重新执行。

ResourceManager容错：ResourceManager出现故障是比较严重的，因为没有ResourceManager，作业和任务容器将无法启动。在默认的配置中，ResourceManager是一个单点故障，因为在机器出现故障时，所有的作业都会失败并且不能被恢复。

3.2、使用场景及优缺点

①MapReduce的优点：

可扩展性强：MapReduce集群的构建选用廉价的、易于扩展的计算机集群，当集群资源不能满足计算需求时。可以通过增加节点的方式达到线性扩展集群的目的。

容错性强：MapReduce并行计算软件框架使用了多种有效的错误检测和恢复机制，如节点自动重启技术，使集群和计算框架具有对付节点失效的健壮性，能有效处理失效节点的检测和恢复。对于节点故障导致的作业失败，MapReduce的其他节点要能够无缝接管失效节点的计算任务；当故障节点恢复后能自动无缝加入集群，而不需要管理员人工进行系统配置，这些，对于用户来说都是透明的

本地化数据处理：为了减少大规模数据并行计算系统中的数据通信开销，MapReduce将处理向数据靠拢和迁移，即计算节点将首先尽量负责计算其本地存储的数据，以发挥数据本地化特点

易于编程开发：MapReduce提供了一种抽象机制将程序员与系统层细节隔离开来，程序员仅需描述需要计算什么，可以不用考虑进程间通信、套接字编程，只需要实现一些非常简单的逻辑

②MapReduce的缺点：

不适合事务/单一请求处理

不适合高速处理

不适合一般Web应用

4、集群搭建

4.1、搭建模式

4.2、搭建步骤

4.3、启动

4.4、验证

5、平台编程

四、Hive

1、基础知识

1.1、概念

①设计目的：

MapReduce门槛太高，通过Hive让精通过SQL技能，但对Java编程技能相对较弱的分析师能够对存放在HDFS中的大规模数据集执行查询。

②Hive数据类型：

③Hive数据模型：

表(Table)：Hive 中的 Table 和数据库中的 Table 在概念上是类似的，每一个 Table 在 Hive 中都有一个相应的目录存储数据。

分区(Partition)表：Partition对应于数据库中的Partition列的密集索引，但是Hive中Partition 的组织方式和数据库中的很不相同。在Hive中，表中的一个Partition对应于表下的一个目录，所有的Partition的数据都存储在对应的目录中。

桶表(Bucket)：Buckets对指定列计算hash，根据hash值切分数据，目的是为了并行，每一个Bucket对应一个文件

外部表(External Table)：External Table指向已经在HDFS中存在的数据，可以创建Partition。它和Table在元数据的组织上是相同的，而实际数据的存储则有较大的差异。

内部表对数据拥有管理权，External Table只有一个过程，加载数据和创建表同时完成，实际数据是存储在指定的HDFS路径中，并不会移动到数据仓库目录中。当删除一个External Table时，仅删除元数据，表中的数据不会真正被删除。

1.2、区分

①外表 vs 内表：

内部表：数据由Hive自身管理。当删除内部表时，HDFS上的数据以及元数据都会被删除。内部表数据存储的位置默认是hive.metastore.warehouse.dir（通常是/user/hive/warehouse）。对内部表的修改（如添加、删除列等）会直接同步给元数据。 外部表：数据由HDFS管理，而Hive仅记录数据的路径。删除外部表时，仅删除元数据，HDFS上的源数据不会被删除1。外部表数据的存储位置由用户自己指定。对外部表的表结构和分区的修改，需要执行MSCK REPAIR TABLE命令来修复元数据

②Hive编程 vs MR：

查询语言与编程模型：

Hive：Hive为用户提供了一个SQL类型的查询语言，称为HiveQL或HQL，使用户能够像操作SQL一样查询存储在Hadoop分布式文件系统（HDFS）中的大数据。Hive将大多数查询转换为MapReduce任务来执行。 MapReduce：MapReduce是一种计算模型，用于处理大型数据处理任务。它将大型任务分解成多个可以在服务器集群中并行执行的小任务，这些小任务的计算结果可以合并起来计算最终的结果。

应用场景：

Hive：Hive适用于数据仓库应用程序，特别适用于静态数据分析。它主要用于维护海量数据，对数据进行挖掘并形成报告或意见。由于Hive基于Hadoop和HDFS，它不支持记录级别的更新、插入或删除操作，数据本身也不会频繁变化。 MapReduce：MapReduce适用于各种类型的数据处理任务，包括但不限于文本处理、图像处理、机器学习等。它具有很好的可扩展性和容错性，并可以在分布式环境下运行，利用多台计算机进行计算以提高计算效率。

延时与性能：

Hive：由于Hive依赖于MapReduce，而MapReduce任务的启动过程需要消耗较长时间，因此Hive的查询延时通常较为严重，不适合用于交互查询系统。 MapReduce：虽然MapReduce任务的启动过程可能较长，但当任务一旦启动，它可以在集群中的多个节点上并行处理数据，从而提高计算效率。

事务支持：

Hive：Hive不支持事务。 MapReduce：MapReduce本身也不直接支持事务，但可以与支持事务的存储系统（如HBase）结合使用来实现事务性处理。

Hive更适合于数据仓库和数据挖掘场景，而MapReduce则更通用，适用于各种类型的数据处理任务。

2、体系结构

2.1、核心组件

用户接口：负责接收用户的输入命令。主要包括Hive CLI、Beeline、JDBC、ODBC、Web GUI 等。其中Hive CLI和Beeline都是交互式用户接口，并且功能相似；JDBC和ODBC是一种类似于编程访问关系型数据库的访问接口；Web GUI 接口是通过浏览器的访问接口。

元数据存储（MetaStore）：元数据存储：存储着Hive的元数据信息。Hive中的元数据包括表的名字、表的列、分区及期属性、表的属性以及表的数据所在路径等。Metastore是一个独立的关系型数据库。通常是与MySQL数据库连接后创建的一个MySQL实例，也可以是Hive自带的derby数据库实例。

跨语言服务（Thrift Server）：Thrift是Facebook开发的一个开源跨语言的 RPC 软件框架，可以用来进行可扩展且跨语言的服务的开发

底层Driver：Hive的核心是引擎、解释器Parser，包括编译器Compiler，优化器Optimizer，执行器Executor。完成HQL查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在HDFS中，并在随后由MR调用执行

2.2、功能

①分区表：

创建分区表的目的：提高查询效率；使数据的维护和管理更方便；优化资源的使用

②分桶表：

创建分桶表的目的：提高查询效率和为Join操作做数据准备，当join时，仅加载部分分桶的数据到内存，避免内存溢出；抽样调查，如创建桶表，按年龄将数据分到4个桶，抽取两个桶的数据创建一个新表

2.3、总体架构

3、架构原理

3.1、工作原理

①Hive执行流程：

编译器：（将SQL转换为抽象语法树，再将抽象语法书转换为查询快，将查询块转换为逻辑查询计划）SQL-->AST Tree-->QueryBlock-->OperatorTree（将SQL转换为抽象语法树，再将抽象语法书转换为查询快，将查询块转换为逻辑查询计划）；OperatorTree由很多逻辑操作符组成，可以在Map阶段和Reduce阶段完成某一特定操作

优化器：对OperatorTree进行逻辑优化,来合并多余的操作符，以减少MapReduce任务数量以及Shuffle阶段的数据量。对优化后的OperatorTree进行遍历，生成需要执行的MapReduce任务。物理优化器生成最终的MapReduce任务执行计划。

执行器：对最终的MapReduce任务进行执行。

3.2、使用场景及优缺点

①Hive的优缺点：

②使用场景

4、集群搭建

4.1、搭建模式

①Hive元数据存储三种搭建模式：

内嵌模式：元数据保存在内嵌derby中，只允许一个会话链接。

本地模式：本地安装MySQL替代derby存储元数据。

远程模式：远程安装MySQL替代derby存储元数据。

4.2、搭建步骤

4.3、启动

4.4、验证

5、平台编程

五、Spark

1、基础知识

1.1、概念

①设计目标：

一个技术栈解决所有问题，实现迭代计算模型、交互式查询和通用流批处理

许多迭代式算法（比如机器学习、图算法等）和交互式数据挖掘工具，共同之处是，不同计算阶段之间会重用中间结果。目前的MapReduce框架都是把中间结果写入到HDFS中，带来了大量的数据复制、磁盘IO和序列化开销

②RDD（弹性分布式数据集）：

一个RDD就是一个分布式对象集合，本质上是一个只读的分区记录集合，每个RDD可分成多个分区，每个分区就是一个数据集片段，并且一个RDD的不同分区可以被保存到集群中不同的节点上，从而可以在集群中的不同节点上进行并行计算

RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的集合，不能直接修改，只能基于稳定的物理存储中的数据集创建RDD，或者通过在其他RDD上执行确定的转换操作（如map、join和group by）而创建得到新的RDD

RDD提供了一组丰富的操作以支持常见的数据运算，分为“动作”（Action）和“转换”（Transformation）两种类型

RDD提供的转换接口都非常简单，都是粗粒度的数据转换操作，而不是针对某个数据项的细粒度修改（不适合网页爬虫）

1.2、区分

①宽依赖 vs 窄依赖：

②Spark vs Hadoop：

虽然Spark很快，但现在在生产环境中仍然不尽人意，它的存储和调度框架还是依赖于HDFS/YARN，Spark也有自己的调度框架，但仍然非常不成熟，无论扩展性、稳定性、管理性等方面都需要进一步增强，基本不可商用。

同时，Spark在流处理领域能力有限，如果要实现亚秒级或大容量的数据获取或处理需要其他流处理产品。Cloudera宣布旨在让Spark流数据技术适用于80%的使用场合，就考虑到了这一缺陷。实时分析（而非简单数据过滤或分发）场景中，很多以前使用S4或Storm等流式处理引擎的实现已经逐渐被Kafka+Spark Streaming代替

Hadoop现在分三块HDFS/MR/YARN，Spark比Hadoop性能好，只是Spark作为一个计算引擎，比MR的性能要好

2、体系结构

2.1、核心组件

Spark生态系统：

2.2、功能

①RDD分区：

②RDD持久化：

在Spark中，RDD采用惰性求值的机制，每次遇到行动操作，都会从头开始执行计算。每次调用行动操作，都会触发一次从头开始的计算。这对于迭代计算而言，代价是很大的，迭代计算经常需要多次重复使用同一组数据 可以通过持久化（缓存）机制避免这种重复计算的开销可以使用persist()方法对一个RDD标记为持久化并不会马上计算生成RDD并把它持久化，而是要等到遇到第一个行动操作触发真正计算以后，才会把计算结果进行持久化持久化后的RDD将会被保留在计算节点的内存中被后面的行动操作重复使用

2.3、总体架构

3、架构原理

3.1、工作原理

①RDD运行过程：

RDD读入外部数据源进行创建；RDD经过一系列的转换（Transformation）操作，每一次都会产生不同的RDD，供给下一个转换操作使用；最后一个RDD经过“动作”操作进行转换，并输出到外部数据源

这一系列处理称为一个Lineage（血缘关系、世族）

3.2、使用场景及优缺点

①优点：

②

③应用场景

4、集群搭建

4.1、搭建模式

①Spark部署模式：

Local模式：单机模式

Standalone模式：使用Spark自带的简单集群管理器

YARN模式：使用YARN作为集群管理器

Mesos模式：使用Mesos作为集群管理器

4.2、搭建步骤

4.3、启动

①本地模式启动Spark

②独立模式启动Spark

③以不同核数启动Spark

4.4、验证

5、平台编程