HBase Python客户端全解析：Thrift协议与happybase实战

如果你在一个以 Java 为主的大数据团队里待过，应该能理解 Python 工程师面对 HBase 时的那种别扭感：集群是 Java 生态的，管理工具是 Java 的，写 MapReduce 是 Java 的，到了业务侧想用 Python 快速做数据探查、补数脚本、或者给算法同学提供特征数据时，却发现官方文档里 Python 客户端四个字连影都没有。网上搜“HBase Python 客户端”，翻来覆去就是几个第三方库，但哪个能用、哪个已经烂尾、哪个适合生产环境，没人一次说清。这篇文章我按技术栈清单的形式，把 HBase 的 Python 客户端支持情况从头到尾梳理一遍，包括协议原理、环境准备、实际踩坑，以及当性能不够时该怎么搭替代架构。

先说结论：HBase 没有官方维护的 Python 客户端，你看到的 Python 客户端基本都是基于 Thrift 或 REST 接口封装出来的。这个“没有官方”并不是 Apache 不重视 Python，而是 HBase 的核心模型天然和 Java 强绑定——它内部依赖 Hadoop 的配置体系、Java 的 RPC 机制、JVM 的内存管理，官方团队把精力都放在 Java API 和周边生态上。对 Python 开发者来说，最靠谱的路径就是通过 Thrift 网关访问，而 Thrift 网关选择哪一版、怎么配、怎么调优，才是真正决定你后续会不会踩坑的地方。

1. HBase 的 Python 客户端到底有几种？先给结论再拆方案

1.1 客户端生态全景：官方原生客户端为什么不存在

在讨论 Python 客户端之前，我们得先理解 HBase 的访问模型。HBase 对外提供三类主流访问途径：

• Java 原生 API：通过 HBase RPC 协议直接和 RegionServer 通信，性能最高，功能最全，但只能 Java 用。
• Thrift 网关：HBase 启动一个独立的 Thrift Server，把 Java API 包装成跨语言的 Thrift 服务，支持 Python、PHP、C++、Go 等语言。
• REST 网关：也就是 HBase REST Server，基于 HTTP + JSON/XML，语言无关，但性能和类型表达力比 Thrift 弱。

Python 想连 HBase，必然落在 Thrift 或 REST 之上。而社区里流传较广的 Python 客户端，我整理成了一张表，方便你做技术栈选型时直接对照：

这里我明确说一句：如果你不是有特殊历史包袱，新项目直接用 happybase 就好。它是目前 Python 社区里封装最完整、文档最友好、坑最少的一个。它底层用的是 HBase 的 Thrift 2 接口，对连接、扫描、批量写入都做了比较合理的封装，单机读写、小规模并行都够用。

1.2 为什么 Thrift 方案是 Python 接入 HBase 的主流

很多人第一次听到“用 Thrift 连 HBase”会犯嘀咕：Thrift 不是过时的 RPC 框架吗？为什么不提供 HTTP 接口直接调？

道理很简单：HBase 的 Java API 最核心的读写路径走的是 RegionServer 上的 RPC 服务，数据是按 KeyValue 结构组织的。如果走 REST，每次请求都要做 JSON 序列化和反序列化，遇到 Scan 这种需要逐行迭代的操作，HTTP 的请求头开销和 JSON 文本冗余会放大到让人崩溃。Thrift 是二进制协议，直接映射 HBase 的数据结构，性能和类型表达都更接近原生，所以从 HBase 0.94 之后，官方把 Thrift 作为跨语言访问的主要推荐方式，REST 更多是用来做轻量查询或者给非 RPC 友好的环境用的。

你只需要记住一个判断标准：只要你的 Python 代码对 HBase 有批量读取或写入需求，走 Thrift；只有偶尔查一两条数据、并且不想引入额外客户端库时，才考虑 REST。

2. 通信链路背后的原理：为什么 Python 客户端绕不开 Thrift

2.1 从 RegionServer 到 Thrift Server：一条请求的完整旅程

要真正搞懂 Python 客户端怎么用，必须明白一条 Python 写的 get 请求到底是怎么一步步执行到 RegionServer 的。完整链路如下：

code复制Python 代码（happybase）
    ↓ Thrift 二进制协议
Thrift Server（独立进程，默认端口 9090）
    ↓ Java API
ZooKeeper（定位 meta 表，找到目标 Region 所在的 RegionServer）
    ↓ HBase RPC
RegionServer（真正的数据读写）

这个过程揭示了几个关键点：

