网易视频云:HBase – 存储文件HFile结构解析

合集下载

Hfile文件详解

Hfile文件详解

Table of Contents

HFile存储格式

Block块结构

HFile存储格式

HFile是参照谷歌的SSTable存储格式进行设计的,所有的数据记录都是通过它来完成持久化,其内部主要采用分块的方式进行存储,如图所示:

每个HFile内部包含多种不同类型的块结构,这些块结构从逻辑上来讲可归并为两类,分别用于数据存储和数据索引(简称数据块和索引块),其中数据块包括:

(1) DATA_BLOCK:存储表格数据

(2) BLOOM_CHUNK:存储布隆过滤器的位数组信息

(3) META_BLOCK:存储元数据信息

(4) FILE_INFO:存储HFile文件信息

索引块包括:

表格数据索引块(ROOT_INDEX、INTERMEDIATE_INDEX、LEAF_INDEX) 在早期的HFile版本中(version-1),表格数据是采用单层索引结构进行存储的,这样当数据量上升到一定规模时,索引数据便会消耗大量内存,导致的结果是Region

加载效率低下(A region is not considered opened until all of its block index data is loaded)。

因此在version-2版本中,索引数据采用多层结构进行存储,加载HFile时只将根索引(ROOT_INDEX)数据载入内存,中间索引(INTERMEDIATE_INDEX)和叶子索引(LEAF_INDEX)在读取数据时按需加载,从而提高了Region的加载效率。

∙元数据索引块(META_INDEX)

网易视频云:探求BlockCache实现机制

网易视频云:探求BlockCache实现机制

网易视频云:探求BlockCache实现机制

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。

LRUBlockCache

LRUBlockCache是HBase目前默认的BlockCache机制,实现机制比较简单。它使用一个ConcurrentHashMap管理BlockKey到Block的映射关系,缓存Block只需要将BlockKey 和对应的Block放入该HashMap中,查询缓存就根据BlockKey从HashMap中获取即可。同时该方案采用严格的LRU淘汰算法,当Block Cache总量达到一定阈值之后就会启动淘汰机制,最近最少使用的Block会被置换出来。在具体的实现细节方面,需要关注三点:

1. 缓存分层策略

HBase在LRU缓存基础上,采用了缓存分层设计,将整个BlockCache分为三个部分:single-access、mutil-access和inMemory。需要特别注意的是,HBase系统元数据存放在InMemory区,因此设置数据属性InMemory = true需要非常谨慎,确保此列族数据量很小且访问频繁,否则有可能会将hbase.meta元数据挤出内存,严重影响所有业务性能。

2. LRU淘汰算法实现

系统在每次cache block时将BlockKey和Block放入HashMap后都会检查BlockCache 总量是否达到阈值,如果达到阈值,就会唤醒淘汰线程对Map中的Block进行淘汰。系统设置三个MinMaxPriorityQueue队列,分别对应上述三个分层,每个队列中的元素按照最近最少被使用排列,系统会优先poll出最近最少使用的元素,将其对应的内存释放。可见,三个分层中的Block会分别执行LRU淘汰算法进行淘汰。

网易视频云:Kudu,支持快速分析的新型Hadoop存储系统

网易视频云:Kudu,支持快速分析的新型Hadoop存储系统

网易视频云:Kudu,支持快速分析的新型

Hadoop存储系统

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。

Kudu是Cloudera开源的新型列式存储系统,是Apache Hadoop生态圈的新成员之一(incubating),专门为了对快速变化的数据进行快速的分析,填补了以往Hadoop存储层的空缺。本文主要对Kudu的动机、背景,以及架构进行简单介绍。

背景——功能上的空白

Hadoop生态系统有很多组件,每一个组件有不同的功能。在现实场景中,用户往往需要同时部署很多Hadoop工具来解决同一个问题,这种架构称为混合架构(hybrid architecture)。比如,用户需要利用Hbase的快速插入、快读random access的特性来导入数据,HBase也允许用户对数据进行修改,HBase对于大量小规模查询也非常迅速。同时,用户使用HDFS/Parquet + Impala/Hive来对超大的数据集进行查询分析,对于这类场景,Parquet这种列式存储文件格式具有极大的优势。

