hbase写数据过程

标签: hbase 数据 | 发表时间:2013-11-29 00:10 | 作者:无尘道长
出处:http://www.iteye.com

博文说明:1、研究版本hbase0.94.12;2、贴出的源代码可能会有删减,只保留关键的代码

 

从client和server两个方面探讨hbase的写数据过程。

一、client端

 

1、写数据API

    写数据主要是HTable的单条写和批量写两个API,源码如下:

// 单条写API

public void put( final Put put) throws IOException {

    doPut(put);

    if (autoFlush) {

      flushCommits();

    }

  }

//批量写API

public void put( final List<Put> puts) throws IOException {

    for (Put put : puts) {

      doPut(put);

    }

    if (autoFlush) {

      flushCommits();

    }

  }

//具体的put实现

private void doPut(Put put) throws IOException{

    validatePut(put);

    writeBuffer.add(put);

    currentWriteBufferSize += put.heapSize();

    if (currentWriteBufferSize > writeBufferSize) {

      flushCommits();

    }

  }

public void close() throws IOException {

    if ( this.closed) {

      return;

    }

    flushCommits();

    ….

  }

    通过两个put API可以看出如果autoFlush为false,则无论是否是批量写效果均是相同,均是等待写入的数据超过配置的writeBufferSize(通过hbase.client.write.buffer配置,默认为2M)时才提交写数据请求,如果最后的写入数据没有超过2M,则在调用close方法时会进行最后的提交,当然,如果使用批量的put方法时,自己控制flushCommits则效果不同,比如每隔1000条进行一次提交,如果1000条数据的总大小超过了2M,则实际上会发生多次提交,导致最终的提交次数多过只由writeBufferSize控制的提交次数,因此在实际的项目中,使用单条写的put( final Put put)API即可,这样即可以简化写操作数据的程序代码,写入效率也更优。

 

2、关于多线程写

在0.94.12这个版本中,对于写操作,hbase内部就是多线程,线程数量与批量提交的数据涉及的region个数相同,通常情况下不需要再自己写多线程代码,自己写的多线程代码主要是解决数据到HTable的put这个过程中的性能问题,数据进入put的缓存,当达到writeBufferSize设定的大小后才会真正发起写操作(如果不是自己控制flush),这个过程的线程数与这批数据涉及的region个数相同,会并行写入所有相关region,一般不会出现性能问题,当涉及的region个数过多时会导致创建过多的线程,消耗大量的内存,甚至会出现线程把内存耗尽而导致OutOfMemory的情况,比较理想的写入场景是调大writeBufferSize,并且一次写入适量的不同regionserver的region,这样可以充分把写压力分摊到多个服务器。

hbase写数据的客户端核心方法是HConnectionManager的processBatchCallback方法,相关源码如下:

