大数据基础知识点：
java
List特点：元素有放入顺序，元素可重复 ，Set特点：元素无放入顺序，元素不可重复。
数据库的三大范式：原子性、一致性、唯一性
对象和引用对象：对象就是好没有初始化的对象，引用对象即使对这个对象进行了初始化
java
List特点：元素有放入顺序，元素可重复 ，Set特点：元素无放入顺序，元素不可重复。
数据库的三大范式：原子性、一致性、唯一性
对象和引用对象：对象就是好没有初始化的对象，引用对象即使对这个对象进行了初始化
ArrayList 和 Vector ：采用数组方式存储数据的,是根据索引来访问元素的，都可以
根据需要自动扩展内部数据长度，以便增加和插入元素，都允许直接序号索引元素，但
是插入数据要涉及到数组元素移动等内存操作，所以索引数据快插入数据慢，他们最大
的区别就是 synchronized 同步的使用。
LinkedList 使用双向链表实现存储，按序号索引数据需要进行向前或向后遍历，但
是插入数据时只需要记录本项的前后项即可，所以插入数度较快！
如果只是查找特定位置的元素或只在集合的末端增加、移除元素，那么使用 Vector
或 ArrayList 都可以。如果是对其它指定位置的插入、删除操作，最好选择 LinkedList
HashMap、HashTable 的区别及其优缺点：
HashTable 中的方法是同步的 HashMap 的方法在缺省情况下是非同步的 ，
因此在多线程环境下需要做额外的同步机制。
HashTable 不允许有 null 值 key 和 value 都不允许，而 HashMap 允许有 null 值 key和 value 都允许
因此 HashMap 使用 containKey（）来判断是否存在某个键。
HashTable 使用 Enumeration ，而 HashMap 使用 iterator。
Hashtable 是 Dictionary 的子类，HashMap 是 Map 接口的一个实现类。
当需要对字符串进行操作时，使用 StringBuffer 而不是 String，String 是 read-only 的，
如果对它进行修改，会产生临时对象，而 StringBuffer 是可修改的，不会产生临时对象。
根据需要自动扩展内部数据长度，以便增加和插入元素，都允许直接序号索引元素，但
是插入数据要涉及到数组元素移动等内存操作，所以索引数据快插入数据慢，他们最大
的区别就是 synchronized 同步的使用。
LinkedList 使用双向链表实现存储，按序号索引数据需要进行向前或向后遍历，但
是插入数据时只需要记录本项的前后项即可，所以插入数度较快！
如果只是查找特定位置的元素或只在集合的末端增加、移除元素，那么使用 Vector
或 ArrayList 都可以。如果是对其它指定位置的插入、删除操作，最好选择 LinkedList
HashMap、HashTable 的区别及其优缺点：
HashTable 中的方法是同步的 HashMap 的方法在缺省情况下是非同步的 ，
因此在多线程环境下需要做额外的同步机制。
HashTable 不允许有 null 值 key 和 value 都不允许，而 HashMap 允许有 null 值 key和 value 都允许
因此 HashMap 使用 containKey（）来判断是否存在某个键。
HashTable 使用 Enumeration ，而 HashMap 使用 iterator。
Hashtable 是 Dictionary 的子类，HashMap 是 Map 接口的一个实现类。
当需要对字符串进行操作时，使用 StringBuffer 而不是 String，String 是 read-only 的，
如果对它进行修改，会产生临时对象，而 StringBuffer 是可修改的，不会产生临时对象。
hadoop
核心：hdfs mr
RPC--远程过程调用协议
HDFS（Hadoop Distributed File System ）Hadoop分布式文件系统。
特点：① 保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。
② 运行在廉价的机器上。
③ 适合大数据的处理。HDFS默认会将文件分割成block，64M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中。如果小文件太多，那内存的负担会很重。
HDFS：Master和Slave结构 （NameNode、SecondaryNameNode、DataNode）
NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；
SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
DataNode：Slave节点，奴隶，干活的。负责存储client发来的数据块block；执行数据块的读写操作。
热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。
冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。
fsimage:元数据镜像文件（文件系统的目录树。）
edits：元数据的操作日志（针对文件系统做的修改操作记录）
namenode内存中存储的是=fsimage+edits。
SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量
hdfs: namenode(metadata)
故障监测机制
(1)节点失败监测机制：每个DN以固定周期（3秒）向NN发送心跳信息，证明在正常工作
，超过一定时间（10分钟），就认为DN泵机
(2)通信故障监测机制 只要发送数据，接收方就要返回确认码
(3)数据错误监测机制 数据+总和校验码 所有DN都定期向NN发送数据块存储状态
HDFS的存放策略是将一个副本存放在本地机架节点上，另外两个副本放在不同机架的不同节点上。
这样集群可在完全失去某一机架的情况下还能存活。同时，这种策略减少了机架间的数据传输，
提高了写操作的效率，因为数据块只存放在两个不同的机架上，减少了读取数据时需要的网络传输总带宽。这样在一定程度上兼顾了数据安全和网络传输的开销。
这样集群可在完全失去某一机架的情况下还能存活。同时，这种策略减少了机架间的数据传输，
提高了写操作的效率，因为数据块只存放在两个不同的机架上，减少了读取数据时需要的网络传输总带宽。这样在一定程度上兼顾了数据安全和网络传输的开销。
MapReduce作业运行流程：
1.在客户端启动一个作业。
2.向JobTracker请求一个Job ID。
3.将运行作业所需要的资源文件复制到HDFS上，包括MapReduce程序打包的JAR文件、配置文件和客户端计算所得的输入划分信息。
这些文件都存放在JobTracker专门为该作业创建的文件夹中。文件夹名为该作业的Job ID。JAR文件默认会有10个副本（mapred.submit.replication属性控制）；
输入划分信息告诉了JobTracker应该为这个作业启动多少个map任务等信息。
4.JobTracker接收到作业后，将其放在一个作业队列里，等待作业调度器对其进行调度，当作业调度器根据自己的调度算法调度到该作业时，
会根据输入划分信息为每个划分创建一个map任务，并将map任务分配给TaskTracker执行。
对于map和reduce任务，TaskTracker根据主机核的数量和内存的大小有固定数量的map槽和reduce槽。
这里需要强调的是：map任务不是随随便便地分配给某个TaskTracker的，这里有个概念叫：数据本地化（Data-Local）。
意思是：将map任务分配给含有该map处理的数据块的TaskTracker上，同时将程序JAR包复制到该TaskTracker上来运行，这叫“运算移动，数据不移动”。
而分配reduce任务时并不考虑数据本地化。
5.TaskTracker每隔一段时间会给JobTracker发送一个心跳，告诉JobTracker它依然在运行，同时心跳中还携带着很多的信息，比如当前map任务完成的进度等信息。
当JobTracker收到作业的最后一个任务完成信息时，便把该作业设置成“成功”。当JobClient查询状态时，它将得知任务已完成，便显示一条消息给用户。
以上是在客户端、JobTracker、TaskTracker的层次来分析MapReduce的工作原理的，下面我们再细致一点，从map任务和reduce任务的层次来分析分析吧。
1.在客户端启动一个作业。
2.向JobTracker请求一个Job ID。
3.将运行作业所需要的资源文件复制到HDFS上，包括MapReduce程序打包的JAR文件、配置文件和客户端计算所得的输入划分信息。
这些文件都存放在JobTracker专门为该作业创建的文件夹中。文件夹名为该作业的Job ID。JAR文件默认会有10个副本（mapred.submit.replication属性控制）；
输入划分信息告诉了JobTracker应该为这个作业启动多少个map任务等信息。
4.JobTracker接收到作业后，将其放在一个作业队列里，等待作业调度器对其进行调度，当作业调度器根据自己的调度算法调度到该作业时，
会根据输入划分信息为每个划分创建一个map任务，并将map任务分配给TaskTracker执行。
对于map和reduce任务，TaskTracker根据主机核的数量和内存的大小有固定数量的map槽和reduce槽。
这里需要强调的是：map任务不是随随便便地分配给某个TaskTracker的，这里有个概念叫：数据本地化（Data-Local）。
意思是：将map任务分配给含有该map处理的数据块的TaskTracker上，同时将程序JAR包复制到该TaskTracker上来运行，这叫“运算移动，数据不移动”。
而分配reduce任务时并不考虑数据本地化。
5.TaskTracker每隔一段时间会给JobTracker发送一个心跳，告诉JobTracker它依然在运行，同时心跳中还携带着很多的信息，比如当前map任务完成的进度等信息。
当JobTracker收到作业的最后一个任务完成信息时，便把该作业设置成“成功”。当JobClient查询状态时，它将得知任务已完成，便显示一条消息给用户。
以上是在客户端、JobTracker、TaskTracker的层次来分析MapReduce的工作原理的，下面我们再细致一点，从map任务和reduce任务的层次来分析分析吧。
Map端：
1．每个输入分片会让一个map任务来处理，默认情况下，以HDFS的一个块的大小（默认为64M）为一个分片，当然我们也可以设置块的大小。
map输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时
（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。
2．在写入磁盘之前，线程首先根据reduce任务的数目将数据划分为相同数目的分区partition，也就是一个reduce任务对应一个分区的数据。
这样做是为了避免有些reduce任务分配到大量数据，而有些reduce任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行hash的过程。
然后对每个分区中的数据进行排序，如果此时设置了Combiner，将排序后的结果进行Combia操作，这样做的目的是让尽可能少的数据写入到磁盘。
3．当map任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和combia操作，
目的有两个：1.尽量减少每次写入磁盘的数据量；2.尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。
为了减少网络传输的数据量，这里可以将数据压缩，只要将mapred.compress.map.out设置为true就可以了。
4．将分区中的数据拷贝给相对应的reduce任务。
有人可能会问：分区中的数据怎么知道它对应的reduce是哪个呢？其实map任务一直和其父TaskTracker保持联系，而TaskTracker又一直和JobTracker保持心跳。
所以JobTracker中保存了整个集群中的宏观信息。只要reduce任务向JobTracker获取对应的map输出位置就ok了哦。
到这里，map端就分析完了。
那到底什么是Shuffle呢？Shuffle的中文意思是“洗牌”，如果我们这样看：一个map产生的数据，结果通过hash过程分区却分配给了不同的reduce任务，
是不是一个对数据洗牌的过程呢？
1．每个输入分片会让一个map任务来处理，默认情况下，以HDFS的一个块的大小（默认为64M）为一个分片，当然我们也可以设置块的大小。
map输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时
（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。
2．在写入磁盘之前，线程首先根据reduce任务的数目将数据划分为相同数目的分区partition，也就是一个reduce任务对应一个分区的数据。
这样做是为了避免有些reduce任务分配到大量数据，而有些reduce任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行hash的过程。
然后对每个分区中的数据进行排序，如果此时设置了Combiner，将排序后的结果进行Combia操作，这样做的目的是让尽可能少的数据写入到磁盘。
3．当map任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和combia操作，
目的有两个：1.尽量减少每次写入磁盘的数据量；2.尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。
为了减少网络传输的数据量，这里可以将数据压缩，只要将mapred.compress.map.out设置为true就可以了。
4．将分区中的数据拷贝给相对应的reduce任务。
有人可能会问：分区中的数据怎么知道它对应的reduce是哪个呢？其实map任务一直和其父TaskTracker保持联系，而TaskTracker又一直和JobTracker保持心跳。
所以JobTracker中保存了整个集群中的宏观信息。只要reduce任务向JobTracker获取对应的map输出位置就ok了哦。
到这里，map端就分析完了。
那到底什么是Shuffle呢？Shuffle的中文意思是“洗牌”，如果我们这样看：一个map产生的数据，结果通过hash过程分区却分配给了不同的reduce任务，
是不是一个对数据洗牌的过程呢？
Reduce端：
1．Reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接受的数据量相当小，则直接存储在内存中（
缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间的百分比），如果数据量超过了该缓冲区大小的一定比例
（由mapred.job.shuffle.merge.percent决定），则对数据合并后溢写到磁盘中。
2．随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省时间。其实不管在map端还是reduce端，MapReduce都是反复地执行排序，
合并操作，现在终于明白了有些人为什么会说：排序是hadoop的灵魂。
3．合并的过程中会产生许多的中间文件（写入磁盘了），但MapReduce会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。
1．Reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接受的数据量相当小，则直接存储在内存中（
缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间的百分比），如果数据量超过了该缓冲区大小的一定比例
（由mapred.job.shuffle.merge.percent决定），则对数据合并后溢写到磁盘中。
2．随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省时间。其实不管在map端还是reduce端，MapReduce都是反复地执行排序，
合并操作，现在终于明白了有些人为什么会说：排序是hadoop的灵魂。
3．合并的过程中会产生许多的中间文件（写入磁盘了），但MapReduce会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。
Shuffle阶段：指从Map的输出开始，包括系统执行排序以及传送Map输出到Reduce作为输入的过程。
Sort阶段：指对Map端输出的Key进行排序的过程。不同的Map可能输出相同的Key，相同的Key必须发送到同一个Reduce端处理。
Sort阶段：指对Map端输出的Key进行排序的过程。不同的Map可能输出相同的Key，相同的Key必须发送到同一个Reduce端处理。
Shuffle阶段可以分为Map端的Shuffle和Reduce端的Shuffle。
1. Map端的Shuffle
Map函数开始产生输出时，并不是简单地把数据写到磁盘，因为频繁的磁盘操作会导致性能严重下降。它的处理过程更复杂，数据首先写到内存中的一个缓冲区，并做一些预排序，以提升效率；
每个MapTask都有一个用来写入输出数据的循环内存缓冲区（默认大小为100MB），当缓冲区中的数据量达到一个特定阈值时（默认是80%）系统将会启动一个后台线程把缓冲区中的内容写到磁盘（即spill阶段）。
在写磁盘过程中，Map输出继续被写到缓冲区，但如果在此期间缓冲区被填满，那么Map就会阻塞直到写磁盘过程完成；
在写磁盘前，线程首先根据数据最终要传递到的Reducer把数据划分成相应的分区（partition）。在每个分区中，后台线程按Key进行排序（快速排序），如果有一个Combiner（即Mini Reducer）便会在排序后的输出上运行；
一旦内存缓冲区达到溢出写的阈值，就会创建一个溢出写文件，因此在MapTask完成其最后一个输出记录后，便会有多个溢出写文件。在在MapTask完成前，溢出写文件被合并成一个索引文件和数据文件（多路归并排序）（Sort阶段）；
溢出写文件归并完毕后，Map将删除所有的临时溢出写文件，并告知TaskTracker任务已完成，只要其中一个MapTask完成，ReduceTask就开始复制它的输出（Copy阶段）；
Map的输出文件放置在运行MapTask的TaskTracker的本地磁盘上，它是运行ReduceTask的TaskTracker所需要的输入数据，但是Reduce输出不是这样的，它一般写到HDFS中（Reduce阶段）。
2. Reduce端的Shuffle
Copy阶段：Reduce进程启动一些数据copy线程，通过HTTP方式请求MapTask所在的TaskTracker以获取输出文件。
Merge阶段：将Map端复制过来的数据先放入内存缓冲区中，Merge有3种形式，分别是内存到内存，内存到磁盘，磁盘到磁盘。默认情况下第一种形式不启用，第二种Merge方式一直在运行（spill阶段）直到结束，然后启用第三种磁盘到磁盘的Merge方式生成最终的文件。
Reduce阶段：最终文件可能存在于磁盘，也可能存在于内存中，但是默认情况下是位于磁盘中的。当Reduce的输入文件已定，整个Shuffle就结束了，然后就是Reduce执行，把结果放到HDFS中。
1. Map端的Shuffle
Map函数开始产生输出时，并不是简单地把数据写到磁盘，因为频繁的磁盘操作会导致性能严重下降。它的处理过程更复杂，数据首先写到内存中的一个缓冲区，并做一些预排序，以提升效率；
每个MapTask都有一个用来写入输出数据的循环内存缓冲区（默认大小为100MB），当缓冲区中的数据量达到一个特定阈值时（默认是80%）系统将会启动一个后台线程把缓冲区中的内容写到磁盘（即spill阶段）。
在写磁盘过程中，Map输出继续被写到缓冲区，但如果在此期间缓冲区被填满，那么Map就会阻塞直到写磁盘过程完成；
在写磁盘前，线程首先根据数据最终要传递到的Reducer把数据划分成相应的分区（partition）。在每个分区中，后台线程按Key进行排序（快速排序），如果有一个Combiner（即Mini Reducer）便会在排序后的输出上运行；
一旦内存缓冲区达到溢出写的阈值，就会创建一个溢出写文件，因此在MapTask完成其最后一个输出记录后，便会有多个溢出写文件。在在MapTask完成前，溢出写文件被合并成一个索引文件和数据文件（多路归并排序）（Sort阶段）；
溢出写文件归并完毕后，Map将删除所有的临时溢出写文件，并告知TaskTracker任务已完成，只要其中一个MapTask完成，ReduceTask就开始复制它的输出（Copy阶段）；
Map的输出文件放置在运行MapTask的TaskTracker的本地磁盘上，它是运行ReduceTask的TaskTracker所需要的输入数据，但是Reduce输出不是这样的，它一般写到HDFS中（Reduce阶段）。
2. Reduce端的Shuffle
Copy阶段：Reduce进程启动一些数据copy线程，通过HTTP方式请求MapTask所在的TaskTracker以获取输出文件。
Merge阶段：将Map端复制过来的数据先放入内存缓冲区中，Merge有3种形式，分别是内存到内存，内存到磁盘，磁盘到磁盘。默认情况下第一种形式不启用，第二种Merge方式一直在运行（spill阶段）直到结束，然后启用第三种磁盘到磁盘的Merge方式生成最终的文件。
Reduce阶段：最终文件可能存在于磁盘，也可能存在于内存中，但是默认情况下是位于磁盘中的。当Reduce的输入文件已定，整个Shuffle就结束了，然后就是Reduce执行，把结果放到HDFS中。
序列化就是把内存中的对象的状态信息转换成字节序列，以便于存储（持久化）和网络传输
反序列化就是就将收到的字节序列或者是硬盘的持久化数据，转换成内存中的对象。
hadoop序列化特点：1，紧凑；2，对象可重用；3，可拓展性；4，互操作性
hadoop原生的序列化类需要实现一个叫Writeable的接口，类似于serializable接口
实现Writable接口必须实现两个方法：write(DataOutputStream out);readField(DataInputStream in)方法。
反序列化就是就将收到的字节序列或者是硬盘的持久化数据，转换成内存中的对象。
hadoop序列化特点：1，紧凑；2，对象可重用；3，可拓展性；4，互操作性
hadoop原生的序列化类需要实现一个叫Writeable的接口，类似于serializable接口
实现Writable接口必须实现两个方法：write(DataOutputStream out);readField(DataInputStream in)方法。
combiner，本地reduce，减少传输到reducer的数据量，可用于过滤数据
zookeeper--提供通用分布式锁机制，用以hadoop分布式协调服务，实现数据同步，典型应用场景：统一命名服务，配置管理，集群管理
YARN：ResourceManager、NodeManager、ApplicationMaster和Container
Resource Manager：RM是一个全局的资源管理器，负责整个系统的资源管理和分配。由两个组件构成：调度器和应用程序管理器
YARN工作步骤：
步骤1 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
步骤2 ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
步骤3 ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，
直到运行结束，即重复步骤4~7。
步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
步骤5 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。
步骤6 NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。
步骤8 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
Resource Manager：RM是一个全局的资源管理器，负责整个系统的资源管理和分配。由两个组件构成：调度器和应用程序管理器
YARN工作步骤：
步骤1 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
步骤2 ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
步骤3 ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，
直到运行结束，即重复步骤4~7。
步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
步骤5 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。
步骤6 NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。
步骤8 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
sqoop:Hadoop和关系数据库中传递数据
Pig:操作hadoop的轻量级脚本语言--先使用不多，一种数据流语言，用来快速轻松的处理巨大的数据。
可以非常方便的处理HDFS和HBase的数据，和Hive一样,Pig可以非常高效的处理其需要做的，通过直接操作Pig查询可以节省大量的劳动和时间。
当你想在你的数据上做一些转换，并且不想编写MapReduce jobs就可以用Pig.
可以非常方便的处理HDFS和HBase的数据，和Hive一样,Pig可以非常高效的处理其需要做的，通过直接操作Pig查询可以节省大量的劳动和时间。
当你想在你的数据上做一些转换，并且不想编写MapReduce jobs就可以用Pig.
Hive，熟悉SQL的朋友可以使用Hive开离线的进行数据处理与分析工作。
注意Hive现在适合在离线下进行数据的操作，就是说不适合在挂在真实的生产环境中进行实时的在线查询或操作，因为一个字“慢”。相反，
起源于FaceBook,Hive在Hadoop中扮演数据仓库的角色。建立在Hadoop集群的最顶层，对存储在Hadoop群上的数据提供类SQL的接口进行操作。
你可以用 HiveQL进行select,join,等等操作。
如果你有数据仓库的需求并且你擅长写SQL并且不想写MapReduce jobs就可以用Hive代替。
Hive的执行入口是Driver，执行的SQL语句首先提交到Drive驱动，然后调用compiler解释驱动，最终解释成MapReduce任务去执行。
注意Hive现在适合在离线下进行数据的操作，就是说不适合在挂在真实的生产环境中进行实时的在线查询或操作，因为一个字“慢”。相反，
起源于FaceBook,Hive在Hadoop中扮演数据仓库的角色。建立在Hadoop集群的最顶层，对存储在Hadoop群上的数据提供类SQL的接口进行操作。
你可以用 HiveQL进行select,join,等等操作。
如果你有数据仓库的需求并且你擅长写SQL并且不想写MapReduce jobs就可以用Hive代替。
Hive的执行入口是Driver，执行的SQL语句首先提交到Drive驱动，然后调用compiler解释驱动，最终解释成MapReduce任务去执行。
HBase
HBase作为面向列的数据库运行在HDFS之上，HDFS缺乏随即读写操作，HBase正是为此而出现。HBase以Google BigTable为蓝本，以键值对的形式存储。
项目的目标就是快速在主机内数十亿行数据中定位所需的数据并访问它。
HBase是一个数据库，一个NoSql的数据库，像其他数据库一样提供随即读写功能，Hadoop不能满足实时需要，HBase正可以满足。如果你需要实时访问一些数据，就把它存入HBase。
你可以用Hadoop作为静态数据仓库，HBase作为数据存储，放那些进行一些操作会改变的数据。
HBase作为面向列的数据库运行在HDFS之上，HDFS缺乏随即读写操作，HBase正是为此而出现。HBase以Google BigTable为蓝本，以键值对的形式存储。
项目的目标就是快速在主机内数十亿行数据中定位所需的数据并访问它。
HBase是一个数据库，一个NoSql的数据库，像其他数据库一样提供随即读写功能，Hadoop不能满足实时需要，HBase正可以满足。如果你需要实时访问一些数据，就把它存入HBase。
你可以用Hadoop作为静态数据仓库，HBase作为数据存储，放那些进行一些操作会改变的数据。
Pig VS Hive
Hive更适合于数据仓库的任务，Hive主要用于静态的结构以及需要经常分析的工作。Hive与SQL相似促使 其成为Hadoop与其他BI工具结合的理想交集。
Pig赋予开发人员在大数据集领域更多的灵活性，并允许开发简洁的脚本用于转换数据流以便嵌入到较大的 应用程序。
Pig相比Hive相对轻量，它主要的优势是相比于直接使用Hadoop Java APIs可大幅削减代码量。正因为如此，Pig仍然是吸引大量的软件开发人员。
Hive和Pig都可以与HBase组合使用，Hive和Pig还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单
Hive VS HBase
Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
HIVE------构建在HDFS上的分布式列存储系统，将数据按照表、行和列进行存储
Hbase表的特点
大：一个表可以有数十亿行，上百万列；
无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
面向列：面向列（族）的存储和权限控制，列（族）独立检索；
稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
数据类型单一：Hbase中的数据都是字符串，没有类型。
基本概念：
RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。
Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列
Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加
Version Number：类型为Long，默认值是系统时间戳，可由用户自定义
Value(Cell)：Byte array
Hbase物理模型
每个column family存储在HDFS上的一个单独文件中，空值不会被保存。
Key 和 Version number在每个 column family中均有一份；
HBase 为每个值维护了多级索引，即：<key, column family, column name, timestamp>
物理存储:
1、Table中所有行都按照row key的字典序排列；
2、Table在行的方向上分割为多个Region；
3、Region按大小分割的，每个表开始只有一个region，随着数据增多，region不断增大，当增大到一个阀值的时候，
region就会等分会两个新的region，之后会有越来越多的region；
4、Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
5、Region虽然是分布式存储的最小单元，但并不是存储的最小单元。
Region由一个或者多个Store组成，每个store保存一个columns family；
每个Strore又由一个memStore和0至多个StoreFile组成，StoreFile包含HFile；
memStore存储在内存中，StoreFile存储在HDFS上。
Hbase基本组件说明：
Client
包含访问HBase的接口，并维护cache来加快对HBase的访问，比如region的位置信息
Master
为Region server分配region
负责Region server的负载均衡
发现失效的Region server并重新分配其上的region
管理用户对table的增删改查操作
Region Server
Regionserver维护region，处理对这些region的IO请求
Regionserver负责切分在运行过程中变得过大的region
Zookeeper作用
通过选举，保证任何时候，集群中只有一个master，Master与RegionServers 启动时会向ZooKeeper注册
存贮所有Region的寻址入口
实时监控Region server的上线和下线信息。并实时通知给Master
存储HBase的schema和table元数据
默认情况下，HBase 管理ZooKeeper 实例，比如， 启动或者停止ZooKeeper
Zookeeper的引入使得Master不再是单点故障
寻找RegionServer
ZooKeeper--> -ROOT-(单Region)--> .META.--> 用户表
-ROOT-
表包含.META.表所在的region列表，该表只会有一个Region；
Zookeeper中记录了-ROOT-表的location
.META.
表包含所有的用户空间region列表，以及RegionServer的服务器地址。
Hbase表的特点
大：一个表可以有数十亿行，上百万列；
无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
面向列：面向列（族）的存储和权限控制，列（族）独立检索；
稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
数据类型单一：Hbase中的数据都是字符串，没有类型。
基本概念：
RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。
Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列
Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加
Version Number：类型为Long，默认值是系统时间戳，可由用户自定义
Value(Cell)：Byte array
Hbase物理模型
每个column family存储在HDFS上的一个单独文件中，空值不会被保存。
Key 和 Version number在每个 column family中均有一份；
HBase 为每个值维护了多级索引，即：<key, column family, column name, timestamp>
物理存储:
1、Table中所有行都按照row key的字典序排列；
2、Table在行的方向上分割为多个Region；
3、Region按大小分割的，每个表开始只有一个region，随着数据增多，region不断增大，当增大到一个阀值的时候，
region就会等分会两个新的region，之后会有越来越多的region；
4、Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
5、Region虽然是分布式存储的最小单元，但并不是存储的最小单元。
Region由一个或者多个Store组成，每个store保存一个columns family；
每个Strore又由一个memStore和0至多个StoreFile组成，StoreFile包含HFile；
memStore存储在内存中，StoreFile存储在HDFS上。
Hbase基本组件说明：
Client
包含访问HBase的接口，并维护cache来加快对HBase的访问，比如region的位置信息
Master
为Region server分配region
负责Region server的负载均衡
发现失效的Region server并重新分配其上的region
管理用户对table的增删改查操作
Region Server
Regionserver维护region，处理对这些region的IO请求
Regionserver负责切分在运行过程中变得过大的region
Zookeeper作用
通过选举，保证任何时候，集群中只有一个master，Master与RegionServers 启动时会向ZooKeeper注册
存贮所有Region的寻址入口
实时监控Region server的上线和下线信息。并实时通知给Master
存储HBase的schema和table元数据
默认情况下，HBase 管理ZooKeeper 实例，比如， 启动或者停止ZooKeeper
Zookeeper的引入使得Master不再是单点故障
寻找RegionServer
ZooKeeper--> -ROOT-(单Region)--> .META.--> 用户表
-ROOT-
表包含.META.表所在的region列表，该表只会有一个Region；
Zookeeper中记录了-ROOT-表的location
.META.
表包含所有的用户空间region列表，以及RegionServer的服务器地址。
Flume--完整的数据收集工具,把数据从数据源收集过来，再送到目的地。
为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。
Flume是Cloudera提供的一个高可用的、高可靠的开源分布式海量日志收集系统，日志数据可以经过Flume流向需要存储终端目的地。
这里的日志是一个统称，泛指文件、操作记录等许多数据。
flume的核心是agent。agent是一个java进程，运行在日志收集端，通过agent接收日志，然后暂存起来，再发送到目的地。
三大核心组件:
①Source：专用于收集日志，可以处理各种类型各种格式的日志数据，包括avro、thrift、、spooling directory、netcat、http、legacy、自定义等。
②Channel：专用于临时存储数据，可以存放在memory、jdbc、file、数据库、自定义等。其存储的数据只有在sink发送成功之后才会被删除。
③Sink：专用于把数据发送到目的地点，目的地包括hdfs、logger、avro、thrift、ipc、file、null、hbase、solr、自定义等。
为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。
Flume是Cloudera提供的一个高可用的、高可靠的开源分布式海量日志收集系统，日志数据可以经过Flume流向需要存储终端目的地。
这里的日志是一个统称，泛指文件、操作记录等许多数据。
flume的核心是agent。agent是一个java进程，运行在日志收集端，通过agent接收日志，然后暂存起来，再发送到目的地。
三大核心组件:
①Source：专用于收集日志，可以处理各种类型各种格式的日志数据，包括avro、thrift、、spooling directory、netcat、http、legacy、自定义等。
②Channel：专用于临时存储数据，可以存放在memory、jdbc、file、数据库、自定义等。其存储的数据只有在sink发送成功之后才会被删除。
③Sink：专用于把数据发送到目的地点，目的地包括hdfs、logger、avro、thrift、ipc、file、null、hbase、solr、自定义等。