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

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

正文：

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

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

為了澄清我的意思，讓我們來看一個例子：消費銀行的貸款批準流程。這是一個在計算機出現(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)的數(shù)據(jù)庫架構是否適合這個新興的世界?

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

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

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

 

 

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

事件流的興起

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

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

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

Apache Kafka® 及其用途

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

 

 

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

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

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

作者介紹

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

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

標簽： 數(shù)據(jù) 餳芄

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