在 2011 年，Marc Andressen 寫了一篇文章，題目是《為什么軟件正在吞噬整個世界》。其中心思想是如果流程可以通過軟件來實現(xiàn)，那么就一定會實現(xiàn)。這已經(jīng)成為一種投資理論簡略的表達方式，這種理論隱藏在硅谷目前獨角獸初創(chuàng)企業(yè)浪潮的背后。它還是我們?nèi)缃窨吹降母鼜V泛的技術(shù)趨勢背后的統(tǒng)一思想，這些技術(shù)包括機器學習、物聯(lián)網(wǎng)、無處不在的 SaaS 以及云計算。這些趨勢都在用不同的方法使軟件變得更豐富和功能強大，并在企業(yè)間擴大其影響范圍。

我認為，伴隨而來的變化容易被忽視但同樣重要。這不僅僅是企業(yè)使用更多的軟件，而且越來越多的企業(yè)通過軟件重新定義。也即，企業(yè)執(zhí)行的核心過程（從生產(chǎn)產(chǎn)品的方式到與客戶交互的方式、交付服務(wù)的方式）正變得越來越多地在軟件中指定、監(jiān)控和執(zhí)行。這已經(jīng)是大多數(shù)硅谷技術(shù)公司的事實情況，但是，這種轉(zhuǎn)變正在蔓延到所有類型的公司，無論其提供什么產(chǎn)品或服務(wù)。

為了澄清我的意思，讓我們來看一個例子：消費銀行的貸款批準流程。這是一個在計算機出現(xiàn)以前就存在的業(yè)務(wù)流程。傳統(tǒng)上，這是一個需要幾個星期才能完成的流程，其中涉及銀行代理人、抵押貸款官員和信貸官員等，各自以手動過程進行協(xié)作。如今，該流程趨向于以半自動化的方式執(zhí)行，這些功能都有一些獨立的軟件應(yīng)用程序，可以幫助使用者更有效地執(zhí)行。

然而現(xiàn)在，在很多銀行中這個操作正在變?yōu)橐粋€完全自動化的流程，其中信貸軟件、風險軟件和 CRM 軟件之間相互通信并在幾秒內(nèi)提供決策。這里，銀行貸款業(yè)務(wù)部門基本上變?yōu)檐浖恕．斎唬@不是說公司將只變?yōu)檐浖词乖谧钜攒浖橹行牡墓局羞€是有很多人的），只是整個業(yè)務(wù)在用軟件定義過程。 

企業(yè)不只是把軟件用作人工流程生產(chǎn)力的輔助手段，他們正在用代碼構(gòu)建整個業(yè)務(wù)部分。

這個轉(zhuǎn)變具有很多重要的意義，但是，我關(guān)注的是，這對軟件本身的角色和設(shè)計有什么意義。在這個新興的世界上，應(yīng)用程序的目的不太可能是為 UI 提供服務(wù)來幫助人們開展業(yè)務(wù)，更可能的是觸發(fā)操作或?qū)浖钠渌糠肿鞒龇磻?yīng)以直接開展業(yè)務(wù)。盡管這很容易理解，但是，它引發(fā)了一個大問題。

傳統(tǒng)的數(shù)據(jù)庫架構(gòu)是否適合這個新興的世界？  

畢竟，數(shù)據(jù)庫一直是應(yīng)用程序開發(fā)中最成功的基礎(chǔ)結(jié)構(gòu)層。然而，所有的數(shù)據(jù)庫，從最完善的關(guān)系數(shù)據(jù)庫到最新的鍵值存儲，都遵循一種范式，在該范式中，數(shù)據(jù)是被動存儲的，數(shù)據(jù)庫等待命令對它進行檢索或修改。被遺忘的是，這種范式的興起是由一種特定類型的面向用戶的應(yīng)用程序來驅(qū)動的，在這種應(yīng)用程序中，用戶可以查看 UI 并啟動將其轉(zhuǎn)換為數(shù)據(jù)庫查詢的操作。在我們上面提到的例子中，很顯然構(gòu)建了一個關(guān)系數(shù)據(jù)庫以支持有助于在這為期 1 到 2 周的貸款批準流程中人為因素的應(yīng)用程序，但是，是否適合把包括實時貸款批準流程在內(nèi)的全套軟件組合在一起，而該實時貸款批準流程是基于不斷變化的數(shù)據(jù)進行持持續(xù)查詢而建立的？

