hbase

可以访问以下网站查看hbase服务状态及master等等信息，http。//retailvm1d。nam。nsroot。net。60010/zk.jspHBase is rooted at /hbaseActive master address: retailvm1d,39706,1377502441684Backup master addresses:Region server holding ROOT: retailvm1d,38110,1377502442130Region servers:retailvm1d,38110,1377502442130Quorum Server Statistics:localhost:2181Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMTClients:/127.0.0.1:36679[1](queued=0,recved=441,sent=448)/127.0.0.1:36681[1](queued=0,recved=502,sent=503)/127.0.0.1:36678[1](queued=0,recved=521,sent=543)/127.0.0.1:37218[0](queued=0,recved=1,sent=0)Latency min/avg/max: 0/0/159Received: 1533Sent: 1562Connections: 4Outstanding: 0Zxid: 0x49Mode: standaloneNode count: 23

可以访问以下网站查看hbase服务状态及master等等信息，http。//retailvm1d。nam。nsroot。net。60010/zk.jspHBase is rooted at /hbaseActive master address: retailvm1d,39706,1377502441684Backup master addresses:Region server holding ROOT: retailvm1d,38110,1377502442130Region servers: retailvm1d,38110,1377502442130Quorum Server Statistics: localhost:2181 Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT Clients: /127.0.0.1:36679[1](queued=0,recved=441,sent=448) /127.0.0.1:36681[1](queued=0,recved=502,sent=503) /127.0.0.1:36678[1](queued=0,recved=521,sent=543) /127.0.0.1:37218[0](queued=0,recved=1,sent=0) Latency min/avg/max: 0/0/159 Received: 1533 Sent: 1562 Connections: 4 Outstanding: 0 Zxid: 0x49 Mode: standalone Node count: 23

hbase的特点：高可靠性、高性能、面向列、可伸缩的。HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。扩展资料访问接口：1. Native Java API，最常规和高效的访问方式，适合Hadoop MapReduce Job并行批处理HBase表数据2. HBase Shell，HBase的命令行工具，最简单的接口，适合HBase管理使用3. Thrift Gateway，利用Thrift序列化技术，支持C++，PHP，Python等多种语言，适合其他异构系统在线访问HBase表数据4. REST Gateway，支持REST 风格的Http API访问HBase, 解除了语言限制5. Pig，可以使用Pig Latin流式编程语言来操作HBase中的数据，和Hive类似，本质最终也是编译成MapReduce Job来处理HBase表数据，适合做数据统计。参考资料来源：百度百科-HBase

Python连接HBase时需要先加载Thrift和HBase的相关包，之后创建与HBase的连接并进行后续操作，具体代码如下：# -*- coding: utf-8 -*-import sysreload(sys)sys.setdefaultencoding("utf-8")from thrift.transport.TSocket import TSocketfrom thrift.transport.TTransport import TBufferedTransportfrom thrift.protocol import TBinaryProtocolfrom hbase import Hbasefrom hbase.ttypes import *import pymongoimport hashlibimport timefrom datetime import datetimeclass HBaseOperator(): def __init__(self): self.host = "ip_address" self.port = 9090 self.transport = TBufferedTransport(TSocket(self.host, self.port)) self.transport.open() self.protocol = TBinaryProtocol.TBinaryProtocol(self.transport) self.client = Hbase.Client(self.protocol) def __del__(self): self.transport.close() def getAllTablesInfo(self): #get table info listTables = self.client.getTableNames() print "="*40 print "Show all tables information...." for tableName in listTables: print "TableName:" + tableName print " " listColumns = self.client.getColumnDescriptors(tableName) print listColumns print " " listTableRegions = self.client.getTableRegions(tableName) print listTableRegions print "+"*40

三台服务器，每个regionserver的请求都有上千？将thrift的最大线程数再调大，thrift的内存调大看看，ulimit参数调大hbase-env.shexport HBASE_THRIFT_OPTS="-Xmx1g -Xms1g -Xmn512m"这里设的是1g，可以根据情况调大

