Jay Kreps是來自LinkedIn的首席工程師，他表示日志幾乎在計算機(jī)產(chǎn)生的時候就存在，除了可用在分布式計算或者抽象分布式計算模型內(nèi)部之外，還有廣泛的用途。本文中他講述的日志的原理和通過把日志用做單獨(dú)服務(wù)來實現(xiàn)數(shù)據(jù)集成、實時數(shù)據(jù)處理以及分布式系統(tǒng)設(shè)計。文章內(nèi)容非常干貨，值得學(xué)習(xí)。

以下是原文：

我在六年前的一個令人興奮的時刻加入到LinkedIn公司。從那個時候開始我們就破解單一的、集中式數(shù)據(jù)庫的限制，并且啟動到特殊的分布式系統(tǒng)套件的轉(zhuǎn)換。這是一件令人興奮的事情：我們構(gòu)建、部署，而且直到今天仍然在運(yùn)行的分布式圖形數(shù)據(jù)庫、分布式搜索后端、Hadoop安裝以及第一代和第二代鍵值數(shù)據(jù)存儲。

從這一切里我們體會到的最有益的事情是我們構(gòu)建的許多東西的核心里都包含一個簡單的理念：日志。有時候也稱作預(yù)先寫入日志或者提交日志或者事務(wù)日志，日志幾乎在計算機(jī)產(chǎn)生的時候就存在，同時它還是許多分布式數(shù)據(jù)系統(tǒng)和實時應(yīng)用結(jié)構(gòu)的核心。

不懂得日志，你就不可能完全懂得數(shù)據(jù)庫，NoSQL存儲，鍵值存儲，復(fù)制，paxos,Hadoop,版本控制以及幾乎所有的軟件系統(tǒng)；然而大多數(shù)軟件工程師對它們不是很熟悉。我愿意改變這種現(xiàn)狀。在這篇博客文章里，我將帶你瀏覽你必須了解的有關(guān)日志的所有的東西，包括日志是什么，如何在數(shù)據(jù)集成、實時處理和系統(tǒng)構(gòu)建中使用日志等。

第一部分：日志是什么？

日志是一種簡單的不能再簡單的存儲抽象。它是一個只能增加的，完全按照時間排序的一系列記錄。日志看起來如下：

我們可以給日志的末尾添加記錄，并且可以從左到右讀取日志記錄。每一條記錄都指定了一個唯一的有一定順序的日志記錄編號。
日志記錄的排序是由“時間”來確定的，這是因為位于左邊的日志記錄比位于右邊的要早些。日志記錄編號可以看作是這條日志 記錄的“時間戳”。在一開始就把這種排序說成是按時間排序顯得有點多余 ，不過 ，與任何一個具體的物理時鐘相比，時間 屬性是非常便于使用的屬性。在我們運(yùn)行多個分布式系統(tǒng)的時候，這個屬性就顯得非常重要。

對于這篇討論的目標(biāo)而言，日志記錄的內(nèi)容和格式不怎么重要。另外提醒一下，在完全耗盡存儲空間的情況下，我們不可能 再給日志添加記錄。稍后我們將會提到這個問題。

日志并不是完全不同于文件或者數(shù)據(jù)表的。文件是由一系列字節(jié)組成，表是由一系列記錄組成，而日志實際上只是按照時間順序存儲記錄的 一種數(shù)據(jù)表或者文件。

此時，你可能奇怪為什么要討論這么簡單的事情呢？ 不同環(huán)境下的一個只可增加的有一定順序的日志記錄是怎樣與數(shù)據(jù)系統(tǒng)關(guān)聯(lián)起來的呢？答案是日志有其特定的應(yīng)用目標(biāo)：它記錄了什么時間發(fā)生了什么事情。 而對分布式數(shù)據(jù)系統(tǒng)許多方面而言， 這才是問題的真正核心。

不過，在我們進(jìn)行更加深入的討論之前，讓我先澄清有些讓人混淆的概念。每個編程人員都熟悉另一種日志記錄-應(yīng)用使用syslog或者log4j可能寫入到本地文件里的沒有結(jié)構(gòu)的錯誤信息或者追蹤信息。為了區(qū)分開來，我們把這種情形的日志記錄稱為“應(yīng)用日志記錄”。應(yīng)用日志記錄是我在這兒所說的日志的一種低級的變種。最大的區(qū)別是：文本日志意味著主要用來方便人們閱讀，而我所說明的“日志”或者“數(shù)據(jù)日志”的建立是方便程序訪問。

（實際上，如果你對它進(jìn)行深入的思考，那么人們讀取某個機(jī)器上的日志這種理念有些不順應(yīng)時代潮流。當(dāng)涉及到許多服務(wù)和服務(wù)器的時候，這種方法很快就變成一個難于管理的方式，而且為了認(rèn)識多個機(jī)器的行為，日志的目標(biāo)很快就變成查詢和圖形化這些行為的輸入了-對多個機(jī)器的某些行為而言，文件里的英文形式的文本同這兒所描述的這種結(jié)構(gòu)化的日志相比幾乎就不適合了。）

數(shù)據(jù)庫日志

我不知道日志概念起源于何處-可能它就像二進(jìn)制搜索一樣：發(fā)明者認(rèn)為它太簡單而不能當(dāng)作一項發(fā)明。它早在IBM的系統(tǒng)R出現(xiàn)時候就出現(xiàn)了。數(shù)據(jù)庫里的用法是在崩潰的時候用它來同步各種數(shù)據(jù)結(jié)構(gòu)和索引。為了保證操作的原子性和持久性，在對數(shù)據(jù)庫維護(hù)的所有各種數(shù)據(jù)結(jié)構(gòu)做更改之前，數(shù)據(jù)庫把即將修改的信息謄寫到日志里。日志記錄了發(fā)生了什么，而且其中的每個表或者索引都是一些數(shù)據(jù)結(jié)構(gòu)或者索引的歷史映射。由于日志是即刻永久化的，可以把它當(dāng)作崩潰發(fā)生時用來恢復(fù)其他所有永久性結(jié)構(gòu)的可信賴數(shù)據(jù)源。

隨著時間的推移，日志的用途從實現(xiàn)ACID細(xì)節(jié)成長為數(shù)據(jù)庫間復(fù)制數(shù)據(jù)的一種方法。利用日志的結(jié)果就是發(fā)生在數(shù)據(jù)庫上的更改順序與遠(yuǎn)端復(fù)制數(shù)據(jù)庫上的更改順序需要保持完全同步。

Oracle,MySQL 和PostgreSQL都包括用于給備用的復(fù)制數(shù)據(jù)庫傳輸日志的日志傳輸協(xié)議。Oracle還把日志產(chǎn)品化為一個通用的數(shù)據(jù)訂閱機(jī)制，這樣非Oracle數(shù)據(jù)訂閱用戶就可以使用XStreams和GoldenGate訂閱數(shù)據(jù)了，MySQL和PostgreSQL上的類似的實現(xiàn)則成為許多數(shù)據(jù)結(jié)構(gòu)的關(guān)鍵組件。
正是由于這樣的起源，機(jī)器可識別的日志的概念大部分都被局限在數(shù)據(jù)庫內(nèi)部。日志用做數(shù)據(jù)訂閱的機(jī)制似乎是偶然出現(xiàn)的，不過要把這種 抽象用于支持所有類型的消息傳輸、數(shù)據(jù)流和實時數(shù)據(jù)處理是不切實際的。

分布式系統(tǒng)日志

日志解決了兩個問題：更改動作的排序和數(shù)據(jù)的分發(fā)，這兩個問題在分布式數(shù)據(jù)系統(tǒng)里顯得尤為重要。協(xié)商出一致的更改動作的順序（或者說保持各個子系統(tǒng)本身的做法，但可以進(jìn)行存在副作用的數(shù)據(jù)拷貝）是分布式系統(tǒng)設(shè)計的核心問題之一。

以日志為中心實現(xiàn)分布式系統(tǒng)是受到了一個簡單的經(jīng)驗常識的啟發(fā)，我把這個經(jīng)驗常識稱為狀態(tài)機(jī)復(fù)制原理：如果兩個相同的、確定性的進(jìn)程從同一狀態(tài)開始，并且以相同的順序獲得相同的輸入，那么這兩個進(jìn)程將會生成相同的輸出，并且結(jié)束在相同的狀態(tài)。

這也許有點難以理解，讓我們更加深入的探討，弄懂它的真正含義。

確定性意味著處理過程是與時間無關(guān)的，而且任何其他“外部的“輸入不會影響到處理結(jié)果。例如，如果一個程序的輸出會受到線程執(zhí)行的具體順序影響，或者受到gettimeofday調(diào)用、或者其他一些非重復(fù)性事件的影響，那么這樣的程序一般最有可能被認(rèn)為是非確定性的。

進(jìn)程狀態(tài)是進(jìn)程保存在機(jī)器上的任何數(shù)據(jù)，在進(jìn)程處理結(jié)束的時候，這些數(shù)據(jù)要么保存在內(nèi)存里，要么保存在磁盤上。

以相同的順序獲得相同輸入的地方應(yīng)當(dāng)引起注意-這就是引入日志的地方。這兒有一個重要的常識：如果給兩段確定性代碼相同的日志輸入，那么它們就會生成相同的輸出。

分布式計算這方面的應(yīng)用就格外明顯。你可以把用多臺機(jī)器一起執(zhí)行同一件事情的問題縮減為實現(xiàn)分布式一致性日志為這些進(jìn)程輸入的問題。這兒日志的目的是把所有非確定性的東西排除在輸入流之外，來確保每個復(fù)制進(jìn)程能夠同步地處理輸入。

當(dāng)你理解了這個以后，狀態(tài)機(jī)復(fù)制原理就不再復(fù)雜或者說不再深奧了：這或多或少的意味著“確定性的處理過程就是確定性的”。不管怎樣，我都認(rèn)為它是分布式系統(tǒng)設(shè)計里較常用的工具之一。

