【.com原创文章】ApacheHBase是Hadoop的大数据存储数据库，一种分布式、可扩展的大数据存储，它依赖于Hadoop。ImageviaPexelsHBase该技术来自FayChang的谷歌论文《Bigtable:ADistributedStorageSystemforStructuredData》。正如Bigtable利用了Google文件系统（FileSystem）提供的分布式数据存储一样，HBase在Hadoop之上提供了类似Bigtable的能力。为什么BATJ要用HBase存储海量数据？因为HBase是建立在HDFS的基础上的，HDFS是一个分布式文件系统。Hbase设计为列式存储，将业务数据按照水平拆分方式在存储中进行划分，因此查询和插入时更加集中。HBase不同于一般的关系型数据库。是适合非结构化数据存储的数据库。特别是，HBase是基于列的而不是基于行的。为什么要用HBase①分布式存储引擎分类分布式存储引擎大致分为：分布式搜索（Elasticsearch）分布式文件系统（HDFS）分布式消息队列（Kafka）缓存数据库（Redis）非关系型分布式数据库（Hbase\Mongodb\Cloudant）etc...②存储引擎的存储方式存储引擎的存储方式如下：Redis有AOF和RDBElasticsearch会将数据写入translog，然后结合FileSystemCache将数据刷盘。Kafka本身就是把数据顺序写入磁盘的。。。这些中间件可以实现持久化（比如HDFS和MySQL就是用来存储数据的），那为什么要用HBase呢？③各种存储引擎的优缺点HDFS可以存储海量数据，容错性高，适合批处理，适合存储大量数据，可以流式数据访问，对服务器要求不高，但也有一些缺点，比如不适合低延迟的数据访问。比如毫秒级别的数据存储是不可能的，大量的小文件也没有办法高效的保存和处理，而且一个文件只能一个线程写入，不允许多个线程同时写入时间，不支持文件。的随机修改。MySQL是我们日常生活中用的比较多的关系型数据库，但是大家都知道MySQL是单机的。单机MySQL的最大容量完全取决于服务器硬盘容量的大小。它最致命的弱点是当需要存储大量数据时，MySQL难以处理。大家都知道Elasticsearch是一个分布式搜索引擎，在搜索效率上还是比较快的。因为Elasticsearch是基于分布式的，所以理论上可以保存大量的数据，我们也可以根据索引进行检索。这是我们心目中最完美的存储方式吗？不，他不是，因为如果我们存储的数据没有必要经常查询。其实放在Elasticsearch里面是一种浪费，因为数据写入Elasticsearch的时候需要切分，这样会消耗很多资源，造成不必要的浪费。Redis是近几年最常用的缓存数据库。读写操作全部在内存中进行，响应速度非常快。所有保存在AOF/RDB中的相关数据都会加载到我们机器的内存中，这使得Redis不适合保存大量数据，毕竟内存是比较有限的。在我们的项目工作中，主要使用Kafka来处理消息的解耦和异步调峰。当数据到达Kafka时，此时数据会被持久化到服务器的硬盘中，而且由于是分布式的，所以扩展非常方便。根据这个逻辑，Kafka可以存储大量数据。但是Kafka的持久化数据最常见的用法是直接重置offset进行操作。④Hbase使用场景Hbase适用于数据的随机读操作或随机写操作，大数据的高并发操作，比如PB级数据每秒上千次操作，读写访问都是非常简单的操作。淘宝索引是Hbase在淘宝的典型应用。交易历史查询非常适合使用Hbase作为底层数据库。HBase入门①HBase特性Hbase是NoSQL数据库，也就是说它不是传统的RDBMS数据库，不支持SQL语句。因为Hbase是一个分布式存储数据库，从技术上讲，它属于分布式存储，因为它缺少RDBMS数据库的很多特性。Hbase有什么特点？如下：大，容量巨大，HBase的单表可以有百亿行，百万列，可以水平垂直维度插入数据，非常灵活。稀疏性，主要体现在Hbase对于列的高度灵活性。比如对于NULL列，不会占用存储空间，所以表可以设计得很稀疏。易于扩展，因为前面也提到了HBase是工作在HDFS上的，所以天然支持分布式表，也继承了HDFS的扩展性。而且HBase的扩展是水平扩展。所谓横向扩展，就是在扩展时不需要提升服务器性能，只需要在现有集群中增加服务器即可。高并发，如果项目使用Hbase架构，使用的PC可以很便宜，所以高IO也是常有的事。我说的高并发是指Hbase和其他NoSQL一样，不支持复杂的SQL语句，这为性能优化带来了更多的可能性，主要工作在内存中。支持大并发的应该没问题。还有别忘了，HBase天生就支持分布式，所以你也可以使用集群等方法来提高并发。高可用性是因为HBase运行在HDFS上。HDFS的多副本存储类似于MySQL的主备容灾。发生故障时可自行恢复。同时HBase还有更多的策略如：Replication、WAL等等。面向列，这个不同于我们常用的关系型数据库如MySQL，HBase是面向列的存储控制。简单来说就是每一列单独存储，支持直接对该列进行查询。下图可以简单的理解什么是对列的操作。从图中理解，看下面的列存储中的行存储，其中行存储是一块存储的，而列存储中的数据是分开的。从上图我们知道，行存储更适合插入和更新，查询操作时需要读取其中的所有数据。此时HBase列存只需要读取相关列即可，可以大大降低系统I/O吞吐量。达到快速阅读的目的。②什么情况更适合使用Hbase？如果你只有几百万条或更少的数据，那么关系型数据库可能更适合你。因为如果数据量不大，HBase的优势根本体现不出来，反而会成为一种负担，因为有大量闲置的机器，浪费资源。还有一个就是你对列查询的使用不是那么高，不需要辅助索引，静态类型列等HBase的特性。在现有的项目中使用关系型数据库已经可以满足它的需求，所以你根本不需要它。将其用于技术。以前的项目如果非要用的话，需要重新设计重构等等，会带来不必要的麻烦。最后，虽然Hbase也可以在单机环境下运行，但是最好在开发环境下使用。③HBase的Key-ValueHBase其实和Redis一样是Key-Value数据库，那么在HBase中，什么是Key呢？什么是价值？首先，KeyValue的概念设计来自一篇名为“Thelog-structuredmerge-tree(LSM-Tree)”的论文。每一行和每一列的数据都被独立的打包成一个特定的结构，即KeyValue，KeyValue中还包含了很多自描述信息，会导致数据膨胀。目前市面上所有项目的主要数据结构有：结构化数据半结构化数据非结构化数据由于HBase的稀疏性，相对于非结构化数据存储有天然的优势。在我们日常的项目中，经常会用到关系数据，也就是结构化数据。由于HBase目前只提供了基于RowKey的单维索引，所以在我们日常的项目中还是有点吃力。还需要在HBase的基础上增加一些特殊的功能，比如：GeoMesa时空数据存储JanusGraph图数据存储OpenTSDB时序数据存储这种情况还是专业的事情交给专业的吧，既然MySQL，Oracle、MSSQL等关系型数据库太擅长处理结构化数据了，让他们来处理吧。由于不擅长处理海量的非结构化数据，所以会使用HBase，所以我明白HBase并不是万能的，它只是对传统关系型数据库的补充。④HBase架构HBase架构如上图所示：Zookeeper，主要功能是分布式协调。RegionServer作为数据节点，用于存储数据，同时也将自己的信息写入ZooKeeper。HDFS，这里主要作为HBase的基础，是为HBase提供服务的分布式文件系统。Master主要负责管理所有的RegionServer，管理所有Region对RegionServer的分配，也可以自己作为一个RegionServer。大致流程是：客户端向Zookeeper提出请求。Zookeeper将HRegionServer地址返回给客户端。客户端获取到Zookeeper返回的地址后，请求HRegionServer。HRegionServer读写数据返回给客户端。⑤HMaster的大作用看上面的过程，好像没有提到HMaster，那么HMaster就没用了吗？那它主要做什么呢？其实它的作用也不容忽视：负责Regionserver的分布式管理和Regionserver的region的负载均衡分配。HRegion分裂后，负责分配新的HRegion。回收HDFS上的垃圾文件并处理模式更新请求。可见HMaster相当于一个指挥，对统筹全局非常重要！RowKey的设计RowKey在查询和存储中起着非常重要的作用。如果在HBase中设计一个RowKey，会影响数据的分布和我们的查询速度。由此我们知道设计一个优秀的RowKey是非常重要的，那么我们如何设计这么重要的RowKey呢？首先要遵循以下原则：长度原则：越短越好，越短越好，越短越好，重要的事情说三遍，最大不能超过64K。如果时间过长，主要有两个影响。首先，它会特别影响HFile的存储效果。其次，MemStore会在内存中缓存一些数据。RowKey字段过长会降低内存的有效利用率，系统无法缓存更多的数据，从而降低检索效率。总结：保存慢，查询慢！唯一的原则：这个应该很容易理解。RowKey的存储结构是Key-Value的形式，就像Java中的Map一样。如果将相同的Key值保存到同一个Map中，保存的值会被Overwrite之前保存的值。排序原则：HBase自然会按照ASCII对RowKeys进行排序，所以我们在设计RowKeys的时候，可以根据这个特性设计出完美的RowKeys。利用好这个特性就是排序原则。散列原则：如果RowKey是按照时间戳递增的，就不要把时间放在二进制码前面。建议使用RowKey的高位作为hash字段，由程序随机生成，低位放时间字段。这样会增加数据均匀分布在各个RegionServer上的概率，从而实现负载均衡。如果没有hash字段，第一个字段直接是时间信息，所有的数据都会集中在一个RegionServer上。这样在数据检索时，负载会集中在各个RegionServer上，造成热点，降低查询效率。①根据RowKey模糊查询，直接上战场。首先，根据业务场景的需要，我们肯定还需要查询之前T数据中的一些数据，即通过RowKey方法进行模糊查询。hbaseshell#首先登录hbaselist#查询系统中所有数据库表扫描'tablename',{STARTROW=>'rowkey1',STOPROW=>'rowkey2'}②根据RowKey范围查询这里是时间范围查询，和TIMERANGE中的值为时间戳。scan‘tablename’,{TIMERANGE=>[1325654785652,1436524854295]}更多操作下次我会在相关文章中为大家详细讲解HBase的使用。HBase调优①读性能优化HBase服务器优化：读请求是否均衡？BlockCache设置是否合理？数据本地化率低吗？有太多的HFile吗？设置是否合理？是否使用批量请求？是否为离线批量读取请求禁用了缓存？请求是否可以显示指定的列族或列？HBase列族优化：布隆过滤器设置了吗？②写性能优化HBase服务器优化：Region是否太少？写入请求是否平衡？HBase客户端优化：能不能用Bulkload方案来写？需要写WAL吗？WAL需要同步写吗？Put可以同步批量提交吗？Put可以异步批量提交吗？KeyValue中写入的数据是否太大？大家可以带着上面的问题来一一优化自己的HBase。参考：http://hbase.apache.org/作者：刘永基简介：中科院大学博士，中科院信息工程研究所，主要从事大数据可视化、虚拟现实和数字孪生技术研究研究;精通Java、Python等主流技术架构，善于从架构的角度思考和解决问题。编辑：陶佳龙征稿：如有意投稿或求报道，请加编辑微信gordonlonglong【原创稿件，合作网站转载请注明原作者及出处为.com】
