【原】数据库和流式数据处理：整合的未来

　　数据库和流处理：整合的未来；刚哥带你参加国际顶级技术会议-QCon London 2021

　　

　　这次，我给大家带来的是在QCon London 2021，最近Confluent正式在纳斯达克上市，市值114亿美元。本文来自Confluent公司CTO Ben Stopford 在去年QCon 伦敦作的数据库和流处理的主题演讲。

　　

　　

　　著名的硅谷投资人Marc Andreessen说“软件最终会吞噬世界”。如果您是投资者，您可能想投资软件，因为随着时间的推移，我们将消费更多的软件。事实上，如果你仔细想想，这有几种不同的形式。这就像弱形式，就像我们作为一个行业只是消耗更多软件的基本思想。实际上有这种强大的形式。强形式很有趣，因为在这种特殊的思考方式下，我们的业务实际上变得更加自动化。这不仅仅是我们购买更多软件，公司消耗更多软件，更多的是实际采用我们的业务流程并使用软件将它们自动化。这有点抽象。那是什么意思？

　　

　　想想像贷款处理申请这样的事情。这个过程几乎 100 年都没有改变。有信贷员，有风险员，有信贷员。他们每个人在这个过程中都有自己的特定阶段。我们有一些软件可以提高效率，公司在编写或购买软件时会拥有这些软件，这使得每个部分都变得更好。帮助信贷官更好地完成工作，或帮助风险官更好地完成工作。这是这种类比的弱形式，或者购买更多软件来帮助这些人做得更好。

　　

　　

　　如今，您实际上可以在几秒钟内获得贷款申请。传统的抵押贷款可能需要几周时间，因为它遵循手动驱动的流程。今天，在这些更现代的应用程序中，对于现代公司来说，您可以将整个事情自动化。这仍然是使用软件，但它以不同的方式使用软件。它使用的软件可以有效地与其他软件对话，因此您可以在几秒钟内非常快速地自动化获得贷款的过程。

　　

　　如果您考虑这对于我们构建的系统架构的实际意义，如果您想帮助信贷员更好地完成工作，这就是三层架构的用武之地。我们有我们的用户，他们与用户界面，有某种后端服务器应用程序在它后面运行，还有一个数据库，你在帮助用户，比方说，更有效地进行风险分析，或者其他任何可能的分析。

　　

　　随着公司变得更加自动化，并且这些业务流程变得更加自动化，我们最终会在服务之间相互交流。这就像软件与软件对话。它不太关注专门帮助一个人，而更关注通过不同的软件实现某些最终的业务目标。

　　一个很好的例子是出租车，拼车应用程序。在这些应用中，实际上处理的是事件流。客户端和出租车司机端的两部电话都具有 GPS 信息，这些信息正在流回服务器端应用程序。您有许多不同的服务在后端运行。他们正在做地理空间匹配来尝试确定他们应该向哪些出租车发送警报，询问他们是否想要乘车，缓冲响应以确定哪个是特定用户最有效的驱动程序等。

　　

　　软件系统的演变

　　你在软件架构的演变中看到了同样的事情。从单体到分布式单体到微服务。这些都是——当然是后两个——涉及分发或处理的实现，但它主要关注用户。它主要集中在用户界面上。实际上，存在于微服务架构中的数据实际上通常在前端连接在一起。用户界面实际上是在与一堆不同的服务对话。前端实际上在执行该连接，因为它向用户显示页面的不同部分。

　　当您想要更多以数据为中心的东西时会发生什么？这就是您倾向于进入事件驱动的微服务的地方。在这种模式中，您仍然拥有用户界面，您仍然拥有响应这些的服务器端程序，但是您正在记录事件，然后允许您将架构和流程分离，执行许多机制，这使得业务工作异步。你有那种以用户为中心的一面，然后我称之为以软件为中心的一面。我们实际上是在使业务自动化，我们正在发展一个架构。