這種方式的一個美妙之處就在于索引日志的時間戳就像時鐘狀態(tài)的一個副本——你可以用一個單獨(dú)的數(shù)字描述每一個副本，這就是經(jīng)過處理的日志的時間戳。時間戳與日志一一對應(yīng)著整個副本的狀態(tài)。

由于寫進(jìn)日志的內(nèi)容的不同，也就有許多在系統(tǒng)中應(yīng)用這個原則的不同方式。舉個例子，我們記錄一個服務(wù)的請求，或者服務(wù)從請求到響應(yīng)的狀態(tài)變化，或者它執(zhí)行命令的轉(zhuǎn)換。理論上來說，我們甚至可以為每一個副本記錄一系列要執(zhí)行的機(jī)器指令或者調(diào)用的方法名和參數(shù)。只要兩個進(jìn)程用相同的方式處理這些輸入，這些進(jìn)程就會保持副本的一致性。

一千個人眼中有一千種日志的用法。數(shù)據(jù)庫工作者通常區(qū)分物理日志和邏輯日志。物理日志就是記錄每一行被改變的內(nèi)容。邏輯日志記錄的不是改變的行而是那些引起行的內(nèi)容被改變的SQL語句（insert，update和delete語句）。

分布式系統(tǒng)通?？梢詫挿悍譃閮煞N方法來處理數(shù)據(jù)和完成響應(yīng)。“狀態(tài)機(jī)器模型”通常引用一個主動-主動的模型——也就是我們?yōu)橹涗浾埱蠛晚憫?yīng)的對象。對此進(jìn)行一個細(xì)微的更改，稱之為“預(yù)備份模型”，就是選出一個副本做為leader，并允許它按照請求到達(dá)的時間來進(jìn)行處理并從處理過程中輸出記錄其狀態(tài)改變的日志。其他的副本按照leader狀態(tài)改變的順序而應(yīng)用那些改變，這樣他們之間達(dá)到同步，并能夠在leader失敗的時候接替leader的工作。

為了理解兩種方式的不同，我們來看一個不太嚴(yán)謹(jǐn)?shù)睦印＜俣ㄓ幸粋€算法服務(wù)的副本，保持一個獨(dú)立的數(shù)字作為它的狀態(tài)（初始值為0），并對這個值進(jìn)行加法和乘法運(yùn)算。主動-主動方式應(yīng)該會輸出所進(jìn)行的變換，比如“+1”，“*2”等。每一個副本都會應(yīng)用這些變換，從而得到同樣的解集。主動-被動方式將會有一個獨(dú)立的主體執(zhí)行這些變換并輸出結(jié)果日志，比如“1”，“3”，“6”等。這個例子也清楚的展示了為什么說順序是保證各副本間一致性的關(guān)鍵：一次加法和乘法的順序的改變將會導(dǎo)致不同的結(jié)果。
分布式日志可以理解為一致性問題模型的數(shù)據(jù)結(jié)構(gòu)。因為日志代表了后續(xù)追加值的一系列決策。你需要重新審視Paxos算法簇，盡管日志模塊是他們最常見的應(yīng)用。 在Paxos算法中，它通常通過使用稱之為多paxos的協(xié)議，這種協(xié)議將日志建模為一系列的問題，在日志中每個問題都有對應(yīng)的部分。在ZAB， RAFT等其它的協(xié)議中，日志的作用尤為突出，它直接對維護(hù)分布式的、一致性的日志的問題建模。

我懷疑的是，我們就歷史發(fā)展的觀點是有偏差的，可能是由于過去的幾十年中，分布式計算的理論遠(yuǎn)超過了其實際應(yīng)用。在現(xiàn)實中，共識的問題是有點太簡單了。計算機(jī)系統(tǒng)很少需要決定單個值，他們幾乎總是處理成序列的請求。這樣的記錄，而不是一個簡單的單值寄存器，自然是更加抽象。

此外，專注于算法掩蓋了 抽象系統(tǒng)需要的底層的日志。我懷疑，我們最終會把日志中更注重作為一個商品化的基石，不論其是否以同樣的方式 實施的，我們經(jīng)常談?wù)撘粋€哈希表而不是糾結(jié)我們 得到是不是具體某個細(xì)節(jié)的哈希表，例如線性或者帶有什么什么其它變體哈希表。日志將成為一種大眾化的接口，為大多數(shù)算法和其實現(xiàn)提升提供最好的保證和最佳的性能。

變更日志101： 表與事件的二相性。

讓我們繼續(xù)聊數(shù)據(jù)庫。數(shù)據(jù)庫中存在著大量變更日志和表之間的二相性。這些日志有點類似借貸清單和銀行的流程，數(shù)據(jù)庫表就是當(dāng)前的盈余表。如果你有大量的變更日志，你就可以使用這些變更用以創(chuàng)建捕獲當(dāng)前狀態(tài)的表。這張表將記錄每個關(guān)鍵點（日志中一個特別的時間點）的狀態(tài)信息。這就是為什么日志是非?；镜臄?shù)據(jù)結(jié)構(gòu)的意義所在：日志可用來創(chuàng)建基本表，也可以用來創(chuàng)建各類衍生表。同時意味著可以存儲非關(guān)系型的對象。
這個流程也是可逆的：如果你正在對一張表進(jìn)行更新，你可以記錄這些變更，并把所有更新的日志發(fā)布到表的狀態(tài)信息中。這些變更日志就是你所需要的支持準(zhǔn)實時的克隆?；诖耍憔涂梢郧宄睦斫獗砼c事件的二相性： 表支持了靜態(tài)數(shù)據(jù)而日志捕獲變更。日志的魅力就在于它是變更的完整記錄，它不僅僅捕獲了表的最終版本的內(nèi)容，它還記錄了曾經(jīng)存在過的其它版本的信息。日志實質(zhì)上是表歷史狀態(tài)的一系列備份。

這可能會引起你對源代碼的版本管理。源代碼管理和數(shù)據(jù)庫之間有密切關(guān)系。版本管理解決了一個大家非常熟悉的問題，那就是什么是分布式數(shù)據(jù)系統(tǒng)需要解決的— 時時刻刻在變化著的分布式管理。版本管理系統(tǒng)通常以補(bǔ)丁的發(fā)布為基礎(chǔ)，這實際上可能是一個日志。您可以直接對當(dāng)前 類似于表中的代碼做出“快照”互動。你會注意到， 與其他分布式狀態(tài)化系統(tǒng)類似，版本控制系統(tǒng) 當(dāng)你更新時會復(fù)制日志，你希望的只是更新補(bǔ)丁并將它們應(yīng)用到你的當(dāng)前快照中。

最近，有些人從Datomic –一家銷售日志數(shù)據(jù)庫的公司得到了一些想法。這些想法使他們對如何 在他們的系統(tǒng)應(yīng)用這些想法有了開闊的認(rèn)識。 當(dāng)然這些想法不是只針對這個系統(tǒng)，他們會成為 十多年分布式系統(tǒng)和數(shù)據(jù)庫文獻(xiàn)的一部分。

這可能似乎有點過于理想化。但是不要悲觀！我們會很快把它實現(xiàn)。
請讓我首先解釋 一下“數(shù)據(jù)集成”是什么意思，還有為什么我覺得它很重要，之后我們再來看看它和日志有什么關(guān)系。

數(shù)據(jù)集成就是將數(shù)據(jù)組織起來，使得在與其有關(guān)的服務(wù)和系統(tǒng)中可以訪問它們。“數(shù)據(jù)集成”（data integration）這個短語應(yīng)該不止這么簡單，但是我找不到一個更好的解釋。而更常見的術(shù)語 ETL 通常只是覆蓋了數(shù)據(jù)集成的一個有限子集(譯注：ETL，Extraction-Transformation-Loading的縮寫，即數(shù)據(jù)提取、轉(zhuǎn)換和加載)——相對于關(guān)系型數(shù)據(jù)倉庫。但我描述的東西很大程度上可以理解為，將ETL推廣至實時系統(tǒng)和處理流程。
你一定不會聽到數(shù)據(jù)集成就興趣盎然屏住呼吸，并且天花亂墜的想到關(guān)于大數(shù)據(jù)的概念，不過，我相信世俗的問題“讓數(shù)據(jù)可被訪問” 是一個組織應(yīng)該關(guān)注的有價值的事情。

對數(shù)據(jù)的高效使用遵循一種 馬斯洛的需要層次理論 。金字塔的基礎(chǔ)部分包括捕獲所有相關(guān)數(shù)據(jù)，能夠?qū)⑺鼈內(nèi)糠诺竭m當(dāng)?shù)奶幚憝h(huán)境（那個環(huán)境應(yīng)該是一個奇妙的實時查詢系統(tǒng)，或者僅僅是文本文件和python腳本）。這些數(shù)據(jù)需要以統(tǒng)一的方式建模，這樣就可以方便讀取和數(shù)據(jù)處理。如果這種以統(tǒng)一的方式捕獲數(shù)據(jù)的基本需求得到滿足，那么就可以在基礎(chǔ)設(shè)施上以若干種方法處理這些數(shù)據(jù)——映射化簡（MapReduce），實時查詢系統(tǒng)，等等。

很明顯，有一點值得注意：如果沒有可靠的、完整的數(shù)據(jù)流，Hadoop集群除了象昂貴的且難于安裝的空間取暖器哪樣外不會做更多事情了。一旦數(shù)據(jù)和處理可用，人們就會關(guān)心良好數(shù)據(jù)模型和一致地易于理解的語法哪些更細(xì)致的問題。最后，人們才會關(guān)注更加高級的處理-更好的可視化、報表以及處理和預(yù)測算法。

以我的經(jīng)驗，大多數(shù)機(jī)構(gòu)在數(shù)據(jù)金字塔的底部存在巨大的漏洞-它們?nèi)狈煽康?、完整的?shù)據(jù)流-而是打算直接跳到高級數(shù)據(jù)模型技術(shù)上。這樣做完全是反著來做的。因此，問題是我們?nèi)绾螛?gòu)建通過機(jī)構(gòu)內(nèi)所有數(shù)據(jù)系統(tǒng)的可靠的數(shù)據(jù)流。

