深度解析LinkedIn大數據平台
http://newshtml.iheima.com/2014/0812/144872.html日誌幾乎與計算機同時產生的，它是許多分佈式數據系統和實時應用結構的核心。但是大多數軟件工程師對他們不是很熟悉。在這裡，我們將聚焦LinkedIn大數據平台的深度解析，探討日誌是什麼，如何在數據集成、實時處理和系統構建中使用日誌等內容。
我在六年前的一個令人興奮的時刻加入到LinkedIn公司。從那個時候開始我們就破解單一的、集中式數據庫的限制，並且啟動到特殊的分佈式系統套件的轉換。這是一件令人興奮的事情：我們構建、部署，而且直到今天仍然在運行的分佈式圖形數據庫、分佈式搜索後端、Hadoop安裝以及第一代和第二代鍵值數據存儲。
從這一切裡我們體會到的最有益的事情是我們構建的許多東西的核心裡都包含一個簡單的理念：日誌。有時候也稱作預先寫入日誌或者提交日誌或者事務日誌，日誌幾乎在計算機產生的時候就存在，同時它還是許多分佈式數據系統和實時應用結構的核心。
不懂得日誌，你就不可能完全懂得數據庫，NoSQL存儲，鍵值存儲，複製，paxos，Hadoop，版本控制以及幾乎所有的軟件系統;然而大多數軟件工程師對它們不是很熟悉。我願意改變這種現狀。在這篇博客文章裡，我將帶你瀏覽你必須瞭解的有關日誌的所有的東西，包括日誌是什麼，如何在數據集成、實時處理和系統構建中使用日誌等。
第一部分：日誌是什麼?
日誌是一種簡單的不能再簡單的存儲抽象。它是一個只能增加的，完全按照時間排序的一系列記錄。日誌看起來如下：
我們可以給日誌的末尾添加記錄，並且可以從左到右讀取日誌記錄。每一條記錄都指定了一個唯一的有一定順序的日誌記錄編號。
日誌記錄的排序是由「時間」來確定的，這是因為位於左邊的日誌記錄比位於右邊的要早些。日誌記錄編號可以看作是這條日誌記錄的「時間戳」。在一開始就把這種排序說成是按時間排序顯得有點多餘 ，不過 ，與任何一個具體的物理時鐘相比，時間屬性是非常便於使用的屬性。在我們運行多個分佈式系統的時候，這個屬性就顯得非常重要。
對於這篇討論的目標而言，日誌記錄的內容和格式不怎麼重要。另外提醒一下，在完全耗盡存儲空間的情況下，我們不可能再給日誌添加記錄。稍後我們將會提到這個問題。
日誌並不是完全不同於文件或者數據表的。文件是由一系列字節組成，表是由一系列記錄組成，而日誌實際上只是按照時間順序存儲記錄的 一種數據表或者文件。
此時，你可能奇怪為什麼要討論這麼簡單的事情呢?不同環境下的一個只可增加的有一定順序的日誌記錄是怎樣與數據系統關聯起來的呢?答案是日誌有其特定的應用目標：它記錄了什麼時間發生了什麼事情。 而對分佈式數據系統許多方面而言， 這才是問題的真正核心。
不過，在我們進行更加深入的討論之前，讓我先澄清有些讓人混淆的概念。每個編程人員都熟悉另一種日誌記錄——應用使用syslog或者log4j可能寫入到本地文件裡的沒有結構的錯誤信息或者追蹤信息。為了區分開來，我們把這種情形的日誌記錄稱為「應用日誌記錄」。應用日誌記錄是我在這兒所說的日誌的一種低級的變種。最大的區別是：文本日誌意味著主要用來方便人們閱讀，而我所說明的「日誌」或者「數據日誌」的建立是方便程序訪問。
(實際上，如果你對它進行深入的思考，那麼人們讀取某個機器上的日誌這種理念有些不順應時代潮流。當涉及到許多服務和服務器的時候，這種方法很快就變成一個難於管理的方式，而且為了認識多個機器的行為，日誌的目標很快就變成查詢和圖形化這些行為的輸入了——對多個機器的某些行為而言，文件裡的英文形式的文本同這兒所描述的這種結構化的日誌相比幾乎就不適合了。)
數據庫日誌
我不知道日誌概念起源於何處-可能它就像二進制搜索一樣：發明者認為它太簡單而不能當作一項發明。它早在IBM的系統R出現時候就出現了。數據庫裡的用法是在崩潰的時候用它來同步各種數據結構和索引。為了保證操作的原子性和持久性，在對數據庫維護的所有各種數據結構做更改之前，數據庫把即將修改的信息謄寫到日誌裡。日誌記錄了發生了什麼，而且其中的每個表或者索引都是一些數據結構或者索引的歷史映射。由於日誌是即刻永久化的，可以把它當作崩潰發生時用來恢復其他所有永久性結構的可信賴數據源。
隨著時間的推移，日誌的用途從實現ACID細節成長為數據庫間複製數據的一種方法。利用日誌的結果就是發生在數據庫上的更改順序與遠端複製數據庫上的更改順序需要保持完全同步。
Oracle，MySQL 和PostgreSQL都包括用於給備用的複製數據庫傳輸日誌的日誌傳輸協議。Oracle還把日誌產品化為一個通用的數據訂閱機制，這樣非Oracle數據訂閱用戶就可以使用XStreams和GoldenGate訂閱數據了，MySQL和PostgreSQL上的類似的實現則成為許多數據結構的關鍵組件。
正是由於這樣的起源，機器可識別的日誌的概念大部分都被侷限在數據庫內部。日誌用做數據訂閱的機制似乎是偶然出現的，不過要把這種 抽象用於支持所有類型的消息傳輸、數據流和實時數據處理是不切實際的。
分佈式系統日誌
日誌解決了兩個問題：更改動作的排序和數據的分發，這兩個問題在分佈式數據系統裡顯得尤為重要。協商出一致的更改動作的順序(或者說保持各個子系統本身的做法，但可以進行存在副作用的數據拷貝)是分佈式系統設計的核心問題之一。
以日誌為中心實現分佈式系統是受到了一個簡單的經驗常識的啟發，我把這個經驗常識稱為狀態機複製原理：如果兩個相同的、確定性的進程從同一狀態開始，並且以相同的順序獲得相同的輸入，那麼這兩個進程將會生成相同的輸出，並且結束在相同的狀態。
這也許有點難以理解，讓我們更加深入的探討，弄懂它的真正含義。
確定性意味著處理過程是與時間無關的，而且任何其他「外部的「輸入不會影響到處理結果。例如，如果一個程序的輸出會受到線程執行的具體順序影響，或者受到gettimeofday調用、或者其他一些非重複性事件的影響，那麼這樣的程序一般最有可能被認為是非確定性的。
進程狀態是進程保存在機器上的任何數據，在進程處理結束的時候，這些數據要麼保存在內存裡，要麼保存在磁盤上。
以相同的順序獲得相同輸入的地方應當引起注意-這就是引入日誌的地方。這兒有一個重要的常識：如果給兩段確定性代碼相同的日誌輸入，那麼它們就會生成相同的輸出。
分佈式計算這方面的應用就格外明顯。你可以把用多台機器一起執行同一件事情的問題縮減為實現分佈式一致性日誌為這些進程輸入的問題。這兒日誌的目的是把所有非確定性的東西排除在輸入流之外，來確保每個複製進程能夠同步地處理輸入。
當你理解了這個以後，狀態機複製原理就不再複雜或者說不再深奧了：這或多或少的意味著「確定性的處理過程就是確定性的」。不管怎樣，我都認為它是分佈式系統設計裡較常用的工具之一。
這種方式的一個美妙之處就在於索引日誌的時間戳就像時鐘狀態的一個副本——你可以用一個單獨的數字描述每一個副本，這就是經過處理的日誌的時間戳。時間戳與日誌一一對應著整個副本的狀態。
由於寫進日誌的內容的不同，也就有許多在系統中應用這個原則的不同方式。舉個例子，我們記錄一個服務的請求，或者服務從請求到響應的狀態變化，或者它執行命令的轉換。理論上來說，我們甚至可以為每一個副本記錄一系列要執行的機器指令或者調用的方法名和參數。只要兩個進程用相同的方式處理這些輸入，這些進程就會保持副本的一致性。
一千個人眼中有一千種日誌的用法。數據庫工作者通常區分物理日誌和邏輯日誌。物理日誌就是記錄每一行被改變的內容。邏輯日誌記錄的不是改變的行而是那些引起行的內容被改變的SQL語句(insert，update和delete語句)。
分佈式系統通常可以寬泛分為兩種方法來處理數據和完成響應「狀態機器模型」通常引用一個主動—主動的模型——也就是我們為之記錄請求和響應的對象。對此進行一個細微的更改，稱之為「預備份模型」，就是選出一個副本做為leader，並允許它按照請求到達的時間來進行處理並從處理過程中輸出記錄其狀態改變的日誌。其他的副本按照leader狀態改變的順序而應用那些改變，這樣他們之間達到同步，並能夠在leader失敗的時候接替leader的工作。
primary-Backup State Machine Replication
為了理解兩種方式的不同，我們來看一個不太嚴謹的例子。假定有一個算法服務的副本，保持一個獨立的數字作為它的狀態(初始值為0)，並對這個值進行加法和乘法運算。主動—主動方式應該會輸出所進行的變換，比如「+1」，「*2」等。每一個副本都會應用這些變換，從而得到同樣的解集。主動—被動方式將會有一個獨立的主體執行這些變換並輸出結果日誌，比如「1」，「3」，「6」等。這個例子也清楚的展示了為什麼說順序是保證各副本間一致性的關鍵：一次加法和乘法的順序的改變將會導致不同的結果。
分佈式日誌可以理解為一致性問題模型的數據結構。因為日誌代表了後續追加值的一系列決策。你需要重新審視Paxos算法簇，儘管日誌模塊是他們最常見的應用。 在Paxos算法中，它通常通過使用稱之為多paxos的協議，這種協議將日誌建模為一系列的問題，在日誌中每個問題都有對應的部分。在ZAB， RAFT等其它的協議中，日誌的作用尤為突出，它直接對維護分佈式的、一致性的日誌的問題建模。
我懷疑的是，我們就歷史發展的觀點是有偏差的，可能是由於過去的幾十年中，分佈式計算的理論遠超過了其實際應用。在現實中，共識的問題是有點太簡單了。計算機系統很少需要決定單個值，他們幾乎總是處理成序列的請求。這樣的記錄，而不是一個簡單的單值寄存器，自然是更加抽象。
此外，專注於算法掩蓋了 抽象系統需要的底層的日誌。我懷疑，我們最終會把日誌中更注重作為一個商品化的基石，不論其是否以同樣的方式 實施的，我們經常談論一個哈希表而不是糾結我們得到是不是具體某個細節的哈希表，例如線性或者帶有什麼什麼其它變體哈希表。日誌將成為一種大眾化的接口，為大多數算法和其實現提升提供最好的保證和最佳的性能。
變更日誌101：表與事件的二相性
讓我們繼續聊數據庫。數據庫中存在著大量變更日誌和表之間的二相性。這些日誌有點類似借貸清單和銀行的流程，數據庫表就是當前的盈餘表。如果你有大量的變更日誌，你就可以使用這些變更用以創建捕獲當前狀態的表。這張表將記錄每個關鍵點(日誌中一個特別的時間點)的狀態信息。這就是為什麼日誌是非常基本的數據結構的意義所在：日誌可用來創建基本表，也可以用來創建各類衍生表。同時意味著可以存儲非關係型的對象。
這個流程也是可逆的：如果你正在對一張表進行更新，你可以記錄這些變更，並把所有更新的日誌發佈到表的狀態信息中。這些變更日誌就是你所需要的支持准實時的克隆。基於此，你就可以清楚的理解表與事件的二相性： 表支持了靜態數據而日誌捕獲變更。日誌的魅力就在於它是變更的完整記錄，它不僅僅捕獲了表的最終版本的內容，它還記錄了曾經存在過的其它版本的信息。日誌實質上是表歷史狀態的一系列備份。
這可能會引起你對源代碼的版本管理。源代碼管理和數據庫之間有密切關係。版本管理解決了一個大家非常熟悉的問題，那就是什麼是分佈式數據系統需要解決的——時時刻刻在變化著的分佈式管理。版本管理系統通常以補丁的發布為基礎，這實際上可能是一個日誌。您可以直接對當前類似於表中的代碼做出「快照」互動。你會注意到，與其他分佈式狀態化系統類似，版本控制系統 當你更新時會複製日誌，你希望的只是更新補丁並將它們應用到你的當前快照中。
最近，有些人從Datomic——一家銷售日誌數據庫的公司得到了一些想法。這些想法使他們對如何在他們的系統應用這些想法有了開闊的認識。 當然這些想法不是只針對這個系統，他們會成為十多年分佈式系統和數據庫文獻的一部分。
這可能似乎有點過於理想化。但是不要悲觀!我們會很快把它實現。
接下來的內容
在這篇文章的其餘部分，我將試圖說明日誌除了可用在分佈式計算或者抽象分佈式計算模型內部之外，還可用在哪些方面。其中包括：
數據集成-讓機構的全部存儲和處理系統裡的所有數據很容易地得到訪問。
實時數據處理-計算生成的數據流。
分佈式系統設計-實際應用的系統是如何通過使用集中式日誌來簡化設計的。
所有這些用法都是通過把日誌用做單獨服務來實現的。
在上面任何一種用法裡，日誌的用途開始都是使用了日誌所能提供的某個簡單功能：生成永久的、可重現的歷史記錄。令人意外的是，問題的核心是可以讓多少台機器以特定的方式，按照自身的速度重現歷史記錄的能力。
第二部分：數據集成
請讓我首先解釋 一下「數據集成」是什麼意思，還有為什麼我覺得它很重要，之後我們再來看看它和日誌有什麼關係。
數據集成就是將數據組織起來，使得在與其有關的服務和系統中可以訪問它們。「數據集成」(data integration)這個短語應該不止這麼簡單，但是我找不到一個更好的解釋。而更常見的術語 ETL 通常只是覆蓋了數據集成的一個有限子集(譯註：ETL，Extraction-Transformation-Loading的縮寫，即數據提取、轉換和加載)——相對於關係型數據倉庫。但我描述的東西很大程度上可以理解為，將ETL推廣至實時系統和處理流程。
你一定不會聽到數據集成就興趣盎然屏住呼吸，並且天花亂墜的想到關於大數據的概念，不過，我相信世俗的問題「讓數據可被訪問」 是一個組織應該關注的有價值的事情。
對數據的高效使用遵循一種馬斯洛的需要層次理論 。金字塔的基礎部分包括捕獲所有相關數據，能夠將它們全部放到適當的處理環境(那個環境應該是一個奇妙的實時查詢系統，或者僅僅是文本文件和python腳本)。這些數據需要以統一的方式建模，這樣就可以方便讀取和數據處理。如果這種以統一的方式捕獲數據的基本需求得到滿足，那麼就可以在基礎設施上以若干種方法處理這些數據——映射化簡(MapReduce)，實時查詢系統，等等。
很明顯，有一點值得注意：如果沒有可靠的、完整的數據流，Hadoop集群除了象昂貴的且難於安裝的空間取暖器哪樣外不會做更多事情了。一旦數據和處理可用，人們就會關心良好數據模型和一致地易於理解的語法哪些更細緻的問題。最後，人們才會關注更加高級的處理——更好的可視化、報表以及處理和預測算法。
以我的經驗，大多數機構在數據金字塔的底部存在巨大的漏洞——它們缺乏可靠的、完整的數據流——而是打算直接跳到高級數據模型技術上。這樣做完全是反著來做的。
因此，問題是我們如何構建通過機構內所有數據系統的可靠的數據流。
數據集成：兩個併發症
兩種趨勢使數據集成變得更困難。
事件數據管道
第一個趨勢是增長的事件數據(event data)。事件數據記錄的是發生的事情，而不是存在的東西。在web系統中，這就意味著用戶活動日誌，還有為了可靠的操作以及監控數據中心的機器的目的，所需要記錄的機器級別的事件和統計數字。人們傾向稱它們為「日誌數據」，因為它們經常被寫到應用的日誌中，但是這混淆了形式與功能。這種數據位於現代web的中心：歸根結底，Google的資產是由這樣一些建立在點擊和映像基礎之上的相關管道所生成的——那也就是事件。
這些東西並不是僅限於網絡公司，只是網絡公司已經完全數字化，所以它們更容易用設備記錄。財務數據一直是面向事件的。RFID(無線射頻識別)將這種跟蹤能力賦予物理對象。我認為這種趨勢仍將繼續，伴隨著這個過程的是傳統商務活動的數字化。
這種類型的事件數據記錄下發生的事情，而且往往比傳統數據庫應用要大好幾個數量級。這對於處理提出了重大挑戰。
專門的數據系統的爆發
第二個趨勢來自於專門的數據系統的爆發，通常這些數據系統在最近的五年中開始變得流行，並且可以免費獲得。專門的數據系統是為OLAP，搜索， 簡單在線存儲， 批處理， 圖像分析，等等而存在的。
更多的不同類型數據的組合，以及將這些數據存放到更多的系統中的願望，導致了一個巨大的數據集成問題。
日誌結構數據流
為了處理系統之間的數據流，日誌是最自然的數據結構。其中的秘訣很簡單：
將所有組織的數據提取出來，並將它們放到一個中心日誌，以便實時查閱。
每個邏輯數據源都可以建模為它自己的日誌。一個數據源可以是一個應用程序的事件日誌(如點擊量或者頁面瀏覽量)，或者是一個接受修改的數據庫表。每個訂閱消息的系統都儘可能快的從日誌讀取信息，將每條新的記錄保存到自己的存儲，並且提升其在日誌中的地位。訂閱方可以是任意一種數據系統 —— 一個緩存，Hadoop，另一個網站中的另一個數據庫，一個搜索系統，等等。
例如，日誌針對每個更改給出了邏輯時鐘的概念，這樣所有的訂閱方都可以被測量。推導不同的訂閱系統的狀態也因此變得相對簡單的多，因為每個系統都有一個讀取動作的「時間點」。
為了讓這個顯得更具體，我們考慮一個簡單的案例，有一個數據庫和一組緩存服務器集群。日誌提供了一種同步更新所有這些系統，並推導出每一個系統的接觸時間點的方法。我們假設寫了一條日誌X，然後需要從緩存做一次讀取。如果我們想保證看到的不是陳舊的數據，我們只需保證沒有從任何尚未複製X的緩存中讀取即可。
日誌也起到緩存的作用，使數據生產與數據消費相同步。由於許多原因這個功能很重要，特別是在多個訂閱方消費數據的速度各不相同的時候。這意味著一個訂閱數據系統可以宕機，或者下線維護，之後重新上線以後再趕上來：訂閱方按照自己控制的節拍來消費數據。批處理系統，如Hadoop或者是一個數據倉庫，或許只是每小時或者每天消費一次數據，而實時查詢系統可能需要及時到秒。由於無論是原始數據源還是日誌，都沒有各種目標數據系統的相關知識，因此消費方系統可以被添加和刪除，而無需傳輸管道的變化。
「每個工作數據管道設計得就像是一個日誌;每個損壞的數據管道以其自己的方式損壞。」—Count Leo Tolstoy (由作者翻譯)
特別重要的是：目標系統只知道日誌，不知道數據源系統的任何細節。消費方系統自身無需考慮數據到底是來自於一個RDBMS(關係型數據庫管理系統Relational Database Management System)，一種新型的鍵值存儲，或者它不是由任何形式的實時查詢系統所生成的。這似乎是一個小問題，但實際上是至關重要的。
這裡我使用術語「日誌」取代了「消息系統」或者「發佈—訂閱」，因為它在語義上更明確，並且對支持數據複製的實際實現這樣的需求，有著更接近的描述。我發現「發佈訂閱」並不比間接尋址的消息具有更多的含義——如果你比較任何兩個發佈—訂閱的消息傳遞系統的話，你會發現他們承諾的是完全不同的東西，而且大多數模型在這一領域都不是有用的。你可以認為日誌是一種消息系統，它具有持久性保證和強大的訂閱語義。在分佈式系統中，這個通信模型有時有個(有些可怕的)名字叫做原子廣播。
值得強調的是，日誌仍然只是基礎設施。這並不是管理數據流這個故事的結束：故事的其餘部分圍繞著元數據，模式，兼容性，以及處理數據結構的所有細節及其演化。除非有一種可靠的，一般的方法來處理數據流運作，語義在其中總是次要的細節。
在LinkefIn(SNS社交網站)
在LinkedIn從集中式關係數據庫向分佈式系統集合轉化的過程中，我看到這個數據集成問題迅速演變。
現在主要的數據系統包括：
搜索
社交圖譜
Voldemort (鍵值存儲)(譯註：一種分佈式數據庫)
Espresso (文檔存儲)
推舉引擎
OLAP查詢引擎(譯註：OLAP聯機分析技術)
Hadoop
Terradata
Ingraphs (監控圖表和指標服務)
這些都是專門的分佈式系統，在其專業領域提供先進的功能。
這種使用日誌作為數據流的思想，甚至在我到這裡之前就已經與LinkedIn相伴了。我們開發的一個最早的基礎設施之一，是一種稱為databus 的服務，它在我們早期的Oracle表上提供了一種日誌緩存抽象，可伸縮訂閱數據庫修改，這樣我們就可以很好支持我們的社交網絡和搜索索引。
我會給出一些歷史並交代一下上下文。我首次參與到這些大約是在2008年左右，在我們轉移鍵值存儲之後。我的下一個項目是讓一個工作中的Hadoop配置演進，並給其增加一些我們的推薦流程。由於缺乏這方面的經驗，我們自然而然的安排了數週計劃在數據的導入導出方面，剩下的時間則用來實現奇妙的預測算法。這樣我們就開始了長途跋涉。
我們本來計劃是僅僅將數據從現存的Oracle數據倉庫中剖離。但是我們首先發現將數據從Oracle中迅速取出是一種黑暗藝術。更糟的是，數據倉庫的處理過程與我們為Hadoop而計劃的批處理生產過程不適合——其大部分處理都是不可逆轉的，並且與即將生成的報告具體相關。最終我們採取的辦法是，避免使用數據倉庫，直接訪問源數據庫和日誌文件。最後，我們為了加載數據到鍵值存儲並生成結果，實現了另外一種管道。
這種普通的數據複製最終成為原始開發項目的主要內容之一。糟糕的是，在任何時間任意管道都有一個問題，Hadoop系統很大程度上是無用的——在錯誤的數據基礎上運行奇特的算法，只會產生更多的錯誤數據。
雖然我們已經以一種通用的方式創建事物，但是每個數據源都需要自定義配置安裝。這也被證明是巨量錯誤與失敗的根源。我們在Hadoop上實現的網站功能已經開始流行起來，同時我們發現我們有一長串感興趣的工程師。每個用戶都有他們想要集成的一系列系統，他們想要的一系列新數據源。
古希臘時代的 ETL(提取轉換加載Extract Transform and Load)。並沒有太多變化
有些東西在我面前開始漸漸清晰起來。
首先，我們已建成的通道雖然有一些雜亂，但實質上它們是很有價值的。在採用諸如Hadoop的新的處理系統生成可用數據的過程，它開啟了大量的可能性。 基於這些數據過去很難實現的計算，如今變為可能。 許多新的產品和分析技術都來源於把分片的數據放在一起，這些數據過被鎖定在特定的系統中。
第二， 眾所周知，可靠的數據加載需要數據通道的深度支持。如果我們可以捕獲所有我們需要的結構，我就就可以使得Hadoop數據全自動的加載，這樣就不需要額外的操作來增加新的數據源或者處理模式變更–數據就會自動的出現在HDFS，Hive表就會自動的生成對應於新數據源的恰當的列。
第三，我們的數據覆蓋率仍然非常低。如果你查看存儲於Hadoop中的可用的Linked 數據的全部百分比，它仍然是不完整的。花費大量的努力去使得各個新的數據源運轉起來，使得數據覆蓋度完整不是一件容易的事情。
我們正在推行的，為每個數據源和目標增建客戶化數據加載，這種方式很顯然是不可行的。我們有大量的數據系統和數據倉庫。把這些系統和倉庫聯繫起來，就會導致任意一對系統會產生如下所示的客戶化通道。
需要注意的是：數據是雙向流動的：例如許多系統諸如數據庫和Hadoop既是數據轉化的來源又是數據轉化的目的地。這就意味著我們我們不必為每個系統建立兩個通道：一個用於數據輸入，一個用於數據輸出。
這顯然需要一大群人，而且也不具有可操作性。隨著我們接近完全連接，最終我們將有差不多O(N2)條管道。
替代的，我們需要像這樣通用的東西：
我們需要儘可能的將每個消費者與數據源隔離。理想情形下，它們應該只與一個單獨的數據倉庫集成，並由此讓他們能訪問到所有東西。
這個思想是增加一個新的數據系統——或者它是一個數據源或者它是一個數據目的地——讓集成工作只需連接到一個單獨的管道，而無需連接到每個數據消費方。
這種經歷使得我關注創建Kafka來關聯我們在消息系統所見的與數據庫和分佈式系統內核所發佈的日誌。我們希望一些實體作為中心的通道，首先用於所有的活動數據，逐步的擴展到其他用途，例如Hadoop外的數據實施，數據監控等。
在相當長的時間內，Kafka是獨一無二的底層產品，它既不是數據庫，也不是日誌文件收集系統，更不是傳統的消息系統。但是最近Amazon提供了非常類似Kafka的服務，稱之為Kinesis。相似度包括了分片處理的方式，數據的保持，甚至包括在Kafka API中，有點特別的高端和低端消費者分類。我很開心看到這些，這表明了你已經創建了很好的底層協議，AWS已經把它作為服務提供。他們對此的期待與我所描述的吻合：通道聯通了所有的分佈式系統，諸如DynamoDB，RedShift，S3等，它同時作為使用EC2進行分佈式流處理的基礎。
與ETL和數據倉庫的關係
我們再來聊聊數據倉庫。數據倉庫是清洗和歸一數據結構用於支撐數據分析的倉庫。這是一個偉大的理念。對不熟悉數據倉庫概念的人來說，數據倉庫方法論包括了：週期性的從數據源抽取數據，把它們轉化為可理解的形式，然後把它導入中心數據倉庫。對於數據集中分析和處理，擁有高度集中的位置存放全部數據的原始副本是非常寶貴的資產。在高層級上，也許你抽取和加載數據的順序略微調整，這個方法論不會有太多變化,無論你使用傳統的數據倉庫Oracle還是Teradata或者Hadoop。
數據倉庫是極其重要的資產，它包含了原始的和規整的數據，但是實現此目標的機制有點過時了。
對以數據為中心的組織關鍵問題是把原始的歸一數據聯結到數據倉庫。數據倉庫是批處理的基礎查詢：它們適用於各類報表和臨時性分析，特別是當查詢包含了簡單的計數、聚合和過濾。但是如果一個批處理系統僅僅包含了原始的完整的數據的數據倉庫，這就意味著這些數據對於實時數據處理、搜索索引和系統監控等實時的查詢是不可用的。
依我之見，ETL包括兩件事：首先，它是抽取和數據清洗過程–特別是釋放被鎖在組織的各類系統中的數據，移除系統專有的無用物。第二，依照數據倉庫的查詢重構數據。例如使其符合關係數據庫類型系統，強制使用星號、雪花型模式，或者分解為高性能的柱狀格式等。合併這兩者是有困難的。這些規整的數據集應當可以在實時或低時延處理中可用，也可以在其它實施存儲系統索引。
在我看來，正是因為這個原因有了額外好處：使得數據倉庫ETL更具了組織級的規模。數據倉庫的精典問題是數據倉庫負責收集和清洗組織中各個組所生成的全部數據。各組織的動機是不同的，數據的生產者並不知曉在數據倉庫中數據的使用情況，最終產生的數據很難抽取，或者需要花費規模化的轉化才可以轉化為可用的形式。當然， 中心團隊不可能恰到好處的掌握規模，使得這規模剛好與組織中其它團隊相匹配，因此數據的覆蓋率常常差別很大，數據流是脆弱的同時變更是緩慢的。
較好的方法是有一個中心通道，日誌和用於增加數據的定義良好的API。與通道集成的且提供良好的結構化的數據文件的職責依賴於數據的生產者所生成的數據文件。這意味著在設計和實施其它系統時應當考慮數據的輸出以及輸出的數據如何轉化為結構良好的形式並傳遞給中心通道。增加新的存儲系統倒是不必因為數據倉庫團隊有一個中心結點需要集成而關注數據倉庫團隊。數據倉庫團隊僅需處理簡單的問題，例如從中心日誌中加載結構化的數據，向其它周邊系統實施個性化的數據轉化等。
如圖所示：當考慮在傳統的數據倉庫之外增加額外的數據系統時，組織結構的可擴展性顯得尤為重要。例如，可以考慮為組織的完整的數據集提供搜索功能。或者提供二級的數據流監控實時數據趨勢和告警。無論是這兩者中的哪一個，傳統的數據倉庫架構甚至於Hadoop聚簇都不再適用。更糟的是，ETL的流程通道的目的就是支持數據加載，然而ETL似乎無法輸出到其它的各個系統，也無法通過引導程序，使得這些外圍的系統的各個架構成為適用於數據倉庫的重要資產。這就不難解釋為什麼組織很難輕鬆的使用它的全部數據。反之，如果組織已建立起了一套標準的、結構良好的數據，那麼任何新的系統要使用這些數據僅僅需要與通道進行簡單的集成就可以實現。
這種架構引出了數據清理和轉化在哪個階段進行的不同觀點：
由數據的生產者在把數據增加到公司全局日誌之前。
在日誌的實時轉化階段進行，這將會產生一個新的轉化日誌。
在向目標系統加載數據時，做為加載過程的一部分進行。
理想的模形是：由數據的生產者在把數據發佈到日誌之前對數據進行清理。這樣可以確保數據的權威性，不需要維護其它的遺留物例如為數據產生的特殊處理代碼或者維護這些數據的其它的存儲系統。這些細節應當由產生數據的團隊來處理，因為他們最瞭解他們自己的數據。這個階段所使用的任何邏輯都應該是無損的和可逆的。
任何可以實時完成的增值轉化類型都應當基於原始日誌進行後期處理。這一過程包括了事件數據的會話流程，或者增加大眾感興趣的衍生字段。原始的日誌仍然是可用的，但是這種實時處理產生的衍生日誌包含了參數數據。
最終，只有針對目標系統的聚合需要做了加載流程的一部分。它包括了把數據轉化成特定的星型或者雪花狀模式，從而用於數據倉庫的分析和報表。因為在這個階段，大部分自然的映射到傳統的ETL流程中，而現在它是在一個更加乾淨和規整的數據流集在進行的，它將會更加的簡單。
日誌文件和事件
我們再來聊聊這種架構的優勢：它支持解耦和事件驅動的系統。
在網絡行業取得活動數據的典型方法是把它記為文本形式的日誌，這些文本文件是可分解進入數據倉庫或者Hadoop，用於聚合和查詢處理的。由此產生的問題與所有批處理的ETL的問題是相同的：它耦合了數據流進入數據倉庫系統的能力和流程的調度。
在LinkedIn中，我們已經以中心日誌的方式構建了事件數據處理。我們正在使用Kafka做為中心的、多訂閱者事件日誌。我們已經定義了數百種事件類型，每種類型都會捕獲用於特定類型動作的獨特的屬性。這將會覆蓋包括頁面視圖、表達式、搜索以及服務調用、應用異常等方方面面。
為了進一步理解這一優勢：設想一個簡單的事務–在日誌頁面顯示已發佈的日誌。這個日誌頁面應當只包括顯示日誌所需要的邏輯。然而，在相當多的動態站點中，日誌頁面常常變的添加了很多與顯示日誌無關的邏輯。例如，我們將對如下的系統進行集成：
需要把數據傳送到Hadoop和數據倉庫中用於離線數據處理。
需要對視圖進行統計，確保視圖訂閱者不會攻擊一些內容片段。
需要聚合這些視圖，視圖將用於作業發佈者的分析頁面顯示。
需要記錄視圖以確保我們為作業推薦的使用者提供了恰當的印象覆蓋，我們不想一次次的重複同樣的事情。
推薦系統需要記錄日誌用於正確的跟蹤作業的普及度。
等等。
不久，簡單的作業顯示變得相當的複雜。我們增加了作業顯示的其它終端——移動終端應用等——這些邏輯必須繼續存在，複雜度不斷的增加。更糟的是我們需要與之做接口交互的系統現在是錯綜複雜的–在為顯示日作業而工作的工程師們需要知曉多個其它系統和它們的特徵，才可以確保它們被正確的集成了。這僅僅是問題的簡單版本，真實的的應用系統只會更加的複雜。
「事件驅動」的模式提供了一種簡化這類問題的機制。作業顯示頁面現在只顯示作業並記錄與正在顯示的作業，作業訂閱者相關的其它屬性，和其它與作業顯示相關的其它有價值的屬性。每個與此相關的其它系統諸如推薦系統、安全系統、作業推送分析系統和數據倉庫，所有這些只是訂閱種子文件，並進行它們的操作。顯示代碼並不需要關注其它的系統，也不需要因為增加了數據的消費者而相應的進行變更。
構建可伸縮的日誌
當然，把發佈者與訂閱者分離不再是什麼新鮮事了。但是如果你想要確保提交日誌的行為就像多個訂閱者實時的分類日誌那樣記錄網站發生的每件事時，可擴展性就會成為你所面臨的首要挑戰。如果我們不能創建快速、高性價比和可擴展性靈活的日誌以滿足實際的可擴展需求，把日誌做為統一的集成機制不再是美好的想像，
人們普遍認為分佈式日誌是緩慢的、重量經的概念(並且通常會把它僅僅與「原數據」類型的使用聯繫起來，對於這類使用Zookeeper可以適用)。但是深入實現並重點關注分類記錄大規模的數據流，這種需求是不切實際的。在LinkedIn，我們現在每天通過Kafka運行著超過600億個不同的消息寫入點(如果統計鏡相與數據中心之間的寫入，那麼這個數字會是數千億)。
我們在Kafk中使用了一些小技巧來支持這種可擴展性：
日誌分片
通過批處理讀出和寫入優化吞吐力
規避無用的數據複製。
為了確保水平可擴展性，我們把日誌進行切片：
每個切片都是一篇有序的日誌，但是各片之間沒有全局的次序(這個有別於你可能包含在消息中的掛鐘時間)。把消息分配到特定的日誌片段這是由寫入者控制的，大部分使用者會通過用戶ID等鍵值來進行分片。分片可以把日誌追加到不存在協作的片段之間，也可以使系統的吞吐量與Kafka聚簇大小成線性比例關係。
每個分片都是通過可配置數量的複製品複製的，每個複製品都有分片的一份完全一致的拷貝。無論何時，它們中的任一個都可以做為主分片，如果主分片出錯了，任何一個複製品都可以接管並做為主分片。
缺少跨分片的全局順序是這個機制的侷限性，但是我們不認為它是最主要的。事實上，與日誌的交互主要來源於成百上千個不同的流程，以致於對於它們的行為排一個總體的順序是沒什麼意義的。相反，我們可以確保的是我們提供的每個分片都是按順序保留的。Kafka保證了追加到由單一發送者送出的特定分片會按照發送的順序依次處理。
日誌，就像文件系統一樣，是容易優化成線性可讀可寫的樣式的。日誌可以把小的讀入和寫出組合成大的、高吞吐量的操作。Kafka一直至立於實現這一優化目標。批處理可以發生在由客戶端向服務器端發送數據、寫入磁盤;在服務器各端之間複製;數據傳遞給消費者和確認提交數據等諸多環節。
最終，Kafka使用簡單的二進制形式維護內存日誌，磁盤日誌和網絡數據傳送。這使得我們可以使用包括「0數據複製傳送」在內的大量的優化機制。
這些優化的積累效應是你常常進行的寫出和讀入數據的操作可以在磁盤和網絡上得到支持，甚至於維護內存以外的大量數據集。
這些詳細記述並不意味著這是關於Kafka的主要內容，那麼我就不需要瞭解細節了。你可閱讀到更多的關於LinkedIn的方法在這個鏈接，和Kafka的設計總述在這個鏈接。
第三部分：日誌和實時流處理
到此為止，我只是描述從端到端數據複製的理想機制。但是在存儲系統中搬運字節不是所要講述內容的全部。最終我們發現日誌是流的另一種說法，日誌是流處理的核心。
但是，等等，什麼是流處理呢?
如果你是90年代晚期或者21世紀初數據庫文化或者數據基礎架構產品的愛好者，那麼你就可能會把流處理與建創SQL引擎或者創建「箱子和箭頭」接口用於事件驅動的處理等聯繫起來。
如果你關注開源數據庫系統的大量出現，你就可能把流處理和一些開源數據庫系統關聯起來，這些系統包括了：Storm，Akka，S4和Samza。但是大部分人會把這些系統作為異步消息處理系統，這些系統與支持群集的遠程過程調用層的應用沒什麼差別(而事實上在開源數據庫系統領域某些方面確實如此)。
這些視圖都有一些侷限性。流處理與SQL是無關的。它也侷限於實時流處理。不存在內在的原因限制你不能處理昨天的或者一個月之前的流數據，且使用多種不同的語言表達計算。
我把流處理視為更廣泛的概念：持續數據流處理的基礎架構。我認為計算模型可以像MapReduce或者分佈式處理架構一樣普遍，但是有能力處理低時延的結果。
處理模型的實時驅動是數據收集方法。成批收集的數據是分批處理的。數據是不斷收集的，它也是按順序不斷處理的。
美國的統計調查就是成批收集數據的良好典範。統計調查週期性的開展，通過挨門挨戶的走訪，使用蠻力發現和統計美國的公民信息。1790年統計調查剛剛開始時這種方式是奏效的。那時的數據收集是批處理的，它包括了騎著馬悠閒的行進，把信息寫在紙上，然後把成批的記錄傳送到人們統計數據的中心站點。現在，在描述這個統計過程時，人們立即會想到為什麼我們不保留出生和死亡的記錄，這樣就可以產生人口統計信息這些信息或是持續的或者是其它維度的。
這是一個極端的例子，但是大量的數據傳送處理仍然依賴於週期性的轉儲，批量轉化和集成。處理大容量轉儲的唯一方法就是批量的處理。但是隨著這些批處理被持續的供給所取代，人們自然而然的開始不間斷的處理以平滑的處理所需資源並且消除延遲。
例如LinkedIn幾乎沒有批量數據收集。大部分的數據或者是活動數據或者是數據庫變更，這兩者都是不間斷髮生的。事實上，你可以想到的任何商業，正如：Jack Bauer告訴我們的，低層的機制都是實時發生的不間斷的流程事件。數據是成批收集的，它總是會依賴於一些人為的步驟，或者缺少數字化或者是一些自動化的非數字化流程處理的遺留信息。當傳送和處理這些數據的機制是郵件或者人工的處理時，這一過程是非常緩慢的。首輪自動化總是保持著最初的處理形式，它常常會持續相當長的時間。
每天運行的批量處理作業常常是模擬了一種一天的窗口大小的不間斷計算。當然，低層的數據也經常變化。在LinkedIn，這些是司空見貫的，並且使得它們在Hadoop運轉的機制是有技巧的，所以我們實施了一整套管理增量的Hadoop工作流的架構。
由此看來，對於流處理可以有不同的觀點。流處理包括了在底層數據處理的時間概念，它不需要數據的靜態快照，它可以產生用戶可控頻率的輸出，而不用等待數據集的全部到達。從這個角度上講，流處理就是廣義上的批處理，隨著實時數據的流行，會兒更加普遍。
這就是為什麼從傳統的視角看來流處理是利基應用。我個人認為最大的原因是缺少實時數據收集使得不間斷的處理成為了學術性的概念。
我想缺少實時數據收集就像是商用流處理系統注定的命運。他們的客戶仍然需要處理面向文件的、每日批量處理ETL和數據集成。公司建設流處理系統關注的是提供附著在實時數據流的處理引擎，但是最終當時極少數人真正使用了實時數據流。事實上，在我在LinkedIn工作的初期，有一家公司試圖把一個非常棒的流處理系統銷售給我們，但是因為當時我們的全部數據都按小時收集在的文件裡，當時我們提出的最好的應用就是在每小時的最後把這些文件輸入到流處理系統中。他們注意到這是一個普遍性的問題。這些異常證明了如下規則：流處理系統要滿足的重要商業目標之一是：財務， 它是實時數據流已具備的基準，並且流處理已經成為了瓶頸。
甚至於在一個健康的批處理系統中，流處理作為一種基礎架構的實際應用能力是相當廣泛的。它跨越了實時數據請求——應答服務和離線批量處理之間的鴻溝。現在的互聯網公司，大約25%的代碼可以劃分到這個類型中。
最終這些日誌解決了流處理中絕大部分關鍵的技術問題。在我看來，它所解決的最大的問題是它使得多訂閱者可以獲得實時數據。對這些技術細節感興趣的朋友，我們可以用開源的Samza,它是基於這些理念建設的一個流處理系統。這些應用的更多技術細節我們在此文檔中有詳細的描述。
數據流圖
流處理最有趣的角度是它與流處理系統內部無關，但是與之密切相關的是如何擴展了我們談到的早期數據集成的數據獲取的理念。我們主要討論了基礎數據的獲取或日誌——事件和各類系統執行中產生的數據等。但是流處理允許我們包括了計算其它數據的數據。這些衍生的數據在消費者看來與他們計算的原始數據沒什麼差別。這些衍生的數據可以按任意的複雜度進行壓縮。
讓我們再深入一步。我們的目標是：流處理作業可以讀取任意的日誌並把日誌寫入到日誌或者其它的系統中。他們用於輸入輸出的日誌把這些處理關聯到一組處理過程中。事實上，使用這種樣式的集中日誌，你可以把組織全部的數據抓取、轉化和工作流看成是一系列的日誌和寫入它們的處理過程。
流處理器根本不需要理想的框架：它可能是讀寫日誌的任何處理器或者處理器集合，但是額外的基礎設施和輔助可以提供幫助管理處理代碼。
日誌集成的目標是雙重的：
首先，它確保每個數據集都有多個訂閱者和有序的。讓我們回顧一下狀態複製原則來記住順序的重要性。為了使這個更加具體，設想一下從數據庫中更新數據流–如果在處理過程中我們把對同一記錄的兩次更新重新排序，可能會產生錯誤的輸出。 TCP之類的鏈接僅僅侷限於單一的點對點鏈接，這一順序的持久性要優於TCP之類的鏈接，它可以在流程處理失敗和重連時仍然存在。
第二，日誌提供了流程的緩衝。這是非常基礎的。如果處理流程是非同步的，那麼上行生成流數據的作業比下行消費流數據的作業運行的更快。這將會導致處理流程阻塞，或者緩衝數據，或者丟棄數據。丟棄數據並不是可行的方法，阻塞將會導致整個流程圖立即停止。 日誌實際上是一個非常大的緩衝，它允許流程重啟或者停止但不會影響流程圖其它部分的處理速度。如果要把數據流擴展到更大規模的組織，如果處理作業是由多個不同的團隊提供的，這種隔離性是極其重的。我們不能容忍一個錯誤的作業引發後台的壓力，這種壓力會使得整個處理流程停止。
Storm和Sama這兩者都是按非同步方式設計的，可以使用Kafka或者其它類似的系統作為它們的日誌。
有狀態的實時流處理
一些實時流處理在轉化時是無狀態的記錄。在流處理中大部分的應用會是相當複雜的統計、聚合、不同窗口之間的關聯。例如有時人們想擴大包含用戶操作信息的事件流(一系列的單擊動作)–實際上關聯了用戶的單擊動作流與用戶的賬戶信息數據庫。不變的是這類流程最終會需要由處理器維護的一些狀態信息。例如數據統計時，你需要統計到目前為止需要維護的計數器。如果處理器本身失敗了，如何正確的維護這些狀態信息呢?
最簡單的替換方案是把這些狀態信息保存在內存中。但是如果流程崩潰，它就會丟失中間狀態。如果狀態是按窗口維護的，流程就會回退到日誌中窗口開始的時間點上。但是，如果統計是按小時進行的，那麼這種方式就會變得不可行。
另一個替換方案是簡單的存儲所有的狀態信息到遠程的存儲系統，通過網絡與這些存儲關聯起來。這種機制的問題是沒有本地數據和大量的網絡間通信。
我們如何支持處理過程可以像表一樣分區的數據呢?
回顧一下關於表和日誌二相性的討論。這一機制提供了工具把數據流轉化為與處理過程協同定位的表，同時也提供了這些表的容錯處理的機制。
流處理器可以把它的狀態保存在本地的表或索引——bdb，或者leveldb，甚至於類似於Lucene 或fastbit一樣不常見的索引。這些內容存儲在它的輸入流中(或許是使用任意的轉化)。生成的變更日誌記錄了本地的索引，它允許存儲事件崩潰、重啟等的狀態信息。流處理提供了通用的機制用於在本地輸入流數據的隨機索引中保存共同分片的狀態。
當流程運行失敗時，它會從變更日誌中恢復它的索引。每次備份時，日誌把本地狀態轉化成一系列的增量記錄。
這種狀態管理的方法有一個優勢是把處理器的狀態也做為日誌進行維護。我們可以把這些日誌看成與數據庫表相對應的變更日誌。事實上，這些處理器同時維護著像共同分片表一樣的表。因為這些狀態它本身就是日誌，其它的處理器可以訂閱它。如果流程處理的目標是更新結點的最後狀態，這種狀態又是流程的輸出，那麼這種方法就顯得尤為重要。
為了數據集成，與來自數據庫的日誌關聯，日誌和數據庫表的二象性就更加清晰了。變更日誌可以從數據庫中抽取出來，日誌可以由不同的流處理器(流處理器用於關聯不同的事件流)按不同的方式進行索引。
我們可以列舉在Samza中有狀態流處理管理的更多細節和大量實用的例子。
日誌壓縮
當然，我們不能奢望保存全部變更的完整日誌。除非想要使用無限空間，日誌不可能完全清除。為了澄清它，我們再來聊聊Kafka的實現。在Kafka中，清理有兩種選擇，這取決於數據是否包括關鍵更新和事件數據。對於事件數據，Kafka支持僅維護一個窗口的數據。通常，配置需要一些時間，窗口可以按時間或空間定義。雖然對於關鍵數據而言，完整日誌的重要特徵是你可以重現源系統的狀態信息，或者在其它的系統重現。
隨著時間的推移，保持完整的日誌會使用越來越多的空間，重現所耗費的時間越來越長。因些在Kafka中，我們支持不同類型的保留。我們移除了廢棄的記錄(這些記錄的主鍵最近更新過)而不是簡單的丟棄舊日誌。我們仍然保證日誌包含了源系統的完整備份，但是現在我們不再重現原系統的全部狀態，而是僅僅重現最近的狀態。我們把這一特徵稱為日誌壓縮。
第四部分：系統建設
我們最後要討論的是在線數據系統設計中日誌的角色。
在分佈式數據庫數據流中日誌的角色和在大型組織機構數據完整中日誌的角色是相似的。在這兩個應用場景中，日誌是對於數據源是可靠的，一致的和可恢復的。組織如果不是一個複雜的分佈式數據系統呢，它究竟是什麼?
分類計價嗎?
如果換個角度，你可以看到把整個組織系統和數據流看做是單一的分佈式數據系統。你可以把所有的子查詢系統(諸如Redis，SOLR，Hive表等)看成是數據的特定索引。你可以把Storm或Samza一樣的流處理系統看成是發展良好的觸發器和視圖具體化機制。我已經注意到，傳統的數據庫管理人員非常喜歡這樣的視圖，因為它最終解釋了這些不同的數據系統到底是做什麼用的–它們只是不同的索引類型而已。
不可否認這類數據庫系統現在大量的出現，但是事實上，這種複雜性一直都存在。即使是在關係數據庫系統的鼎盛時期，組織中有大量的關係數據庫系統。或許自大型機時代開始，所有的數據都存儲在相同的位置，真正的集成是根本不存在的。存在多種外在需求，需要把數據分解成多個系統，這些外在需求包括：規模、地理因素、安全性，性能隔離是最常見的因素。這些需求都可以由一個優質的系統實現：例如，組織可以使用單一的Hadoop聚簇，它包括了全部的數據，可以服務於大型的和多樣性的客戶。
因此在向分佈式系統變遷的過程中，已經存在一種處理數據的簡便的方法：把大量的不同系統的小的實例聚合成為大的聚簇。許多的系統還不足以支持這一方法：因為它們不夠安全，或者性能隔離性得不到保證，或者規模不符合要求。不過這些問題都是可以解決的。
依我之見，不同系統大量出現的原因是建設分佈式數據庫系統很困難。通過削減到單一的查詢或者用例，每個系統都可以把規模控制到易於實現的程度。但是運行這些系統產生的複雜度依然很高。
未來這類問題可能的發展趨勢有三種：
第一種可能是保持現狀：孤立的系統還會或長或短的持續一段時間。這是因為建設分佈式系統的困難很難克服，或者因為孤立系統的獨特性和便捷性很難達到。基於這些原因，數據集成的核心問題仍然是如何恰當的使用數據。因此，集成數據的外部日誌非常的重要。
第二種可能是重構：具備通用性的單一的系統逐步融合多個功能形成超極系統。這個超級系統表面看起來類似關係數據庫系統，但是在組織中你使用時最大的不同是你只需要一個大的系統而不是無數個小系統。在這個世界裡，除了在系統內已解決的這個問題不存在什麼真正的數據集成問題。我想這是因為建設這樣的系統的實際困難。
雖然另一種可能的結果對於工程師來說是很有吸引力的。新一代數據庫系統的特徵之一是它們是完全開源的。開源提供了一種可能性：數據基礎架構不必打包成服務集或者面嚮應用的系統接口。在Java棧中，你可以看到在一定程度上，這種狀況已經發生了。
Zookeeper用於處理多個系統之間的協調，或許會從諸如Helix 或者Curator等高級別的抽象中得到一些幫助。
Mesos和YARN用於處理流程可視化和資源管理。
Lucene和LevelDB等嵌入式類庫做為索引。
Netty，Jetty和Finagle，rest.li等封裝成高級別的用於處理遠程通信。
Avro，Protocol Buffers，Thrift和umpteen zillion等其它類庫用於處理序列化。
Kafka和Bookeeper提供支持日誌。
如果你把這些堆放在一起，換個角度看，它有點像是簡化版的分佈式數據庫系統工程。你可以把這些拼裝在一起，創建大量的可能的系統。顯而易見，現在探討的不是最終用戶所關心的API或者如何實現，而是在不斷多樣化和模塊化的過程中如何設計實現單一系統的途徑。因為隨著可靠的、靈活的模塊的出現，實施分佈式系統的時間週期由年縮減為周，聚合形成大型整體系統的壓力逐步消失。
日誌文件在系統結構中的地位
那些提供外部日誌的系統如今已允許個人電腦拋棄他們自身複雜的日誌系統轉而使用共享日誌。在我看來，日誌可以做到以下事情：
通過對節點的並發更新的排序處理數據的一致性(無論在及時還是最終情況下)
提供節點之間的數據複製
提供」commit「語法(只有當寫入器確保數據不會丟失時才會寫入)
位系統提供外部的數據訂閱資源
提供存儲失敗的複製操作和引導新的複製操作的能力
處理節點間的數據平衡
這實際上是一個數據分發系統最重要的部分，剩下的大部分內容與終端調用的API和索引策略相關。這正是不同系統間的差異所在，例如：一個全文本查詢語句需要查詢所有的分區，而一個主鍵查詢只需要查詢負責鍵數據的單個節點就可以了。
下面我們來看下該系統是如何工作的。系統被分為兩個邏輯區域：日誌和服務層。日誌按順序捕獲狀態變化，服務節點存儲索引提供查詢服務需要的所有信息(鍵—值的存儲可能以B-tree或SSTable的方式進行，而搜索系統可能存在與之相反的索引)。寫入器可以直接訪問日誌，儘管需要通過服務層代理。在寫入日誌的時候會產生邏輯時間戳(即log中的索引)，如果系統是分段式的，那麼就會產生與段數目相同數量的日誌文件和服務節點，這裡的數量和機器數量可能會有較大差距。
服務節點訂閱日誌信息並將寫入器按照日誌存儲的順序盡快應用到它的本地索引上。
客戶端只要在查詢語句中提供對應的寫入器的時間戳，它就可以從任何節點中獲取」讀寫「語義。服務節點收到該查詢語句後會將其中的時間戳與自身的索引比較，如果必要，服務節點會延遲請求直到對應時間的索引建立完畢，以免提供舊數據。
服務節點或許根本無需知道」控制「或」投標選擇(leader election)「的概念，對很多簡單的操作，服務節點可以愛完全脫離領導的情況下提供服務，日誌即是信息的來源。
分發系統所需要做的其中一個比較複雜的工作，就是修復失敗節點並移除幾點之間的隔離。保留修復的數據並結合上各區域內的數據快照是一種較為典型的做法，它與保留完整的數據備份並從垃圾箱內回收日誌的做法幾乎等價。這就使得服務層簡單了很多，日誌系統也更有針對性。
有了這個日誌系統，你可以訂閱到API，這個API提供了把ETL提供給其它系統的數據內容。事實上，許多系統都可以共享相同的日誌同時提供不同的索引，如下所示：
這樣一個以日誌為中心的系統是如何做到既數據流的提供者又同時加載其它系統的數據的呢?因為流處理器既可以消費多個輸入的數據流，隨後又可以通過其它系統對數據做索引為它們提供服務。
這個系統的視圖可以清晰的分解到日誌和查詢API，因為它允許你從系統的可用性和一致性角度分解查詢的特徵。這可以幫助我們對系統進行分解，並理解那些並沒按這種方式設計實施的系統。
雖然Kafka和Bookeeper都是一致性日誌，但這不是必須的，也沒什麼意義。你可以輕鬆的把Dynamo之類的數據構分解為一致性的AP日誌和鍵值對服務層。這樣的日誌使用起來靈活，因為它重傳了舊消息，像Dynamo一樣，這樣的處理取決於消息的訂閱者。
在很多人看來，在日誌中另外保存一份數據的完整複本是一種浪費。事實上，雖然有很多因素使得這件事並不困難。首先，日誌可以是一種有效的存儲機制。我們在Kafka生產環境的服務器上存儲了5 TB的數據。同時有許多的服務系統需要更多的內存來提供有效的數據服務，例如文本搜索，它通常是在內存中的。服務系統同樣也需樣硬盤的優化。例如，我們的實時數據系統或者在內存外提供服務或者使用固態硬盤。相反，日誌系統只需要線性的讀寫，因此，它很樂於使用TB量級的硬盤。最終，如上圖所示，由多個系統提供的數據，日誌的成本分攤到多個索引上，這種聚合使得外部日誌的成本降到了最低點。
LinkedIn就是使用了這種方式實現它的多個實時查詢系統的。這些系統提供了一個數據庫(使用數據總線做為日誌摘要，或者從Kafka去掉專用的日誌)，這些系統在頂層數據流上還提供了特殊的分片、索引和查詢功能。這也是我們實施搜索、社交網絡和OLAP查詢系統的方式。事實上這種方式是相當普遍的：為多個用於實時服務的服務系統提供單一的數據(這些來自Hadoop的數據或是實時的或是衍生的)。這種方式已被證實是相當簡潔的。這些系統根本不需要外部可寫入的API，Kafka和數據庫被用做系統的記錄和變更流，通過日誌你可以查詢系統。持有特定分片的結點在本地完成寫操作。這些結點盲目的把日誌提供的數據轉錄到它們自己的存儲空間中。通過回放上行流日誌可以恢復轉錄失敗的結點。
這些系統的程度則取決於日誌的多樣性。一個完全可靠的系統可以用日誌來對數據分片、存儲結點、均衡負載，以及用於數據一致性和數據複製等多方面。在這一過程中，服務層實際上只不過是一種緩存機制，這種緩存機制允許直接寫入日誌的流處理。
結束語
如果你對於本文中所談到的關於日誌的大部內容，如下內容是您可以參考的其它資料。對於同一事務人們會用不同的術語，這會讓人有一些困惑，從數據庫系統到分佈式系統，從各類企業級應用軟件到廣闊的開源世界。無論如何，在大方向上還是有一些共同之處。
學術論文、系統、評論和博客
關於狀態機和主備份復現的概述。
PacificA是實施微軟基於日誌的分佈式存儲系統的通用架構。
Spanner-並不是每個人都支持把邏輯時間用於他們的日誌，Google最新的數據庫就嘗試使用物理時間，並通過把時間戳直接做為區間來直接建時鐘遷移的不確定性。
Datanomic:解構數據庫，它是Rich Hickey在它的首個數據庫產品中的的重要陳述之一，Rich Hickey是Clojure的創建者。
在消息傳遞系統中回捲恢復協議的調查。我發現這個有助於引入容錯處理和數據庫以外的應用系統日誌恢復。
Reactive Manifesto-事實上我並不清楚反應編程的確切涵義，但是我想它和「事件驅動」指的是同一件事。這個鏈接並沒有太多的訊息，但由久富盛史的Martin Odersky講授的課程是很有吸引力的。
Paxos!
1)Leslie Lamport有一個有趣的歷史：在80年代算法是如何發現的，但是直到1998年才發表了，因為評審組不喜歡論文中的希臘寓言，而作者又不願修改。
2)甚至於論文發佈以後，它還是不被人們理解。Lamport再次嘗試，這次它包含了一些並不有趣的小細節，這些細節是關於如何使用這些新式的自動化的計算機的。它仍然沒有得到廣泛的認可。
3)Fred Schneider和Butler Lampson分別給出了更多細節關於在實時系統中如何應用Paxos.
4)一些Google的工程師總結了他們在Chubby中實施Paxos的經驗。
5)我發現所有關於Paxos的論文理解起來很痛苦，但是值得我們費大力氣弄懂。你不必忍受這樣的痛苦了，因為日誌結構的文件系統的大師John Ousterhout的這個視頻讓這一切變得相當的容易。這些一致性算法用展開的通信圖表述的更好，而不是在論文中通過靜態的描述來說明。頗為諷刺的是，這個視頻錄製的初衷是告訴人們Paxos很難理解。
6)使用Paxos來構造規模一致的數據存儲。
Paxos有很多的競爭者。如下諸項可以更進一步的映射到日誌的實施，更適合於實用性的實施。
1)由Barbara Liskov提出的視圖戳復現是直接進行日誌復現建模的較早的算法。
2)Zab是Zookeeper所使用的算法。
3)RAFT是易於理解的一致性算法之一。由John Ousterhout講授的這個視頻非常的棒。
你可以的看到在不同的實時分佈式數據庫中動作日誌角色：
1)PNUTS是探索在大規模的傳統的分佈式數據庫系統中實施以日誌為中心設計理念的系統。
2)Hbase和Bigtable都是在目前的數據庫系統中使用日誌的樣例。
3)LinkedIn自己的分佈式數據庫Espresso和PNUTs一樣，使用日誌來復現，但有一個小的差異是它使用自己底層的表做為日誌的來源。
流處理：這個話題要總結的內容過於寬泛，但還是有幾件我所關注的要提一下：
1)TelegraphCQ
2)Aurora
3)NiagaraCQ
4)離散流：這篇論文討論了Spark的流式系統。
5)MillWheel 它是Google的流處理系統之一。
6)Naiad：一個實時數據流系統
7)在數據流系統中建模和相關事件：它可能是研究這一領域的最佳概述之一。
8)分佈處式流處理的高可用性算法。
企業級軟件存在著同樣的問題，只是名稱不同，或者規模較小，或者是XML格式的。哈哈，開個玩笑。
事件驅動——據我所知：它就是企業級應用的工程師們常說的「狀態機的復現」。有趣的是同樣的理念會用在如此迥異的場景中。事件驅動關注的是小的、內存中的使用場景。這種機制在應用開發中看起來是把發生在日誌事件中的「流處理」和應用關聯起來。因此變得不那麼瑣碎：當處理的規模大到需要數據分片時，我關注的是流處理作為獨立的首要的基礎設施。
變更數據捕獲–在數據庫之外會有些對於數據的舍入處理，這些處理絕大多數都是日誌友好的數據擴展。
企業級應用集成，當你有一些現成的類似客戶類系管理CRM和供應鏈管理SCM的軟件時，它似乎可以解決數據集成的問題。
複雜事件處理(CEP)，沒有人知道它的確切涵義或者它與流處理有什麼不同。這些差異看起來集中在無序流和事件過濾、發現或者聚合上，但是依我之見，差別並不明顯。我認為每個系統都有自己的優勢。
企業服務總線(ESB)——我認為企業服務總線的概念類似於我所描述的數據集成。在企業級軟件社區中這個理念取得了一定程度的成功，對於從事網絡和分佈式基礎架構的工程師們這個概念還是很陌生的。
一些相關的開源軟件：
Kafka是把日誌作為服務的一個項目，它是後邊所列各項的基礎。
Bookeeper 和Hedwig 另外的兩個開源的「把日誌作為服務」的項目。它們更關注的是數據庫系統內部構件而不是事件數據。
Databus是提供類似日誌的數據庫表的覆蓋層的系統。
Akka 是用於Scala的動作者架構。它有一個事件驅動的插件，它提供持久化和記錄。
Samza是我們在LinkedIn中用到的流處理框架，它用到了本文論述的諸多理念，同時與Kafka集成來作為底層的日誌。
Storm是廣泛使用的可以很好的與Kafka集成的流處理框架之一。
Spark Streaming一個流處理框架，它是Spark的一部分。
Summingbird是在Storm或Hadoop之上的一層，它提供了便潔的計算摘要。
本文由「華爾街俱樂部」推薦。
