做分析报表的网站,国外网站设计模板,html5官网免费下载,海拉尔网站建设平台文章目录 一. HBase 数据模型1. 行存储与列式存储1.1. 行存储1.2. 列存储 2. HBase 数据模型2.1. 模型概览2.2. 列与列族2.3. 时间戳#xff1a;定义数据版本2.4. HBase的Key-Value 三. HBase架构1. HBase读写流程简述2. HRegionServer内部内部数据流转#xff1a;HRegion 定义数据版本2.4. HBase的Key-Value 三. HBase架构1. HBase读写流程简述2. HRegionServer内部内部数据流转HRegion - Store(HFile) - MemStore - HLog 3. HMaster 四. 特性讨论1. 大数据存储与拓展2. HBase速度真的很快2.1. 为何HBase速度很快2.1.1. 写入快的原因2.1.2.查询快的原因a. Region定位b. LSM树型结构c. LRU Cache算法 MemStore内存 2.1.3. 举例说明 2.2. 查询效率什么情况下会降低 3. 有限的查询方式3.1.不适合复杂查询3.2. 不支持sql查询 4. 列存储的特点 四、适合的业务场景1. 写密集型但相对读数量较小的应用2. 搜索引擎应用3. 车联网数据的收集4. 标签数据稀疏矩阵的存储5. 用户交互数据6. 广告效果和点击流 五. 用在生产环境前的注意事项1. 查询条件2. rowkey设计要求较高2.1. RowKey设计2.2. 根据RowKey查询a. 根据RowKey进行单条查询b. 根据RowKey范围查询的场景 2.3. 热点问题处理 3. 不太适合大范围key查询4. Hbase部署相对复杂运维成本高 通过了解Hbase的基础概念、架构特点底层原理等可以了解HBase读写的特点。通过从底层理解这些特点我们能够将HBase应用到合适的场景。 本文主要了解HBase的
hbase的概念、架构hbase的特点细节存储拓展性、列存储、定义数据版本、查询快吗应用场景、生产注意事项。 Apache HBase™ is the Hadoop database, a distributed, scalable, big data store. Apache HBase 是 Hadoop 数据库一个分布式、可伸缩的大数据存储。HBase是一个NoSQL数据库它把数据存在HDFS上。 HBase在HDFS之上提供了高并发的随机写和支持实时查询这是HDFS不具备的。 HBase特点 存储数据的”结构“可以地非常灵活。HBase仅能通过主键(row key)和主键的range来检索数据仅支持单行事务(可通过 hive 支持来实现多表 join等复杂操作)主要用来存储结构化和半结构化的松散数据。Hbase 目标主要依靠横向扩展通过不断增加廉价的商用服务器来增加计算和存储能力。 一. HBase 数据模型
1. 行存储与列式存储
1.1. 行存储
行存储系统以行的方式来组织数据。行存储将数据一行一行的写入写入一条数据记录时只需要将数据追加到已有数据记录后面即可。 行模式存储适合 OLTP(Online Transaction Processing)系统。因为数据基于行存储所以数据的写入会更快。对按记录查询数据也更简单。
场景统计整个系统今天的博客点赞数。对于行存储系统需要将所有行数据读入内存然后对 like_num 列做 sum 操作从而得到结果。
我们假设磁盘一次可以读取图中 3 个方框的数据那么这个聚合计算需要 N(N数据量)次磁盘访问。 1.2. 列存储
同样是上面的示例数据我们来看列式存储是怎样组织数据的。
列式存储将每一列的数据组织在一起。 利于对于列的操作如上面我们说到的统计所有 like_num 之和。其过程将如下
依然假设磁盘一次可以读取 3 个方框的数据(实际按 byte 读取)。可以看出按列存储组织数据的方式只需要 1 次磁盘操作就可以完成。 列式存储也有不利的一面。首先就表现在数据写入上。 HBASE是怎么存储的我们下面讨论。 对比 2. HBase 数据模型
2.1. 模型概览
概念解释Name Space1. 命名空间类似于关系型数据库的 DataBase 概念每个命名空间下有多个表。2. HBase有两个自带的命名空间分别是 hbase 和 defaulthbase 中存放的是 HBase 内置的表default 表是用户默认使用的命名空间。Region1. 类似于关系型数据库的表概念。2. 不同的是HBase 定义表时只需要声明列族即可不需要声明具体的列。这意味着往 HBase 写入数据时字段可以动态、按需指定。因此和关系型数据库相比HBase 能够轻松应对字段变更的场景。Row1. HBase 表中的每行数据都由一个 RowKey 和多个 Column列组成。2. 数据是按照 RowKey的字典顺序存储的并且查询数据时只能根据 RowKey 进行检索所以 RowKey 的设计十分重要热点数据。rowKeyrowKey又叫行键它是有序的字典顺序Column1. HBase 中的每个列都由 Column Family(列族)和 Column Qualifier列限定符进行限定例如 infonameinfoage。2. 建表时只需指明列族而列限定符无需预先定义。Time Stamp用于标识数据的不同版本每条数据写入新增、更新、删除等操作都是写入时如果不指定时间戳系统会自动为其加上该字段其值为写入 HBase 的时间。Cell由{rowkey, column Familycolumn Qualifier, time Stamp} 确定一条数据的单元。 接下来重点讲解几个和关系型数据库不同的方面.
2.2. 列与列族
HBase的列不是我们在关系型数据库所想象中的列。
HBase的列Column都得归属到列族Column Family中。在HBase中用列修饰符Column Qualifier来标识每个列。在HBase里先有列族后有列。
什么是列族可以简单理解为列的属性类别 什么是列修饰符在列族下用列修饰符来标识一列。 看一个的例子
HBase表的每一行中列的组成都是灵活的行与行之间的列不需要相同。换句话说一个列族下可以任意添加列不受任何限制。 2.3. 时间戳定义数据版本
数据写到HBase的时候都会被记录一个时间戳这个时间戳被我们当做一个版本。比如说我们修改或者删除某一条的时候本质上是往里边新增一条数据新增了记录的版本。 现在要把这条记录的值改为40实际上就是多添加一条记录在读的时候按照时间戳读最新的记录。在外界「看起来」就是把这条记录改了。删除一条数据实际上也是增加一条记录只不过我们在KeyType里边设置为“Delete”就可以了。 2.4. HBase的Key-Value
HBase本质上其实就是Key-Value的数据库那在HBase里边Key是什么Value是什么
每个KeyValue都由4个部分构成分别为key lengthvalue lengthkey和value。其中 key length和value length是两个固定长度的数值key是一个复杂的结构, rowkey长度、rowkey ColumnFamily长度、ColumnFamily、ColumnQualifier 时间戳 KeyTypekeytype有四种类型分别是Put、Delete、 DeleteColumn和DeleteFamily value就是一串纯粹的二进制数据。 要准确定位一条数据那就需要知道RowKeyColumn时间戳。 三. HBase架构 1. HBase读写流程简述
1、Client客户端它提供了访问HBase的接口并且维护了对应的cache来加速HBase的访问。 2、zookeeper不存储meta表meta表还是放到regionserver里的region存储的和其他表没啥太大区别相当于其他表的索引而zookeeper放的是meta表的索引相当于索引的索引也就是二层索引。
查找快的原因 从Zookeeper里拿到meta元数据告诉给客户端去哪台机器读写数据这也是hbase能支持海量数据快速查找的一个原因。数据按rowkey字典序排序了既然是排好序的数据那二分法查找时间复杂度是logN。 3、HRegionServer它是处理客户端的读写请求负责与HDFS底层交互是真正干活的节点。 总结大致的流程就是 client请求到ZookeeperZookeeper返回HRegionServer地址给clientclient得到Zookeeper返回的地址去请求HRegionServerHRegionServer读写数据后返回给client。 2. HRegionServer内部 HBase一张表的数据会分到多台机器上的。那HBase是怎么切割一张表的数据的呢用的就是RowKey来切分其实就是表的横向切割。 内部数据流转HRegion - Store(HFile) - MemStore - HLog
名字说明Region一个Region存储HBase表的一部分数据多个Store组成一个Region。StoreFileHFile1. 物理结构保存实际数据的物理文件StoreFile 以 HFile 的形式存储在 HDFS 上。每个 Store 会有一个或多个 StoreFileHFile数据在每个 StoreFile 中都是有序的。2. 用于存储列族一个列族的数据是存储在一起的即存储到一个HFile中。所以我们可以认为HBase是基于列族存储的。 3. HFile以KeyValue形式存储数据。MemStore写缓存由于 HFile 中的数据要求是有序的所以数据是先存储在 MemStore 中排好序后等到达刷写时机才会刷写到 HFile每次刷写都会形成一个新的 HFile。HLog1. 为了防止数据丢失由于数据要经 MemStore 排序后才能刷写到 HFile但把数据保存在内存中会有很高的概率导致数据丢失为了解决这个问题数据会先写到HLog中然后再写入 MemStore 中。所以在系统出现故障的时候数据可以通过这个日志文件重建。2. 顺序写HLog是顺序写到磁盘的所以速度还是挺快的类似于kafka的感觉
小结 HRegionServer是真正干活的机器用于与hdfs交互我们HBase表用RowKey来横向切分表HRegion里边会有多个Store每个Store其实就是一个列族的数据即HBase基于列族存储的Store里边有Men Store和StoreFile(HFile)其实就是先走一层内存然后再刷到磁盘的结构 3. HMaster
上面我们知道RegionServer管理所有Region负责DML操作接下来我们看HMaster。
HMaster负责DDL操作、管理所有RegionServer HMaster会处理元数据的变更;监控RegionServer的状态在RegionServer出现意外宕机时Master会负责该RegionServer上的Region进行迁移;处理 HRegion 的分配或转移如果HRegion的数据量太大的话HMaster会对拆分后的Region 重新分配RegionServer。如果发现失效的HRegion也会将失效的HRegion分配到正常的HRegionServer中。 四. 特性讨论
1. 大数据存储与拓展 海量存储Hbase 适合存储 PB 级别的海量数据在 PB 级别的数据以及采用廉价 PC 存储的情况下能在几十到百毫秒内返回数据。极易扩展: a. 基于存储的扩展HDFS。b. 通过横向添加 RegionSever 的机器进行水平扩展提升 Hbase 上层的处理能力。基于Hbase的设计理念与存储原理Hbase单表可以有百亿行、百万列在横向和纵向两个维度所支持的数据量级都非常巨大在列上其实并没有数量的限制。 所以根据业务需求当表需要非常大时可考虑选型Hbase。 如果最多只是上亿条记录并且列不是特别大的话没有必要放入hbase中ES和mongodb都能轻松搞定。 数据高可靠性Hbase本身高可靠性特性以及HDFS的高可靠性。 2. HBase速度真的很快
2.1. 为何HBase速度很快
2.1.1. 写入快的原因 前面说过HBase会将数据保存到内存中在内存中的数据是有序的如果内存空间满了会刷写到HFile中而在HFile中保存的内容也是有序的。当数据写入HFile后内存中的数据会被丢弃。 HBase的写入速度快是因为 它其实并不是真的立即写入文件中而是先写入内存随后异步刷入HFile。所以在客户端看来写入速度很快。另外写入时候将随机写入转换成顺序写数据写入速度也很稳定。 2.1.2.查询快的原因
HBase能提供实时计算服务主要原因是由其架构和底层的数据结构决定的 即由 HTable(region分区)CacheLSM-Tree(Log-Structured Merge-Tree) a. Region定位
通过RowKey定位数据所在Region 1客户端先通过ZooKeeper的/hbase/meta-region-server节点查询到哪台RegionServer上有hbase:meta表。 2客户端连接含有hbase:meta表的RegionServer。hbase:meta表存储了所有Region的行键范围信息通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面以及这个Region又是属于哪个RegionServer。 3获取这些信息后客户端就可以直连其中一台拥有你要存取的rowkey的RegionServer并直接对其操作。 客户端会把meta信息缓存起来下次操作就不需要进行以上加载hbase:meta的步骤了。 b. LSM树型结构
读取速度快是因为它使用了 LSM树型结构ing而不是B或B树。磁盘的顺序读取速度要比寻找磁道速度快很多。
HBase的存储结构使得磁盘寻道时间在可预测范围内并且rowkey任意连续数量的记录都不会引发额外的寻道开销。 比如有5个存储文件那么最多需要5次磁盘寻道就可以。而关系型数据库即使有索引也无法确定磁盘寻道次数。 c. LRU Cache算法 MemStore内存
HBase首先会在 缓存BlockCache中查找它采用了 LRU最近最少使用算法如果缓存中没找到会从内存中的MemStore中查找只有这两个地方都找不到时才会加载HFile中的内容而上文也提到了读取HFile速度也会很快因为节省了寻道开销。 小结 数据定位 客户端定位数据所在HRegion server接着在服务器的一个region上查找要匹配的数据通过内存LRU Cache算法 MemStore内存或访问磁盘LSM查找到数据。 2.1.3. 举例说明
hbase是根据rowkey查询的我们看下如何快速定位rowkey 快速找到region分区假设表有10亿条记录占空间1TB, 分列成了500个region, 通过zk二分法找到region的时间复杂度为O(log₂500)9步。 根据列存储缩小范围是按列存储的其实是列族假设分为3个列族每个列族就是666M 设要查询的东西在其中1个列族上包含一个或多个HFile、假设一个HFile是128M该列族包含在5个HFile文件剩下的在内存中。 根据字段排序再加速查询查找的记录有可能在最前面或最后面假设最坏情况在中间我们只需遍历2.5个HStoreFile共300M 通过rowkey遍历一个个数据块中key的位置并判断符合条件可以了。一般key是有限固定长度假设key:value长度是1:19最终只需要15M就可获取的对应的记录按照磁盘的访问100M/S只需0.15秒。 加上块缓存机制LRU原则会取得更高的效率。 HBase适合存储PB级别的海量数据百亿千亿量级条记录如果根据记录主键Rowkey来查询能在几十到百毫秒内返回数据。 2.2. 查询效率什么情况下会降低
hbase适合大数据量的查询但并不适合大范围的查询本质上HBase是put、get kv对海量数据下跑类似select一样的检索scan一遍全表且因为分布式的原因查询效率会随着查询范围的增大导致查询效率降低。 3. 有限的查询方式
3.1.不适合复杂查询
HBase作为一种KV数据库数据访问模式以主键为核心当面对非主键查询时其原生解决方案Filter无法满足大多数联机应用的性能需求。
3.2. 不支持sql查询
与传统的关系型数据库不同HBase不支持SQL查询也没有标准的关系型数据库中所定义的表关系也不支持多表联合查询。
其次由于HBase是面向列Column的数据存储模型它可以存储大量稀疏的数据而这种数据在关系型数据库中一般是难以处理的需要对数据进行多表关联才能实现。因此在HBase中使用SQL查询的效率和灵活性都是相对较低的。
实际使用过程中可以使用HBase提供的API或者其他工具来实现数据的读写操作。
public class HBaseManager {public static void main(String[] args) throws IOException {//创建HBase配置对象Configuration config HBaseConfiguration.create();//设置Zookeeper地址Zookeeper是HBase的元数据存储位置config.set(hbase.zookeeper.quorum, localhost);//创建HBase连接Connection conn ConnectionFactory.createConnection(config);//获取HBase表对象Table table conn.getTable(TableName.valueOf(test_table));//创建HBase行键对象byte[] rowKey Bytes.toBytes(rowkey1);//创建HBase查询对象Get get new Get(rowKey);//获取HBase行数据Result result table.get(get);//读取HBase列数据byte[] value result.getValue(Bytes.toBytes(cf), Bytes.toBytes(col1));4. 列存储的特点 适合稀疏特性的数据进行存储 为空的列并不占用存储空间表可以设计的非常稀疏。不必像关系型数据库那样需要预先知道所有列名然后再进行null填充。动态列拓展 Hbase的数据在表中是按照列族进行存储的可动态增加列这样在只查询少数几个字段的时候不需要全表扫描能极大提高查询效率。 四、适合的业务场景
针对某些特点的数据可以使用 HBase 高效地解决如以下的应用场景。 数据库中的很多列都包含了很多空字段在 HBase 中列存储使得空字段不会像在关系型数据库中占用空间。需要很高的吞吐量瞬间写入量很大。数据有很多版本需要维护HBase 利用时间戳来区分不同版本的数据。具有高可扩展性能动态地扩展整个存储系统。 接下来具体说明
1. 写密集型但相对读数量较小的应用
京东用Hbase存储卖家操作日志即几十万商家时时刻刻进行的各种操作。以便进行分析并且可以保证商家可以精确查询自己的各种操作。卖家操作日志的特点是数据量大、实时性强、增多查少。
HBase只支持基于rowkey的查询对于HBase来说单条记录或者小范围的查询是可以接受的大范围的查询由于分布式的原因在性能上会受影响。并且不支持多条件复杂查询。
因此Hbase适合做海量数据亿万条记录的最底层数据源。 2. 搜索引擎应用
HBase 是 Google Bigtable 的开源实现而 Google 公司开发 Bigtable 是为了它的搜索引擎应用。
HBase 应用于网络搜索的逻辑过程。 首先网络爬虫持续不断地从网络上抓取新页面并将页面内容存储到 HBase 中爬虫可以插入和更新 HBase 里的内容然后用户可以利用 MapReduce 在整张表上计算并生成索引为网络搜索做准备接着用户发起搜索请求最后搜索引擎查询建立好的索引列表 获取文档索引后再从 HBase 中获取所需的文档内容最后将搜索结果提交给用户。 3. 车联网数据的收集
车联网系统是利用车载设备收集车辆运行时产生的各项数据通过网络实时上传在平台进行动态分析和利用。 车联网系统所面对的数据特点是 大量车辆终端高并发的不间断写入TB级甚至PB级的数据而且对于实时分析来说为了保证分析结果的时效性又要求查询的低时延响应。 HBase采用LSM存储模型可以从容应对高并发写入的场景同时也能保证读时延在可接受的范围内。同时HBase具有良好的水平扩展能力。通过增减RegionServer来实现对存储容量动态调整满足对使用成本的要求。 4. 标签数据稀疏矩阵的存储
标签数据是稀疏矩阵的代表描述了实体的各类属性主要应用于智能推荐、商务智能或营销引擎等领域。 如下三个不同的用户在同一公司旗下的不同APP中留下了大量的行为数据这些数据中包含了直接填写的用户资料、使用APP的具体行为以及领域专家对某些现象的标记通过后台的标签算法可以得到这样的数据 可以看到对用户行为采集存在局限性因此所能得到的标签种类各不相同表中大量的数据项只能被置空也就是所谓的稀疏矩阵。而且随着用户更深度的使用APP可以预见到对用户感兴趣领域/不感兴趣领域会逐渐被发掘那么表的列也会随之增加。 使用HBase存储时未指定value的列不会占用任何的存储空间且HBase对于Column的增删极为容易有利于应对未来属性的扩张。 5. 用户交互数据
例如Facebook 里的 Like 按钮每次用户 Like —个特定主题计数器增加一次。FaceBook 使用 HBase 的计数器来计量人们 Like 特定网页的次数。内容原创人或网页主人可以得到近乎实时的、用户 Like 他们网页的数据信息。他们可以据此更敏捷地判断应该提供什么内容。
基于 HBaseFacebook 可以很方便地横向扩展服务规模提供给数百万用户也可以继续使用他们已有的运行大规模 HBase 机群的经验。该系统每天处理数百亿条事件记录数百个参数。 6. 广告效果和点击流 实时存储 使用HBase实时存储点击行为数据如点击广告的时间、位置。 实时推荐 当用户访问网站或APP时系统可以实时地根据用户的历史点击行为从 HBase 中检索数据并使用推荐算法如协同过滤、内容推荐等来推荐相关的广告给用户。 反馈和优化 收集用户对广告的点击反馈用于优化推荐算法。 扩展和分析 利用HBase的分析工具对积累的数据进行批量处理发现用户行为规律进一步优化系统。 五. 用在生产环境前的注意事项
HBase从本身原理和特性上保证了其高可用、高可靠性以及分布式全内存异步的高写入性能那么最终用在生产前需要注意以下几个方面
1. 查询条件
HBase查询条件简单只支持基于主键rowkey索引即只能通过rowkey进行查询不能像其他数据库一样使用多条件复杂查询不支持二级索引因此选型前需确认是否能满足业务需求。 2. rowkey设计要求较高
2.1. RowKey设计
设计RowKey时要保证RowKey是唯一的毕竟它是行键其次为了带来更好的满足业务需求我们可以使用时间戳、自增数据、组合键例如userId_regionId_timestamp等方式。 2.2. 根据RowKey查询
在HBase里边提供了全局扫描、根据一个RowKey进行查询、根据RowKey过滤的范围查询等三种方式。
a. 根据RowKey进行单条查询
从0.96版本之后Hbase为二层查询架构。 1客户端先通过ZooKeeper的/hbase/meta-region-server节点查询到哪台RegionServer上有hbase:meta表。 2客户端连接含有hbase:meta表的RegionServer。hbase:meta表存储了所有Region的行键范围信息通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面以及这个Region又是属于哪个RegionServer。 3获取这些信息后客户端就可以直连其中一台拥有你要存取的rowkey的RegionServer并直接对其操作。 客户端会把meta信息缓存起来下次操作就不需要进行以上加载hbase:meta的步骤了。 RowKey是会按字典序排序的HBase表会用RowKey来横向切分表。
HRegion有start-key和end-key两个属性用于标识RowKey的范围。当读写时我们通过RowKey[start-keyend-key定位到HRegion也就定位到HRegionServer。 b. 根据RowKey范围查询的场景 假设直播过程中间隔几秒就采集直播间热度之后业务方经常要把主播的一段时间内的热度给查询出来。 通过设计RowKey( 某直播平台_主播名ID_直播时间戳 )将该主播的一段时间内的热度都写到同一个HRegion上拉取的时候只要访问一个HRegionServer就可以得到全部我想要的数据了那查询的速度就快很多。 2.3. 热点问题处理
由于我们的RowKey是以字典序排序的如果我们对RowKey没有做任何处理那就有可能存在热点数据某类数据会出现很集中的现象的问题。 方式1: 自己指定RowKey的分割点来划分region个数。 比如有一组数据RowKey为[1,2,3,4,5,6,7]此时给定split。 RowKey是1,3,6,那么就会划分为[1,3),[3,6),[6,7)的三个region里。如果对于RowKey的组成及数据分布非常清楚的话可以使用这种方式精确预分区。 方式2 : 只知道RowKey的组成大致的范围时 设定始末的RowKey以及根据数据量给定大致的region数。一般建议region数最多不要超过集群的regionServer节点数过多region数不但不能增加表访问性能反而会增加master节点压力。如果给定始末RowKey范围与实际偏差较大的话还是比较容易产生数据热点问题。 方式3生成RowKey时进行加盐或者哈希的处理可以缓解数据热点问题。 HBase是Key/vale数据库也只能通过key即rowkey来查询数据rowkey的设计非常重要一个优秀的rowkey设计即可以满足查询业务需求同时也能让数据均衡分布在集群中的节点上。提升读写性能。 3. 不太适合大范围key查询
从HBase的存储原理可知其根据rowkey字节范围进行分区分文件存储大范围的数据查询会使查询落到多个不同的RegionServer上所以大范围的rokey查询查询效率会比较低下。 4. Hbase部署相对复杂运维成本高
部署Hbase集群之前首先要部署Hadoop集群这包括HDFS、Yarn、Mapredue等一系列组件其次还要部署Zookeeper集群。 在这两块的服务都正常部署启动后才能部署HBase集群此外还包括监控运维等服务组件。