數(shù)據(jù)集成：兩個并發(fā)癥

兩種趨勢使數(shù)據(jù)集成變得更困難。

事件數(shù)據(jù)管道

第一個趨勢是增長的事件數(shù)據(jù)(event data)。事件數(shù)據(jù)記錄的是發(fā)生的事情，而不是存在的東西。在web系統(tǒng)中，這就意味著用戶活動日志，還有為了可靠的操作以及監(jiān)控數(shù)據(jù)中心的機(jī)器的目的，所需要記錄的機(jī)器級別的事件和統(tǒng)計數(shù)字。人們傾向稱它們?yōu)?ldquo;日志數(shù)據(jù)”，因為它們經(jīng)常被寫到應(yīng)用的日志中，但是這混淆了形式與功能。這種數(shù)據(jù)位于現(xiàn)代web的中心：歸根結(jié)底，Google的資產(chǎn)是由這樣一些建立在點擊和映像基礎(chǔ)之上的相關(guān)管道所生成的——那也就是事件。

這些東西并不是僅限于網(wǎng)絡(luò)公司，只是網(wǎng)絡(luò)公司已經(jīng)完全數(shù)字化，所以它們更容易用設(shè)備記錄。財務(wù)數(shù)據(jù)一直是面向事件的。RFID(無線射頻識別)將這種跟蹤能力賦予物理對象。我認(rèn)為這種趨勢仍將繼續(xù)，伴隨著這個過程的是傳統(tǒng)商務(wù)活動的數(shù)字化。

這種類型的事件數(shù)據(jù)記錄下發(fā)生的事情，而且往往比傳統(tǒng)數(shù)據(jù)庫應(yīng)用要大好幾個數(shù)量級。這對于處理提出了重大挑戰(zhàn)。

專門的數(shù)據(jù)系統(tǒng)的爆發(fā)

第二個趨勢來自于專門的數(shù)據(jù)系統(tǒng)的爆發(fā)，通常這些數(shù)據(jù)系統(tǒng)在最近的五年中開始變得流行，并且可以免費(fèi)獲得。專門的數(shù)據(jù)系統(tǒng)是為OLAP, 搜索, 簡單 在線 存儲, 批處理, 圖像分析, 等 等 而存在的。

更多的不同類型數(shù)據(jù)的組合，以及將這些數(shù)據(jù)存放到更多的系統(tǒng)中的愿望，導(dǎo)致了一個巨大的數(shù)據(jù)集成問題。

日志結(jié)構(gòu)數(shù)據(jù)流

為了處理系統(tǒng)之間的數(shù)據(jù)流，日志是最自然的數(shù)據(jù)結(jié)構(gòu)。其中的秘訣很簡單：

將所有組織的數(shù)據(jù)提取出來，并將它們放到一個中心日志，以便實時查閱。

每個邏輯數(shù)據(jù)源都可以建模為它自己的日志。一個數(shù)據(jù)源可以是一個應(yīng)用程序的事件日志（如點擊量或者頁面瀏覽量），或者是一個接受修改的數(shù)據(jù)庫表。每個訂閱消息的系統(tǒng)都盡可能快的從日志讀取信息，將每條新的記錄保存到自己的存儲，并且提升其在日志中的地位。訂閱方可以是任意一種數(shù)據(jù)系統(tǒng) —— 一個緩存，Hadoop，另一個網(wǎng)站中的另一個數(shù)據(jù)庫，一個搜索系統(tǒng)，等等。

例如，日志針對每個更改給出了邏輯時鐘的概念，這樣所有的訂閱方都可以被測量。推導(dǎo)不同的訂閱系統(tǒng)的狀態(tài)也因此變得相對簡單的多，因為每個系統(tǒng)都有一個讀取動作的“時間點”。

為了讓這個顯得更具體，我們考慮一個簡單的案例，有一個數(shù)據(jù)庫和一組緩存服務(wù)器集群。日志提供了一種同步更新所有這些系統(tǒng)，并推導(dǎo)出每一個系統(tǒng)的接觸時間點的方法。我們假設(shè)寫了一條日志X，然后需要從緩存做一次讀取。如果我們想保證看到的不是陳舊的數(shù)據(jù)，我們只需保證沒有從任何尚未復(fù)制X的緩存中讀取即可。

日志也起到緩存的作用，使數(shù)據(jù)生產(chǎn)與數(shù)據(jù)消費(fèi)相同步。由于許多原因這個功能很重要，特別是在多個訂閱方消費(fèi)數(shù)據(jù)的速度各不相同的時候。這意味著一個訂閱數(shù)據(jù)系統(tǒng)可以宕機(jī)，或者下線維護(hù)，之后重新上線以后再趕上來：訂閱方按照自己控制的節(jié)拍來消費(fèi)數(shù)據(jù)。批處理系統(tǒng)，如Hadoop或者是一個數(shù)據(jù)倉庫，或許只是每小時或者每天消費(fèi)一次數(shù)據(jù)，而實時查詢系統(tǒng)可能需要及時到秒。由于無論是原始數(shù)據(jù)源還是日志，都沒有各種目標(biāo)數(shù)據(jù)系統(tǒng)的相關(guān)知識，因此消費(fèi)方系統(tǒng)可以被添加和刪除，而無需傳輸管道的變化。
特別重要的是：目標(biāo)系統(tǒng)只知道日志，不知道數(shù)據(jù)源系統(tǒng)的任何細(xì)節(jié)。消費(fèi)方系統(tǒng)自身無需考慮數(shù)據(jù)到底是來自于一個RDBMS（關(guān)系型數(shù)據(jù)庫管理系統(tǒng)Relational Database Management System），一種新型的鍵值存儲，或者它不是由任何形式的實時查詢系統(tǒng)所生成的。這似乎是一個小問題，但實際上是至關(guān)重要的。

這里我使用術(shù)語“日志”取代了“消息系統(tǒng)”或者“發(fā)布-訂閱”，因為它在語義上更明確，并且對支持?jǐn)?shù)據(jù)復(fù)制的實際實現(xiàn)這樣的需求，有著更接近的描述。我發(fā)現(xiàn)“發(fā)布訂閱”并不比間接尋址的消息具有更多的含義——如果你比較任何兩個發(fā)布-訂閱的消息傳遞系統(tǒng)的話，你會發(fā)現(xiàn)他們承諾的是完全不同的東西，而且大多數(shù)模型在這一領(lǐng)域都不是有用的。你可以認(rèn)為日志是一種消息系統(tǒng)，它具有持久性保證和強(qiáng)大的訂閱語義。在分布式系統(tǒng)中，這個通信模型有時有個(有些可怕的)名字叫做原子廣播。

值得強(qiáng)調(diào)的是，日志仍然只是基礎(chǔ)設(shè)施。這并不是管理數(shù)據(jù)流這個故事的結(jié)束：故事的其余部分圍繞著元數(shù)據(jù)，模式，兼容性，以及處理數(shù)據(jù)結(jié)構(gòu)的所有細(xì)節(jié)及其演化。除非有一種可靠的，一般的方法來處理數(shù)據(jù)流運(yùn)作，語義在其中總是次要的細(xì)節(jié)。

在 LinkedIn（SNS社交網(wǎng)站）

在LinkedIn從集中式關(guān)系數(shù)據(jù)庫向分布式系統(tǒng)集合轉(zhuǎn)化的過程中，我看到這個數(shù)據(jù)集成問題迅速演變。

現(xiàn)在主要的數(shù)據(jù)系統(tǒng)包括：

搜索
社交圖譜
Voldemort (鍵值存儲)(譯注：一種分布式數(shù)據(jù)庫)
Espresso (文檔存儲)
推舉引擎
OLAP查詢引擎(譯注：OLAP聯(lián)機(jī)分析技術(shù))
Hadoop
Terradata
Ingraphs (監(jiān)控圖表和指標(biāo)服務(wù))
這些都是專門的分布式系統(tǒng)，在其專業(yè)領(lǐng)域提供先進(jìn)的功能。
這種使用日志作為數(shù)據(jù)流的思想，甚至在我到這里之前就已經(jīng)與LinkedIn相伴了。我們開發(fā)的一個最早的基礎(chǔ)設(shè)施之一，是一種稱為databus 的服務(wù)，它在我們早期的Oracle表上提供了一種日志緩存抽象，可伸縮訂閱數(shù)據(jù)庫修改,這樣我們就可以很好支持我們的社交網(wǎng)絡(luò)和搜索索引。

我會給出一些歷史并交代一下上下文。我首次參與到這些大約是在2008年左右，在我們轉(zhuǎn)移鍵值存儲之后。我的下一個項目是讓一個工作中的Hadoop配置演進(jìn)，并給其增加一些我們的推薦流程。由于缺乏這方面的經(jīng)驗，我們自然而然的安排了數(shù)周計劃在數(shù)據(jù)的導(dǎo)入導(dǎo)出方面，剩下的時間則用來實現(xiàn)奇妙的預(yù)測算法。這樣我們就開始了長途跋涉。

我們本來計劃是僅僅將數(shù)據(jù)從現(xiàn)存的Oracle數(shù)據(jù)倉庫中剖離。但是我們首先發(fā)現(xiàn)將數(shù)據(jù)從Oracle中迅速取出是一種黑暗藝術(shù)。更糟的是，數(shù)據(jù)倉庫的處理過程與我們?yōu)镠adoop而計劃的批處理生產(chǎn)過程不適合——其大部分處理都是不可逆轉(zhuǎn)的，并且與即將生成的報告具體相關(guān)。最終我們采取的辦法是，避免使用數(shù)據(jù)倉庫，直接訪問源數(shù)據(jù)庫和日志文件。最后，我們?yōu)榱思虞d數(shù)據(jù)到鍵值存儲 并生成結(jié)果，實現(xiàn)了另外一種管道。
這種普通的數(shù)據(jù)復(fù)制最終成為原始開發(fā)項目的主要內(nèi)容之一。糟糕的是，在任何時間任意管道都有一個問題，Hadoop系統(tǒng)很大程度上是無用的——在錯誤的數(shù)據(jù)基礎(chǔ)上運(yùn)行奇特的算法，只會產(chǎn)生更多的錯誤數(shù)據(jù)。

