1. 概述编辑
本文讲述如何配置实时管道任务。
2. 实时管道任务配置流程编辑
2.1 准备工作
| 准备工作 | 说明 |
|---|---|
| 步骤一（必做）：准备 FDL 工程 | 参考 FineDataLink部署方案选择 文档，部署 FDL 工程 |
| 步骤二（必做）：注册功能点 | 若需要使用数据管道功能，则需要参考文档注册相关功能点：注册简介 |
| 步骤三（必做）：数据源准备 | 管道任务支持的数据源请参见：数据管道支持的数据源类型 需要拥有数据连接的使用权限，参考 配置数据连接 文档新建数据连接，或者联系管理员分配数据连接的使用权限：数据连接权限概述 |
2.2 配置流程
| 步骤 |
|---|
| 步骤一：准备数据库环境（必做） 基于需要设置数据管道任务的数据源，授予数据源配置的账号在数据库进行相应操作的权限。详情请参见：数据库环境准备概述 注：4.2.1.1 之前版本，若使用 SQL Server 数据库作为管道任务的来源库，配置数据连接时不建议使用自定义驱动；且管道任务的日志等级不建议为 DEBUG （可设置为 INFO）。否则管道任务中会出现大量 SQL Server cdc 日志打印 |
| 步骤二：管道任务环境准备（必做） 部署 Kafka 开源流处理平台作为中间件。详情请参见：部署Kafka、配置传输队列（只有 FDL 工程的超管才能配置传输队列） 注1：Kafka 建议部署在 Linux 系统中（Kafka 也支持安装在 Windows 中，但性能会受到限制，仅做演示使用，不建议用于生产环境）；Kafka 与 FDL 可以不在一个服务器上 注2：重启 Kafka 前，需要先手动暂停管道任务，重启 Kafka 后，需要重启下 FineDataLink 工程，再手动重启管道任务，否则管道任务会有异常。 注3：数据管道需要使用 Kafka 作为中间件完成实时同步，若来源表有 1000 张，kafka 中会生成 1000 个 topic，即一张表对应一个 |
| 步骤三：分配管道任务权限（选做） 若需要使用数据管道的用户不是超级管理员，则需要为对应用户分配数据管道功能的使用权限 若需要在某个文件夹下新建管道任务，则需要分配该文件夹的管理权限 详情请参见：管道任务管理权限 |
步骤四：配置数据管道任务（必做） 按照顺序参考以下文档： 注1：不建议用户使用数据管道同步 longtext 类型的字段，否则 Kafka 会有问题，运行效率也会有问题 注2：不建议来源表字段名称中包含空格，否则任务启动将会报错
在 4.2.1.1 之前的版本中，支持设置任务级别的脏数据阈值，用户通常设置较大数值，4.2.1.1 及之后版本，调整为表脏数据阈值；所以，升级至 4.2.1.1 及后续版本后，建议适当调小该阈值设置，以有效控制脏数据量 |
3. 管道任务配置指导说明编辑
任务的划分是管道设计的基石。不合理的划分，如单个任务承载过多或过少的表，都会在任务首次启动、日常运行及异常恢复等环节带来潜在的风险和效率瓶颈。
3.1 任务划分与设计策略
3.1.1 均衡负载，隔离风险
1）避免「一表一任务」
因果关系：每个实时管道任务在启动和运行时都会占用独立的系统资源（如内存、线程、数据连接）。创建大量「一表一任务」的管道，会急剧增加 FineDataLink 和 Kafka 服务器的整体负载，导致资源争抢和系统性能下降。
运维挑战：任务数量过多会极大地增加监控和管理的复杂度，使得快速定位问题变得困难。
注：管道任务的来源端若为 MySQL、SQLServer、Oracle，若同一个库中的多张表都需要实时同步，建议在一个管道任务中实现；若同一个库中的多张表，每张表单独配置一个管道任务，数据库将承受较大压力。
2）避免「一任务千表」
因果关系：当一个任务包含数千张表时，任务的启动过程（包括权限校验、元数据加载、资源分配等）会变得异常漫长。更重要的是，一旦任务中的任何一张表或数据出现问题导致任务中断，整个任务（包含所有几千张表）的同步都会暂停。恢复时，需要对整个任务进行回溯和处理，恢复周期极长，风险极高。
风险隔离：这种模式缺乏风险隔离机制，单一表的故障会引发“雪崩效应”，影响该任务下所有表的同步时效性。
提示:常见误区：
误区一：为了管理的“方便”，将一个业务系统下的所有表都放在一个管道任务里
解读：这种“方便”是短暂的，一旦出现问题，排查和恢复的代价将远超初期配置的便利。真正的运维便利性来自于稳定、可控的系统设计
3.1.2 任务拆分策略
1）按目标端拆分
原则：如果数据需要写入到多个不同的目标端（例如，一部分数据入Hadoop，一部分入MySQL），这是拆分任务的必要条件。
建议：即使是同一个源，同一个目标端，如果采集的表非常多，也建议进行拆分。根据经验，将一个源到一个目标的任务数量控制在5个以内是比较合理的范围，这在管理复杂度和资源开销之间取得了较好的平衡。
2）按表规模拆分
策略：将规模和同步特征相似的表进行分组。
超大表独立任务：将数据量巨大（例如：上亿行或TB级别）的表单独放置在一个或少数几个任务中。
中小表合并任务：将数据量较小的表合并到同一个任务中。
价值解读：
提升启动与恢复效率：超大表的首次全量同步和异常恢复通常耗时很长。将其独立出来，可以确保中小规模表的同步任务能够快速启动和恢复，不受大表影响。
资源精细化管理：可以为超大表的任务单独分配更多的资源，而无需让中小表任务也占用同等级的高额资源。
3.1.3 FAQ
1）如果一个任务包含了上千张表，除了启动和恢复慢，还会有什么其他风险
资源消耗不可控：任务启动时会为所有表预估和申请资源，可能导致瞬间资源占用过高，影响平台其他任务。
Kafka Topic管理困难：每个同步的表默认会对应一个或多个Kafka Topic，上千张表意味着数千个Topic，对 Kafka 集群的管理和维护是巨大的挑战。
问题定位困难：日志会变得非常庞杂，当出现数据延迟或积压时，很难快速定位到是哪几张表出了问题。
2）对于“中小表”，大概的数量级建议是多少？几十张还是几百张
这没有一个绝对的数字，取决于表的总数、数据变更频率和可接受的运维复杂度。一个比较普适的建议是，单个任务包含的表数量在几十到一百张以内是比较健康的范围。如果表数量超过 200 张，就应该认真考虑是否需要进一步拆分。
3.2 源端数据库配置建议
源端数据库的正确配置是实时管道稳定运行的生命线，尤其是日志相关配置，直接决定了在发生长时间故障后数据能否成功恢复。
3.2.1 日志保留时长
建议：源端数据库的增量日志（如Oracle的归档日志、MySQL的Binlog）保留时长建议不少于3天。具体步骤请自行百度。
原因：这是为应对非工作日（如周末、节假日）发生的“长尾”故障而设计的“黄金窗口”。如果日志只保留24小时，周五晚上发生的管道故障，到周一早上来处理时，所需日志可能已被清理，导致增量数据断流，无法从断点恢复，只能重新进行成本高昂的全量同步。3天的保留策略为处理和恢复提供了充足的缓冲时间。
3.2.2 Oracle 全库补充日志
最佳实践：如非源端日志量超大或有严格的存储限制，强烈建议开启全库级别的补充日志，而不是逐个表去开启。
因果关系：
简化管理：一次性开启后，后续新增的需要同步的表无需再单独执行ADD SUPPLEMENTAL LOG DATA命令，大大简化了运维操作，降低了因忘记配置而导致同步失败的风险。
保障DDL同步：全库补充日志是实现DDL变更捕获（如RENAME COLUMN）的必要前提之一。如果仅开启表级别日志，DDL同步可能会失败或出现异常。
3.2.3 配置效率
建议：在实时管道配置界面中，应充分利用批量选表和对已选表进行批量操作（如修改写入方式、配置字段映射规则）的功能。
价值解读：对于包含数十乃至上百张表的任务，批量操作可以指数级地提升配置效率，减少重复劳动和人为错误。
3.2.4 FAQ
开启全库补充日志对Oracle数据库的性能影响有多大
全库补充日志会增加一定的I/O开销和日志生成量，因为数据库需要记录更多额外信息。
但在现代硬件条件下，对于大多数业务系统，这种性能影响通常在可接受范围之内（一般低于5%）。其带来的运维便利性和数据同步的可靠性远超其性能开销。只有在日志生成量确实达到系统瓶颈时（如每日TB级别），才应考虑切换为表级别按需开启。
3.3 核心同步配置项详解
3.3.1 优先选择物理主键
强烈建议：为目标表寻找并配置一个物理主键（Primary Key）。
价值解读：
极大提升同步效率：目标端数据库在执行 UPDATE 和 DELETE 操作时，利用主键索引可以实现极高的定位效率。无主键的表在更新时，数据库需要进行全表扫描来找到匹配行，数据量大时性能会急剧下降。
最大程度确保数据一致性：主键的唯一性约束是防止目标端出现重复数据的最强保障。它能确保对同一条记录的多次变更操作能够准确地应用在同一行上。
3.3.2 谨慎使用无主键同步
原则：如非必要，不要启用无主键同步。
因果关系：
无主键同步 的匹配逻辑远比有主键复杂，需要依赖所有非LOB类型的字段来唯一确定一行数据。这不仅使得匹配逻辑本身更耗时，而且一旦任何一个字段的值发生变化，就会被视为一条全新的数据，可能导致数据重复插入而非更新。
适用场景：只适用于源端和目标端都完全没有唯一键可选，且数据基本为只增场景的特殊情况。
提示:常见误区：源表没有主键，就直接使用无主键方式同步
正确的做法是：即使源表没有物理主键，也应积极与业务方沟通，寻找能够唯一标识一行业务数据的业务主键（一个或多个字段的组合），并在目标端将其创建为物理主键或唯一索引，从而利用高效的主键同步模式
3.4 任务健壮性与可观测性配置
健壮的配置能让任务在面临临时性故障时自我恢复，而良好的可观测性则能让我们在问题发生时第一时间知晓。
3.4.1 开启并合理配置重试机制
强烈建议：开启任务的 失败重试 功能。
最佳实践：针对网络波动、数据库连接瞬断等常见临时性故障，配置合理的重试间隔与次数。例如，可以配置重试3次，间隔分别为1分钟、5分钟、10分钟。
价值解读：这是一种低成本、高回报的容错机制。它能让管道任务自动从大量常见的、非持续性的“软”故障中恢复，避免了大量不必要的人工干预和告警。
3.4.2 开启并配置有效的消息通知
强烈建议：开启 结果通知，并配置能够及时触达运维人员的渠道。
最佳实践：
渠道选择：除了平台内通知，优先配置钉钉、飞书、微信或邮件等客户端，这些渠道的触达率和即时性远高于平台内消息。
通知事件：至少应配置“任务运行异常”、“数据同步延迟预警”和“脏数据超出阈值”等关键事件的通知。
价值解读：消息通知是运维的“眼睛”和“耳朵”。及时的通知可以让我们在问题发生的“第一时间”介入，将故障影响降到最低，是保障业务SLA（服务等级协议）的关键环节。
3.4.3 开启INFO级别日志
提示:强烈建议：在管道的日志设置中，将日志级别设置为 INFO
价值解读：
日常观察：INFO 级别日志会记录任务启动、停止、数据批次处理等关键节点信息，便于日常观察任务的健康状态。
问题排查：当任务出现问题时，INFO 级别的日志提供了丰富上下文。我们可以清晰地追溯问题发生前的完整过程，例如“是在哪个数据批次处理时卡住的”、“在DDL变更后发生了什么”，这对于快速定位问题根源至关重要。相比之下，默认的 WARN 或 ERROR 级别日志只记录结果，过程信息的缺失会大大增加排查难度。
3.5 日常运维与监控
主动、定期的巡检是发现潜在问题的最佳方式，能有效避免小问题演变成大故障。
3.5.1 定期巡检管道状态
最佳实践：运维人员应养成定期（建议每隔2-3天）登录FDL平台，在“管道首页”或“任务运维”模块查看所有任务的整体状态。
巡检要点：
任务状态：关注是否有处于“异常”或“暂停”状态的任务。
待同步数量：检查“待同步数量”是否有持续增长的趋势，这通常是数据积压的前兆。
脏数据状态：查看是否有新增的脏数据，并及时分析原因。
价值解读：通过这种“体检式”的巡检，可以在数据积压、性能瓶颈等问题初期就发现端倪，提前介入处理，防患于未然。
3.5.2 监控核心服务器磁盘空间
高频问题：FDL 服务器和 Kafka 服务器的磁盘空间不足，是导致管道服务整体崩溃的常见且高频的原因。
最佳实践：必须将 FDL 和 Kafka 服务器的磁盘使用率纳入核心系统监控，并设置合理的告警阈值（例如：超过85%告警，超过95%紧急告警）。
因果关系：
FDL服务器：需要磁盘空间存储临时文件、缓存数据和运行日志。
Kafka 服务器：所有通过管道的数据都会在 Kafka 中暂存，如果消费端（写入端）出现延迟，数据会在 Kafka 中积压，迅速耗尽磁盘空间。一旦磁盘写满，Kafka 将无法接收新数据，导致所有管道任务阻塞。