kf_panda

HBase put数据时会先将数据写入内存，其内存结构是一个ConcurrentSkipListMap，其Comparator是KVComparator。 keyvalue对象结构 KVComparator的KeyValue对象比较过程 1.使用KeyComparator比较rowkey，结果是rowkey字节序从小到大 2.如果rowkey一样，则按column

LSM树是HBase里非常有创意的一种数据结构，它和传统的B+树不太一样，下面先说说B+树。 1 B+树 相信大家对B+树已经非常的熟悉，比如Oracle的普通索引就是采用B+树的方式，下面是一个B+树的例子： 根节点和枝节点很简单，分别记录每个叶子节点的最小值，并用一个指针指向叶子节点。 叶子节点里每个键值都指向真正的数据块（如Oracle里的Ro

定制LoadBalancer插件需要两个步骤： 1、继承org.apache.hadoop.hbase.master.LoadBalancer Interface，实现自己的LoadBalancer Class。 2、在hbase-site.xml中增加配置项，使得定制的LoadBalancer生效 hbase.master.loadbalancer.class {your custom

Hadoop常常被用作大型数据处理生态系统中的一部分。它的优势在于能够批量地处理大量数据，并将结果以最好的方式与其他系统相集成。从高层次角度来看，整个过程就是Hadoop接收输入文件、使用自定义转换（Map-Reduce步骤）获得内容流，以及将输出文件的结果写回磁盘。上个月InfoQ展示了怎样在第一个步骤中，使用InputFormat类来更好地对接收输入文件进行控制。而在本文中，我们将同大家一起探

1. 发起 hbase split 1.1 HBaseAdmin.split /** * Split a table or an individual region. * Asynchronous operation. * * @param tableNameOrRegionName table to region to split * @param spli

1. HMaster中有个main方法,这是HMaster启动的开始的地方 /** * @see org.apache.hadoop.hbase.master.HMasterCommandLine */ public static void main(String [] args) { VersionInfo.logVersion(); new HMaster

HBase 0.94之前版本中，split使用的是ConstantSizeRegionSplitPolicy。当region中文件大小超过配置中所指定大小时，会进行切分。 而在0.94版本之后，默认split策略修改为了IncreasingToUpperBoundRegionSplitPolicy。该策略使用了另一种方法来计算是否应当切割，导致原先的参数失效。 该方法中的分配策略，是根

hindex在源码中关于split的修改部分 1、CompactSplitThread.requestSplit 如果是索引表直接退出 public synchronized void requestSplit(final HRegion r, byte[] midKey) { if (midKey == null) { LOG.debug("Region " +

以网上的一个学生成绩表的例子来演示hbase的用法。 name grad course math art Tom 5 97 87 Jim 4 89 80 这里grad对于表来说是一个只有它自己的列族,course对于表来说是一个有两个列的列族,这个列族由两个列组成math

key:   Row Length(2B) + Row + Column Family Length(1B) + Column Family + Column Qualifier + TimeStamp(8B) + KeyType(1B)       bytes:   if(tagsLength == 0) keylength(4B) + valuelength(4B) + key +

在今年的北京QCon大会上，360公司的系统部技术经理赵健博在演讲中公布了360公司的HBase二级索引方案，这一方案的提出将比华为HBase二级索引更好的解决了Hbase的多维实时查询问题。它的核心思想是保证了索引和数据在同一region上，减少了IO通信，提升了HBase的读性能，并且无非修改HBase源码，实现更加简单。 360HBase二级索引公布的演讲视频：http://www.i

1、查询   客户端并行的向表的所有region发一个请求，然后每个region在server端会对数据进行检索和查询以及数据获取并把最终结果返回给客户端。客户端获取到各个region上检索的结果之后，会对结果进行合并和排序。 2、建索引   客户端把请求发给各个region，各个region根据索引说明构建好索引，并将索引存储进去。 整体的过程都是分布式和并发式的构建。 3、采

HMaster类中与balance相关部分 1、初始化 //balancer作为HMaster的一个成员变量 LoadBalancer balancer; //ClusterStatusChore 这个会定时去执行balancer private ClusterStatusChore clusterStatusChore; //在HMaster的initializeZKBased

HBASE优化、维护相关 一、性能优化  1.、垃圾回收优化 由于master负载通常比较轻，所以一般考虑region服务器启动参数。写负载高的情况下，memstore在不同时期创建各种不同大小的对象。memstore会保存缓冲区中的数据直到超过hbase.hregion.memstore.flush.size（建表时可以针对每个表指定这个参数）配置的大小才会刷写（或者客户端调用flushC

hbase 版本 0.98.3 HBase 可以根据当前集群的负载以region为单位进行rebalance。在HMaster中，后台会起一个线程定期检查是否需要进行rebalance，线程叫做BalancerChore。线程每隔 hbase.balancer.period会定期执行 master.balance()函数，配置项默认300000毫秒，5分钟。每次balance最多执行 hb

创建表 Here is some help for this command: Creates a table. Pass a table name, and a set of column family specifications (at least one), and, optionally, table configuration. Column specification can be

ResultScanner类 扫描操作不会通过一次RPC请求返回所有匹配的行，而是以行为单位进行返回。很明显，行的数目很大，可能有上千条甚至更多，同时在一次请求中发送大量数据，会占用大量的系统资源并消耗很长时间。 ResultScanner把扫描操作转换为类似的get操作，它将每一行数据封装成一个Result实例，并将所有的Result实例放入一个迭代器中。ResultScanner的

package test; import java.io.IOException; import java.util.ArrayList; import java.util.List; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.Path; import org.apache.hadoop

我们先看HConnection的getTable方法描述： getTable HTableInterface getTable(String tableName) throws IOException Retrieve an HTableInterface implementation for access to a table.

如果要统对hbase中的数据，进行某种统计，比如统计某个字段最大值，统计满足某种条件的记录数，统计各种记录特点，并按照记录特点分类（类似于sql的group by）~ 常规的做法就是把hbase中整个表的数据scan出来，或者稍微环保一点，加一个filter，进行一些初步的过滤（对于rowcounter来说，就加了FirstKeyOnlyFilter），但是这么做来说还是会有很大的副作用，比

http://www.boyunjian.com/javadoc/org.apache.servicemix.bundles/org.apache.servicemix.bundles.hbase/0.95.0_1/_/org/apache/hadoop/hbase/KeyValue.html

在管理集群时，最容易导致hbase节点发生故障的恐怕就是hbase region split和compact的了，日志有split时间太长；文件找不到；split的时候response too slow等等，所以先看看hbase region split源码，希望对以后能有帮助   HBase region split源码分析 一、流程概述 1.HBaseAdmin 发起

hadoop common 下的两个类 InterfaceAudience ，InterfaceStability ； InterfaceAudience 有三个抽象方法，主要用于说明使用的范围 /**    * Intended for use by any project or application. 在任何项目或应用中可使用    */ @InterfaceA

1、RegionServer决定本地的region分裂，并准备分裂工作。第一步是，在zookeeper的/hbase/region-in-reansition/region-name下创建一个znode，并设为SPLITTING状态。 2、Master通过父region-in-transition znode的watcher监测到刚刚创建的znode。 3、RegionServer在H

在HBase中，大部分的操作都是在RegionServer完成的，Client端想要插入，删除，查询数据都需要先找到相应的RegionServer。什么叫相应的RegionServer？就是管理你要操作的那个Region的RegionServer。Client本身并不知道哪个RegionServer管理哪个Region，那么它是如何找到相应的RegionServer的？本文就是在研究源码的基础上揭

今天测试用hbaseadmin.split手动对region进行拆分，拆分完之后，并没有和我想的那样region均衡分布到3个regionserver上去。感觉很莫名，说好的balancer呢，怎么不起作用，于是我手工执行了一下hbaseadmin.balancer(),还是没效果。尼玛！ 把源码翻开了看终于发现了原因： banancer是针对整个集群的region分布，而不是针对某个

HBase Compaction策略 RegionServer这种类LSM存储引擎需要不断的进行Compaction来减少磁盘上数据文件的个数和删除无用的数据从而保证读性能。 RegionServer后台有一组负责flush region的线程(MemStoreFlusher)，每次从flushQueue中拿出一个flush region请求，会检查这个region是否有某个sto

1 hbase-server ： SplitTransactionImpl 类添加 SplitInfo 内部类 2 hbase-server ： RegionCoprocessorHost 中添加 public SplitInfo preSplitBeforePONR(byte[] splitKey) 方法 3 hbase-server ： RegionObserver 接口中添加 Split