随着Web2.0的到来，互联网数据快速增长。大规模数据的采集和处理及应用直接影响着用户体验，决定着企业的发展。比较传统关系型数据库和分布式非关系型数据库两者处理大数据的性能，将本地数据迁移到分布式数据库势在必行。

　　本篇是对HBase官方参考文档的大体翻译，介于本人英文水平实在有限，难免有纰漏之处。本篇不只是对官方文档的翻译，还加入了些本人对HBase的理解。在翻译过程中，些没有营养的废话，我就忽略了没有翻译。

　　本文展示个Storm的topology，该topology对给定的词源进行词频统计，然后存入HBase，该实例不借助storm-hbase包，而是直接使用hbase client来完成对HBase的操作。

　　HBase发展到当下，对其进行的各种优化从未停止，而GC优化更是其中的重中之重。从0.94版本提出 MemStoreLAB策略、Memstore Chuck Pool策略对写缓存Memstore进行优化开始，到0.96版本提出BucketCache以及堆外内存方案对读缓存BlockCache进行优化，再到后续2.0版本宣称会引入更多堆外内存，可见HBase会将堆外内存的使用作为优化GC的个战略方向。

Hbase的REST访问

　　上篇文章主要基于工作流程对compaction进行了介绍，同时说明了compaction的核心作用是通过合并大量小文件为个大文件来减少hfile的总数量，进而保证读延迟的稳定。合并文件首先是读出所有小文件的KVs，再写入同个大文件，这个过程会带来严重的IO压力和带宽压力，对整个系统的读请求和写请求带来不同程度的影响。

　　HBase，基于Google Bigtable实现的开源、分布式、可伸缩的列式存储数据库，诞生于Hadoop，也是Hadoop生态的重要环，如今作为个Apache高项目，早已经不能将其仅仅看作Hadoop的部分，基于Storm，Spark等框架的数据处理方案中，都有它的身影，可以说它已经成为大数据工具箱中非常重要的种数据存储工具，也因此必然会被很纳入很多人学习计划。

　　随着大数据的越来越普及，HBase也变得越来越流行。会用HBase现在已经变的并不困难，然而，怎么把它用的更好却并不简单。那怎么定义‘用的好’呢?很简单，在保证系统稳定性、可用性的基础上能够用较少的系统资源(CPU,IO等)获得较好的性能(吞吐量，读写延迟)就是’用的好’。

　　在使用Spark Streaming的过程中对于计算产生结果的进行持久化时，我们往往需要操作数据库，去统计或者改变些值。较近个实时消费者处理任务，在使用spark streaming进行实时的数据流处理时，我需要将计算好的数据更新到hbase和mysql中，所以本文对spark操作hbase和mysql的内容进行总结，并且对自己踩到的些坑进行记录。

　　了解HBase的童鞋都知道，HBase是种Log-Structured Merge Tree架构模式，用户数据写入先写WAL，再写缓存，满足定条件后缓存数据会执行flush操作真正落盘，形成个数据文件HFile。随着数据写入不断增多，flush次数也会不断增多，进而HFile数据文件就会越来越多。

　　了解HBase的童鞋都知道，HBase是种Log-Structured Merge Tree架构模式，用户数据写入先写WAL，再写缓存，满足定条件后缓存数据会执行flush操作真正落盘，形成个数据文件HFile。随着数据写入不断增多，flush次数也会不断增多，进而HFile数据文件就会越来越多。

　　随着大数据的越来越普及，HBase也变得越来越流行。会用HBase现在已经变的并不困难，然而，怎么把它用的更好却并不简单。那怎么定义‘用的好’呢?很简单，在保证系统稳定性、可用性的基础上能够用较少的系统资源(CPU,IO等)获得较好的性能(吞吐量，读写延迟)就是’用的好’。

　　Hbase是种基于HDFS的分布式数据库

hbase的调优

　　HBase是hadoop生态系统中的重要组成部分，是个开源的、面向列、适合存储海量非结构化数据或半结构化数据，具备高可靠性、高性能、可灵活扩展伸缩、支持实时数据读写的分布式存储系统