第7章 生态与连接器：数据从哪来 到哪去

第 7 章 · 生态与连接器：数据从哪来 到哪去

章节摘要：本章跟着一条数据走完它在管道里的完整旅程——从业务库的一次 UPDATE，变成 CDC 流、经消息队列进入作业、被 SQL 加工、最终落进 OLAP 与大屏。三站依次看源头与出口（连接器）、源头里的异类（Flink CDC）、以及把这一切组织起来的元数据层（Catalog）。终点是你能为任何一条数据画出它的全景管道图。

一条主线

主线是一条具体的数据：业务库里一行订单记录的状态从"待支付"改成了"已支付"。对业务库来说这只是一次再普通不过的 UPDATE；但对实时体系来说，一次变更的大戏刚刚开场——变更被捕获成事件，流入消息队列，被 Flink 作业消费加工，与维度表关联补全，最终落到 OLAP 引擎，三秒后出现在大屏上。

这条旅程把前面六章的知识全部串上了血管：第 3 章的时间语义负责把乱序的变更排好队，第 4 章的状态与检查点负责加工过程的可靠，第 6 章的运维体系负责管道不塌方。而本章要补上的最后一块拼图是进出管道的接口：数据从哪进（Source 连接器与 CDC）、往哪出（Sink 连接器）、元数据谁来管（Catalog）。接口的选型与配置，直接决定了前六章精心守护的"精确一次"能不能延伸到端到端。

沿途站点

7.1 数据源与 Sink——连接器总览。Source 与 Sink 的分类学（带位点管理的、批量导入的、流批两用的）、容错语义的三个等级、选型时的四问清单。你会看懂为什么"能不能重放、会不会重写"是连接器评估的第一问。

7.2 Flink CDC——源头革命。变更数据捕获如何把数据库的 binlog 变成 Flink 的流；整库快照加增量续读的无锁机制；schema 演进的应对。CDC 把"数据集成"从搬运工的苦活变成一条 SQL 的声明，是近年实时数仓的最大变量。

7.3 Catalog 与元数据——管道的户籍系统。表从哪来（临时表、环境目录、外部目录三级）、Doris 与 Hive 等 Catalog 如何让"建表"变成"挂表"、元数据中心化对协作的价值。管道越长，户籍越重要。

三站由外向内：先认识血管的两端，再深入最重要的进口，最后看贯穿全身的神经系统。读完合上书，你应该能随手画出自己公司实时链路的全景图——每个环节用什么连接器、语义承诺是什么、元数据登记在哪。

拐点与结论

本章的认知拐点在 7.2：传统数据集成把"同步"当成搬箱子——定时扫表、比对、批量搬运，延迟以小时计、对账以天计。CDC 的出现把范式掰了过来：数据库的变更日志本身就是一条天然的流，同步不再是搬运而是"订阅"。理解了这个范式，你会发现实时数仓的很多老大难（延迟、对账、重复）在架构层面就消解了，而不是靠搬运脚本打补丁。

最终落点是一张端到端的语义对账表：从业务库的变更，到消息队列的位点，到 Flink 的检查点，到 OLAP 的提交，每一跳的精确一次承诺由谁签署、哪一跳可能降级。第 8 章的大屏复盘里，这张表是对账争议的最终裁判。

读完你应该

• 说出 Source 与 Sink 各自的容错语义等级，并为关键链路选择精确一次级的组合；
• 解释 CDC 的快照加增量机制，判断哪些表适合整库同步、哪些要拆出去单独处理；
• 处理一次 schema 演进（加列、改类型），写出兼容策略与验证步骤；
• 用 Catalog 把作业里的临时表收敛到中心化元数据，说清三级目录的分工；
• 画出自己业务的端到端管道图，并为每一跳标注语义承诺与潜在降级点。

下一章的接力

血管通了，最后一步是让整个身体更加强壮：第 8 章进入性能调优与生产实战——资源怎么配、状态怎么养、倾斜怎么拆，最后用一次大屏任务的全流程复盘把全册知识合龙。

金句：引擎再可靠，血管不通也是白搭——端到端的承诺，从来是最弱一跳说了算。