企业官网建设流程全解析

花了大半周时间，终于把 Flume + HBase + Kafka 这条数据管道完整地跑通了，从环境搭建到数据落地，中间踩了不少坑，也理清了很多之前模棱两可的概念。这套组合在大数据领域非常经典：Flume 负责采集日志，Kafka 负责削峰和缓冲，HBase 负责海量数据的实时读写。如果你正在搭建日志采集系统、准备做用户行为分析，或者想搞清楚这几个组件到底怎么配合，这篇文章应该能让你少走很多弯路。

先说清楚这套东西解决了什么问题。假设你有几十台服务器在不停产生日志，直接让业务程序往 HBase 里写，首先并发压力扛不住，其次 HBase 的写放大效应会让集群负载忽高忽低。Flume 把分散的日志集中收拢，Kafka 在中间做一个大号的“蓄水池”，下游消费程序按照自己的节奏去消费，最终落到 HBase 存储。整个过程是异步解耦的，数据不会丢，也不会把存储端打挂。我这次搭的是最小可用版本：单机部署所有组件，日志文件作为数据源，验证从采集到存储分发的全链路流程，但配置和生产环境是一致的，换到集群环境也只需要改几个地址参数。

1. 整体架构设计与组件角色定位

1.1 为什么是这三个组件，而不是其他方案

很多人第一次接触这条链路会问：直接用 Logstash + Elasticsearch 不行吗，或者直接用 Kafka Connect 不香吗？这得分场景。Logstash 全家桶在日志检索和可视化上确实强，但它本质是一个管道工具，存储层做数据分析能力偏弱。而一旦数据量到了每天几亿条，需要按 RowKey 做高并发随机读写，或者要对海量历史数据做扫描，HBase 比 ES 更合适。Kafka Connect 虽然能对接 HBase，但控制灵活性差一些，一旦需要做清洗、补字段、个性化表结构设计，写一个原生消费者会更顺手。

Flume 在这里承担的是“搬运工”角色。它最擅长的是监控文件、目录、端口，然后把数据推送到下游。相比直接用 Filebeat 之类的采集器，Flume 内置了强大的 Channel 缓冲机制；相比写一个定时脚本去 scp 日志，Flume 支持断点续传和事务保障，不丢数据。所以选它的核心原因不是它功能多，而是它对“文件到消息队列”这件事支持得最成熟，而且足够轻量。

Kafka 的角色就更好理解了。采集端可能瞬时爆发，比如半夜任务集中跑批，或者某个接口突然被刷。如果 Flume 直接写 HBase，HBase 的 memstore 会被瞬间打满，触发刷写，导致 CPU 飙升、响应变慢。Kafka 像一个蓄水池，上游随便泄洪，下游按需取水。同时它也为“一份数据多个消费者”提供了便利，比如同一条日志既要做实时指标统计，又要入离线数仓，加一个新的消费组就行，完全不影响已有链路。

1.2 数据流全链路拆解与各环节职责

我把这次测试的完整数据流画出来，应该一眼就能看明白整条链路的职责划分：

日志文件 -> Flume Source 监听文件新增行 -> Channel 缓冲 -> Kafka Sink 发送 -> Topic 存储流转 -> HBase 消费程序拉取 -> 解析 -> 批量 Put -> HBase RegionServer

这个链路里的每个环节都有明确的职责边界。Flume 只做采集，不管数据长什么样；Kafka 只做传输和暂存，不关心数据内容；消费程序负责解析和转换；HBase 负责最终存储。唯一需要人肉介入的，就是消费程序里对数据格式的处理逻辑。这种职责单一的好处是：任何一个环节出问题，不会污染其他环节的数据，排查起来也容易定位。

每个组件内部还有一个“小链路”。比如 Flume 有三件套：Source、Channel、Sink。Source 读取文件行，放进 Channel，Sink 再从 Channel 拿数据发给 Kafka。Source 和 Sink 之间通过 Channel 解耦，两端的速率不一致不影响彼此。Kafka 内部则是 Producer、Broker、Consumer 三段：Flume 充当 Producer，Broker 负责分区存储，消费程序是 Consumer。HBase 内部虽然也有写路径，但对我们开发人员来说基本透明，只需要关心表设计。