很多公司都成功地部署了HDFS/Parquet + HBase混合架构,然而这种架构较为复杂,而且在维护上也十分困难。首先,用户用Flume或Kafka等数据Ingest工具将数据导入HBase,用户可能在HBase上对数据做一些修改。然后每隔一段时间(每天或每周)将数据从Hbase中导入到Parquet文件,作为一个新的partition放在HDFS上,最后使用Impala等计算引擎进行查询,生成最终报表。

HBase数据存储格式

HBase数据存储格式

HBase数据存储格式

好的数据结构,对于检索数据,插⼊数据的效率就会很⾼。

常见的数据结构

B+树

根节点和枝节点⾮常easy,分别记录每⼀个叶⼦节点的最⼩值,并⽤⼀个指针指向叶⼦节点。

叶⼦节点⾥每⼀个键值都指向真正的数据块。每⼀个叶⼦节点都有前指针和后指针,这是为了做范围查询时。叶⼦节点间能够直接跳转。从⽽避免再去回溯⾄枝和根节点。

特点:

1、有n棵⼦树的结点中含有n个keyword,每⼀个keyword不保存数据,仅仅⽤来索引,全部数据都保存在叶⼦节点。

2、所有的叶⼦结点中包括了所有keyword的信息,及指向含这些keyword记录的指针。且叶⼦结点本⾝依keyword的⼤⼩⾃⼩⽽⼤顺序链接。

3、全部的⾮终端结点能够看成是索引部分。结点中仅含其⼦树(根结点)中的最⼤(或最⼩)keyword。

缺点:

通常数据量会⾮常⼤,磁盘中的数据採⽤这样的分页形式的话。就会⽐較多。⾮常有可能存储的数据在两个页表其中不连续。相隔⾮常远,这样的顺序查询的⽅式就会⽐較慢。

B+树最⼤的性能问题是会产⽣⼤量的随机IO。随着新数据的插⼊。叶⼦节点会慢慢分裂。逻辑上连续的叶⼦节点在物理上往往不连续。甚⾄分离的⾮常远,但做范围查询时,会产⽣⼤量读随机IO。

对于⼤量的随机写也⼀样,举⼀个插⼊key跨度⾮常⼤的样例。如7->1000->3->2000 … 新插⼊的数据存储在磁盘上相隔⾮常远,会产⽣⼤量的随机写IO。

从上⾯能够看出,低下的磁盘寻道速度严重影响性能。

LSM树

为了更好的说明LSM树的原理,以下举个⽐較极端的样例:

网易视频云技术分享:HBase BlockCache系列-性能对比测试报告

网易视频云技术分享:HBase BlockCache系列-性能对比测试报告

网易视频云技术分享:HBaseBlockCache系列-性能对比测试报告

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PAAS 服务,在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。

HBaseBlockCache系列文章到了终结篇,几个主角的是是非非也该有个了断了,在SlabCache被早早地淘汰之后,站在华山之巅的也就仅剩LRU君(LRUBlockCache)和CBC君(binedBlockCache)。谁赢谁输,我说了不算,你说了也不算,那就来让数据说话。这篇文章主要对比LRU君和CBC君(offheap模式)分别在四种场景下几种指标(GC、Throughput、Latency、CPU、IO等)的表现情况。四种场景分别是缓存全部命中、少大部分缓存命中、少量缓存命中、缓存基本未命中。

需要注意的是,本文的所有数据都来自社区文档,在这里分享也只是给大家一个参考,更加详细的测试数据可以阅读文章《paring BlockCache Deploys》和HBASE-11323附件报告。

说明:本文所有图都以时间为横坐标,纵坐标为对应指标。每X图都会分别显示LRU 君和CBC君的四种场景数据,总计八种场景,下面数据表示LRU君的四种场景分布在时间段21:36:39~22:36:40,CBC君的四种场景分布在时间段23:02:16~00:02:17,看图的时候需要特别注意。

hfile格式详细介绍

hfile格式详细介绍

HFile: A Block-Indexed File Format

to Store Sorted Key-Value Pairs

Sep 10, 2009 Schubert Zhang (schubert.zhang@)

1. Introduction

HFile is a mimic of Google’s SSTable. Now, it is available in Hadoop HBase-0.20.0. And the previous releases of HBase temporarily use an alternate file format – MapFile[4], which is a common file format in Hadoop IO package. I think HFile should also become a common file format when it becomes mature, and should be moved into the common IO package of Hadoop in the future.