• Python 客户端不直接连 RegionServer，而是先把请求发给 Thrift Server，由 Thrift Server 转成 Java API 调用。
• Thrift Server 需要访问 ZooKeeper，所以 HBase 集群必须把 ZooKeeper 连接信息配好，否则 Thrift Server 起不来。
• 一次请求的链路比纯 Java API 多一跳，所以延迟会比 Java 略高，但吞吐量在大多数场景下足够。

这个“多一跳”也是很多性能问题的根源。后面我会专门讲 Thrift Server 的并发瓶颈和优化方式。

2.2 Thrift 1 和 Thrift 2：版本选错，连接直接失败

HBase 的 Thrift 接口有 v1 和 v2 两代，区别很大：

• Thrift 1：早期接口，方法命名简单，返回的是裸对象，需要自己处理异常。
• Thrift 2：接口重新设计，方法更贴近 Java API 语义，支持批量操作、命名空间管理、检查并修改（checkAndMutate）等高级功能，并且把很多异常封装得更清楚。

happybase 从 1.0 版本开始默认走 Thrift 2。如果你用的 HBase 集群比较老，只启动了 Thrift 1 服务，那么 happybase 连接时就会报方法不存在的错误。这是一个非常典型的版本兼容性坑。

在实际环境里，我建议你这样确认 HBase 的 Thrift 版本：

bash复制# 查看 HBase 安装目录下的 lib 中 thrift 相关 jar 包版本
ls $HBASE_HOME/lib | grep thrift
# 例如 hbase-thrift-2.5.0.jar，说明是 Thrift 2

同时看 hbase-daemon.sh 启动脚本，里面 thrift 子命令一般会标明是用 thrift1 还是 thrift2。如果你的发行版默认启动了 Thrift 1，但你的 Python 代码里用的是 happybase 新版，大概率会出现：

code复制TTransportException: Could not connect to ...

或者更隐蔽的：

code复制TApplicationException: Invalid method name: 'openScanner'

遇到这种，不要急着改代码，先去查服务端启动的是哪个 Thrift 版本。

2.3 一次 Scan 的内存放大与网络交互：为什么“慢”在协议层

很多人抱怨 happybase 扫描大表时特别慢，以为是 Python 性能问题。其实大部分瓶颈出在 Thrift 协议本身的工作方式。

HBase 的 Scan 操作天然设计成“服务端保留游标，客户端分批拉取”的模型。Java API 里，Scan 会为每个 Region 创建一个 Scanner，客户端通过 next() 方法一批一批取数据。Thrift 接口也复刻了这套逻辑：你先 openScanner 拿到 scannerId，然后反复调用 next 获取行数据。

问题出在数据大小上。Thrift 的 next 方法通过 TTransport 传输时，默认的帧大小和 Java API 的批量拉取策略不同。如果你不显式设置 scan 的批量大小（batch size），一次 next 可能把一整行所有的列全部拉回来；如果一行有几百个列且列名很长，单次网络包就会被撑大，Python 端还要做完整的 Thrift 反序列化，内存和 CPU 开销直线上升。

举个实际例子，我曾处理过一个特征表扫描任务，HBase 里每行有 200 多个列，存量数据约 1 亿行。最初用 happybase 的 table.scan() 不加任何参数，扫 1000 万行耗时 40 多分钟，任务经常被 OOM 干掉。后来加上 batch=100 和 columns 过滤，扫描时间直接降到 8 分钟。这个优化不是 Python 层面做了什么魔法，而是让 Thrift 每次传输的数据量更小、更可控。

3. happybase 从零到能跑：环境、端口、连接、读写全流程

3.1 服务端准备：先确认 Thrift 端口和 ZooKeeper 配置

在写 Python 代码之前，先去 Hadoop/HBase 集群上把服务端环境确认好，不然代码写得再对也白搭。默认情况下，HBase Thrift 服务监听在 9090 端口，REST 服务监听在 8080 端口。但生产环境经常有端口调整，所以第一步是去 hbase-site.xml 里确认：

xml复制<property>
  <name>hbase.regionserver.thrift.port</name>
  <value>9090</value>
</property>
<property>
  <name>hbase.regionserver.thrift.compact</name>
  <value>true</value>
</property>
<property>
  <name>hbase.thrift.framed</name>
  <value>true</value>
</property>

这里有两个参数需要特别留意：

