Hadoop学习笔记之组件了解

                        Hadoop生态图

HDFS-分布式文件系统
作用：服务器以集群方式存在的时候,磁盘空间合并起来，HDFS用来管理合并起来的空间。
YARN
管理集群中的CPU以及内存（YARN是基于HDFS之上的）
框架：
HBase:
分布式列式数据库（分布式数据库，列式数据库），HBase不支持多行事务和跨表事务。下面我们介绍列式数据库与关系数据库的区别。

EmpId Lastname Firstname Salary 1 Smith Joe 40000 2 Jones Mary 50000 3 Johnson Cathy 44000

在行式数据库（关系数据库）中是按照如下方式在内存中存储的
1,Smith,Joe,40000;2,Jones,Mary,50000;3,Johnson,Cathy,44000;
在列式数据库中是按照如下方式在内存中存储的
1,2,3;Smith,Jones,Johnson;Joe,Mary,Cathy;40000,50000,44000;
列式数据库的优点：
不读取无效数据：降低 I/O 开销，同时提高每次 I/O 的效率，从而大大提高查询性能。查询语句只从磁盘上读取所需要的列，其他列的数据是不需要读取的。例如，有两张表，每张表100GB 且有100 列，大多数查询只关注几个列，采用列存储，不需要像行存数据库一样，将整行数据取出，只取出需要的列。磁盘 I/0 是行存储的 1/10或更少，查询响应时间提高 10 倍以上。
高压缩比：压缩比可以达到 5 ~ 20 倍以上，数据占有空间降低到传统数据库的1/10 ，节省了存储设备的开销。
当数据库的大小与数据库服务器内存大小之比达到或超过 2:1 （典型的大型系统配置值）时，列存的 I/O 优势就显得更加明显；
适合聚合操作。
缺点：
插入和更新的操作特别慢（因为每一次要扫描好多列）。
根据上面的介绍可以看出在HBase下比较容易做大数据分析。
MapReduce-分布式离线计算框架（hadoop自带）
MR是所有计算框架的源头。
作用：在HDFS上所有SQL标准能做的事情，我们都可以通过MR在分布式框架上面做到。
流式计算：
storm->Flink->Spark Streaming
实时性从高到低，抗压性从低到高。
流式计算与批量计算的区别如下：
· 如图 1所示,批量计算首先进行数据的存储,然后再对存储的静态数据进行集中计算.Hadoop是典型的大数据批量计算架构,由HDFS分布式文件系统负责静态数据的存储,并通过MapReduce将计算逻辑分配到各数据节点进行数据计算和价值发现;

如图 2所示,流式计算中,无法确定数据的到来时刻和到来顺序,也无法将全部数据存储起来.因此,不再进行流式数据的存储,而是当流动的数据到来后在内存中直接进行数据的实时计算.如Twitter的Storm、Yahoo的S4就是典型的流式数据计算架构,数据在任务拓扑中被计算,并输出有价值的信息.

流式计算和批量计算分别适用于不同的大数据应用场景:对于先存储后计算,实时性要求不高,同时,数据的准确性、全面性更为重要的应用场景,批量计算模式更合适;对于无需先存储,可以直接进行数据计算,实时性要求很严格,但数据的精确度要求稍微宽松的应用场景,流式计算具有明显优势.流式计算中,数据往往是最近一个时间窗口内的,因此数据延迟往往较短,实时性较强,但数据的精确程度往往较低.流式计算和批量计算具有明显的优劣互补特征,在多种应用场合下可以将两者结合起来使用.通过发挥流式计算的实时性优势和批量计算的计算精度优势,满足多种应用场景在不同阶段的数据计算要求。
Spark-分布式内存计算
需求大量的内存和CPU，没有离线和实时的概念，服务器的配置，1个核2个G的内存配置，最差情况下1个核4个G的内存配置。
Tez
在MR的基础上面做封装优化（例如SQL的嵌套），使用Tez做大量的数据查询的时候比较快。
Hive
给不会使用MR的人使用，我们写SQL，Hive会把它转化成MR语句，因此Hive继承MR的所有优缺点。
Flume
数据在远端，我们可以把数据源从远端传到本地。
sqoop:
一个导数据的工具，可以把数据从关系数据库中导入到HDFS中，对oracle的版本部分类型支持比较差。HDFS->HBase,HBase->HDFS。
Oozie
可以控制任务在什么时候做，频率多少（Python调用shell脚本）
大数据学习小贴士：
必会框架：
zookeeper
(1)投票器
(2)分布式锁
(3)协同（强制数据库同步）

分布式锁功能：
当很多进程需要访问共享资源时，我们可以通过zk来实现分布式锁。主要步骤是：
1.建立一个节点，假如名为：lock 。节点类型为持久节点（PERSISTENT）
2.每当进程需要访问共享资源时，会调用分布式锁的lock()或tryLock()方法获得锁，这个时候会在第一步创建的lock节点下建立相应的顺序子节点，节点类型为临时顺序节点（EPHEMERAL_SEQUENTIAL），通过组成特定的名字name+lock+顺序号。
3.在建立子节点后，对lock下面的所有以name开头的子节点进行排序，判断刚刚建立的子节点顺序号是否是最小的节点，假如是最小节点，则获得该锁对资源进行访问。
4.假如不是该节点，就获得该节点的上一顺序节点，并给该节点是否存在注册监听事件。同时在这里阻塞。等待监听事件的发生，获得锁控制权。
5.当调用完共享资源后，调用unlock（）方法，关闭zk，进而可以引发监听事件，释放该锁。
实现的分布式锁是严格的按照顺序访问的并发锁。
协同功能（强制数据同步）：
应用项目中都会有一些配置信息，这些配置信息数据量少，一般会保存到内存、文件或者数据库，有时候需要动态更新。当需要在多个应用服务器中修改这些配置文件时，需要做到快速、简单、不停止应用服务器的方式修改并同步配置信息到所有应用中去。本篇文章就是介绍如何使用ZooKeeper来实现配置的动态同步。
投票器：
1.每个Sever服务器启动以后都会询问其他的Sever服务器要投票给谁
2.对于其他服务器的询问，服务器每次都会根据自己的状态恢复自己推荐的Leader的id和上一次处理事务的zxid，但是系统启动的时候每个服务器都会推荐自己的
3.自己服务器收到其他所有的服务器回复以后，就计算出zxid最大的那个服务器，并将这个服务器相关信息设置成下一次要投票的Sever
4.计算的过程中获得的票数最多，且票数要过半数的服务器就选为Leader，否则要一直继续这个选举的过程，知道Leader被选举出来
5.选出的Leader开始等待其他服务器Follower的连接
6.Follower连接Leader将最大的zxid发送给Leader
7.Leader根据Follwer的zxid来确定同步点，，完成同步后通知Follower已经成为update（现时）状态
8.Follower收到update消息后，就可以接受Client的请求服务了。
为了让投票肯定成功，所以我们必须设置奇数个节点（3,5,7,9）.