2011年，MarcAndressen写了一篇名为《为什么软件正在吞噬整个世界》的文章。中心思想是，如果一个过程可以用软件实现，它就必须是。它已成为硅谷当前独角兽创业浪潮背后投资理论的简称。这也是我们今天看到的更广泛技术趋势背后的统一思想，包括机器学习、物联网、无处不在的SaaS和云计算。这些趋势中的每一个都在以不同的方式使软件变得更丰富、更强大，并扩大其在整个企业的影响范围。随之而来的变化很容易被忽视，但我认为同样重要。不仅仅是企业在使用更多的软件，而是越来越多的企业正在通过软件被重新定义。也就是说，企业执行的核心流程——从他们如何生产产品到他们如何与客户互动再到他们如何提供服务——正越来越多地在软件中指定、监控和执行。大多数硅谷科技公司已经是这种情况，但这种转变正在蔓延到所有类型的公司，无论它们提供什么产品或服务。为了阐明我的意思，让我们看一个例子：消费者银行的贷款审批流程。这是在计算机出现之前就存在的业务流程。传统上，这是一个需要数周才能完成的过程，涉及银行代理、抵押官员和信贷官员等，每个人都在手动过程中进行协作。今天，该过程倾向于以半自动方式执行，这些功能使用单独的软件应用程序来帮助用户更有效地执行它们。然而现在，在许多银行中，这种操作正在成为一个完全自动化的过程，其中信贷软件、风险软件和CRM软件相互通信并在几秒钟内提供决策。到这里，银行贷款业务单元基本变成了软件。当然，这并不是说公司会变成只有软件（即使在大多数以软件为中心的公司中也有很多人），只是整个业务都在使用软件来定义流程。企业不只是将软件用作手动流程生产力的附属物，他们还在代码中构建业务的整个部分。这种转变有很多重要的意义，但我关心的是它对软件本身的角色和设计意味着什么。在这个新兴世界中，应用程序的目的不太可能是提供UI来帮助人们开展业务，而更有可能触发操作或对软件的其他部分作出反应以直接开展业务。虽然这很容易理解，但它提出了一个大问题。传统的数据库架构是否适合这个新兴世界？毕竟，数据库一直是应用程序开发中最成功的基础设施层。然而，所有数据库，从最完善的关系数据库到最新的键值存储，都遵循一种范例，其中数据是被动存储的，数据库等待命令来检索或修改它。被遗忘的是，这种范式的兴起是由一种特定类型的面向用户的应用程序驱动的，在这种应用程序中，用户查看UI并启动转换为数据库查询的操作。在我们上面提到的示例中，很明显，关系数据库的构建是为了支持在这个1到2周的贷款审批流程中帮助解决人为因素的应用程序，但是，在基于不断查询不断变化的数据的实时贷款审批流程中的全套软件？事实上，值得注意的是，随着RDBMS（CRM、HRIS、ERP等）的兴起，软件时代的所有应用程序都是作为人类生产力辅助工具出现的。CRM应用程序使销售团队更有效率，HRIS使HR团队更有效率，等等。这些应用程序就是软件工程师所说的“CRUD”应用程序。它们帮助用户创建、更新和删除数据库记录以及管理流程上的业务逻辑。其中固有的假设是网络的另一端有人驱动和执行业务流程。这些应用程序的目标是向人们展示一些东西（他们会查看结果），向应用程序提供更多数据。该模式与公司采用软件的方式相匹配：逐步添加由人员执行的组织和流程。但数据基础架构本身不知道如何互连或对公司内其他地方发生的事情做出反应。这导致了围绕数据库构建的所有类型的解决方案，包括集成层、ETL产品、消息系统和大量代码，这些代码是大规模软件集成的标志。因为数据库不对数据流建模，所以公司内部系统之间的互连是一团糟。事件流的兴起当软件的主要作用不是为UI提供服务，而是直接触发操作或对软件的其他部分做出反应时，我们的数据平台需要哪些新功能？我想这个问题的答案要从事件和事件流的概念说起。什么是事件？发生的任何事情，包括用户登录尝试、购买、价格变化等。什么是事件流？持续更新的一系列事件，代表过去发生的事情和现在发生的事情。事件流为思考传统数据库中的数据提供了一种非常不同的范例。基于事件构建的系统不再被动地存储数据集并等待来自UI驱动的应用程序的命令。相反，它旨在支持数据在整个业务中的流动以及对业务中发生的每个事件的实时响应和处理。这似乎与数据库领域相去甚远，但在我看来，数据库的一般概念对于未来的发展来说太狭隘了。ApacheKafka及其用途通过分享我自己的背景，我将概述一些事件用例。Confluent的创始人最初在LinkedIn工作时创建了开源项目ApacheKafka，近年来Kafka已成为事件流运动的基础技术。我们的动机很简单：虽然LinkedIn的所有数据都是通过24/7永无止境的过程不断生成的，但利用这些数据的基础设施仅限于缓慢的大批量数据转储和每天结束时的简单查找。“一天结束时批处理”的概念似乎是旧时代穿孔卡和大型机的遗留物。事实上，对于一家全球性企业来说，没有一天结束的概念。显然，当我们投入到这个挑战中时，这个问题并没有现成的解决方案。此外，在构建NoSQL以支持实时网站之后，我们知道分布式系统研究和技术的复兴为我们提供了一套工具来以过去不可能的方式解决这个问题。我们注意到关于“流处理”的学术文献，这是一个将数据库存储和数据处理技术扩展到静态表之外的研究领域，并将其应用于这种连续的、永无止境的数据流，这种数据流在LinkedIn等数字业务的核心。我们都熟悉这个古老的问题：“我们到了吗？”传统数据库有点幼稚，除了不断提问之外没有其他方法可以回答这个问题。通过流处理，ETA成为连续计算，始终与问题的位置同步。在社交网络中，事件可以表示点击、电子邮件、登录、新连接或个人资料更新。将这些数据视为持续不断的数据流，使其可供LinkedIn的所有其他系统访问。我们的早期用例涉及填充LinkedIn的社交图、搜索、Hadoop、数据仓库环境，以及面向用户的应用程序，如推荐系统、新闻提要、广告系统和其他产品功能。随着时间的推移，Kafka的使用扩展到安全系统、低级应用程序监控、电子邮件、新闻提要和数百种其他应用程序。这一切都发生在如此大规模的需求背景下：每天有数万亿条消息流经Kafka，成千上万的工程师围绕它展开工作。在我们开源Kafka之后，它在LinkedIn之外广泛传播，类似的架构出现在Netflix、Uber、Pinterest、Twitter、Airbnb等。自从我在2014年离开LinkedIn开始Confluent以来，Kafka和事件流已经开始在硅谷科技公司之外获得关注，从简单的数据管道转向直接为实时应用程序提供动力。如今，一些世界上最大的银行将Kafka和Confluent用于欺诈检测、支付系统、风险系统和微服务架构。Kafka是Euronext下一代证券交易平台的核心，处理整个欧洲市场的数十亿笔交易。在零售行业，Walmart、Target、Nordstrom等公司都采用了Kafka。项目包括实时库存管理，以及电子商务和实体设施的整合。零售业传统上建立在缓慢的日常批处理之上，但来自电子商务的竞争推动了集成和实时化。包括特斯拉和奥迪在内的几家汽车公司已经为其下一代联网汽车构建了物联网平台，将车辆数据建模为实时事件流。他们不是唯一这样做的人。火车、轮船、仓库和重型机械也都开始在事件流中捕获数据。从硅谷开始的现在已成为主流，成千上万的组织使用Kafka，其中包括60%的财富100强。事件流作为中枢神经系统这些公司中的大多数最初采用Kafka来启用单个可扩展的实时应用程序或数据管道对于特定的用例。这种最初的使用通常可以迅速传播到公司内的其他应用程序。这种快速传播的原因是事件流有多个读者：一个事件流可以有任意数量的“订阅者”，他们可以处理、响应或回复它。以零售为例，例如，零售商可能会针对单个用例捕获商店中发生的销售流，以加快仓库管理。每个事件都可能代表与销售相关的数据：售出的商品、售出商品的商店等。但是，虽然使用可能从单个应用程序开始，但相同的销售流程对于定价、报告、折扣系统和许多其他用例至关重要。事实上，在全球零售业务中，有数百甚至数千个软件系统来管理业务的核心流程，包括库存管理、仓库运营、运输、价格变更、分析和采购。有多少核心流程会受到销售产品这一简单事件的影响？答案是很多或大部分，因为销售商品是零售业最基本的活动之一。这是采用的良性循环。第一个应用程序带来了它的关键数据流。新的应用程序加入平台以访问这些数据流并带来自己的数据流。数据流导致应用程序，应用程序导致更多数据流。其核心思想是事件流可以作为所发生事件的记录进行处理，并且任何系统或应用程序都可以实时利用它来做出反应、响应或处理数据流。这具有非常重要的意义。在公司内部，通常是一堆相互连接的系统，每个应用程序都临时连接到另一个。这是一种非常昂贵且耗时的方法。事件流提供了另一种选择：可以有一个支持实时处理、查询和计算的中央平台。每个应用程序都可以发布与其业务部分相关的流，并以完全解耦的方式依赖于其他流。为了推动内部连接，事件流平台充当新兴软件定义公司的中枢神经系统。我们可以将独立的、以UI为中心的离线应用程序视为软件世界中的一种单细胞有机体。一个综合性的数字公司不能通过简单地堆叠许多这些单细胞动物来形成，就像一只狗不能从一堆未分化的变形虫中创造出来一样。多细胞动物有一个神经系统，可以将所有单个细胞协调成一个整体，可以对它在其任何组成部分中遇到的任何事情做出反应、计划和立即采取行动。数字公司需要与这种神经系统相当的软件来连接他们所有的系统、应用程序和流程。这让我们相信，这个新兴的事件流平台将成为现代企业最具战略意义的单一数据平台。事件流平台：数据库和数据流必须结合在一起做好这件事不仅仅是管道胶带公司为临时集成而构建的生产问题。这还不足以满足现状，更不用说新兴趋势了。需要的是一个实时数据平台，它可以将数据库的全部存储和查询处理能力结合到一个现代的、可水平扩展的数据平台中。对该平台的需求超出了对这些事件流的读写。事件流不仅仅是关于正在发生的事情的简短、有损的数据喷射，它是对企业从过去到现在发生的事情的完整、可靠、持久的记录。要充分利用事件流，需要一个实时数据平台来存储、查询、处理和转换这些流，而不仅仅是短暂事件数据的“哑管道”。将数据库的存储和处理能力与实时数据结合起来似乎很奇怪。如果我们把数据库看作是一种容器，里面存放着大量的被动数据，那么事件流似乎离数据库的领域还很远。然而，流处理的思想却颠覆了这一点。如果我们将公司内部发生的任何事情的流视为“数据”并允许对其处理、响应和反应进行连续“查询”，会发生什么情况？这导致了一个根本不同的数据库功能框架。在传统的数据库中，数据处于被动状态，等待应用程序或人发出它响应的查询。在流处理中，这个过程是相反的：数据是一个持久的、活跃的事件流，被馈送到一个被动查询中，该查询简单地反应和处理数据流。在某些方面，数据库在其内部设计中展示了表和事件流的双重性，如果不是它们的外部特征的话。大多数数据库都是围绕提交日志构建的，它充当数据修改事件的持久流。通常这些日志只是传统数据库中的一个实现细节，查询无法访问。然而，在事件流的世界中，这些日志和它们填充的表需要是一等公民。然而，整合这两件事的原因不仅仅是基于数据库内部。基本上，应用程序使用存储在表中的数据对世界上发生的事件做出反应。在我们的零售示例中，销售事件影响库存事件（数据库表中的状态），库存事件影响再订购事件（另一个事件！）。整个业务流程可以通过以菊花链方式连接这些应用程序和数据库交互、创建新事件同时改变世界状态（减少库存数量、更新余额等）来形成。传统数据库只支持这个问题的一半，剩下的一半嵌入在应用程序代码中。诸如KSQL之类的现代流处理系统正在将这些抽象集合在一起，开始跨事件和传统存储表做数据库需要做的事情，但事件和数据库的统一只是运动的开始。Confluent的使命Confluent的使命是构建这个事件流平台，并帮助企业围绕这个事件流平台开始重构自己。甚至在公司诞生之前，创始人和许多早期员工就开始从事该项目，并一直持续到今天。我们构建平台的方法是自下而上的。从帮助Kafka的核心可靠地大规模存储、读取和写入事件流开始。然后我们将堆栈向上移动到连接器和KSQL，使事件流变得简单易用，我们认为这对于构建新的主流开发范式至关重要。我们已将此堆栈作为软件产品和主要公共云提供商上的完全托管云服务提供。这使得事件流平台在企业运营的整个环境中可用，并跨所有环境集成数据和事件。整个生态系统有大量机会建立在这个新的基础设施上：从实时监控和分析到物联网、微服务、机器学习管道和架构、数据移动和集成。随着这个新平台和生态系统的出现，我们相信它可以成为通过软件定义和执行业务的公司转型的重要组成部分。随着它逐渐成为这个角色，我认为事件流平台将在范围和战略重要性上与关系数据库相提并论。在Confluent，我们的目标是实现它。作者介绍了JayKreps，他是Confluent的CEO和ApacheKafka的联合创始人。他是LinkedIn的高级架构师。