1）HFile由DataBlock、Meta信息(Index、BloomFilter)、Info等信息组成。 2）整个DataBlock由一个或者多个KeyValue组成。 3）在文件内按照Key排序。 这里只介绍V2版本的，HFileV1的数据格式在0.92版本升级到V2版本。 1）文件分为三部分：Scanned block section,Non-scanned block section,以及Opening-time data section Scanned block section：表示顺序扫描HFile时（包含所有需要被读取的数据）所有的数据块将会被读取，包括Leaf Index Block和Bloom Block； Non-scanned block section：HFile顺序扫描的时候该部分数据不会被读取，主要包括Meta Block即BloomFilter和Intermediate Level Data Index Blocks两部分； Load-on-open-section：这部分数据在HBase的region server启动时，需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index； Trailer：这部分主要记录了HFile的基本信息、各个部分的偏移值和寻址信息。 Leaf index block具体存储了DataBlock的offset、length、以及firstkey的信息。 RootDataIndex 存储的是每个Leaf index block的offset、length、Leaf index Block记录的第一个key，以及截至到该Leaf Index Block记录的DataBlock的个数。 假定DataBlock的个数足够多，HFile文件又足够大的情况下，默认的128KB的长度的ROOTDataIndex仍然存在超过chunk大小的情况时，会分成更多的层次。这样最终的可能是ROOT INDEX –> IntermediateLevel ROOT INDEX(可以是多层) —〉Leaf index block 在ROOT INDEX中会记录Mid Key所对应的信息，帮助在做File Split或者折半查询时快速定位中间Row的信息。 HFile V2的写操作流程： 1）Append KV到 Data Block。在每次Append之前，首先检查当前DataBlock的大小是否超过了默认的设置，如果不超出阈值，写入输出流。如果超出了阈值，则执行finishBlock()，按照Table-CF的设置，对DataBlock进行编码和压缩，然后写入HFile中。//以Block为单位进行编码和压缩，会有一些性能开销，可以参考 HBase实战系列1—压缩与编码技术 2）根据数据的规模，写入Leaf index block和Bloom block。 Leaf index Block，每次Flush一个DataBlock会在该Block上添加一条记录，并判断该Block的大小是否超过阈值(默认128KB)，超出阈值的情况下，会在DataBlock之后写入一个Leaf index block。对应的控制类：HFileBlockIndex，内置了BlockIndexChunk、BlockIndexReader和BlockIndexWriter(实现了InlineBlockWriter接口)。 Bloom Block设置：默认使用MURMUR hash策略，每个Block的默认大小为128KB，每个BloomBlock可以接收的Key的个数通过如下的公式计算，接收的key的个数 与block的容量以及errorRate的之间存在一定的关系，如下的计算公式中，可以得到在系统默认的情况下，每个BloomBlock可以接纳109396个Key。 注意：影响BloomBlock个数的因素，显然受到HFile内KeyValue个数、errorRate、以及BlockSize大小的影响。可以根据应用的需求合理调整相关控制参数。 每一个BloomBlock会对应index信息，存储在Meta Index区域。 这样在加载数据的时候，只需加载不超过128KB的RootDataIndex以及IntermediateLevelRootIndex，而避免加载如HFile V1的所有的Leaf index block信息，同样，也只需要加载BloomBlockIndex信息到内存，这样避免在HFile V1格式因为加载过大的DataBlockIndex造成的开销，加快Region的加载速度。 在HFile中根据一个key搜索一个data的过程： 1、先内存中对HFile的root index进行二分查找。如果支持多级索引的话，则定位到的是leaf/intermediate index，如果是单级索引，则定位到的是data block 2、如果支持多级索引，则会从缓存/hdfs（分布式文件系统）中读取leaf/intermediate index chunk，在leaf/intermediate chunk根据key值进行二分查找（leaf/intermediate index chunk支持二分查找），找到对应的data block。 3、从缓存/hdfs中读取data block 4、在data block中遍历查找key。 1、 首先读取文件尾的4字节Version信息（FileTrailer的version字段）。 2、 根据Version信息得到Trailer的长度（不同版本有不同的长度），然后根据trailer长度，加载FileTrailer。 3、 加载load-on-open部分到内存中，起始的文件偏移地址是trailer中的loadOnOpenDataOffset，load-on-open部分长度等于（HFile文件长度 - HFileTrailer长度） Load-on-open各个部分的加载顺序如下： 依次加载各部分的HFileBlock（load-on-open所有部分都是以HFileBlock格式存储）：data index block、meta index block、FileInfo block、generate bloom filter index、和delete bloom filter。HFileBlock的格式会在下面介绍。 在hfile中，所有的索引和数据都是以HFileBlock的格式存在在hdfs中， HFile version2的Block格式如下两图所示，有两种类型，第一种类型是没有checksum；第二种是包含checksum。对于block，下图中的绿色和浅绿色的内存是block header；深红部分是block data；粉红部分是checksum。 第一种block的header长度= 8 + 2 * 4 + 8; 第二种block的header长度=8 + 2 * 4 + 8 + 1 + 4 * 2； BlockType：8个字节的magic，表示不同的block 类型。 CompressedBlockSize：表示压缩的block 数据大小（也就是在HDFS中的HFileBlock数据长度），不包括header长度。 UncompressedBlockSize：表示未经压缩的block数据大小，不包括header长度。 PreBlockOffset：前一个block的在hfile中的偏移地址；用于访问前一个block而不用跳到前一个block中，实现类似于链表的功能。 CheckSumType：在支持block checksum中，表示checksum的类型。 bytePerCheckSum：在支持checksum的block中，记录了在checksumChunk中的字节数；records the number of bytes in a checksum chunk。 SizeDataOnDisk：在支持checksum的block中，记录了block在disk中的数据大小，不包括checksumChunk。 DataBlock是用于存储具体kv数据的block，相对于索引和meta（这里的meta是指bloom filter）DataBlock的格式比较简单。 在DataBlock中，KeyValue的分布如下图，在KeyValue后面跟一个timestamp。 HFile中的index level是不固定的，根据不同的数据类型和数据大小有不同的选择，主要有两类，一类是single-level（单级索引），另一类是multi-level（多级索引，索引block无法在内存中存放，所以采用多级索引）。 HFile中的index chunk有两大类，分别是root index chunk、nonRoot index chunk。而nonRoot index chunk又分为interMetadiate index chunk和leaf index chunk，但intermetadiate index chunk和leaf index chunk在内存中的分布是一样的。 对于meta block和bloom block，采用的索引是single-level形式，采用single-level时，只用root index chunk来保存指向block的索引信息（root_index-->xxx_block）。 而对于data，当HFile的data block数量较少时，采用的是single level(root_index-->data_block)。当data block数量较多时，采用的是multi-level，一般情况下是两级索引，使用root index chunk和leaf index chunk来保存索引信息(root_index-->leaf_index-->data_block)；但当data block数量很多时，采用的是三级索引，使用root index chunk、intermetadiate index chunk和leaf index chunk来保存指向数据的索引（root_index-->intermediate_index-->leaf_index-->data_block）。 所有的index chunk都是以HFileBlock格式进行存放的，首先是一个HFileBlock Header，然后才是index chunk的内容。 Root index适用于两种情况： 1、作为data索引的根索引。 2、作为meta和bloom的索引。 在Hfile Version2中，Meta index和bloom index都是single-level，也都采用root索引的格式。Data index可以single-level和multi-level的这形式。Root index可以表示single-level index也可以表示multi-level的first level。但这两种表示方式在内存中的存储方式是由一定差别，见图。 对于multi-level root index，除了上面index entry数组之外还带有格外的数据mid-key的信息，这个mid-key是用于在对hfile进行split时，快速定位HFile的中间位置所使用。Multi-level root index在硬盘中的格式见图3.4。 Mid-key的信息组成如下： 1、Offset：所在的leaf index chunk的起始偏移量 2、On-disk size：所在的leaf index chunk的长度 3、Key：在leaf index chunk中的位置。

Hbase是Hadoop的一个存储组件可以提供低延迟的读写操作，它一般构建在HDFS之上，可以处理海量的数据。Hbase有个很好的特性是可以自动分片，也就是意味着当表的数据量变得很大的时候，系统可以自动的分配这些数据。 Hbase的基本存储单位是Region，Region是表数据的子集，多个Region的数据集合可以组成一张完成的表数据。Region本质上存储的一些排好序的，连续的行数据。最初的时候一张表只有一个Region，当Region变得非常大的时候，Region就会从中间分裂成两个基本等大的Region。 在Hbase中，slave也被称作RegionServer，每个RegionServer负责管理一些Region，同时一个Region只能属于一个RegionServer。 一个RegionServer可以服务一个或多个Region，每个Region在Region Server启动的时候被分配。Master可以决定将一些Region从一个RegionServer中移动到令一个RegionServer里面，以便更好的负载均衡。当某个RegionServer故障的时候，Master也可以将它的Region分配给其他的RegionServer。 Region与RegionServer之间的映射关系存储在Zookeeper中的META表中，通过读取META表，你就可以知道那个Region可以负责处理你的rowkey操作，其实这也代表着在HBase读写操作的时候是不用经过Master节点的，你可以之间联系RegionServer。 如图，在客户端进行scan的时候，它可以之间联系多个RegionServer处理当前的操作。 Meta表是用来跟踪Region的，它包含服务器的名称，Region的名称，表名，还有Region的startkey。通过startkey的范围，客户端就可以定位到当前的key要去哪一个Region了。 客户端在请求过META表之后，一般会将表缓存起来，防止每次操作都去获取。在Region进行分裂的时候，客户端去RegionServer操作Region的时候回返回异常，然后客户端会重新获取最新的META表信息。 Hbase的Java客户端API有两个主要的接口： 通过上面介绍，可以知道HBase虽然是Master/Slave架构的，但是并不是每次操作都经过Master的，读写数据的时候HBase只需要直接联系RegionServer即可。这也是HBase可以“无限扩容”的原因。在吞吐量不够的时候，通过增加RegionServer节点，可以增加吞吐量。

