做 Flink 压测这些年我最常说的一句话是压测最大的瓶颈从来不是 Source而是 Sink。你想测一个拓扑的真实吞吐上限结果数据全写进 Kafka、HDFS、MySQL下游集群先扛不住了指标全被污染最后只能把数据删掉重来。后来 Flink SQL 引入了一个名字特别形象的内置连接器——BlackHole Sink它就是流处理界的/dev/null不管你喂多少条数据进去它都照单全收然后无声无息地吞掉不落盘、不转发、不做任何额外计算。这篇文章就围绕 BlackHole Connector 展开说一说它为什么会成为压测与验证阶段的神器怎么用才能测出接近真实的结果以及我实际踩过的几个坑。1. 压测场景下的“数据出口”困境为什么非它不可1.1 真实的 Sink 会毁掉一次压测实验先说一个很典型的场景。你写了一个 Flink SQL 作业Source 是从 Kafka 消费用户行为日志中间做了一些维度关联和窗口聚合最后要写入 ClickHouse 或者 HDFS。压测的时候最自然的做法是把作业原封不动跑起来然后把 Kafka 的 Topic 灌满数据看端到端吞吐能到多少。结果是什么呢数据真的进了 ClickHouse 和 HDFS下游的存储压力先爆了。ClickHouse 写入变慢开始反压HDFS 小文件激增甚至把生产环境的磁盘搞满。你本意是测 Flink 作业的处理上限最后却测出了一堆外部系统的瓶颈。这种数据一旦写进去清理也是一件痛苦事。BlackHole 解决的就是这个“出口”问题。它在逻辑上是一个完整的 Sink可以从 Flink 的拓扑中正常接收数据完成所有的序列化、分区、算子链上的数据流动但到了 Sink 这一层之后每条记录都被直接丢弃。这个行为和 Linux 下的/dev/null完全一致写入永远成功永远不需要读出来。1.2 你真正想验证的只有三条链路抛开那些复杂的监控指标不谈压测一个 Flink 作业本质上只关心三件事吞吐上限在哪里、反压发生在哪一级、状态和 Checkpoint 是否稳定。这三件事都发生在 Source 到 Sink 之间的算子里跟 Sink 后面接的是什么系统其实没有直接关系。比如你想知道窗口聚合的性能数据从 Kafka 进来经过 keyBy、窗口计算、输出这个过程的 CPU 消耗和序列化开销才是关键。BlackHole 把最后的输出丢弃掉恰好把外部存储的变量从实验里剔除出去剩下的就是纯 Flink 引擎的真实表现。所以当有人问我“压测时能不能不写 Sink”的时候我的回答是不行。Flink SQL 编译出的作业图必须是一个有进有出的 DAG如果没有 Sink作业根本起不来。BlackHole 就是那个让你“有出口但不产生副作用”的完美占位符。1.3 “/dev/null”思想从操作系统到流处理接触过 Linux 的同学都知道/dev/null是一个特殊的设备文件写入它的任何数据都会被系统丢弃而且写入速度极快。流处理里的 BlackHole Connector 几乎复刻了同样的设计哲学接口完整行为为空。这个思想在分布式系统里特别重要。你在做全链路压测的时候环境往往是隔离的不能污染真实数据。但如果整个链路少了最后一段又无法完整评估作业图的行为。BlackHole 提供了一种“结构性真实、行为性虚拟”的中间态让压测环境既保留了完整的作业拓扑又不会对下游系统产生任何影响。2. BlackHole Sink 的设计逻辑与执行真相2.1 DDL 背后的实现一个“空操作”的 RichSinkFunctionFlink 从 1.13 版本开始提供 BlackHole SQL Connector在源码里对应的实现类路径是org.apache.flink.connector.blackhole.table.BlackHoleTableSink。对于有自定义 Sink 经验的同学看这个实现会觉得很亲切它本质上就是一个继承RichSinkFunction的 Sink 算子。我直接说 Key 部分BlackHoleSinkFunction#invoke()方法里对收到的每条数据什么都没做直接返回。没有网络请求没有状态更新没有序列化到字节数组更没有事务提交。从 Flink 引擎的视角看这个算子依然参与了整条数据处理链路但从实际效果看它就是一条透明的“下水道”。这里有个容易被忽略的点invoke()什么都不做不代表这条链路没有开销。数据从上游算子传输过来依然要走序列化、反序列化、网络缓冲、算子之间传递这些机制。所以 BlackHole 压测的结果体现的是“数据处理引擎的真实上限”而不是“Sink 有多快”。2.2 为何它对背压指标的反馈如此敏感Flink 的背压机制是逐级传导的。当下游处理不过来就会通过缓冲区水位向上游传递压力。真实场景里Kafka 生产者、HDFS IO、数据库连接池都可能是背压的源头这些外部因素会掩盖 Flink 作业本身的问题。换成 BlackHole 之后Sink 这一侧永远不会成为背压制造者。那么背压指标一旦出现就可以非常明确地判断背压来自作业内部——可能是 keyBy 产生了数据倾斜可能是某个 UDF 计算量过大可能是 RocksDB 状态后端的读写太慢。我做过一个实验同一个窗口聚合作业分别接 Kafka Sink 和 BlackHole Sink全部放开并发度去跑。Kafka Sink 版本在 50 万条每秒就开始出现背压橙色预警BlackHole Sink 版本到 120 万条每秒背压依然全绿。这 70 万条每秒的差距就是 Kafka 生产端和分区写入带来的真实开销。用 BlackHole 压测你可以把这个变量摘出去单独优化作业内部逻辑。2.3 并发度、序列化与吞吐的隐藏关联很多人以为 Sink 是空操作并行度设多少都一样。其实不然。BlackHole 算子的并行度如果设得太低反而可能成为整个拓扑的理论瓶颈因为它要承接所有上游输出。更值得关注的是序列化行为。BlackHole 虽然不主动序列化数据但 Flink 内部的网络传输层会做二进制序列化。如果你在 DDL 里定义了一大堆 VARCHAR、ARRAY、ROW 类型的字段即便数据被 Sink 丢弃序列化和网络传输的 CPU 开销依然存在。压测的时候DDL 字段越接近真实生产结构结果越有参考价值。千万别为了省事只定义一个字段那样测出来的数据和真实场景差得很远。3. 十分钟上手DDL 与双 Sink 压测配置3.1 最小可用的 BlackHole DDL如果你的 Flink 版本支持 SQL Connector直接在 SQL 客户端或者 Flink SQL 作业里执行这一段就行CREATE TABLE blackhole_sink ( user_id BIGINT, event_time TIMESTAMP(3), behavior STRING ) WITH ( connector blackhole );这里有个典型的WITH参数只写connector就足够了。不需要配置format、不需要配置地址或者认证信息。你定义的字段结构实际上只用于 Flink 的类型系统传递不会真正做格式解析和映射。完成后把 Source 表和这张表一起用INSERT INTO blackhole_sink SELECT user_id, event_time, behavior FROM source_table;作业一旦启动你就可以安心观察 Metrics 面板上的吞吐曲线了。3.2 一份数据双 Sink用 STATEMENT SET 搭压测骨架压测时我经常遇到另一个需求同一份数据既要丢到 BlackHole 跑纯引擎性能又要写一份到真实系统看端到端效果。Flink SQL 的STATEMENT SET可以非常优雅地同时提交多个 INSERTBEGIN STATEMENT SET; INSERT INTO blackhole_sink SELECT user_id, event_time, behavior FROM source_table; INSERT INTO real_sink SELECT user_id, event_time, behavior FROM source_table; END;这个写法会在同一张作业图中创建一个分支一条边流向 BlackHole一条边流向真实 Sink。压测的时候可以先让 BlackHole 分支先跑稳再去观察真实 Sink 分支是否成为瓶颈。这也是一种比较常见的“影子流量”压测方案源数据只有一份但出口有虚拟和真实两条。不过要注意如果两个分支共享了很多上游计算比如同一个 JOIN、同一个窗口聚合Flink 会把公共部分合并计算一次不会重复执行这正符合我们对性能测试的预期。3.3 配合限流 Source 做阶梯压测BlackHole 只能处理 Sink 侧Source 侧需要自己控制输入速率。常见的做法是用 Kafka Source 的scan.startup.mode和消息量来控制但更精细的控制建议结合 Flink SQL 的 Source 限流能力。一个简单的策略是准备一个测试 Topic用脚本持续生产数据然后在作业里逐步放开 Source 并行度。每调整一次观察三个指标端到端吞吐、背压百分比、Checkpoint 时长。BlackHole Sink 保证了出口不会干扰实验变量所以你看到的每一个变化都来自 Source 或者中间算子。如果手头没有专门的压测工具也可以用 Flink 自带的 DataGen Connector 生成数据它同样可以配合 BlackHole 做一张无状态的单作业压测图CREATE TABLE datagen_source ( id BIGINT, name STRING ) WITH ( connector datagen, rows-per-second 100000, fields.id.kind sequence, fields.id.start 1, fields.id.end 100000000 );DataGen 加 BlackHole是我见过最干净的 Flink SQL 压测组合没有外部依赖纯本地计算链路。4. 别只盯着 BlackHolePrint、自定义 Sink 与选型对比4.1 Print Sink 更适合调试不适合压测有些同学会问Flink 不是已经有 Print Sink 了吗它也会把数据打出来但不落存储能不能用来压测我的回答是Print Sink 是调试工具不是压测工具。Print Sink 会把每条记录以字符串形式序列化后输出到 TaskManager 日志或者标准输出这个toString 操作本身就有很大的 CPU 开销而且会疯狂刷日志。流量一大日志系统先被打满磁盘 IO 也跟着涨。它更适合小数据量下确认拓扑逻辑和字段值而不是做性能实验。4.2 带采样的自定义 Sink 与校验型 Sink压测到后期很多人会希望“丢数据的同时还能留点证据”。BlackHole 不提供任何回调机制这时候就需要写一个轻量级自定义 Sink。我常用的一个思路是在 Sink 里对数据做哈希每 10000 条取一条写入本地文件或者打一条计数日志其余全部丢弃。这样可以确认数据确实经过了 Sink 算子而不是因为 SQL 写错导致没有数据到达。如果只是想验证作业链路通不通还可以在 Sink 里维护一个计数器定期输出“已处理 X 条”的日志。这种自定义 Sink 的代价很低通常不会有外部 IO 的瓶颈比 Print Sink 干净得多。如果你对 Flink 的 Sink 接口不熟可以基于RichSinkFunction重写invoke()里面只保留采样逻辑。4.3 Sink 选型决策表我把常见的“假 Sink”放到一起对比方便你做技术选型。实测下来不同场景适合的工具并不一样。场景推荐 Sink原因单作业引擎压测BlackHole零副作用、无外部依赖、吞吐最高SQL 拓扑逻辑验证Print能直接看到字段内容但只适合小流量抽样留证自定义采样 Sink丢弃大头保留小部分做验证全链路影子流量压测BlackHole 真实 Sink 双跑用 STATEMENT SET 分流隔离变量生产集群压测演练BlackHole 替换真实存储避免污染生产数据压完直接下线5. 我踩过的坑BlackHole 不是万能的5.1 坑一字段校验失效SQL 语义错误被掩盖这是我最想提醒的一点BlackHole 不会校验数据的真实内容所以 DDL 写错了也不会报错。真实 Sink 往往会校验字段约束、格式、类型BlackHole 什么都不校验因为它根本不解码数据。我有一次做压测Source 里有一个TIMESTAMP(3)字段DDL 写成了TIMESTAMP_LTZ(3)如果是写入真实 Sink 可能早就暴露了类型不一致问题但因为 Sink 是 BlackHole作业跑得非常顺畅。最后切回真实 Sink 时才发现类型映射不对白白浪费了一轮压测时间。所以在压测之前建议先让作业经过一次真实 Sink 的小流量验证确认 SQL 语义和字段映射没问题再切换到 BlackHole 进行大规模压测。5.2 坑二压测结果“漂亮”不代表生产也漂亮BlackHole 的零副作用特征是一把双刃剑。它让你看到了 Flink 引擎的物理上限但生产环境不可能真的接一个 BlackHole。真实链路里Kafka 生产端需要有 ACK 机制HDFS 有文件滚动和副本复制ClickHouse 有批量写入窗口。这些开销都会真实地反映在端到端延迟上。我建议把黑盒压测结果当作“理论天花板”而不是目标值。比如 BlackHole 测出 120 万条每秒接上真实 Kafka Sink 后打七折到 85 万条每秒这是很健康的表现如果黑盒压测只能跑 40 万条每秒那作业内部一定有大问题跟 Sink 没关系需要回去查 keyBy 和状态设计。5.3 坑三检查点恢复后丢数据是设计使然BlackHole Sink 不会保存任何自有状态也不会向 Flink 报告它已经处理到了哪一条数据。作业根据 Checkpoint 恢复后BlackHole 这一侧不会回滚或重放因为对于它来说恢复了就等于从 Source 位点继续往下读。这个特性通常是合理的但如果你在验证“端到端精确一次”语义BlackHole 不是一个合格的目标系统。它无法提供任何输出凭据你只能通过 Source 的位点变化和 Checkpoint 完成情况来判断链路健康不能验证真正的投递结果。要验证精确一次还是需要接一个可以做事务或者幂等写入的系统。5.4 坑四在 Flink CDC Pipeline 里做验证要小心的点很多人现在会用 Flink CDC Pipeline 做数据同步先采集 MySQL 数据再通过 Pipeline 写入下游。调试 Pipeline 的时候有人会把 Sink 换成 BlackHole这种做法本身没问题但 CDC 场景有个特殊注意点Schema 变更。真实 CDC Sink 通常会处理新增列、删除列、DDL 变更等事件有些 Sink 还有 Schema Evolution 能力。BlackHole 没有这个逻辑它拿到什么就丢什么。所以在 CDC Pipeline 里用 BlackHole 只能验证数据采集链路是否拉通、增量是否在推进无法验证 DDL 变更处理逻辑是否正确。这一点一定要结合自定义的校验 Sink 来补齐。6. 一套可落地的 BlackHole 端到端压测方案6.1 完整作业 DDL 示例下面给出一个完整的压测作业骨架你只需要替换掉真实的 Source DDL 即可CREATE TABLE source_kafka ( user_id BIGINT, item_id BIGINT, category_id BIGINT, behavior STRING, ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL 3 SECOND ) WITH ( connector kafka, topic test_behavior, properties.bootstrap.servers localhost:9092, properties.group.id stress_test_group, scan.startup.mode earliest-offset, format json ); CREATE TABLE blackhole_sink ( user_id BIGINT, item_id BIGINT, category_id BIGINT, behavior STRING, ts TIMESTAMP(3) ) WITH ( connector blackhole ); CREATE TABLE sampled_sink ( user_id BIGINT, behavior STRING, cnt BIGINT ) WITH ( connector print ); INSERT INTO blackhole_sink SELECT user_id, item_id, category_id, behavior, ts FROM source_kafka; INSERT INTO sampled_sink SELECT user_id, behavior, COUNT(*) FROM source_kafka GROUP BY user_id, behavior HAVING COUNT(*) % 10000 0;这段 SQL 的思路是主体数据全部走向 BlackHole不产生存储副作用同时用一个聚合抽样每满 10000 条输出一次到 Print用来确认链路是活的。6.2 如何通过指标定位瓶颈作业跑起来之后不要只盯着吞吐数字。我建议在 Flink Web UI 或者监控系统里固定看四个指标背压状态如果 Source 和中间算子全部以下游被反压标红先把 Sink 并行度调大排除传输层问题。Checkpoint 时长和失败率状态大的作业Checkpoint 时间会随吞吐上升而显著变长这是压测中很常见的隐藏瓶颈。CPU 使用率如果 TaskManager 的 CPU 已经跑满说明瓶颈在计算逻辑或者序列化而不是吞吐配置。GC 情况黑盒 Sink 不会产生外部 IO如果 Full GC 频繁很可能是内存配置或者 RocksDB 状态访问过大。压测结束后建议把每一轮结果记录到表格里对比不同并行度、不同限速下的表现而不是只看最终一个峰值数字。6.3 抽样保留与双跑校验的建议最后聊一点实战经验。全链路压测时我最常用的三板斧是主力数据进 BlackHole千分之一数据进真实 Sink再配合一个计数型自定义 Sink 做完整性核对。这样做的价值在于既能跑出引擎的极限吞吐又能顺带验证“如果接真实系统这条链路是否能正常工作”。真实 Sink 那一路流量虽然很小但足以暴露字段映射、主键冲突、序列化格式等隐患。如果你有资源做更完整的影子压测还可以把真实 Sink 指向一个压测专用的测试库用 STATEMENT SET 把 99% 流量给 BlackHole1% 给测试库。这样可以观察少量真实写入对下游系统的延迟影响又不会把测试库写爆。BlackHole 不是黑魔法它不会让你的作业变快也不会帮你发现所有问题它是把“外部因素”从压测实验里剔除出去的隔离工具。压测之前想清楚要验证什么压测之后带着怀疑去审视结果这个工具才能真正发挥价值。