Following words of SSTable are from section 4 of Google’s Bigtable paper.

The Google SSTable file format is used internally to store Bigtable data. An SSTable provides a persistent, ordered immutable map from keys to values, where both keys and values are arbitrary byte strings. Operations are provided to look up the value associated with a specified key, and to iterate over all key/value pairs in a specified key range. Internally, each SSTable contains a sequence of blocks (typically each block is 64KB in size, but this is configurable). A block index (stored at the end of the SSTable) is used to locate blocks; the index is loaded into memory when the SSTable is opened. A lookup can be performed with a single disk seek: we first find the appropriate block by performing a binary search in the in-memory index, and then reading the appropriate block from disk. Optionally, an SSTable can be completely mapped into memory, which allows us to perform lookups and scans without touching disk.[1]

网易视频云技术分享:HBase - 建表语句解析

网易视频云技术分享:HBase - 建表语句解析

网易视频云技术分享:HBase -建表语句解析

网易视频云是网易公司旗下的视频云服务产品,以Paas服务模式,向开发者提供音视频编解码SDK和开放API,助力APP接入音视频功能。现在,网易视频云的技术专家给大家分享一篇技术性文章:HBase -建表语句解析。

像所有其他数据库一样,HBase也有表的概念,有表的地方就有建表语句,而且建表语句还很大程度上决定了这张表的存储形式、读写性能。比如我们熟悉的MySQL,建表语句中数据类型决定了数据的存储形式,主键、索引则很大程度上影响着数据的读写性能。虽然HBase没有主键、索引这些概念,但在HBase的世界里,有些东西和它们一样重要!

废话不说,直接奉上一条HBase建表语句,来为各位看官分解剖析:

create

'NewsClickFeedback',{NAME=>'Toutiao',VERSIONS=>1,BLOCKCACHE=>true,BLOOMFILTER=> 'ROW',COMPRESSION=>'SNAPPY',TTL => ' 259200 '},{SPLITS =>

['1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']}

上述建表语句表示创建一个表名为“NewsClickFeedback”的表,该表只包含一个列簇“Toutiao”。接下来重点讲解其他字段的含义以及如何正确设置。Note:因为篇幅有限本文并不讲解具体的工作原理,后续会有相关专题对其进行分析。

VERSIONS

hbase数据库工作原理

hbase数据库工作原理

hbase数据库工作原理

HBase是一种分布式、面向列的NoSQL数据库,它建立在Apache Hadoop的HDFS(Hadoop Distributed File System)之上,并利用Hadoop的分布式计算能力。以下是HBase数据库的工作原理的简要介绍:

1. 数据模型:

- HBase采用列族-列-行的数据模型。数据按列族进行组织,每个列族包含多个列,每个列又包含多个版本的单元格。行键(Row Key)用于唯一标识每一行数据。

-列族内的列是动态的,可以根据需要随时添加或删除,而无需预定义表结构。

2. 存储方式:

-HBase的数据存储在HDFS上,将数据水平切分成多个Region,每个Region负责存储一定范围的行键数据。Region 会根据数据量的增长或减少进行自动拆分和合并。

-数据在磁盘上以HFile的形式存储,每个HFile包含按照列族和行键排序的数据块。

3. 架构:

- HBase采用主从架构,包括一个或多个Master节点和多个RegionServer节点。Master节点负责元数据管理、负载均衡和Region的分配等工作。

-RegionServer节点负责实际的数据存储和查询操作,每个RegionServer负责多个Region。

4. 写入过程:

-当应用程序写入数据时,数据会首先被写入内存中的MemStore。当MemStore的大小达到一定阈值时,数据会被刷写到磁盘的HFile中。

-写入的数据同时也会写入Write Ahead Log(WAL),用于保证数据的可靠性和持久化。

hbase.loadincrementalhfiles 参数-概述说明以及解释

hbase.loadincrementalhfiles 参数-概述说明以及解释

hbase.loadincrementalhfiles 参数-概述说明以及

解释

1.引言

1.1 概述

在大数据处理中,HBase作为一种分布式的、面向列的NoSQL数据库,被广泛应用于海量数据存储和实时查询场景。而

hbase.loadincrementalhfiles参数则是HBase中的一个重要参数,用于在数据装载过程中进行性能优化和调整。