2. 测试环境搭建与组件基础配置

2.1 版本选型与基础设施要求

先说版本，这地方很容易给自己挖坑。我这次用的组合是：JDK 1.8、Flume 1.9.0、Kafka 2.8.0（自带 ZooKeeper 但我是单独装的）、HBase 2.4.17。这套版本在测试环境跑了四天，没有遇到明显的兼容性问题。如果你的项目已经在用其他版本，务必确认一点：Flume 的 Kafka Sink 底层依赖 Kafka 客户端版本，和你的 Kafka Broker 版本差异不要超过一个中版本。否则可能出现协议不兼容，Flume 启动报错“NoSuchMethodError”或者“UnsupportedVersionException”之类的问题。

另外一个基础设施层面的坑是依赖组件的重叠。Kafka 2.8 开始可以不用 ZooKeeper，但 HBase 必须要 ZooKeeper。很多人在同一台机器上装了 Kafka 自带的 ZooKeeper 又装了独立的 ZooKeeper，端口冲突搞得启动不了。我的建议是测试环境只维护一套独立 ZooKeeper，Kafka 和 HBase 共用，虽然 Kafka 官方已经在去 ZooKeeper 化，但共用能省一个进程，测试完全够用。

还需要注意内存分配。HBase 的 RegionServer 默认堆内存可能只有 1GB，跑小数据量没问题，但我在压测时数据量一上来就频繁 Full GC，导致写请求停顿。测试环境建议手动把 HBASE_HEAPSIZE 设置为 2GB 到 4GB。Kafka 的堆内存反而不需要太大，它依赖操作系统的页缓存，堆外内存留给系统当缓冲区更好。Flume 的内存默认 1GB 够用，只要 Channel 数据量别太大。

2.2 各组件安装配置要点

安装已经没有技术含量了，解压即用，关键是配置。我把几个关键配置项做了记录。

ZooKeeper 我用的 3.5.8，配置文件只改了两处：clientPort 保持默认 2181，dataDir 指向磁盘上空间充裕的目录。启动之后先跑一下bin/zkServer.sh status确认起来了，再用 Flume 之前先通过zkCli.sh -server localhost:2181测一下连通性。很多 Flume 报错连接 Kafka 超时，根子其实是 Kafka 在 ZooKeeper 上注册的地址不对，提前验证 ZooKeeper 能省不少排查时间。

Kafka 的 server.properties 需要注意几个点。listeners=PLAINTEXT://localhost:9092这个配置，之前有同事图省事配置成0.0.0.0，结果客户端一直在连，报错却全是连接超时。log.dirs要指定到一个空间充足的目录，Kafka 的 Segment 日志如果磁盘满了会直接拒绝写入。另外log.retention.hours我设成了 72，测试周期内足够翻查消息，避免数据被过早清理。

HBase 的 hbase-site.xml 重点配置hbase.rootdir指向 HDFS 或者本地文件系统。测试环境没有 HDFS，我用的是本地路径，也就是 thelocal file system：file:///data/hbase。这里有个细节：如果后面换成 HDFS，根目录必须是一个不存在的路径，HBase 会自动创建，否则也会报错。hbase.zookeeper.quorum指向 ZooKeeper 地址。集群环境还需要把hbase.cluster.distributed配成 true，单机测试保持 false 就行。

我整理了一个最小可用的基础配置对照表，方便对照排查：

组件之间还有一个很隐蔽的依赖关系容易被忽略：HBase 需要在系统 hosts 文件里配置主机名映射。如果/etc/hosts里只写了 127.0.0.1 却没有写自己的主机名，HBase 启动后 RegionServer 可能注册失败，排查半天都不知道为什么。提前把hostname输出的名字和 IP 写进 hosts，这是新手最容易忽略的一步。

3. Flume 端配置：采集与投递 Kafka 的实现细节

3.1 Flume 核心配置逐行解析

Flume 的配置是整个链路里第一个真正需要动脑子的地方。我用的 flume.conf 本质上只干一件事：监听一个日志文件，把新增的每一行发给 Kafka。但是配置里有大量可以调整的参数，每一个都对应不同的行为语义。先看我的完整配置文件：