ZooKeeper是一个开源的分布式协调服务，由雅虎创建，是Google Chubby的开源实现。分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。 既然ZooKeeper的作用这么大，那我们就来详细说说ZooKeeper在HBase中的应用叭！ 一个分布式HBase系统安装依赖于一个运行着的ZooKeeper集群，所有参与的节点和客户端必须能够正常访问运行着的ZooKeeper集群。HBase默认为你提供一个节点的ZooKeeper集群，它会伴随着HBase start/stop进程的启动/停止而启动/停止。那么HBase主要用ZooKeeper来干什么呢？HBase主要用ZooKeeper来实现HMaster选举与主备切换、系统容错、RootRegion管理、Region状态管理和分布式SplitWAL任务管理等。 一，HMaster选举与主备切换 HMaster选举与主备切换的原理和HDFS中NameNode及YARN中ResourceManager的HA原理相同。 二，系统容错 当HBase启动时，每个RegionServer都会到ZooKeeper的/hbase/rs节点下创建一个信息节点（下文中，我们称该节点为”rs状态节点”），例如/hbase/rs/[Hostname]，同时，HMaster会对这个节点注册监听。当某个 RegionServer 挂掉的时候，ZooKeeper会因为在一段时间内无法接受其心跳（即 Session 失效），而删除掉该 RegionServer 服务器对应的 rs 状态节点。与此同时，HMaster 则会接收到 ZooKeeper 的 NodeDelete 通知，从而感知到某个节点断开，并立即开始容错工作。 按照上面所说，那为什么HBase不直接让HMaster来负责RegionServer的监控呢？如果HMaster直接通过心跳机制等来管理RegionServer的状态，随着集群越来越大，HMaster的管理负担会越来越重，另外它自身也有挂掉的可能，因此数据还需要持久化。在这种情况下，ZooKeeper就成了理想的选择。 三，Region管理 对于大的HBase集群来说，Region的数量可能会多达十万级别，甚至更多，这样规模的Region状态管理交给ZooKeeper来做也是一个非常nice的选择。 四，分布式SplitWAL任务管理 当某台RegionServer服务器挂掉时，由于总有一部分新写入的数据还没有持久化到HFile中，因此在迁移该RegionServer的服务时，一个重要的工作就是从WAL中恢复这部分还在内存中的数据，而这部分工作最关键的一步就是SplitWAL，即HMaster需要遍历该RegionServer服务器的WAL，并按Region切分成小块移动到新的地址下，并进行日志的回放（replay）。 由于单个RegionServer的日志量相对庞大（可能有上千个Region，上GB的日志），而用户又往往希望系统能够快速完成日志的恢复工作。因此一个可行的方案是将这个处理WAL的任务分给多台RegionServer服务器来共同处理，而这就又需要一个持久化组件来辅助HMaster完成任务的分配。当前的做法是，HMaster会在ZooKeeper上创建一个SplitWAL节点（默认情况下，是/hbase/SplitWAL节点），将“哪个RegionServer处理哪个Region”这样的信息以列表的形式存放到该节点上，然后由各个RegionServer服务器自行到该节点上去领取任务并在任务执行成功或失败后再更新该节点的信息，以通知HMaster继续进行后面的步骤。ZooKeeper在这里担负起了分布式集群中相互通知和信息持久化的角色。 u200b 综上，就是ZooKeeper在HBase中的应用，在这里只列举出了一部分，相对说比较突出的作用，其实ZooKeeper在HBase中的应用远不止这些，比如HMaster还依赖ZooKeeper来完成Table的enable/disable状态记录，以及HBase中几乎所有的元数据存储都是放在ZooKeeper上的等等。

MapReduce把Nutch提取的Segment中data文件里信息保存到Hbase里。

