HBase写数据的异常问题以及优化
HBase数据写入通常会遇到两类问题，一类是写性能较差，另一类是数据根本写不进去。
出现这种问题的原因是因为和服务器通信超时导致的。所以需要将下面两个参数的默认值进行调整。hbase.snapshot.region.timeout hbase.snapshot.master.timeoutMillis 这两个值的默认值为60000，单位是毫秒，也即1min。
必须在设计上保证RowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若向HBase中同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据覆盖。设计的RowKey应均匀的分布在各个HBase节点上，避免数据热点现象。
region下的StoreFile数目越少，HBase读性能越好 Hfile可以被压缩并存放到HDFS上，这样有助于节省磁盘IO，但是读写数据时压缩和解压缩会提高CPU的利用率。
）对于读端，捕获异常后，可以采取休眠一段时间后进行重试等方式。3）当然，还可以根据实际情况合理调整hbase.client.retries.number和hbase.client.pause配置选项。
逻辑故障 逻辑故障中的一种常见情况就是配置错误，就是指因为网络设备的配置原因而导致的网络异常或故障。
HBase合并storefile的原因是什么?在合并的过程中会做什么操作
1、）合并文件。由于zhidaoflush的触发是回针对所有memStore，所以缓存有些记录不多的memStore flush之后的结果是很多小文件。Compaction操作可以合并这些小文件，减小对StoreFile的维护成本。2）清除删除、过期、多余版本的数据。
2、明显的，有Memstore Flush产生的HFile越多，集群系统就要做更多的合并操作(额外负载)。更糟糕的是：Compaction处理是跟集群上的其他请求并行进行的。
3、不矛盾，合并机制是为了对更新、删除后的数据进行有效管理，并释放资源；拆分是为了避免Region太大，致使Region所在节点因负载过重而宕机设定的机制。两者都是为了对大数据存储和管理进行优化而设定的机制，因此并不矛盾。
六、HBase写入流程
整个写入顺序图流程如下：1 客户端查找对应region 客户端根据要操作rowkey，查找rowkey对应的region。查找region的过程为通过zk获取到hbase：meta表所在region。
和读相比，HBase写数据流程倒是显得很简单：数据先顺序写入HLog，再写入对应的缓存Memstore，当Memstore中数据大小达到一定阈值(128M)之后，系统会异步将Memstore中数据flush到HDFS形成小文件。
首先Hbase是依赖于HDFS和zookeeper的。 Zookeeper分担了Hmaster的一部分功能，客户端进行DML语句的时候，都是先跟ZK交互。
HBase存储架构
1、HBase采用了类似Google Bigtable的数据模型，即一个稀疏的、分布式的、持久化的多维映射表，每个表都由行键、列族、列限定符和时间戳组成。
2、hbase的核心数据结构为LSM树。LSM树分为内存部分和磁盘部分。内存部分是一个维护有序数据集合的数据结构。RowKey与nosql数据库们一样，RowKey是用来检索记录的主键。
3、/hbase/.archive HBase 在做 Split或者 compact 操作完成之后，会将 HFile 移到.archive 目录中，然后将之前的 hfile 删除掉，该目录由 HMaster 上的一个定时任务定期去清理。
4、hbase的核心数据结构为LSM树。LSM树分为内存部分和磁盘部分。内存部分是一个维护有序数据集合的数据结构。
5、HBase系统架构如下所示，包括客户端、Zookeeper服务器、Master主服务器、Region服务器。一般而言，HBase会采用HDFS作为底层数据存储。
关于hbasecompact过程和hbase committer的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。