雖然我們已經(jīng)以一種通用的方式創(chuàng)建事物，但是每個數(shù)據(jù)源都需要自定義配置安裝。這也被證明是巨量錯誤與失敗的根源。我們在Hadoop上實現(xiàn)的網(wǎng)站功能已經(jīng)開始流行起來，同時我們發(fā)現(xiàn)我們有一長串感興趣的工程師。每個用戶都有他們想要集成的一系列系統(tǒng)，他們想要的一系列新數(shù)據(jù)源。
有些東西在我面前開始漸漸清晰起來。

首先，我們已建成的通道雖然有一些雜亂，但實質(zhì)上它們是很有價值的。在采用諸如Hadoop的新的處理系統(tǒng)生成可用數(shù)據(jù)的過程，它開啟了大量的可能性。 基于這些數(shù)據(jù)過去很難實現(xiàn)的計算，如今變?yōu)榭赡堋?許多新的產(chǎn)品和分析技術(shù)都來源于把分片的數(shù)據(jù)放在一起，這些數(shù)據(jù)過被鎖定在特定的系統(tǒng)中。

第二， 眾所周知，可靠的數(shù)據(jù)加載需要數(shù)據(jù)通道的深度支持。如果我們可以捕獲所有我們需要的結(jié)構(gòu)，我就就可以使得Hadoop數(shù)據(jù)全自動的加載，這樣就不需要額外的操作來增加新的數(shù)據(jù)源或者處理模式變更–數(shù)據(jù)就會自動的出現(xiàn)在HDFS，Hive表就會自動的生成對應(yīng)于新數(shù)據(jù)源的恰當(dāng)?shù)牧小?/p>

第三，我們的數(shù)據(jù)覆蓋率仍然非常低。如果你查看存儲于Hadoop中的可用的Linked 數(shù)據(jù)的全部百分比，它仍然是不完整的?；ㄙM(fèi)大量的努力去使得各個新的數(shù)據(jù)源運(yùn)轉(zhuǎn)起來，使得數(shù)據(jù)覆蓋度完整不是一件容易的事情。

我們正在推行的，為每個數(shù)據(jù)源和目標(biāo)增建客戶化數(shù)據(jù)加載，這種方式很顯然是不可行的。我們有大量的數(shù)據(jù)系統(tǒng)和數(shù)據(jù)倉庫。把這些系統(tǒng)和倉庫聯(lián)系起來，就會導(dǎo)致任意一對系統(tǒng)會產(chǎn)生如下所示的客戶化通道。

需要注意的是：數(shù)據(jù)是雙向流動的：例如許多系統(tǒng)諸如數(shù)據(jù)庫和Hadoop既是數(shù)據(jù)轉(zhuǎn)化的來源又是數(shù)據(jù)轉(zhuǎn)化的目的地。這就意味著我們我們不必為每個系統(tǒng)建立兩個通道：一個用于數(shù)據(jù)輸入，一個用于數(shù)據(jù)輸出。

這顯然需要一大群人，而且也不具有可操作性。隨著我們接近完全連接，最終我們將有差不多O(N2)條管道。

替代的，我們需要像這樣通用的東西：

我們需要盡可能的將每個消費(fèi)者與數(shù)據(jù)源隔離。理想情形下，它們應(yīng)該只與一個單獨(dú)的數(shù)據(jù)倉庫集成，并由此讓他們能訪問到所有東西。

這個思想是增加一個新的數(shù)據(jù)系統(tǒng)——或者它是一個數(shù)據(jù)源或者它是一個數(shù)據(jù)目的地——讓集成工作只需連接到一個單獨(dú)的管道，而無需連接到每個數(shù)據(jù)消費(fèi)方。

這種經(jīng)歷使得我關(guān)注創(chuàng)建Kafka來關(guān)聯(lián)我們在消息系統(tǒng)所見的與數(shù)據(jù)庫和分布式系統(tǒng)內(nèi)核所發(fā)布的日志。我們希望一些實體作為中心的通道，首先用于所有的活動數(shù)據(jù)，逐步的擴(kuò)展到其他用途，例如Hadoop外的數(shù)據(jù)實施，數(shù)據(jù)監(jiān)控等。

在相當(dāng)長的時間內(nèi)，Kafka是獨(dú)一無二的底層產(chǎn)品，它既不是數(shù)據(jù)庫，也不是日志文件收集系統(tǒng)，更不是傳統(tǒng)的消息系統(tǒng)。但是最近Amazon提供了非常類似Kafka的服務(wù)，稱之為Kinesis.相似度包括了分片處理的方式，數(shù)據(jù)的保持，甚至包括在Kafka API中，有點特別的高端和低端消費(fèi)者分類。我很開心看到這些，這表明了你已經(jīng)創(chuàng)建了很好的底層協(xié)議，AWS已經(jīng)把它作為服務(wù)提供。他們對此的期待與我所描述的吻合：通道聯(lián)通了所有的分布式系統(tǒng)，諸如DynamoDB, RedShift, S3等，它同時作為使用EC2進(jìn)行分布式流處理的基礎(chǔ)。

與ETL和數(shù)據(jù)倉庫的關(guān)系

我們再來聊聊數(shù)據(jù)倉庫。數(shù)據(jù)倉庫是清洗和歸一數(shù)據(jù)結(jié)構(gòu)用于支撐數(shù)據(jù)分析的倉庫。這是一個偉大的理念。對不熟悉數(shù)據(jù)倉庫概念的人來說，數(shù)據(jù)倉庫方法論包括了：周期性的從數(shù)據(jù)源抽取數(shù)據(jù)，把它們轉(zhuǎn)化為可理解的形式，然后把它導(dǎo)入中心數(shù)據(jù)倉庫。對于數(shù)據(jù)集中分析和處理，擁有高度集中的位置存放全部數(shù)據(jù)的原始副本是非常寶貴的資產(chǎn)。在高層級上，也許你抽取和加載數(shù)據(jù)的順序略微調(diào)整，這個方法論不會有太多變化,無論你使用傳統(tǒng)的數(shù)據(jù)倉庫Oracle還是Teradata或者Hadoop。

數(shù)據(jù)倉庫是極其重要的資產(chǎn)，它包含了原始的和規(guī)整的數(shù)據(jù)，但是實現(xiàn)此目標(biāo)的機(jī)制有點過時了。
對以數(shù)據(jù)為中心的組織關(guān)鍵問題是把原始的歸一數(shù)據(jù)聯(lián)結(jié)到數(shù)據(jù)倉庫。數(shù)據(jù)倉庫是批處理的基礎(chǔ)查詢：它們適用于各類報表和臨時性分析，特別是當(dāng)查詢包含了簡單的計數(shù)、聚合和過濾。但是如果一個批處理系統(tǒng)僅僅包含了原始的完整的數(shù)據(jù)的數(shù)據(jù)倉庫，這就意味著這些數(shù)據(jù)對于實時數(shù)據(jù)處理、搜索索引和系統(tǒng)監(jiān)控等實時的查詢是不可用的。

依我之見，ETL包括兩件事：首先，它是抽取和數(shù)據(jù)清洗過程–特別是釋放被鎖在組織的各類系統(tǒng)中的數(shù)據(jù)，移除系統(tǒng)專有的無用物。第二，依照數(shù)據(jù)倉庫的查詢重構(gòu)數(shù)據(jù)。例如使其符合關(guān)系數(shù)據(jù)庫類型系統(tǒng)，強(qiáng)制使用星號、雪花型模式，或者分解為高性能的柱狀格式等。合并這兩者是有困難的。這些規(guī)整的數(shù)據(jù)集應(yīng)當(dāng)可以在實時或低時延處理中可用，也可以在其它實施存儲系統(tǒng)索引。

在我看來，正是因為這個原因有了額外好處：使得數(shù)據(jù)倉庫ETL更具了組織級的規(guī)模。數(shù)據(jù)倉庫的精典問題是數(shù)據(jù)倉庫負(fù)責(zé)收集和清洗組織中各個組所生成的全部數(shù)據(jù)。各組織的動機(jī)是不同的，數(shù)據(jù)的生產(chǎn)者并不知曉在數(shù)據(jù)倉庫中數(shù)據(jù)的使用情況，最終產(chǎn)生的數(shù)據(jù)很難抽取，或者需要花費(fèi)規(guī)?；霓D(zhuǎn)化才可以轉(zhuǎn)化為可用的形式。當(dāng)然， 中心團(tuán)隊不可能恰到好處的掌握規(guī)模，使得這規(guī)模剛好與組織中其它團(tuán)隊相匹配，因此數(shù)據(jù)的覆蓋率常常差別很大，數(shù)據(jù)流是脆弱的同時變更是緩慢的。

較好的方法是有一個中心通道，日志和用于增加數(shù)據(jù)的定義良好的API。與通道集成的且提供良好的結(jié)構(gòu)化的數(shù)據(jù)文件的職責(zé)依賴于數(shù)據(jù)的生產(chǎn)者所生成的數(shù)據(jù)文件。這意味著在設(shè)計和實施其它系統(tǒng)時應(yīng)當(dāng)考慮數(shù)據(jù)的輸出以及輸出的數(shù)據(jù)如何轉(zhuǎn)化為結(jié)構(gòu)良好的形式并傳遞給中心通道。增加新的存儲系統(tǒng)倒是不必因為數(shù)據(jù)倉庫團(tuán)隊有一個中心結(jié)點需要集成而關(guān)注數(shù)據(jù)倉庫團(tuán)隊。數(shù)據(jù)倉庫團(tuán)隊僅需處理簡單的問題，例如從中心日志中加載結(jié)構(gòu)化的數(shù)據(jù)，向其它周邊系統(tǒng)實施個性化的數(shù)據(jù)轉(zhuǎn)化等。