• hbase.regionserver.thrift.compact：是否启用 Thrift 的紧凑压缩协议。happybase 默认使用 framed + compact 协议，如果服务端没开 compact，你连接时大概率会报协议不匹配。
• hbase.thrift.framed：是否启用 framed 传输。这也是 happybase 默认期待的传输方式，两边必须保持一致。

如果你用的是 Cloudera / CDP 这类商业发行版，通常已经把这些参数调好了；如果自己手工搭的 Apache HBase，很容易漏掉 compact 配置，导致 Python 客户端怎么都握手失败。

确认完配置，启动 Thrift 服务：

bash复制# 前台启动可以这样
$HBASE_HOME/bin/hbase-daemon.sh start thrift2
# 或者前台启动，方便看日志
$HBASE_HOME/bin/hbase thrift2

启动后，用 netstat 或 telnet 验证端口是通的：

bash复制netstat -anp | grep 9090
telnet <hbase-thrift-host> 9090

不要跳过这一步。很多“连接不上”的问题，最后定位出来是防火墙、安全组或者服务没启动，和 Python 代码一点关系都没有。

3.2 Python 环境准备：安装 happybase 及其依赖

Python 侧非常简单，直接 pip 安装：

bash复制pip install happybase

happybase 依赖 thrift 库，pip 会自动帮你装好。装完后验证一下版本：

bash复制python -c "import happybase; print(happybase.__version__)"

如果你发现安装的 thrift 版本和 HBase 服务端的 Thrift IDL 版本有冲突，先不要慌。happybase 自带的 thrift 兼容层已经处理了大部分情况，只要不是跨了两个大版本（比如服务端还是 thrift 0.9.x，客户端却强制用了 thriftpy2 的最新版），一般问题不大。

3.3 连接配置与连接池：Connection 的隐藏参数

happybase 的连接对象是 Connection，看似简单，但很多参数直接影响生产环境的表现。核心参数如下：

python复制import happybase

# 最基础的连接参数
connection = happybase.Connection(
    host='hbase-thrift.example.com',  # Thrift Server 地址
    port=9090,
    timeout=20000,                     # 连接超时，单位毫秒
    table_prefix=None,                 # 表名前缀，可选
    protocol='compact',                # 协议，默认就是 compact
    transport='framed',                # 传输方式，默认就是 framed
)

这里我要重点说两个参数：

• timeout：默认是 None，也就是不设超时。在 Python 进程卡死或 Thrift Server 无响应时，没有超时的连接会一直阻塞，最终拖垮整个应用。生产环境务必设置，建议 10~30 秒。
• table_prefix：如果 HBase 开启了命名空间，或者团队使用表名前缀来区分业务线，你可以通过这个参数统一管理，不用每次写表名都拼前缀。

在生产项目里，我更推荐用 Python 的 contextlib 或 with 语法来管理连接和表对象：

python复制with happybase.Connection('hbase-thrift.example.com', timeout=20000) as connection:
    table = connection.table('user_behavior')
    row = table.row('user_001')
    print(row)

这里有一个很多人不会注意的细节：Connection 对象的创建实际上是懒加载的，真正建立连接发生在你第一次执行操作时。所以如果你想在应用启动阶段就确认 HBase 是否可用，可以主动调用一次 connection.open() 或执行一个轻量操作。

3.4 建表、写入、读取、删除的完整代码范例

下面给出一套最基本的操作代码，覆盖建表、写读删：

python复制import happybase

# 建立连接
connection = happybase.Connection('hbase-thrift.example.com', timeout=30000)

# 1. 建表
# 如果表不存在则创建，指定一个列族 cf
if b'user_behavior' not in connection.tables():
    connection.create_table(
        'user_behavior',
        {'cf': dict(max_versions=3, block_cache_enabled=True)}
    )

# 2. 获取表对象
table = connection.table('user_behavior')

# 3. 写入单行
table.put(
    b'user_001',
    {
        b'cf:user_name': b'zhangsan',
        b'cf:action': b'click',
        b'cf:timestamp': b'2024-06-01 12:00:00',
    }
)

# 4. 读取单行
row = table.row(b'user_001')
print(row)
# 输出: {b'cf:user_name': b'zhangsan', b'cf:action': b'click', ...}

# 5. 读取整列族
columns = table.row(b'user_001', columns=[b'cf:action'])

# 6. 删除一行
table.delete(b'user_001')

# 7. 批量写入
with table.batch(batch_size=1000) as bat:
    for i in range(10000):
        bat.put(
            f'batch_user_{i}'.encode(),
            {b'cf:user_name': f'user_{i}'.encode(), b'cf:action': b'click'}
        )