　　我为什么要告诉你这一切？这种趋势导致了这样一种想法，即未来软件的用户可能会越来越多，不仅仅是你和我，不仅仅是应用程序的用户，而且实际上是与其他软件对话的软件。

　　

　　这对数据库意味着什么？

　　这对数据库意味着什么？想一想，想想什么是数据库。你们都用过数据库。我敢肯定，你们中的许多人每天都在使用它们。当然，你们都会在某个时候使用它们。使用数据库是什么感觉？你写了一个查询，远处某处有一些服务器。它有很多关于它的数据。您可以编写此查询，它允许您回答问题。你永远无法自己回答这个问题，因为数据太多，你的大脑无法通过它。你可以把这个问题发送出去，你就可以得到答案。太棒了。这真是一个强大的想法。当我想到数据库时，这就是我的想法。我没有花很多年时间构建和使用数据库。

　　我们今天实际上有数百个这样的东西。我们都有同感。我们有许多不同的变体，像 Cassandra 这样的变体可以让您根据它使用的内存量存储大量数据。 Elasticsearch 之类的东西为您提供了一个非常好的、丰富的交互式查询模型。 Neo4j 会让你做一些事情，比如查询、实体之间的关系，而不仅仅是实体本身。 Oracle 或 PostgreS 之类的东西是主力数据库，可以变形为不同类型的用例。数百种不同的东西，它们都有略微不同的变体，使它们更适合某种类型的用例。

　　

　　

　　他们都有几个基本假设。主要问题之一是数据是被动的。他们只是坐在数据库上等着你做点什么。数据库作为一种软件实际上是为了帮助你而设计的，它实际上是一种技术，因为它成长于我们构建旨在帮助用户的应用程序的时代，无论是你还是我，还是信贷员或风险官，或者其他什么。如果没有等待的用户界面，如果没有人坐在那里点击按钮并期待事情发生，您必须问一个问题，它是否必须同步？

　　

　　一种替代方法是使用事件流，就像使用不同的方法一样。流处理器是一种技术，它允许我们以与数据库操作文件中保存的数据的方式非常相似的方式操作事件流。重要的是，它们是为活动数据而构建的，并且它们是为异步而构建的。让我们对这意味着什么进行分类。如果你考虑一个流处理器，它实际上有一个非常不同的交互模型。

　　

　　正是因为这个交互模型，我们从数据库中获得的这个非常熟悉的交互模型。对于流处理器，我们并没有真正做到这一点，因为流处理器并不是真正为我们设计的。对于传统数据库，查询是主动的，数据是被动的。那是什么意思？这意味着这是关于启动行动的原因，是什么使事情发生。在数据库中，您通过运行查询来使事情发生，数据只是被动地坐在那里等待您运行该查询。如果您正在泡一杯茶，那么数据库什么也不做，它什么也不做。您必须实际启动该操作。

　　

　　在流处理器中，并最终在处理中，情况正好相反。查询是被动的。查询就在那里，它不会改变，因为它永远运行，它只是坐在正在运行的服务器上。让它做某事的不是有人运行查询。它是数据，是世界上正在发生的一些事件，是其他系统发出的东西，或者可能是什么。这是一个非常不同的交互模型。

　　流还是表

　　考虑到这一点，我想更深入地挖掘我们在流处理器中拥有的一些基本结构，并比较它们与数据库的具体关系。可能最基本的是流和表的概念。因为我认为流以多种方式定义了流处理器或事件流系统的作用。流处理器处理事件。这听起来是一个非常简单的想法。事实上，这是一个非常简单的想法。我们可以根据许多事件记录世界上发生的事情。这可能是某人下订单，可能是他们正在购买一条裤子，这可能是您为这条裤子付款，也可能是更改客户详细信息。它实际上可能是您手机的位置，因此是另一种连续的事件流。它实际上可能是一大堆不同的事情，一个事实的记录，一些发生的事情。

　　

