(zookeeper+hbase+hive原理总结
面试可能会问到的原理总结
持续更新中
zookeeper：
配置管理
集群管理
命名空间
zookeeper是一个分布式锁服务
leader：老大，管理小弟follower，然后负责来自客户端的数据读写请求，
先写到内存，然后持久化到本地，通知follower及时同步数据。
follower：负责同步数据，还会参与选举等。
更多干货分享，加群大数据学习交流群 805127855 广播协议（数据强一致性）：leader广播所有的follower同步数据
数据模型：
是一个树形结构，跟linux文件系统类似的，每一个节点都有一个绝对路径来唯一标识并且不能相同，相同就是覆盖数据
zookeeper的文件系统是用来做分布式服务协调的，它每一个节点只能携带少量数据，每一个文件既是目录又是文件
znode数据节点有四种
普通znode:/name /name，相同文件下面有相同的文件，就会覆盖数据
普通序列化znode:创建相同的文件名字，都会给一个唯一标识进行追加进行分别，/name 00001 /name 00002
普通的数据节点就是永久性的，一旦创建的话它就永久的存在，除非你手动删除它
临时znode :一旦你创建session会话消失的话，那么这个临时的数据节点就消失了
watcher:事件（节点可以注册事件）删除节点,创建节点，更新节点，创建子节点等（事件具有一次性）
事件的ACID:
原子性
一致性
隔离性
持久性
Hbase:
HBase运行在HDFS之上，Hbase的数据是存在HDFS上，还有一些少量的数据存在内存上。
并且可以容错的存储海量稀疏数据，允许存在大量字段为空的，不能保证你的列就一定有数据。
特性：高可靠，高并发读写，面向列，可伸缩，易构建。
Hbase是一个随机写入和访问的数据库
面向列与面向行存储的区别：
传统数据库是采用面向行存储，传统数据库能够对数据保证完整性，但是却在查询的过程中会把一些冗余的数据查询出来，即使你指定了查询表中的字段，但是它在底层还是会把所有的表进行读取然后从中找出相应你指定的表的字段。
而Hbase是采用面向列存储，它在查询等操作过程中，内部不会读取冗余的数据，但是在写入的过程中效率比较差，因为它无法保证你的数据的一个完整性，所以Hbase适合对那些对数据完整性要求不高的大数据领域。
Hbase是rowkey作为唯一的主键，它是按照字节顺序的存储的，这样的话可以方便快速的进行查询。
更多干货分享，加群大数据学习交流群 805127855
Column Family列族：是基本的访问控制单元
Hbase对表的增加，修改等操作都不是在原来的表的基础之上进行修改的，而是HBase内部会把原来的表进行一个复制，然后从复制过来的表进行一个修改，增加等操作，而旧的表不会被删除，旧的表会以一个时间戳的形式保留在HBase表中，而在复制过来进行修改等操作的表会重新给它一个时间戳，这样的话就可以维护多个版本。
Hbase检索快速数据维护合理的三维有序特点：
三维有序就是三个纬度，第一个纬度就是rowkey，第二个纬度就是列，这个列包含列族和子列，第三个纬度就是时间戳。
Region就是Hbase数据分布的最小单位
Region只属于一个regionserver
Hbase的数据模型：
Hbase的表是由一个或多个region组成，region就是比如一个区域一个分区，并且rowkey是按照顺序排序的，而每一个region区域都是全局的排序，而且每一个region区域的大小都是不一样的，你的数据的不断插入，使得每一个region区域就变得越来越大，那么此时这个变得越来越大的region区域，数据超了Hbase内部默认的10G，那么就会划分为两个区域，当然这个默认的10G是可以修改的，并且在插入数据的时候，比如表中的rowkey有66，67，69，70，75这几个，那么你要新插入68这个数据rowkey那么就必须要插在表中的rowkey67和69中间，使其能够有一个顺序的排序
Hbase的宕机处理原理：
一个regionserver节点死掉了，该节点里面的数据就会被其他的regionserver节点进行处理，并且每一个regionserver里面的数据都有三个备份，都存在不同的节点上，当一个节点出现问题了，那么其他节点里面还保存着挂掉的这个节点的数据的备份。
更多干货分享，加群大数据学习交流群 805127855
这58行这个记录，如果对于这种又有读又有写的这种情况我们就必须要有一个锁对吧？必须有一个顺序，在Hbase里面你想对某一行记录要去做修改的时候尽管你只修改里面其中一个字段，其他字段不修改，把整行记录加锁明白这意思把？所以Hbase它是按行锁定的，那么把这58行加锁了之后也就说明由我当时获得锁的这个进程是拥有绝对的主权的对吧？尽管我当时在读数据，我只读这个字段但是这三个字段我不会去碰，那么这个时候有其他进程让你写那也是不允许的。
所以它这个锁的粒度也不是特别的细，行锁列它的粒度就比较粗的，这个大家注意一下，就是对于一个数据表来说这个region是什么意思呢？这个region相当于是一个逻辑概念，然后这个region就是把这个表里面分了很多的区域，然后每一个区域代表一个region，这是一个逻辑概念。
每一个region会分配到不同的server上去，每一个server都会管理着一个或者多个region。
Hbase的数据看上去是一整张，而从它物理的角度方向来看，Hbase的数据是分布在不同的机器上的。
hive：
hive读时模式：读的时候才会去检查，写的时候不会去检查，所以hive写的时候是相当快的
hive用的是hdfs关系型数据库，然后hive的计算模型是mapreduce,关系型数据库是自己的
hive的数据是存在HDFS上的。
hive有四种数据模型：Table（内部表）,Extemal Table（外部表）,Partition,Bucket
hive的优化有两种，常见分区和分库，分库就是把一张表拆分成多个表，来优化查询。也是对表与表之间做一个join的优化
hive创建表尽量创建外部表。
如果外部表数据被删除了，需要数据重新修复，那么就采取把这个表重新建一下，数据就自动恢复
数据类型有：原生类型和复合类型，原生类型就是int，float,double等，复合类型就是数组，集合，结构体和联合体等操
操作hive的更多优化：
union all的缺点就是合并不去重的操作，新来的数据直接在后面追加
union就是一个合并去重的操作，把相应相同的数据去掉。
关于mapreduce数据倾斜：
在写mapreduce的时候，对于key进行聚合，那么此时可能会导致相同的key都放到同一个桶上，那肯定会存在有的桶多，有的桶少，导致key分布的不均匀。
解决方案：
那么其优化就是我们可以对这个key进行一个修改，相当于把以key为聚合的那些记录比较多的看看能不能把它拆开，
就是做一个对key进行一个改写来解决问题。
hive的数据倾斜：
配置参数：set hive,groupby.skewindata=true 可以解决数据倾斜的问题，使其能够负载均衡！！
关于hive写数据的优化：（所以最好是每次写join的时候，小表放左边，大表放右边）
尽量在跟表与表之间做join的时候，判断出哪个表为小表，如果有小表就最好放在join的前面，使其该小表可以放入内存
因为hive在写sql语句中，默认会把左边的数据放入内存，这样将大大提高了对hive内部的优化
但是上面这种优化也不是很好，如果把大表放在join的前面，那么优化的机制就不一定能派的上用场了。
但是我还想对hive进行一个内部优化，就还可以采用以下的方案：
可以在hivesql中用*+MAPJOIN(小表名)来指定谁是小表，那么即使这个大表在join的前面，
hive内部机制也会把用*+MAPJOIN(小表名)指定好的小表名放入内存中) 更多干货分享，加群大数据学习交流群 805127855