企业官网建设流程全解析

Redpanda Connect 连接器性能基准测试摘要：CDC 与集群迁移吞吐量全景解读

【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect

本文基于 docs/benchmark-results/SUMMARY.md 及其配套的逐连接器结果文件，系统梳理 Redpanda Connect 在 Redpanda Migrator、DynamoDB CDC、SQL Server CDC、Oracle CDC 等核心连接器上的实测吞吐数据，并结合 docs/benchmarking.md 与各基准套件源码，说明这些数字是在什么条件下测得的、如何复现，以及如何将其正确用于容量规划与性能评估。读完本文，你将能够读懂 Redpanda Connect 的基准测试报告，理解"读吞吐"与"写吞吐"的边界，并掌握用内置benchmark处理器自行验证连接器性能的完整方法。

一、性能总览：一张表看懂五个核心场景

SUMMARY.md把当前仓库所有已归档的基准结果浓缩为一张速览表。这张表统计的是各连接器在本地 Docker 环境、开发级硬件上的峰值读吞吐：

几点阅读要领：

• 峰值吞吐：表中为各场景记录到的最优滚动统计值（rolling stats）而非全程均值；
• 消息速率：以每秒处理的消息条数为单位，与吞吐字节数共同刻画性能；
• 未标注项（—）：Oracle CDC 快照与流式场景在原始记录中只汇报了 msg/sec，未单独给出 MB/sec 数据，因此表中留空，而非数据缺失或异常。

二、逐场景解读：数字背后的含义与瓶颈

2.1 Redpanda Migrator：1 GB/s 的集群间迁移

Redpanda Migrator 是专门用于在 Redpanda 集群之间搬运数据的连接器，基准显示它能在 1 GB/s 以上的速率移动数据，30GB 的迁移任务约 30 秒即可完成（约 103.5 万 msg/sec）。这一结果来自 internal/impl/redpanda/migrator/bench/ 基准套件：源与目标 Redpanda 各分配 1 CPU/2.5GB 内存，Loader 2 CPU、Migrator 3 CPU，topic 40 分区（启用写缓存，flush.ms=1000），数据集为 30GB（3000 万条约 1KB 的未压缩消息）。

其关键调优参数在 migrator.yaml 中可以直接看到：

input: redpanda_migrator: seed_brokers: - src:9092 topics: - test-topic regexp_topics: true start_from_oldest: true consumer_group: migrator_cg partition_buffer_bytes: 2MB max_yield_batch_bytes: 1MB output: redpanda_migrator: seed_brokers: - dst:9092 consumer_groups: enabled: false max_in_flight: 40

其中partition_buffer_bytes: 2MB控制每个分区在内存中缓冲的数据量上限，max_yield_batch_bytes: 1MB限制单次交付给下游的批次大小，max_in_flight: 40决定并行在途的输出请求数。运行时的滚动统计直接印证了表内数值：

[output.processors.0] msg="rolling stats: 1035873 msg/sec, 1.0 GB/sec" [output.processors.0] msg="rolling stats: 1035211.5 msg/sec, 1.0 GB/sec" [output.processors.0] msg="rolling stats: 1037427.5 msg/sec, 1.0 GB/sec"

2.2 DynamoDB CDC：216 MB/s 的多表变更捕获

DynamoDB CDC 场景在 3 张表（users / products / orders，各 15 万条约 1KB 条目）上测得约 200–216 MB/s、9.5 万–10.2 万 msg/sec。基准使用 DynamoDB Local（内存模式）在 Docker 中运行，每张表仅有一个 shard——连接器能完全榨干每个 shard，一旦记录消费完毕吞吐即归零，直到有新写入到来。

一个重要的生产推论：真实 AWS DynamoDB 的 Streams 会按多 shard 横向扩展，因此生产环境吞吐有望高于本地数字。其实际配置见 benchmark_config.yaml：

input: aws_dynamodb_cdc: tables: - bench-users - bench-products - bench-orders table_discovery_mode: includelist checkpoint_table: bench-checkpoints endpoint: http://localhost:8000 region: us-east-1 batch_size: 1000 output: processors: - benchmark: interval: 1s count_bytes: true drop: {}

注意这里的endpoint指向本地 8000 端口，checkpoint_table用于记录消费位点，batch_size: 1000是吞吐调优的关键旋钮。另外，DynamoDB Streams 的记录只保留 24 小时——基准文档特别提醒：播种数据后要尽快跑测试，否则会看到"0 msg/sec"的空跑结果。

2.3 SQL Server CDC：154 MB/s 与"单连接瓶颈"的发现

SQL Server CDC 在单表流式读取下达到约 140–154 MB/s、10.5 万–11.9 万 msg/sec（峰值 154 MB/s）。这个结果本身就是一次教科书式的瓶颈定位：基准记录显示 SQL Server 当时烧掉了 4 核中的 1 核（106% CPU），而连接池中配置的 100 条连接只有 1 条在用（sql.DBStats{OpenConnections:1, InUse:1}）——瓶颈是 SQL Server 单连接的 CDC 读取速度，而非 Redpanda Connect 本身。