實際上，值得注意的是，隨著 RDBMS（CRM、HRIS、ERP 等等）的興起，所有的應(yīng)用程序都是在軟件時代作為人類生產(chǎn)力輔助工具出現(xiàn)的。CRM 應(yīng)用程序使銷售團隊更有效率，HRIS 讓 HR 團隊更有效率等等。這些應(yīng)用程序都是軟件工程師所謂的“CRUD”應(yīng)用程序。它們幫助用戶創(chuàng)建、更新及刪除數(shù)據(jù)庫記錄，并在該流程上管理業(yè)務(wù)邏輯。這其中固有的假設(shè)是，在網(wǎng)絡(luò)的另一端有人在驅(qū)動和執(zhí)行該業(yè)務(wù)過程。這些應(yīng)用程序的目標是給人們看一些東西（他們會查看結(jié)果），給應(yīng)用程序輸入更多的數(shù)據(jù)。

該模式與公司采用軟件的方式相匹配：一點一點地增加由人執(zhí)行的組織和過程。但是，數(shù)據(jù)基礎(chǔ)設(shè)施本身并不知道如何互連或?qū)緝?nèi)部其他地方發(fā)生的事情做出反應(yīng)。這導(dǎo)致產(chǎn)生了圍繞數(shù)據(jù)庫構(gòu)建的所有類型的解決方案，其中包括集成層、ETL 產(chǎn)品、消息傳遞系統(tǒng)，以及大量代碼，這些代碼是大規(guī)模軟件集成的標志。

由于數(shù)據(jù)庫沒有為數(shù)據(jù)流建模，因此，公司內(nèi)部系統(tǒng)之間的互連是一團亂麻。

事件流的興起  

當軟件的主要角色不是為 UI 提供服務(wù)，而是直接觸發(fā)操作或?qū)浖钠渌糠肿龀龇磻?yīng)時，那么，我們的數(shù)據(jù)平臺需要什么新功能呢？

我認為，要從事件和事件流的概念開始來回答這個問題。什么是事件？發(fā)生的任何事情，包括用戶登錄嘗試、購買行為、價格的變化等等。什么是事件流？一系列不斷更新的事件，代表了過去發(fā)生的事情和現(xiàn)在正在發(fā)生的事情。

事件流為傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)提供了一種非常不同的思考范式。基于事件構(gòu)建的系統(tǒng)不再被動地存儲數(shù)據(jù)集和等待來自 UI 驅(qū)動的應(yīng)用程序的命令。與之相反，它的設(shè)計目的是支持貫穿整個業(yè)務(wù)中的數(shù)據(jù)流以及實時響應(yīng)和處理發(fā)生在業(yè)務(wù)中的每個事件的反應(yīng)。這似乎與數(shù)據(jù)庫的領(lǐng)域相去甚遠，但是，我認為，數(shù)據(jù)庫的一般概念對未來的發(fā)展來說過于狹隘。

Apache Kafka 及其用途  

通過分享我自己的背景知識，我將概述一些事件用例。Confluent 的創(chuàng)始人最初在 LinkedIn 工作的時候創(chuàng)建了這個開源項目 Apache Kafka，近年來，Kafka 已經(jīng)成為事件流運動的基礎(chǔ)技術(shù)。我們的動機很簡單：盡管 LinkedIn 所有的數(shù)據(jù)是通過一天 24 小時永不停止的流程不斷生成的，但是，利用這些數(shù)據(jù)的基礎(chǔ)設(shè)施限于每天結(jié)束時緩慢的大型批處理數(shù)據(jù)轉(zhuǎn)儲和簡單的查找。“一天結(jié)束后的批處理”概念似乎是過去穿孔卡片和大型機時代的遺產(chǎn)。事實上，對于一個全球性的企業(yè)來說，每天沒有結(jié)束的概念。

很顯然，當我們投入這個挑戰(zhàn)時，這個問題沒有現(xiàn)成的解決方案。此外，在構(gòu)建了支持實時網(wǎng)站的 NoSQL 后，我們知道，分布式系統(tǒng)研究和技術(shù)的復(fù)興為我們提供了一套工具，以過去不可能的方式來解決這個問題。我們注意到“流處理”的學術(shù)文獻，流處理是一個研究領(lǐng)域，可以把數(shù)據(jù)庫的存儲和數(shù)據(jù)處理技術(shù)擴展到靜態(tài)表之外，并把它們應(yīng)用于這類持續(xù)、永不停息的數(shù)據(jù)流，這種數(shù)據(jù)流是像 LinkedIn 那樣的數(shù)字業(yè)務(wù)的核心。