　　实际上作为数据模型的事件略有不同。因为它们包含了意图告诉您状态更改的概念，而不仅仅是状态。以典型的 LinkedIn 为例，如果 Bob 在 Google 工作，那么这就是 Bob 在某个时间点的状态。事件是Bob已经从谷歌转移到亚马逊。这实际上不同的原因是，通常当我们驱动处理时，我们驱动我们的应用程序，我们不只是想要状态，我们还希望被状态更改触发，这个意图。流处理器总是转发这些事件，这个意图，这个事情发生的事实，以便你可以对它们做出反应。

　　

　　流是准确记录发生了什么、发布了什么，通常是在一个主题上。一个表代表当前状态。正是这种记录绝对发生的每一件事的想法，都记录在流中。如果你们中的任何人曾经使用过事件溯源，那么这是一个非常相似的概念，这个想法是我们将每一个状态变化都记录在日志中。如果我们想导出当前状态，可以通过重放流来实现。该信息流告诉我们我们去过哪里与现在在哪里，或者您已支付的款项与您的账户余额。

　　

　　我真正喜欢思考的一种方式是思考，让我们使用国际象棋，这是一个很好的类比。我可以将数据库表视为每个部分的位置。所以我可以选择每个部分的位置，这告诉我我目前的状态。如果我愿意，我可以将它存储在某个地方并重新创建它。 Stream 以相反的方式工作。它从国际象棋开始时的起始位置取一系列事件，然后我们可以重播所有移动、事件、状态变化，使我们进入相同的位置。 Streams 不仅告诉我们某个时间点的董事会位置。他们还告诉我们游戏的情况，并告诉我们我们是如何得到它的。

　　

　　这和数据库有什么关系？我们实际上可以将流视为一种表。实际上，没有真正的理由称它为流。我们稍后会谈到。流绝对可以被认为是一种表。这是大多数数据库中不存在的一种特殊类型的表。它是不可变的。你不能改变它。它是仅附加的。在表中，我可以插入、更新和删除。这是可变的，它有一个主键的概念，这也很重要。

　　

　　流可以被视为不可变，仅追加数据的表。如果我写了一个值，它会自动被永远记录下来。我不能回去改变它。我无法更改它的原因是因为它可能已被其他人使用。如果我想更改它，我必须制作另一条记录，编写另一条消息，然后实际上会传播该更改。这就是为什么不变性如此重要的原因，它允许我们通过一系列事实重新创建状态。流处理器通过流进行通信。输入流，转到输出流。

　　

　　

　　在内部，流处理器，即使该模型是流到流，但在内部，它们使用表。这实际上有点像数据库中的方式。数据库在运行查询时，实际上使用这些临时表来保存进行计算时的中间结果。看不到它们，它们是暂时的。在流处理器中，它们不是临时的，因为流查询会永远运行。对于每个用户，每个请求，它的运行方式并没有不同。这就像一个并发运行的查询。它确实包含这种表格的概念。

　　

　　在这种情况下，我收到了付款。在左侧，有一个付款流。然后我正在运行一些信用评分功能。这将基本上破坏支付流，我们可以将其视为支付表，并按用户汇总，以便每个用户都有一个信用评分。我的表实际上比我的输入流小。然后流处理器侦听该表并将输出作为另一个流提供。当我们使用流处理器时，我们创建表，我们只是没有真正向任何人展示它们。因为我们要做的是读取数据流和输出数据流。

　　

　　这导致了这种二元性，这种流表二元性，其中流代表历史。每一个状态变化都发生了。我可以应用投影，它可以像按键分组一样简单，这基本上只涉及为每个键创建一个具有最新版本的表，这是大多数人在使用数据库时认为的表。然后同样地，您可以监听一张表，聆听其中发生的所有变化并创建另一个流。如果您的表正在使用聚合，那么该流将与您开始使用的流不同，因为您丢失了数据，但您可以同时维护这两个流。你有这种二元性。流可以转到表，表可以返回到流。

　　

