搬瓦工中文网
流式SQL是指采用用于编写数据库查询的相同的声明式SQL，而在快速变化的数据流上运行。这很有用，因为。
- 当你能迅速采取行动时，数据往往更有价值
- 现有的从数据流中获得实时洞察力的工具过于复杂。
SQL的 “声明 “性质在解决第二点方面发挥了重要作用，因为它允许用户专注于他们想要什么，而让底层引擎担心如何完成。
在现实世界中，流式SQL被用来。
- 启用新的内部和面向客户的洞察力、自动化和应用程序
- 通过为关键指标提供单一的最新真相来源来提高商业智能数据的价值
- 通过取代代码进行数据协调和转换来简化微服务
什么是流式SQL?
让我们先具体说明一下我们说的流处理和SQL是什么意思。
流(事件流)
流指的是像Kafka、Kinesis或Pulsar这样的消息中介，它们将数据作为事件或消息的连续流来处理。
事件流处理一切，从交易到用户在网站或移动应用程序上的行动、物联网传感器数据、服务器的指标，甚至是传统数据库上的活动，都通过 change data capture.
SQL
在流的背景下，SQL为用户提供了一种声明性语言，用于。
- 创建视图，将流中的原始数据连接、过滤和分组为更有用的输出(CREATE MATERIALIZED VIEW)
- 从源和视图中选择数据(SELECT)
注意：CREATE MATERIALIZED VIEW命令是流式SQL的核心概念。它来自于 databases来的，在那里它被用来提前计算视图，以防数据发生变化。在流媒体中，数据一直在变化，所以查询在维护成物化视图时往往更有用。
其他常见的SQL动词如INSERT、UPDATE和DELETE在流式SQL中也有作用，但在这篇文章中，我们将重点讨论从流中读取、连接/过滤/转换这些流的核心概念，并使其输出可查询或 写到一个新的流。
流上的SQL和数据库之间的区别
一旦你尝试在流上使用SQL，一些关键的区别就会变得很明显。
时间点查询与连续查询
在传统数据库上运行SQL查询，会从一个时间点上返回一组静态的结果。
以这个疑问为例：
SELECT SUM(amount) as total_amount FROM invoices;
当你运行它时，数据库引擎会扫描在查询时存在的所有的Invoices，并返回其金额之和。
使用流式SQL，你可以运行上面的确切查询，并得到一个时间点的答案。但是你查询的是快速变化的数据流，一旦你得到了结果，它们可能就已经过时了。在许多情况下，一个持续更新的查询(物化视图)在以下几个方面更有用，我们将在下面描述。
要把上面的查询变成一个物化的视图，你要写。
CREATE MATERIALIZED VIEW invoice_summary AS SELECT SUM(amount) as total_amount FROM invoices;
当你第一次创建时，SQL引擎将处理它所能访问的整个Invoice事件历史，直到现在，然后随着新的发票事件的到来继续更新。
响应时间与滞后
传统的数据库有查询响应时间的概念：你运行一个查询，在引擎计算结果的过程中会经过一些时间，然后你得到响应。
在流处理中，最初的响应时间只是在你第一次物化一个视图时的一个因素。但是，如果我们的输入事件突然激增，在流结果中一定会有某种时间上的惩罚。这种惩罚就是时间滞后：输出比输入落后多少时间?
就像传统数据库的响应时间一样，大多数终端用户不需要考虑流式系统的时滞问题，但知道它的存在有助于以避免问题的方式编写和使用流式SQL。
不同的行动为底层引擎创造工作
在读取方面，传统的数据库引擎一直在闲置，直到它收到一个查询，然后它计划和优化它，并开始工作提供结果。一旦它回复了结果，它就会再次闲置，直到它收到另一个查询。发送查询是为引擎创造工作。
如果你回到上面的物化视图，来自流的新数据为引擎创造了工作。在Materialize中，这种方法是通过增量计算实现的：更新视图所做的工作与进来的数据成比例，而不是与查询的复杂性成比例。我们不需要对数据进行全面的重新扫描来更新结果。
这种模式的转变使得流式SQL最适合于反复询问同一问题的查询(如仪表盘、报告、自动化、大多数应用程序代码)，而不是临时性的查询。
为什么流式SQL是有用的?
1.数据最初出现时往往是最有价值的
这有两个原因，一个很明显，一个不太明显。
- 更快的数据=更快的决策–股票市场是这个想法发挥到极致的一个明显例子。
- 但它也适用于SaaS企业，像市场、旅游、活动等需要对费率和库存做出快速决策的垂直行业，以及零售和物流业，因为快速决策可以减少低效率，等等。
- 数据离它的源头越近，被误解的机会就越少–数据从创建的地方到使用的地方，每一步都会增加出错的可能性，即终端用户(人或机器)认为数据代表的东西并不存在。时间在其中起到了作用，它迫使人们围绕操作顺序和工作的一致性进行协调。在这种情况下，切换到流数据并不是因为它更快，而是因为你不再需要考虑时间问题。
2.SQL是一种从流式数据中获得洞察力的伟大手段
这里是另一个关于流式事件的物化视图的例子。
CREATE MATERIALIZED VIEW experiments AS SELECT experiment_views.name, experiment_views.variant, COUNT(DISTINCT(experiment_views.user_id)) as unique_users, COUNT(DISTINCT(conversions.user_id)) as unique_conversions FROM experiment_views LEFT JOIN conversions ON conversions.user_id = experiment_views.user_id AND conversions.created_at > experiment_views.created_at GROUP BY experiment_views.name, experiment_views.variant;
- SQL并不是流处理所特有的–当数据从流转移到数据库时，其意义并没有改变，所以我们查询的方式也不应该改变。
- 它的声明性提高了生产力 – 开发人员几乎不需要做任何优化决定，特别是与代码中的相同任务相比。
SQL有一个额外的好处，那就是它是一种成熟的语言，建立了30多年，周围有一个工具和教育的生态系统。这意味着更多的开发者可以使用流媒体数据，并轻松地将其整合到他们的堆栈的其他部分。
流式SQL的用例
今天，任何已经在使用像Kafka这样的消息代理的人都可以开始使用流式SQL，而不需要付出很大努力。在未来，随着CDC软件的成熟，这一标准将扩展到 “任何拥有数据库的人”。”以下是一些使用流式SQL的例子。
商业智能和分析
当决定 “什么是赋予我们的内部团队从数据中做出智能决策的最佳方式 “时，流式SQL是一个需要考虑的选项，它的权衡使它对某些情况比其他情况更好。
在许多情况下，用流式SQL完成的主源数据的物化视图是一个更简单的 data pipeline.除了实时数据的好处外，企业使用这种方法还可以回避以下问题。
- 批量处理中的时间间隔和操作顺序的协调
- 在下一个批次运行前无法修复或测试的错误所导致的长时间停工
- 仪表盘加载缓慢
- 缓存、反规范化造成的不一致问题
微服务
流式SQL被用来取代在微服务中做复杂数据协调和转换的代码。
像kafka这样的事件流通常已经是微服务架构中的第一等公民。工程师们经常发现自己在构建和维护复杂的应用程序，从kafka中消费。例如：从事件日志中读取的应用程序，以产生对SaaS应用程序的API使用的洞察力和测量。
微服务中任何看起来像查询的组件都可能被流式SQL所取代。
实时应用
如果你的应用程序的价值取决于你实时交付更新和数据的能力，流式SQL可能是建立一个昂贵或复杂的多组件堆栈的替代方案。
新的能力
- 面向用户的实时分析–以前，只有像LinkedIn和Google这样的技术巨头才有规模和工程团队来建立面向用户的实时分析(如LinkedIn的 “谁浏览了你的个人资料 “页面或Google Analytics的实时仪表板)。通过降低复杂性，流式SQL向更多的公司开放了神奇的实时用户分析功能。
- 业务自动化 – 一旦你有了实时仪表盘的流式SQL，一个自然的进展就是开始在相同的数据上做出自动化的决定。(例如。如果你的电子商务网站从某一特定来源获得的流量激增，就在主页上增加一个促销活动)。
总结
Materialize提供了一个流式SQL实现，它在两个重要方面是独一无二的。
在Materialize中，你可以用与postgres兼容的SQL编写查询。我们认为值得花费额外的精力来构建这个系统，因为只有在这种级别的SQL兼容中，你才能获得与现有工具集成的好处，并消除用户对高级流处理概念的负担。
查询引擎使用增量计算(Differential Dataflow)来更有效地维护物化视图，因为新的数据进来了。
