HBASE 1.0

前身：BigTable

网页搜索：

google分布式存储系统BigTable依赖GFS

Hbase（bigtable的开源实现）: 高可靠、高性能、面向列、可伸缩

存储结构化和半结构化的数据

优点：

水平可扩展性特别好：

依赖：

文件存储系统：HDFS

海量数据处理：MapReduce

协同管理服务：Zookeeper
满足了：大数据量的实时计算
数据类型：

    RDBMS：关系数据模型、多种数据类型

    Hbase：

数据 *** 作：

存储模式：

索引：

数据维护：

可伸缩性：

        纵向扩展：

        水平扩展：

Hbase的访问接口：

            JAVA API

            shell

            thrift Gateway

            restful Gateway

            SQL接口：pig编写类sql  hive用hivesql访问Hbase

Hbase的数据类型：

        列限定符

        每个值都是未解释的bytes

        一个行可以有一个行键和多列

        表由列族组成
Hbase数据模型：

    列族支持动态扩展、保留旧版本（HDFS只能追加数据）

基础元素：

    行键 ： rowkey

    列族

    列限定符

    单元格 （时间戳概念、对应数据版本）

坐标概念：

    四维定位：行键、列族、列限定符、时间戳

稀疏表

HBASE：面向列的存储：高数据压缩率、分析便捷

RDBMS ：面向行存储，事务性 *** 作（记录完整）、不便于分析（需要全表扫描）
43 HBASE 的实现原理

431 库函数 、master服务器、region服务器

Master服务器：

分区信息进行维护和管理

维护region服务器列表

确认当前工作的region服务器

负责对region进行分配和负载平衡

对表的增删改查

region服务器：

客户端不依赖于Master获取位置信息

用户数据的存储和管理

Region服务器--10-1000个region -----Store是一个列族----每个列族就是一个Hfile----所有region公用1个Hlog

写数据流程：Region服务器---写缓存Memstore---写日志（Hlog）

读数据流程：Region服务器-读缓存Memstore（最新数据）----StoreFile

缓存刷新：周期性将缓存内容刷写到Storefile 清空缓存---Hlog写入标记

每次刷写会生成新的StoreFile 每个Store包含多个StoreFile

每个Region服务器都有一个自己的Hlog，将启动检查确认缓存刷新是否有新的内容需要刷写，发现则刷写新的storefile,完成后删除Hlog，开始对外提供服务

Storefile的合并,storefile 的数量达到阈值后，会进行合并。当Storefile超过大小阈值则会触发Region的分裂
44 Hlog的工作原理

Zookeeper负责监听region服务器，由master处理故障，通过故障服务器的Hlog恢复，按region切分Hlog，将region和对应的Hlog分配到新的region服务器上
一个HBASE表会被划分成多个Region（1G-2G 取决于服务器性能）

同一个region不会被拆分到不同服务器上

Region的寻找：

Meta表：regionID 服务器ID 存储元数据

Root表：只有一个region

三级寻址：

zookeeper文件---root表-多个meta表--多个用户数据表

客户端会有Hbase三层寻址的缓存，调用访问Hbase的接口，缓存失效后，再次寻址

zookeeper决定master服务器，确保只有一个master

45 Hbase的应用方案

性能优化：

1）时间靠近存放----将时间戳引入行键，使用Longmax-时间戳进行排序

2）提升读写性能,创建表时设置HcloumnDescriptorsetMemory=true，会将表放入内存的缓存中

3）节省存储·空间----设置最大版本数、保存最新版的数据，将最大版本参数设置为1

4）timetolive参数，会将过期数据自动清空

检测Hbase性能：

Maste-status（web浏览器查询）

ganglia

OpenTSDB

Armbari

sql 查询HBASE

1）hive整合hbase

2）Phoenix