我們都熟悉這個古老的問題：“我們到了嗎？”傳統(tǒng)數(shù)據(jù)庫有點像個孩子，要回答這個問題除了不斷詢問，別無選擇。借助流處理，ETA 變成一個連續(xù)的計算，總是和問題的位置保持同步。

在社交網(wǎng)絡(luò)中，一個事件可以代表一次點擊、一封電郵、一次登錄、一個新的連接，或者一次個人資料的更新。把這些數(shù)據(jù)作為不斷發(fā)生的流來對待，可以讓 LinkedIn 所有的其他系統(tǒng)都可以訪問這些數(shù)據(jù)。

我們的早期用例涉及為 LinkedIn 的社交圖片、搜索、Hadoop、數(shù)據(jù)倉庫環(huán)境，以及像推薦系統(tǒng)、新聞提要、廣告系統(tǒng)的面向用戶的應(yīng)用程序及其他產(chǎn)品功能提供填充數(shù)據(jù)。隨著時間的流逝，Kafka 的使用擴展到安全系統(tǒng)、低級應(yīng)用程序監(jiān)控、電郵、新聞提要以及數(shù)以百計的其他應(yīng)用程序。這些都發(fā)生在這樣一個大規(guī)模要求的背景下：每天都有數(shù)以萬億計的消息流經(jīng) Kafka，并且數(shù)以千計的工程師圍繞著它工作。

在我們開源 Kafka 后，它在 LinkedIn 外開始了廣泛的傳播，在 Netflix、Uber、Pinterest、Twitter、Airbnb 等公司出現(xiàn)了類似的架構(gòu)。

隨著我于 2014 年離開 LinkedIn，創(chuàng)辦了 Confluent 后，Kafka 和事件流已經(jīng)開始引起硅谷科技公司以外的廣泛關(guān)注，并從簡單數(shù)據(jù)管道轉(zhuǎn)變?yōu)橹苯訛閷崟r應(yīng)用程序提供支持。

如今，全球最大的銀行中有一些把 Kafka 和 Confluent 用于欺詐檢測、支付系統(tǒng)、風險系統(tǒng)和微服務(wù)架構(gòu)。Kafka 是 Euronext 下一代證券交易平臺的核心，用于處理歐洲市場數(shù)十億筆交易。

在零售行業(yè)，Walmart、Target 和 Nordstrom 等公司已經(jīng)采用了 Kafka。項目包括實時庫存管理，另外還有電子商務(wù)和實體設(shè)施的整合。零售業(yè)傳統(tǒng)上建立于每日緩慢的批處理的基礎(chǔ)之上，但是，來自電子商務(wù)的競爭已經(jīng)推動了一體化和實時化。

包括 Tesla 和 Audi 在內(nèi)的多家汽車公司已經(jīng)為其下一代聯(lián)網(wǎng)的汽車構(gòu)建了物聯(lián)網(wǎng)平臺，把汽車數(shù)據(jù)建模為實時事件流。他們并不是唯一這么做的。火車、船舶、倉儲和重型機械也都開始在事件流中捕獲數(shù)據(jù)了。

從硅谷開始的現(xiàn)象現(xiàn)在成了主流，成千上萬的組織都在使用 Kafka，其中包括 60% 的財富 100 強公司。

事件流作為中樞神經(jīng)系統(tǒng)  

這些公司中的大多數(shù)最初采用 Kafka 是為了一個特定用例啟用單個可擴展的實時應(yīng)用程序或數(shù)據(jù)管道。這種最初的用法往往可以在公司內(nèi)部迅速傳播到其他應(yīng)用程序。

這種迅速傳播的原因是，事件流都是有多個讀者的：一個事件流可以有任意數(shù)量的“訂閱者”，可以對它進行處理、做出反應(yīng)或回復(fù)。

