企业官网建设流程全解析

HBase读慢这件事，十次里有七次不是某一个环节的问题。拿到一个“读超时”反馈，先查客户端连接、再查RegionServer GC、最后查HFile数量，这一套组合拳下来，往往能定位到根因。但如果你对HBase读流程的理解停留在“给RegionServer发个请求，它把数据返回给我”，那排查时就会像盲人摸象——一看meta表、二看BlockCache、三看Handler，每个地方都有嫌疑，每个地方都解释不了全部现象。

这篇文章我把HBase读流程从客户端请求到数据返回这条链路完整拆开，讲清楚每个环节做了什么、为什么这么做、卡住时会有什么表现，也会把生产环境里踩过的坑和调试思路一并放进去。写这篇的初衷是给自己做个系统梳理，也希望能帮到正在用HBase、遇到过读超时或者准备面试的朋友。

1. 读流程全景：从一次Get看全局

1.1 一次get背后是“四层接力”

当客户端执行table.get(new Get(Bytes.toBytes("user_1001")))时，过程并不像表面上那样“把rowkey发给某个服务器”。HBase是分布式系统，一张表的数据按rowkey范围被切成多个Region，由不同的RegionServer提供读写服务。客户端拿到rowkey之后，第一件事不是发请求，而是先搞清楚：这个rowkey落在哪个Region？这个Region现在由哪台RegionServer在管？

整个链路我习惯分成四层，叫它“四层接力”：

1. 客户端连ZooKeeper，读取hbase:meta系统表所在的位置；
2. 客户端通过meta表找到目标Region所在RegionServer；
3. 客户端向目标RegionServer发起真正的get RPC请求；
4. RegionServer内部完成Region定位、Scanner构建、HFile读取和合并，返回结果。

多数人把注意力都放在第3、4步，觉得读流程就是RegionServer内部的事。但客户端侧那两步寻址动作，恰恰是很多诡异延迟和超时的源头。比如客户端刚重启、本地缓存是空的，第一次读至少多两次RTT；比如Region因为split或balance被移走了，客户端还拿着旧地址请求，就要等一个NotServingRegionException触发重试。这些跟RegionServer内部扫描快慢没关系，但会直接表现为读延迟飙升。

生产上客户端会在第一次请求后就把Region位置缓存住，所以长期运行的业务很少每次都查ZooKeeper。但这个缓存什么时候失效、失效后如何重建，才是很多“间歇性读超时”的真正答案。

1.2 读可见性：为什么必须合并三个数据源

RegionServer接收到读请求后，需要在一个Region的某个ColumnFamily对应的Store里找数据。Store里的数据，某一时刻可能同时存在于三处。

• MemStore：写路径的缓冲区，最新写入的数据还在内存，还没flush成HFile；
• BlockCache：最近被读过的HFile数据块缓存，命中它可以省掉磁盘IO；
• HFile：落盘的数据文件，可能有多个，同一个rowkey的不同版本会分散在多个文件里。

读请求必须把这三个来源的数据合并，才能返回给客户端一份一致的结果。这里最核心的难点是内存和磁盘数据之间的版本关系。一条数据先写入一次，后来又被更新；更新可能已经flush到了某个HFile，旧版本还留在另一个HFile，甚至删除操作也只是往HFile里写一条Delete标记而已。读取方拿到的是多个文件里的多个Cell，它必须按照时间戳和操作类型做排序、合并、过滤，才能决定最终返回哪个版本，又是什么数据按理应当“被删除”。

这块正是HBase读流程里最容易被忽视、却又最影响正确性的部分。HBase用MVCC的ReadPoint机制来控制可见性：每个写入在RegionServer上会拿到一个自增序号，读请求也会带一个读取开始时的序号，只能看到小于等于该序号的那些写入。听起来简单，但并发环境下，如果MemStore快照和HFile之间出现版本乱序，就会产生脏读。所以Scanner在读取MemStore时，不是直接读正在被写入的MemStore，而是读它的一个线程安全快照；而flush操作也会基于快照进行，保证一批数据要么全部进入HFile，要么继续留在内存。

2. 客户端侧定位：从ZooKeeper到目标RegionServer

2.1 客户端初始化：Connection和ZooKeeper