public void flushCommits() throws IOException {

    try {

      Object[] results = new Object[writeBuffer.size()];

       try {

        this.connection.processBatch(writeBuffer, tableName, pool, results);

      } catch (InterruptedException e) {

        throw new IOException(e);

      } finally {

       

    } finally {

     

    }

  }

 

public void processBatch(List<? extends Row> list, final byte[] tableName, ExecutorService pool,

        Object[] results) throws IOException, InterruptedException {

      …

      processBatchCallback(list, tableName, pool, results, null);

    }

 

public <R> void processBatchCallback(List<? extends Row> list, byte[] tableName, ExecutorService pool,

        Object[] results, Batch.Callback<R> callback) throws IOException, InterruptedException {

      ….

      HRegionLocation [] lastServers = new HRegionLocation[results.length];

      for ( int tries = 0; tries < numRetries && retry; ++tries) {

        // step 1: break up into regionserver-sized chunks and build the data structs

        Map<HRegionLocation, MultiAction<R>> actionsByServer =

          new HashMap<HRegionLocation, MultiAction<R>>();

for ( int i = 0; i < workingList.size(); i++) {

          Row row = workingList.get(i);

          if (row != null) {

            HRegionLocation loc = locateRegion(tableName, row.getRow());

            byte[] regionName = loc.getRegionInfo().getRegionName();

            MultiAction<R> actions = actionsByServer.get(loc);

            if (actions == null) {

              actions = new MultiAction<R>();

              actionsByServer.put(loc, actions);  //每一个region对应一个MultiAction对象,每个MultiAction对象持有该region所有的put Action

            }

            Action<R> action = new Action<R>(row, i);

            lastServers[i] = loc;

            actions.add(regionName, action);

          }

        }

 

        // step 2: make the requests ,每个region 开启一个线程

        Map<HRegionLocation, Future<MultiResponse>> futures =

            new HashMap<HRegionLocation, Future<MultiResponse>>(actionsByServer.size());

        for (Entry<HRegionLocation, MultiAction<R>> e: actionsByServer.entrySet()) {

          futures.put(e.getKey(), pool.submit(createCallable(e.getKey(), e.getValue(), tableName)));

        }

 

        // step 3: collect the failures and successes and prepare for retry

        …

        // step 4: identify failures and prep for a retry (if applicable).

        …

}

}

 

3、在写入数据前,需要先定位具体的数据应该写入的region,核心方法:

// 从缓存中定位region,通过NavigableMap实现,如果没有缓存则需查询.META.表

HRegionLocation getCachedLocation( final byte [] tableName,

        final byte [] row) {

      SoftValueSortedMap< byte [], HRegionLocation> tableLocations =

        getTableLocations(tableName);

      …

      // 找到小于 rowKey 并且最接近rowKey startKey 对应 的region ,通过NavigableMap 实现

      possibleRegion = tableLocations.lowerValueByKey(row);

      if (possibleRegion == null) {

        return null;

      }

      // 表的最末一个region的endKey是空字符串,如果不是最末一个region,则只有当rowKey小于endKey才返回region。

      byte[] endKey = possibleRegion.getRegionInfo().getEndKey();

      if (Bytes. equals(endKey, HConstants. EMPTY_END_ROW) ||

          KeyValue. getRowComparator(tableName).compareRows(

              endKey, 0, endKey.length, row, 0, row.length) > 0) {

        return possibleRegion;

      }

      return null;

}

 

 二、服务端

    服务端写数据的主要过程是:写WAL日志(如果没有关闭写WAL日志)-》写memstore-》触发flush memstore(如果memstore大小超过hbase.hregion.memstore.flush.size的设置值),在flush memstore过程中可能会触发compact操作,在以下内容会对写put方法、flush memstore和compact进行讲解。

 

1、HTableInterface接口操作hbase数据的API对应的服务端是由HRegionServer类实现,源代码如下:

 

//单条put

public void put( final byte[] regionName, final Put put) throws IOException {

    HRegion region = getRegion(regionName);

if (!region.getRegionInfo().isMetaTable()) {

// 检查HRegionServer的memstore总内存占用量是否已经超过了hbase.regionserver.global.memstore.upperLimit(默认值是0.4)或者hbase.regionserver.global.memstore.lowerLimit(默认值是0.35)的限制,如果超过了则会在flush队列中添加一个任务,其中如果是超过了upper的限制则会阻塞所有的写memstore的操作,直到内存降至lower限制以下。

       this.cacheFlusher.reclaimMemStoreMemory();

    }

boolean writeToWAL = put.getWriteToWAL();

//region会调用Store的add()方法把数据保存到相关Store的memstore中

//region在保存完数据后,会检查是否需要flush memstore,如果需要则发出flush请求,由HRegionServer的flush守护线程异步执行。

    region.put(put, getLockFromId(put.getLockId()), writeToWAL);

  }

// 批量put

public int put( final byte[] regionName, final List<Put> puts) throws IOException {

    region = getRegion(regionName);

    if (!region.getRegionInfo().isMetaTable()) {

       this.cacheFlusher.reclaimMemStoreMemory();

    }

   OperationStatus codes[] = region.batchMutate(putsWithLocks);

    for (i = 0; i < codes.length; i++) {

        if (codes[i].getOperationStatusCode() != OperationStatusCode. SUCCESS) {

          return i;

        }

     }

     return -1;

  }

 

2、Flush Memstore

    memstore的flush过程由类MemStoreFlusher控制,该类是Runnable的实现类,在HRegionServer启动时会启动一个MemStoreFlusher的守护线程,每隔10s从flushQueue中获取flush任务进行刷新,如果需要flush memstore时,只需调用MemStoreFlusher的requestFlush或者requestDelayedFlush方法把flush请求加入到flush队列中即可,具体的flush是异步执行的。

    memstore的大小有两个控制级别:

    1)Region级

    a、hbase.hregion.memstore.flush.size:默认值128M,超过将被flush到磁盘

    b、hbase.hregion.memstore.block.multiplier:默认值2,如果memstore的内存大小已经超过了hbase.hregion.memstore.flush.size的2倍,则会阻塞该region的写操作,直到内存大小降至该值以下

  2)RegionServer级

   a、hbase.regionserver.global.memstore.lowerLimit:默认值0.35,HRegionServer的所有memstore占用内存在HRegionServer总内存中占的lower比例,当达到该值,则会触发整个RegionServer的flush(并不会真正flush所有的region,关于该点请参看后续内容),直到总内存比例降至该数限制以下

   b、hbase.regionserver.global.memstore.upperLimit:默认值0.4,HRegionServer的所有memstore占用内存在总内存中的upper比例,当达到该值,则会触发整个RegionServer的flush,直到总内存比例降至该数限制以下,并且在降至限制比例以下前将阻塞所有的写memstore的操作

  在对整个HRegionServer进行flush操作时,并不会刷新所有的region,而是每次均会根据region的memstore大小、storeFile数量等因素找出最需要flush的region进行flush,flush完成后再进行内存总比例的判断,如果还未降至lower限制以下则会再寻找新的region进行flush。

  在flush region时会flush该region下所有的store,虽然可能某些store的memstore内容很少。

  在flush memstore时会产生updatesLock(HRegion类的一个属性,采用jdk的ReentrantReadWriteLock实现)的排它锁write lock,当获取完memstore的快照后释放updatesLock的write lock,在释放之前,所有的需要获取updatesLock的write、read lock的操作均会被阻塞,该影响是整个HRegion范围,因此如果表的HRegion数量过少,或者数据写入时热点在一个region时会导致该region不断flush memstore,由于该过程会产生write排他锁(虽然进行memstore快照的时间会很快),因此会影响region 的整体写能力。

 

3、Compact操作

  hbase有两种compact:minor和major,minor通常会把若干个小的storeFile合并成一个大的storeFile,minor不会删除标示为删除的数据和过期的数据,major则会删除这些数据,major合并之后,一个store只有一个storeFile文件,这个过程对store的所有数据进行重写,有较大的资源开销,major 合并默认1天执行一次,可以通过 hbase.hregion.majorcompaction配置执行周期,通常是把该值设置为0进行关闭,采用手工执行,这样可以避免当集群繁忙时执行整个集群的major合并,major合并是必须执行的操作,因为删除标示为删除和过期的数据操作是在该合并过程中进行的。通过merge可以对表的两个region进行合并,以减少region的数量,执行命令:

    $ bin/hbase org.apache.hadoop.hbase.util.Merge <tablename> <region1> <region2>

    参数<region1>需要写region的名称,比如:
    gd500M,4-605-52-78641,1384227418983.ccf74696ef8a241088356039a65e1aca

    执行该操作时需要先停止运行hbase集群,并且如果hdfs不是与hbase拥有相同的用户组和用户且hdfs配置为需要进行权限控制(由配置项dfs.permissions控制,默认为true)时需要切换linux用户到hdfs用户下执行该操作,执行完成后,需要通过hadoop dfs –chown 命令把合并后产生的新region的用户修改为hbase的用户,否则会导致启动hbase后管理界面看不到任何表等问题,如图,新合成后的region在hdfs中的存放路径信息:

    由上图可见,表gd500M的新region的用户是hdfs,执行如下命令,修改所属用户,注意最好是对hbase根目录进行用户改变,因为不只是新region的用户是hdfs,还有一些在merge过程中形成的日志文件等也会是hdfs用户

    修改后查看新region的用户信息,已经改为hbase:


 
    compact合并的级别

    1)、整个hbase集群

在HRegionServer启动时会开启一个守护线程定时扫描集群下的所有在线的region下的storeFile文件,对所有符合 Store.needsCompaction()或 Store.isMajorCompaction()的store进行合并操作,默认周期是10000秒(大概2.7小时),其中如果 hbase.hregion.majorcompaction配置为0则该守护线程永远也不会触发major合并 源代码如下:

// threadWakeFrequency 默认值是10*1000 multiplier 默认值是1000 ,单位:毫秒

this.compactionChecker = new CompactionChecker(this, this.threadWakeFrequency * multiplier, this);

 

//chore是CompactionChecker定时执行的方法,定时进行minor和major的compcat合并,如果hbase.hregion.majorcompaction配置为0则不执行major合并,minor升级为major除外。