该参数主要用于在HBase中,通过将预先生成的HFile文件装载至指定表中来加速数据导入过程。HFile是一种适用于HBase的数据存储格式,它可以事先进行排序、压缩和索引,并且可以按照特定的分区键进行划分,以提高读写操作的效率。

当需要将大量数据导入HBase表中时,使用

hbase.loadincrementalhfiles参数可以避免通过逐条插入数据的方式进行导入,从而大幅提高导入速度。通过预先生成HFile文件,并使用该参数进行装载,可以实现批量导入操作,减少了网络传输和写入操作的开销,有效降低了导入数据的时间和资源消耗。

然而,虽然hbase.loadincrementalhfiles参数在提高导入速度方面具有显著的优势,但其也存在一定的限制和注意事项。在使用该参数时,需要注意表的状态、RegionServer的负载以及网络带宽等因素,以避免对HBase集群的性能和稳定性造成不利影响。

本文将对hbase.loadincrementalhfiles参数进行详细介绍和说明其使用方法,通过对该参数的全面认识和合理使用,可以使数据导入过程更加高效、稳定和可靠。同时,本文还将对该参数进行总结,并给出对其的一些建议,以帮助读者更好地应用和理解hbase.loadincrementalhfiles 参数的作用和价值。

HBase云存储.ppt

HBase云存储.ppt

(1) 商品表 (trade table) ,“产品ID”字段作为主键,这个问题上,可以在 map 阶段,将
每行为一条数据;
两个表格数据根据 “ 产品 ID ” 这个
(2) 支付表 (pay table) ,“产品ID”字段作为主键, 每行为一条数据;
key 分发出去 ,将 “ 商品 ID ” 及 “ 支付 ID ” 封装一下,作为 map
HLog
每个RegionServer中都有一个 HLog对象,HLog是一个实现Write Ahead Log 的类,在每次用户操作写入MemStore的同时,也会写一份数据到HLog文件 中,HLog文件定期会滚动出新的,并删除旧的文件(已持久化到StoreFile中 的数据)。 Store在系统正常工作的前提下是没有问题的,但是在分布式系统环境中,无 法避免系统出错或者宕机,因此一旦RegionServer意外退出,MemStore中的 内存数据将会丢失,于是引入了HLog。 当RegionServer意外终止后,Master会通过Zookeeper感知到,Master首先 会处理遗留的 HLog文件,将其中不同Region的Log数据进行拆分,分别放到 相应region的目录下,然后再将失效的region重新分配,领取到这些region的 RegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此 会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据 恢复。

网易视频云:HBase – 存储文件HFile结构解析

网易视频云:HBase – 存储文件HFile结构解析

网易视频云是网易推出的PaaS视频云服务,主要应用于在线教育、直播秀场、远程医疗、企业协作等领域。今天,网易视频云技术专家与大家分享一下:HBase –存储文件HFile结构解析。

HFile是HBase存储数据的文件组织形式,参考BigTable的SSTable和Hadoop的TFile 实现。从HBase开始到现在,HFile经历了三个版本,其中V2在0.92引入,V3在0.98引入。HFileV1版本的在实际使用过程中发现它占用内存多,HFile V2版本针对此进行了优化,HFile V3版本基本和V2版本相同,只是在cell层面添加了Tag数组的支持。鉴于此,本文主要针对V2版本进行分析,对V1和V3版本感兴趣的同学可以参考其他信息。

HFile逻辑结构

HFile V2的逻辑结构如下图所示:

文件主要分为四个部分:Scanned block section,Non-scanned block section,Opening-time data section和Trailer。

Scanned block section:顾名思义,表示顺序扫描HFile时所有的数据块将会被读取,包括Leaf Index Block和Bloom Block。

Non-scanned block section:表示在HFile顺序扫描的时候数据不会被读取,主要包括Meta Block和Intermediate Level Data Index Blocks两部分。

Load-on-open-section:这部分数据在HBase的region server启动时,需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index。

网易视频云技术分享H精选se优化实战精编

网易视频云技术分享H精选se优化实战精编

网易视频云技术分享H 精选s e优化实战精编

Document number:WTT-LKK-GBB-08921-EIGG-22986

网易视频云技术分享:HBase优化实战

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PAAS服务,在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在,网易视频云的技术专家给大家分享一则技术文:HBase优化实战。

背景