agent.sources = src1 agent.channels = ch1 agent.sinks = sink1 agent.sources.src1.type = taildir agent.sources.src1.positionFile = /data/flume/taildir_position.json agent.sources.src1.filegroups = f1 agent.sources.src1.filegroups.f1 = /data/logs/app/.*\.log agent.sources.src1.fileHeader = true agent.channels.ch1.type = memory agent.channels.ch1.capacity = 10000 agent.channels.ch1.transactionCapacity = 5000 agent.sinks.sink1.type = org.apache.flume.sink.kafka.KafkaSink agent.sinks.sink1.kafka.bootstrap.servers = localhost:9092 agent.sinks.sink1.kafka.topic = app-log-topic agent.sinks.sink1.kafka.flumeBatchSize = 500 agent.sinks.sink1.kafka.producer.acks = all agent.sources.src1.channels = ch1 agent.sinks.sink1.channel = ch1

第一眼看这个配置，最大的亮点是 Source 类型用的 taildir，而不是大多数人熟悉的 spooldir 或 exec。taildir 和 exectail -F行为类似，但多了记忆功能。它会把文件里已经消费到的位置记录在 positionFile 里，Flume 重启后能接着断点继续读，不会重复也不会丢。spooldir 只适合处理固定文件名的目录，每个文件只能完整消费一次，不适合日志这种持续追加的场景。所以只要目标是无边界的日志文件，taildir 就是第一选择。

Channel 我用的 memory。优点是吞吐高、延迟低，缺点是 Flume 进程挂了数据会丢。Kafka 和 HBase 的框架设计都足够可靠，但这不代表每个环节都能扔数据。我做测试时用 memory 图省事，但如果你在生产环境，文件改成 file channel 更稳妥，代价是磁盘 IO 和吞吐量会打折。后面故障排查部分我还会再提这一点。

Kafka Sink 部分最值得关注的是kafka.producer.acks = all。acks 代表 Kafka 确认消息写入的节点数量。设成 all 意味着只有所有副本都写入成功才算发送成功，这是最严的保证；代价是延迟和吞吐量有损耗。测试环境无所谓，生产环境如果你能接受极端情况下丢失少量数据换吞吐，可以设成 1，但日志系统多数还是建议 all，毕竟日志丢了就没法重建了。

3.2 生产场景的调参与注意事项

配置能跑起来很简单，但跑起来之后你会发现几个性能瓶颈点。首先是 taildir 的filegroups正则要注意：同一个文件组里如果有多个文件，taildir 会顺序读取还是并发读取？它内部实际上是单线程串行处理每个文件的新增内容的，所以如果多个日志文件都在高频写入，单个 Flume agent 会形成瓶颈。生产上的解法是：把不同来源文件的日志拆成多个 filegroup，甚至起多个 agent，每个负责一部分文件。

第二个调参重点是 Channel 的 capacity 和 transactionCapacity。capacity 是 Channel 里最多缓存多少条消息，transactionCapacity 是 Source 或 Sink 单次事务最多取多少条。我配置里的容量看起来很大，但生产环境要谨慎：memory channel 的数据是放在堆内存里的，capacity 设太大，一旦 Source 读进来很多但 Sink 网络堵塞，Channel 里的数据就会堆积，直接把 Flume 的堆内存打满，表现就是 Flume 频繁 Full GC，消息积压越来越严重。经验是 capacity 设置为单日高峰流量的 10% 左右，transactionCapacity 不要超过 capacity 的一半。

Kafka Sink 还有个隐藏参数容易被忽略：flumeBatchSize。这是 Flume 每批次向 Kafka 发送的消息条数，我设了 500。之前用默认配置 100 的时候，遇到突发日志量，Kafka 的生产端明显跟不上，Topic 里的消息积压严重。调大之后 Flume 需要攒够 500 条才发一次，虽然单条延迟变高了，但整体吞吐明显提升。日志类场景本身就不苛求单条毫秒级延迟，吞吐优先是正确方向。