如圖所示：當(dāng)考慮在傳統(tǒng)的數(shù)據(jù)倉庫之外增加額外的數(shù)據(jù)系統(tǒng)時，組織結(jié)構(gòu)的可擴(kuò)展性顯得尤為重要。例如，可以考慮為組織的完整的數(shù)據(jù)集提供搜索功能?；蛘咛峁┒壍臄?shù)據(jù)流監(jiān)控實時數(shù)據(jù)趨勢和告警。無論是這兩者中的哪一個，傳統(tǒng)的數(shù)據(jù)倉庫架構(gòu)甚至于Hadoop聚簇都不再適用。更糟的是，ETL的流程通道的目的就是支持?jǐn)?shù)據(jù)加載，然而ETL似乎無法輸出到其它的各個系統(tǒng)，也無法通過引導(dǎo)程序，使得這些外圍的系統(tǒng)的各個架構(gòu)成為適用于數(shù)據(jù)倉庫的重要資產(chǎn)。這就不難解釋為什么組織很難輕松的使用它的全部數(shù)據(jù)。反之，如果組織已建立起了一套標(biāo)準(zhǔn)的、結(jié)構(gòu)良好的數(shù)據(jù)，那么任何新的系統(tǒng)要使用這些數(shù)據(jù)僅僅需要與通道進(jìn)行簡單的集成就可以實現(xiàn)。
這種架構(gòu)引出了數(shù)據(jù)清理和轉(zhuǎn)化在哪個階段進(jìn)行的不同觀點：

由數(shù)據(jù)的生產(chǎn)者在把數(shù)據(jù)增加到公司全局日志之前。
在日志的實時轉(zhuǎn)化階段進(jìn)行，這將會產(chǎn)生一個新的轉(zhuǎn)化日志。
在向目標(biāo)系統(tǒng)加載數(shù)據(jù)時，做為加載過程的一部分進(jìn)行。
理想的模形是：由數(shù)據(jù)的生產(chǎn)者在把數(shù)據(jù)發(fā)布到日志之前對數(shù)據(jù)進(jìn)行清理。這樣可以確保數(shù)據(jù)的權(quán)威性，不需要維護(hù)其它的遺留物例如為數(shù)據(jù)產(chǎn)生的特殊處理代碼或者維護(hù)這些數(shù)據(jù)的其它的存儲系統(tǒng)。這些細(xì)節(jié)應(yīng)當(dāng)由產(chǎn)生數(shù)據(jù)的團(tuán)隊來處理，因為他們最了解他們自己的數(shù)據(jù)。這個階段所使用的任何邏輯都應(yīng)該是無損的和可逆的。

任何可以實時完成的增值轉(zhuǎn)化類型都應(yīng)當(dāng)基于原始日志進(jìn)行后期處理。這一過程包括了事件數(shù)據(jù)的會話流程，或者增加大眾感興趣的衍生字段。原始的日志仍然是可用的，但是這種實時處理產(chǎn)生的衍生日志包含了參數(shù)數(shù)據(jù)。

最終，只有針對目標(biāo)系統(tǒng)的聚合需要做了加載流程的一部分。它包括了把數(shù)據(jù)轉(zhuǎn)化成特定的星型或者雪花狀模式，從而用于數(shù)據(jù)倉庫的分析和報表。因為在這個階段，大部分自然的映射到傳統(tǒng)的ETL流程中，而現(xiàn)在它是在一個更加干凈和規(guī)整的數(shù)據(jù)流集在進(jìn)行的，它將會更加的簡單。

日志文件和事件

我們再來聊聊這種架構(gòu)的優(yōu)勢：它支持解耦和事件驅(qū)動的系統(tǒng)。

在網(wǎng)絡(luò)行業(yè)取得活動數(shù)據(jù)的典型方法是把它記為文本形式的日志，這些文本文件是可分解進(jìn)入數(shù)據(jù)倉庫或者Hadoop，用于聚合和查詢處理的。由此產(chǎn)生的問題與所有批處理的ETL的問題是相同的：它耦合了數(shù)據(jù)流進(jìn)入數(shù)據(jù)倉庫系統(tǒng)的能力和流程的調(diào)度。

在LinkedIn中，我們已經(jīng)以中心日志的方式構(gòu)建了事件數(shù)據(jù)處理。我們正在使用Kafka做為中心的、多訂閱者事件日志。我們已經(jīng)定義了數(shù)百種事件類型，每種類型都會捕獲用于特定類型動作的獨(dú)特的屬性。這將會覆蓋包括頁面視圖、表達(dá)式、搜索以及服務(wù)調(diào)用、應(yīng)用異常等方方面面。

為了進(jìn)一步理解這一優(yōu)勢：設(shè)想一個簡單的事務(wù)–在日志頁面顯示已發(fā)布的日志。這個日志頁面應(yīng)當(dāng)只包括顯示日志所需要的邏輯。然而，在相當(dāng)多的動態(tài)站點中，日志頁面常常變的添加了很多與顯示日志無關(guān)的邏輯。例如，我們將對如下的系統(tǒng)進(jìn)行集成：

需要把數(shù)據(jù)傳送到Hadoop和數(shù)據(jù)倉庫中用于離線數(shù)據(jù)處理。
需要對視圖進(jìn)行統(tǒng)計，確保視圖訂閱者不會攻擊一些內(nèi)容片段。
需要聚合這些視圖，視圖將用于作業(yè)發(fā)布者的分析頁面顯示。
需要記錄視圖以確保我們?yōu)樽鳂I(yè)推薦的使用者提供了恰當(dāng)?shù)挠∠蟾采w，我們不想一次次的重復(fù)同樣的事情。
推薦系統(tǒng)需要記錄日志用于正確的跟蹤作業(yè)的普及度。
等等。
不久，簡單的作業(yè)顯示變得相當(dāng)?shù)膹?fù)雜。我們增加了作業(yè)顯示的其它終端–移動終端應(yīng)用等–這些邏輯必須繼續(xù)存在，復(fù)雜度不斷的增加。更糟的是我們需要與之做接口交互的系統(tǒng)現(xiàn)在是錯綜復(fù)雜的–在為顯示日作業(yè)而工作的工程師們需要知曉多個其它系統(tǒng)和它們的特征，才可以確保它們被正確的集成了。這僅僅是問題的簡單版本，真實的的應(yīng)用系統(tǒng)只會更加的復(fù)雜。

“事件驅(qū)動”的模式提供了一種簡化這類問題的機(jī)制。作業(yè)顯示頁面現(xiàn)在只顯示作業(yè)并記錄與正在顯示的作業(yè)，作業(yè)訂閱者相關(guān)的其它屬性，和其它與作業(yè)顯示相關(guān)的其它有價值的屬性。每個與此相關(guān)的其它系統(tǒng)諸如推薦系統(tǒng)、安全系統(tǒng)、作業(yè)推送分析系統(tǒng)和數(shù)據(jù)倉庫，所有這些只是訂閱種子文件，并進(jìn)行它們的操作。顯示代碼并不需要關(guān)注其它的系統(tǒng)，也不需要因為增加了數(shù)據(jù)的消費(fèi)者而相應(yīng)的進(jìn)行變更。

構(gòu)建可伸縮的日志

當(dāng)然，把發(fā)布者與訂閱者分離不再是什么新鮮事了。但是如果你想要確保提交日志的行為就像多個訂閱者實時的分類日志那樣記錄網(wǎng)站發(fā)生的每件事時，可擴(kuò)展性就會成為你所面臨的首要挑戰(zhàn)。如果我們不能創(chuàng)建快速、高性價比和可擴(kuò)展性靈活的日志以滿足實際的可擴(kuò)展需求，把日志做為統(tǒng)一的集成機(jī)制不再是美好的想像，

人們普遍認(rèn)為分布式日志是緩慢的、重量經(jīng)的概念（并且通常會把它僅僅與“原數(shù)據(jù)”類型的使用聯(lián)系起來，對于這類使用Zookeeper可以適用）。但是深入實現(xiàn)并重點關(guān)注分類記錄大規(guī)模的數(shù)據(jù)流，這種需求是不切實際的。在LinkedIn, 我們現(xiàn)在每天通過Kafka運(yùn)行著超過600億個不同的消息寫入點(如果統(tǒng)計鏡相與數(shù)據(jù)中心之間的寫入，那么這個數(shù)字會是數(shù)千億。)

我們在Kafk中使用了一些小技巧來支持這種可擴(kuò)展性：

日志分片
通過批處理讀出和寫入優(yōu)化吞吐力
規(guī)避無用的數(shù)據(jù)復(fù)制。
為了確保水平可擴(kuò)展性，我們把日志進(jìn)行切片：

每個切片都是一篇有序的日志，但是各片之間沒有全局的次序（這個有別于你可能包含在消息中的掛鐘時間）。把消息分配到特定的日志片段這是由寫入者控制的，大部分使用者會通過用戶ID等鍵值來進(jìn)行分片。分片可以把日志追加到不存在協(xié)作的片段之間，也可以使系統(tǒng)的吞吐量與Kafka聚簇大小成線性比例關(guān)系。

每個分片都是通過可配置數(shù)量的復(fù)制品復(fù)制的，每個復(fù)制品都有分片的一份完全一致的拷貝。無論何時，它們中的任一個都可以做為主分片，如果主分片出錯了，任何一個復(fù)制品都可以接管并做為主分片。

缺少跨分片的全局順序是這個機(jī)制的局限性，但是我們不認(rèn)為它是最主要的。事實上，與日志的交互主要來源于成百上千個不同的流程，以致于對于它們的行為排一個總體的順序是沒什么意義的。相反，我們可以確保的是我們提供的每個分片都是按順序保留的。Kafka保證了追加到由單一發(fā)送者送出的特定分片會按照發(fā)送的順序依次處理。

日志，就像文件系統(tǒng)一樣，是容易優(yōu)化成線性可讀可寫的樣式的。日志可以把小的讀入和寫出組合成大的、高吞吐量的操作。Kafka一直至立于實現(xiàn)這一優(yōu)化目標(biāo)。批處理可以發(fā)生在由客戶端向服務(wù)器端發(fā)送數(shù)據(jù)、寫入磁盤;在服務(wù)器各端之間復(fù)制；數(shù)據(jù)傳遞給消費(fèi)者和確認(rèn)提交數(shù)據(jù)等諸多環(huán)節(jié)。

