1，HBase的的的的伪分布式配置
- 对zookeeper的配置，这个前面配置过，修改zoo.cfg文件，指定zookeeper的主入口
- 配置的HBase的的：进入/opt/modules/hbase-0.98.6目录下
1.1，修改的CONF目录下的文件hbase-env.sh，指定自己的环境
＃要使用的Java实现。需要的Java 1.6。
导出 JAVA_HOME = /opt/module/apache/jdk1.8.0_151
＃额外的Java类路径元素。可选的。export HBASE_CLASSPATH = / opt / module / apache / jHadoop的2.7.3 / etc / hadoop
不使用的HBase的的自带的ZK，选择自己安装ZK，所以设置为假
＃告诉HBase它是否应该管理它自己的Zookeeper实例。 导出HBASE_MANAGES_ZK = false
1.2，修改的CONF目录下的HBase的-site.xml中中文件
//指定HBase的所有表数据存储的位置，也可以指定为本地，类似于蜂房的数据仓库的位置一样概念 <名称> hbase.rootdir > HDFS：// [主机名称]：8020 / HBase的 //指定的HBase的模式，是否使用分布式集群模式，如果假的英文就是单机模式，无论是伪分布还是完全分布都是分布式 hbase.cluster.distributed < 值>真 //指定动物园管理员的实例化地址，ZK是HBase的访问入口，客户端访问时都要经过ZK // UI访问都会经过ZK <属性> <名称> hbase.zookeeper.quorum <值> [主机名]
1.3，修改regionservers - >类似于hadoop的奴隶节点
改为自己的主机名
1.4，替换jar：替换掉的hadoop和ZK的jar（如果使用CDH版本不需要这一步）
删除以前的罐：hadoop15个，ZK一个（是以hadoop-开头后包含具体的2.2.2的罐包）替换罐子：hadoop14个，ZK一个，HTRACE核一个（罐的的的hadoop的份额中去找）启动HBase的（ZK和hadoop的之上）注意：启动之前一定要先启动ZK和hadoop的 1，启动HBase的： 仓/ hbase-daemon.sh启动主（停止）斌/ hbase- daemon.sh start regionserver（stop）或者bin / start-hbase.sh bin / stop-hbase.sh 1.6，webUI界面主机 名+端口号60010这里可以查看我们的用户建立了那些namesapace，以及我们的相关节点信息
2，在成功配置了HBase的的的单节点（伪分布式）后，对命令进行熟悉的过程中，老是弹出如下警告
SLF4J：类路径包含多个SLF4J绑定.SLF4J ：在[jar：file：/opt/module/apache/hbase-0.98.6-hadoop2/lib/slf4j-log4j12-1.6.4.jar！/ org / slf4j /impl/StaticLoggerBinder.class]中找到绑定 SLF4J：在[JAR：文件：/opt/module/apache/hadoop-2.7.3/share/hadoop/common/lib/slf4j-log4j12-1.7.10.jar！ / org / slf4j / impl / StaticLoggerBinder中找到绑定。类] SLF4J：请参阅http://www.slf4j.org/codes.html#multiple_bindings以获取解释。
这表示我们的LIB目录下有两个罐子相互冲突了，删掉其中一个就OK，解决问题
==> rm /opt/module/apache/hbase-0.98.6-hadoop2/lib/slf4j-log4j12-1.6.4.jar
3，hbase shell的基本操作
| 基本操作 |
sshell命令 |
| 创建表 |
ccreate'table_name'，'column_family'，' column_family1 ' ，' column_family2 ' |
| 删除列簇 |
ALTER 'TABLE_NAME'，{NAME => ' column_family'，METHOD => '删除' } |
| 增加列簇 |
alter table_name'，{NAME =>'column_family'，VERSION => 5}（后面指定的为该列簇的版本数） |
添加记录
|
改变'TABLE_NAME'，'row_key'，'column_family：列名'，'值'
|
查看某个row_key的记录
|
得到'表名'，'row_key'
|
| 删除一条记录 |
删除' table_name '，'row_key'，'column_family：column_name'
|
| 删除表 |
第一步禁用'表名'第二步drop'table_name“ |
| 查看表的所有记录 |
扫描“表格名”后面也可以接具体的列和查看的版本数，不大于实际版本 扫描“table_name”，{COLUMN =>' column_family：column_name '，VERSIOnS=> 2} |
| 查看某个表某列的所有值 |
扫描“表格名”，['column_family：列名：']
|
| 更新记录 |
就是添加数据，对之前的数据进行过覆盖，版本> 1时，就都保存，版本= 1，保存最新的 |
| 查看一个列的多个版本信息 |
get'table_name'，'row_key'，{COLUMN =>' column_family：column_name '，VERSIOnS=> number}
|
| 删除某列的某个版本的值 |
ddelete '表名'， 'row_key'， 'column_family：列名：'，时间戳若最新这里删除的时间戳的数据，则扫描，得到出来就没有该列的值，删除之前的时间戳的值，还会查询出最新的时间戳的值 |
4，一些应该要注意的概念
如图1所示，区域是分布式存储和负载均衡的最小单元（数据的移动只能在区域层面）
2，hbase.meta记录了所有用户表的区域信息，元的区域信息保存在动物园管理员中，hbase.namespqce也一样
3，物理结构的相关的详细理解：后面贴上来
5，预写日志WAL :(将客户端操作的命令都会记录到这个WAL）-用户每次写入memstore同时，也会写一份数据到Hlog文件中，写入hlog时间在memstore之前-写入成功后才会通知客户端该操作成功-每个regionserver只有一个Hlog文件- Hlog文件定期的刷新，删除旧的文件-避免内存中丢失数据，可以在日志文件中恢复
==>其实很多的依赖内存的高可用性框架，都会用到“预写日志”的理念，比如Spark Streaming Redis，因为内存中的数据是极易丢失，而且找不到来的，所以在速度与存储空间之间，很难达到一个平衡，这都是为了数据的安全性，以及框架的高可用
6，HBase的的存储内部机制
-客户端写入 - >存入MemStore，一直到MemStore满（Hlog） - > Flush成一个StoreFile存储在HDFS上-当每次冲洗会生成一个Hfile。
StoreFile，直到增长到一定阈值 - >触发Compact合并操作 - >多个StoreFile合并成一个StoreFile - 当单个StoreFile大小超过一定阈值后，触发
顺序为{minor - major- compact完成}，最开始对HFILE的minor ，再是对storefile的major，最后当storefile经过compact达到一定大小，则对region进行split。
红色字体理解错误了，查了资料发现最开始的的理解才是对的， 留着提个醒，下面为正确的
我们先看看官网上说的
客户端写入 首先写入到Hlog(WAL),写入成功后，在写入到memstore中， 直到达到memstore的阈值，就flush到HDFS上，形成一个Hstorefile,这样会产生很多小的Hstorefile文件，当达到这个数量（3）会自动合并为一个，这就是是minor conpaction 就会对小的文件进行合并为一个大的storefile，这个过程不会删除带有删除标记的数据。
major compaction 一般会设置在集群空闲的时候执行，而在执行一个major之后，一个store只会有一个sotrefile,通常情况下这样可以提供性能。注意：major紧缩将会将store中的数据全部重写，在一个负载很大的系统中，这个操作是很伤的，因为会占用大量的内存来重写这些数据。这个操作会对有删除标记的数据进行删除
当某个Hstorefile的大小达到某个阈值时,这个时候回触发split操作，把当前region->split成2个region，HMASTER分配到相应的HRegionServer上
京公网安备 11010802041100号