　　这实际上与物化视图的概念非常相似。物化视图是一种在许多数据库中可用的结构，尤其是关系数据库，它来自于 1990 年代流行的活动数据库的想法。有几个很大的不同。流处理器，我们有一个流，我们的输入是一个流，我们有我们的聚合函数或逻辑或任何可能的东西，这将创建我的表。然后将其作为流输出到另一个应用程序，因此另一个应用程序可以对此做出反应。那是异步的。该查询基本上是一个推送查询。它一直在运行，并且正在创造新的结果。

　　一个活动数据库，输入是一张表。我们有一张表。请记住，这两件事可能是相似的。我们可以创建一个只能追加的表和数据库。然后我们有一个运行的函数，创建我们的信用评分。然后如果我们想与之交互，我们必须发送一个查询并得到一个结果，因为它是一个数据库。在这种情况下，有两个很大的不同。创建物化视图的整个过程是同步的。锁定在数据库内部，通常在事务内部。交互模型是池查询。这代表了一个非常相似的概念。只是我们与它交互的方式和数据移动的方式不同。物化视图和流过程之间的巨大相似性。

　　Join

　　让我们看看连接。连接是这些东西有点像的另一种方式。流处理器可以做连接，数据库，大部分可以做连接，或者很多都可以做连接。这些东西是完全相同还是略有不同？在大多数情况下，它们非常相似，但让我们看看连接在流处理器中是如何工作的。有几种不同类型的连接。我们将从连接到表开始。

　　

　　这是一个非常简单的想法。我们有一个订单流进入这里，还有一个客户流将在这个表中具体化。我们将用一些客户信息来丰富每个订单。那就是我们的流处理器。基本上，订单进来了，我们根据这个主键在表中进行查找。这个表，背后其实有一个事件流，它必须有效地按键做一个组来物化表。然后我们得到的是一个订单连接到它的客户信息。这很简单。这实际上几乎正是数据库所做的。数据库从文件中读取数据，从订单表中读取订单。您没有索引，可能是客户信息，也可能是该表上的主键。它只会在查询中查找值。这两件事的工作方式非常相似。数据库的最大区别在于数据库了解它所获得的数据。我可以维护我的统计数据和告诉你这些数据基数的东西。这有助于您决定是否使用索引之类的东西。在流处理器中，您通常不知道接下来会发生什么，因为它就像实时数据。您无法真正进行这些优化。

　　

　　

　　

　　

　　

　　

　　

　　连接两个流回事怎么样？那有点不同。关于流的事情是你对它知之甚少。我们可以对那个表进行索引，我们可以给它一个主键。对于流，情况并非如此。在这种情况下，它的工作方式是，我们有 Bob 的订单，Bob 和 Jill 有订单，我们有付款，我们将订单加入付款。也许Bob买了一些裤子然后他付款了，我们想把它们整理在一起。因为系统是异步的，所以这些东西可以重新排序。它们基本上可以重新排序并迟到。实际上，Bob 的订单落后于 Bob 对 Jill 的付款。

　　当这些事件进入流处理器时，会发生 Bob 的付款进入并缓存在一个小索引中。Jill的订单也进入自助餐，Jill的付款进来了。我们可以做一个匹配。每次处理这些时，它都在寻找相应的一侧或另一侧的相应事件。它实际上也在检查事件时间，它使用事件时间来处理它。我们稍后会回到这个话题。然后Jill的付款作为一个联合出来。只有当这两种东西都可用时，我们才能真正得到输出。哪个先来或最后来并不重要，更重要的是。这就是实际获得输出的要点。然后同样，Bob 的订单以匹配的形式进入并发送出去。

　　这与数据库有点不同的原因是它实际上使用了一些东西。一是您只缓冲了这么多数据，这意味着您可以处理这些吞吐量非常高的用例，在这些用例中，您不想在表中维护整个数据集并对其进行索引和即时查找。另一个原因是这些流通常是历史记录，它们就像一个历史表——保存特定事件的所有不同版本。如果 Bob 买了一条裤子，然后他决定更改订单，那么对于同一件事，您实际上会拥有一组不同的订单或订单的不同版本。在这种情况下，可能就像从 Boots 更改为 Boots2。我们实际上从这个流中的同一实体得到了多个不同的值、多个不同的状态变化。我们只是把它当作一张表。我们得到这个笛卡尔积。那会非常低效，你会一直得到大量数据。

　　