HBase客户端是一个典型的瘦客户端，不参与存储逻辑，只负责“寻址”和“请求转发”。创建Connection时，客户端会先从ZooKeeper上读取/hbase/meta-region-server节点，拿到当前hbase:meta表所在的RegionServer地址。这个节点由HBase的Master和RegionServer共同维护，meta表一旦被移动，节点内容会同步更新。

需要强调一点：ZooKeeper在整个读链路里的角色，仅限于告诉客户端meta表在哪，后续正常的读流程不再直接访问ZooKeeper。因此ZooKeeper集群短暂抖动，已建立连接的客户端不一定会立刻读失败，但一旦meta位置缓存失效、需要重新定位meta表，就会暴露连接异常。

Java API里Connection是线程安全的，官方推荐全局复用，千万不要每次请求都新建。我在实践中见过太多“每个方法里ConnectionFactory.createConnection”的写法，结果RegionServer的连接数暴涨，handler被陌生连接占满，随后其他语言的客户端也开始报“连接被远端重置”之类的错。这不是HBase读流程本身变慢了，而是连接管理混乱造成的连带效应。

2.2 三层寻址：meta表的缓存、更新与失效

客户端内部的RegionLocator维护着一张“rowkey范围 -> RegionServer地址”的映射缓存。第一次读取某一段rowkey时，客户端按下面的逻辑走：

1. 先从本地缓存尝试匹配rowkey所属Region，没命中就走下一步；
2. 定位meta表本身。如果meta表位置也没缓存，就从ZooKeeper读取meta表所在RegionServer；
3. 向meta表所在RegionServer发一个scan/get请求，查出目标Region的位置信息；
4. 更新本地缓存，随后向目标RegionServer发起真正的读请求。

这里有个常见困惑：从ZooKeeper到目标RegionServer，最坏情况下有3次网络跳转——客户端到ZooKeeper，再到meta表所在RS，再到目标RS。这就是网上常说的“HBase三次跳转才能找到数据”。但缓存放热之后，客户端可以直接向目标RS发起请求，所以生产环境里绝大多数读请求都只是一次RTT而已。真正出现三次跳转的场景，通常是客户端刚重启、缓存为空，或者meta表本身做了split导致缓存失效。

meta表本身就是一张普通的HBase表，只有一个Region。这个Region如果挂了，整个集群的读路径都会被堵死。所以我在监控里会单独盯着meta表所在RegionServer的状态、ZooKeeper连接数，任何访问/hbase/meta-region-server的异常延迟都值得优先处理。

2.3 实际调用：超时、重试与客户端参数

一个最简单的Java读操作长这样：

Configuration conf = HBaseConfiguration.create(); conf.set("hbase.zookeeper.quorum", "zk-01,zk-02,zk-03"); conf.set("hbase.client.retries.number", "3"); conf.set("hbase.client.pause", "100"); Connection conn = ConnectionFactory.createConnection(conf); Table table = conn.getTable(TableName.valueOf("user")); Get get = new Get(Bytes.toBytes("user_1001")); Result result = table.get(get); table.close(); conn.close();

这段代码里已经藏了好几个关键参数。hbase.client.retries.number控制遇到可重试异常（如NotServingRegionException、SocketTimeoutException、ConnectionClosedException）时的最大重试次数；hbase.client.pause控制每次重试之间的退避时间。默认重试次数大约13到15次，这对在线业务太久——请求会堆积在客户端线程池里，用户侧看到的延迟会被放大到几十秒。我一般会降到3次，优先让上游快速感知失败、走降级逻辑，而不是默默重试赌运气。

超时方面，get请求通常受hbase.client.operation.timeout和hbase.rpc.timeout影响。scan请求除了rpc timeout，还会受hbase.client.scanner.timeout.period控制，默认60秒，它代表服务端认为scan会话失效的时间。如果业务做全表扫描，两步之间间隔超过这个值，服务端会强制关闭Scanner，客户端下一批拉数据时拿到UnknownScannerException。

下表是我常用的几个客户端参数默认值和建议值：

超时和重试必须配套调整。只把超时调小、重试次数还按默认走，你会看到请求在“快速失败”和“默默重试”之间来回循环，最终整体耗时反而更不稳定。我的经验是：operation timeout设成3s、rpc timeout设成1.5s、重试3次，业务侧再加一层降级缓存，整套读链路的SLA反而比之前“宽容的默认值”更稳。

2.4 客户端寻址异常：缓存过期与meta压力

