hbase

HBase集群的搭建（在《 HBase伪分布式安装 》基础上搭建） 1 集群结构，主节点(hmaster)是hadoop0，从节点(region server)是hadoop1和hadoop2 2 修改hadoop0上的hbase的几个文件 　　(1)修改hbase-env.sh的最后一行export HBASE_MANAGES_ZK=false 　　(2)修改hbase-site.xml文件的hbase.zookeeper.quorum的value值为hadoop0,hadoop1,hadoop2 　　(3)修改regionservers文件(存放的region server的hostname)，内容修改为hadoop1、hadoop2 3 复制hadoop0中的hbase文件夹到hadoop1、hadoop2中 　　　　scp -r /usr/local/hbase hadoop1:/usr/local/ 　　　　scp -r /usr/local/hbase hadoop2:/usr/local/ 　　 复制hadoop0中的/etc/profile到hadoop1、hadoop2中 ， 　　　　scp /etc/profile hadoop1:/etc/ 　　　　scp /etc/profile hadoop2:/etc/ 　　 在hadoop1

下载安装包 我使用的是：hbase-0.99.2-bin.tar.gz 上传到指定目录：个人习惯，我放在了/home/hadoop/apps/ 解压 tar –zxvf hbase-0.99.2-bin.tar.gz 重命名 mv hbase-0.99.2 hbase 修改环境变量 在node1机器上执行下面命令 vim /etc/profile 添加内容： export HBASE_HOME=/home/hadoop/apps/hbase export PATH=$PATH:$HBASE_HOME/bin 使其立即生效： source /etc/profile 同样在其他机器上也执行上述操作。 修改配置文件 cd /home/hadoop/apps/hbase/conf hbase-env.sh主要配置如下几点： # jdk安装目录 export JAVA_HOME=/usr/jdk # hadoop配置文件的位置 export HBASE_CLASSPATH=/home/hadoop/hadoop/conf # 如果使用独立安装的zookeeper这个地方就是false export HBASE_MANAGES_ZK=true hbase-site.xml主要配置如下： <configuration> <property> <name>hbase.master</name>

一：高可用 1）：关闭集群 　　 stop-hbase.sh 2）：在conf目录下创建 backup-masters 文件 　　 touch backup-masters 3）：backup-masters文件中配置高可用 HMaster 节点 　　 echo k200 > backup-masters 4）：将整个 conf 目录 scp 到其他节点 　　 scp -r /soft/hive/conf/ k200:/soft/hive/ 5）：打开页面测试 二：Hadoop 的通用性优化 1）：NameNode 元数据备份使用 SSD 2）：定时备份NameNode 上的元数据 　　 通过定时任务复制元数据目录即可 3）：为 NameNode 指定多个元数据目录 　　 使用 dfs.name.dir 或者 dfs.namenode.name.dir 指定。这样可以提供元数据的冗余和健壮性，以免发生故障。 4）：NameNode的 dir 自恢复 　　 设置 dfs.namenode.name.dir.restore 为 true，允许尝试恢复之前失败的dfs.namenode.name.dir目录，在创建 checkpoint时做此尝试，如果设置了多个磁盘，建议允许。 5）：HDFS保证 RPC 调用会有较多的线程数 　　 hdfs-site.xml: 　　 属性：dfs

一：说明 该安装是在hadoop集群安装后进行，详情可见上一篇博客 虚拟机centos7系统下安装hadoop ha和yarn ha（详细) 。其中涉及五台机器，两台master（机器名：master，master2），三台slave（slave01，slave02，slave03）。以下将在master安装Hmaster，master2安装备用Hmaster，在三台slave安装HRegionServer。 二：下载 （1）从 hbase下载 对应版本hbase，本篇下载的是hbase-0.99.2-bin.tar.gz . 三：安装 （1）将下载的压缩包上传至master主机，使用命令解压 tar -zxvf hbase-0.99.2-bin.tar.gz （2）将hadoop安装目录下/etc/hadoop目录下的hdfs-site.xml和core-site.xml 放到hBase/conf下 （3）修改hBase/conf下的三个文件，hbase-env.sh ， hbase-site.xml和regionservers ①修改hbase-env.sh 去掉以下参数注释，并修改 //自己的jdk路径 export JAVA_HOME=/usr/java/jdk1.8.0_181 //hadoop配置文件的位置 export HBASE_CLASSPATH=/home