　　流进程通过允许我及时关联事物来处理这个问题。这就是窗口的由来。我们可以使用时间窗口来基本上限制我们将如何连接数据集。如果我们想及时关联这两件事，而且还想通过它们的标识符来关联，我们可以使用窗口来做到这一点。在数据库中很难做到这一点。

　　所以我们有这样的想法，即在流处理器中包含及时关联最近事件的能力。在数据库中您无法真正做到的事情。你实际上做了很多更高级的版本。会话窗口是另一件有趣的事情，在数据库中也很难做到。一个会话就像，你就像在你的网站上寻找裤子，然后也许你买了一些，然后你就走了。您只想检测一些然后结束的活动时期。会话窗口允许您这样做。它没有定义的长度，它只是持续一段时间，然后当有一段时间不活动时，它会动态结束。

　　

　　另一件事是迟到和乱序的数据，因为事情显然发生了变化。我们在流处理中谈论的一件事是，很难确定某事的结束位置、某事何时结束、一天何时结束、计算何时结束。在流处理中，您实际上可以使用窗口函数来创建您发送的输出。然后你实际上是在使用时间来关联什么时候有东西进来，它应该进入哪个窗口。你有这个历史概念，你可以更新以前的窗口。这使您可以处理迟到和无序的数据。

　　

　　流处理器提供了一堆工具让我们处理异步性。它使我们能够利用时间。任何分布式系统中的时间都难以计算或难以推理。这个概念中的时间，在流处理中，可以有系统时间、有效时间或流时间，也可以有事件时间，也就是事件实际由客户端创建的时间。您可以将系统配置为使用任何一种。他们让你利用时间，然后他们也让你专注于现在。流处理器是为这种处理而设计的，它是关于实时事件的。他们有点相似。连接工作的方式有相似之处，但也有一些差异。

　　数据放置

　　数据放置呢？流处理器使用两层存储模型，其中大部分。不同的人使用的方法实际上略有不同，但它们都非常相似。存储通常在流系统中，例如 Kafka。 Flink 实际上也使用类似 Kafka 的东西，可能还有用于快照的 HDFS。实际上，我们可以将其视为一些分布式存储层。然后流在到达时被处理，因为存储层不仅仅是一个文件系统，尽管 Kafka 实际上在架构上看起来很像一个分布式文件系统。实际发生的事情是至少在概念上是向你推送数据。

　　

　　您可以实时对流做出反应。如果要创建表，则需要将它们Materialize。这实际上是在流处理器内部完成的。如果您有一个客户表，它实际上将在流处理器本身内Materialize。这实际上与数据库的工作方式非常相似。如果你看像Snowflake这样的东西。 Snowflake 有一个后端，它是分析引擎，它在本地实现表，因此它可以进行高效的弹性处理。

　　

　　数据也是分区的。它实际上分为两个不同的层次。您正在存储级别进行分区。 Kafka 将数据存储在一堆不同机器上的一堆不同分区中。如果我有一些订单数据集，它实际上将分布在所有这些机器上。同样在处理层，我们还将数据分布在不同分区或分片中的多台不同机器上。这使我们能够并行处理事物。但是，这样做的大问题或问题之一是，如果您想加入事物，则必须以相同的方式对其进行分区。如果您想将订单加入付款，您必须确保它们共享一个密钥，以便订单和付款对应，或者与同一订单对应的付款最终出现在正确的机器上。您可以通过应用密钥来完成此操作。如果您没有正确的密钥，或者您之前的处理没有使用正确的密钥，则您必须进行洗牌，重新分配数据，这相对昂贵。同样，这与分布式数据库使用的过程相同。

　　

