作者：Jay Kreps   譯者：姚佳靈
來源：InfoQ

作者 Jay Kreps 是 Confluent 的首席執(zhí)行官，他分析了傳統(tǒng)數據庫的架構不適合新興的世界的原因，提出了要構建事件流平臺，把數據庫和數據流結合在一起的目標。

正文：

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

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

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

然而現(xiàn)在，在很多銀行中這個操作正在變?yōu)橐粋�完全自動化的流程，其中信貸軟件、風險軟件和 CRM 軟件之間相互通信并在幾秒內提供決策。這里，銀行貸款業(yè)務部門基本上變?yōu)檐浖�了。當然，這不是說公司將只變?yōu)檐浖?即使在最以軟件為中心的公司中還是有很多人的)，只是整個業(yè)務在用軟件定義過程。

 

 

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

這個轉變具有很多重要的意義，但是，我關注的是，這對軟件本身的角色和設計有什么意義。在這個新興的世界上，應用程序的目的不太可能是為 UI 提供服務來幫助人們開展業(yè)務，更可能的是觸發(fā)操作或對軟件的其他部分作出反應以直接開展業(yè)務。盡管這很容易理解，但是，它引發(fā)了一個大問題：

傳統(tǒng)的數據庫架構是否適合這個新興的世界?

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

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

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

 

 

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

事件流的興起

當軟件的主要角色不是為 UI 提供服務，而是直接觸發(fā)操作或對軟件的其他部分做出反應時，那么，我們的數據平臺需要什么新功能呢?

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

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

Apache Kafka® 及其用途

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

事件流平臺：數據庫和數據流必須結合在一起

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

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

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

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

 

 

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

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

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

作者介紹

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

原文鏈接： Every Company is Becoming a Software Company

標簽： 數據 餳芄

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。