还有一个很容易踩的坑：如果 Flume 配置里 kafka.topic 不存在，KafkaSink 默认会自动创建吗？虽然 Kafka 默认允许自动创建 Topic，但生产环境通常会把auto.create.topics.enable关掉。所以比较稳妥的做法是提前用kafka-topics.sh把 Topic 创建好，指定好分区数和副本数。提前创建也能让该 Topic 的分区分布更均匀，避免自动创建时全部落在同一个节点上。我的分区数设计参考了后续消费者并行度，4 个分区对应单机测试的 4 个消费线程。

调试 Flume 时还有一个实用技巧：加一个 logger sink 来辅助观察数据是否真的被采集到。把 Kafka sink 临时替换成 logger sink，Flume 会在日志里把每条消息内容打印出来。确认数据格式没问题之后，再切回 Kafka。这样能快速区分问题出在 Flume 采集端还是 Kafka 传输端。

4. 消费端落地 HBase：表设计、RowKey 与批量写入

4.1 数据表设计与 RowKey 策略

数据从 Kafka 读出来之后，真正的重头戏开始了：怎么设计 HBase 的表，以及怎么把数据写进去。表设计直接决定了后续查询性能和数据分布，我花在这个环节的时间比配置 Flume 还多。

先说表结构。针对日志类数据，我建的表结构非常简洁：一张表、一个列族、一列数据。因为日志内容本身是半结构化的，用 HBase 的列族动态特性没有必要拆太散。表名app_log，列族cf，每条日志的逻辑存储为：RowKey 是规则拼接的唯一标识，列名data，值就是日志的完整原始内容。如果你需要对日志字段做查询，可以把解析后的结构化字段单独存成多个列，但要注意后续的业务需求——需求没确定前，保留 raw 格式最稳妥，后面加列不需要改表结构，HBase 列族天然支持动态列。

RowKey 的设计是最关键的。HBase 的物理存储是按 RowKey 字典序排列的，如果 RowKey 用客户端 ID 加时间戳，那么同一个客户端的日志会全部落在相邻 Region 上，热点全部集中在一个 RegionServer，其他节点闲着没事干。我这次测试用了最简单的加盐方案：RowKey = 2 位随机前缀 + 时间戳倒序 + 客户端 ID。前缀打散分布，时间戳倒序是为了让同一行的新数据靠前，方便筛选最新日志。简单来说，RowKey 设计要平衡三个诉求：唯一性、查询效率、写入分散。

预分区是表设计里不能跳过的一步。刚开始我直接建表，没有做预分区，结果所有写入全部挤在同一个 Region，虽然测试数据量也不大，但明显能感觉到写延迟不稳定。HBase 单表默认只有一个 Region，Pre-split 需要提前规划好 split 点。以 RowKey 前缀 00 到 99 为例，可以在建表时拆成 10 个 Region，每个扫 10 个前缀区间。这一步是 HBase 性能的关键，如果上线后再改，需要涉及 region split 再平衡，代价比预先规划大得多。

4.2 消费写入代码实现与参数权衡

代码部分我用 Java 写了一个 Kafka 消费程序，核心逻辑很直观：监听 Kafka 的 app-log-topic，拿到每条消息后解析出业务字段，组织成 Put 请求，批量写入 HBase。让我把核心代码展示一下：

// 核心消费循环 try (KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)) { consumer.subscribe(Collections.singletonList("app-log-topic")); Connection hbaseConn = ConnectionFactory.createConnection(hbaseConf); BufferedMutator mutator = hbaseConn.getBufferedMutator(TableName.valueOf("app_log")); while (running) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000)); List<Put> puts = new ArrayList<>(records.count()); for (ConsumerRecord<String, String> record : records) { String[] fields = record.value().split("\\|"); String rowKey = buildRowKey(fields[0], fields[1]); Put put = new Put(Bytes.toBytes(rowKey)); put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("data"), Bytes.toBytes(record.value())); puts.add(put); } mutator.mutate(puts); mutator.flush(); consumer.commitSync(); } }

这段代码背后有三个重要的权衡决定，值得展开说。

