1. 架构演进：从一体化到采传分离
1.1 历史架构：一体化的管道任务
在早期架构中，实时管道任务是一个完全独立的、端到端的单元。每个实时管道任务都内置了完整的 E-T-L（抽取-转换-加载）能力。这意味着，每创建一个实时管道任务，系统就会启动一个独立的进程，该进程会直接连接到源端数据库，执行日志读取（如 Oracle Logminer、MySQL Binlog）或 CDC 表查询操作。
这种模式的弊端在高并发、多任务场景下尤为突出：
源端压力巨大：如果有 10 个管道任务需要从同一个 Oracle 数据库同步数据，就会建立 10 个独立的 Logminer 连接。这会急剧增加源端数据库的 CPU 和 I/O 负担，甚至影响核心业务的稳定性。
资源浪费严重：每个管道任务都在重复地执行相同的“日志读取”和“数据解析”工作，造成了计算和网络资源的极大浪费。
扩展性受限：每增加一个管道任务，对源端的压力就增加一分，使得整个数据同步系统的横向扩展能力受到源端数据库性能的严重制约。
1.2 全新架构：采集任务与管道任务的分离
新架构引入了「实时数据共享中心」的概念，其核心思想就是“采传分离”（采集与传输分离）。我们将数据读取（采集）的能力从实时管道任务中剥离出来，形成一个独立的、可共享的单元——采集任务。
采集任务 (Collection Task)
职责：连接到一个特定的数据源（例如一个数据库实例），并持续不断地捕获其数据变更事件（增、删、改）。它就像一个部署在源端的数据探针。
特性：一个采集任务对应一个数据源。它是一个可被多个下游任务复用的共享资源。
管道任务 (Pipeline Task)
职责：职责转变为专注于数据的消费、转换与加载。它不再直连源端数据库进行日志解析，而是从一个或多个已经配置好的“采集任务”那里订阅并获取数据。
特性：管道任务现在是纯粹的数据消费者和处理者。
2. 示例
在新的架构下，实时管道任务和采集任务形成了一种典型的「生产者-消费者」模型。
生产者（采集任务）：采集任务连接到源数据库，捕获所有配置表的变更数据，并将这些数据标准化后推送到一个内部的高速消息队列（如 Kafka）中。
消费者（实时管道任务）：一个或多个管道任务可以订阅该消息队列。每个管道任务根据自身的配置，只从队列中拉取自己感兴趣的表的数据进行后续处理。
假设：
存在一个名为 ORA_DB_01 的 Oracle 数据源。
实时管道任务 A：需要同步 ORA_DB_01 的 ORDERS 表和 CUSTOMERS 表。
实时管道任务 B：需要同步 ORA_DB_01 的 CUSTOMERS 表和 PAYMENTS 表。
实时管道任务 C：需要同步 ORA_DB_01 的 PRODUCTS 表。
运行逻辑如下：
1）创建共享的采集任务：
系统会创建一个名为 采集任务_FOR_ORA_DB_01 的采集任务。
该采集任务会连接到 ORA_DB_01。
它会被配置为捕获这三个实时管道任务所需的所有表的并集，即 ORDERS, CUSTOMERS, PAYMENTS, PRODUCTS 四张表的变更数据。
2）单一数据捕获：
采集任务只启动一个 Logminer 进程，从数据库的 Redo Log 中一次性读取上述四张表的所有数据变更，并将其发送到内部消息队列。
3）管道按需消费：
实时管道任务 A 从消息队列中只订阅和过滤 ORDERS 和 CUSTOMERS 表的数据。
实时管道任务 B 从消息队列中只订阅和过滤 CUSTOMERS 和 PAYMENTS 表的数据。
实时管道任务 C 从消息队列中只订阅和过滤 PRODUCTS 表的数据。
通过这种方式，无论有多少个实时管道任务，只要它们源于同一个数据库，对该数据库的日志读取操作就永远只有一次。
3. 采集任务价值
1）极大降低源端数据库压力
对单一数据源的读取操作从 N 次（N 为实时管道任务数量）减少到 1 次。这从根本上解决了因数据同步任务过多而导致源端业务库不堪重负的问题，保障了核心业务的稳定性。
2）复用采集资源
计算密集型的日志解析、数据标准化等工作由共享的采集任务统一完成。新增的实时管道任务可以直接利用已有的采集成果，无需重复建设，极大地节省了服务器的 CPU 和内存资源。
3）提升整体扩展性
由于新增实时管道任务对源端的压力几乎为零，数据同步系统的横向扩展能力不再受限于源端数据库。企业可以根据业务需求，放心地创建更多的实时管道任务，以支持更多的数据应用场景，而无需担心拖垮源库。
4. 内容扩展
4.1 注意事项
1）共享的采集任务是多个实时管道/实时任务的「生命线」，其健康状态至关重要。应将其作为核心组件进行重点监控。
2）由于采集任务是共享资源，对其的修改（如增删采集的表）会影响所有关联的实时管道/实时任务。应谨慎控制其配置权限。
4.2 常见误区
误区一：增加实时管道任务一定会增加数据库负载。
正解：在采传分离架构下，如果新增的管道任务复用了已有的采集任务，那么它对源端数据库的增量负载几乎为零。主要的资源消耗体现在 FDL 平台侧的计算和网络上。
误区二：删除实时管道任务后，对应的数据库连接就会断开。
正解：如果该管道关联的采集任务还在为其他管道服务，那么这个采集任务及其数据库连接会继续保持活跃，不会因为单个管道的删除而中断。
4.3 FAQ
Q1: 我如何知道我的几个管道任务是不是共享了同一个采集任务
您可以通过以下两种方式确认：
1）查看管道任务配置：在管道任务的“选择来源”步骤中，会明确显示其所关联的“采集任务”名称或ID。如果多个管道任务显示的采集任务标识相同，则它们共享同一个采集任务。
2）查看实时数据共享中心：在“实时数据共享中心”的管理界面，可以查看到所有的采集任务列表。点击某个采集任务，通常会有一个“依赖关系”或“关联任务”的视图，其中会列出所有正在使用该采集任务的管道任务。
Q2: 如果一个共享的采集任务出错了，会影响所有使用它的管道吗？
是的，会影响所有使用它的管道任务。
采集任务是所有关联管道的数据唯一来源。一旦采集任务因故出错停止（例如，数据库连接中断、日志文件损坏、权限变更等），它将无法继续捕获新的数据变更。这将导致所有依赖于它的管道任务都无法获取到增量数据，表现为“待同步数据量”持续为零，数据同步出现事实上的中断。因此，对共享采集任务的监控和告警至关重要。
上一篇：实时采集任务功能说明