一、背景 最近由于项目和论文的需要，需要搭建一个垂直搜索的环境，查阅了很多资料，决定使用Apache的一套解决方案hadoop+hbase+nutch+es。这几样神器的作用就不多作介绍了，自行参考各类百科就行了。我选择这样的方案主要是基于以下考虑： 1、可扩展，虽然 一、背景最近由于项目和论文的需要，需要搭建一个垂直搜索的环境，查阅了很多资料，决定使用Apache的一套解决方案hadoop+hbase+nutch+es。这几样神器的作用就不多作介绍了，自行参考各类百科就行了。我选择这样的方案主要是基于以下考虑：1、可扩展，虽然只是实验环境，但是以后在项目中是要应用到生产中的，随着数据量的增大，需要的硬件设备能够方便的加入进来，所以选择了分布式的方案中最具人气的hadoop+hbase组合2、数据来源兼容，nutch2以后集成了gora和tika，可以方便的进行数据ORM和分析3、与时俱进，es很火嘛，而且各种评测说es比solr更快更稳定，虽然没有自己测试过，但是跟随github大牛们的脚步总不会错得太离谱二、前言这一部分纯粹吐槽，国内的好多技术博客不是停留在nutch1X阶段，就是各种不负责任的抄袭转载，某几位先驱说这几样东西版本必须一对一兼容，然后所有人都这样去做，没有一点探索精神和质疑精神。今天，我就做第一个吃螃蟹的人，谁说gora0.3只能配hbase0.92，谁说nutch2只能配es0.19，既然开源的大牛们放出了稳定最新版，就一定有能兼容的道理！三、安装与配置过程（伪分布式）整个实验环境采用伪分布式模式搭建，也就是只有一台master的分布式环境，以后扩展只需要继续配置slaver就可以了。 系统为ubuntu server 12.04hadoop1.2.1hadoop安装的前提是java和ssh免密码登陆配置，这个不多说了，基本的，jdk1.6和1.7都可以。1、官网的stable目录里面下载hadoop1.2.1的deb包2、安装hadoop的deb包sudo dpkg -i /home/hadoop/hadoop_1.2.1-1_x86_64.deb3、查看安装的位置whereis hadoop输出：hadoop: /usr/bin/hadoop /etc/hadoop /usr/etc/hadoop /usr/bin/X11/hadoop /usr/include/hadoop /usr/share/hadoop这里面/etc/hadoop目录是hadoop的各种配置文件，/usr/share/hadoop则是hadoop的主要jar包和监控页面的东西4、下面开始修改配置文件：hdfs-site.xmldfs.name.dir/home/hadoop/namedfs.data.dir/home/hadoop/datadfs.replication1Default block replication.The actual number of replications can be specified when the file is created.The default is used if replication is not specified in create time.mapred-site.xml?mapred.job.trackerlocalhost:54311The host and port that the MapReduce job tracker runsat. If "local", then jobs are run in-process as a single mapand reduce task.core-site.xmlhadoop.tmp.dir/home/hadoop/tmpA base for other temporary directories.fs.default.namehdfs://localhost:54310The name of the default file system. A URI whosescheme and authority determine the FileSystem implementation. Theuri"s scheme determines the config property (fs.SCHEME.impl) namingthe FileSystem implementation class. The uri"s authority is used todetermine the host, port, etc. for a filesystem.hadoop-env.sh修改java路径export JAVA_HOME=/usr/lib/jvm/java-7-oracle修改pid路径为hadoop运行账户能访问到的路径，默认是/var/run/hadoop，如果不是sudo组的化是没权限的，而且每次重启都会清空这个目录，用chown无法起到长期作用。export HADOOP_PID_DIR=/home/hadoop/run/hadoopexport HADOOP_SECURE_DN_PID_DIR=/home/hadoop/run/hadoopmasters和slaves如果是伪分布式，直接localhost，如果是完全分布式，masters填写master的ip地址，slaves填写slave的ip地址，回车隔开至此基本的配置已经完毕，如果想了解更多配置内容可以参考这篇文章《hadoop三个配置文件的参数含义说明》5、启动hadoop先格式化namenodehadoop?namenode?-format然后启动start-all.sh=============================================hbase0.94.111、官网stable目录下下载hbase0.94.11的tar包并解压tar -zxvf hbase-0.94.11.tar.gz2、去conf目录修改hbase-site.xmlhbase.rootdirhdfs://localhost:54310/hbasehbase.cluster.distributedtruehbase.zookeeper.quorumlocalhost3、修改hbase-env.sh文件添加如下三行：export JAVA_HOME=/usr/lib/jvm/java-7-oracle/export HBASE_CLASSPATH=/etc/hadoopexport HBASE_MANAGES_ZK=true至此配置文件修改结束（如果完全分布式还要修改regionservers），更多配置参数和调优可以参考这篇文章《HBase入门篇3-hbase 配置文件参数设置及优化》4、替换hadoop的jar文件hbase0.94.11默认支持的是hadoop1.0.4，我们可以用替换hadoop-core的方式让其支持hadoop1.2.1rm?/home/hadoop/hbase-0.94.11/lib/hadoop-core-1.0.4.jarcp?/usr/share/hadoop/hadoop-core-1.2.1.jar?/home/hadoop/hbase-0.94.11/libcp /usr/share/hadoop/lib/commons-collections-3.2.1.jar?/home/hadoop/hbase-0.94.11/libcp /usr/share/hadoop/lib/commons-configuration-1.6.jar?/home/hadoop/hbase-0.94.11/lib5、启动hbase/home/hadoop/hbase-0.94.11/bin/start-hbase.sh6、用jps命令看是否运行正常输出为：2032 NameNode13764 HQuorumPeer29069 Jps2630 JobTracker2280 DataNode13889 HMaster2535 SecondaryNameNode2904 TaskTracker14180 HRegionServer注意这几个东西一个都不能少，如果有什么少了，一定要去日志里看看是怎么回事。7、尝试运行hbase命令/home/hadoop/hbase-0.94.11/bin/hbase?shellHBase?Shell;?enter?"help"?for?list?of?supported?commands.Type?"exit"?to?leave?the?HBase?ShellVersion?0.90.4,?r1150278,?Sun?Jul?24?15:53:29?PDT?2011hbase(main):001:0>?listTABLE??????????????????????????????????????????webpage?????????????????????????????????????????1?row(s)?in?0.5270?seconds如果不报错，说明已经配置成功?==================================================================ElasticSearch0.90.5这里不像一般的博客那样先安装nutch，而是先安装es，为什么，因为逻辑上来讲，nutch是一个爬虫加集成器，es被nutch集成，所以先安装es，这在思想上叫做由零到整。1、官网下载es0.90.5的deb安装包并安装sudo dpkg -i /home/hadoop/elasticsearch/elasticsearch-0.90.5.deb2、查看安装了哪些东西whereis?elasticsearch输出：elasticsearch: /etc/elasticsearch /usr/share/elasticsearch其中/etc/elasticsearch目录里面的elasticsearch.yml文件是比较重要的配置文件，这里我们使用默认配置，不做修改，需要特殊配置的同学可以参考这篇文章《分布式搜索elasticsearch配置文件详解》。而/usr/share/elasticsearch里面则是es主要的执行文件和jar包了3、检查es运行状态es安装好后就默认开启了，貌似关闭只能杀死进程，启动的话直接输入命令elasticsearch即可。使用curl来检查es的cluster的运行状态，并获得clusternamecurl -XGET "localhost:9200/_cluster/health?pretty"如果获得以下输出，表示成功了{"cluster_name" : "elasticsearch","status" : "green","timed_out" : false,"number_of_nodes" : 2,"number_of_data_nodes" : 2,"active_primary_shards" : 5,"active_shards" : 10,"relocating_shards" : 0,"initializing_shards" : 0,"unassigned_shards" : 0}======================================================================nutch2.2.11、官网下载tar包并解压2、修改源码这里要吐槽下nutch的开源大牛们，这么明显的bug你就发出版本来了，而且几个版本都不改，如果你有你的道理，你应该文档说明一下好吧，为毛我都找不到你们的正式说明？进入src/java/org/apache/nutch/crawl目录，修改GeneratorJob.java中的public Map run(Map args) 方法。添加以下三行//?generate?batchId?int?randomSeed?=?Math.abs(new?Random().nextInt()); ??String?batchId?=?(curTime?/?1000)?+?"-"?+?randomSeed; ??getConf().set(BATCH_ID,?batchId); ??如果不这样做，nutch generate的时候会报NullPointerException，真心不知道他们是出于什么目的?3、拷贝hbase的配置文件到nutch??cp /home/hadoop/hbase-0.94.11/conf/hbase-site.xml /home/hadoop/nutch2.2.1/conf/?4、拷贝 hbase0.92 ? 的jar包到nutch的lib目录这一步是关键，nutch自带的gora0.3是只能支持到最高hbase0.92，默认是hbase0.90，如果不做这一步，nutch就会用默认的0.90jar包去操作0.94的hbase，导致一个“java.lang.IllegalArgumentException: Not a host:port pair”的奇葩错误（据说是低版本client操作高版本server的常见错误）。但是你也不能直接用0.94的jar包去替换，因为这又会导致另一个奇葩错误“java.lang.NoSuchMethodError:org.apache.hadoop.hbase.HColumnDescriptor.setMaxVersions(I)V”，据说这个错误已经被记入HBASE官方JIRA，BUG编号：HBASE-8273。大概意思是说这个setMaxVersions函数的返回值改了。尼玛，这帮人有没有点面向对象合作编程的常识啊，你丫就不能重新写个函数啊。。那么吐槽归吐槽，怎么解决呢，既然大家都说0.92的支持好，那我就用0.92的jar包做替换试试，离0.94就差一个版本，应该不算太低的版本，说不定能操作0.94的库呢，这一试还真成了。具体办法就是官网上下个hbase0.92.2的版本，把里面的hbase-0.92.2.jar文件拷贝到/home/hadoop/nutch2.2.1/lib目录下即可?5、修改nutch-site.xml?storage.data.store.classorg.apache.gora.hbase.store.HBaseStoreDefault?class?for?storing?datahttp.agent.nameMozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36?关于该文件各个参数的详细解释可以参考这个excel文件——《nutch配置》?6、修改ivy/ivy.xml??首先是一个常规的修改，找到这一行，把注释去掉?然后是见证奇迹的修改，让nutch2.2.1支持es0.90.5的修改。找到这一行，把rev的值0.19.4替换为?0.90.5?这就是ivy进行包依赖管理的强大之处，一会儿执行ant的时候就是见证奇迹的时刻。如果不做这一步，在进行nutch elasticindex（建立索引）的时候，会报MasterNotDiscoveredException?7、修改conf/gora.properties文件添加一行：?gora.datastore.default=org.apache.gora.hbase.store.HBaseStore8、执行ant编译首次执行ant的时候会比较慢，因为ivy要下载依赖包，大家仔细观察屏幕上的输出，可以看到编译到elasticsearch依赖的时候，成功下来了0.90.5的jar包，同时下载的还有lucene4.4.0执行完成后，会看到nutch目录下多了runtime目录，里面deploy用于分布式抓取，local用于本地抓取?至此，所有的安装配置都已完成，enjoy it！??四、简单体验一下抓取和检索的过程?1、建立一个目录urls2、在urls目录里写一个种子文件，命名为url，里面随便写个页面丰富的网址例如http://blog.tianya.cn3、将该目录放到hadoop的hdfs上? ? ?hadoop fs -copyFromLocal urls /home/hadoop/urls4、执行nutch inject，向hbase注入抓取种子页? ??bin/nutch inject /home/hadoop/urls执行完成后，可以在hbase里面看到“webpage”这个表?5、执行nutch 抓取流程分别执行以下命令?bin/nutch generate -topN 10bin/nutch?fetch?-allbin/nutch?parse?-allbin/nutch?updatedb执行完成后，可以去hbase里面scan一下webpage表，应该已经有了百行以上的结果?6、为elasticsearch建立索引?bin/nutch elasticindex-all?如果没有修改过es的配置文件，这里cluster name默认应该是“elasticsearch”?7、利用curl进行查询?curl -XGET "http://localhost:9200/_search?content=tianya"要想进行中文查询，可以自行添加中文分词插件，参考《分布式搜索elasticsearch中文分词集成》??五、总结?这篇博客虽然吐槽较多，但我还是挺尊重一些认真写博客，认真在论坛回答问题的大牛的，能够配置安装成功，也受到了一些大牛博客和大牛回答的启发，在这里要感谢这些无私的人。?下面就要在实际的实验和项目中检验我这套配置的合理性和健壮性了，以后博客中，也会多多记录在使用中遇到的问题和解决方法。? 声明：如未作说明，则本文为 渣滓洞【解_的博客】 原创。转载务必注明出处。 注意：转载须保留全文，如需修改请联系作者。 本文永久地址:http://xieminis.me/?p=268