生产环境经常有一个现象：Region正在做split，或者Master在做负载均衡把Region移到别的服务器，客户端本地缓存里存的RegionServer地址其实已经过期了。拿着过期地址发请求，服务端会返回NotServingRegionException。客户端会自动清除对应缓存、重新查meta表、再重试一次。这套机制本身是自动的，问题在于“瞬时的重试风暴”：

如果大量请求同时拿着旧地址打过来，又同时触发meta表重查，meta表所在RegionServer可能瞬间收到海量读请求。表现为meta表所在服务器CPU飙高、ZooKeeper会话超时、随后整个集群出现连锁的读异常。应对办法是避免所有客户端在同一时间点重启，尤其大版本发布或连接池重建时要错峰；另外meta表所在服务器的CPU、handler util要单独做告警。

3. RegionServer端请求处理与Scanner构建

3.1 RPC层与handler模型

请求到达目标RegionServer后，首先进入RPC框架。每个RegionServer启动时会创建一组handler线程，数量由hbase.regionserver.handler.count控制，默认值在30左右。handler线程负责从RPC队列里取出请求，执行真正的读取逻辑。

handler数不是越大越好。线程增加会带来上下文切换和内存开销，盲目调到200反而让性能更差。我一般按机器核数的1/4到1/3来调，上限不超过100。常见的线上故障是：某台RegionServer上HFile特别多、block命中率又低，读请求每次都触发慢磁盘IO，handler全部忙不过来，新请求在RPC队列里排队，客户端表现就是“连接没断但就是不返回”，最后RPC超时。如果监控里的handler utilization长期高于60%，就要动手了，要么扩容RegionServer，要么优化这块Region的读路径。

拿到请求后，handler根据请求里的regionName定位到对应的Region实例。Region内部按ColumnFamily分Store，读请求涉及哪个列族，就在哪个Store里扫描。如果一次get指定了多个family，Region会分别为每个Store创建Scanner，再按rowkey把结果合并起来，这部分对用户是透明的。

3.2 Region、Store、MemStore与HFile的结构

深入一点看Region内部结构：

• Region是HBase进行数据分配和负载均衡的最小单位，一个表有多个Region，每个Region包含一段连续的rowkey；
• Region内可以有一个或多个ColumnFamily，每个ColumnFamily对应一个Store；
• 每个Store包含一个MemStore和一批HFile；
• BlockCache是RegionServer级别的，被所有Region共享，不属于某一个Store。

对一个Store而言，MemStore处理最新写入，HFile保存已经flush的数据。读一次数据不能只看某个文件，需要把所有可能包含目标rowkey的HFile都纳入扫描范围。问题来了：一个Store下面少则几个、多则几十个HFile，难道每个文件都打开读一遍？显然不行。于是HBase引入了两个主要的过滤手段：BlockCache和BloomFilter。

BlockCache解决的是“这个文件里的数据块是不是已经在内存里”，BloomFilter解决的是“这个文件是不是根本不可能包含我要找的rowkey”。前者节省磁盘IO，后者直接跳过无效文件。

3.3 Scanner体系：RegionScanner、StoreScanner、StoreFileScanner

这是整个读流程最核心的三层结构。我尽量讲清楚，不绕弯子。一次get进入Region后，服务端会构造这样的Scanner体系：

RegionScanner ├── StoreScanner(FamilyA) │ ├── MemStoreScanner(snapshot) │ ├── StoreFileScanner(HFile_1) │ ├── StoreFileScanner(HFile_2) │ └── ... └── StoreScanner(FamilyB) ├── MemStoreScanner(snapshot) ├── StoreFileScanner(HFile_3) └── ...

RegionScanner是用户读请求的入口，往下管着多个StoreScanner。每个StoreScanner内部有一个KeyValueHeap，把所有StoreFileScanner和MemStoreScanner按Key排序后，逐个弹出最小的KeyValue。换句话说，读请求看到的是所有文件按rowkey合并出的有序流，而不是某个文件的单独内容。

为什么必须做这种堆排序？因为单个HFile内部KeyValue是有序的，但文件之间并没有全局排序。同一个rowkey的两个版本，可能一个在HFile_A里，另一个在HFile_B里。只有把两个文件同时打开、按Key顺序取数据，才能在一次遍历中把最新版本找出来。

