第一章：
1PB 被称为大数据
习题：
-
大数据的四个基本特征：4V
- 数据量大 Volume
- 数据类型繁多 Variety
- 处理速度快 Velocity
- 价值密度低 Value
-
科学研究经历了
- 实验范式
- 理论范式
- 计算范式
- 数据范式
-
大数据对思维方式的重要影响
- 全样而非抽样
- 效率而非精确
- 相关而非因果
-
定义并解释以下术语：云计算、物联网
- 云计算：云计算就是实现了通过网络提供可伸缩的、廉价的分布式计算机能力，用户只需要在具备网络接入条件的地方，就可以随时随地获得所需的各种 IT 资源。
- 物联网是物物相连的互联网，是互联网的延伸，它利用局部网络或互联网等通信技术把传感器、控制器、机器、人类和物等通过新的方式连在一起，形成人与物、物与物相连，实现信息化和远程管理控制
第二章：
习题：
-
试述 Hadoop 具有哪些特性
- 高可靠性
- 高效性
- 高可扩展性
- 高容错性
- 成本低
- 运行在 Linux 平台
- 支持多种编程语言
-
Hadoop 生态系统以及每个部分的具体功能
-
-
HDFS
分布式文件系统
-
MapReduce
分布式并行编程模型
-
YARN
资源管理和调度器
-
Tez
运行在 YARN 之上的下一代 Hadoop 查询处理框架
-
Hive
Hadoop 上的数据仓库
-
HBase
Hadoop 上的非关系型的分布式数据库
-
Pig
一个基于 Hadoop 的大规模数据分析平台，提供类似 SQL 的查询语言 Pig Latin
-
Sqoop
用于在 Hadoop 与传统数据库之间进行数据传递
-
Oozie
Hadoop 上的工作流管理系统
-
Zookeeper
提供分布式协调一致性服务
-
Storm
流计算框架
-
Flume
一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统
-
Ambari
Hadoop 快速部署工具，支持 Apache Hadoop 集群的供应、管理和监控
-
Kafka
一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据
-
Spark
类似于 Hadoop MapReduce 的通用并行框架
-
第三章：
-
试述分布式文件系统设计的需求
● 兼容廉价的硬件设备
● 流数据读写：放松 POSIX 要求，以流式方式访问文件系统数据。
● 大数据集：GB 或 TB 级别数据
● 简单的文件模型：“一次写入，多次读取”
● 强大的跨平台兼容性
● 不适合低延迟数据访问：高吞吐率（多节点并行读写）但是高延迟（hadoop 针对高数据吞吐量做了优化，牺牲了获取数据的延迟），不适合毫秒级以内的数据读写
● 无法高效存储大量小文件：大量小文件元数据占用 NameNode 大量内存
● 不支持多用户写入及任意修改文件：对文件采用“一次写入，多次读取”的逻辑设计，不支持文件并发写入、不支持文件修改
-
试述 HDFS 中的名称节点和数据节点的具体功能
-
名称节点记录了每个文件中各个块所在的数据节点的位置信息，但是并不
持久化存储这些信息，而是在系统每次启动时扫描所有数据结点重构得到
这些信息。
-
• 数据节点是分布式文件系统 HDFS 的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，
并且向名称节点定期发送自己所存储的块的列表
• 每个数据节点中的数据会被保存在各自节点的本地 Linux 文件系统中
-
-
HDFS 只设置一个 NameNode 的局限性：
- 命名空间的限制：名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制。
- 性能的瓶颈：整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。
- 隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此，无法对不同应用程序进行隔离。
- 集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。
-
HDFS 冗余数据保存策略
- HDFS 采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上
-
HDFS 流数据读写（流水线复制）
• 当客户端向 HDFS 文件写入数据的时候，一开始是写到本地临时文件中。
• 假设该文件的副本系数设置为 3，当本地临时文件累积到一个数据块的大小时，客户端会从 Namenode 获取一个 Datanode 列表用于存放副本。
• 然后客户端开始向第一个 Datanode 传输数据，第一个 Datanode 一小部分一小部分(4 KB)地接收数据，将每一部分写入本地仓库，并同时传输该部分到列表中第二个 Datanode 节点。
• 第二个 Datanode 也是这样，一小部分一小部分地接收数据，写入本地仓库，并同时传给第三个 Datanode。
• 最后，第三个 Datanode 接收数据并存储在本地。
• 因此，Datanode 能流水线式地从前一个节点接收数据，并在同时转发给下一个节点，数据以流水线的方式从前一个 Datanode 复制到下一个。
-
数据错误与恢复
-
名称节点出错
名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是 FsImage 和 Editlog，如果这两个文件发生损坏，那么整个 HDFS 实例将失效。因此，HDFS 设置了备份机制，把这些核心文件同步复制到备份服务器 SecondaryNameNode 上。当名称节点出错时，就可以根据备份服务器 SecondaryNameNode 中的 FsImage 和 Editlog 数据进行恢复
-
数据节点出错
• 每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态
• 当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何 I/O 请求
• 这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子
• 名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本
• HDFS 和其它分布式文件系统的最大区别就是可以调整冗余数据的位置
-
数据出错
• 网络传输和磁盘错误等因素，都会造成数据错误
• 客户端在读取到数据后，会采用 md5 和 sha1 对数据块进行校验，以确定读取到正确的数据
• 在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面
• 当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块
-
-
读数据的过程（一次写入、多次读取）
• (l) 客户端通过 Filesystem 对象的 open()方法来打开希望读取的文件。
• (2)分布式文件系统通过 RPC 来调用名字节点(Namenode)，来确定文件开头部分数据块的位置。
• (3)客户端对 FSDatalnputstream 输入流调用 read()方法。
• (4) FSDatalnputstream 对象随即与存储着文件开头部分的块的数据节点相连，通过在数据流中反复调用 read()方法，数据就会从数据节点返回到客户端。
• (5)当读取到块的最后一端时，FSDatalnputstream 就会关闭与数据节点间的联系。然后为下一块找到最佳的数据节点。
• (6)当客户端读取完毕时，就会对文件系统输入数据流调用 close()方法。
-
写数据的过程
• (1)客户端通过 Filesystem 对象的 create()方法来创建希望写入的文件。
• (2)分布式文件系统通过 RPC 来调用名字节点(Namenode)，并在文件系统的命名空间中创建一个新文件
• (3)客户端对写入数据调用 write()方法。
• (4) FSDataOutputstream 将客户写入的数据分成一个个的包(write packet)，写入内部的数据队列，然后队列中的数据流依次写入到由数据节点组成的管线中.
• (5) FSDataOutputstream 有一个内部的包队列来等待数据节点发送的确认信息（ack packet），一个包只有在被管线中的所有节点确认后才被转移出包队列
• (6)当客户端完成数据的写入后，就会对数据流调用 close()方法。
• (7)向名字节点发送写入完成的信息。
第四章：
-
阐述 HBase 和传统关系数据库的区别
（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase 则采用了更加简单的数据模型，它把数据存储为未经解释的字符串
（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase 操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为 HBase 在设计上就避免了复杂的表和表之间的关系
（3）存储模式：关系数据库是基于行模式存储的。HBase 是基于列存储的，每个列族都由几个文件保存（同一个列族里面的数据存储在一起，由于 Region 分裂造成文件多于 1 个），不同列族的文件是分离的。
（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase 只有一个索引——行键，通过巧妙的设计，HBase 中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来
（5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在 HBase 中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留
（6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase 和 BigTable 这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。
-
HBase 有哪些类型的访问接口
HBase 提供了 Native Java API , HBase Shell , Thrift Gateway , REST GateWay , Pig , Hive 等访问接口。
-
请以实例说明 HBase 数据模型
-
分别解释 HBase 中行键、列键和时间戳的概念
- 行键是唯一的，在一个表里只出现一次，否则就是在更新同一行，行键可以是任意的字节数组。
- 列族需要在创建表的时候就定义好，数量也不宜过多。列族名必须由可打印字符组成，创建表的时候不需要定义好列。
- 时间戳，默认由系统指定，用户也可以显示设置。使用不同的时间戳来区分不同的版本。
-
请举个实例来阐述 HBase 的概念视图和物理视图的不同
-
HBase 数据的概念视图
-
HBase 数据的物理视图
在 HBase 的概念视图中，一个表可以视为一个稀疏、多维的映射关系。
在物理视图中，一个表会按照属于同一列族的数据保存在一起
-
-
试述 HBase 各功能组建及其作用
（1）库函数：链接到每个客户端；
（2）一个 Master 主服务器：主服务器 Master 负责管理和维护 HBase 表的分区信息，维护 Region 服务器列表，分配 Region，负载均衡
（3）许多个 Region 服务器：
•Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求 • 客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据 • 客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小 -
请阐述 HBase 的数据分区机制
HBase 采用分区存储，一个大的表会被分拆许多个 Region，这些 Region 会被分发到不同的服务器上实现分布式存储。
-
HBase 中的分区是如何定位的
- 每个 Region 都有一个 RegionID 来标识它的唯一性，这样，一个 Region 标识符就可以表示为“表名 + 开始主键 +RegionID”
- 为了定位 Region 所在的位置，需要构建一张映射表，映射表的头目包含 Region 标识符、Region 服务器标识两个信息。
-
试述 HBase 的三层结构中各层次的名称和作用
-
第一层 Zookeeper 文件
记录了-ROOT-表的位置信息
-
第二层-ROOT-表
记录了.META.表的 Region 位置信息-ROOT-表只能有一个 Region。通过-ROOT-表，就可以访问.META.表中的数据
-
第三层.META.表
记录了用户数据表的 Region 位置信息，.META.表可以有多个 Region，保存了 HBase 中所有用户数据表的 Region 位置信息
-
-
请阐述 HBase 的三层结构下，客户端是如何访问到数据的
首先访问 Zookeeper，获取-ROOT 表的位置信息，然后访问-Root-表，获得.MATA.表的信息，接着访问.MATA.表，找到所需的 Region 具体位于哪个 Region 服务器，最后才会到该 Region 服务器读取数据。
-
试述 HBase 系统基本架构以及每个组成部分的作用
（1）客户端
客户端包含访问 HBase 的接口，同时在缓存中维护着已经访问过的 Region 位置信息，用来加快后续数据访问过程
（2）Zookeeper 服务器
Zookeeper 可以帮助选举出一个 Master 作为集群的总管，并保证在任何时刻总有唯一一个 Master 在运行，这就避免了 Master 的“单点失效”问题
（3）Master
主服务器 Master 主要负责表和 Region 的管理工作：管理用户对表的增加、删除、修改、查询等操作；实现不同 Region 服务器之间的负载均衡；在 Region 分裂或合并后，负责重新调整 Region 的分布；对发生故障失效的 Region 服务器上的 Region 进行迁移
（4）Region 服务器
Region 服务器是 HBase 中最核心的模块，负责维护分配给自己的 Region，并响应用户的读写请求
-
请阐述 Region 服务器向 HDFS 文件系统中读写数据的基本原理
• Region 服务器是 Hbase 最核心的模块
• Region 服务器内部管理了一系列的 Region 对象和一个 HLog 文件，其中，HLog 是磁盘上面的记录文件，它记录着所有的更新操作。
• 每个 Region 对象又是由多个 Store 组成的，每个 Store 对应了表中的一个列族的存储。
• 每个 Store 又包含了一个 MemStore 和若干个 StoreFile，其中，MemStore 是在内存中的缓存，保存最近更新的数据；StoreFile 是磁盘中的文件，这些文件是 B 树结构的，方便快速读取。StoreFile 在底层的实现方式就是 HDFS 文件系统的 HFile，HFile 的数据块通常采用压缩方式存储，压缩之后可以大大减少网络 I/O 和磁盘 I/O。
-
试述 HStore 的工作原理
每个 Store 对应了表中的一个列族的存储。每个 Store 包括一个 MenStore 缓存和若干个 StoreFile 文件。MenStore 是排序的内存缓冲区，当用户写入数据时，系统首先把数据放入 MenStore 缓存，当 MemStore 缓存满时，就会刷新到磁盘中的一个 StoreFile 文件中，当单个 StoreFile 文件大小超过一定阈值时，就会触发文件分裂操作。
-
试述 HLog 的工作原理
HBase 系统为每个 Region 服务器配置了一个 HLog 文件，它是一种预写式日志（Write Ahead Log），用户更新数据必须首先写入日志后，才能写入 MemStore 缓存，并且，直到 MemStore 缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘
-
在 HBase 中，每个 Region 服务器维护一个 HLog，而不是为每个 Region 都单独维护一个 HLog。请说明这种做法的优缺点
- 优点： 多个 Region 对象的更新操作所发生的日志修改，只需要不断把日志记录追加到单个日志文件中，不需要同时打开、写入到多个日志文件中。减少磁盘寻址次数，提高对表的写操作性能.
- 缺点：如果一个 Region 服务器发生故障，为了恢复其上次的 Region 对象，需要将 Region 服务器上的对象，需要将 Region 服务器上的 HLog 按照其所属的 Region 对象进行拆分，然后分发到其他 Region 服务器上执行恢复操作。
-
当一台 Region 服务器意外终止时，Master 如何发现这种意外终止情况？为了恢复这台发生意外的 Region 服务器上的 Region,Master 应该做出哪些处理(包括如何使用 HLog 进行恢复)?
- Zookeeper 会实时监测每个 Region 服务器的状态，当某个 Region 服务器发生故障时，Zookeeper 会通知 Master.
- Master 首先会处理该故障 Region 服务器上面遗留的 HLog 文件，这个遗留的 HLog 文件中包含了来自多个 Region 对象的日志记录。
- 系统会根据每条日志记录所属的 Region 对象对 HLog 数据进行拆分，分别放到相应 Region 对象的目录下，然后，再将失效的 Region 重新分配到可用的 Region 服务器中，并把与该 Region 对象相关的 HLog 日志记录也发送给相应的 Region 服务器。
- Region 服务器领取到分配给自己的 Region 对象以及与之相关的 HLog 日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到 MemStore 缓存中，然后，刷新到磁盘的 StoreFile 文件中，完成数据恢复。
-
HBase 常用命令
见第四章 PPT P62
第五章：
-
请比较 NoSQL 数据库和关系数据库的优缺点
-
试述 CAP 理论的具体含义
⚫ C（Consistency）：一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据
⚫ A:（Availability）：可用性，是指快速获取数据，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应；
⚫ P（Tolerance of Network Partition）：分区容忍性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。
第七章：
-
Map 和 Reduce 各自的输入输出以及处理过程
- • Map 函数的输入来自于分布式文件系统的文件块，这些文件块的格式是任意的，可以是文档，也可以是二进制格式的。文件块是一系列元素的集合，这些元素也是任意类型的，同一个元素不能跨文件块存储。Map 函数将输入的元素转换成 <key,value> 形式的键值对，键和值的类型也是任意的，其中键不同于一般的标志属性，即键没有唯一性，不能作为输出的身份标识，即使是同一输入元素，也可通过一个 Map 任务生成具有相同键的多个 <key,value>。
- • Reduce 函数的任务就是将输入的一系列具有相同键的键值对以某种方式组合起来，输出处理后的键值对，输出结果会合并成一个文件。用户可以指定 Reduce 任务的个数（如 n 个），并通知实现系统，然后主控进程通常会选择一个 Hash 函数，Map 任务输出的每个键都会经过 Hash 函数计算，并根据哈希结果将该键值对输入相应的 Reduce 任务来处理。对于处理键为 k 的 Reduce 任务的输入形式为 <k,<v1,v2,…,vn>>，输出为 <k ,V>。
-
MapReduce 的工作流程
• （1）MapReduce 框架使用 InputFormat 模块做 Map 前的预处理，比如验证输入的格式是否符合输入定义；然后，将输入文件切分为逻辑上的多个 InputSplit，InputSplit 是 MapReduce 对文件进行处理和运算的输入单位，只是一个逻辑概念，每个 InputSplit 并没有对文件进行实际切割，只是记录了要处理的数据的位置和长度。
• （2）因为 InputSplit 是逻辑切分而非物理切分，所以还需要通过 RecordReader（RR）根据 InputSplit 中的信息来处理 InputSplit 中的具体记录，加载数据并转换为适合 Map 任务读取的键值对，输入给 Map 任务。
• （3）Map 任务会根据用户自定义的映射规则，输出一系列的 <key,value> 作为中间结果。
• （4）为了让 Reduce 可以并行处理 Map 的结果，需要对 Map 的输出进行一定的分区（Partition）、排序（Sort）、合并（Combine）、归并（Merge）等操作，得到 <key,value-list> 形式的中间结果，再交给对应的 Reduce 进行处理，这个过程称为 Shuffle。从无序的 <key,value> 到有序的 <key,value-list>，这个过程用 Shuffle（洗牌）来称呼是非常形象的。
• （5）Reduce 以一系列 <key,value-list> 中间结果作为输入，执行用户定义的逻辑，输出结果给 OutputFormat 模块。
• （6）OutputFormat 模块会验证输出目录是否已经存在以及输出结果类型是否符合配置文件中的配置类型，如果都满足，就输出 Reduce 的结果到分布式文件系统。
Shuffle 过程简介
（1）在 Map 端的 Shuffle 过程
Map 的输出结果首先被写入缓存，当缓存满时，就启动溢写操作，把缓存中的数据写入磁盘文件，并清空缓存。当启动溢写操作时，首先需要把缓存中的数据进行分区，然后对每个分区的数据进行排序（Sort）和合并（Combine），之后再写入磁盘文件。每次溢写操作会生成一个新的磁盘文件，随着 Map 任务的执行，磁盘中就会生成多个溢写文件。在 Map 任务全部结束之前，这些溢写文件会被归并（Merge）成一个大的磁盘文件，然后通知相应的 Reduce 任务来领取
属于自己处理的数据。
（2）在 Reduce 端的 Shuffle 过程
Reduce 任务从 Map 端的不同 Map 机器领回属于自己处理的那部分数据，然后对数据进行归并（Merge）后交给 Reduce 处理。
-
描述 Map 端和 Reduce 端的 Shuffle 过程（包括溢写、排序、归并、领取的过程）
P15-24，内容较多，建议观看 PPT
-
是否所有的 MapReduce 程序都需要经过 Map 和 Reduce 这两个过程?如果不是，请举例说明
不是。对于关系的选择运算，只需要 Map 过程就能实现，对于关系 R 中的每个元组 t,检测是否是满足条件的所需元组，如果满足条件，则输出键值对 <,>,也就是说，键和值都是 t。这时的 Reduce 函数就只是一个恒等式，对输入不做任何变换就直接输出。
第八章：
YARN 架构中各组件功能
-
ResourceManager
•ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理器 Applications Manager）
•调度器接收来自 ApplicationMaster 的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”
•容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的 CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量
•调度器被设计成是一个可插拔的组件，YARN 不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器
•应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动等
-
ApplicationMaster
ResourceManager 接收用户提交的作业，按照作业的上下文信息以及从 NodeManager 收集来的容器状态信息，启动调度过程，为用户作业启动一个 ApplicationMaster
ApplicationMaster 的主要功能是：
（1）当用户作业提交时，ApplicationMaster 与 ResourceManager 协商获取资源，ResourceManager 会以容器的形式为 ApplicationMaster 分配资源；
（2）把获得的资源进一步分配给内部的各个任务（Map 任务或 Reduce 任务），实现资源的“二次分配”；
（3）与 NodeManager 保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；
（4）定时向 ResourceManager 发送“心跳”消息，报告资源的使用情况和应用的进度信息；
（5）当作业完成时，ApplicationMaster 向 ResourceManager 注销容器，执行周期完成。
-
NodeManager
NodeManager 是驻留在一个 YARN 集群中的每个节点上的代理，主要负责：
•容器生命周期管理
•监控每个容器的资源（CPU、内存等）使用情况
•跟踪节点健康状况
•以“心跳”的方式与 ResourceManager 保持通信
•向 ResourceManager 汇报作业的资源使用情况和每个容器的运行状态
•接收来自 ApplicationMaster 的启动/停止容器的各种请求需要说明的是，NodeManager 主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map 任务或 Reduce 任务）自身状态的管理，因为这些管理工作是由 ApplicationMaster 完成的，ApplicationMaster 会通过不断与 NodeManager 通信来掌握各个任务的执行状态
第九章：
Hive 本身不储存和处理数据，某种程度上可以看作是用户编程接口
Hive 需要把 HiveQL 语句转换成 MapReduce 任务进行运行
-
Hive 与传统数据库的对比
（1）数据插入：在传统数据库中同时支持导入单条数据和批量数据，而 Hive 中仅支持批量导入数据，因为 Hive 主要用来支持大规模数据集上的数据仓库应用程序的运行，常见操作是全表扫描，所以单条插入功能对 Hive 并不实用。
（2）数据更新：更新是传统数据库中很重要的特性，Hive 不支持数据更新。Hive 是一个数据仓库工具，而数据仓库中存放的是静态数据，所以 Hive 不支持对数据进行更新。
（3）索引：索引也是传统数据库中很重要的特性，Hive 在 hive 0.7 版本后已经可以支持索引了。但 Hive 不像传统的关系型数据库那样有键的概念，它只提供有限的索引功能，使用户可以在某些列上创建索引来加速一些查询操作，Hive 中给一个表创建的索引数据被保存在另外的表中。
（4）分区：传统的数据库提供分区功能来改善大型表以及具有各种访问模式的表的可伸缩性，可管理性和提高数据库效率。Hive 也支持分区功能，Hive 表组织成分区的形式，根据分区列的值对表进行粗略的划分，使用分区可以加快数据的查询速度。
（5）执行延迟：因为 Hive 构建于 HDFS 与 MapReduce 上，所以对比传统数据库来说 Hive 的延迟比较高，传统的 SQL 语句的延迟少于一秒，而 HiveQL 语句的延迟会达到分钟级。
（6）扩展性：传统关系数据库很难横向扩展，纵向扩展的空间也很有限。相反 Hive 的开发环境是基于集群的，所以具有较好的可扩展性。
-
Hive 的访问方式
JDBC、ODBC 以及 Thrift Server 可以向用户提供进行编程访问的接口
-
Hive 的几个模块
-
• 用户接口模块：包括 CLI、HWI、JDBC、ODBC、Thrift Server 等。
CLI 是 Hive 自带的一个命令行界面；
HWI 是 Hive 的一个简单网页界面；
JDBC、ODBC 以及 Thrift Server 可以向用户提供进行编程访问的接口。
-
• 驱动模块：包括编译器、优化器、执行器等。
所有命令和查询都会进入到驱动模块，通过该模块对输入进行解析编译，对需求的计算进行优化，然后按照指定的步骤进行执行。
-
• 元数据存储模块（Metastore）：是一个独立的关系型数据库。
通常是与 MySQL 数据库连接后创建的一个 MySQL 实例，也可以是 Hive 自带的 derby 数据库实例。元数据存储模块中主要保存表模式和其他系统元数据，如表的名称、表的列及其属性、表的分区及其属性、表的属性、表中数据所在位置信息等。
-
-
向 Hive 输入一段命令或查询的具体查询过程
•
第 0 步：用户通过命令行 CLI 或其他 Hive 访问工具，向 Hive 输入一段命令或查询。
•
第 1 步：由 Hive 驱动模块中的编译器——Antlr 语言识别工具，对用户输入的 SQL 语言进行词法和语法解析，将 SQL 语句转化为抽象语法树（AST Tree）的形式。
•
第 2 步：对该抽象语法树进行遍历，进一步转化成 QueryBlock 查询单元。因为抽象语法树的结构仍很复杂，不方便直接翻译为 MapReduce 算法程序，所以 Hive 把抽象语法树进一步转化为 QueryBlock，其中 QueryBlock 是一条最基本的 SQL 语法组成单元，包括输入源、计算过程和输出三部分。
•
第 3 步：再对 QueryBlock 进行遍历，生成执行操作树（OperatorTree）。其中，OperatorTree 由很多逻辑操作符组成，如 TableScanOperator，SelectOperator，FilterOperator，JoinOperator，GroupByOperatorReduceSinkOperator 等。这些逻辑操作符可以在 Map 阶段和 Reduce 阶段完成某一特定操作。
•
第 4 步：通过 Hive 驱动模块中的逻辑优化器对 OperatorTree 进行优化。变换 OperatorTree 的形式，来合并多余的操作符，已减少 MapReduce 任务数量以及 Shuffle 阶段的数据量。
-
Hive HA 基本原理
• 在 Hadoop 集群上构建的数据仓库由多个 Hive 进行管理
• 将若干个 hive 实例纳入一个资源池，然后由 HAProxy 提供一个统一的对外接口
• 客户端的查询请求首先访问 HAProxy，由 HAProxy 对访问请求进行转发。
• HAProxy 收到请求后，会轮询资源池里可用的 Hive 实例，执行逻辑可用性测试。如可用，则将客户端的访问请求转发到该 Hive 实例；若不可用，则将它放进黑名单，并取出下一个 Hive 实例进行逻辑测试。
• 对于黑名单中的 Hive 实例，Hive HA 会每隔一段时间进行统一处理，尝试重启，若成功则放入资源池。
• 对于程序开发人员，就把它认为是一台超强“hive"。每次它接收到一个 HIVE 查询连接后，都会轮询资源池里可用的 hive 资源。
第十章：
-
Spark 的出现是为了解决 Hadoop MapReduce 的不足，试列举 Hadoop MapReduce 的几个缺陷，并说明 Spark 具备哪些优点
-
Hadoop 存在如下一些缺点：
• 表达能力有限。计算都必须转化为 Map 和 Reduce 两个操作，但这并不适合所有的情况，难以描述复杂的数据处理过程。
• 磁盘 IO 开销大。每次执行时都要从磁盘读取数据，并且在计算完成后需要将中间结果写入到磁盘，IO 开销大。
• 延迟高
- 一次计算可能需要分解成一系列按顺序执行的 MapReduce 任务，任务之间的衔接涉及 IO 开销延迟较高
- 在前一个任务执行完成之前，其他任务就无法开始，难以胜任复杂、多阶段的计算任务
-
相比于 Hadoop MapReduce，Spark 主要具有如下优点：
• Spark 的计算模式也属于 MapReduce，但不局限于 Map 和 Reduce 操作，还提供了多种数据集操作类型，编程模型比 Hadoop MapReduce 更灵活
• Spark 提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更高
• Spark 基于 DAG 的任务调度执行机制，要优于 Hadoop MapReduce 的迭代执行机制
-
-
Spark 已打造出结构一体化，功能多样化的大数据生态系统，试述 Spark 的生态系统。
• Spark 的设计遵循“一个软件栈满足不同应用场景”的理念，逐渐形成了一套完整的生态系统
• 既能够提供内存计算框架，也可以支持 SQL 即席查询、实时流式计算、机器学习和图计算等
• Spark 可以部署在资源管理器 YARN 之上，提供一站式的大数据解决方案
• 因此，Spark 所提供的生态系统足以应对上述三种场景，即同时支持批处理、交互式查询和流数据处理
Spark 的生态系统主要包含了 Spark Core、Spark SQL、Spark Streaming、MLLib 和 GraphX 等组件
• Spark Core
Spark Core 包含 Spark 的基本功能，如内存计算、任务调度、部署模式、故障恢复、
存储管理等。Spark 建立在统一的抽象 RDD 之上，使其可以以基本一致的方式应
对不同的大数据处理场景。通常所说的 Apache Spark，就是指 Spark Core。
• Spark SQL
Spark SQL 允许开发人员直接处理 RDD，同时也可查询 Hive、HBase 等外部数据源。
Spark SQL 的一个重要特点是其能够统一处理关系表和 RDD，使得开发人员可
以轻松地使用 SQL 命令进行查询，并进行更复杂的数据分析。
• Spark Streaming
Spark Streaming 支持高吞吐量、可容错处理的实时流数据处理，其核心思路是将
流式计算分解成一系列短小的批处理作业。Spark Streaming 支持多种数据输入
源，如 Kafka、Flume 和 TCP 套接字。
• MLlib（机器学习）
MLlib 提供了常用机器学习算法的实现，包括聚类、分类、回归、协同过滤等，降
低了机器学习的门槛，开发人员只要具备一定的理论知识就能进行机器学习的
工作。
• GraphX（图计算）
GraphX 是 Spark 中用于图计算的 API，可认为是 Pregel 在 Spark 上的重写及优化，
Graphx 性能良好，拥有丰富的功能和运算符，能在海量数据上自如地运行复杂
的图算法。
-
试述“Spark on YARN”的概念
Spark 可以运行与 YARN 之上，与 Hadoop 进行统一部署，即“Spark on YARN”，其架构如图所示，资源管理和调度以来 YARN，分布式存储则以来 HDFS
-
试述如下 Spark 的几个主要概念：RDD、DAG、阶段、分区、窄依赖、宽依赖
①RDD：是弹性分布式数据集（Resilient Distributed Dataset）的英文缩写，是分布式内存的一个抽象概念，提供了一种高度受限的共享内存模型。
②DAG：是 Directed Acyclic Graph（有向无环图）的英文缩写，反映 RDD 之间的依赖关系。
③ 阶段：是作业的基本调度单位，一个作业会分为多组任务，每组任务被称为“阶段”，或者也被称为“任务集”。
④ 分区：一个 RDD 就是一个分布式对象集合，本质上是一个只读的分区记录集合，每个 RDD 可以分成多个分区，每个分区就是一个数据集片段。
⑤ 窄依赖：父 RDD 的一个分区只被一个子 RDD 的一个分区所使用就是窄依赖。
⑥ 宽依赖：父 RDD 的一个分区被一个子 RDD 的多个分区所使用就是宽依赖。
-
Spark 对 RDD 的操作主要分为行动（Action）和转换（Transformation）两种类型，两种类型操作的区别是什么？
行动（Action）：在数据集上进行运算，返回计算值。
转换（Transformation）：基于现有的数据集创建一个新的数据集。
第十一章：
Spark Streaming 与 Storm 的对比
• Spark Streaming 和 Storm 最大的区别在于，SparkStreaming 无法实现毫秒级的流计算，而 Storm 可以实现毫秒级响应
• Spark Streaming 构建在 Spark 上，一方面是因为 Spark 的低延迟执行引擎（100ms+）可以用于实时计算，另一方面，相比于 Storm，RDD 数据集更容易做高效的容错处理
• Spark Streaming 采用的小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法，因此，方便了一些需要历史数据和实时数据联合分析的特定应用场合
第十二章：
-
Flink 核心组件栈
（1）物理部署层。Flink 的底层是物理部署层。Flink 可以采用 Local 模式运行，启动单个 JVM，
也可以采用 Standalone 集群模式运行，还可以采用 YARN 集群模式运行，或者也可以运行在谷歌
云服务（GCE）和亚马逊云服务（EC2）上。
（2）Runtime 核心层。该层主要负责对上层不同接口提供基础服务，也是 Flink 分布式计算框
架的核心实现层。该层提供了两套核心的 API：流处理（DataStream API）和批处理（DataSet API）。
（3）API&Libraries 层。作为分布式数据库处理框架，Flink 提供了支撑流计算和批计算的接口，同时，在此基础上抽象出不同的应用类型的组件库，如 CEP（基于流处理的复杂事件处理库）、SQL&Table 库（既可以基于流处理，也可以基于批处理）、FlinkML（基于批处理的机器学习库）、Gelly（基于批处理的图计算库）等。
-
JobManager 和 TaskManager
JobManager
– 单个作业的协调者，每个作业有一个 JobManager
– 将 JobGraph 转化为物理执行图 ExecutionGraph
– 向 ResourceManager 申请资源
– 管理 TaskManager，将具体计算任务分发部署到多个 TaskManager 上
TaskManager
• 负责具体计算任务的执行
• 提供一定量的任务槽位（Task Slot，简称 Slot），Flink 作业运行在这些 Slot 上
• Slot 会注册到 ResourceManager 上，ResourceManager 分配这些 Slot 给具体的作业
JobManager 负责协调资源分配和作业执行，它首先要做的是分配所需的资源。资源
分配完成后，任务将提交给相应的 TaskManager。在接收任务时，TaskManager 启动一个线程以开
始执行。执行到位时，TaskManager 会继续向 JobManager 报告状态更改。作业可以有各种状态，
例如开始执行、正在进行或已完成。作业执行完成后，其结果将发送回客户端（Job Client）。
-
Flink 编程模式的层次架构
-
对比分析 Flink、Spark、Storm
（1）同时支持高吞吐、低延迟、高性能。
对于分布式流计算框架而言，同时支持高吞吐、低延迟和高性能非常重要。但是，目前在开源社区中，能够同时满足这 3 个方面要求的流计算框架只有 Flink。Storm 可以做到低延迟，但是无法实现高吞吐。Spark Streaming 可以实现高吞吐和容错性，但是不具备低延迟和实时处理能力。
（2）同时支持流处理和批处理。
Flink 不仅擅长流处理，也能够很好地支持批处理。对于 Flink 而言，批量数据是流数据的一个子集，批处理被视作一种特殊的流处理，因此，可以通过一套引擎来处理流数据和批量数据。
（3）高度灵活的流式窗口。
在流计算中，数据流是无限的，无法直接进行计算，因此，Flink 提出了窗口的概念。一个窗口是若干元素的集合，流计算以窗口为基本单元进行数据处理。窗口可以是时间驱动的（Time Window，例如每 30 秒），也可以是数据驱动的（Count Window，例如每 100 个元素）。窗口可以分为翻滚窗口（TumblingWindow，无重叠）、滚动窗口（Sliding Window，有重叠）和会话窗口（SessionWindow）。
（4）支持有状态计算。
流计算分为无状态和有状态两种情况。无状态计算观察每个独立的事件，并根据最后一个事件输出结果，Storm 就是无状态的计算框架，每一条消息来了以后，彼此都是独立的，和前后都没有关系。有状态的计算则会基于多个事件输出结
果。正确地实现有状态计算，比实现无状态计算难得多。Flink 就是可以支持有状态计算的新一代流处理框架。
（5）具有良好的容错性。
当分布式系统引入状态时，就会产生“一致性”问题。一致性实际上是“正确性级别”的另一种说法，也就是说，在成功处理故障并恢复之后得到的结果，与没有发生故障时得到的结果相比，前者有多正确。Storm 只能实现“至少一次”（At-least-once）的容错性，Spark Streaming 虽然可以支持“精确一次”的容错性，但是，无法做到毫秒级的实时处理。Flink 提供了容错机制，可以恢复数据流应用到一致状态。该机制确保在发生故障时，程序的状态最终将只反映数据流中的每个记录一次，也就是实现了“精确一次”的容错性。容错机制不断地创建分布式数据流的快照，对于小状态的流式程序，快照非常轻量，可以高频率创建而对性能影响很小。
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于