目前主流的数据库或者NoSQL要么在CAP里面选择AP，比较典型的例子是Cassandra，要么选择CP比如HBase，这两个是目前用得非常多的NoSQL的实现。我们的价值观一定认为未来是分布式的，一定是尽量倾向于全部都拥有，大部分情况下取舍都是HA，主流的比较顶级的数据库都会选择C，分布式系统一定逃不过P，所以A就只能选择HA。现在主要领域是数据库的开发，完全分布式，主要方向和谷歌的F1方向非常类似。目前看NewSQL代表未来(GoogleSpanner、F1、)，HBase在国内有六个Committer，在目前主流的开源数据库里面几乎是最强的阵容。大家选型的时候会有一个犹豫，到底应该选择HBase还是选Cassandra。根据应用场景，如果需要一致性，HBase一定是你最好的选择，我推荐HBase。它始终保持强一致，我们非常喜欢一致性，丧失一致性的时候有些错误会特别诡异，很难查。对于Push-down特性的设计其实比较好，全局上是一个巨大的分布式数据库，但是逻辑上是分成了一个个Region，Region在哪台机器上是明确的。比如要统计记录的条数，假设数据分布在整个系统里面，对数十亿记录做一个求和操作，就是说不同的机器上都要做一个sum，把条件告诉他要完成哪些任务，他给你任务你再汇总，这是典型的分布式的MPP，做加速的时候是非常有效的。2015年HBaseConf上面有一句总结:“NothingishotterthanSQL-on-Hadoop,andnowSQL-on-HBaseisfastapproachingequalhotnessstatus”，实际上SQL-on-HBase也是非常火。因为SchemaLess没有约束其实是很吓人的一件事情，当然没有约束也比较爽，就是后期维护十分痛苦，规模进一步扩大了之后又需要迁移到SQL。现在无论从品质还是速度上要求已经越来越高，拥有SQL的同时还希望有ACID的东西(OLAP一般不追求一致性)。所以TiDB在设计时就强调这样的特点：始终保持分布式事务的支持，兼容MySQL协议。无数公司在SQL遇到Scale问题的时候很痛苦地做出了选择，比如迁移到HBase，CassandraMongoDB已经看过太多的公司做这种无比痛苦的事情，现在不用痛苦了，直接迁过来，直接把数据导进来就OK了。TiDB最重要的是关注OLTP，对于互联网业务来说通常是在毫秒级内就需要返回一个结果。我们到目前为止开发了六个月，开源了两个月。昨天晚上TiDB达到了第一个Alpha的阶段，现在可以拥有一个强大的数据库：支持分布式事务，始终保持同步的复制，强大的按需Scale能力，无阻塞的Schema变更。发布第一个Alpha版本的时候以前的质疑都会淡定下来，因为你可以阅读每一行代码，体验每个功能。选择这个领域也是非常艰难的决定，实在太Hardcore了，当初GoogleSpanner也做了5年。不过我们是真爱，我们就是技术狂，就是要解决问题，就是要挑大家最头痛的问题去解决。好在目前阿里的OceanBase给我们服了颗定心丸，大家也不会质疑分布式关系型数据库是否可行。