另一个要点：Scanner是懒加载的。初始化时不把整行数据塞进内存，而是每取一个Cell（或者结合caching参数取一批），按需从底层StoreFileScanner读Block。这样Scan操作的内存占用能被控制住，但代价是一次大Scan需要多轮RPC才能完成，所以有了客户端侧的caching、batch以及服务端的租约机制。

3.4 随机读与Scan读：pread方式和租约

讲读流程必须区分两类场景：随机读get和范围扫描scan，服务端处理有差别。get请求通常以pread方式打开HFile，一次性拿到需要的Block后立刻关闭文件句柄，不长期占用资源。scan请求会保持HFile的读通道，在租约期限内持续从文件里拉数据块，所以scan对Scanner cache更依赖，也更需要关注服务端对Scanner的过期回收。

服务端为每个Scanner分配一个lease，默认60秒。客户端每拉一批数据都会续租，如果客户端处理太慢或者GC停顿太长，租约到期后服务端会直接关闭Scanner，客户端再取下一批数据时就会收到UnknownScannerException。这是线上scan报错最常见的两个原因之一，另一个是客户端scan timeout设得太短。

4. 存储侧读取细节：HFile、BlockCache与数据合并

4.1 HFile逻辑布局与索引结构

HFile不是简单把KeyValue顺序堆起来的文件。为了随机读快，它做了一整套索引。一个HFile大致包含这些部分：

• Data Block：存放KeyValue，默认块大小64KB；
• Leaf Index Block / Intermediate Index Block / Root Index Block：多级索引，按块查找定位；
• Bloom Block：布隆过滤器位数组；
• Meta Block / FileInfo / Trailer：文件元信息和布隆参数等。

读取某个rowkey时，先从文件尾部Trailer拿到Root Index Block的位置，逐级二分查找，定位到包含目标Key的Data Block。然后把这个Block读入缓存，块内再做二分查找定位Cell。整个过程不需要从头扫完整个文件，这是HBase能支撑毫秒级随机读的根基。

有个小细节值得知道：Data Block的边界和rowkey不是对齐的，索引里记录每个Block的最后一个Key，所以索引定位可能“误命中”一个其实是跨界的Block。定位到某个Block之后有时还需要往前回溯一个Block。这个细节调优时碰不到，但理解它对后续排查“数据明明存在却扫不到”的问题有帮助。

4.2 BlockCache：读缓存的命门

BlockCache缓存的是已经加载过的HFile数据块，由RegionServer内所有Region共享，默认是LRU策略的LruBlockCache。默认情况下，RegionServer堆内存的40%分给hfile.block.cache.size，另外40%分给MemStore，剩下的留给JVM其他部分。线上要根据读写比例动态调整这两个值：读多写少可以调大BlockCache占比，写多读少则维持或调大MemStore占比。

BlockCache命中率是读延迟最敏感的指标之一。数据总量远大于BlockCache容量时，冷数据不断把热数据挤出缓存，命中率就会下滑。常见的优化手段：

• 使用BucketCache，把部分缓存放到堆外或SSD，缓解堆内存压力；
• 对热列族设置较高的缓存优先级，让该列族的块进入memory优先级，淘汰概率更低。适合meta表、字典表这类数据量不大但访问很频繁的场景；
• 控制单行大小。BlockCache以“块”为单位，单行数据越大，一个块能覆盖的行数越少，缓存效率越差。

BlockCache里有几个关键指标值得盯：cacheHitRatio、cacheMissRatio。我在生产上用监控看这两个指标，如果miss率持续升高，优先检查几个方向：HFile数量是不是暴增了？最近是不是有超大的scan把热块全部冲掉？Region是不是因为split导致文件分布变差了？

4.3 BloomFilter：把无用的HFile挡在门外

BloomFilter是HBase读路径上最实惠的“过滤器”。它解决的是：当Store下面有几十个HFile时，一次get到底需要打开哪些文件的问题。

建表时可以把BloomFilter设为ROW或ROWCOL。对于get请求，BloomFilter能快速判断文件里可能没有某个rowkey，于是这个StoreFileScanner就直接不创建，跳过文件打开和Block读取。对点查为主的表，我强烈建议用ROW模式；对于scan为主的表，布隆过滤器的价值不大，因为scan要读取一整段数据，依赖的是顺序读和BlockCache。