这带来一个可操作结论：吞吐随被捕获的表数量近似线性扩展，因为每张表使用独立的数据库连接。实测 2 张表并行时总吞吐翻倍到约 2×（SQL Server CPU 升到 136%），理论上有 4 倍提升空间。作者还用sql_raw输入直接读表以排除 CDC 组件的影响，无论怎样提高 Connect 可用核数、改用 Linux VM 直连、或试多种 Azure SQL 规格，都无法突破约 139 MB/s——进一步坐实了"源端限制"而非"连接器限制"。

2.4 Oracle CDC：快照 140K vs 流式 50–90K 的双模式差异

Oracle CDC 是典型的"两个模式、两种性格"：

• 快照模式：全表批量读取，约 140,000 msg/sec。它受益于更高的读并发，本质是一次大SELECT，因此行为与其它 SQL 系连接器类似，通常比流式更快；
• 流式模式：基于 Oracle LogMiner 的实时变更捕获，平均约 50,000 msg/sec（全程均值 25,000），峰值 70,000–90,000 msg/sec。

流式吞吐受限于 LogMiner 自身的机制——它不是为 CDC 设计的：需要把事务缓冲到COMMIT/ROLLBACK之后才能刷出、redo log 的 SCN 之间存在大间隔、且本质上是单线程。基准文档明确指出这是协议级限制，并给出证据：移除缓冲层仅带来轻微改善，而同为 LogMiner 方案的 Debezium Oracle CDC 在同一负载下数字相近。换言之，50–90K 是 Oracle 生态的天花板，不是 Redpanda Connect 的短板。

该场景使用的调优参数（见 oracledb-cdc.md）：

• snapshot_max_batch_size: 160000
• logminer.scn_window_size: 190000
• batching.count: 140000

三、测试条件与数字边界：先弄清测的是什么

3.1 环境前提

所有归档基准都在开发者笔记本上运行，源数据库以 Docker 容器方式启动（生产部署在专用硬件 + 合理规格数据库上通常会更好）。Migrator 与 SQL Server 场景还使用了 CPU 固定（cpuset）与内存上限，以保证跨运行的条件一致。

3.2 读吞吐 vs 写吞吐

这是最容易误读的一点：这些数字代表读吞吐（ingest）——即 Redpanda Connect 从各源系统摄取数据的速度。基准配置中输出一律使用drop: {}丢弃消息，正是为了把目标端开销剥离，只测输入侧能力。写入目标系统的吞吐取决于目标本身，需要单独基准化（例如 aws-s3.md 中 S3 写入、postgres.md 与 mysql-cdc.md 中 Kafka→DB 写入均有独立结果）。

四、如何复现：基准测试的标准流程

SUMMARY.md指向的完整流程在 docs/benchmarking.md 中。其标准范式是"一个task命令跑完整个套件"，通用步骤为：

1. 在 Docker 中拉起外部依赖（数据库、消息中间件等），优先使用与生产一致的真实镜像，避免"lite/local"变体（DynamoDB Local 属于唯一可选场景，需在 README 中记录该限制）；
2. 生成真实感数据集——多张不同 schema 的表（如 users/products/orders）比单张巨表更接近生产，典型行大小 1–2KB；
3. 运行带benchmark处理器的 Redpanda Connect 流水线，统计吞吐；
4. 在 PR 描述中记录结果（msg/sec 与 MB/sec）。

复现性控制要点：通过cpuset做 CPU 固定避免调度噪声、用mem_limit防止 OOM、对 Connect 容器设置GOMAXPROCS/GOMEMLIMIT控制调度与 GC。可参考 migrator 的 docker-compose.yml：

migrator: environment: GOMAXPROCS: "3" GOMEMLIMIT: "3GiB" cpuset: "5,6,7" mem_limit: 3500M

数据生成有三种方式：SQL 脚本（存储过程循环批量插入）、Go seeder 程序（如 DynamoDB 基准的 main.go，16 个并发 worker 插入 45 万条）、以及纯消息吞吐场景下的 Bloblanggenerate输入：

input: generate: interval: "" # 尽可能快 count: 30_000_000 batch_size: 1_000 mapping: | root = "<your payload here>"

4.1 基准流水线的最小配置

benchmark处理器是整套方法的核心——它按固定间隔打印滚动吞吐统计。最小可复现配置如下（来自 docs/benchmarking.md）：

http: debug_endpoints: true # 暴露 pprof 用于剖析 input: <your_connector>: batching: count: 1000 # 按连接器调优批量大小 output: processors: - benchmark: interval: 1s # 统计日志间隔 count_bytes: true # 同时报告 MB/sec drop: {} # 丢弃输出，只测读吞吐 logger: level: INFO metrics: prometheus: add_process_metrics: true add_go_metrics: true

要点解读：

• http.debug_endpoints: true在localhost:4195暴露 pprof，用于 CPU/内存/阻塞剖析；
• drop: {}消除输出开销，确保测量的是输入吞吐；
• Prometheus 指标（进程与 Go 运行时）供 Grafana 监控，相关监控栈位于resources/docker/profiling/。