protected void chore() {

      for (HRegion r : this.instance.onlineRegions.values()) {

        if (r == null)

          continue;

        for (Store s : r.getStores().values()) {

          try {

            if ( s.needsCompaction()) {

              // 如果整个store 下的storeFile 文件均需要合并,则会自动升级到major 合并

              this.instance.compactSplitThread.requestCompaction(r, s, getName()

                  + " requests compaction", null);

            } else if (s.isMajorCompaction()) {

              if (majorCompactPriority == DEFAULT_PRIORITY

                  || majorCompactPriority > r.getCompactPriority()) {

                this.instance.compactSplitThread.requestCompaction(r, s, getName()

                    + " requests major compaction; use default priority", null);

              } else {

                this.instance.compactSplitThread.requestCompaction(r, s, getName()

                    + " requests major compaction; use configured priority",

                  this.majorCompactPriority, null);

              }

            }

          } catch (IOException e) {

            LOG.warn("Failed major compaction check on " + r, e);

          }

        }

      }

}

 

// store 内除去正在执行compact 的storeFile 后剩余的storeFile 数如果大于配置的最小可合并数,则可以进行compact 合并,最小的可合并数通过hbase.hstore.compactionThreshold 配置,默认是3 ,最小值为2

public boolean needsCompaction() {

    return (storefiles.size() - filesCompacting.size()) > minFilesToCompact;

}

 

// 是否是major 合并

private boolean isMajorCompaction(final List<StoreFile> filesToCompact) throws IOException {

boolean result = false;

// 根据hbase.hregion.majorcompaction 配置的major 合并周期计算下次进行major 合并的时间,如果设置为0则不进行major合并

long mcTime = getNextMajorCompactTime();

if (filesToCompact == null || filesToCompact.isEmpty() || mcTime == 0) {

      return result;

    }

// TODO: Use better method for determining stamp of last major (HBASE-2990)

// store中最久没有被修改过的 storeFile文件的 时间,作为上次major合并的时间进行判断下次应该进行major合并的时间,这种做法并不合理,可能会导致延后执行major 合并,极端情况下会导致永远不进行major 合并。

    long lowTimestamp = getLowestTimestamp(filesToCompact);

    long now = System. currentTimeMillis();

    // 只有当达到了major 合并时间才可能进行major 合并

    if (lowTimestamp > 0l && lowTimestamp < (now - mcTime)) { 

      // Major compaction time has elapsed.

      if (filesToCompact.size() == 1) {

        StoreFile sf = filesToCompact.get(0);

        // store 中最久的时间与当前时间的时间差

        long oldest = (sf.getReader().timeRangeTracker == null) ?

                Long. MIN_VALUE :

                now - sf.getReader().timeRangeTracker.minimumTimestamp;

        if (sf.isMajorCompaction() && ( this.ttl == HConstants. FOREVER || oldest < this.ttl)) {

          //如果 列簇没有设置过期时间( 通过HColumnDescriptor.setTimeToLive() 设置) ,因此无需通过major 合并删除过期数据。

          }

        } else if ( this.ttl != HConstants. FOREVER && oldest > this.ttl) {

            result = true;

        }

      } else {

        result = true;

      }

    }

    return result;

  }

        

    2) 、表级

   通过HBaseAdmin或者CompactionTool可以触发表下的所有region和列簇进行compact合并(minor或者major)。HBaseAdmin还可以触发表下的指定列簇的compact操作。

       

    3)、region级

    通过HBaseAdmin或者CompactionTool可触发对指定region下的所有列簇进行compact操作(minor或者major)。HBaseAdmin还可以触发region下的指定列簇的compact操作。

   通过Merge工具可以把给定表下的任意两个region合并成一个region,在合并region前会触发region的major compact操作。

  在flush memstore过程中会触发当前region的compact,写数据或者split region等会触发flush memstore。

    

  4)、列簇级(Store级)

  有很多情况均会触发Store的compact,比如:执行CompactionTool工具的compact方式、flush memstore等。

  注:以上4条只是指触发compact操作,但是不一定真正发生compact,还需满足needsCompaction()或者isMajorCompaction()的条件。

compact总结:

  1)、从compact的程度可以分为:minor和major合并;  

  2)、从发生的范围可以分:整个集群、表、region、列簇4个级别;

  3)、从触发的方式上可以分:

a、hbase内部自动触发(HRegionServer的定时器、flush memstore等)

b、客户端等外部触发(hbase管理工具、HBaseAdmin(client端管理类)、CompactionTool等)

 

  Compact的执行逻辑如下:

//CompactSplitThread类,只由HRegionServer类持有,在以下几个地方被调用:

//1、HRegionServer的compact守护线程

//2、MemStoreFlusher的flushRegion

//3、CompactingRequest的run方法

public synchronized CompactionRequest requestCompaction(final HRegion r, final Store s,

      final String why, int priority, CompactionRequest request) throws IOException {

    CompactionRequest cr = s.requestCompaction(priority, request);

      cr.setServer(server);

// 是否是large合并,只与参与合并的文件的总大小有关,超过一定值后就会通过large合并的线程池,

//注意与major合并的区别,large线程池执行的任务可能是一个minor合并也可能是major合并。

//默认的large和small线程数是1,可以通过hbase.regionserver.thread.compaction.large和hbase.regionserver.thread.compaction.small配置

ThreadPoolExecutor pool = s.throttleCompaction(cr.getSize())? largeCompactions : smallCompactions;

      pool.execute(cr);

    return cr;

  }

 

// Store

public CompactionRequest requestCompaction( int priority, CompactionRequest request)

      throws IOException {

   …

    this.lock.readLock().lock();

    try {

      synchronized (filesCompacting) {

        // candidates = all storefiles not already in compaction queue

        List<StoreFile> candidates = Lists. newArrayList(storefiles);

        if (!filesCompacting.isEmpty()) {

          // exclude all files older than the newest file we're currently

          // compacting. this allows us to preserve contiguity (HBASE-2856)

          StoreFile last = filesCompacting.get(filesCompacting.size() - 1);

          int idx = candidates.indexOf(last);

          Preconditions. checkArgument(idx != -1);

          candidates.subList(0, idx + 1).clear();

        }

 

        boolean override = false;

        if (region.getCoprocessorHost() != null) {

          override = region.getCoprocessorHost().preCompactSelection( this, candidates, request);

        }

        CompactSelection filesToCompact;

        if (override) {

          // coprocessor is overriding normal file selection

          filesToCompact = new CompactSelection(conf, candidates);

        } else {

          filesToCompact = compactSelection(candidates, priority);

        }

 

        if (region.getCoprocessorHost() != null) {

          region.getCoprocessorHost().postCompactSelection( this,

            ImmutableList. copyOf(filesToCompact.getFilesToCompact()), request);

        }

 

        // no files to compact

        if (filesToCompact.getFilesToCompact().isEmpty()) {

          return null;

        }

 

        // basic sanity check: do not try to compact the same StoreFile twice.

        if (!Collections. disjoint(filesCompacting, filesToCompact.getFilesToCompact())) {

          // TODO: change this from an IAE to LOG.error after sufficient testing

          Preconditions. checkArgument( false, "%s overlaps with %s",

              filesToCompact, filesCompacting);

        }

        filesCompacting.addAll(filesToCompact.getFilesToCompact());

        Collections. sort(filesCompacting, StoreFile.Comparators. FLUSH_TIME);

 

        // major compaction iff all StoreFiles are included

        boolean isMajor = (filesToCompact.getFilesToCompact().size() == this.storefiles.size());

        if (isMajor) {

          // since we're enqueuing a major, update the compaction wait interval

          this.forceMajor = false;

        }

 

        // everything went better than expected. create a compaction request

        int pri = getCompactPriority(priority);

        //not a special compaction request, so we need to make one

        if(request == null){

          request = new CompactionRequest(region, this, filesToCompact, isMajor, pri);

        } else {

          // update the request with what the system thinks the request should be

          // its up to the request if it wants to listen

          request.setSelection(filesToCompact);

          request.setIsMajor(isMajor);

          request.setPriority(pri);

        }

      }

    } finally {

      this.lock.readLock().unlock();

    }

    if (request != null) {

      CompactionRequest. preRequest(request);

    }

    return request;

  }

 

// 如果合并的总文件大小超过2 * this.minFilesToCompact * this.region.memstoreFlushSize则会通过大合并的线程池进行合并,总共有两个合并的线程池

ThreadPoolExecutor pool = s.throttleCompaction(cr.getSize())? largeCompactions : smallCompactions;

 

// minFilesToCompact默认值为3, memstoreFlushSize默认值128M

boolean throttleCompaction( long compactionSize) {

    long throttlePoint = conf.getLong(

        "hbase.regionserver.thread.compaction.throttle",

        2 * this.minFilesToCompact * this.region.memstoreFlushSize);

    return compactionSize > throttlePoint;

  }

 

 

 

 

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [hbase 数据] 推荐:

HBASE数据架构

- - 数据库 - ITeye博客
关系数据库一般用B+树,HBASE用的是LSM树. MYSQL所用类B+树一般深度不超过3层,数据单独存放,在B+树的叶节点存储指向实际数据的指针,叶节点之间也相互关联,类似双向链表. 这种结构的特点是数据更新或写入导致数据页表分散,不利于顺序访问. LSM存储中,各个文件的结构类似于B+树,但是分多个存在内存或磁盘中,更新和写入变成了磁盘的顺序写,只在合并时去掉重复或过时的数据.

hbase写数据过程

- - 数据库 - ITeye博客
博文说明:1、研究版本hbase0.94.12;2、贴出的源代码可能会有删减,只保留关键的代码. 从client和server两个方面探讨hbase的写数据过程.     写数据主要是HTable的单条写和批量写两个API,源码如下:. hbase写数据的客户端核心方法是HConnectionManager的processBatchCallback方法,相关源码如下:.

HBase数据查询之Coprocessor

- - 开源软件 - ITeye博客
协处理器的概念、作用和类型不介绍,可以参看:http://www.cnblogs.com/ventlam/archive/2012/10/30/2747024.html,官方blog:https://blogs.apache.org/hbase/entry/coprocessor_introduction.

从hbase(hive)将数据导出到mysql

- - CSDN博客云计算推荐文章
在上一篇文章《 用sqoop进行mysql和hdfs系统间的数据互导》中,提到sqoop可以让RDBMS和HDFS之间互导数据,并且也支持从mysql中导入到HBase,但从HBase直接导入mysql则不是直接支持,而是间接支持. 要么将HBase导出到HDFS平面文件,要么将其导出到Hive中,再导出到mysql.

通过HBase Observer同步数据到ElasticSearch

- - SegmentFault 最新的文章
Observer希望解决的问题. HBase是一个分布式的存储体系,数据按照RowKey分成不同的Region,再分配给RegionServer管理. 但是RegionServer只承担了存储的功能,如果Region能拥有一部分的计算能力,从而实现一个HBase框架上的MapReduce,那HBase的操作性能将进一步提升.

HBase基本数据操作详解

- - 互联网 - ITeye博客
之前详细写了一篇HBase过滤器的文章,今天把基础的表和数据相关操作补上. 本文档 参考最新 (截止2014年7月16日)的 官方 Ref Guide、 Developer API编写. 所有代码均基于“hbase  0.96.2-hadoop2 ”版本编写,均实测通过. 对于建表,和RDBMS类似,HBase也有namespace的概念,可以指定表空间创建表,也可以直接创建表,进入default表空间.

JAVA操作HBASE数据操作详解

- -
Hbase对于建表,和RDBMS类似,HBase也有namespace的概念,可以指定表空间创建表,也可以直接创建表,进入default表空间. 对于数据操作,HBase支持四类主要的数据操作,分别是:. Put :增加一行,修改一行;. Delete :删除一行,删除指定列族,删除指定column的多个版本,删除指定column的制定版本等;.

两次hbase丢失数据的故障及原因分析

- gengmao - 蓝色时分
    hbase的稳定性是近期社区的重要关注点,毕竟稳定的系统才能被推广开来,这里有几次稳定性故障和大家分享.     第一次生产故障的现象及原因. 1 hbase发现无法写入 2 通过hbck检测发现.META.表中出现空洞,具体log是:;Chain of regions in table.     修复方法:直接使用check_meta.rb重新生成.META.表并修补空洞,但是会引起数据丢失.

java实现hbase表创建、数据插入、删除表

- - 学着站在巨人的肩膀上
近日查看了相关资料后,梳理了一下用java实现hbase的表创建、数据插入、删除表,代码如下:. 类别: Hadoop  查看评论.

HBase – 基于Hadoop的分布式数据库

- - ITeye博客
  修改:dataDir=/home/ysc/zookeeper. mkdir /home/ysc/zookeeper(注:dataDir是zookeeper的数据目录,需要手动创建). hbase存在系统时间同步的问题,并且误差要再30s以内. HBase是数据库,会在同一时间使用很多的文件句柄,大多数linux系统使用的默认值1024是不能满足的,还需要修改 hbase 用户的nproc,在压力很大的情况下,如果过低会造成 OutOfMemoryError异常.