第一个是为什么用 BufferedMutator 而不是普通的单条 put。写 HBase 有一个永远存在的性能原则：要批量写。单条 put 会产生大量 RPC，吞吐直接被网络往返打垮。BufferedMutator 在客户端维护缓冲区，攒到一定量或者超过写缓冲区阈值时批量 flush 到服务端。测试里单条写入的吞吐大约是每秒 500 行，BufferedMutator 加 500 批次能到每秒 1.5 万行以上，差距非常明显。

第二个是 Kafka 如何提交 offset。我用了同步 commitSync，消费完一批消息并成功写入 HBase 之后再去提交 offset。这是“至少一次”语义，写入 HBase 成功了，但 offset 提交失败会怎么样？程序重启后消费程序会重复消费这一批消息。重复写入 HBase 的后果取决于 RowKey：如果 RowKey 相同，那后续 put 就是覆盖，结果幂等没问题；如果 RowKey 里有随机值，结果就会出现重复数据。所以实践上最好让 RowKey 能唯一标识同一条日志，从源头避免重复插入。

第三个是生产消费的并发度匹配。Kafka 的分区数决定消费组内的并行度上限。我这里 Topic 有 4 个分区，消费组里可以起 4 个并发线程，每个线程负责一个分区。写 HBase 的缓冲区和线程数也要跟上，否则消费线程很快把数据拉到内存，但 HBase 的写入吞吐却跟不上，会导致内存溢出。测试环境跑 4 个线程时我给每个线程单独建 BufferedMutator，启动时固定写缓冲区大小为 8MB，限制单个客户端可能占用的内存总量，防止堆内存波动。

消费端的错误处理也要提前想清楚。Kafka 的 poll 拉取可能拉到空数据，这是正常的，不要当成异常去打印刷屏。如果写入 HBase 抛异常，比如 RegionServer 正在 split 导致短暂不可用，我的策略是重试三次，超过重试次数就把原始消息记录到本地待补偿表。而不是死循环重试——Kafka 已经可以保证数据不丢，别让客户端变成新的故障点。

5. 端到端联调全流程与数据核验方法

5.1 从启动组件到数据落库的完整操作序列

配置和代码都就绪后，联调变成了流水线式的操作。第一次通链路的人很容易卡在启动顺序上，这里给一套标准顺序，照做不会出问题。

第一步，先启动 ZooKeeper，然后启动 Kafka。不要同时在终端启动多个前台进程，Kafka 切换到后台运行并写日志：bin/kafka-server-start.sh config/server.properties > /data/kafka/logs/server.log 2>&1 &。验证 Kafka 是否正常，我用bin/kafka-topics.sh --bootstrap-server localhost:9092 --list这个命令，能列出 Topic 就说明启动成功。创建 Topic 的命令：kafka-topics.sh --create --topic app-log-topic --partitions 4 --replication-factor 1 --bootstrap-server localhost:9092。

第二步，启动 HBase。bin/start-hbase.sh之后，最好等 10 秒左右让 RegionServer 注册完成。然后bin/hbase shell进入命令行，执行list命令，确认能看到刚创建的表。这一步千万别略过，我第一次就是没确认，结果下游消费程序在尝试连接 HBase 时报错找不到表。

第三步，在测试目录/data/logs/app/下创建一个日志文件，启动 Flume agent。启动命令是bin/flume-ng agent -n agent -c conf -f conf/flume.conf -Dflume.root.logger=INFO,console。日志里能看到 source 和 sink 启动成功的信息。这时候往日志文件里追加几行测试数据，应该在 Kafka 的 Topic 里能立刻看到。启动 Flume 的时机有个讲究：Log 文件不存在时 taildir 也能正常启动，等文件出现后会自动开始读文件头。所以你可以先启动 Flume 再创建日志文件。

第四步，启动消费程序。理论上到这一步数据就会自动流转到 HBase 了。但我建议在启动消费程序之前，先用 Kafka 自带的命令行消费者确认数据格式，再让程序去消费，这样排查效率最高。命令是kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic app-log-topic --from-beginning。

最后打开 HBase shell，执行scan 'app_log', {LIMIT => 10}，能看到数据就说明全链路通了。不要小看最后这个核验步骤，很多人通到一半发现 Kafka 能看到数据就以为万事大吉了，实际上数据根本没写到 HBase，等到想查数据的时候才发现白高兴一场。