　　分布式数据库使用的另一件事是广播数据， 将数据集广播到所有节点。这实际上是为了避免洗牌的问题。在分区数据模型中，如果要从不是之前操作中使用的键的键做连接，则必须重新洗牌。您可以使用广播Join。有不同的方法可以做到这一点。在 Kafka Streams 和 ksql 中，有一个叫做全局表的东西。这将创建数据集的副本。假设我想将订单加入客户。订单是一个大的事实数据集，相比之下，客户相对较小，通常也不会那么频繁地变化。我们实际上广播了所有节点。我可以拥有订单的分区数据和复制的数据，每个处理节点上都有相同的副本，这样我就不会“不必进行洗牌。我可以有效地进行更多连接。

　　

　　在架构上，实际上与数据仓库有很多相似之处。这种事件和事实的想法非常相似。它们通常几乎相同。记录发生的每一件事。维度是您要查找的这些内容。客户信息，账户信息，这种东西，比较少。实际上，支持它的许多技术是模式处理查询，并以不同方式将数据分发到不同节点，两者实际上是相同的，两者之间非常相似。

　　交互模型

　　最后，我们得到了交互模型的概念。我们之前讨论过这个问题。流处理器使用事件流连续处理输入到输出。这就是你与它互动的方式。它与您与数据库交互的方式非常不同。查询持续运行，并在结果发生时立即输出。传统数据库，查询是主动的，数据是被动的。在事件流中，数据是主动的，查询是被动的。

　　

　　数据库具有池查询的这种概念。这就是我们所说的池查询。 Ben 现在的信用评分是多少？我问了一个问题，然后我得到了结果。在流处理器中，进程一直在运行，每次表在内部发生变化时，我们都会发布结果。我们可以创建这两者的混合体。为什么我们只需要一个？这就是我们认为事情正在发生的地方。

　　

　　在混合流处理器中，有几件事是不同的。首先，交互模型不仅处理查询、响应请求，还处理事件流。我可以有一个支付流进来，我可以再次计算我的表。我可以总结并具体化这些信用评分。因为那是一张表，所以实际上没有什么可以阻止我查询它的地方。我可以发送一个选择语句，得到响应。同时，我还可以聆听该表发生的变化。我可以同时拥有两种交互模型。

　　

　　我认为我们最终会得到一个统一的模型。它确实管理了两个很大的差异。还有比这更多的东西。我们讨论了不同类型的关节之类的东西。从根本上说，两个大的区别是处理异步和同步，以及拥有一个主动和被动的交互模型。

　　

　　这实际上是什么样子的？其实，这很简单。请记住，我们实际上可以将流视为具有不同交互模型的表。然后我们可以使用 SQL 运行查询。标准数据库查询基本上只是从最早的数据位开始运行。它运行从开始到现在。然后它停止。它给你答案。这就是我们都习惯的查询模型。

　　

　　标准流处理查询。那现在开始。它不考虑以前的数据，除非我要求或可以这样做，否则它可以及时返回并重新处理所有内容。我们可以根据需要将所有数据存储在 Kafka 中，但这不是必须的。通常，它会立即启动并永远运行。只是永远运行。

　　

　　还有另一个交互模型，就像这个仪表盘查询。在这方面，我们从最早的记录开始，我们一直查询到现在，但实际上会继续前进，永远继续前进。我称其为仪表板查询模型，因为它有点像将数据加载到仪表板中，然后使其保持最新状态。这实际上有点微妙，因为当您执行初始查询时，您实际上返回了什么？您是否只返回从现在开始的快照，即表中每个键的最新版本？或者您返回所有事件，还是某种组合？因为未来的数据必须一次出现一个事件，或者至少在您的窗口函数是。

　　