connection.close()

这里我想要强调几个工程上的点：

• HBase 的行键（row key）、列名、值全部是字节数组，Python 字符串必须 encode 成 bytes。初学者最容易在这上面出错，比如用 'user_001' 直接作为 row key，结果底层存储的是 str 对象，读取时又用 b'user_001'，自然查不到数据。
• 批量写入必须用 table.batch()，不要循环单条 put。批量操作会把多条 put 打包成一个 RPC 请求，写入吞吐能提升几倍甚至一个数量级。
• 建表时指定 max_versions 很重要。HBase 默认保留 3 个版本，如果你明确不需要多版本数据，设置成 1 能减少存储开销和读放大。

3.5 扫描（Scan）的正确姿势与批量拉取

Scan 是 Python 访问 HBase 最高频的操作，也比 get 更容易出错。下面是一个生产级扫描函数示例：

python复制def scan_user_data(table, start_row=None, stop_row=None, columns=None, batch=200, limit=None):
    """
    按行键范围扫描，返回生成器，避免全量载入内存。
    """
    scan_kwargs = dict(
        batch=batch,
        limit=limit,
    )
    if start_row:
        scan_kwargs['row_start'] = start_row
    if stop_row:
        scan_kwargs['row_stop'] = stop_row
    if columns:
        scan_kwargs['columns'] = columns

    scanner = table.scan(**scan_kwargs)
    for row_key, row_data in scanner:
        yield row_key, row_data

几个参数解读：

• row_start / row_stop：按行键范围扫描，尽量设计行键时保证前缀有序，这样 Scan 才能高效。
• batch：每次 RPC 请求返回的行数，或者说 Cell 数量。设置太小会导致网络往返次数增加；设置太大会拉取过多数据，容易 OOM。经验值 100~500。
• limit：最多返回多少行，适合调试和抽样。

4. 生产环境里真正会遇到的坑：端口不通、协议不匹配、Scan 超时与连接泄漏

4.1 HBase 端口清单：你该开放哪些端口，怎么排查

HBase 集群涉及的端口很多，和 Python 客户端最相关的只有两个：Thrift 端口（默认 9090）和 ZooKeeper 客户端端口（默认 2181）。

很多人在排查 Python 连不上时，只盯着 9090，其实如果 Thrift Server 连不上 ZooKeeper，它自己根本起不来。完整的排查顺序应该是：

1. telnet <thrift-host> 9090：确认 Thrift 端口通不通；
2. telnet <zk-host> 2181：确认 ZooKeeper 端口通不通；
3. 在 HBase 服务器上执行 jps，确认 ThriftServer 进程存在；
4. 查看 Thrift Server 日志，确认没有 ZK 连接异常。

这里放一张相关端口速查表，方便你贴到运维文档里：

4.2 Thrift 协议与版本匹配问题：一次真实排错过程

有一次线上任务突然报错，错误信息是：

code复制TTransportException: TSocket read 0 bytes

排查过程是这样的：

• 第一步，telnet 9090 端口是通的，排除网络问题。
• 第二步，用 happybase 连接时指定了 protocol='compact'，但服务端日志显示它接收的是 binary 协议的帧。
• 第三步，检查 hbase-site.xml，发现 hbase.regionserver.thrift.compact 没有配置，默认值是 false，也就是服务端用的是 binary 协议。

解决办法是把 hbase-site.xml 里改成 true，然后重启 Thrift Server。但重启会影响正在使用该服务的业务，所以更稳妥的临时方案是让 Python 端改协议：

python复制connection = happybase.Connection(
    host='hbase-thrift.example.com',
    port=9090,
    protocol='binary',  # 匹配服务端的 binary 协议
    transport='buffered',
)

后来我复盘发现，这类问题最容易出现在团队自己搭建 Apache HBase 的场景，商业发行版通常默认把 compact 和 framed 都打开了。所以，当你在生产环境遇到 “TSocket read 0 bytes” 这类模糊错误时，优先怀疑两端协议不一致。

4.3 数据类型序列化：数字、字符串、二进制到底怎么存

HBase 对数据没有类型约束，所有值都是字节数组。因此 Python 端存什么类型，读出来就得自己反序列化。这里的坑在于大家惯用的 Python 类型和 HBase 生态中常用的 serialization 是不一致的。

