中文字幕在线观看,亚洲а∨天堂久久精品9966,亚洲成a人片在线观看你懂的,亚洲av成人片无码网站,亚洲国产精品无码久久久五月天

傳統(tǒng)數(shù)據(jù)庫架構已經不適合新興世界了?

2020-04-28    來源:raincent

容器云強勢上線!快速搭建集群,上萬Linux鏡像隨意使用

作者: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ù)提供了一種非常不同的思考范式;谑录䴓嫿ǖ南到y(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)系。

上一篇:2020年媒體技術趨勢報告:13大領域、89項變革全輸出

下一篇:未來五年影響金融業(yè)的5大新興科技 大數(shù)據(jù)、AI和區(qū)塊鏈均位列其中