Hadoop
# Hadoop MapReduce八大步骤以及Yarn工作原理详解
Map阶段:
- 第一步: 通过FileInputFormat读取文件, 解析文件成为key, value对, 输出到第二步.
- 第二步: 自定义Map逻辑, 处理key1, value1, 将其转换为key2, value2, 输出到第三步.
Shuffle阶段://数据分区，排序，分组，规约，合并等过程）
- 第三步: 对key2, value2进行分区.
- 第四步: 对不同分区内的数据按照相同的key进行排序.
- 第五步: 分组后的数据进行规约(combine操作)，降低数据的网络拷贝（可选步骤）
- 第六步: 对排序后的数据, 将相同的key的value数据放入一个集合中, 作为value2.
Reduce阶段:
- 第七步: 对多个map的任务进行合并, 排序. 自定义reduce逻辑, 处理key2, value2, 将其转换为key3, value3, 进行输出.
- 第八步: 通过FileOutputFormat输出处理后的数据, 保存到文件.
hadoop小文件存储处理
**Hadoop Archive:**
Haddop Archive是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样同时在减少Namenode的内存使用。
II**、Sequence file：**
sequence file由一系列的二进制key/value组成。key为小文件名，value为文件内容，可以将大批小文件合并成一个大文件。
**从小文件的产生途径解决：**
1. 使用sequencefile作为表存储形式，不要使用textfile，在一定程度上可以减少小文件
2. 减少reduce的个数（减少生成分区数量）
3. 少用动态分区，使用distribute by分区
**对已经存在的小文件做出的解决方案：**
1. 使用Hadoop achieve把小文件进行归档
2. 重建表，建表时减少reduce的数量
3. 通过参数调节，设置map/reduce的数量
Hive
hive运行原理
.JobTracker接收到作业后，将其放在一个作业队列里，等待作业调度器对其进行调度，当作业调度器根据自己的调度算法调度到该作业时，会根据输入划分信息为每个划分创建一个map任务，并将map任务分配给TaskTracker执行；
6.对于map和reduce任务，TaskTracker根据主机核的数量和内存的大小有固定数量的map槽和reduce槽。这里需要强调的是：map任务不是随随便便地分配给某个TaskTracker的，这里有个概念叫：数据本地化（Data-Local）。意思是：将map任务分配给含有该map处理的数据块的TaskTracker上，同时将程序JAR包复制到该TaskTracker上来运行，这叫“运算移动，
7.TaskTracker每隔一段时间会给JobTracker发送一个心跳，告诉JobTracker它依然在运行，同时心跳中还携带着很多的信息，比如当前map任务完成的进度等信息。当JobTracker收到作业的最后一个任务完成信息时，便把该作业设置成“成功”。当JobClient查询状态时，它将得知任务已完成，便显示一条消息给用户；
8.运行的TaskTracker从HDFS中获取运行所需要的资源，这些资源包括MapReduce程序打包的JAR文件、配置文件和客户端计算所得的输入划分等信息；
9.TaskTracker获取资源后启动新的JVM虚拟机；
hive执行过程
整个过程的执行步骤如下：
(1) 解释器完成词法、语法和语义的分析以及中间代码生成，最终转换成抽象语法树；
(2) 编译器将语法树编译为逻辑执行计划；
(3) 逻辑层优化器对逻辑执行计划进行优化，由于Hive最终生成的MapReduce任务中，Map阶段和Reduce阶段均由OperatorTree组成，所以大部分逻辑层优化器通过变换OperatorTree，合并操作符，达到减少MapReduce Job和减少shuffle数据量的目的；
(4) 物理层优化器进行MapReduce任务的变换，生成最终的物理执行计划；
(5) 执行器调用底层的运行框架执行最终的物理执行计划。
Kafka
Producer requiredaction consumer
Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么**
> ISR:In-Sync Replicas 副本同步队列
> AR:Assigned Replicas 所有副本
> ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。
**6.kafka follower如何与leader同步数据**
> Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。
**.消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?**
> offset+1
**.Kafka中的消息是否会丢失和重复消费？**
> 要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。
>
> **1、消息发送**
>
> Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：
>
> 1. *0---表示不进行消息接收是否成功的确认；*
> 2. *1---表示当Leader接收成功时确认；*
> 3. *-1---表示Leader和Follower都接收成功时确认；*
========================================
> （1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，**消息可能丢失**；
> （2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，**数据可能丢失**；
> **2、消息消费**
>
> Kafka消息消费有两个consumer接口，Low-level API和High-level API：
>
> 1. Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；
> 2. High-level API：封装了对parition和offset的管理，使用简单；
>
> 如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“*诡异*”的消失了；
>
> **解决办法**：
>
> 针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；
>
> 针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。
>
# kagka吞服量高原因
顺写
o拷贝
分段日志
Hbase
hbase运行原理
.1 读过程
Client访问ZK，通过-ROOT-和.META.表，查找到表的Region元数据，并找到相应的RegionServer
Client直接与RegionServer通信获取数据
Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache
5.2 写过程
Client访问ZK，通过-ROOT-和.META.表，查找到表的Region元数据，并找到相应的RegionServer
数据被写入HLog和Region的MemStore中，当MemStore达到预设阈值后，Flush成一个StoreFile
StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除
StoreFile的大小超过一定阈值后，会把当前的Region分割为两个（Split），并由Hmaster分配到相应的HRegionServer，实现负载均衡
> # hive 与hbase区别
>
> **Hive**是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。**HBase**是Hadoop的数据库，一个分布式、可扩展、大数据的存储。
HBase通过存储key/value来工作。它支持四种主要的操作：增加或者更新行，查看一个范围内的cell，获取指定的行，删除指定的行、列或者是列的版本。版本信息用来获取历史数据(每一行的历史数据可以被删除，然后通过Hbase compactions就可以释放出空间)。虽然HBase包括表格，但是schema仅仅被表格和列簇所要求，列不需要schema。Hbase的表格包括增加/计数功能
## 3.hbase 的存储结构？
答： Hbase 中的每张表都通过行键(rowkey)按照一定的范围被分割成多个子表（HRegion），默认一个 HRegion 超过 256M 就要被分割成两个，由 HRegionServer 管理，管理哪些 HRegion由 Hmaster 分配。 HRegion 存取一个子表时，会创建一个 HRegion 对象，然后对表的每个列族（Column Family）创建一个 store 实例，每个 store 都会有 0 个或多个 StoreFile 与之对应，每个 StoreFile 都会对应一个 HFile， HFile 就是实际的存储文件，因此，一个 HRegion 还拥有一个 MemStore 实例。
## 4.Hbase 和 hive 有什么区别hive 与 hbase 的底层存储是什么？hive是产生的原因是什么？habase是为了弥补hadoop的什么缺陷？
答案:共同点：1.hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储
区别：2.Hive是建立在Hadoop之上为了减少MapReducejobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
3.想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
4.Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
5.Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。
6.hive借用hadoop的MapReduce来完成一些hive中的命令的执行
7.hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
8.hbase是列存储。
9.hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。
10.hive需要用到hdfs存储文件，需要用到MapReduce计算框架。
## 12.HBase 宕机如何处理
答：宕机分为 HMaster 宕机和 HRegisoner 宕机，如果是 HRegisoner 宕机， HMaster 会将其所管理的 region 重新分布到其他活动的 RegionServer 上，由于数据和日志都持久在 HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。如果是 HMaster 宕机， HMaster 没有单点问题， HBase 中可以启动多个 HMaster，通过Zookeeper 的 Master Election 机制保证总有一个 Master 运行。即 ZooKeeper 会保证总会有一个 HMaster 在对外提供服务。
## 13.导致Hbase挂掉的场景
HMaster
HMaster会出现异常(执行abort())停止的场景如下：
1.zk异常导致的master停止服务是最常见的场景，涉及操作包含但不限于以下：
a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟, 如果fail.fast.expired.active.master配置的值为false（默认为false），则不会立即abort，而是会尝试恢复zk的过期session；
b)在打开region后，需要从zk中删除opened节点，如果zk有该节点，但是删除失败；
c)在split region过程中，从zk删除split节点时；
d)Master节点改变时；
e)从zk中创建unassigned节点时；
f)在下线disabled的regoin时，从zk中删除disabled的region如果发生zk异常；
g)还有很多操作zk的节点时如果出现异常。
2.在assign时，如果设置region为offlined状态，但是region之前的状态不是closed或者offlined；
3.在assign时，如果无法从.META.表中读取region信息；
4.把新的hbase集群加入到正在运行的hbase集群时，如果zk的/hbase/unassigned节点没有数据；
5.使用线程池批量分配region时，如果出现未被捕获的异常，实现方式如下：
6.在启动master的服务线程时，出现了异常；
7.在hdfs中检查hbase日志路径时，发现了dead的server时，需从hdfs中读出log，如果出现io异常需要检查hdfs文件系统，如果fsOk状态为true，但是通过FSUtils工具类进行检查时出现io异常；
8.在校验并且分配-ROOT-的region时，如果zk异常，或者其它异常（其它异常会重试10次），比如：“-ROOT- is onlined on the dead server”。
HRegionServer
HRegionServer会出现异常停止(执行abort())服务的场景如下：
1.在读写hdfs时如果出现IOException异常，此时会发起hdfs的文件系统检查（checkFileSystem）1.
2.Regionserver的服务线程出现了未捕获异常；
3.在启动HRegionServer时出现异常；
4.在进行HLog回滚时，出现异常；
5.在flush memstore时，如果持久化失败，会重启RS，在重启中把hlog的内容重新加载到memstore；
6.出现zk异常，包括但不限于以下场景：
a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟，与master不同，如果zk操作不会重试；
b)启动HRegionServer时出现KeeperException异常；
c)在进行split操作时，如果出现异常会进行回滚操作，在回滚过程中需要从zk中删除region的spliting状态，如果删除时出现KeeperException或者回滚的其它操作出现异常；
d)在打开region时，出现了KeeperException异常；
e)在进行hbase集群复制时，很多与zk交互的操作出现KeeperException异常时均会导致abort；
7.在close region时，如果出现异常，比如：不能成功的flush memstore；
8.Flush memstore时，如果HLog发现该region已经在flush则会强制终止JVM，采用的是Runtime.getRuntime().halt(1)方法，该方法不会执行正常退出的关闭钩子，从而不会flush RS的所有region，也不会迁移region，只有等待ZK的session超时后master才会发现该RS不可用，做迁移工作。
0.Hbase是什么？
(1) Hbase一个分布式的基于列式存储的数据库,基于Hadoop的hdfs存储，zookeeper进行管理。
(2) Hbase适合存储半结构化或非结构化数据，对于数据结构字段不够确定或者杂乱无章很难按一个概念去抽取的数据。
(3) Hbase为null的记录不会被存储.
(4)基于的表包含rowkey，时间戳，和列族。新写入数据时，时间戳更新，同时可以查询到以前的版本.
(5) hbase是主从架构。hmaster作为主节点，hregionserver作为从节点。
1. HBase 的特点是什么？
大 无模式 面向列 稀疏 数据多版本 数据类型单一
1）大：一个表可以有数十亿行，上百万列；
2）无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一
张表中不同的行可以有截然不同的列；
3）面向列：面向列（族）的存储和权限控制，列（族）独立检索；
4）稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
5）数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元
格插入时的时间戳；
6）数据类型单一：Hbase 中的数据都是字符串，没有类型。
6.请详细描述 HBase 中一个 cell 的结构？
HBase 中通过 row 和 columns 确定的为一个存贮单元称为 cell。
Cell：由{row key, column(=<family> + <label>), version}唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存贮。
14.如何提高 HBase 客户端的读写性能？请举例说明（☆☆☆☆☆）
1 开启 bloomfilter 过滤器，开启 bloomfilter 比没开启要快 3、4 倍
2 Hbase 对于内存有特别的需求，在硬件允许的情况下配足够多的内存给它
3 通过修改 hbase-env.sh 中的
export HBASE_HEAPSIZE=3000 #这里默认为 1000m
4 增大 RPC 数量
通过修改 hbase-site.xml 中的 hbase.regionserver.handler.count 属性，可以适当的放大RPC 数量，默认值为 10 有点小。
15.直接将时间戳作为行健，在写入单个 region 时候会发生热点问题，为什么呢？（☆☆☆☆☆）
region 中的 rowkey 是有序存储，若时间比较集中。就会存储到一个 region 中，这样一个 region 的数据变多，其它的 region 数据很少，加载数据就会很慢，直到 region 分裂，此问题才会得到缓解。
16.请描述如何解决 HBase 中 region 太小和 region 太大带来的冲突？
Region 过大会发生多次compaction，将数据读一遍并重写一遍到 hdfs 上，占用io，region过小会造成多次 split，region 会下线，影响访问服务，最佳的解决方法是调整 hbase.hregion.max.filesize 为 256m。
Spack运行原理
Spack运行原理
- 为应用构建起基本的运行环境，即由Driver创建一个SparkContext进行资源的申请、任务的分配和监控
- 资源管理器为Executor分配资源，并启动Executor进程
- SparkContext根据RDD的依赖关系构建DAG图，DAG图提交给DAGScheduler解析成Stage，然后把一个个TaskSet提交给底层调度器TaskScheduler处理。
- Executor向SparkContext申请Task，TaskScheduler将Task发放给Executor运行并提供应用程序代码。
- Task在Executor上运行把执行结果反馈给TaskScheduler，然后反馈给DAGScheduler，运行完毕后写入数据并释放所有资源。
Spark运行架构特点：
- 每个Application都有自己专属的Executor进程，并且该进程在Application运行期间一直驻留。Executor进程以多线程的方式运行Task。
- Spark运行过程与资源管理器无关，只要能够获取Executor进程并保存通信即可。
- Task采用数据本地性和推测执行等优化机制。