[baoniu@search0001 ~]$ hbase hfile 2 usage: HFile [-a] [-b] [-e] [-f <arg>] [-k] [-m] [-p] [-r <arg>] [-s] [-v] 3 [-w <arg>] 4 -a,--checkfamily Enable family check 5 -b,--printblocks Print block index meta data 6 -e,--printkey Print keys 7 -f,--file <arg> File to scan. Pass full-path; e.g. 8 hdfs://a:9000/hbase/hbase:meta/12/34 9 -k,--checkrow Enable row order check; looks for out-of-order 10 keys 11 -m,--printmeta Print meta data of file 12 -p,--printkv Print key/value pairs 13 -r,--region <arg> Region to scan. Pass region name; e.g. 14 "hbase:meta,,1" 15 -s,--stats Print statistics 16 -v,--verbose Verbose output; emits file and meta data 17 delimiters 18 -w,--seekToRow <arg> Seek to this row and print all the kvs for this

MemStore 是 HBase 非常重要的组成部分，MemStore 作为 HBase 的写缓存，保存着数据的最近一次更新，同时是HBase能够实现高性能随机读写的重要组成。 HBase Table 的每个 Column family 维护一个 MemStore，当满足一定条件时 MemStore 会执行一次 flush，文件系统中生成新的 HFile。 而每次 Flush 的最小单位是 Region 。 MemStore的主要作用： 如果一个 HRegion 中 MemStore 过多（Column family 设置过多），每次 flush 的开销必然会很大，并且生成大量的 HFile 影响后续的各项操作，因此建议在进行表设计的时候尽量减少 Column family 的个数。 MemStore 无论是对 HBase 的写入还是读取性能都至关重要，其中 flush 操作又是 MemStore 最核心的操作。MemStore 在多种情况下会执行一次 Flush 操作： 再次注意，MemStore 的 最小 flush 单元是 HRegion 而不是单个 MemStore 。 更新被阻塞对单个节点和整个集群的影响都很大，需要关注 MemStore 的大小和 Memstore Flush Queue 的长度。 为了减少 flush 过程对读写的影响，HBase 采用了类似于两阶段提交的方式，将整个 flush 过程分为三个阶段： 上述 flush 流程可以通过日志信息查看： 整个 flush 过程可能涉及到 compact 操作和 split 操作，因为过于复杂，不做详细讲解。 正常情况下，大部分 Memstore Flush 操作都不会对业务读写产生太大影响，比如：定期刷新 MemStore、手动触发、单个 MemStore flush、Region 级别的 flush 以及超过 HLog 数量限制等情况，这几种场景只会短暂的阻塞对应 Region 上的写请求，阻塞时间很短，毫秒级别。 然而 一旦触发 Region Server 级别的限制导致 flush，就会对用户请求产生较大的影响 。会阻塞所有落在该 RegionServer 上的更新操作，阻塞时间很长，甚至可以达到分钟级别。 导致触发 RegionServer 级别限制的主要因素： - Region Server 上运行的 Region 总数 Region 越多，Region Server 上维护的 MemStore 就越多。根据业务表读写请求量和 RegionServer 可分配内存大小，合理设置表的分区数量（预分区的情况）。 - Region 上的 Store 数（表的 Column family 数量） 每个 Column family 会维护一个 MemStore，每次 MemStore Flush，会为每个 Column family 都创建一个新的 HFile。当其中一个CF的 MemStore 达到阈值 flush 时，所有其他CF的 MemStore 也会被 flush，因此不同CF中数据量的不均衡将会导致产生过多 HFile 和小文件，影响集群性能。很多情况下，一个CF是最好的设计。 频繁的 MemStore Flush 会创建大量的 HFile。在检索的时候，就不得不读取大量的 HFile，读性能会受很大影响。为预防打开过多 HFile 及避免读性能恶化（读放大），HBase 有专门的 HFile 合并处理（HFile Compaction Process），根据一定的策略，合并小文件和删除过期数据。后续的文章会有详细介绍。

compaction从store上面，选取一些HFile进行合并。把key-value按顺序排列写入到新的文件下面，取代之前的文件提供数据。分为minorcompaction和majorcompaction。 1.minorcompaction 较小的，相邻的HFile的合并 2.majorcompaction 一个store里面的所有HFile的合并，合并成一个，会清理三类数据： 1.已经删除的数据 2.ttl过期的数据 3.版本超过限定的数据