5.2 数据核验：从源头到落地的全链路一致性检查

联调通了之后，还要做一个更重要的事：数据有没有丢、有没有重复。我这次用的是“三段对账法”，把完整流程分成三段来校验，每一段都能独立验证它前面的环节是否正常。

第一段是采集端到 Kafka。先在日志文件里写入 N 条固定格式的日志，然后用kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group group1查看消费组的位置。如果这个 Topic 没有消费者，就临时用控制台消费者消费一次，统计消息条数是否等于写入的文件行数。这里最容易暴露的问题是 taildir 正则写错导致没有监控到文件，或者文件没有追加新内容导致 Flume 没感知到。taildir 对日志文件的移动和重命名有严格的行为约束，日志框架切割文件时如果直接重命名当前文件，Flume 可能误判为“新文件出现”，导致整个文件重复消费一遍。

第二段是 Kafka 到 HBase 消费端。这里主要看消费程序有没有重复提交 offset。判断方法是观察 HBase 里的 RowKey 是否重复，或者看消费组里LAG是否为 0。如果 LAG 持续走高，说明消费速度跟不上生产速度。我之前出现过消费端程序逻辑里写了Thread.sleep(10)，单个消费者拉取间隔太短导致 CPU 空转的情况，现象就是数据都堆在 Kafka 拉不过来。调大 poll 的批量参数和减少不必要的同步操作后，LAG 才稳定下降。

第三段是最终落库数据。这个环节最容易忽略的是数据内容对不对。我在消费程序里打印了实际写入 HBase 的 RowKey 和原日志的对比日志，发现有一个字段的时间戳解析逻辑不对，所有行的时间都偏移了 8 个小时。数据管道通了不代表数据是对的，这种业务逻辑错误往往比技术问题更难发现。建议在联调阶段找三条完整的日志，从原始文件开始、到 Kafka 消息、再到 HBase 数据，逐条比对内容，做一次全链路的字段级核对。

我最后还把测试时的数据规模做了一次小压力验证：写入 100 万行日志，观察整个管道的吞吐。实测结果是 Flume 采集约每秒 1.2 万条，Kafka 端到端消费约每秒 8000 到 1 万条，HBase 批量写入也在这个量级附近。瓶颈不在单点性能，而在于我的虚拟机和磁盘 IO。生产环境换 SS 磁盘、多个 agent 并行、消费端扩容，整个链路的吞吐提升空间非常大。

6. 常见故障与排查经验速查

6.1 高频故障现象与处理方法

联调过程中绝对会遇到问题。我整理了一个速查表，覆盖了最容易出现的几类故障现象，每条都标注了排查思路和解决办法：

这些问题里有几个特别值得展开讲讲处理思路。

Flume 启动后没有数据这个现象，我遇到过的最大原因不是配置问题，而是日志文件压根没有新内容追加。taildir 只会监控文件的新增行，老文件的历史内容不会回头去读，所以你如果直接往一个已有 100 行的日志文件里丢新行，没问题；但你要是期待它把历史 100 行也读出来，它是读不了的。测试时不少人会用echo "test" >> app.log的方式追加，这个没问题，确认一下文件是不是真的追加成功了，别用覆盖的方式写。

Kafka 连接超时这个问题，十有八九是监听地址和客户端地址不一致。如果你启动 Kafka 时 listeners 配的是localhost:9092，但 Flume 配置的是服务器的内网 IP，客户端会拿着内网 IP 去对 Kafka 返回的 broker 地址握手，自然连不上。绝招是把advertised.listeners也配成对应的地址，避免 broker 把错误的地址返回给客户端。如果你跨机器测试，这个是必踩的坑。

6.2 排查链路各阶段的定位思路

出了故障之后，快速定位到具体环节比记住故障列表更重要。我总结了一套自己的定位方法，按阶段递进排查：

第一看 Kafka。kafka-consumer-groups --describe是定位整个链路问题的万能钥匙。如果 LAG 一直为 0，说明生产速率和消费速率匹配；如果 LAG 快速上涨，说明消费端是瓶颈。再配合kafka-run-class kafka.tools.GetOffsetShell查看当前偏移量，能判断数据是否真的进入了 Kafka。