Hbase 二级索引 (辅助索引）

默认只支持对rowkey进行索引

Hbase行访问：

1）单行键访问

2）确定起点和终点访问区间数据

3）全表扫描
二级索引样例：

    Hindex    Hbase+redis  Solr+ Hbase

二级索引的机制：

        Hbase Coprocessor 

        endpoint  ---存储过程

        observer----触发器

        通过Observer监测数据插入动作，同步写入索引表，完成对表和列的索引

      Hbase 主表 索引表

46 HBASE的shell命令

三种部署模式：单机 伪分布式  分布式

HDFS

创建表

create table， F1， F2， F3

list table

每次只能为1行的1列添加数据

put  table R1，R1:C1 ，“1,2,3”

scan  table  R1，{column='R1:C1'}

get  table

删除表：

disable table +drop table

47 JAVA API +HBASE

hbase的核心数据结构如下：

Hadoop是大数据开发的重要框架，其核心是HDFS和MapReduce，HDFS为海量的数据提供了存储，MapReduce为海量的数据提供了计算，因此，需要重点掌握，除此之外，还需要掌握Hadoop集群、Hadoop集群管理、YARN以及Hadoop高级管理等相关技术与 *** 作!

其他数据结构：

1、Java编程技术

Java编程技术是大数据学习的基础，Java是一种强类型语言，拥有极高的跨平台能力，可以编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等，是大数据工程师最喜欢的编程工具，因此，想学好大数据，掌握Java基础是必不可少的!

2、Linux命令

对于大数据开发通常是在Linux环境下进行的，相比Linux *** 作系统，Windows *** 作系统是封闭的 *** 作系统，开源的大数据软件很受限制，因此，想从事大数据开发相关工作，还需掌握Linux基础 *** 作命令。

其实，你弄错了hadoop的真正意图。首先，hadoop不适合于开发WEB程序。hadoop的优势在于大规模的分布式数据处理。负责数据的分析并采用分布式数据库(hbase)来存储。但是，hadoop有个特点是，所有的数据处理作业都是批处理的，也就是说hadoop在实时性上是不占优势的。对于WEB应用来说，你也许可以做的是，将系统的数据处理部分分离出来交给hadoop去做。关于hadoop的数据处理有一个专门的工具:hive。hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为 MapReduce任务进行运行。 其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。 希望对你有帮助

在说HBase之前，我想再唠叨几句。做互联网应用的哥们儿应该都清楚，互联网应用这东西，你没办法预测你的系统什么时候会被多少人访问，你面临的用户到底有多少，说不定今天你的用户还少，明天系统用户就变多了，结果您的系统应付不过来了了，不干了，这岂不是咱哥几个的悲哀，说时髦点就叫“杯具啊”。
其实说白了，这些就是事先没有认清楚互联网应用什么才是最重要的。从系统架构的角度来说，互联网应用更加看重系统性能以及伸缩性，而传统企业级应用都是比较看重数据完整性和数据安全性。那么我们就来说说互联网应用伸缩性这事儿对于伸缩性这事儿，哥们儿我也写了几篇博文，想看的兄弟可以参考我以前的博文，对于web server,app server的伸缩性，我在这里先不说了，因为这部分的伸缩性相对来说比较容易一点，我主要来回顾一些一个慢慢变大的互联网应用如何应对数据库这一层的伸缩。
首先刚开始，人不多，压力也不大,搞一台数据库服务器就搞定了，此时所有的东东都塞进一个Server里，包括web server,app server,db server,但是随着人越来越多，系统压力越来越多，这个时候可能你把web server,app server和db server分离了，好歹这样可以应付一阵子，但是随着用户量的不断增加，你会发现，数据库这哥们不行了，速度老慢了，有时候还会宕掉，所以这个时候，你得给数据库这哥们找几个伴，这个时候Master-Salve就出现了，这个时候有一个Master Server专门负责接收写 *** 作，另外的几个Salve Server专门进行读取，这样Master这哥们终于不抱怨了，总算读写分离了，压力总算轻点了,这个时候其实主要是对读取 *** 作进行了水平扩张，通过增加多个Salve来克服查询时CPU瓶颈。一般这样下来，你的系统可以应付一定的压力，但是随着用户数量的增多，压力的不断增加，你会发现Master server这哥们的写压力还是变的太大，没办法，这个时候怎么办呢？你就得切分啊，俗话说“只有切分了，才会有伸缩性嘛”，所以啊，这个时候只能分库了，这也是我们常说的数据库“垂直切分”，比如将一些不关联的数据存放到不同的库中，分开部署，这样终于可以带走一部分的读取和写入压力了，Master又可以轻松一点了，但是随着数据的不断增多，你的数据库表中的数据又变的非常的大，这样查询效率非常低，这个时候就需要进行“水平分区”了，比如通过将User表中的数据按照10W来划分，这样每张表不会超过10W了。
综上所述，一般一个流行的web站点都会经历一个从单台DB，到主从复制，到垂直分区再到水平分区的痛苦的过程。其实数据库切分这事儿，看起来原理貌似很简单，如果真正做起来，我想凡是sharding过数据库的哥们儿都深受其苦啊。对于数据库伸缩的文章，哥们儿可以看看后面的参考资料介绍。
好了，从上面的那一堆废话中，我们也发现数据库存储水平扩张scale out是多么痛苦的一件事情，不过幸好技术在进步，业界的其它弟兄也在努力，09年这一年出现了非常多的NoSQL数据库，更准确的应该说是No relation数据库，这些数据库多数都会对非结构化的数据提供透明的水平扩张能力，大大减轻了哥们儿设计时候的压力。下面我就拿Hbase这分布式列存储系统来说说。
一 Hbase是个啥东东？
在说Hase是个啥家伙之前，首先我们来看看两个概念，面向行存储和面向列存储。面向行存储，我相信大伙儿应该都清楚，我们熟悉的RDBMS就是此种类型的，面向行存储的数据库主要适合于事务性要求严格场合，或者说面向行存储的存储系统适合OLTP，但是根据CAP理论，传统的RDBMS，为了实现强一致性，通过严格的ACID事务来进行同步，这就造成了系统的可用性和伸缩性方面大大折扣，而目前的很多NoSQL产品，包括Hbase，它们都是一种最终一致性的系统，它们为了高的可用性牺牲了一部分的一致性。好像，我上面说了面向列存储，那么到底什么是面向列存储呢？Hbase,Casandra,Bigtable都属于面向列存储的分布式存储系统。看到这里，如果您不明白Hbase是个啥东东，不要紧，我再总结一下下：
Hbase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写 *** 作，同时Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。
二 Hbase数据模型
HBase,Cassandra的数据模型非常类似，他们的思想都是来源于Google的Bigtable，因此这三者的数据模型非常类似，唯一不同的就是Cassandra具有Super cloumn family的概念，而Hbase目前我没发现。好了，废话少说，我们来看看Hbase的数据模型到底是个啥东东。
在Hbase里面有以下两个主要的概念，Row key,Column Family，我们首先来看看Column family,Column family中文又名“列族”，Column family是在系统启动之前预先定义好的，每一个Column Family都可以根据“限定符”有多个column下面我们来举个例子就会非常的清晰了。
假如系统中有一个User表，如果按照传统的RDBMS的话，User表中的列是固定的，比如schema 定义了name,age,sex等属性，User的属性是不能动态增加的。但是如果采用列存储系统，比如Hbase，那么我们可以定义User表，然后定义info 列族，User的数据可以分为：info:name = zhangsan,info:age=30,info:sex=male等，如果后来你又想增加另外的属性，这样很方便只需要info:newProperty就可以了。
也许前面的这个例子还不够清晰，我们再举个例子来解释一下，熟悉SNS的朋友，应该都知道有好友Feed，一般设计Feed，我们都是按照“某人在某时做了标题为某某的事情”，但是同时一般我们也会预留一下关键字，比如有时候feed也许需要url，feed需要image属性等，这样来说，feed本身的属性是不确定的，因此如果采用传统的关系数据库将非常麻烦，况且关系数据库会造成一些为null的单元浪费，而列存储就不会出现这个问题，在Hbase里，如果每一个column 单元没有值，那么是占用空间的。下面我们通过两张图来形象的表示这种关系：
上图是传统的RDBMS设计的Feed表，我们可以看出feed有多少列是固定的，不能增加，并且为null的列浪费了空间。但是我们再看看下图，下图为Hbase，Cassandra,Bigtable的数据模型图，从下图可以看出，Feed表的列可以动态的增加，并且为空的列是不存储的，这就大大节约了空间，关键是Feed这东西随着系统的运行，各种各样的Feed会出现，我们事先没办法预测有多少种Feed，那么我们也就没有办法确定Feed表有多少列，因此Hbase,Cassandra,Bigtable的基于列存储的数据模型就非常适合此场景。说到这里，采用Hbase的这种方式，还有一个非常重要的好处就是Feed会自动切分，当Feed表中的数据超过某一个阀值以后，Hbase会自动为我们切分数据，这样的话，查询就具有了伸缩性，而再加上Hbase的弱事务性的特性，对Hbase的写入 *** 作也将变得非常快。
上面说了Column family，那么我之前说的Row key是啥东东，其实你可以理解row key为RDBMS中的某一个行的主键，但是因为Hbase不支持条件查询以及Order by等查询，因此Row key的设计就要根据你系统的查询需求来设计了额。我还拿刚才那个Feed的列子来说，我们一般是查询某个人最新的一些Feed，因此我们Feed的Row key可以有以下三个部分构成<userId><timestamp><feedId>，这样以来当我们要查询某个人的最进的Feed就可以指定Start Rowkey为<userId><0><0>，End Rowkey为<userId><LongMAX_VALUE><LongMAX_VALUE>来查询了，同时因为Hbase中的记录是按照rowkey来排序的，这样就使得查询变得非常快。
三 Hbase的优缺点
1 列的可以动态增加，并且列为空就不存储数据,节省存储空间
2 Hbase自动切分数据，使得数据存储自动具有水平scalability
3 Hbase可以提供高并发读写 *** 作的支持
Hbase的缺点：
1 不能支持条件查询，只支持按照Row key来查询
2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉
四补充
1数据类型，HBase只有简单的字符类型，所有的类型都是交由用户自己处理，它只保存字符串。而关系数据库有丰富的类型和存储方式。
2数据 *** 作：HBase只有很简单的插入、查询、删除、清空等 *** 作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接 *** 作。
3存储模式：HBase是基于列存储的，每个列族都由几个文件保存，不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的
4数据维护，HBase的更新 *** 作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改
5可伸缩性，Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能

1hbase有那些管理工具，首先hbase有自带的简单的web界面2还有一种HBase图形界面管理工具HBaseXplorer

HBaseXplorer 是一款HBase管理工具,采用JAVA界面方式,查看和管理数据都很发布

HBaseXplorer原名为 hbase-gui-admin ,是由 zpasal 开发的一款HBase管理工具

下载地址:>

开启程序:

Mac OS X 下,直接启动 HBaseXplorerjar

Linux 下,启动 HBaseXplorersh

Win 下,启动 HBaseXplorerbat

启动输入zookeeper地址 , 需要配置好 host

3hbase web管理工具phphbaseadmin

HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。由于hbase自带的 *** 作工具只有hbase
shell，创建表、批量删除表、查看记录等 *** 作很不方便，因此开发了phphbaseadmin工具，使用hbase thrift接口、php
CI框架、bootstrap前端框架开发。

目前实现的功能主要有

浏览表、创建表、批量删除表、查看表metadata、搜索表记录、清空表，其中搜索记录可以根据rowkey
、timestamp、value几个字段查询。

4IBM 的BigInsights

IBM 对 HBase 的改进和扩展

BigInsights 最大限度的提供了统一的，IBM 特有的 HBase
管理功能，包括用户界面以及后台命令行管理模式。这样，用户可以通过简单的界面 *** 作或者后台命令来启停 / 查看 HBase 集群，而不用关心具体的实现细节。

与此同时，IBM 还提供了统一的用户界面和添加、删除节点命令来支持 HBase 集群的可伸缩性。

另外，HBase Master 多结点功能的实现，提供并保证了 HBase 在 BigInsights 中的高可用性。

---