不同列族分别存在不同的文件夹里。 与MySQL比较 首先Hbase是依赖于HDFS和zookeeper的。 Zookeeper分担了Hmaster的一部分功能，客户端进行DML语句的时候，都是先跟ZK交互。 RegionServer管理了很多的Region（表），RegionServer里面的WAL(HLog)是预写入日志，功能是防止内存中的数据没有来的及落盘时丢失。在Region里面管理的Store管理的是列族，Store里面有Mem Store（内存），Flush之后，删除内存中的数据，同时写入文件StoreFile Hfile,Hfile 其实是在DataNode里面的。 Hbase的读比写慢。 Hbase命名空间下有一张元数据表meta表和namespace表。meta表里面保存了要操作的表所在的位置等元数据。 （1）首先客户端向zk请求元数据表所在的RegionServer，zk返回给客户端meta表所在的regionServer。 （2）然后客户端再去对应的RegionServer查找meta表，找到真正要操作的表所在的regionServer，同时把meta表的信息缓存下来，加快后续的查询。 （3）然后客户端再向目标表所在的RegionServer发送put请求。先把数据写到Hlog里面，再写到内存MemStore,数据会在内存排序，然后向客户端发送ack，到这里对于客户端来说写数据已经结束了。再等到MemStore的刷写时机后，将数据刷写到Hfile. 注：meta表所在的位置信息保存在zk的meta-region-server节点上，客户端首先就是在这个节点上差询meta表所在的RegionServer。meta表里面的信息就是表与其对应的RegionServer的信息 这个stu表可能不止一条，因为stu表可能数据量大了之后根据RowKey进行了切分，并且可能会在不同的机器上。 不同的列族是在不同的文件夹。 MemStore刷写时机： 全局的MemStore的容量，默认是堆内存的40%。这个容量值会触发flush操作，所有的MemStore都要刷写，flush操作会阻塞读写操作。 会刷写并阻塞到到MemStore大小降到它的最大容量的95% WAL日志的刷写时机： 可以设置日志的大小和数量，当达到一定数量，刷写到HDFS （1）从zk找meta表所在的RegionServer （2）从上述RegionServer里的meta表里找目标表所在的RegionServer，同时把meta表缓存，加速后面的查询。 （3）向目标表所在的RegionServer发送get请求。可以从block Cache，MemStore还有StoreFile里面查，具体从哪查根据时间戳，查时间戳大的，具体就都查然后merge取最新。 RegionServer里面有block Cache可以缓存磁盘的数据，加速查询。如果block Cache里面有，就将缓存和MemStore的数据merge然后取最新时间戳，没有就是把磁盘读的和MemStore里面的合并。所以hbase大多数读要走磁盘，所以读很慢。 每次刷写会生成新的Hfile，Hfile很小并且数量多的时候会影响查询的速度。所以要进行合并。合并分为minor Compaction和major Compaction minor Compaction将临近的若干较小的Hfile合并成一个较大的Hfile，不会清理过期和删除的数据，major Compaction会将一个Store里面的所有Hfile合并成一个大的Hfile，并且会清理掉过期和删除的数据。 数据的读写可以不依赖Hmaster，只需要指定zookeeper，但是Hmaster负责region调度的元数据 但是DDL语言是要有Hmaster的 Flush和major Compact （1）flush在同一个内存中清除过期或删除（删除标记也是一行数据）的数据，但是如果数据不同的版本分布在不同的memStroe，就不能清除。删除的标记在flush之后不会被删，但在后面的major compaction会把删除标记删除掉。 （2）major compaction 会清除过期或删除的数据。 默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动拆分，两个子Region开始都会在一个Regionserver里面，但是出于负载均衡的考虑，Hmaster有可能会将某个Region传给其他的RegionServer。 Split的时机： （1）当一个Region中的某个Store下的StoreFile的总大小查过某个值，由参数hbase.hregion.max.filesize设定（默认10g），该Region就会按照RowKey进行拆分。 （2）在新版本中这个值是Min（R^2*"hbase.hregion.memStore.flush.size（128M）","hbase.hregion.max.filesize"）,R是当前RegionServer中属于该Table的Region个数。分region是按照RowKey切分的。这会导致数据倾斜，就是因为切分的阈值在变化，导致切分之后的region数据量不均匀，导致热点的问题。所以在建表的时候要做预分区，就是用RowKey规划好多少个region，不让hbase自己的切分逻辑切分。 官方建议只用一个列族，防止不同的列族之间数据不均匀，单一列族数据量增多，导致全局的flush，数据量小的列族也要flush，这样会形成很多小的storeFile。 delete操作： （1）设置RowKey：打的删除标记是deleteFamily，删除多个版本 （2）设置RowKey+Family：打的标记是deleteFamily，删除多个版本 （3）设置RowKey+family+column：有addColumn()和addColumns().addColumn是删除最新的版本或者删除指定时间戳的版本，删除标记是delete标记。addColumns是删除所有的版本或者删除指定时间戳或之前的版本，删除标记是deleteColumn Delete的操作其实也是put操作，put的是删除的标记。 在Hbase中HMaster负责监控HRegionServer的生命周期，均衡RegionServer的负载，如果HMaster挂掉了，那个整个Hbase集群将处于不健康的状态，并且此时的工作状态不会维持太久。所以Hbase支持对HMaster的高可用配置。 在Hbase的conf目录下新建backup-masters文件，vim加入备份Master，比如slave01,slave02.在把文件分发到各个slave里，然后再启动hbase 就能实现HMaster的高可用了。 每一个region维护着StartRow和EndRow，如果加入的数据符合某个region维护的RowKey范围，则该数据交给这个region维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高Hbase性能。 （1）手动设定预分区 手动设置RowKey分了5个region （2）生成16进制序列预分区 （3）按照文件中设置的规则预分区 创建split.txt 然后执行 这里如果文件里面给的分区键不是按照顺序的，hbase会先帮我们把键排序，然后按照键来分区。 （4）使用JavaAPI预分区 admin的创建表的方法有多个重载，可以只传表的描述，也可以加入分区的信息。admin.createTable 规划分区要考虑未来数据量和机器的规模。虽然提前做了分区，但是最后如果分区大于了10G,还是会触发split。假设一台机器有100G磁盘，那么预分区尽量大于10个，这样就能避免预分区之后又触发了大于10G的split。 （1）希望数据能够尽量均匀的分配在多个分区里面（散列性）。 （2）唯一性 （3）长度原则（生产环境70到100位） 常见的设计方案： （1）生产随机数、hash、散列值 （2）字符串反转 （3）字符串拼接 电信项目： 一次通话的记录：13112341233->18998768771 2018-12-12 12:12:21 568 假设分300个区 分区键怎么设计： （299个键） 000| 001| ... 298| RowKey的前面一般会拼上000_,001_,...,298_ 这样做的好处是，根据前三位就能知道哪个分区。 （1）我们希望手机号尽量分布在不同的分区，但是相同的手机号数据集中在同一个分区，这样方便查询某个用户的通话信息。000_13112341233 （2）因为每个人通话的需求不同，也希望把同一个人的通话记录也分布在不同的分区里面。000_13112341233_2019-12-12 哈希取余：[（13112341234^201912）.hash]%299 假设要查询某用户2019年2月的通话记录，可以用13112341234 201902做startRowkey，13112341234 201903做endRowKey 微博。 1、需求 （1）微博内容的浏览 （2）用户社交：关注用户，取关用户 （3）拉取关注人的微博用户 2、设计表 （1）微博内容表Content 行键：用户id+时间戳 （2）用户关系表 因为正常情况一个用户的粉丝和关注都不多，可以用一行存储关注和粉丝的情况。 行键：用户id （3）初始化页面的表（显示关注的人的最近三条微博）

Minor Compaction称为小合并，主要是选取一些小的、相邻的HFile将他们合并成较大的HFile，并删除HFile中的过期数据。Major Compaction称为大合并，会将一个列族下的所有HFile合并成一个大的HFile，同时删除过期数据、已删除数据（打了Delete标记的）、版本过大的数据等三类无效数据。