最終，Kafka使用簡單的二進(jìn)制形式維護(hù)內(nèi)存日志，磁盤日志和網(wǎng)絡(luò)數(shù)據(jù)傳送。這使得我們可以使用包括“0數(shù)據(jù)復(fù)制傳送”在內(nèi)的大量的優(yōu)化機(jī)制。

這些優(yōu)化的積累效應(yīng)是你常常進(jìn)行的寫出和讀入數(shù)據(jù)的操作可以在磁盤和網(wǎng)絡(luò)上得到支持，甚至于維護(hù)內(nèi)存以外的大量數(shù)據(jù)集。
到此為止，我只是描述從端到端數(shù)據(jù)復(fù)制的理想機(jī)制。但是在存儲系統(tǒng)中搬運(yùn)字節(jié)不是所要講述內(nèi)容的全部。最終我們發(fā)現(xiàn)日志是流的另一種說法，日志是流處理的核心。

但是，等等，什么是流處理呢？

如果你是90年代晚期或者21世紀(jì)初數(shù)據(jù)庫文化或者數(shù)據(jù)基礎(chǔ)架構(gòu)產(chǎn)品的愛好者，那么你就可能會把流處理與建創(chuàng)SQL引擎或者創(chuàng)建“箱子和箭頭”接口用于事件驅(qū)動的處理等聯(lián)系起來。

如果你關(guān)注開源數(shù)據(jù)庫系統(tǒng)的大量出現(xiàn)，你就可能把流處理和一些開源數(shù)據(jù)庫系統(tǒng)關(guān)聯(lián)起來，這些系統(tǒng)包括了：Storm,Akka,S4和Samza.但是大部分人會把這些系統(tǒng)作為異步消息處理系統(tǒng)，這些系統(tǒng)與支持群集的遠(yuǎn)程過程調(diào)用層的應(yīng)用沒什么差別（而事實上在開源數(shù)據(jù)庫系統(tǒng)領(lǐng)域某些方面確實如此）。

這些視圖都有一些局限性。流處理與SQL是無關(guān)的。它也局限于實時流處理。不存在內(nèi)在的原因限制你不能處理昨天的或者一個月之前的流數(shù)據(jù)，且使用多種不同的語言表達(dá)計算。
我把流處理視為更廣泛的概念：持續(xù)數(shù)據(jù)流處理的基礎(chǔ)架構(gòu)。我認(rèn)為計算模型可以像MapReduce或者分布式處理架構(gòu)一樣普遍，但是有能力處理低時延的結(jié)果。

處理模型的實時驅(qū)動是數(shù)據(jù)收集方法。成批收集的數(shù)據(jù)是分批處理的。數(shù)據(jù)是不斷收集的，它也是按順序不斷處理的。

美國的統(tǒng)計調(diào)查就是成批收集數(shù)據(jù)的良好典范。統(tǒng)計調(diào)查周期性的開展，通過挨門挨戶的走訪，使用蠻力發(fā)現(xiàn)和統(tǒng)計美國的公民信息。1790年統(tǒng)計調(diào)查剛剛開始時這種方式是奏效的。那時的數(shù)據(jù)收集是批處理的，它包括了騎著馬悠閑的行進(jìn)，把信息寫在紙上，然后把成批的記錄傳送到人們統(tǒng)計數(shù)據(jù)的中心站點?，F(xiàn)在，在描述這個統(tǒng)計過程時，人們立即會想到為什么我們不保留出生和死亡的記錄，這樣就可以產(chǎn)生人口統(tǒng)計信息這些信息或是持續(xù)的或者是其它維度的。

這是一個極端的例子，但是大量的數(shù)據(jù)傳送處理仍然依賴于周期性的轉(zhuǎn)儲，批量轉(zhuǎn)化和集成。處理大容量轉(zhuǎn)儲的唯一方法就是批量的處理。但是隨著這些批處理被持續(xù)的供給所取代，人們自然而然的開始不間斷的處理以平滑的處理所需資源并且消除延遲。

例如LinkedIn幾乎沒有批量數(shù)據(jù)收集。大部分的數(shù)據(jù)或者是活動數(shù)據(jù)或者是數(shù)據(jù)庫變更，這兩者都是不間斷發(fā)生的。事實上，你可以想到的任何商業(yè)，正如：Jack Bauer告訴我們的，低層的機(jī)制都是實時發(fā)生的不間斷的流程事件。數(shù)據(jù)是成批收集的，它總是會依賴于一些人為的步驟，或者缺少數(shù)字化或者是一些自動化的非數(shù)字化流程處理的遺留信息。當(dāng)傳送和處理這些數(shù)據(jù)的機(jī)制是郵件或者人工的處理時，這一過程是非常緩慢的。首輪自動化總是保持著最初的處理形式，它常常會持續(xù)相當(dāng)長的時間。

每天運(yùn)行的批量處理作業(yè)常常是模擬了一種一天的窗口大小的不間斷計算。當(dāng)然，低層的數(shù)據(jù)也經(jīng)常變化。在LinkedIn,這些是司空見貫的，并且使得它們在Hadoop運(yùn)轉(zhuǎn)的機(jī)制是有技巧的，所以我們實施了一整套管理增量的Hadoop工作流的架構(gòu)。

由此看來，對于流處理可以有不同的觀點。流處理包括了在底層數(shù)據(jù)處理的時間概念，它不需要數(shù)據(jù)的靜態(tài)快照，它可以產(chǎn)生用戶可控頻率的輸出，而不用等待數(shù)據(jù)集的全部到達(dá)。從這個角度上講，流處理就是廣義上的批處理，隨著實時數(shù)據(jù)的流行，會兒更加普遍。

這就是為什么從傳統(tǒng)的視角看來流處理是利基應(yīng)用。我個人認(rèn)為最大的原因是缺少實時數(shù)據(jù)收集使得不間斷的處理成為了學(xué)術(shù)性的概念。

我想缺少實時數(shù)據(jù)收集就像是商用流處理系統(tǒng)注定的命運(yùn)。他們的客戶仍然需要處理面向文件的、每日批量處理ETL和數(shù)據(jù)集成。公司建設(shè)流處理系統(tǒng)關(guān)注的是提供附著在實時數(shù)據(jù)流的處理引擎，但是最終當(dāng)時極少數(shù)人真正使用了實時數(shù)據(jù)流。事實上，在我在LinkedIn工作的初期，有一家公司試圖把一個非常棒的流處理系統(tǒng)銷售給我們，但是因為當(dāng)時我們的全部數(shù)據(jù)都按小時收集在的文件里，當(dāng)時我們提出的最好的應(yīng)用就是在每小時的最后把這些文件輸入到流處理系統(tǒng)中。他們注意到這是一個普遍性的問題。這些異常證明了如下規(guī)則：流處理系統(tǒng)要滿足的重要商業(yè)目標(biāo)之一是：財務(wù)， 它是實時數(shù)據(jù)流已具備的基準(zhǔn)，并且流處理已經(jīng)成為了瓶頸。

甚至于在一個健康的批處理系統(tǒng)中，流處理作為一種基礎(chǔ)架構(gòu)的實際應(yīng)用能力是相當(dāng)廣泛的。它跨越了實時數(shù)據(jù)請求-應(yīng)答服務(wù)和離線批量處理之間的鴻溝。現(xiàn)在的互聯(lián)網(wǎng)公司，大約25%的代碼可以劃分到這個類型中。

最終這些日志解決了流處理中絕大部分關(guān)鍵的技術(shù)問題。在我看來，它所解決的最大的問題是它使得多訂閱者可以獲得實時數(shù)據(jù)。對這些技術(shù)細(xì)節(jié)感興趣的朋友，我們可以用開源的Samza,它是基于這些理念建設(shè)的一個流處理系統(tǒng)。這些應(yīng)用的更多技術(shù)細(xì)節(jié)我們在此文檔中有詳細(xì)的描述。

數(shù)據(jù)流圖

流處理最有趣的角度是它與流處理系統(tǒng)內(nèi)部無關(guān)，但是與之密切相關(guān)的是如何擴(kuò)展了我們談到的早期數(shù)據(jù)集成的數(shù)據(jù)獲取的理念。我們主要討論了基礎(chǔ)數(shù)據(jù)的獲取或日志–事件和各類系統(tǒng)執(zhí)行中產(chǎn)生的數(shù)據(jù)等。但是流處理允許我們包括了計算其它數(shù)據(jù)的數(shù)據(jù)。這些衍生的數(shù)據(jù)在消費(fèi)者看來與他們計算的原始數(shù)據(jù)沒什么差別。這些衍生的數(shù)據(jù)可以按任意的復(fù)雜度進(jìn)行壓縮。

讓我們再深入一步。我們的目標(biāo)是：流處理作業(yè)可以讀取任意的日志并把日志寫入到日志或者其它的系統(tǒng)中。他們用于輸入輸出的日志把這些處理關(guān)聯(lián)到一組處理過程中。事實上，使用這種樣式的集中日志，你可以把組織全部的數(shù)據(jù)抓取、轉(zhuǎn)化和工作流看成是一系列的日志和寫入它們的處理過程。

流處理器根本不需要理想的框架：它可能是讀寫日志的任何處理器或者處理器集合，但是額外的基礎(chǔ)設(shè)施和輔助可以提供幫助管理處理代碼。

日志集成的目標(biāo)是雙重的：

首先，它確保每個數(shù)據(jù)集都有多個訂閱者和有序的。讓我們回顧一下狀態(tài)復(fù)制原則來記住順序的重要性。為了使這個更加具體，設(shè)想一下從數(shù)據(jù)庫中更新數(shù)據(jù)流–如果在處理過程中我們把對同一記錄的兩次更新重新排序，可能會產(chǎn)生錯誤的輸出。 TCP之類的鏈接僅僅局限于單一的點對點鏈接，這一順序的持久性要優(yōu)于TCP之類的鏈接，它可以在流程處理失敗和重連時仍然存在。

第二，日志提供了流程的緩沖。這是非?；A(chǔ)的。如果處理流程是非同步的，那么上行生成流數(shù)據(jù)的作業(yè)比下行消費(fèi)流數(shù)據(jù)的作業(yè)運(yùn)行的更快。這將會導(dǎo)致處理流程阻塞，或者緩沖數(shù)據(jù)，或者丟棄數(shù)據(jù)。丟棄數(shù)據(jù)并不是可行的方法，阻塞將會導(dǎo)致整個流程圖立即停止。 日志實際上是一個非常大的緩沖，它允許流程重啟或者停止但不會影響流程圖其它部分的處理速度。如果要把數(shù)據(jù)流擴(kuò)展到更大規(guī)模的組織，如果處理作業(yè)是由多個不同的團(tuán)隊提供的，這種隔離性是極其重的。我們不能容忍一個錯誤的作業(yè)引發(fā)后臺的壓力，這種壓力會使得整個處理流程停止。

Storm和Sama這兩者都是按非同步方式設(shè)計的，可以使用Kafka或者其它類似的系統(tǒng)作為它們的日志。

有狀態(tài)的實時流處理

一些實時流處理在轉(zhuǎn)化時是無狀態(tài)的記錄。在流處理中大部分的應(yīng)用會是相當(dāng)復(fù)雜的統(tǒng)計、聚合、不同窗口之間的關(guān)聯(lián)。例如有時人們想擴(kuò)大包含用戶操作信息的事件流（一系列的單擊動作）–實際上關(guān)聯(lián)了用戶的單擊動作流與用戶的賬戶信息數(shù)據(jù)庫。不變的是這類流程最終會需要由處理器維護(hù)的一些狀態(tài)信息。例如數(shù)據(jù)統(tǒng)計時，你需要統(tǒng)計到目前為止需要維護(hù)的計數(shù)器。如果處理器本身失敗了，如何正確的維護(hù)這些狀態(tài)信息呢？

最簡單的替換方案是把這些狀態(tài)信息保存在內(nèi)存中。但是如果流程崩潰，它就會丟失中間狀態(tài)。如果狀態(tài)是按窗口維護(hù)的，流程就會回退到日志中窗口開始的時間點上。但是，如果統(tǒng)計是按小時進(jìn)行的，那么這種方式就會變得不可行。

另一個替換方案是簡單的存儲所有的狀態(tài)信息到遠(yuǎn)程的存儲系統(tǒng)，通過網(wǎng)絡(luò)與這些存儲關(guān)聯(lián)起來。這種機(jī)制的問題是沒有本地數(shù)據(jù)和大量的網(wǎng)絡(luò)間通信。

我們?nèi)绾沃С痔幚磉^程可以像表一樣分區(qū)的數(shù)據(jù)呢?

回顧一下關(guān)于表和日志二相性的討論。這一機(jī)制提供了工具把數(shù)據(jù)流轉(zhuǎn)化為與處理過程協(xié)同定位的表，同時也提供了這些表的容錯處理的機(jī)制。

流處理器可以把它的狀態(tài)保存在本地的表或索引–bdb,或者leveldb,甚至于類似于Lucene 或fastbit一樣不常見的索引。這些內(nèi)容存儲在它的輸入流中（或許是使用任意的轉(zhuǎn)化）。生成的變更日志記錄了本地的索引，它允許存儲事件崩潰、重啟等的狀態(tài)信息。流處理提供了通用的機(jī)制用于在本地輸入流數(shù)據(jù)的隨機(jī)索引中保存共同分片的狀態(tài)。

當(dāng)流程運(yùn)行失敗時，它會從變更日志中恢復(fù)它的索引。每次備份時，日志把本地狀態(tài)轉(zhuǎn)化成一系列的增量記錄。

這種狀態(tài)管理的方法有一個優(yōu)勢是把處理器的狀態(tài)也做為日志進(jìn)行維護(hù)。我們可以把這些日志看成與數(shù)據(jù)庫表相對應(yīng)的變更日志。事實上，這些處理器同時維護(hù)著像共同分片表一樣的表。因為這些狀態(tài)它本身就是日志，其它的處理器可以訂閱它。如果流程處理的目標(biāo)是更新結(jié)點的最后狀態(tài)，這種狀態(tài)又是流程的輸出，那么這種方法就顯得尤為重要。

為了數(shù)據(jù)集成，與來自數(shù)據(jù)庫的日志關(guān)聯(lián)，日志和數(shù)據(jù)庫表的二象性就更加清晰了。變更日志可以從數(shù)據(jù)庫中抽取出來，日志可以由不同的流處理器（流處理器用于關(guān)聯(lián)不同的事件流）按不同的方式進(jìn)行索引。

我們可以列舉在Samza中有狀態(tài)流處理管理的更多細(xì)節(jié)和大量實用的例子。

日志壓縮

當(dāng)然，我們不能奢望保存全部變更的完整日志。除非想要使用無限空間，日志不可能完全清除。為了澄清它，我們再來聊聊Kafka的實現(xiàn)。在Kafka中,清理有兩種選擇，這取決于數(shù)據(jù)是否包括關(guān)鍵更新和事件數(shù)據(jù)。對于事件數(shù)據(jù)，Kafka支持僅維護(hù)一個窗口的數(shù)據(jù)。通常，配置需要一些時間，窗口可以按時間或空間定義。雖然對于關(guān)鍵數(shù)據(jù)而言，完整日志的重要特征是你可以重現(xiàn)源系統(tǒng)的狀態(tài)信息，或者在其它的系統(tǒng)重現(xiàn)。

隨著時間的推移，保持完整的日志會使用越來越多的空間，重現(xiàn)所耗費(fèi)的時間越來越長。因些在Kafka中,我們支持不同類型的保留。我們移除了廢棄的記錄(這些記錄的主鍵最近更新過)而不是簡單的丟棄舊日志。我們?nèi)匀槐ＷC日志包含了源系統(tǒng)的完整備份，但是現(xiàn)在我們不再重現(xiàn)原系統(tǒng)的全部狀態(tài)，而是僅僅重現(xiàn)最近的狀態(tài)。我們把這一特征稱為日志壓縮。

我們最后要討論的是在線數(shù)據(jù)系統(tǒng)設(shè)計中日志的角色。

在分布式數(shù)據(jù)庫數(shù)據(jù)流中日志的角色和在大型組織機(jī)構(gòu)數(shù)據(jù)完整中日志的角色是相似的。在這兩個應(yīng)用場景中，日志是對于數(shù)據(jù)源是可靠的，一致的和可恢復(fù)的。組織如果不是一個復(fù)雜的分布式數(shù)據(jù)系統(tǒng)呢，它究竟是什么？

如果換個角度，你可以看到把整個組織系統(tǒng)和數(shù)據(jù)流看做是單一的分布式數(shù)據(jù)系統(tǒng)。你可以把所有的子查詢系統(tǒng)（諸如Redis, SOLR,Hive表等）看成是數(shù)據(jù)的特定索引。你可以把Storm或Samza一樣的流處理系統(tǒng)看成是發(fā)展良好的觸發(fā)器和視圖具體化機(jī)制。我已經(jīng)注意到，傳統(tǒng)的數(shù)據(jù)庫管理人員非常喜歡這樣的視圖，因為它最終解釋了這些不同的數(shù)據(jù)系統(tǒng)到底是做什么用的–它們只是不同的索引類型而已。

不可否認(rèn)這類數(shù)據(jù)庫系統(tǒng)現(xiàn)在大量的出現(xiàn)，但是事實上，這種復(fù)雜性一直都存在。即使是在關(guān)系數(shù)據(jù)庫系統(tǒng)的鼎盛時期，組織中有大量的關(guān)系數(shù)據(jù)庫系統(tǒng)?；蛟S自大型機(jī)時代開始，所有的數(shù)據(jù)都存儲在相同的位置，真正的集成是根本不存在的。存在多種外在需求，需要把數(shù)據(jù)分解成多個系統(tǒng)，這些外在需求包括：規(guī)模、地理因素、安全性，性能隔離是最常見的因素。這些需求都可以由一個優(yōu)質(zhì)的系統(tǒng)實現(xiàn)：例如，組織可以使用單一的Hadoop聚簇，它包括了全部的數(shù)據(jù)，可以服務(wù)于大型的和多樣性的客戶。

因此在向分布式系統(tǒng)變遷的過程中，已經(jīng)存在一種處理數(shù)據(jù)的簡便的方法：把大量的不同系統(tǒng)的小的實例聚合成為大的聚簇。許多的系統(tǒng)還不足以支持這一方法：因為它們不夠安全，或者性能隔離性得不到保證，或者規(guī)模不符合要求。不過這些問題都是可以解決的。

依我之見，不同系統(tǒng)大量出現(xiàn)的原因是建設(shè)分布式數(shù)據(jù)庫系統(tǒng)很困難。通過削減到單一的查詢或者用例，每個系統(tǒng)都可以把規(guī)?？刂频揭子趯崿F(xiàn)的程度。但是運(yùn)行這些系統(tǒng)產(chǎn)生的復(fù)雜度依然很高。

未來這類問題可能的發(fā)展趨勢有三種：

第一種可能是保持現(xiàn)狀：孤立的系統(tǒng)還會或長或短的持續(xù)一段時間。這是因為建設(shè)分布式系統(tǒng)的困難很難克服，或者因為孤立系統(tǒng)的獨(dú)特性和便捷性很難達(dá)到?；谶@些原因，數(shù)據(jù)集成的核心問題仍然是如何恰當(dāng)?shù)氖褂脭?shù)據(jù)。因此，集成數(shù)據(jù)的外部日志非常的重要。