　　我们有这些不同的交互模型，但是对于我们实际上可能想要如何表达该数据存在某种微妙之处。我们可能想要一个快照，我们可能想要过去发生的每一个状态变化。我们把它们放在一起，你就得到了这个统一的模型，你有最早到现在、最早到永远、现在永远来表示不同类型的查询。我们可以用 SQL 来表示这些。我们的推送查询看起来像常规 SQL、SELECT user、credit_score、orders 等，WHERE ROWKEY='bob'，但我们必须有这个 EMIT CHANGES。我们基本上将执行查询，然后继续为您提供额外的结果。或者您可以只执行标准的拉取查询。在标准的拉式查询中，我们实际上只是要问一个问题，然后我们将得到答案。

　　

　　这就是交互模型的内部。那是一部分。另一部分是这种拥抱同步性的想法。这是我们认为需要改变的另一件事，或者认为越来越多的事情将会改变。在异步世界中，如果您回想一下微服务方面，我们将把这些不同的东西、系统的不同部分连接在一起的想法。我们经常希望异步执行此操作以自动化您的业务流程。不同的微服务想要有不同的生命周期，它们想要解耦等等。我们实际上希望能够跨不同的进程进行编排。我们可能想从数据库中提取数据，将其推送到事件流中，执行一些处理，将其推送到应用程序中，也许进入 lambda 函数或其他东西。管道的这种想法实际上是理想情况下我们希望能够与这种交互模型一起接受的东西。拥有管理这种异步世界所需的那种连接/聚合/时间处理。

　　

　　另一件事是交易。数据库中的事务实际上是非常不同的。与流处理器中的事务完全不同。在数据库中，当您实际更改或读取数据时，实际上您有两阶段提交协议。在异步系统中，您实际做的是通过障碍。屏障流经系统内部的各种不同操作。这些障碍实际上是提交的，还有一个两阶段提交协议。它基于流经这个系统的这些障碍。这就是您基本上可以管理事务的方式，以一种原子方式管理对各个不同地方的更新，使用异步处理系统。我们有一个同步管道。

　　我想提一下其他几个重要的变体。今天的流处理器，大部分其实都是框架。 Flink 有一个 SQL API，Kafka Streams 有 KSQL。还有其他一些进行基于 SQL 的处理。我们绝对认为这是谈论数据的正确方式，您通常希望使用声明性语言谈论数据。这是数据库肯定会做对的一件事。其中很多实际上是基于JVM的编程框架。其中大部分是基于JVM的。这实际上给了你很大的力量。你可以写任何你想要的东西，你可以直接与这些表交互，你可以构建不同类型的应用程序。

　　另一方面是活动数据库也通过 MongoDB、Couchbase、RethinkDB 之类的东西得到了改进。这些让您可以监听表上的更改流，这同样非常相似。它们没有那种时间函数或同步处理和创建您在流处理器中获得的物化视图。这绝对是一条正在进行的整合之路。我想我们会看到更多。

　　

　　随着软件吞噬世界

　　一开始，我们谈到了软件正在吞噬世界的想法，而今天的软件用户，随着我们的业务流程的自动化，随着时间的推移不太可能成为用户，不太可能只是你和我。它实际上更有可能是我们在一些自动化架构中缝合在一起的其他软件。为此，我们认为您需要两者兼而有之。这是异步和同步。您需要能够处理这两件事。您还需要这些不同的交互模型，您需要能够查询被动数据集并为点击按钮并期待事情发生的用户获得答案。您还需要这种主动交互模型，其中数据已作为事件流推送到不同的订阅服务。我们仍然需要所有这些。仍然需要所有这些不同类型的数据库，但我们可能会看到这种转变发生，我们开始在这些活动数据库周围形成不同的利基，ksqlDB 就是一个例子。您实际上看到数据库社区中的其他运动朝着相同的方向发展，尤其是围绕活动数据库。

　　

　　我对您的最后想法是，如果你们中的任何人确实闭上了眼睛，即使您只是比喻性地这样做，并且您考虑了数据库对您的意义，您考虑了如何与数据库交互。也许这些事情会改变。那个概念也是如此，我们如此珍视的那个东西，数据库是什么的想法也是如此。也许它需要与今天的情况略有不同。