Datastream一直以来在使用HBase分流日志,每天的数据量很大,日均大概在80亿条,10TB的数据。对于像Datastream这种数据量巨大、对写入要求非常高,并且没有复杂查询需求的日志系统来说,选用HBase作为其数据存储平台,无疑是一个非常不错的选择。

HBase是一个相对较复杂的分布式系统,并发写入的性能非常高。然而,分布式系统从结构上来讲,也相对较复杂,模块繁多,各个模块之间也很容易出现一些问题,所以对像HBase这样的大型分布式系统来说,优化系统运行,及时解决系统运行过程中出现的问题也变得至关重要。正所谓:“你”若安好,便是晴天;“你”若有恙,我便没有星期天。

历史现状

应用反应经常会过段时间出现数据写入缓慢,导致应用端数据堆积现象,是否可以通过增加机器数量来解决其实,那个时候,我们本身对HBase也不是很熟悉,对HBase的了解,也仅仅在做过一些测试,了解一些性

能,对内部结构,实现原理之类的基本上都不怎么清楚。于是刚开始几天,各种问题,每天晚上拉着一男一起摸索,顺利的时候,晚上8,9点就可以暂时搞定线上问题,更多的时候基本要到22点甚至更晚(可能那个时候流量也下去了),通过不断的摸索,慢慢了解HBase在使用上的一些限制,也就能逐渐解决这一系列过程中发现的问题。后面挑几个相对比较重要,效果较为明显的改进点,做下简单介绍。

一张图看懂HBase

一张图看懂HBase
HMaster
HBase Client
ZookeepBiblioteka Baidur
HRegionServer内部管 理了一系列HRegion对 象,每个HRegion对应 Table中的一个Region。 HRegion由多个Store组 成。每个Store对应 Table中的一个Column Family的存储,即一个 Store管理一个Region上 的一个列族(CF)。每 个Store包含一个 MemStore和0到多个 StoreFile。Store是 HBase的存储核心,由 MemStore 和 StoreFile 组成。
4
HBase数据模型
存储在HBase表每一行数据都有可排序的关键字(Row Key)和任意列项(Column & Column Family)。在HBase中,仅能通过主键(Row Key)和主键版本号来检索数据, 仅支持单行事务。下面以HBase存储搜索引擎的网页为例:
Row Key "com.cnn.www" "com.cnn.www" "com.cnn.www" "com.cnn.www" "com.cnn.www" Time Stamp t9 t8 t6 t5 t3 contents:html = "<html>..." contents:html = "<html>..." contents:html = "<html>..." ColumnFamily : contents ColumnFamily : anchor anchor:cnnsi.com = "CNN" anchor:my.look.ca = "CNN.com"

关于HFile的存储结构梳理以及快速定位rowkey

关于HFile的存储结构梳理以及快速定位rowkey

一、HFile结构介绍

为了支持数据的随机查询,HFile结构分为六个部分:

1、数据块–保存表中的数据,每一个数据块由块头和一些keyValue(record)组成,key的值是严格按照顺序存储的。块大小默认为64K(由建表时创建cf时指定或者HColumnDescriptor.setBlockSize(size)),这一部分可以压缩存储。在查询数据时,是以数据块为单位从硬盘load到内存。查找数据时,是顺序的遍历该块中的keyValue对。

2、元数据块 (可选的)–保存用户自定义的kv对,可以被压缩。比如booleam filter 就是存在元数据块中的,该块只保留value值,key值保存在元数据索引块中。每一个元数据块由块头和value值组成。可以快速判断key是都在这个HFile中。

3、File Info–Hfile的元信息,不被压缩,用户也可以在这一部分添加自己的元信息。

4、数据索引块–Data Block的索引,每条索引的key是被索引的block的第一条记录的key(格式为:头信息,数据块offset数据块大小块第一个记录的key,........)。

这个参数控制hfile中索引块的大小,默认值是128K,也就是说当索引的信息超过128K后,就会新分配一个索引块。hbase对于hfile的访问都是通过索引块来实

现的,通过索引来定位所要查的数据到底在哪个数据块里面。hfile中的索引块可以分成三中,根索引块,枝索引块,叶索引块。根索引块是一定会有的,但是如果hfile 中的数据块比较少的话,枝索引块和叶索引块就可能不存在。当单个的索引块中没有办法存储全部的数据块的信息时,索引块就会分裂,会产生叶索引块和根索引块,根索引块是对叶索引块的索引,如果数据块继续增加就会产生枝索引块,整个索引结果的层次也会加深。

