总结StreamingSQL是指采用与用于编写数据库查询相同的声明式SQL，但对快速变化的数据流进行操作。这很有用，因为。当您可以迅速采取行动时，数据通常更有价值用于从数据流中获取实时洞察力的现有工具过于复杂。SQL的“声明式”性质在解决第二点方面发挥着重要作用，因为它允许用户专注于他们想要的东西，而让底层引擎担心它是如何完成的。在现实世界中，使用的是流式SQL。启用新的内部和面向客户的洞察力、自动化和应用程序通过为关键指标提供单一、最新的真实来源来增加商业智能数据的价值通过替换数据协调和转换代码来简化微服务什么是StreamingSQL？让我们首先具体说明流处理和SQL的含义。Streaming(EventStreaming)Streaming是指像Kafka、Kinesis或Pulsar这样的消息代理，它们将数据处理为事件或消息的连续流。事件流处理从交易到用户在网站或移动应用程序上的操作、物联网传感器数据、来自服务器的指标，甚至通过更改数据捕获在传统数据库上的活动的一切。SQL在流的上下文中，SQL为用户提供了一种声明性语言。创建视图以将流中的原始数据加入、过滤和分组为更有用的输出（创建具体化视图）从源和视图中选择数据（选择）注意：创建具体化视图命令是流式SQL的核心概念。它来自数据库，用于在数据发生变化时提前计算视图。在流中，数据一直在变化，因此查询在作为物化视图维护时通常更有用。其他常见的SQL动词，如INSERT、UPDATE和DELETE在流式SQL中也有作用，但在这篇文章中，我们将重点关注从流中读取、加入/过滤/转换这些流并使它们输出的核心概念。查询或写入新流。SQLonstreams和数据库之间的差异一旦您尝试在streams上使用SQL，一些关键差异就会变得明显。时间点查询和连续查询在传统数据库上运行SQL查询将返回一个时间点的一组静态结果。以这道题为例：SELECTSUM(amount)astotal_amountFROMinvoices;当您运行它时，数据库引擎将扫描查询时存在的所有发票并返回它们的金额总和。使用流式SQL，您可以运行上面的精确查询并获得时间点答案。但是您查询的是一个快速变化的数据流，一旦您得到结果，它们可能已经过时了。在许多情况下，持续更新的查询（物化视图）在以下方面更有用，我们将在下面进行描述。要将上述查询变成物化视图，您必须编写。CREATEMATERIALIZEDVIEWinvoice_summaryASSELECTSUM(amount)astotal_amountFROMinvoices;当您第一次创建时，SQL引擎将处理直到现在它有权访问的整个发票事件历史记录，然后在新发票事件到达时继续更新。响应时间和滞后传统数据库有查询响应时间的概念：你运行一个查询，引擎计算结果的一段时间过去了，然后你得到一个响应。在流处理中，初始响应时间只是您首次具体化视图时的一个因素。但是，如果我们的输入事件突然激增，则流式处理结果中肯定存在某种时间损失。这种惩罚是时间滞后：输出滞后于输入多少时间？就像传统数据库的响应时间一样，大多数终端用户不需要担心流式系统的滞后，但了解它的存在有助于避免问题的发生。编写和使用流式SQL的方法。不同的操作为底层引擎创建工作在读取端，传统的数据库引擎处于空闲状态，直到它收到查询，然后对其进行计划和优化，并开始工作以提供结果。一旦它回复了结果，它就会再次闲置，直到它收到另一个查询。发送查询正在为引擎创建工作。如果您返回上面的物化视图，来自流的新数据会为引擎创建工作。在Materialise中，这种方法是通过增量计算实现的：更新视图所做的工作与传入的数据成正比，而不是查询的复杂性。我们不需要对数据进行全面重新扫描来更新结果。这种范式转变使流式SQL最适合重复询问相同问题的查询（例如仪表板、报告、自动化、大多数应用程序代码），而不是临时查询。为什么流式SQL有用？1.数据往往在刚出现的时候最有价值。有两个原因，一个很明显，一个不那么明显。更快的数据=更快的决策——股票市场就是将这种想法发挥到极致的明显例子。但它也适用于SaaS业务、市场、旅游、活动等垂直行业，它们需要对费率和库存以及零售和物流做出快速决策，因为快速决策可以减少低效率，等等。数据越接近它的来源，它被误解的可能性就越小——数据从创建它的地方到它被使用的地方所采取的每一步都会增加错误的机会，而最终用户（人或机器）认为数据代表的东西并不'不存在。时间在这方面发挥了作用，迫使围绕操作顺序和工作一致性进行协调。在这种情况下，切换到流式数据并不是因为它更快，而是因为您不再需要担心时间问题。2.SQL是从流数据中获得洞察力的好方法下面是流事件的物化视图的另一个例子。CREATEMATERIALIZEDVIEW实验ASSELECTexperiment_views.name,experiment_views.variant,COUNT(DISTINCT(experiment_views.user_id))asunique_users,COUNT(DISTINCT(conversions.user_id))asunique_conversionsFROMexperiment_viewsLEFTJOINconversionsONconversions.user_id=experiment_views.user_idANDconversions.created_at>experiment_views.created_atGROUPBYexperiment_views.name,experiment_views.variant;SQL并不特定于流处理——数据的含义在从流移动到数据库时不会改变，因此我们查询的方式也不应该改变。它的声明性本质提高了生产力——开发人员几乎不需要做出任何优化决策，尤其是与代码中的相同任务相比。SQL有一个额外的好处，它是一种成熟的语言，建立了30多年，围绕它有一个工具和教育生态系统。这意味着更多开发人员可以使用流数据并将其轻松集成到堆栈的其他部分。StreamingSQL的用例如今，任何已经在使用像Kafka这样的消息代理的人都可以毫不费力地开始使用StreamingSQL。未来，随着CDC软件的成熟，这一标准将扩展到“任何拥有数据库的人”。“以下是一些使用流式SQL的示例。商业智能和分析StreamingSQL是在决定“什么是使我们的内部团队能够根据数据做出明智决策的最佳方式”时要考虑的一个选项，权衡使其在某些情况下比其他情况更好。在许多情况下，使用流式SQL完成的主要源数据的物化视图是一个更简单的数据管道。除了实时数据的好处外，企业还可以通过这种方式避免以下问题。批处理中时间间隔和操作顺序的协调下一批运行前无法修复或测试的错误由于仪表盘加载缓慢导致停机时间长缓存、非规范化导致的不一致微服务使用StreamingSQL代替复杂数据协调和转换的代码在微服务中。像Kafka这样的事件流通常已经是微服务架构中的一等公民。工程师经常发现自己构建和维护使用Kafka的复杂应用程序。示例：应用程序从事件日志中读取以生成SaaS应用程序的API使用情况的见解和度量。微服务中任何看起来像查询的组件都可能被流式SQL取代。实时应用程序如果您的应用程序的价值取决于您实时提供更新和数据的能力，则StreamingSQL可能是构建昂贵或复杂的多组件堆栈的替代方法。新功能实时面向用户的分析——以前，只有LinkedIn和谷歌这样的科技巨头拥有规模和工程团队来构建实时面向用户的分析（如LinkedIn的“谁查看了你的个人资料”页面或谷歌分析的实时分析）。时间仪表板）。通过降低复杂性，StreamingSQL为更多公司打开了实时用户分析的魔力。业务自动化——一旦您拥有用于实时仪表板的流式SQL，一个自然的过程就是开始对相同数据做出自动化决策。（例如，如果您的电子商务网站的特定来源的流量激增，请在主页上添加促销信息）。总结Materialise提供了一种流式SQL实现，它在两个重要方面是独一无二的。在Materialise中，您可以使用与postgres兼容的SQL编写查询。我们认为构建这个系统的额外努力是值得的，因为只有具备这种级别的SQL兼容性，您才能获得与现有工具集成的好处，并消除高级流处理概念给用户带来的负担。查询引擎使用差异数据流在新数据进入时更有效地维护物化视图。
