最近在线上往hbase导数据，因为hbase写入能力比较强，没有太在意写的问题。让业务方进行历史数据的导入操作，中间发现一个问题，写入速度太快，并且业务数据集中到其中一个region，这个region无法split掉，处于不可用状态。这里描述一整个过程—— 事情的起因：业务方按照use
目录1.HBase写入数据流程2.疑问2.1上述（8）中，数据写入到HLog时，实际上在这个时刻只是写入文件系统的缓存中，并没有真正的落地到磁盘中，那什么时候落地到磁盘中呢？1.HBase写入数据流程（1）Client向服务端发起Put请求。默认情况下，autoflush=true，所以每发送一个Put请求，就会直接发送到服务端。当autoflush=false时，则会将Put缓存到本地buffe
hbase整理1：hbase是啥： HBase（Hadoop Ddatabase）是一个开源的、面向列，适用于海量数据存储（TB、PB）的、具备高可用、高性能、可灵活扩展伸缩的、支持实时数据读写的分布式存储系统。2：hbase适用场景： 1.海量数据：TB,PB级别的 2.高吞吐量：HBase支持高并发读写，通过使用日志文件（HLOG）和内存存储来将随机写转换成顺序写，保证稳定的数据插入速率
目录写入1. Client处理2. Region写入3. MemStore Flush1. flush 触发时机2. flush 写入流程3. HFile生成读取Compaction文件合并触发时机待合并HFile集合选择策略写入1. Client处理调用Put请求后，数据放入Client缓冲区，满足一定条件后异步批量提交或直接提交（autoflush参数控制）根据rowkey到hbase:met
1，HBase的的读写流程图，是一个二次寻址的过程第一次直接到动物园管理员中找到元的元数据信息，即元对应的储存其他所有用户表的RegionServer的的位置，示意图中所给出的为regionserver1，然后第二次直接到regionserver1中的meta.region查询对应的{namespace：table，rowkey，column_family，column}的位置，这个具体的regi
最近spark跑的很慢，主要时间在scan hbase上。来来回回调试了挺长时间，最后确定瓶颈在AWS EBS的磁盘I/O(跑spark时IOPS爆到1500)，所以实际上也没有太多调优可以做。倒是调试过程中看了许多文章和资料，我觉得值得记录一下。中间废话略多，不爱看直接跳文章最后一句。网上HBASE/Hadoop调优的文章非常多，这里列一些我觉得值得留作reference的：应用层：hbase
写入数据: public class TestWrit {
private static Configuration cfg = new Configuration();
private static final int BLOCK_INDEX_SIZE = 60;
private static final int BLOOM_BLOCK_INDEX_SIZE = 10
性能测试小结：
测试环境：
机器：1 client 5 regin server 1 master 3 zookeeper
配置：8 core超到16 /24G内存，region server分配了4G heap /单seta磁盘,raid10后500GB
系统：Red Hat Enterprise Linux Server release 5.4
HBase采用LSM树架构，天生适用于写多读少的应用场景。在真实生产环境中，也正是因为HBase集群出色的写入能力，才能支持当下很多数据激增的业务。需要说明的是，HBase服务端并没有提供update、delete接口，HBase中对数据的更新、删除操作在服务器端也认为是写入操作，不同的是，更新操作会写入一个最新版本数据，删除操作会写入一条标记为deleted的KV数据。所以HBase中更新、删除
Flume事务 Put 事务流程doPut：将批数据先写入临时缓冲区 putListdoCommit：检查 channel 内存队列是否足够合并doRollback：channel 内存队列空间不足，回滚数据Take 事务流程doTake：将数据取到临时缓冲区 takeList，并将数据发送到 HDFSdoCommit：如果数据全部发送成功，则清除临时缓冲区 takeLi
对hbase调优首先需要对hbase架构有一个初步认知。hbase写数据在HBase 中无论是增加新行还是修改已有的行，其内部流程都是相同的。HBase 接到命令后存下变化信息，或者写入失败抛出异常。默认情况下，执行写入时会写到两个地方：1、预写式日志(write-ahead log，也称HLog)；2、MemStore。HBase 的默认方式是把写入动作记录在这两个地方，以保证数据持久化。只有当
原生的写入流程读取数据 --> HBase的内存 --> StoreFile --> HFile --> 分裂到更多的Region中原生的写入方法有什么问题写入效率比较慢由于数据量比较大,写入操作会长期占用HBase的带宽,这时候如果还有大量的读操作,可能会导致读操作变的异常缓慢,因为没有带宽读取数据导致HBase的压力剧增,不断地溢写,不断地合并,不断地分裂HBase的B
HBase读数据流程说明：HBase集群，只有一张meta表，此表只有一个region，该region数据保存在一个HRegionServer上1、客户端首先与zk进行连接；
从zk找到meta表的region位置，即meta表的数据 一HRegionServer上；客户端与此HRegionServer建立连接，然后读取meta表中的数据；meta表中存储了所有用户表的region信息，我们可以
HBase的批量加载: 将一批数据一次性全部写入到HBase中原生写入流程: 读取数据 --> hbase的内存 --> storeFile ---> HFile ---> 分裂 到更多的Region中HBase的bulk load的应用场景: 适合于需要一次性写入大量的数据场景演示步骤：将CSV文件转换为HFile文件格式package com.itheima.hbase
文章目录HBase读写流程HBase写入流程客户端处理阶段Region写入阶段MSLAB内存管理方式MemStore Chunk PoolMemStore Flush阶段MemStore Flush触发条件MemStore Flush执行流程BulkLoad功能HBase读取流程Client-Server读取交互逻辑CoprocessorCoprocessor分类 HBase读写流程HBase写
目录写原理读原理Flush流程HFile合并流程Region拆分流程数据删除时间HBase系列：
HBase系列（一）、数据模型 HBase系列（二）、架构原理写原理客户端请求HBase写请求（PUT,DELETE）流程如下：Client 先访问ZK中的/hbase/meta-region-server 这个Znode，获取 hbase:meta 表所在的RegionServe
一、客户端写入过程1.1、写入组件交互 1.2、客户端处理阶段 在 HBase中，大部分的操作都是在RegionServer完成的，Client端想要插入、删除、查询数据都需要先找到相应的 RegionServer。hbase客户端处理写入请求的核心流程可以分为三步：用户提交put请求后，Hbase客户端会将写入的数据添加到本地缓冲区中，符合一定条件就会通过AsyncProcess异步批
Hbase2.0查询优化1）设置scan缓存HBase中Scan查询可以设置缓存，方法是setCaching()，这样可以有效的减少服务端与客户端的交互，更有效的提升扫描查询的性能。Scan scan = new Scan();
scan.setCaching(1000);2）显示的指定列当使用Scan或者GET获取大量的行时，最好指定所需要的列，因为服务端通过网络传输到客户端，数据量太大可能是瓶
写流程： 1：Client先访问zookeeper，得到对应的RegionServer地址2：Client对RegionServer发起写请求，RegionServer接受数据写入内存3：当MemStore的大小达到一定的值后，flush到StoreFile并存储到HDFS Region是hbase存储数据的基本单元，数据都存储在Region中，每一个Region只存储一个co