复制master节点上的版本内容到所有slaves节点上 注意： 1：版本目录做了软链接，如 ln -s hbase-0.94.6 hbase 2: 要根据实际情况，将/usr/local/修改为hbase所在的目录 #!/bin/bash # copy a new release of HBase from the masternode to all slave nodes # Rsyncs HBase files across all slaves. Must run on master. # Assumes all files are located in /usr/local if [ "$#" != "2" ]; then echo "usage: $(basename $0) <dir-name> <ln-name>" echo " example: $(basename $0) hbase-0.1 hbase" exit 1 fi SRC_PATH="/usr/local/$1/conf/regionservers" for srv in $(cat $SRC_PATH); do echo "Sending command to $srv..."; rsync -vaz --exclude='logs/*' /usr/local/$1 $srv:/usr/local/

一.背景 　　2003年，Google发表了“The Google File System”的论文。这个分布式文件系统简称GFS，它使用商用硬件集群存储海量数据。文件系统将数据在节点之间冗余复制，这样的话，即使一台存储服务器发生故障，也不会影响数据的可用性。它对数据的流式读取也做了优化，可以边处理边读取。 　　不久，Google又发表了"MapReduce:Simplified Data Processing on Large Clusters"的论文。MapReduce是GFS架构的一个补充，因为它能够充分利用GFS集群中的每个商用服务器提供的大量CPU。MapReduce加上GFS形成了处理海量数据的核心力量，包括构建Google的搜索索引。 　　不过，两个系统都缺乏实时随机存取数据的能力【这意味着尚不足以处理Web服务】。GFS的另一个缺陷是，它适合存储少许非常大的文件，而不适合存储数量众多的小文件。因为文件的元数据信息最终要存储在主节点的内存中，文件越多主节点的压力越大。 　　因此，Google尝试去找到一个能够驱动交互式应用的解决方案，例如，Google邮件或Google分析，能够同时利用这种基础结构、依靠GFS存储的数据冗余和数据可用性较强的特点。存储的数据应该拆分成特别小的条目，然后由系统将这些小记录聚合到非常大的存储文件中，并提供一些索引排序

转自： http://www.oschina.net/question/12_32573 二级索引与索引Join是Online业务系统要求存储引擎提供的基本特性。RDBMS支持得比较好，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来探讨如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook和官方Coprocessor方案的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果想实现了高性能地范围检索，必然需要依赖冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果对范围检索的性能要求不高，那么可以不考虑冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row

二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性，RDBMS早已支持，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来讨论如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook方案和官方Coprocessor的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果你实现了高性能地范围检索，必然需要靠冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果你不要求高效地范围检索，那么可以不考虑产生冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。 单表以row key存储索引

二级索引与索引Join是Online业务系统要求存储引擎提供的基本特性。RDBMS支持得比较好，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来探讨如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index,?ITHbase, Facebook和官方Coprocessor方案的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果想实现了高性能地范围检索，必然需要依赖冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果对范围检索的性能要求不高，那么可以不考虑冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。 单表以row

问题现象：hive执行sql报错 select count(*) from test_hive_table; 报错 Error: java.io.IOException: org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=36, exceptions: Wed May 16 10:22:17 CST 2018, null, java.net.SocketTimeoutException: callTimeout=60000, callDuration=68270: row '6495922803d09' on table 'test_hbase_table' at region=test_hbase_table,6495922803d09,1526207008130.6060407a4aa5e23c8df09614dd3fe650., hostname=server121,16020,1526398855988, seqNum=47468 直接原因一：region状态 这个hive表是外部表，底层数据存放在hbase中，出现问题的region状态： 2018-05-16 03:18:16 在RegionServer server121 上线； 2018-05-16 06