比如说，你想存一个整数 12345，直接 str(12345).encode() 存进去，读出来是 b'12345'。这样没问题，但你在 Java 端用 Bytes.toBytes(12345) 读同一行时，得到的字节流是 4 字节的大端整数 \x00\x00\x30\x39，完全对不上。如果 HBase 表同时被 Java 和 Python 写，必须约定好序列化格式。

常见的解决方案有三种：

1. 全部用 UTF-8 字符串编码，数字也转成字符串存储——简单，但排序和范围查询会按字典序而不是数值序。
2. 使用 Python 的 struct 模块把整数打包成大端字节序，和 Java 侧 Bytes.toBytes 保持一致。
3. 在行键设计时，用固定宽度的字符串表示数字，比如 b'000012345'，保证字典序等于数值序。

我这里推荐按团队约定来做。如果 HBase 表主要由 Java 生产、Python 消费，第二种方案是最稳妥的。下面是 Python 端读写 int 的示例：

python复制import struct

# 存储 int 为 4 字节大端
value = struct.pack('>i', 12345)
table.put(b'row1', {b'cf:num': value})

# 读取并解析
row = table.row(b'row1')
num = struct.unpack('>i', row[b'cf:num'])[0]
print(num)  # 12345

4.4 连接与连接池泄漏：为什么 Python 服务跑几天后卡死

happybase 的 Connection 对象不是线程安全的，每个线程最好持有自己的连接。但实际项目里，往往会出现一个全局 Connection 对象被多个线程同时调用，导致 Thrift 连接状态错乱，表现为偶发性的读超时、数据错乱。

正确做法是使用连接池。happybase 官方没有提供线程池，但社区常用 queue.Queue 简单封装，或者直接用 thriftpool 这类库。下面是我实际项目里用过的连接池实现：

python复制import queue
import threading
import happybase

class HBaseConnectionPool:
    def __init__(self, host, port=9090, size=10, **kwargs):
        self._pool = queue.Queue(maxsize=size)
        self._kwargs = dict(host=host, port=port, **kwargs)
        for _ in range(size):
            self._pool.put(happybase.Connection(**self._kwargs))

    def get(self):
        conn = self._pool.get()
        try:
            conn.open()
        except Exception:
            # 连接异常时重建
            conn = happybase.Connection(**self._kwargs)
            conn.open()
        return conn

    def put(self, conn):
        self._pool.put(conn)

这个连接池虽然简陋，但解决了两个最核心问题：多线程竞争时不共享同一连接；异常连接会被重建而不是持续复用。实际用下来，服务跑一个月基本不会出现连接卡死的问题。

还有一个细节：如果 Connection 长时间没有操作，可能被服务端的 keepalive 断开，但 Python 端不知道。所以连接池里拿出来的连接，最好在 get 时调用 open() 或做一个轻量心跳操作。上面代码里我调用了 open()，这个调用不是每次都重新建立底层 socket，它内部会判断是否已经打开，所以不会带来额外开销。

4.5 超大表 Scan 的经典超时问题：scannerLeaseTries 和心跳维护

HBase 服务端对 Scanner 有租约（lease）机制。默认情况下，如果客户端在 60 秒内没有向服务端拉数据，Scanner 会被服务端清理。Python 端如果处理数据的速度跟不上扫描速度，或者中间做了耗时计算，就会导致 scanner 过期，报错信息通常是：

code复制org.apache.hadoop.hbase.exceptions.ScannerLeaseExpiredException

解决思路有两个方向：

• 调大服务端的 hbase.client.scanner.timeout.period，默认 60000 毫秒，改成 180000。
• 在 Python 端降低批量大小，保证每次拉取和处理能在一个租约周期内完成。

我实际使用时倾向于把 batch 调小到 100，同时代码里避免在循环中做耗时操作。如果确实需要复杂数据处理，先把扫描结果快速写入本地临时文件或内存队列，之后再处理，而不是在 scan 循环里直接做。

5. 性能瓶颈与替代架构：什么场景下该换 Java 网关或走 Phoenix

5.1 Thrift 方案的性能天花板：实测数据与判断标准

我经常被问：happybase 到底能撑多大并发？

坦白说，这和你的 Thrift Server 资源配置、数据规模、查询模式都有关系，没法给一个绝对数字。但根据我自己的压测经验，可以给出一组参考数据：

• 单 Thrift Server，4 核 8G，单行 get，QPS 大概在 2000~5000。
• 同配置，批量写入（batch=1000），吞吐大概在 5~10 万行/秒。
• 同配置，全表扫描，吞吐大概在 5000~10000 行/秒，取决于每行大小。