第二種可能是重構(gòu)：具備通用性的單一的系統(tǒng)逐步融合多個功能形成超極系統(tǒng)。這個超級系統(tǒng)表面看起來類似關(guān)系數(shù)據(jù)庫系統(tǒng)，但是在組織中你使用時最大的不同是你只需要一個大的系統(tǒng)而不是無數(shù)個小系統(tǒng)。在這個世界里，除了在系統(tǒng)內(nèi)已解決的這個問題不存在什么真正的數(shù)據(jù)集成問題。我想這是因為建設(shè)這樣的系統(tǒng)的實際困難。

雖然另一種可能的結(jié)果對于工程師來說是很有吸引力的。新一代數(shù)據(jù)庫系統(tǒng)的特征之一是它們是完全開源的。開源提供了第三種可能性 ：數(shù)據(jù)基礎(chǔ)架構(gòu)不必打包成服務(wù)集或者面向應(yīng)用的系統(tǒng)接口。在Java棧中，你可以看到在一定程度上，這種狀況已經(jīng)發(fā)生了。

分類計價嗎？

Zookeeper用于處理多個系統(tǒng)之間的協(xié)調(diào)，或許會從諸如Helix 或者Curator等高級別的抽象中得到一些幫助。
Mesos和YARN用于處理流程可視化和資源管理。
Lucene和LevelDB等嵌入式類庫做為索引。
Netty,Jetty和Finagle,rest.li等封裝成高級別的用于處理遠(yuǎn)程通信。
Avro,Protocol Buffers,Thrift和umpteen zillion等其它類庫用于處理序列化。
Kafka和Bookeeper提供支持日志。
如果你把這些堆放在一起，換個角度看，它有點像是簡化版的分布式數(shù)據(jù)庫系統(tǒng)工程。你可以把這些拼裝在一起，創(chuàng)建大量的可能的系統(tǒng)。顯而易見，現(xiàn)在探討的不是最終用戶所關(guān)心的API或者如何實現(xiàn)，而是在不斷多樣化和模塊化的過程中如何設(shè)計實現(xiàn)單一系統(tǒng)的途徑。因為隨著可靠的、靈活的模塊的出現(xiàn)，實施分布式系統(tǒng)的時間周期由年縮減為周，聚合形成大型整體系統(tǒng)的壓力逐步消失。
日志文件在系統(tǒng)結(jié)構(gòu)中的地位

那些提供外部日志的系統(tǒng)如今已允許個人電腦拋棄他們自身復(fù)雜的日志系統(tǒng)轉(zhuǎn)而使用共享日志。在我看來，日志可以做到以下事情：

通過對節(jié)點的并發(fā)更新的排序處理數(shù)據(jù)的一致性（無論在及時還是最終情況下）
提供節(jié)點之間的數(shù)據(jù)復(fù)制
提供”commit“語法（只有當(dāng)寫入器確保數(shù)據(jù)不會丟失時才會寫入）
位系統(tǒng)提供外部的數(shù)據(jù)訂閱資源
提供存儲失敗的復(fù)制操作和引導(dǎo)新的復(fù)制操作的能力
處理節(jié)點間的數(shù)據(jù)平衡
這實際上是一個數(shù)據(jù)分發(fā)系統(tǒng)最重要的部分，剩下的大部分內(nèi)容與終端調(diào)用的API和索引策略相關(guān)。這正是不同系統(tǒng)間的差異所在，例如：一個全文本查詢語句需要查詢所有的分區(qū)，而一個主鍵查詢只需要查詢負(fù)責(zé)鍵數(shù)據(jù)的單個節(jié)點就可以了。

下面我們來看下該系統(tǒng)是如何工作的。系統(tǒng)被分為兩個邏輯區(qū)域：日志和服務(wù)層。日志按順序捕獲狀態(tài)變化，服務(wù)節(jié)點存儲索引提供查詢服務(wù)需要的所有信息（鍵-值的存儲可能以B-tree或SSTable的方式進(jìn)行，而搜索系統(tǒng)可能存在與之相反的索引）。寫入器可以直接訪問日志，盡管需要通過服務(wù)層代理。在寫入日志的時候會產(chǎn)生邏輯時間戳（即log中的索引），如果系統(tǒng)是分段式的，那么就會產(chǎn)生與段數(shù)目相同數(shù)量的日志文件和服務(wù)節(jié)點，這里的數(shù)量和機(jī)器數(shù)量可能會有較大差距。

服務(wù)節(jié)點訂閱日志信息并將寫入器按照日志存儲的順序盡快應(yīng)用到它的本地索引上。

客戶端只要在查詢語句中提供對應(yīng)的寫入器的時間戳，它就可以從任何節(jié)點中獲取”讀寫“語義。服務(wù)節(jié)點收到該查詢語句后會將其中的時間戳與自身的索引比較，如果必要，服務(wù)節(jié)點會延遲請求直到對應(yīng)時間的索引建立完畢，以免提供舊數(shù)據(jù)。

服務(wù)節(jié)點或許根本無需知道”控制“或”投標(biāo)選擇（leader election）“的概念，對很多簡單的操作，服務(wù)節(jié)點可以愛完全脫離領(lǐng)導(dǎo)的情況下提供服務(wù)，日志即是信息的來源。

分發(fā)系統(tǒng)所需要做的其中一個比較復(fù)雜的工作，就是修復(fù)失敗節(jié)點并移除幾點之間的隔離。保留修復(fù)的數(shù)據(jù)并結(jié)合上各區(qū)域內(nèi)的數(shù)據(jù)快照是一種較為典型的做法，它與保留完整的數(shù)據(jù)備份并從垃圾箱內(nèi)回收日志的做法幾乎等價。這就使得服務(wù)層簡單了很多，日志系統(tǒng)也更有針對性。

有了這個日志系統(tǒng)，你可以訂閱到API，這個API提供了把ETL提供給其它系統(tǒng)的數(shù)據(jù)內(nèi)容。事實上，許多系統(tǒng)都可以共享相同的日志同時提供不同的索引，如下所示：

這樣一個以日志為中心的系統(tǒng)是如何做到既數(shù)據(jù)流的提供者又同時加載其它系統(tǒng)的數(shù)據(jù)的呢？因為流處理器既可以消費(fèi)多個輸入的數(shù)據(jù)流，隨后又可以通過其它系統(tǒng)對數(shù)據(jù)做索引為它們提供服務(wù)。

這個系統(tǒng)的視圖可以清晰的分解到日志和查詢API,因為它允許你從系統(tǒng)的可用性和一致性角度分解查詢的特征。這可以幫助我們對系統(tǒng)進(jìn)行分解，并理解那些并沒按這種方式設(shè)計實施的系統(tǒng)。

雖然Kafka和Bookeeper都是一致性日志，但這不是必須的，也沒什么意義。你可以輕松的把Dynamo之類的數(shù)據(jù)構(gòu)分解為一致性的AP日志和鍵值對服務(wù)層。這樣的日志使用起來靈活，因為它重傳了舊消息，像Dynamo一樣，這樣的處理取決于消息的訂閱者。

在很多人看來，在日志中另外保存一份數(shù)據(jù)的完整復(fù)本是一種浪費(fèi)。事實上，雖然有很多因素使得這件事并不困難。首先，日志可以是一種有效的存儲機(jī)制。我們在Kafka生產(chǎn)環(huán)境的服務(wù)器上存儲了5 TB的數(shù)據(jù)。同時有許多的服務(wù)系統(tǒng)需要更多的內(nèi)存來提供有效的數(shù)據(jù)服務(wù)，例如文本搜索，它通常是在內(nèi)存中的。服務(wù)系統(tǒng)同樣也需樣硬盤的優(yōu)化。例如，我們的實時數(shù)據(jù)系統(tǒng)或者在內(nèi)存外提供服務(wù)或者使用固態(tài)硬盤。相反，日志系統(tǒng)只需要線性的讀寫，因此，它很樂于使用TB量級的硬盤。最終，如上圖所示，由多個系統(tǒng)提供的數(shù)據(jù)，日志的成本分?jǐn)偟蕉鄠€索引上，這種聚合使得外部日志的成本降到了最低點。

LinkedIn就是使用了這種方式實現(xiàn)它的多個實時查詢系統(tǒng)的。這些系統(tǒng)提供了一個數(shù)據(jù)庫（使用數(shù)據(jù)總線做為日志摘要，或者從Kafka去掉專用的日志），這些系統(tǒng)在頂層數(shù)據(jù)流上還提供了特殊的分片、索引和查詢功能。這也是我們實施搜索、社交網(wǎng)絡(luò)和OLAP查詢系統(tǒng)的方式。事實上這種方式是相當(dāng)普遍的：為多個用于實時服務(wù)的服務(wù)系統(tǒng)提供單一的數(shù)據(jù)（這些來自Hadoop的數(shù)據(jù)或是實時的或是衍生的）。這種方式已被證實是相當(dāng)簡潔的。這些系統(tǒng)根本不需要外部可寫入的API，Kafka和數(shù)據(jù)庫被用做系統(tǒng)的記錄和變更流，通過日志你可以查詢系統(tǒng)。持有特定分片的結(jié)點在本地完成寫操作。這些結(jié)點盲目的把日志提供的數(shù)據(jù)轉(zhuǎn)錄到它們自己的存儲空間中。通過回放上行流日志可以恢復(fù)轉(zhuǎn)錄失敗的結(jié)點。

這些系統(tǒng)的程度則取決于日志的多樣性。一個完全可靠的系統(tǒng)可以用日志來對數(shù)據(jù)分片、存儲結(jié)點、均衡負(fù)載，以及用于數(shù)據(jù)一致性和數(shù)據(jù)復(fù)制等多方面。在這一過程中，服務(wù)層實際上只不過是一種緩存機(jī)制，這種緩存機(jī)制允許直接寫入日志的流處理。

結(jié)束語

如果你對于本文中所談到的關(guān)于日志的大部內(nèi)容，如下內(nèi)容是您可以參考的其它資料。對于同一事務(wù)人們會用不同的術(shù)語，這會讓人有一些困惑，從數(shù)據(jù)庫系統(tǒng)到分布式系統(tǒng)，從各類企業(yè)級應(yīng)用軟件到廣闊的開源世界。無論如何，在大方向上還是有一些共同之處。