第二看 HBase。hbase shell里执行count 'app_log'看总行数，和 Kafka 消费总数做个对比。如果行数远小于 Kafka 消息总数，问题出在消费端写入逻辑或者 RowKey 大量重复导致覆盖。用scan按时间范围扫一下，看数据有没有持续新增。

第三看日志。各组件日志是最后的线索来源。Flume 的日志会打印Sink 写入成功多少条；Kafka 的 server.log 会记录分区变化和异常；HBase 的 RegionServer 日志最容易暴露写阻塞、Region split 等问题。记得把日志级别调到 INFO 以上再测试，WARN 级别容易把关键报错过滤掉。

还有一个终端排查技巧：用jstack查看消费程序当前在干什么。有一次我看到消费端一直不消费，按经验怀疑是 Kafka 消费组重平衡卡住了，用jstack一看，原来卡在 HBase 的ConnectionFactory.createConnection上，连接一直没有建立成功。这种问题不看线程栈很难定位，日志里只会有几行连接超时的告警。

7. 联调之外：Kafka 分区数与 HBase Region 数的搭配建议

通了之后我认真思考了一下这个链路的容量规划问题，这是从“能跑”到“跑得好”的分水岭。Kafka 的分区数和 HBase 的预分区数应该联动规划，而不是各自独立决定。Kafka 的消费并行度上限是分区数，HBase 的写入并行度上限是 Region 数。如果 Kafka 有 16 个分区但 HBase 只有 4 个预分区，那么 16 个消费线程会全部竞争写入那 4 个 Region，热点和写入阻塞无法避免。反过来 HBase 有 32 个 Region 但 Kafka 只有 4 个分区，那大部分 Region 一直闲着，资源浪费。

我这次测试用的比例是 Kafka 4 个分区，HBase 预分区 10 个。这其实不是一个严格的公式，但思路是对的：先根据单条消息大小和预估 TPS 确定 Kafka 分区数，再让 HBase 的预分区数等于或者略多于 Kafka 总分区数乘以单台消费节点的线程数。这样任何一端的扩容都能被另一端接住，不会出现资源错配。

还有一个容易忽略的容量瓶颈是磁盘 IO。这条链路的数据最终流量是双份的：Kafka 写了一份日志，消费端读了一份，HBase 又写了一份。也就是说每来一条日志，磁盘要至少承担三次 IO。SSD 在测试环境已经都快被占满，机械盘跑大数据量场景基本会变成整个管道的最大短板。如果你准备把这个方案用于生产，先给机器配好 SSD 再谈性能，这是硬件层面性价比最高的选择。

关于监控，我个人的建议是不要一开始就上一套完整的监控系统，那会分散精力。先把三个指标盯住：Kafka 消费组的 LAG、HBase 的写请求延迟、Flume 的 Channel 占用率。这三个指标任何一个报警，都能快速定位到瓶颈点。我这次就是靠 LAG 指标发现了消费端线程数设置不合理的问题，及时调整后吞吐直接翻倍。

Kafka 数据保留时间也值得提前规划。虽然我们最终目的是写入 HBase，但 Kafka 作为缓冲层会保留一定时间段的数据，这段时间就是数据重放和修复的窗口。如果你只是为了实时落库，保留 24 小时就够；如果你在链路还没有完全稳定，建议保留 72 小时，给自己留足排查时间。我测试期间就把这个参数改成了三天，某次消费端程序出问题导致丢了一批数据，就是靠 Kafka 里的残留数据补回来的。

最终再分享一个我们测试链路时的经验：改造数据时尽量保持源日志的完整性和全链路统一性。这条链路非常适合先跑起来，然后逐步迭代。Flume 负责采集、Kafka 负责缓冲、HBase 负责存储，每个组件只干一件事，出问题时只需要盯住那一个环节。我这几天的切身体会就是，最难的永远不是技术本身，而是链路跑通之后如何持续监控、快速定位问题，以及在上线前把每一个可能出错的细节都提前演练一遍。踩过一轮坑之后，整个数据通道现在是真的一路畅通了。