Flink SQL和DataStream API该用哪个？什么场景必须用DataStream？
先说结论
| 维度 | Flink SQL | DataStream API |
|---|---|---|
| 开发效率 | 高（SQL语法，门槛低） | 低（Java/Scala编程） |
| 优化器 | 有（基于Calcite的优化） | 无（手动优化） |
| 状态控制 | 自动管理 | 精确控制（自定义State、Timer） |
| 复杂逻辑 | 有限（窗口+聚合+Join） | 无限（任意逻辑） |
| 连接器 | 丰富（Kafka/JDBC/Hive/ES等） | 同样丰富 |
| 版本迭代 | 改SQL即可，不需要编译 | 改代码要重新编译部署 |
| 生产推荐 | 默认选择 | 复杂逻辑时使用 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这个问题和Spark的“DataFrame vs RDD”很像。简单说：80%的场景用Flink SQL就够了，但有些场景必须用DataStream。关键是知道“边界在哪里”。我在两家公司分别用过两种API，今天把经验总结分享出来。
什么场景必须用DataStream？
场景一：复杂的状态逻辑
比如“用户在A页面停留超过30秒且没有点击任何按钮，就发送一个提醒”——这种涉及自定义Timer和复杂状态转换的逻辑，SQL写不了。
场景二：CEP（复杂事件处理）
比如“检测用户30分钟内连续登录3个不同设备”这种模式匹配，Flink CEP库只支持DataStream API。
场景三：自定义Source/Sink
如果要读写的外部系统没有现成的SQL Connector，就需要用DataStream API自己写。
实战经验：我的选型策略
我在元宇宙社交App时，大部分实时作业用的是DataStream API，因为那时候Flink SQL生态还不成熟（Flink 1.10时代）。但在当前短剧出海公司，基本全用Flink SQL——因为通过阿里云的DataWorks平台提交SQL作业非常方便，不需要编译打包。
经验总结：能用SQL就用SQL，SQL搞不定再用DataStream。SQL的迭代速度和维护成本远低于Java代码。
总结
80%场景用Flink SQL，复杂状态逻辑、CEP、自定义Source/Sink用DataStream。面试时能说清楚“边界在哪里”，再加一个“我在两家公司的不同选择”的经验，就很有说服力。
下一篇聊一个高频场景：两条流要关联——Flink的双流Join怎么做？有哪些坑？
你们生产环境用的Flink SQL多还是DataStream多？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长