批量大小（batching.count）是影响最大的旋钮，且随连接器差异巨大：现有基准从 1,000（SQL Server、DynamoDB）到 140,000（Oracle CDC）不等。太小则单批开销占比过高，太大则内存压力与延迟尖峰并存，需要逐个场景实测。此外，在 Apple Silicon 上务必使用redpandadata/connect:edge-arm64这类正确架构的镜像——x86 镜像经 Rosetta/QEMU 模拟会大幅拉低数字，产生误导。

手动分步执行的方式：

# 启动服务 → 建表 → 播种数据 task service:up task create task seed # 运行基准 go run ../../../../cmd/redpanda-connect/main.go run ./benchmark_config.yaml

运行期间应能看到类似输出（与 SUMMARY 表中的数字同源）：

INFO rolling stats: 101000 msg/sec, 135 MB/sec @service=redpanda-connect ... INFO rolling stats: 104000 msg/sec, 139 MB/sec @service=redpanda-connect ...

4.2 快照模式与流式模式必须分开测

对 CDC 连接器，benchmarking.md要求两种模式分别基准化：快照模式（全量读现状，并发高、吞吐高，如 Oracle 快照 140K vs 流式 50K）确立理论上限；流式模式（从日志/流读取变更，通常每表单线程、受源系统变更捕获机制约束）才是生产真正体验到的速率。报告时应两者都给——快照定上限，流式定体验。

4.3 数据保留窗口是常见坑

部分源系统的变更数据有保留期，处理不当会直接得到"0 msg/sec"：

• DynamoDB Streams：仅保留 24 小时，需及时播种并及时运行；
• Oracle LogMiner：SCN 窗口与 redo log 保留策略相关，需按rman_setup.rman配置归档日志策略；
• SQL Server CDC：清理作业可能清除变更表，基准期间应禁用或延长保留期。

同时，多数 CDC 连接器维护检查点/游标，两次运行之间需要清理（如删除 checkpoint 表），套件中通常有drop-checkpoint任务。

五、仓库中的基准套件地图与结果归档

每个需要基准化的连接器都在其实现包内维护自包含的bench/目录，典型结构为：

internal/impl/<component>/bench/ ├── README.md # 运行方式、前置条件、预期输出 ├── Taskfile.yaml # 任务编排 ├── benchmark_config.yaml # Redpanda Connect 流水线配置 ├── docker-compose.yml # （可选）多服务编排 ├── create.sql # （可选）建表脚本 ├── users.sql # （可选）数据生成脚本 └── main.go # （可选）程序化数据播种

已归档结果与套件对应关系如下：

另有 MySQL、PostgreSQL、S3 等场景的独立结果（mysql-cdc.md、postgres.md、aws-s3.md），其中 MySQL 快照读取峰值约 19.1 万 msg/sec，且含与 Debezium、Kafka Connect JDBC Sink 的对比数据。每个结果文件按日期追加新运行段，以便追踪性能随时间的变化。

六、AWS 实网基准与结果自动生成

SUMMARY.md中还包含一段由注释标记的自动生成区（bench:aws:start/bench:aws:end），用于承载针对真实 AWS 端点、专用基础设施的第二阶段基准，包括带 CloudWatch 告警的持续浸泡（soak）测试与滚动回归基线。截至本文所依据的版本，该区域显示 "no AWS runs yet"，即尚无已归档的 AWS 实网运行。

这段内容无需手工维护：运行task aws:summary即可在不重新执行基准的情况下，从各场景的最新运行产物（原始样本与 Prometheus 快照位于results/<connector>/<scenario>/）重新生成摘要表。完整机制见 benchmarking/aws/README.md（runner、场景、task aws:bench一键扫测与成本控制）与 benchmarking/aws/SOAK.md（夜间与 PR 对比 soak、告警、如何新增场景）。

七、结语：如何正确使用这些数字

• 横向比较要限定同一条件：本摘要的数字均为本地 Docker + 开发硬件的读吞吐上限，与生产环境（专用硬件、多 shard、多分区）存在合理差距，规划容量时应为写路径与目标端预留余量；
• 区分"连接器快"与"协议慢"：SQL Server 单连接读取、Oracle LogMiner 单线程是源端协议特性，与实现无关；多表并行是 SQL Server CDC 扩容的有效手段；
• 用同一套方法自行验证：借助benchmark处理器与drop: {}输出，任何连接器都能在几分钟内得到可信的读吞吐基线；批量大小与 GOMAXPROCS 是需要重点扫描的两个变量（PostgreSQL 基准显示 batch=5000 常在多数核数下最优，而 Oracle 需要大得多的 batch）；
• 结果是活文档：新增或修改连接器热路径（批处理、缓冲、连接管理、序列化）后应重跑基准并追加日期化记录，防止性能回退。

如需深入了解方法论、剖析工具与报告规范，可继续阅读 docs/benchmarking.md；逐连接器的完整环境、原始输出与瓶颈分析见 docs/benchmark-results/ 目录下的对应文件。

【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect