作者：吴英骏｜RisingWave Labs 创始人 & CEO
上个月，我在圣何塞参加了流处理领域最负盛名的活动------Current 2023 。这是我在今年参与过的最喜欢的活动之一。每年，来自世界各地的流处理专家集聚于此，一起参与到数据流系统的讨论中。
由于路途遥远，的确国内的朋友来参加 Current 2023 的比较少，但总结一下，Confluent 在这个大会上主要发布了两个内容：
- 全新的 Kora 引擎，官方宣称 10 倍于 Apache Kafka ：www.confluent.io/10x-apache-...；
- 基于 Flink SQL 的流计算云托管服务（预览版） ：www.confluent.io/blog/introd...。
当然了，除了 Confluent 自家的产品发布之外，不少独立厂商带来的产品也吸引了不少眼球，其中就包括我们在做的流数据库（streaming database）。有兴趣的朋友们可以参加一下技术博客博主 Yaroslav Tkachenko （来自 Goldsky）撰写的博客。在他分享的众多见解中，他对于流式数据库的两条评论让我特别感兴趣：
- "They [Streaming databases] can cover 50% to 80% of use cases, but they'll never arrive close to 100%. But they can be surprisingly sticky!" （"流式数据库可以涵盖 50% 到 80% 的使用场景，虽然它们永远不会接近 100%。但用户粘性非常大！"）
- "I approached some of the vendors and asked if they planned to introduce programmatic APIs down the road. Everyone said no - SQL should give them enough market share."（"我找到一些供应商，问他们是否计划在将来推行编程 API。每个人都说不 ，因为 SQL 会为他们提供足够的市场份额。"）
Yaroslav 的观察引发了我一连串的思考。不过这并不是因为我持有不同观点，相反我完全同意他的观点。作为一直致力于打造 10 倍于 Apache Flink 的 RisingWave 的我来说，他的博客激发了我从不同角度思考 SQL 流计算和流数据库。在本文，我就与大家分享一下这些思考。
SQL 的表达力
流数据库能够让用户以使用数据库的方式来处理流式数据，SQL 自然成为其主要语言。与大多数现代数据库一样，RisingWave 和其他几个流数据库都优先考虑了 SQL，也提供了像 Python 和 Java 等语言的用户定义函数（UDF）。但这些数据库实际上并没有提供更底层的编程 API 。
因此，我们需要思考的问题是：SQL（即使有 UDF 支持）能满足流处理的需求吗？
在我与数百名流处理从业者的交流中，许多人认为单独使用 SQL 不足以进行流处理，我脑海中立刻浮现出三个使用场景：（1）（基于规则的）欺诈检测；（2）金融交易；（3）机器学习。
- 对于欺诈检测，许多应用继续依赖基于规则的方法。对于这些应用程序，Java 通常更容易用于表达规则并与应用程序直接集成。为什么？主要是因为许多系统后端是用 Java 开发的。如果流数据不需要在数据库中持久化，使用一致的编程语言（如 Java）来表达逻辑会更容易。
- 在金融交易方面，人们会担心 SQL 的局限性，特别是在处理标准 SQL 之外的特殊表达式时。虽然可以将这些逻辑嵌入到用户定义函数（UDF）中，但 UDF 可能会造成更大的延迟。因为传统的 UDF 实现通常涉及主机 UDF 服务器，它们通常会导致较大的延迟。
- 机器学习领域的从业者更倾向于使用 Python。因为他们主要使用 Python 来开发应用程序，并且严重依赖如 Pandas 和 Numpy 之类的流行的库。对于他们来说，使用 SQL 来表达逻辑并不是一个自然而然的选择。
虽然在许多使用场景中，无论是否支持 UDF，SQL 都能够满足需求（大家可以参考 RisingWave 在金融科技和机器学习领域的一些案例），但确实 SQL 可能比不上 Java 或 Python 的表达力 。但值得讨论的是，如果 SQL 可以满足大家的流处理需求，大家会选择以 SQL 为中心的接口，还是继续使用以 Java 为中心的框架。在我看来，大多数人会选择 SQL，因为 SQL 作为一门基础语言其被广泛使用，每个数据工程师、分析师和科学家都熟悉它。如果基本工具能够满足人们的需求，为什么要用更复杂的解决方案呢？
SQL 的受众
大多数在大数据时代出现的数据系统都是以 Java 为中心的，像 Hadoop、Spark、Hive、Flink 等。然而，像 ClickHouse、RisingWave 和 DuckDB 这样的新系统，本质上来说属于数据库系统，它们优先考虑 SQL。那么到底是哪些公司在使用这些以 Java 为中心的系统，又是哪些公司在使用以 SQL 为中心的系统呢？
共同特点
我发现说服成立于 2015 年之前的公司采用 SQL 进行流处理是很有挑战性的，比如 LinkedIn、Uber 和 Pinterest 等。很显然其中许多公司之所以不接受我的建议，主要是因为它们已经建立了健全的数据基础设施，而且更愿意专注于开发更多应用级别的项目（我知道现在许多公司都在研究LLM！）。仔细研究会发现它们具有以下共性：
- 这些公司的数据基础设施建立于自己维护的数据中心；
- 他们使用以 Java 为中心的大数据生态系统，包括 Hadoop、Spark 和 Hive 等技术；
- 他们建立了专门的工程团队专门运维以及二次开发数据基础设施；
- 即使转向云计算，他们更倾向于在 EC2、S3 或 EKS 等平台上构建定制化的数据基础设施，而不是选择托管的数据服务。
阻碍因素
有一些具有挑战性的因素阻碍了这些企业采用更新更好的流处理技术：
- 这些企业的代码库完全使用 Java。虽然 SQL 数据库提供 Java UDF，但在这些 UDF 中频繁调用Java 代码并不总是可行的。
- 他们使用的一些大数据系统是根据他们特定的需求定制的，这使得迁移非常困难。
- 与大量的大数据生态系统集成通常需要大量的工程工作。
- 还需要考虑人的因素 。在小部分企业中，部分员工已经长期运维一些特定系统，更换系统实际上会威胁到他们的职业稳定性。
尽管将流数据库这样的以 SQL 为中心的系统推销给这些公司可能具有挑战性，但毕竟技术总是在向前告诉发展，不少迹象给我们带来了强烈的信号：
- 越来越多的公司开始转变到像 Snowflake、Redshift 或 Big Query 这样的基于 SQL 的数据仓库。随着"现代数据栈"得到广泛推崇，这些公司将他们的数据基础设施重新定位到以 SQL为中心的数据仓库周围。因此，他们将愈发不愿意管理自己的基础设施或坚持使用以 Java 为中心的系统。
- 另一个有趣的信号是业务变化和领导层的变更。无论是由于业务重心的改变还是出现新领导掌权，这些变化通常会引发对现有系统的重新评估。新领导者可能不愿意简单地维持现状（因为这样做带来的投资回报可能有限），所以更愿意探索其他选择，比如升级他们的数据基础设施。
有趣的是，SQL 流处理的日益普及主要得益于以 Java 为中心的大数据技术，如 Apache Spark Streaming 和 Apache Flink 的支持和推广。虽然这些平台最初选择了 Java ，但它们越来越认识到SQL 的重要性。普遍的趋势表明，这些平台的大多数初学者使用 SQL 来开始他们的探索，这也使他们更倾向于 SQL 生态系统，而不是 Java 生态系统。而且，即使他们最初采用了以 Java 为中心的系统，将来转向 SQL 流数据库可能会比预期的更顺利。
SQL 流处理市场规模
在深入探讨 SQL 流处理的市场规模之前，先看看更广泛的流处理市场是很有必要的。我们必须承认，与批处理市场相比，目前的流处理市场相对更小。争论这个问题毫无意义，简单对比一下Confluent（头部流数据公司）和 Snowflake（头部批数据公司）的当前市值即可证明这一点。但不论其当前地位如何，流处理市场无疑是蓬勃发展的。越来越多的流处理创业公司被投资，而且Snowflake、Databricks 和 MongoDB 等主要数据基础设施公司也开始开发自己的现代流处理系统。
我们有理由认为流处理市场最终将在模式和趋势上会与批处理市场趋于相似。那么在批处理市场中，SQL 部分的规模有多大呢？Snowflake、Redshift 和 Big Query 等以 SQL 为中心的产品的营收就能够解答这个问题。而主要提供 Java 接口的产品的市场规模是多大呢？至少目前在数据基础设施领域，我没有看到任何强大的产品。
有人可能会提到 Databricks，这是一家将 Spark 商业化的公司，增长迅速而且即将上市。虽然没有人能否认 Spark 是世界上被最广泛使用的大数据系统，但仔细研究 Databricks 的产品和营销策略我们能得出结论，他们押注在以 SQL 为中心的数据湖仓上。
这样一来就出现了一个悖论：与 Java 相比 SQL 的表达力可能有限，但以 SQL 为中心的数据系统却能够带来更多收入。为什么呢？
首先，正如 Yaroslav 的博客中所强调的，SQL 可以满足大约 50-80% 的使用场景。尽管确切的数字难以确定，但显然 SQL 对于组织的大部分需求是能够满足的。假设一家公司确定 SQL 流处理符合其使用场景，那么他们会选择哪个系统？一个以 SQL 为中心的系统还是一个以 Java 为中心的系统？如果你不确定，我们可以类比一下：当你打算切割一根牛肋骨时，你会选择一把专用的牛肋骨刀还是一把瑞士军刀？答案是显而易见的。
其次，考虑到 Java 的受众。具有计算机科学背景的人可能能够熟练地使用 Java 并理解系统特定的 Java API。但期望那些没有这种背景的人掌握 Java 是不现实的。即使他们能够掌握，他们是否愿意单独管理这个服务呢？虽然这不是绝对的，但拥有强大工程团队的公司应该不太倾向于外包。
不仅仅是流处理
我们已经深入探讨了 SQL 流处理，现在是时候将注意力转向流数据库。像 Spark Streaming 和 Flink 这样的传统流处理引擎已经集成了 SQL。如前所述，这些引擎已经开始使用 SQL 作为入门语言。供应商主要侧重于 SQL，Confluent 的 Flink 就是一个明显的例子。鉴于 Spark Streaming 和 Flink 都提供了 SQL 接口，那为什么还要推动流数据库呢？
答案是明显的，大数据 SQL 与数据库 SQL 有本质上的不同 。例如，大数据 SQL 通常缺乏数据库系统中常见的标准 SQL 语句，如 create、drop、alter、insert、update 和 delete 等。更深入地看，一个关键的区别在于存储能力：流式数据库具备存储能力，而流处理引擎通常不具备。这种差异影响了设计、实施、系统效率、成本、性能以及其他多个方面。大家如果对这些区别非常感兴趣，可以参考我的 QCon San Francisco 2023演讲（幻灯片在这里）
此外，数据库的基本理念与计算引擎的基本理念不同。数据库用户经常使用 BI 工具或客户端库进行结果可视化，而那些使用计算引擎的用户通常依赖外部系统进行存储和查询。
有人认为，流式数据库就是流处理引擎和传统数据库的融合。从技术上讲，你可以通过合并 Flink（流处理引擎）和 Postgres（数据库）来构建一个流式数据库。然而，这样的尝试会带来许多挑战，包括维护、一致性、故障恢复以及其他复杂的技术问题。我将在下一篇博客中详细介绍这些问题。
总结思考
SQL 在大多数场景下都具有足够的表达力，虽然 Java、Python 等其他语言在特定场景中确实会胜过它。然而，是否拥抱 SQL 流处理不仅仅取决于SQL 的表达力，它通常还受到公司当前情况以及其数据基础设施发展历程的影响。借助于批处理领域观察到的趋势，我们可以推测出 SQL 流处理未来的市场规模相当可观。我们也知道流式数据库提供的功能超出了单纯的流处理。
在未来几年中，见证这个领域的演变将会是非常有趣的。
关于 RisingWave
RisingWave 是一款分布式 SQL 流处理数据库，旨在帮助用户降低实时应用的的开发成本。作为专为云上分布式流处理而设计的系统，RisingWave 为用户提供了与 PostgreSQL 类似的使用体验，并且具备比 Flink 高出 10 倍的性能以及更低的成本。了解更多：
GitHub: risingwave.com/github
官网: risingwave.com
公众号： RisingWave 中文开源社区