布隆过滤器本身有约1%的假阳性率，但它判断“一定不存在”是准确的，所以能拦截绝大多数无关文件。要注意Bloom块本身也占用内存，会被加载到BlockCache；如果HFile特别多，Bloom元数据的占用同样不可忽视。所以该做的Major Compaction别偷懒，做了Major Compaction之后文件数量下降，Bloom块数量也同步下降。

4.4 多源合并：时间戳、Delete标记与版本选择

读流程最后一步，是把所有Scanner弹出的Cell按排序归并，然后应用“当前读时间点生效”的逻辑。Cell在HFile内沿用了严格的排序顺序：

• 按rowkey升序；
• row相同时按column family升序；
• 然后按qualifier升序；
• 然后按时间戳降序（新版本在前）；
• 最后按KeyType排序，Put类型的Cell排在Delete类型前面。

这个排序顺序很关键。例如同一rowkey、同一column的多个版本，时间戳大的先被读到，如果客户端请求的是最新版本，Scanner弹出第一个Cell后就可以直接返回，不用继续翻历史版本。而Delete标记分为三类：Delete（删整行）、DeleteFamily（删整个列族）、DeleteColumn（删某个列）。删除标记也带时间戳，表示“在这个时间点之后写入的版本都是无效的”。读取时遇到Delete标记后，会检查后面读到的Cell的时间戳，小于标记时间的就跳过，实现逻辑删除。

这里有个经典坑：在做Major Compaction之前，Delete标记仍然物理存在。如果用raw=true去scan，你会看到“已被删除”的数据，因为raw模式绕过正常过滤、直接返回底层物理Cell。所以线上排查数据时千万不要用raw模式，它返回的是物理视图，不是逻辑视图。正常scan就是最正确的验证方式，raw只适合底层分析。

5. 读路径性能优化与参数调优实战

5.1 读放大是怎么来的

RegionServer内部的读延迟，很大程度取决于“读放大”。我理解读放大的本质是“为了找到一份目标数据，不得不读取或扫描的额外数据量”。在HBase里，读放大主要来自三个方面：

• 同一个rowkey的数据分散在MemStore和多个HFile里，读一次需要合并的文件越多，CPU排序和磁盘IO越多；
• HFile的Data Block默认64KB，一个get可能读取一个64KB的块，但用户只想要其中的几个字节；块越大，这种浪费越明显；
• 如果HFile数量失控、没有及时做Compaction，读路径要打开的StoreFileScanner会显著增加，延迟上升肉眼可见。

控制读放大的首要手段，就是控制HFile数量。合理配置MemStore的flush size、用好Compaction策略、关注Store下的文件数，是每个HBase使用者的基本功。我的建议是让Store下的HFile数量尽量控制在20到30个以内，超过这个数量后读路径的合并成本会明显拉高延迟。Major Compaction虽然能合并所有文件，但它是阻塞型操作、IO消耗很大，线上大表不建议频繁手动触发。可以通过调整hbase.hregion.majorcompaction延长自动周期，或者用Stripe Compaction等策略降低影响。

5.2 核心参数速查

读路径调优离不开几个核心参数，这里我按“我目前在线上用到的值”整理一下：

BlockCache调整有个总约束：BlockCache和MemStore的占用之和，不要超过RegionServer物理内存的70%。剩下的空间要留给JVM元空间、线程栈、堆外内存，如果RegionServer跑着HDFS的DataNode，还要给DataNode留缓冲。我曾经在内存128G的机器上把两个0.4加到一起还额外开了缓存，结果频繁Full GC，读延迟比不调还差。

5.3 热点读的典型场景与解法

读性能里最让人头疼的不是平均延迟，而是热点导致的尾延迟。典型例子：秒杀场景里所有用户都用同一个前缀的rowkey，比如user_1001到user_9999都落在同一个Region；数据量一大，请求集中打在这一个Region上，BlockCache命中率再高，单Region的handler和堆内存也会成为瓶颈。

处理热点读，我常用的三板斧：

• 加盐/哈希：给rowkey前面加一个哈希前缀，把同一数据前缀的访问分散到多个Region上；
• 预分区：按业务量提前规划Region数量和split point，避免单个Region持续过大；
• 反转：时间序数据按倒序方式存储，让最新数据固定在少数几个Region上，适合“按时间查最新”的访问模式。

三种方式不是非此即彼。比如预分区做好之后，再加盐，配合ROW级BloomFilter，点查性能会明显好转。但要注意加盐会破坏range query的连续性，如果有范围扫描需求，可以做“可解析前缀”的变体：前缀是可计算的业务字段hash，后段保持原业务key，这样既能分散热点，又能在需要时按段扫回数据。

5.4 一个容易忽略的优化：别把scan当搜索引擎

调参之余，“人的优化”也很关键。实际业务里经常有人写一段scan扫描整张表，加上一个filter去匹配rowkey前缀，再在客户端对结果过滤。本质上是让RegionServer读全表、再把不匹配的行丢掉，整个读路径所有资源全部浪费了。

定位单行永远用get；定位一个小范围也要用scan，并且明确指定STARTROW和STOPROW，尽量缩小扫描区间，用服务端Filter完成过滤，不要把大结果全部拉回客户端做过滤。能走get的不要scan，能用前缀过滤的不要全表扫描。这套“设计层面的优化”往往比调BlockCache参数更立竿见影。

6. 线上读故障排查实录

6.1 客户端报“无法将数据写入传输连接：远程主机强迫关闭了”

这类错误在C#的RESTClient、Java、Go等客户端里都很常见，本质上就是TCP连接被对端重置或关闭。大多数时候不是网络断掉了，而是服务端在某个层面“主动”关了连接。读路径上常见的原因有几种：

• RegionServer进入长时间GC，RPC线程无法及时处理现有连接，客户端等待超时后被服务端或网络层断开；
• RegionServer的handler线程耗尽，请求堆积在队列里，服务端为释放资源关掉部分连接；
• 客户端连接池中累积了大量陈旧连接，一次重建瞬间打满服务端连接数；
• 网络层面出现跨机房抖动，或者交换机端口异常。

排查思路是不要只盯着客户端日志。先去RegionServer看GC日志、RPC handler利用率、网络连接数曲线；同时确认meta表和ZooKeeper是否健康。如果是GC问题，调整RegionServer堆内存、换G1、减少Region数量降低RSet开销；如果是handler满，按核数调大handler.count。这条链路上的连接重置，多数根因都指向资源瓶颈或长GC，而不是HBase进程本身不可达。

6.2 Master初始化期间的读不可用

热词里有“hbase出现master initialing”，这个现象我在实际运维中遇到过好几次。Master初始化是一个长流程，期间要做WAL日志拆分（Log Splitting）、恢复或重建meta表、把用户Region重新分配下去。在Master没有完成这些工作之前，客户端可能能连上ZooKeeper，但meta表定位不了，或者目标Region还没Assign成功，表现就是整表读不可用。

常见于RegionServer非正常宕机后的集群启动。Master要先检查该RegionServer的WAL文件，做Log Splitting，判断哪些Region需要恢复，然后才谈得上分配Region和对外提供服务。启动日志卡在WAL拆分还是卡在meta表恢复，处理方法不太一样。如果Region数量非常大，可以适当调大WAL日志拆分的并发参数，缩短初始化时间。业务侧则要配置好合理的重试和超时策略，在Master初始化期间短暂不可用时不至于把上层业务全部打挂。

6.3 WAL异常与读流程的间接关联

WAL（预写日志）主要负责崩溃恢复，本身并不在正常读路径的返回过程里。但热词里“hbase wal预写日志异常”出现频率很高，原因在于WAL一旦异常，会严重影响Region的持久化和Master对Region状态的判断。比如RegionServer宕机后，如果WAL文件损坏或无法读取，Master在Log Splitting阶段会卡住，导致该RS服务的所有Region迟迟不能重新分配，读请求自然会失败。更严重的情况下，MemStore在宕机时尚未落盘的数据如果无法从WAL回放，数据就真的丢了。

WAL并不是读流程的“常客”，但它能从根上影响集群恢复时间，读延迟会成倍放大。生产环境要关注WAL持久化级别、WAL文件所在磁盘的健康、WAL文件数量是否异常增长。这些都是间接保障读路径稳定性的工作。

6.4 读流程常见故障速查表

读流程的优化，我最后的体会是：先找瓶颈点，再动参数。不要一上来就按网上帖子把BlockCache调到0.6、handler调到80。用监控数据说话——看读延迟是花在客户端等待，还是服务端处理，还是磁盘IO。对着瓶颈动手，效果才立竿见影。另外，参数要跟着业务形态走，同一套HBase集群里混跑点查和全表scan业务，最好分组隔离，避免相互污染。这个思路比收藏多少配置模板都重要。