以零售業(yè)為例，零售商可能首先捕獲單個用例在商店中發(fā)生的銷售流，比如，加快倉庫管理。每個事件可能表示和一次銷售有關(guān)的數(shù)據(jù)：售出的商品、售出商品的商店等等。但是，盡管使用可能從單個應(yīng)用程序開始，相同的銷售流對于定價、報告、折扣系統(tǒng)以及數(shù)十個其他用例至關(guān)重要的。實際上，在全球零售業(yè)務(wù)中，有數(shù)百個甚至數(shù)千個軟件系統(tǒng)管理著業(yè)務(wù)的核心流程，包括庫存管理、倉庫操作、發(fā)貨、價格變動、分析及采購。有多少個核心流程受產(chǎn)品銷售這個簡單事件的影響？答案是很多或大多數(shù)，因為銷售商品是零售行業(yè)中最基本的活動之一。

這是采用的良性循環(huán)。第一個應(yīng)用程序帶來其關(guān)鍵數(shù)據(jù)流。新的應(yīng)用程序加入平臺以訪問這些數(shù)據(jù)流，并帶來它們自己的數(shù)據(jù)流。數(shù)據(jù)流帶來應(yīng)用程序，而應(yīng)用程序又帶來更多的數(shù)據(jù)流。

其核心思想是，事件流可以作為已發(fā)生事件的記錄加以處理，并且，任何系統(tǒng)或應(yīng)用程序都可以實時利用它來對數(shù)據(jù)流做出反應(yīng)、響應(yīng)或進行處理。

這有著非常重要的意義。在公司內(nèi)部，通常是一團亂麻似的相互連接的系統(tǒng)，每個應(yīng)用程序都臨時與另外一個連接。這是非常昂貴耗時的方法。事件流提供了一種替代方法：可以有一個中央平臺，支持實時處理、查詢和計算。每個應(yīng)用程序都可以發(fā)布與其業(yè)務(wù)部分相關(guān)的流，并以完全解耦的方式依賴其他流。

為了驅(qū)動內(nèi)部連接，事件流平臺充當新興軟件定義的公司的中樞神經(jīng)系統(tǒng)。我們可以把單獨的、以 UI 為中心、離線的應(yīng)用程序看作一種軟件世界的單細胞生物。通過很多這類單細胞動物的簡單堆疊不可能形成一個綜合的數(shù)字公司，就像一條狗不能從一堆沒有差異的阿米巴變形蟲中創(chuàng)造出來一樣。一個多細胞動物有神經(jīng)系統(tǒng)，協(xié)調(diào)所有單個細胞成為一個整體，可以對其在任何組成部分中所經(jīng)歷的任何事情做出反應(yīng)、計劃和即時行動。數(shù)字公司需要相當于這種神經(jīng)系統(tǒng)的軟件，以連接其所有的系統(tǒng)、應(yīng)用程序和流程。

這讓我們相信，這個新興的事件流平臺將會是現(xiàn)代企業(yè)中最具戰(zhàn)略意義的單一數(shù)據(jù)平臺。

事件流平臺：數(shù)據(jù)庫和數(shù)據(jù)流必須結(jié)合在一起  

正確地做這件事不僅僅是管道膠帶公司為特別集成構(gòu)建的生產(chǎn)問題。就現(xiàn)狀來說，這是不夠的，更別說新興的潮流了。所需的是實時數(shù)據(jù)平臺，可以把數(shù)據(jù)庫的全部存儲和查詢處理能力整合到一個現(xiàn)代的、水平可擴展的數(shù)據(jù)平臺中。

對這個平臺的需求不僅僅是對這些事件流進行讀寫。事件流不只是關(guān)于正在發(fā)生的事情短暫的、有損的數(shù)據(jù)噴射，它是對業(yè)務(wù)從過去到現(xiàn)在的過程中所發(fā)生事情的完整的、可靠的、持久的記錄。為了充分利用事件流，需要一個用于存儲、查詢、處理和轉(zhuǎn)換這些流的實時數(shù)據(jù)平臺，而不只是一個短暫的事件數(shù)據(jù)的“啞巴管道”。

把數(shù)據(jù)庫的存儲和處理能力與實時數(shù)據(jù)結(jié)合起來似乎有點古怪。如果我們把數(shù)據(jù)庫看作一種含有一大堆被動數(shù)據(jù)的容器，那么，事件流看起來離數(shù)據(jù)庫的領(lǐng)域還很遠。但是，流處理的想法顛覆了這一點。如果我們把在公司內(nèi)部發(fā)生的任何東西的流看作“數(shù)據(jù)”，并允許持續(xù)“查詢”對它的處理、響應(yīng)和反應(yīng)，會發(fā)生什么事呢？這導(dǎo)致了根本不同的數(shù)據(jù)庫功能框架。

