第12章 HBase原理与架构.pptx

第三篇非关系数据库HBaseHadoop技术原理与案例教程HadoopTechnicalPrinciplesPractices主编：韩玉民郭丽副主编：王尧张文宁张炎峰缑西梅

第12章Hbase原理与架构第三篇非关系数据库HBase

学习目标（1）掌握列数据库原理。（2）掌握HBase的架构原理。

12.1HBase数据格式HBase是典型的NoSQL数据库，NoSQL数据库一般分为文档数据库和列数据库两种，HBase属于列数据库。那么，为什么HBase要实现为列数据库？

Mysql在大数据时代出现的问题显然，在所有数据的保存方式中，纯文本文件的方式是最简答的。我们的所有问题从我们拿到了一份记录学生名单的文本文件开始：

Mysql在大数据时代出现的问题在学生工作中，我们常常会遇到一些统计上的任务，比如计算学生男生多还是女生多，或者计算籍贯一样的学生是否都在一个宿舍等等。为了便于做这些事，常见的做法是把数据保存在excel中进行数据分析。但对于工程师来说，显然我们需要更强大的工具，因此我们可以将这些数据保存进Mysql这一关系型数据库中，并通过SQL语句或编程语言的API进行数据分析。

Mysql在大数据时代出现的问题加载完毕后可以把这些数据打印一下：这个表的结构如图所示：

Mysql在大数据时代出现的问题Mysql是典型的行式存储数据库，这样的数据库有个特点，即查询某个特定值——如王五同学的生日——会需要一行一行扫描整个表的数据，直到找到姓名是王五的这一行，显然这样很慢。那我们不能直接定位这一行数据吗？或者说，如果一行长度是l，你用n*l作为偏移量不就可以了？这里大家忽略了一个问题：文件中真的存在行吗？典型的如Mysql在硬盘中实际的保存方式可能是下图这样的：

Mysql在大数据时代出现的问题小数据量的时候，全表扫描还好，如果数据量非常大的话呢？在大数据场景下，经常遇到数据有缺失的情况，我们考虑一个有1亿用户的购物网站，假如网站上一共有3000W种商品，如果我们需要存储用户的购买行为供后续分析，应该怎么存？

Mysql在大数据时代出现的问题显然，用户在网站上购买的商品总是远远小于网站的总商品数量，因此上面的用户-商品购买矩阵是极其稀疏的。另一个问题是这个矩阵行很大，列也很大，以行或列的方式建Mysql的表显然不合适。不妨将其展开成两列，第一列存用户名，第二列以字符串组合的方式存商品名，这就成了用户的购买表，如图：

Mysql在大数据时代出现的问题那我们直接把用户购买表保存到Mysql是不是就万事大吉了？这样做有三个问题：查询不便：如果要查询哪些用户之前购买了product1，以前可以对product1建索引，现在只能全表进行文字匹配存储不便：使用varchar还是char？无SQL性：因查询不便导致的问题，对于折中存储的稀疏数据，无法适应SQL语句的查询

思路1：不再要求数据列之间有位置关系变为：姓名：{1：张三，2：李四}性别：{1：男，2：男}生日：{1：2003-04-06，2：2003-10-11}籍贯：{1：开封，2：安阳}宿舍：{1：1#101，2：1#101}1张三男2000/1/1开封1#1012李四男2000/1/1安阳1#1013王五男2000/1/1洛阳1#1024赵六男2000/1/1三门峡1#1025孙七女2000/1/1商丘2#1016周八女2000/1/1周口2#1017吴九女2000/1/1南阳2#1028郑十女2000/1/1驻马店2#103

思路2：将复杂性内敛到一行，另外处理行复杂性变为：1张三男2000/1/1开封1#1012李四男2000/1/1安阳1#1013王五男2000/1/1洛阳1#1024赵六男2000/1/1三门峡1#1025孙七女2000/1/1商丘2#1016周八女2000/1/1周口2#1017吴九女2000/1/1南阳2#1028郑十女2000/1/1驻马店2#103/*1*/{_id:1,姓名:张三,性别:男,生日:2003-04-06,籍贯:开封,宿舍:1#101}/*2*/{_id:2,姓名:李四,性别:男,生日:2003-10-11,籍贯:安阳,宿舍:1#101}

两种思路对比对稀疏矩阵友好型：第一种更好数据复杂查询的理论性能：第一种更好数据修改方便性：第二种更好思路一：列数据库思路二：文件数据库（键值数据库、图数据库）1-姓名：张三，性别：男，生日：2020/1/1，籍贯：开封，宿舍：1#101{_id:1,姓名:张三,性别:男