HBase采用了类似Google Bigtable的数据模型，即一个稀疏的、分布式的、持久化的多维映射表，每个表都由行键、列族、列限定符和时间戳组成。在底层实现上，HBase使用了基于Hadoop的分布式文件系统HDFS来存储数据，并且使用了一种称为LSM-Tree（Log-Structured Merge-Tree）的数据结构来管理数据。LSM-Tree是一种支持高写入吞吐量的数据结构，它把数据分成多个层，每层采用不同的策略来管理数据，包括内存中的缓存、写入磁盘的SSTable、和合并SSTable的操作。通过这种方式，HBase能够支持高并发、高吞吐量的数据写入，同时保证数据的一致性和可靠性。另外，HBase还采用了Bloom Filter、MemStore和Compaction等技术来提高数据查询效率和存储效率。Bloom Filter是一种快速的数据过滤技术，可以帮助HBase快速地过滤掉无效的查询请求，提高查询效率。MemStore是一种缓存机制，可以帮助HBase加速数据写入，提高数据写入效率。Compaction则是一种数据压缩和合并技术，可以帮助HBase节省存储空间，提高存储效率。综上所述，HBase采用了LSM-Tree、Bloom Filter、MemStore和Compaction等多种数据结构和技术，以实现高并发、高吞吐量的分布式存储和查询功能。

合并storefile的过程称为Compaction过程，主要过程是合并由memStore的flush操作产生的部分或者所有StoreFile，主要有以下几个作用： 1）合并文件。由于flush的触发是针对所有memStore，所以缓存有些记录不多的memStore flush之后的结果是很多小文件。Compaction操作可以合并这些小文件，减小对StoreFile的维护成本。 2）清除删除、过期、多余版本的数据。由于HBase所有写入的数据都是不可修改的，所以对数据的修改操作就是添加一条新的记录，原数据仍保存在StoreFile中；而删除操作是添加一个删除的标识。Compaction操作可以整合这些信息，减少磁盘空间的占用。 3）提高读写数据的效率。

pom文件中有google的guava依赖吧？或者其他地方引用到了。这个问题就是guava冲突了，版本不一致，hbase中也有guava

时间戳；时间邮票。时间戳（Timestamp）：用于标识媒体数据的采样时间，以打包数据采样第 一个字节数据的时刻记录了该包中数据的第一个字节的采样时刻。

1、首先你有没有那么多台服务器的集群，如果只是几台，你要想够不够，你的hbase 有几百亿，那么你hdfs上的数据可能要有两个备份，你这几百亿条是如何生成的，肯定是mapreduce跑出来导入到hbase中把，那么原始数据你要不要留，如果留，加上备份就要三份，所以节点的多少要确定。2、几百亿其实挺多的，hbase 的设计一定要跟你的业务相关，hbase他不能完全像关系型数据库那样去随意查询，到达一定量级，如果设计的不好也是非常之慢的，甚至将hbase搞到崩溃。所以你先去网上看看rowkey的设计原则，比如长度原则等等，然后根据自己业务，哪些查询经常用到，哪些不会用到，想要用hbase实现那种非常灵活的类似关系数据库的查询是不理智的。3、楼上的兄弟说得对，还有region热点的问题，如果你的hbase数据不是那种每天增量的数据，建议跑个mapreduce对你的数据进行各评判，看看如何能将数据尽可能均匀的分配到每个region中，当然这需要预先分配region4、几百亿条数据，如果对rowkey进行模糊过滤一定非常非常之慢，所以可以考虑二级索引或者协处理器

对于hbase当前noSql数据库的一种，最常见的应用场景就是采集的网页数据的存储，由于是key-value型数据库，可以再扩展到各种key-value应用场景，如日志信息的存储，对于内容信息不需要完全结构化出来的类CMS应用等。注意hbase针对的仍然是OLTP应用为主。对于hive主要针对的是OLAP应用，注意其底层不是hbase，而是hdfs分布式文件系统，重点是基于一个统一的查询分析层，支撑OLAP应用中的各种关联，分组，聚合类SQL语句。hive一般只用于查询分析统计，而不能是常见的CUD操作，要知道HIVE是需要从已有的数据库或日志进行同步最终入到hdfs文件系统中，当前要做到增量实时同步都相当困难。和mysql,oracle完全不是相同的应用场景。这个是结构化数据库，针对的更多的是结构化，事务一致性要求高，业务规则逻辑复杂，数据模型复杂的企业信息化类应用等。包括互联网应用中的很多业务系统也需要通过结构化数据库来实现。所以和hbase,hive不是一个层面的东西，不比较。

对于hbase当前noSql数据库的一种，最常见的应用场景就是采集的网页数据的存储，由于是key-value型数据库，可以再扩展到各种key-value应用场景，如日志信息的存储，对于内容信息不需要完全结构化出来的类CMS应用等。注意hbase针对的仍然是OLTP应用为主。对于hive主要针对的是OLAP应用，注意其底层不是hbase，而是hdfs分布式文件系统，重点是基于一个统一的查询分析层，支撑OLAP应用中的各种关联，分组，聚合类SQL语句。hive一般只用于查询分析统计，而不能是常见的CUD操作，要知道HIVE是需要从已有的数据库或日志进行同步最终入到hdfs文件系统中，当前要做到增量实时同步都相当困难。和mysql,oracle完全不是相同的应用场景。这个是结构化数据库，针对的更多的是结构化，事务一致性要求高，业务规则逻辑复杂，数据模型复杂的企业信息化类应用等。包括互联网应用中的很多业务系统也需要通过结构化数据库来实现。所以和hbase,hive不是一个层面的东西，不比较。

1、hbase的核心数据结构为LSM树。LSM树分为内存部分和磁盘部分。内存部分是一个维护有序数据集合的数据结构。2、RowKey与nosql数据库们一样，RowKey是用来检索记录的主键。3、HBase是介于MapEntry(key&value)和DBRow之间的一种数据存储方式。4、hbase使用的是jdk提供的ConcurrentSkipListMap，并对其进行了的封装，Map结构是KeyValue，KeyValue的形式。Concurrent表示线程安全。5、而HBase中的数据存储是基于列族（columnfamily）和行键（rowkey）的，HBase的数据存储结构是按行键排序的有序映射表，可以通过行键的前缀匹配来检索数据。

看报错应该是缺少zookeeper依赖jar包，看一下hadoop使用的zookeeper版本和hbase使用的是否版本一致。或者hbase使用的是不是内置的zookeeper

Region是HBase数据存储和管理的基本单位。一个表中可以包含一个或多个Region。每个Region只能被一个RS（RegionServer）提供服务，RS可以同时服务多个Region，来自不同RS上的Region组合成表格的整体逻辑视图。

HBaseAdmin提供compact方法来手动合并小文件 public void compact(final byte [] tableNameOrRegionName) public void majorCompact(final byte [] tableNameOrRegionName)majorCompact会对所有的文件进行Compact，而compact会选取合适的进行compact