在傳統(tǒng)的數(shù)據(jù)庫中，數(shù)據(jù)是被動地放置的，等待應(yīng)用程序或人來發(fā)出其要響應(yīng)的查詢。在流處理中，這個過程倒過來了：數(shù)據(jù)是持續(xù)的，活動的事件流，饋送到被動的查詢中，該查詢只是對數(shù)據(jù)流做出反應(yīng)和處理。

[[278991]]

在某些方面，數(shù)據(jù)庫已經(jīng)在內(nèi)部設(shè)計中展示了其在表和事件流上的二元性，即使不是其外部特征也是如此。大多數(shù)數(shù)據(jù)庫都是圍繞提交日志構(gòu)建的，提交日志充當數(shù)據(jù)修改事件的持久流。通常，這些日志僅僅是傳統(tǒng)數(shù)據(jù)庫中的實現(xiàn)細節(jié)，查詢無法訪問。然而，在事件流的世界，這些日志及其填充的表需要成為一等公民。

但是，集成這兩件事的理由不只是基于數(shù)據(jù)庫內(nèi)部。基本上，應(yīng)用程序是用存儲在表中的數(shù)據(jù)對世界上發(fā)生的事件做出反應(yīng) 。在我們的零售示例中，銷售事件會影響庫存事件（數(shù)據(jù)庫表中的狀態(tài)），從而影響重新訂購事件（另一個事件！）。整個業(yè)務(wù)流程可以由這些應(yīng)用程序和數(shù)據(jù)庫交互的菊花鏈形成，創(chuàng)建新事件的同時也改變這個世界的狀態(tài)（減少庫存數(shù)量，更新余額等等）。

傳統(tǒng)數(shù)據(jù)庫只支持這個問題的一半，剩下的一半嵌入應(yīng)用程序代碼。KSQL 等現(xiàn)代流處理系統(tǒng)正在把這些抽象集合到一起，以開始完成數(shù)據(jù)庫需要跨事件和傳統(tǒng)存儲數(shù)據(jù)表進行的操作，但是，事件與數(shù)據(jù)庫的統(tǒng)一只是一個剛開始的運動。

Confluent 的使命  

Confluent 的使命是構(gòu)建這個事件流平臺，幫助企業(yè)圍繞這個事件流平臺開始重構(gòu)自身。創(chuàng)始人和很多早期員工甚至在公司誕生之前就已經(jīng)開始為這個項目工作了，并一直工作至今。

我們構(gòu)建該平臺的方法是由下而上。通過幫助 Kafka 的核心可靠地進行大規(guī)模的存儲、讀寫事件流開始。然后，我們將堆棧移到連接器和 KSQL 上，讓事件流變得容易及易于使用，我們認為這對于構(gòu)建新的主流開發(fā)范式是至關(guān)重要的。

我們已經(jīng)在主要的公共云供應(yīng)商以軟件產(chǎn)品和完全托管的云服務(wù)形式讓這個堆棧變得可用。這使事件流平臺可用跨越企業(yè)運營的整個環(huán)境，并在所有環(huán)境中集成數(shù)據(jù)和事件。

整個生態(tài)系統(tǒng)有大量機會在這個新的基礎(chǔ)設(shè)施上進行構(gòu)建：從實時監(jiān)控和分析，到物聯(lián)網(wǎng)、微服務(wù)、機器學習管道和架構(gòu)，數(shù)據(jù)移動和集成。

隨著這個新的平臺和生態(tài)系統(tǒng)的興起，我們認為，它可以成為正在通過軟件定義和執(zhí)行其業(yè)務(wù)的轉(zhuǎn)型公司的主要部分。隨著它成長為這個角色，我認為，無論是在其范圍還是戰(zhàn)略重要性上，事件流平臺將會和關(guān)系數(shù)據(jù)庫平起平坐。在 Confluent，我們的目標是使之實現(xiàn)。

作者介紹

Jay Kreps，Confluent 的首席執(zhí)行官，也是 Apache Kafka 的聯(lián)合創(chuàng)始人之一。他曾是 LinkedIn 的資深架構(gòu)師。