Flink SQL 里那些DDL的秘密，原来不是光写语法那么简单啊

直接整理自李劲松（网名“巴蜀真人”）在Flink Forward Asia 2021的演讲《Flink SQL DDL 的终极秘密》，以及其个人技术博客相关文章，略有删减整合）

说实话,刚开始用Flink SQL的DDL时，我觉得这玩意儿不就是照着文档把CREATE TABLE的语法写对吗？定义个字段名、类型，配一下连接器参数，不就完事儿了？但踩过几次坑之后才发现，真是想简单了，这里面门道不少，根本不是光把语法写对就能让作业跑得稳定、高效的，今天我就把这些容易被忽略的“秘密”摊开来讲讲。

第一个秘密：DDL不是孤立的，它深刻影响执行计划。

来源里讲了个让我印象深刻的例子,你写一个非常简单的DDL，比如创建一个Kafka源表，你可能会随手写上'scan.startup.mode' = 'latest-offset'，这语法没错，对吧？但问题来了，如果你的作业因为某种故障重启了，而你的上游Kafkatopic还在不断进数据，那么重启后，从最新的offset开始读，就意味着你会丢失从故障发生到重启成功这段时间内流入的数据，这对于要求精确一次语义（exactly-once）的作业来说是灾难性的。

那怎么办？你得根据业务场景选择'scan.startup.mode' = 'earliest-offset'或者更高级的'timestamp'模式，这个选择不是在调优引擎参数，而是在你写DDL的那一刻就决定了，DDL的第一个秘密就是：它不仅是定义表结构，更是定义数据流入的初始状态和行为规则，直接关系到业务的正确性和数据的完整性。 你DDL写得马虎，后面用再复杂的SQL也补不回来。

第二个秘密：“水印”声明是流处理DDL的灵魂，但坑也最多。

水印（Watermark）是Flink流处理里衡量事件时间进度的核心机制，在DDL里，我们通过WATERMARK FOR rowtime_column AS expression来定义，看起来就是一行声明，但这里面的讲究可多了。

来源中特别强调了一个关键点：水印的生成策略决定了窗口的触发时机和结果的准确性。 你用的是ASCENDING单调递增的水印，还是BOUNDED有界乱序的水印？那个延迟时间delay你设了多少？这个值不是拍脑袋定的。

如果你设得太小,比如数据本身网络抖动可能导致乱序达到5秒，你只设置了2秒的延迟，那么那些晚到的、本该参与计算的数据就会被水印无情地抛弃，导致计算结果偏小，如果你设得太大，比如30秒，虽然数据都能等到，但窗口触发会变得非常迟钝，整个流处理的实时性就大打折扣了，写水印DDL时，你必须对上游数据源的乱序情况有清晰的了解，这个delay参数是一个典型的业务技术权衡，DDL语法可不会告诉你该填几秒。

第三个秘密：连接器参数配置是性能和生产稳定的重灾区。

Flink SQL的强大在于它能用DDL连接各种外部系统，比如Kafka, MySQL, HBase, Elasticsearch等，每个连接器都有一大堆参数，很多人只是从网上复制粘贴一段配置，能跑通就不管了。

但来源里指出,这里面隐藏着大量影响性能和稳定性的细节，写入Sink端时，批量提交的参数就极其重要，像JDBC Sink，如果你不配置sink.buffer-flush.max-rows和sink.buffer-flush.interval，它可能每一条数据都触发一次数据库连接和写入，这对于数据库来说是巨大的压力，性能极差且可能把数据库打挂，合理的批量提交能将多条数据攒成一个批次写入，大幅提升吞吐量。

再比如,Kafka Sink的transaction.timeout.ms参数，这个需要和Flink的检查点间隔协调好，如果Flink的检查点时间比Kafka事务超时时间还长，那么事务会在完成前就被Kafka终止，导致数据提交失败，这些参数都需要你在DDL中根据实际的集群环境和业务要求进行精细调整，而不是无脑用默认值。

第四个秘密：主键约束（PRIMARY KEY）不只是逻辑约束，它直接影响某些操作的语义。

在DDL里定义主键,以前我以为是可有可无的，只是为了语义清晰，后来发现，对于像UPSERT-Kafka这样的Sink，或者用于CDC（变更数据捕获）的场景，声明主键是必须的，因为它决定了更新（UPDATE）和删除（DELETE）操作如何被正确解释和执行。

如果没有正确定义主键,Flink可能无法区分哪条数据是新的、哪条是旧的，导致changelog流处理错误，写出脏数据，主键约束在Flink SQL DDL中，尤其是在涉及更新操作的流式ETL和汇入OLAP系统的场景下，是一个具有实际执行语义的强约束，不是装饰品。

第五个秘密：Schema的演变与兼容性是个前瞻性设计。

业务是在发展的,表结构难免要变更，比如增加一个字段，在批处理世界里，这或许简单点，但在流处理中，Source和Sink的Schema变更需要谨慎处理，你的DDL设计需要有前瞻性，考虑如何与Schema Registry（如Confluent Schema Registry）集成，或者如何配置连接器（如Kafka）的value.fields-include、key.fields-include等参数来适应未来可能的变化，如果一开始DDL没设计好，后期变更Schema可能导致作业无法从检查点恢复，或者数据格式不兼容，造成生产事故。

Flink SQL的DDL远不止是语法正确那么简单，它是一门结合了业务知识（数据特征、容错要求）、流处理核心概念（时间语义、状态管理）和外部系统特性（连接器原理、参数调优）的综合实践，下次再写DDL时，或许我们得多想一想：这个配置，在作业启动、运行、故障恢复以及未来扩展时，到底意味着什么？想清楚了这些，才能算是真正掌握了Flink SQL DDL的秘密。