这个量级对于大部分离线任务、小规模在线查询是够用的。但如果你要支撑高并发在线接口，比如每秒钟几万次点查，或者要 Scan 海量数据，Thrift Server 会成为明显的瓶颈——因为所有 Python 请求都要经过这个单点，而这个单点还要在 JVM 里完成一次完整的 Java API 调用。

判断是否需要换架构，我个人的标准很简单：

• 如果 QPS 需求小于 5000，且对延迟不敏感，happybase + 单个 Thrift Server 完全够用。
• 如果 QPS 需求在 1 万以上，或延迟要求 P99 小于 50ms，就需要考虑多 Thrift Server 负载均衡，或者使用 Java 网关做聚合查询。

5.2 替代方案对比：Phoenix、REST、自建 Java 网关怎么选

这里我想重点说一下自建 Java 网关。它本质上是一个中间层服务，内部用 Java API 访问 HBase，对外提供 HTTP 或 RPC 接口给 Python 调用。表面上这只是把 Thrift Server 换成了自己写的服务，但好处是：

• 可以利用 Java API 的协处理器（Coprocessor）、二级索引等高级特性；
• 可以做请求级缓存、批量聚合，而 Thrift Server 只是简单转发；
• 避免 Python 端每个功能都处理一遍 row key 设计和序列化细节。

代价也很明显，你必须维护一个 Java 服务，这和你“用 Python 写脚本”的初衷相违背。所以我的建议是：只在团队确实遇到 Thrift 性能瓶颈，且有 Java 开发和运维能力时才上这个方案。

5.3 一个我亲测有效的生产落地形态：Python 应用 + 轻量 Thrift 网关

最后分享一下我在一个用户画像项目里用的架构，应该对你有参考价值。

当时业务方要每天从 HBase 里扫描几十亿行特征数据，用 Python 做特征清洗，再灌入下游 Redis。最开始直接用 happybase 扫描，发现性能瓶颈不在 Python，而在 Thrift Server 的单机处理能力。后来我做了两个关键改动：

1. 在 HBase 集群里起两个 Thrift Server，用 Nginx 做 TCP 负载均衡，Python 端连接的是 Nginx 暴露的虚拟 IP，流量被分发到两个 Thrift Server 上，扫描吞吐立刻翻倍。
2. Python 端改成多进程并行扫描，每个进程负责一段 row key 区间，互不重复。每个进程各自持有连接池，避免线程争抢。

最终这套方案稳定支撑了每天几十亿行的扫描量。关键是改动幅度不大，没有引入新的 Java 服务，只是把流量分散到了两个 Thrift Server 上，Python 代码的结构也基本没变。

这里给一个多进程扫描的架构示例：

python复制from multiprocessing import Pool
import happybase

def scan_partition(params):
    host, start_key, stop_key = params
    connection = happybase.Connection(host, timeout=30000)
    table = connection.table('user_behavior')
    for row_key, row_data in table.scan(row_start=start_key, row_stop=stop_key, batch=200):
        # 处理这一行
        pass
    connection.close()
    return True

# 假设 row key 范围被拆成 16 段
partitions = [('hbase-thrift.example.com', f'user_{i:04d}', f'user_{i+1:04d}') for i in range(16)]
with Pool(8) as pool:
    results = pool.map(scan_partition, partitions)

几个关键点：

• 拆 key 范围时，要考虑数据分布的均匀性。如果 row key 不是均匀分布，某个 partition 的数据量会远超其他 partition，导致任务倾斜。
• 每个进程单独创建连接，不要跨进程共享连接。
• 进程数不是越多越好，受限于 HBase Region 数量和磁盘 IO，一般设置为 RegionServer 数量的 1~2 倍。

最后再分享一个小经验：Thrift Server 的 JVM 堆内存要根据实际数据量调整。默认情况下 HBase 的 HBASE_HEAPSIZE 被设置得比较保守（通常 1G~4G），但如果你使用大 batch 扫描，Thrift Server 需要同时缓存多行数据，堆内存很快会被打满，这会导致频繁 Full GC，进而表现为扫描速度突然陡降。我们遇到过一次典型的“一开始很快，几十秒后开始大量 GC，速度掉到原来的十分之一”，排查后发现就是 hbase-env.sh 里的堆内存设置太小。调大之后问题立刻消失。所以，遇到 Thrift 性能问题别急着换架构，先把 JVM 参数和服务端 GC 日志检查一遍。