harefile 解析

harefile 解析

harefile 解析

摘要:

1.harefile 文件的介绍

2.harefile 文件的解析原理

3.harefile 文件的优势和应用

4.harefile 文件的常见问题及解决方案

5.总结

正文:

Harefile 文件解析

Harefile 文件是一种新型的数据存储格式,它将数据存储为一种简洁、高效的格式,广泛应用于大数据处理和分布式存储领域。Harefile 文件解析是数据处理过程中的关键环节,对于正确理解和处理数据具有重要意义。本文将对Harefile 文件的解析原理、优势和应用进行详细阐述,并针对常见的解析问题给出解决方案。

一、Harefile 文件的介绍

Harefile 文件是一种专门为大数据处理而设计的存储格式,具有存储空间小、读写速度快、易于解析等优点。Harefile 文件通常包含多个数据块,每个数据块都包含一定数量的数据记录。数据记录之间通过某种特定的分隔符进行分隔,使得解析过程更加简单。

二、Harefile 文件的解析原理

Harefile 文件的解析原理主要包括以下几个步骤:

1.打开文件并读取内容

2.根据文件头信息判断文件格式

3.按数据块分隔符分割文件内容

4.解析数据块,提取有效数据

5.将提取的数据按照预定的格式进行输出

三、Harefile 文件的优势和应用

Harefile 文件的优势主要体现在以下几个方面:

1.存储空间小:通过高效的编码方式,使得文件在保证数据完整性的同时,占用较少的存储空间。

2.读写速度快:Harefile 文件采用特定的存储结构,使得读写速度大大提高,适用于大数据处理场景。

网易视频云:网易HBase基准性能测试之准备篇

网易视频云:网易HBase基准性能测试之准备篇

网易视频云:网易HBase基准性能测试之准备篇

网易视频云是网易推出是PAAS级视频云服务,致力于为客户提供真正易用的视频云服务,目前已经广泛应用于在线教育、秀场直播、游戏直播、远程医疗等领域,在网易内部,也有广泛运用视频云的产品,比如网易新闻直播、网易BOBO、网易青果等。而网易视频云的技术团队全部来自网易杭州研究院十多年的技术骨干,现在,由网易视频云的技术专家给大家分享一则技术文:网易HBase基准性能测试之准备篇。

本次测试主要评估线上HBase的整体性能,量化当前HBase的性能指标,对各种场景下HBase性能表现进行评估,为业务应用提供参考。本篇文章主要介绍此次测试的基本条件,测试结果和分析可以阅读文章《网易HBase基准性能测试之结果篇》测试环境

测试环境包括测试过程中HBase集群的拓扑结构、以及需要用到的硬件和软件资源,硬件资源包括:测试机器配置、网络状态等等,软件资源包括操作系统、HBase相关软件以及测试工具等。

集群拓扑结构

本次测试中,测试环境总共包含4台SA5212H2物理机作为数据存储。生成数据的YCSB 程序与数据库并不运行在相同的物理集群。

单台机器主机硬件配置

软件版本信息

测试工具

YCSB全称Yahoo! Cloud Serving Benchmark,是Yahoo公司开发的专门用于NoSQL测试的基准测试工具。github地址:https:///brianfrankcooper/YCSB YCSB支持各种不同的数据分布方式

1. Uniform:等概论随机选择记录

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

网易视频云是网易推出的PaaS视频云服务,主要应用于在线教育、直播秀场、远程医疗、企业协作等领域。今天,网易视频云技术专家与大家分享一下:HBase –存储文件HFile结构解析。

HFile是HBase存储数据的文件组织形式,参考BigTable的SSTable和Hadoop的TFile 实现。从HBase开始到现在,HFile经历了三个版本,其中V2在0.92引入,V3在0.98引入。HFileV1版本的在实际使用过程中发现它占用内存多,HFile V2版本针对此进行了优化,HFile V3版本基本和V2版本相同,只是在cell层面添加了Tag数组的支持。鉴于此,本文主要针对V2版本进行分析,对V1和V3版本感兴趣的同学可以参考其他信息。

HFile逻辑结构

