简介这份PDF文档聚焦Apache Flink与HBase在阿里巴巴电商业务中的落地实践面向大数据开发工程师、实时计算架构师及对电商实时数据处理感兴趣的技术人员帮助读者理解如何用Flink流处理与HBase存储构建高并发、可扩展的实时数据链路。资源包内仅含1个PDF文件大小约2.9MB内容以技术分享讲稿形式呈现涵盖业务背景、典型场景、技术架构与具体实现代码。文档围绕报表监控、商品库管理、用户足迹分析、生意参谋、供应链预警及全链路debug平台等场景展开并给出Flink SQL与Table API的聚合计算、HBase表DDL定义、数据写入Sink等示例同时涉及2000机器、单机QPS 20W、亿级数据量的优化策略。目前已有167人学习适合希望借鉴阿里实战经验、掌握Flink与HBase协同开发思路的读者参考。1. 从一份 PDF 标题说起FlinkHBase 在电商业务里到底扛了什么活电商大促的凌晨订单、加购、收藏、退款、物流轨迹这些数据像开闸一样涌进来运营要的是「这个用户最近 30 分钟看了什么、加购了什么、有没有下单」风控要的是「这个设备/IP 是不是在刷单」推荐要的是「实时画像」。这些诉求有一个共同点写多读也多、单条数据小、按行随机读写、要求毫秒级响应。用 HDFS 存、用 Hive 查延迟扛不住用 MySQL 硬顶写入一上来就锁表。这时候 FlinkHBase 的组合就上场了Flink 负责把上游 Kafka/日志里的流数据做清洗、聚合、维表关联HBase 负责把结果按 rowkey 落成一张能随机读写的宽表供下游推荐、风控、运营后台实时查询。这份标题里的「阿里巴巴电商业务中的应用」本质讲的就是这条链路流计算做实时加工HBase 做实时存储两者拼成一个能扛住大促峰值的实时数仓底座。适合谁看做实时数仓、用户画像、订单宽表、风控特征存储的工程师尤其是被「MySQL 写爆了」「Hive 查太慢」折磨过的人。下面我按「选型理由 → 环境搭建 → 写入实现 → 避坑 → 进阶调优」把这条链路拆开讲能抄的代码我都给全。2. 为什么是 Flink 写 HBase而不是别的组合2.1 电商实时场景对存储的三个硬要求先想清楚业务要什么再谈选型。电商实时链路对存储的要求基本是三条按主键随机读写查「用户 A 的实时画像」「订单 B 的当前状态」都是按一个 key 精确命中不需要扫全表。这是 HBase rowkey 设计的天然强项。高并发写入 水平扩展大促峰值每秒几十万条写入MySQL 单机顶不住分库分表又要改业务代码HBase 靠 Region 分裂天然水平扩展加机器就能扛。稀疏宽表用户画像动辄几百个标签但每个用户实际有值的标签可能就几十个。HBase 列族下按列存空列不占空间正好匹配。对比一下常见方案MySQL 适合强事务、数据量千万级以内Redis 适合纯 KV 缓存但持久化和复杂查询弱ClickHouse 适合 OLAP 聚合分析但不擅长高频单行更新。HBase 的定位正好卡在「海量 随机读写 稀疏宽表」这个区间这是它和 Flink 搭伙的根本原因。2.2 Flink 侧为什么用 HBase Connector 而不是 JDBC热搜里常看到「flink 的 jdbc 连接器异常」很多人第一反应是用 JDBC 连 HBase这是典型误区。HBase 根本不走 JDBC 协议它用的是原生 Java APITable/Connection。Flink 官方提供的是flink-connector-hbase底层封装的就是 HBase Client。用 JDBC 去连 HBase 要么连不上要么得套一层 Phoenix多一层就多一份延迟和故障点。所以正确姿势是Flink 用HBaseSink或自定义RichSinkFunction通过 HBase 原生 API 写入。前者适合简单 put后者适合你要做批量攒批、条件更新、多表写入的复杂逻辑。下面两章分别给这两种写法。2.3 rowkey 设计决定 HBase 会不会热点的命门HBase 按 rowkey 字典序排列相邻 rowkey 落在同一个 Region。如果 rowkey 是递增的订单 ID所有写入都会打到最后一个 Region形成写热点RegionServer 直接被打爆。电商场景常见的解法是加盐或反转加盐salt hash(userId) % regionCountrowkey salt userId写入打散到多个 Region。反转把递增 ID 反转比如订单号20240101123456反转成65432110104202让高位变化。代价是读的时候要按同样规则拼 rowkey范围查询会变复杂。所以一般做法是需要范围扫描的维度用反转纯点查的维度用加盐。这个决策要在建表前定死建完表再改 rowkey 等于重建。3. 把 HBase 环境跑起来安装、建表、验证一条龙3.1 单机伪分布式安装的最小步骤热搜里「hbase 安装与配置」「头歌 hbase 数据库的安装」出现频率很高说明很多人卡在环境这一步。下面给一套单机伪分布式的最小可跑流程依赖 JDK 和 Hadoop伪分布式即可。# 1. 解压并配置环境变量 tar -zxvf hbase-2.4.11-bin.tar.gz -C /opt/ echo export HBASE_HOME/opt/hbase-2.4.11 /etc/profile echo export PATH$PATH:$HBASE_HOME/bin /etc/profile source /etc/profile # 2. 修改 conf/hbase-site.xml指定 HBase 数据落在 HDFS # propertynamehbase.rootdir/namevaluehdfs://localhost:9000/hbase/value/property # propertynamehbase.cluster.distributed/namevaluetrue/value/property # propertynamehbase.zookeeper.quorum/namevaluelocalhost/value/property # 3. 启动先确保 Hadoop 已启动 start-hbase.sh # 4. 验证进入 shell 看状态 hbase shell # 在 shell 里执行 status看到 1 servers 即成功逻辑说明hbase.rootdir指向 HDFS 是为了让数据持久化伪分布式模式下 HMaster、HRegionServer、ZooKeeper 都在本机。参数上hbase.zookeeper.quorum必须和实际 ZooKeeper 地址一致写错会卡在启动阶段。启动后如果status报Connection refused九成是 ZooKeeper 没起来或端口被占。3.2 建一张电商用户画像宽表画像表是电商最典型的 HBase 表一个用户一行多个列族存不同维度的标签。# 在 hbase shell 中执行 create user_profile, \ {NAME basic, VERSIONS 1, BLOOMFILTER ROW}, \ {NAME behavior, VERSIONS 1, TTL 2592000}, \ {NAME order, VERSIONS 1}参数说明VERSIONS 1表示只保留最新版本画像标签不需要历史版本省空间BLOOMFILTER ROW开启行级布隆过滤器点查时能跳过不含目标 rowkey 的 HFile显著降低读延迟behavior列族设TTL 259200030 天行为数据过期自动清理避免表无限膨胀。列族不宜超过 3 个因为列族是 HBase 的物理存储单元列族越多flush 和 compaction 时产生的 IO 放大越严重。3.3 用 Java API 做一次读写验证热搜里「hbase 开发使用 java 操作 hbase」是高频需求先跑通一次原生读写后面接 Flink 才有底。// 依赖hbase-client 2.4.11 Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, localhost); conf.set(hbase.zookeeper.property.clientPort, 2181); try (Connection conn ConnectionFactory.createConnection(conf); Table table conn.getTable(TableName.valueOf(user_profile))) { // 写入rowkey 用户ID列族 basic列 age Put put new Put(Bytes.toBytes(user_1001)); put.addColumn(Bytes.toBytes(basic), Bytes.toBytes(age), Bytes.toBytes(28)); put.addColumn(Bytes.toBytes(basic), Bytes.toBytes(city), Bytes.toBytes(hangzhou)); table.put(put); // 读取 Get get new Get(Bytes.toBytes(user_1001)); Result result table.get(get); String age Bytes.toString(result.getValue( Bytes.toBytes(basic), Bytes.toBytes(age))); System.out.println(age age); }逻辑说明Connection是重量级对象必须复用不能每次读写都新建否则连接泄漏会把 RegionServer 拖垮。Table是轻量对象可以每次取。参数上hbase.zookeeper.property.clientPort默认 2181改过端口要同步。这段代码跑通说明 HBase 侧没问题可以进入 Flink 集成。4. Flink 写入 HBase 的两种落地写法4.1 用官方 HBaseSink 做简单写入如果只是把流数据一条条 put 进去官方HBaseSink最省事。// 依赖flink-connector-hbase-2.4 Configuration hbaseConf HBaseConfiguration.create(); hbaseConf.set(hbase.zookeeper.quorum, localhost); HBaseSinkRow sink new HBaseSink.BuilderRow(hbaseConf, new HBaseMutationConverterRow() { Override public void open() {} Override public Mutation convertToMutation(Row row) { // 用 userId 作为 rowkey写入 behavior 列族 Put put new Put(Bytes.toBytes(row.getField(userId).toString())); put.addColumn(Bytes.toBytes(behavior), Bytes.toBytes(lastClick), Bytes.toBytes(row.getField(clickTime).toString())); return put; } }).setBufferFlushMaxSizeInBytes(2 * 1024 * 1024) .setBufferFlushIntervalMillis(2000) .build(); stream.addSink(sink);逻辑说明HBaseMutationConverter是核心把 Flink 的Row映射成 HBase 的Put。参数上setBufferFlushMaxSizeInBytes和setBufferFlushIntervalMillis控制攒批达到 2MB 或 2 秒任一条件就 flush。这两个值直接决定吞吐和延迟的平衡——调大吞吐高但延迟高调小反之。大促场景我一般设 2MB/2s平时设 1MB/1s。4.2 用 RichSinkFunction 做批量攒批写入官方 Sink 在需要「按业务维度聚合后再写」「多表写入」「条件更新」时就不够用了这时候自定义RichSinkFunction更灵活。public class HBaseBatchSink extends RichSinkFunctionRow { private transient Connection conn; private transient BufferedMutator mutator; Override public void open(Configuration parameters) throws Exception { Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, localhost); conn ConnectionFactory.createConnection(conf); // BufferedMutator 自带异步攒批比手动 List 更稳 BufferedMutatorParams params new BufferedMutatorParams( TableName.valueOf(user_profile)) .writeBufferSize(4 * 1024 * 1024); mutator conn.getBufferedMutator(params); } Override public void invoke(Row row, Context context) throws Exception { Put put new Put(Bytes.toBytes(row.getField(userId).toString())); put.addColumn(Bytes.toBytes(order), Bytes.toBytes(lastOrderId), Bytes.toBytes(row.getField(orderId).toString())); mutator.mutate(put); // 异步攒批不阻塞 } Override public void close() throws Exception { if (mutator ! null) mutator.close(); // 必须 flush 剩余数据 if (conn ! null) conn.close(); } }逻辑说明BufferedMutator是 HBase 客户端自带的异步批量写入器内部维护写缓冲区攒够writeBufferSize自动提交比自己在invoke里维护 List 再批量 put 更可靠。关键坑在close()如果不调mutator.close()缓冲区里没提交的数据会丢这是血泪教训。参数上writeBufferSize设 4MB 是经验值太小频繁 RPC太大内存压力大。4.3 维表关联用 HBase 做 Lookup Join电商实时链路里订单流要关联用户画像这就是维表关联。Flink 提供HBaseLookupFunction做 Lookup Join。// 定义 HBase 维表 String ddl CREATE TABLE user_dim ( user_id STRING, city STRING, level STRING, PRIMARY KEY (user_id) NOT ENFORCED ) WITH ( connector hbase-2.2, table-name user_profile, zookeeper.quorum localhost:2181); tableEnv.executeSql(ddl); // 订单流与维表 join String joinSql SELECT o.orderId, o.amount, d.city, d.level FROM order_stream AS o JOIN user_dim FOR SYSTEM_TIME AS OF o.proc_time AS d ON o.userId d.user_id;逻辑说明FOR SYSTEM_TIME AS OF o.proc_time是 Lookup Join 的语法表示用订单到达时刻去 HBase 查一次维表。参数上connector写hbase-2.2是 Flink 的 connector 标识对应 HBase 2.x。这里有个性能点Lookup Join 默认每条数据查一次 HBaseQPS 高时会把 HBase 读爆生产上要开lookup.cache.max-rows和lookup.cache.ttl做本地缓存。5. 踩过的坑FlinkHBase 链路的 5 个翻车现场5.1 写入热点导致 RegionServer 被打爆现象大促开始后HBase 写入延迟从 5ms 飙到 500ms监控看到某个 RegionServer 的请求量是其他节点的 10 倍。原因rowkey 用了递增的订单 ID所有写入集中到最后一个 Region。解决rowkey 加盐rowkey (hash(userId) % 16) _ userId写入打散到 16 个 Region。改完后各节点请求量均衡。注意加盐后点查要按同样规则拼 rowkey范围查询要扫所有盐值分区。5.2 Sink 关闭时数据丢失现象任务正常停止后最后几秒的数据在 HBase 里查不到。原因BufferedMutator缓冲区里的数据没 flushclose()里只关了 Connection 没关 mutator。解决close()里先mutator.close()再conn.close()顺序不能反。另外开启 Flink checkpoint配合HBaseSink的 exactly-once 语义任务失败恢复时不会丢。5.3 Lookup Join 把 HBase 读挂现象订单流 QPS 上来后HBase 读请求暴涨RegionServer 的 RPC 队列打满连带写入也变慢。原因Lookup Join 每条数据都查一次 HBase没有缓存。解决在 DDL 里加lookup.cache.max-rows 10000和lookup.cache.ttl 10min把维表数据缓存在 Flink 的 LRU Cache 里。代价是维表更新有最多 10 分钟延迟画像这种变化不频繁的维度可以接受。5.4 列族过多导致 compaction 风暴现象HBase 集群每隔一段时间 IO 飙升写入抖动严重。原因建表时按业务维度建了 8 个列族每次 flush 产生 8 个 HFilecompaction 时 IO 放大 8 倍。解决列族控制在 3 个以内把访问模式相近的列合并到一个列族。已经建的表可以alter合并但数据量大时耗时很长最好建表前就规划好。5.5 Flink 任务反压导致 checkpoint 超时现象Flink UI 上 Sink 算子显示反压checkpoint 一直失败。原因HBase 写入变慢比如 Region 在 splitSink 处理不过来反压传导到上游。解决一是调大writeBufferSize和攒批间隔减少 RPC 次数二是给 HBase 写入加超时和重试hbase.client.retries.number设 3hbase.client.operation.timeout设 30s三是监控 Region split提前做预分区避免运行中 split。6. 进阶预分区、监控与压测把链路调到能扛大促6.1 建表时预分区避免运行中 splitHBase 默认建表只有一个 Region数据写满才 splitsplit 期间该 Region 不可写直接造成写入抖动。生产上必须预分区。# 按 rowkey 前两位的 hash 值预分 16 个区 create user_profile, \ {NAME basic, VERSIONS 1}, \ {NAME behavior, VERSIONS 1, TTL 2592000}, \ {NAME order, VERSIONS 1}, \ SPLITS [0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f]逻辑说明SPLITS指定 16 个分割点建表时就生成 16 个 Region写入直接打散。分割点要和 rowkey 加盐规则对应——如果 rowkey 是hash % 16的十六进制前缀分割点就用0到f。预分区数量按「峰值写入 QPS / 单 Region 承载能力」估算单 Region 写入经验值 1-2 万 QPS大促峰值 20 万 QPS 就分 16 个区留余量。6.2 关键监控指标清单调优不能靠猜得看指标。下面这张表是我日常盯的 HBase 侧核心指标。指标含义告警阈值排查方向hbase.regionserver.writeRequestCount写入请求数单节点突增 3 倍是否热点hbase.regionserver.blockCacheHitRatio读缓存命中率低于 0.8内存不足或读模式异常hbase.regionserver.compactionQueueSizecompaction 队列长度持续大于 10列族过多或写入过快hbase.regionserver.flushQueueSizeflush 队列长度持续大于 5memstore 太小或写入过猛hbase.regionserver.rpcQueueSizeRPC 队列长度持续大于 100读写压力超载Flink 侧则盯numRecordsOutPerSecondSink 吞吐、currentSendTime发送耗时和 checkpoint 的alignmentDuration。两边指标对着看能快速定位是 Flink 写不过来还是 HBase 扛不住。6.3 用压测确定容量水位上线前一定要压测。我的做法是用 Flink 造一批模拟数据按大促峰值的 1.5 倍打进去观察 HBase 的写入延迟和 Flink 的反压情况。// 用 Flink 的 DataGenerator 造压测数据 DataGeneratorSourceRow source new DataGeneratorSource( new RowGenerator() { Override public Row next() { return Row.of( user_ (int)(Math.random() * 1000000), System.currentTimeMillis(), Math.random() * 1000 ); } }, 200000L, // 每秒 20 万条 RateLimiterStrategy.perSecond(200000), Types.ROW(Types.STRING, Types.LONG, Types.DOUBLE) );逻辑说明RateLimiterStrategy.perSecond(200000)控制发送速率模拟峰值。压测时重点看三个数HBase 写入 P99 延迟是否小于 50ms、Flink Sink 是否反压、RegionServer 的 RPC 队列是否堆积。如果 P99 超过 100ms就要加 Region 或调大攒批。压测数据要和生产数据分布接近否则测出来的容量没参考价值。6.4 一个我常犯的错最后说个我自己的教训。早期做这条链路时我总觉得「写入慢就加机器」结果加了机器热点还在因为 rowkey 设计错了加机器只是让更多节点闲着。后来才明白HBase 的性能问题八成出在 rowkey 和列族设计上调参和加机器只能解决剩下两成。所以每次新链路我都会先花半天把 rowkey 规则、预分区、列族规划写清楚再动手写 Flink 代码。这个习惯帮我省了无数次半夜爬起来处理热点的后悔药。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/6 17:58:55 · 阅读 1.2k Flink+HBase电商实时数仓实战：写入、维表关联与调优
简介这份PDF文档聚焦Apache Flink与HBase在阿里巴巴电商业务中的落地实践面向大数据开发工程师、实时计算架构师及对电商实时数据处理感兴趣的技术人员帮助读者理解如何用Flink流处理与HBase存储构建高并发、可扩展的实时数据链路。资源包内仅含1个PDF文件大小约2.9MB内容以技术分享讲稿形式呈现涵盖业务背景、典型场景、技术架构与具体实现代码。文档围绕报表监控、商品库管理、用户足迹分析、生意参谋、供应链预警及全链路debug平台等场景展开并给出Flink SQL与Table API的聚合计算、HBase表DDL定义、数据写入Sink等示例同时涉及2000机器、单机QPS 20W、亿级数据量的优化策略。目前已有167人学习适合希望借鉴阿里实战经验、掌握Flink与HBase协同开发思路的读者参考。1. 从一份 PDF 标题说起FlinkHBase 在电商业务里到底扛了什么活电商大促的凌晨订单、加购、收藏、退款、物流轨迹这些数据像开闸一样涌进来运营要的是「这个用户最近 30 分钟看了什么、加购了什么、有没有下单」风控要的是「这个设备/IP 是不是在刷单」推荐要的是「实时画像」。这些诉求有一个共同点写多读也多、单条数据小、按行随机读写、要求毫秒级响应。用 HDFS 存、用 Hive 查延迟扛不住用 MySQL 硬顶写入一上来就锁表。这时候 FlinkHBase 的组合就上场了Flink 负责把上游 Kafka/日志里的流数据做清洗、聚合、维表关联HBase 负责把结果按 rowkey 落成一张能随机读写的宽表供下游推荐、风控、运营后台实时查询。这份标题里的「阿里巴巴电商业务中的应用」本质讲的就是这条链路流计算做实时加工HBase 做实时存储两者拼成一个能扛住大促峰值的实时数仓底座。适合谁看做实时数仓、用户画像、订单宽表、风控特征存储的工程师尤其是被「MySQL 写爆了」「Hive 查太慢」折磨过的人。下面我按「选型理由 → 环境搭建 → 写入实现 → 避坑 → 进阶调优」把这条链路拆开讲能抄的代码我都给全。2. 为什么是 Flink 写 HBase而不是别的组合2.1 电商实时场景对存储的三个硬要求先想清楚业务要什么再谈选型。电商实时链路对存储的要求基本是三条按主键随机读写查「用户 A 的实时画像」「订单 B 的当前状态」都是按一个 key 精确命中不需要扫全表。这是 HBase rowkey 设计的天然强项。高并发写入 水平扩展大促峰值每秒几十万条写入MySQL 单机顶不住分库分表又要改业务代码HBase 靠 Region 分裂天然水平扩展加机器就能扛。稀疏宽表用户画像动辄几百个标签但每个用户实际有值的标签可能就几十个。HBase 列族下按列存空列不占空间正好匹配。对比一下常见方案MySQL 适合强事务、数据量千万级以内Redis 适合纯 KV 缓存但持久化和复杂查询弱ClickHouse 适合 OLAP 聚合分析但不擅长高频单行更新。HBase 的定位正好卡在「海量 随机读写 稀疏宽表」这个区间这是它和 Flink 搭伙的根本原因。2.2 Flink 侧为什么用 HBase Connector 而不是 JDBC热搜里常看到「flink 的 jdbc 连接器异常」很多人第一反应是用 JDBC 连 HBase这是典型误区。HBase 根本不走 JDBC 协议它用的是原生 Java APITable/Connection。Flink 官方提供的是flink-connector-hbase底层封装的就是 HBase Client。用 JDBC 去连 HBase 要么连不上要么得套一层 Phoenix多一层就多一份延迟和故障点。所以正确姿势是Flink 用HBaseSink或自定义RichSinkFunction通过 HBase 原生 API 写入。前者适合简单 put后者适合你要做批量攒批、条件更新、多表写入的复杂逻辑。下面两章分别给这两种写法。2.3 rowkey 设计决定 HBase 会不会热点的命门HBase 按 rowkey 字典序排列相邻 rowkey 落在同一个 Region。如果 rowkey 是递增的订单 ID所有写入都会打到最后一个 Region形成写热点RegionServer 直接被打爆。电商场景常见的解法是加盐或反转加盐salt hash(userId) % regionCountrowkey salt userId写入打散到多个 Region。反转把递增 ID 反转比如订单号20240101123456反转成65432110104202让高位变化。代价是读的时候要按同样规则拼 rowkey范围查询会变复杂。所以一般做法是需要范围扫描的维度用反转纯点查的维度用加盐。这个决策要在建表前定死建完表再改 rowkey 等于重建。3. 把 HBase 环境跑起来安装、建表、验证一条龙3.1 单机伪分布式安装的最小步骤热搜里「hbase 安装与配置」「头歌 hbase 数据库的安装」出现频率很高说明很多人卡在环境这一步。下面给一套单机伪分布式的最小可跑流程依赖 JDK 和 Hadoop伪分布式即可。# 1. 解压并配置环境变量 tar -zxvf hbase-2.4.11-bin.tar.gz -C /opt/ echo export HBASE_HOME/opt/hbase-2.4.11 /etc/profile echo export PATH$PATH:$HBASE_HOME/bin /etc/profile source /etc/profile # 2. 修改 conf/hbase-site.xml指定 HBase 数据落在 HDFS # propertynamehbase.rootdir/namevaluehdfs://localhost:9000/hbase/value/property # propertynamehbase.cluster.distributed/namevaluetrue/value/property # propertynamehbase.zookeeper.quorum/namevaluelocalhost/value/property # 3. 启动先确保 Hadoop 已启动 start-hbase.sh # 4. 验证进入 shell 看状态 hbase shell # 在 shell 里执行 status看到 1 servers 即成功逻辑说明hbase.rootdir指向 HDFS 是为了让数据持久化伪分布式模式下 HMaster、HRegionServer、ZooKeeper 都在本机。参数上hbase.zookeeper.quorum必须和实际 ZooKeeper 地址一致写错会卡在启动阶段。启动后如果status报Connection refused九成是 ZooKeeper 没起来或端口被占。3.2 建一张电商用户画像宽表画像表是电商最典型的 HBase 表一个用户一行多个列族存不同维度的标签。# 在 hbase shell 中执行 create user_profile, \ {NAME basic, VERSIONS 1, BLOOMFILTER ROW}, \ {NAME behavior, VERSIONS 1, TTL 2592000}, \ {NAME order, VERSIONS 1}参数说明VERSIONS 1表示只保留最新版本画像标签不需要历史版本省空间BLOOMFILTER ROW开启行级布隆过滤器点查时能跳过不含目标 rowkey 的 HFile显著降低读延迟behavior列族设TTL 259200030 天行为数据过期自动清理避免表无限膨胀。列族不宜超过 3 个因为列族是 HBase 的物理存储单元列族越多flush 和 compaction 时产生的 IO 放大越严重。3.3 用 Java API 做一次读写验证热搜里「hbase 开发使用 java 操作 hbase」是高频需求先跑通一次原生读写后面接 Flink 才有底。// 依赖hbase-client 2.4.11 Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, localhost); conf.set(hbase.zookeeper.property.clientPort, 2181); try (Connection conn ConnectionFactory.createConnection(conf); Table table conn.getTable(TableName.valueOf(user_profile))) { // 写入rowkey 用户ID列族 basic列 age Put put new Put(Bytes.toBytes(user_1001)); put.addColumn(Bytes.toBytes(basic), Bytes.toBytes(age), Bytes.toBytes(28)); put.addColumn(Bytes.toBytes(basic), Bytes.toBytes(city), Bytes.toBytes(hangzhou)); table.put(put); // 读取 Get get new Get(Bytes.toBytes(user_1001)); Result result table.get(get); String age Bytes.toString(result.getValue( Bytes.toBytes(basic), Bytes.toBytes(age))); System.out.println(age age); }逻辑说明Connection是重量级对象必须复用不能每次读写都新建否则连接泄漏会把 RegionServer 拖垮。Table是轻量对象可以每次取。参数上hbase.zookeeper.property.clientPort默认 2181改过端口要同步。这段代码跑通说明 HBase 侧没问题可以进入 Flink 集成。4. Flink 写入 HBase 的两种落地写法4.1 用官方 HBaseSink 做简单写入如果只是把流数据一条条 put 进去官方HBaseSink最省事。// 依赖flink-connector-hbase-2.4 Configuration hbaseConf HBaseConfiguration.create(); hbaseConf.set(hbase.zookeeper.quorum, localhost); HBaseSinkRow sink new HBaseSink.BuilderRow(hbaseConf, new HBaseMutationConverterRow() { Override public void open() {} Override public Mutation convertToMutation(Row row) { // 用 userId 作为 rowkey写入 behavior 列族 Put put new Put(Bytes.toBytes(row.getField(userId).toString())); put.addColumn(Bytes.toBytes(behavior), Bytes.toBytes(lastClick), Bytes.toBytes(row.getField(clickTime).toString())); return put; } }).setBufferFlushMaxSizeInBytes(2 * 1024 * 1024) .setBufferFlushIntervalMillis(2000) .build(); stream.addSink(sink);逻辑说明HBaseMutationConverter是核心把 Flink 的Row映射成 HBase 的Put。参数上setBufferFlushMaxSizeInBytes和setBufferFlushIntervalMillis控制攒批达到 2MB 或 2 秒任一条件就 flush。这两个值直接决定吞吐和延迟的平衡——调大吞吐高但延迟高调小反之。大促场景我一般设 2MB/2s平时设 1MB/1s。4.2 用 RichSinkFunction 做批量攒批写入官方 Sink 在需要「按业务维度聚合后再写」「多表写入」「条件更新」时就不够用了这时候自定义RichSinkFunction更灵活。public class HBaseBatchSink extends RichSinkFunctionRow { private transient Connection conn; private transient BufferedMutator mutator; Override public void open(Configuration parameters) throws Exception { Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, localhost); conn ConnectionFactory.createConnection(conf); // BufferedMutator 自带异步攒批比手动 List 更稳 BufferedMutatorParams params new BufferedMutatorParams( TableName.valueOf(user_profile)) .writeBufferSize(4 * 1024 * 1024); mutator conn.getBufferedMutator(params); } Override public void invoke(Row row, Context context) throws Exception { Put put new Put(Bytes.toBytes(row.getField(userId).toString())); put.addColumn(Bytes.toBytes(order), Bytes.toBytes(lastOrderId), Bytes.toBytes(row.getField(orderId).toString())); mutator.mutate(put); // 异步攒批不阻塞 } Override public void close() throws Exception { if (mutator ! null) mutator.close(); // 必须 flush 剩余数据 if (conn ! null) conn.close(); } }逻辑说明BufferedMutator是 HBase 客户端自带的异步批量写入器内部维护写缓冲区攒够writeBufferSize自动提交比自己在invoke里维护 List 再批量 put 更可靠。关键坑在close()如果不调mutator.close()缓冲区里没提交的数据会丢这是血泪教训。参数上writeBufferSize设 4MB 是经验值太小频繁 RPC太大内存压力大。4.3 维表关联用 HBase 做 Lookup Join电商实时链路里订单流要关联用户画像这就是维表关联。Flink 提供HBaseLookupFunction做 Lookup Join。// 定义 HBase 维表 String ddl CREATE TABLE user_dim ( user_id STRING, city STRING, level STRING, PRIMARY KEY (user_id) NOT ENFORCED ) WITH ( connector hbase-2.2, table-name user_profile, zookeeper.quorum localhost:2181); tableEnv.executeSql(ddl); // 订单流与维表 join String joinSql SELECT o.orderId, o.amount, d.city, d.level FROM order_stream AS o JOIN user_dim FOR SYSTEM_TIME AS OF o.proc_time AS d ON o.userId d.user_id;逻辑说明FOR SYSTEM_TIME AS OF o.proc_time是 Lookup Join 的语法表示用订单到达时刻去 HBase 查一次维表。参数上connector写hbase-2.2是 Flink 的 connector 标识对应 HBase 2.x。这里有个性能点Lookup Join 默认每条数据查一次 HBaseQPS 高时会把 HBase 读爆生产上要开lookup.cache.max-rows和lookup.cache.ttl做本地缓存。5. 踩过的坑FlinkHBase 链路的 5 个翻车现场5.1 写入热点导致 RegionServer 被打爆现象大促开始后HBase 写入延迟从 5ms 飙到 500ms监控看到某个 RegionServer 的请求量是其他节点的 10 倍。原因rowkey 用了递增的订单 ID所有写入集中到最后一个 Region。解决rowkey 加盐rowkey (hash(userId) % 16) _ userId写入打散到 16 个 Region。改完后各节点请求量均衡。注意加盐后点查要按同样规则拼 rowkey范围查询要扫所有盐值分区。5.2 Sink 关闭时数据丢失现象任务正常停止后最后几秒的数据在 HBase 里查不到。原因BufferedMutator缓冲区里的数据没 flushclose()里只关了 Connection 没关 mutator。解决close()里先mutator.close()再conn.close()顺序不能反。另外开启 Flink checkpoint配合HBaseSink的 exactly-once 语义任务失败恢复时不会丢。5.3 Lookup Join 把 HBase 读挂现象订单流 QPS 上来后HBase 读请求暴涨RegionServer 的 RPC 队列打满连带写入也变慢。原因Lookup Join 每条数据都查一次 HBase没有缓存。解决在 DDL 里加lookup.cache.max-rows 10000和lookup.cache.ttl 10min把维表数据缓存在 Flink 的 LRU Cache 里。代价是维表更新有最多 10 分钟延迟画像这种变化不频繁的维度可以接受。5.4 列族过多导致 compaction 风暴现象HBase 集群每隔一段时间 IO 飙升写入抖动严重。原因建表时按业务维度建了 8 个列族每次 flush 产生 8 个 HFilecompaction 时 IO 放大 8 倍。解决列族控制在 3 个以内把访问模式相近的列合并到一个列族。已经建的表可以alter合并但数据量大时耗时很长最好建表前就规划好。5.5 Flink 任务反压导致 checkpoint 超时现象Flink UI 上 Sink 算子显示反压checkpoint 一直失败。原因HBase 写入变慢比如 Region 在 splitSink 处理不过来反压传导到上游。解决一是调大writeBufferSize和攒批间隔减少 RPC 次数二是给 HBase 写入加超时和重试hbase.client.retries.number设 3hbase.client.operation.timeout设 30s三是监控 Region split提前做预分区避免运行中 split。6. 进阶预分区、监控与压测把链路调到能扛大促6.1 建表时预分区避免运行中 splitHBase 默认建表只有一个 Region数据写满才 splitsplit 期间该 Region 不可写直接造成写入抖动。生产上必须预分区。# 按 rowkey 前两位的 hash 值预分 16 个区 create user_profile, \ {NAME basic, VERSIONS 1}, \ {NAME behavior, VERSIONS 1, TTL 2592000}, \ {NAME order, VERSIONS 1}, \ SPLITS [0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f]逻辑说明SPLITS指定 16 个分割点建表时就生成 16 个 Region写入直接打散。分割点要和 rowkey 加盐规则对应——如果 rowkey 是hash % 16的十六进制前缀分割点就用0到f。预分区数量按「峰值写入 QPS / 单 Region 承载能力」估算单 Region 写入经验值 1-2 万 QPS大促峰值 20 万 QPS 就分 16 个区留余量。6.2 关键监控指标清单调优不能靠猜得看指标。下面这张表是我日常盯的 HBase 侧核心指标。指标含义告警阈值排查方向hbase.regionserver.writeRequestCount写入请求数单节点突增 3 倍是否热点hbase.regionserver.blockCacheHitRatio读缓存命中率低于 0.8内存不足或读模式异常hbase.regionserver.compactionQueueSizecompaction 队列长度持续大于 10列族过多或写入过快hbase.regionserver.flushQueueSizeflush 队列长度持续大于 5memstore 太小或写入过猛hbase.regionserver.rpcQueueSizeRPC 队列长度持续大于 100读写压力超载Flink 侧则盯numRecordsOutPerSecondSink 吞吐、currentSendTime发送耗时和 checkpoint 的alignmentDuration。两边指标对着看能快速定位是 Flink 写不过来还是 HBase 扛不住。6.3 用压测确定容量水位上线前一定要压测。我的做法是用 Flink 造一批模拟数据按大促峰值的 1.5 倍打进去观察 HBase 的写入延迟和 Flink 的反压情况。// 用 Flink 的 DataGenerator 造压测数据 DataGeneratorSourceRow source new DataGeneratorSource( new RowGenerator() { Override public Row next() { return Row.of( user_ (int)(Math.random() * 1000000), System.currentTimeMillis(), Math.random() * 1000 ); } }, 200000L, // 每秒 20 万条 RateLimiterStrategy.perSecond(200000), Types.ROW(Types.STRING, Types.LONG, Types.DOUBLE) );逻辑说明RateLimiterStrategy.perSecond(200000)控制发送速率模拟峰值。压测时重点看三个数HBase 写入 P99 延迟是否小于 50ms、Flink Sink 是否反压、RegionServer 的 RPC 队列是否堆积。如果 P99 超过 100ms就要加 Region 或调大攒批。压测数据要和生产数据分布接近否则测出来的容量没参考价值。6.4 一个我常犯的错最后说个我自己的教训。早期做这条链路时我总觉得「写入慢就加机器」结果加了机器热点还在因为 rowkey 设计错了加机器只是让更多节点闲着。后来才明白HBase 的性能问题八成出在 rowkey 和列族设计上调参和加机器只能解决剩下两成。所以每次新链路我都会先花半天把 rowkey 规则、预分区、列族规划写清楚再动手写 Flink 代码。这个习惯帮我省了无数次半夜爬起来处理热点的后悔药。希望帮到你。本文还有配套的精品资源点击获取