1.一文掌握HBase核心知识以及面试问题
2.RaftKeeper v2.1.0版本发布,性能大幅提升!
3.[知识讲解篇-189] hbase 参数解析,史上最全(二)
4.HBase最佳实践 – Scan用法大观园
5.å¦ä½å¨windowså¹³å°ä¸ç¨Eclipseè°è¯è¿è¡HBase
一文掌握HBase核心知识以及面试问题
HBase核心知识与面试问题解析
HBase基础与架构
HBase是用于存储海量结构化与半结构化数据的分布式、面向列的key-value存储系统。它基于Google Bigtable实现,但在底层存储、独家指标源码数据处理引擎及协同服务方面有所不同。表结构与关键概念
HBase以表的形式存储数据至HDFS,建表时仅需定义列簇,插入数据时可指定任意多个列至指定列簇。其核心要素包括:行键、列簇、列与时间戳。行键(row key)
行键用于唯一标识一行数据,同时指导数据排序,建议设计时考虑经常一起读取的数据存放在一起。列簇(column family)
表可包含多个列簇,每个列簇内可有多个列,需在建表时定义列簇,但无需明确列。列族的统计与访问控制均在此层级进行。过多列簇会导致更多IO操作与文件寻址时间。列(qualifier)
列以字节数组形式存储,无类型与长度限制,与列簇结合表示具体数据。Cell
Cell由{ row key, column family:qualifier, version}唯一确定,存储单元以字节码形式。时间戳(timestamp)
用于标记数据版本,便于读取最新值,并通过时间戳索引数据。时间戳类型为位整数,非源码是什么可由客户端指定或HBase自动赋值。HBase系统架构
HBase集群包含主节点HMaster、从节点RS及Zookeeper(ZK)。HMaster维护表与region的元数据,RS负责数据存储。HMaster
HMaster是集群的管理节点,负责表与region的元数据管理,不参与数据IO。其容错机制包括主备切换与数据恢复。RegionServer(RS)
RS是集群的工作节点,负责数据存储与region分配。其关键职责包括region分配、负载均衡与容错机制。Zookeeper
ZK作为集群管理与协调服务,RS与HMaster通过ZK进行状态监控与数据同步。HBase数据存储
HBase通过负载均衡将数据分散存储于不同RS,底层基于HDFS实现随机读写。数据通过预写日志(WAL log)和LSM树进行容错与恢复。预写日志(WAL log)
预写日志用于记录数据变更,确保数据一致性。RS按需处理内存中的数据,完成数据持久化。LSM树
LSM树结合预写日志与内存存储,实现高效的数据更新与查询。通过合并小文件优化性能。HBase查询机制与优化
HBase查询主要通过-ROOT-和META表进行寻址。优化方面包括布隆过滤器与协处理器的使用。布隆过滤器(Bloom Filter)
布隆过滤器用于提高查询效率,降低内存和存储负担,适用于特定访问模式。不死uboot源码下载协处理器
协处理器提供事件处理与扩展能力,用于实现数据处理与自定义命令。数据迁移与备份
HBase提供多种数据迁移与备份方式,包括distcp、copytable、replication、Export/Import与snapshot。distcp与copytable
distcp与copytable通过MapReduce实现文件与表的同步,但需要停写操作。replication
通过复制WAL日志实现异步数据同步,需开启并注意数据一致性。Export/Import
Export将HBase表转换为序列文件,Import时需先创建目标表。snapshot
通过快照方式实现数据迁移与备份,效率高,推荐使用。面试问题解答
掌握HBase核心知识,包括架构、查询机制、数据存储与迁移备份方法,可有效应对面试中涉及HBase的问题。 了解更多内容,建议阅读原文《一文掌握HBase核心知识以及面试问题》。RaftKeeper v2.1.0版本发布,性能大幅提升!
RaftKeeper,一款高性能分布式共识服务,以其卓越的性能和对Zookeeper的全面兼容性而闻名。在大数据领域,如ClickHouse和HBase,RaftKeeper被广泛应用于解决Zookeeper性能瓶颈问题。示波器上位机源码相较于Zookeeper,RaftKeeper在大规模应用中的表现更为出色。
在版本v2.1.0中,一系列创新特性被引入,尤其是引入了异步创建snapshot功能。这一版本的亮点在于显著的性能提升:写请求性能提升%,在读写混合场景中,性能更是大幅度提升了%。本文将深入解析v2.1.0版本的改进和优化细节。
性能测试结果显示,使用raftkeeper-bench工具,测试环境为三个节点组成的集群,每个节点配置为核CPU、GB内存和GB存储空间。测试对象包括RaftKeeper v2.1.0、RaftKeeper v2.0.4和ZooKeeper 3.7.1,均采用默认配置。
测试分为两组:第一组纯create操作,结果显示,RaftKeeper v2.1.0相较于v2.0.4性能提升了%,相较于ZooKeeper性能提升了%。第二组请求比例为create-1%、set-8%、get-%、list-%、delete-1%,其中list请求结果包含个子节点,每个子节点大小为字节;get、set、create请求的推客app 源码节点value大小为字节。结果显示,RaftKeeper v2.1.0相较于v2.0.4性能提升了%,相较于ZooKeeper性能提升了%。
v2.1.0版本在测试中avgRT和TP指标均优于v2.0.4版本,具体可以参考测试报告。
接下来,我们将从工程细节的角度,介绍v2.1.0版本的优化点。
1. 响应并行序列化:RaftKeeper广泛应用于ClickHouse中,测试发现ResponseThread线程消耗大量CPU时间片,其中大约三分之一时间片用于序列化响应。通过将响应的序列化交给IO线程执行,以并发方式提高吞吐量。优化后,TPS增加了%,AvgRT降低了%。
2. 优化List请求:测试发现List请求处理几乎消耗了request-processor线程的所有CPU时间片。通过优化内存分配和vector插入操作,List请求处理在CPU的占比从5.%下降到3.%,TPS从.8w/s增长到.9w/s,同时TP更低。
3. 优化无用的系统调用:通过bpftrace对RaftKeeper进行profile,发现大量的getsockname和getsockopt系统调用占用了开销。排查发现是在打印日志时错误进行了调用。优化后,这些系统调用不再存在。
4. 线程池优化:针对benchmark测试中发现的条件变量等待调用占CPU时间片超过%的情况,通过去掉线程池,单线程处理读请求,TPS提升了%。
在Snapshot优化方面,v2.1.0支持异步snapshot功能,将创建snapshot的过程分为主线程处理和后台序列化到磁盘,显著降低用户阻塞时间,同时消耗约%的内存。进一步优化DataTree拷贝过程,采用向量化和prefetch,将拷贝时间从4.5s降低到3.5s。
在Snapshot加载速度优化中,改进了加载流程,采用并行化处理节点存储和父子关系构建,将加载时间从s降低到s,通过锁优化、snapshot格式优化和减少数据拷贝,最终将加载时间降低到s。
上线效果方面,通过将ClickHouse集群从ZooKeeper升级到RaftKeeper v2.0.4和v2.1.0,QPS分别为w/s和更优的性能,特别是在List请求场景中,v2.1.0展现出显著优势。
[知识讲解篇-] hbase 参数解析,史上最全(二)
zookeeper.znode.acl.parent
根节点用于访问控制列表,通常默认即可。
hbase.zookeeper.peerport
Zookeeper成员间交互端口,通常默认即可。
hbase.zookeeper.leaderport
Zookeeper用于选举主节点的端口,通常默认即可。
hbase.zookeeper.property.initLimit
从Zookeeper配置文件zoo.cfg读取的属性,初始同步阶段的时间长度,默认为*tickTime,tickTime为滴答单位。
hbase.zookeeper.property.syncLimit
从Zookeeper配置文件zoo.cfg读取的属性,发送请求与获得确认之间的最大时间间隔,默认为5*tickTime。
hbase.zookeeper.property.dataDir
Zookeeper数据snapshot存储目录。
hbase.zookeeper.property.clientPort
从Zookeeper配置文件zoo.cfg读取的属性,客户端连接端口,通常默认为。
hbase.zookeeper.property.maxClientCnxns
从Zookeeper配置文件zoo.cfg读取的属性,单个客户端可连接的zookeeper成员的最大数量,默认为。
hbase.client.retries.number
客户端操作的最大重试次数,与重试时间间隔相关,默认为。
hbase.client.max.total.tasks
一个HTable实例可以提交给集群的最大并发任务数,默认为。
hbase.client.max.perserver.tasks
一个HTable实例给单个region server提交的最大并发任务数,默认为2。
hbase.client.max.perregion.tasks
客户端对于单个region维护的最大并发连接数。
hbase.client.perserver.requests.threshold
所有客户端线程对单个服务器的最大并发挂起请求数,默认值为,防止慢速region server占用用户线程。
hbase.client.scanner.caching
scanner一次从服务端获取的行数,默认为Integer.MAX_VALUE,以充分利用网络而不受具体行数限制,最大值设置可根据需要调整。
hbase.client.keyvalue.maxsize
HBase列族的最大值,默认为M。
hbase.server.keyvalue.maxsize
单个cell的最大允许大小,包括value和所有key组件,值为0或负数将禁用检查,默认为MB。
hbase.client.scanner.timeout.period
客户端scanner租期时间,以毫秒为单位。
hbase.bulkload.retries.number
最大重试次数,原子批量加载尝试的迭代次数,默认为。
hbase.compaction.after.bulkload.enable
批量加载后立即触发compaction,默认为false。
hbase.master.balancer.maxRitPercent
均衡时允许的最大region迁移比例,值默认为1.0,无限制。设置为0.表示最多1%的region在迁移,集群平衡时可用性至少为%。
hbase.balancer.period
Master上运行均衡器的周期,以毫秒为单位,默认值为。
hbase.regions.slop
当任何regionserver的平均加权值超过平均值加上平均值与slop的乘积时,需要进行均衡,默认值取决于负载均衡器类型。
hbase.normalizer.period
Master上运行normalizer的周期,以毫秒为单位,默认值为。
hbase.normalizer.split.enabled
在normalization过程中是否启用split,默认为true。
hbase.normalizer.merge.enabled
在normalization过程中是否启用merge,默认为true。
hbase.normalizer.min.region.count
考虑合并normalization的表中region数量的最小值,默认值为3。
hbase.normalizer.merge.min_region_age.days
region被考虑合并的最小天数,默认值为3天。
hbase.normalizer.merge.min_region_size.mb
考虑合并的region的最小大小,以完整MB为单位,默认值为1MB。
HBase最佳实践 – Scan用法大观园
HBase 从用法的角度来讲其实乏陈可善,所有更新插入删除基本一两个 API 就可以搞定。要说稍微有点复杂的话,Scan 的用法可能会多一些说头。扫描用法包括 ScanAPI、TableScanMR 以及 SnapshotScanMR。这三种用法各有特点,适用于不同的应用场景。以下将分别对这三种用法进行解析,并对比它们的原理、效率和最佳实践,以帮助读者更好地理解 Scan 的使用。
Scan API 是最常见的用法,基于官方 API 文档。Scan 的工作原理涉及到客户端代码中的 ResultScanner 对象,实际操作中,客户端不断调用 next 请求获取数据,这个过程可以分为几个步骤。这种设计模式在大数据量场景下可能会遇到一些挑战,主要体现在效率和异常处理方面。
ScanAPI 的应用场景通常局限于 OLTP(在线事务处理)场景,对于需要从 HBase 扫描大量数据进行 OLAP(在线分析处理)分析的业务,可以考虑使用 TableScanMR 和 SnapshotScanMR。TableScanMR 是 ScanAPI 的并行化版本,通过将扫描请求分解为多个子扫描,提高了扫描效率。SnapshotScanMR 与 TableScanMR 类似,但采用了客户端直接访问 HDFS 的方式,进一步优化了扫描性能。
为了确保扫描操作的高效执行,TableScanMR 和 SnapshotScanMR 都提供了一些最佳实践建议,如设置缓存大小、避免不必要的并行操作等。这些实践有助于优化扫描性能,尤其是在处理大数据量时。
在实际应用中,TableScanMR 和 SnapshotScanMR 都存在一些问题,比如对大 region 的扫描粒度仍然较大,以及在某些情况下生成的 Mapper 较少。为了解决这些问题,需要提供更精细的扫描粒度策略。性能对比显示,SnapshotScanMR 在某些场景下表现出更好的性能,但其当前版本可能仍存在一些不完善之处,需要进一步优化。
总之,Scan 的使用需要根据实际业务需求选择合适的扫描方法,并结合最佳实践来优化性能。通过理解不同扫描方法的原理和特点,开发者可以更有效地利用 HBase 进行数据查询和分析。
å¦ä½å¨windowså¹³å°ä¸ç¨Eclipseè°è¯è¿è¡HBase
ããæä½æ¥éª¤å¦ä¸ï¼ãã1.ä¸è½½åå®è£ cygwinï¼
ãã2.ä¸è½½æ°çZookeeperå åHBaseå ï¼è¿éZooKeeperçæ¬ä¸º3.3.1ï¼HBaseçæ¬ä¸º0..4
ãã3.æå©ç¨å®ä»¬çæºç å å¨Eclipseä¸çæ2个ç¬ç«çProject,注æï¼zookeeperå·¥ç¨ï¼è¦æé£ä¸ªconfç®å½å å ¥å°å·¥ç¨çsrcä¸å»
ãã4.ä¿®æ¹zookeeperå·¥ç¨ä¸çconfç®å½ä¸çzoo.cfgæ件ï¼ä¾åå¦ä¸ï¼
ãã# The number of milliseconds of each tick
ããtickTime=
ãã# the directory where the snapshot is stored.
ããdataDir=D:/zookeeper-3.3.1/data
ãã# the port at which the clients will connect
ããclientPort=
ããå°±æ¯ç»zookeeperæå®æ件åæ¾çå°æ¹ä»¥å端å£
ãã5.å¯å¨zookeeper
ããå¨Eclipseä¸æ°å»ºä¸ä¸ªRun configï¼main class为ï¼org.apache.zookeeper.server.quorum.QuorumPeerMain
ããå¯å¨çç¨åºåæ°ä¸ºï¼D:/workspace/zookeeper3.3.1/conf/zoo.cfg
ããå¯å¨çèææºåæ°ä¸ºï¼
ãã-Dzookeeper.log.dir=D:/workspace/zookeeper3.3.1/log
ãã-Dzookeeper.root.logger=INFO,CONSOLE
ããå¦å¾æ示ï¼
ãã好äºï¼è¿æ ·å°±å¯ä»¥å¨Eclipseä¸æZooKeeperå¯å¨èµ·æ¥äºã
ãã6.ä¿®æ¹HBase projectä¸çä¸ä¸ªç±»
ããorg.apache.hadoop.hbase.LocalHBaseCluster
ããæ¾å°å®çmainå½æ°ï¼æmainå½æ°æ¹æä¸
ããpublic static void main(String[] args) throws IOException {
ããHBaseConfiguration conf = new HBaseConfiguration();
ããconf.set("hbase.zookeeper.quorum", "localhost");
ããconf.set("hbase.zookeeper.property.clientPort", "");
ããLocalHBaseCluster cluster = new LocalHBaseCluster(conf,1);
ããcluster.startup();
ãã}ãã
ãã注æè¡ï¼LocalHBaseCluster cluster = new LocalHBaseCluster(conf,1); æé å½æ°ä¸ç1æ¯ä»£è¡¨Region serverç个æ°ï¼å¨è¿éåªæ³èµ·ä¸ä¸ªregion server.
ãã7.ä¿®æ¹HBaseçé ç½®æ件
ããå¨HBase projectä¸çsrcä¸å¯ä»¥çå°hbase-default.xmlåhbase-site.xml两个æ件ï¼æ¹åªä¸ªé½å¯ä»¥ãç´æ¥å¨hbase-default.xmlæ¹çï¼éè¦çæ¯ä¸é¢3个å±æ§hbase.rootdirï¼hbase.cluster.distributedï¼hbase.tmp.dirï¼
ããæhbase.rootdirï¼hbase.tmp.diré½æåäºæ¬å°çç®å½ï¼å½ç¶å¯ä»¥æ ¹æ®èªå·±çéè¦è°æ´,å½ç¶æ ¼å¼ä¸å®ä¸æ ·åã
ãã<property>
ãã<name>hbase.rootdir</name>
ãã<value>file:///D:/hbase-0..3/data </value>
ãã<description>The directory shared by region servers.
ããShould be fully-qualified to include the filesystem to use.
ããE.g: hdfs://NAMENODE_SERVER:PORT/HBASE_ROOTDIR
ãã</description>
ãã</property>
ãã<property>
ãã<name>hbase.cluster.distributed</name>
ãã<value>false </value>
ãã<description>The mode the cluster will be in. Possible values are
ããfalse: standalone and pseudo-distributed setups with managed Zookeeper
ããtrue: fully-distributed with unmanaged Zookeeper Quorum (see hbase-env.sh)
ãã</description>
ãã</property>
ãã<property>
ãã<name>hbase.tmp.dir</name>
ãã<value>D:/hbase-0..3/tmp </value>
ãã<description>Temporary directory on the local filesystem.</description>
ãã</property>
ãã<property>ãã
ãã8.å¯å¨HBaseï¼ç´æ¥run org.apache.hadoop.hbase.LocalHBaseClusterå°±å¯ä»¥ï¼run configä¸éè¦æ²¡æä»ä¹å«çé ç½®ãå½ç¶å°±ä¹å¯ä»¥debugäºã