HFile V2的逻辑结构如下图所示:

文件主要分为四个部分:Scanned block section,Non-scanned block section,Opening-time data section和Trailer。

Scanned block section:顾名思义,表示顺序扫描HFile时所有的数据块将会被读取,包括Leaf Index Block和Bloom Block。

Non-scanned block section:表示在HFile顺序扫描的时候数据不会被读取,主要包括Meta Block和Intermediate Level Data Index Blocks两部分。

Load-on-open-section:这部分数据在HBase的region server启动时,需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index。

Trailer:这部分主要记录了HFile的基本信息、各个部分的偏移值和寻址信息。

HFile物理结构

如上图所示,HFile会被切分为多个大小相等的block块,每个block的大小可以在创建表列簇的时候通过参数blocksize=> ‘65535’进行指定,默认为64k,大号的Block有利于顺序Scan,小号Block利于随机查询,因而需要权衡。而且所有block块都拥有相同的数据结构,如图左侧所示,HBase将block块抽象为一个统一的HFileBlock。HFileBlock支持两种类型,一种类型不支持checksum,一种不支持。为方便讲解,下图选用不支持checksum的HFileBlock内部结构:

上图所示HFileBlock主要包括两部分:BlockHeader和BlockData。其中BlockHeader 主要存储block元数据,BlockData用来存储具体数据。block元数据中最核心的字段是BlockType字段,用来标示该block块的类型,HBase中定义了8种BlockType,每种BlockType 对应的block都存储不同的数据内容,有的存储用户数据,有的存储索引数据,有的存储meta元数据。对于任意一种类型的HFileBlock,都拥有相同结构的BlockHeader,但是BlockData结构却不相同。下面通过一张表简单罗列最核心的几种BlockType,下文会详细针对每种BlockType进行详细的讲解:

HFile中Block块解析

上文从HFile的层面将文件切分成了多种类型的block,接下来针对几种重要block进行详细的介绍,因为篇幅的原因,索引相关的block不会在本文进行介绍,接下来会写一篇单独的文章对其进行分析和讲解。首先会介绍记录HFile基本信息的TrailerBlock,再介绍用户数据的实际存储块DataBlock,最后简单介绍布隆过滤器相关的block。

Trailer Block

主要记录了HFile的基本信息、各个部分的偏移值和寻址信息,下图为Trailer内存和磁盘中的数据结构,其中只显示了部分核心字段:

HFile在读取的时候首先会解析Trailer Block并加载到内存,然后再进一步加载LoadOnOpen区的数据,具体步骤如下:

1. 首先加载version版本信息,HBase中version包含majorVersion和minorVersion两部分,前者决定了HFile的主版本:V1、V2 还是V3;后者在主版本确定的基础上决定是否支持一些微小修正,比如是否支持checksum等。不同的版本决定了使用不同的Reader对象对HFile进行读取解析

2. 根据Version信息获取trailer的长度(不同version的trailer长度不同),再根据trailer 长度加载整个HFileTrailer Block

3. 最后加载load-on-open部分到内存中,起始偏移地址是trailer中的LoadOnOpenDataOffset字段,load-on-open部分的结束偏移量为HFile长度减去Trailer长度,load-on-open部分主要包括索引树的根节点以及FileInfo两个重要模块,FileInfo是固定长度的块,它纪录了文件的一些Meta信息,例如:AVG_KEY_LEN, AVG_VALUE_LEN,

LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等;索引树根节点放到下一篇文章进行介绍。

Data Block

DataBlock是HBase中数据存储的最小单元。DataBlock中主要存储用户的KeyValue数据(KeyValue后面一般会跟一个timestamp,图中未标出),而KeyValue结构是HBase存储的核心,每个数据都是以KeyValue结构在HBase中进行存储。KeyValue结构在内存和磁盘中可以表示为:

每个KeyValue都由4个部分构成,分别为key length,value length,key和value。其中key value和value length是两个固定长度的数值,而key是一个复杂的结构,首先是rowkey 的长度,接着是rowkey,然后是ColumnFamily的长度,再是ColumnFamily,最后是时间戳和KeyType(keytype有四种类型,分别是Put、Delete、DeleteColumn和DeleteFamily),value就没有那么复杂,就是一串纯粹的二进制数据。

BloomFilter Meta Block & Bloom Block

相关文档
最新文档