首席工程師揭秘：LinkedIn大數據后臺是如何運作的

編者按： Jay Kreps是來自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的工作。

為了理解兩種方式的不同，我們來看一個不太嚴謹的例子。假定有一個算法服務的副本，保持一個獨立的數字作為它的狀態（初始值為0），并對這個值進行加法和乘法運算。主動-主動方式應該會輸出所進行的變換，比如“+1”，“*2”等。每一個副本都會應用這些變換，從而得到同樣的解集。主動-被動方式將會有一個獨立的主體執行這些變換并輸出結果日志，比如“1”，“3”，“6”等。這個例子也清楚的展示了為什么說順序是保證各副本間一致性的關鍵：一次加法和乘法的順序的改變將會導致不同的結果。

分布式日志可以理解為一致性問題模型的數據結構。因為日志代表了后續追加值的一系列決策。你需要重新審視Paxos算法簇，盡管日志模塊是他們最常見的應用。 在Paxos算法中，它通常通過使用稱之為多paxos的協議，這種協議將日志建模為一系列的問題，在日志中每個問題都有對應的部分。在ZAB， RAFT等其它的協議中，日志的作用尤為突出，它直接對維護分布式的、一致性的日志的問題建模。

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

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

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

讓我們繼續聊數據庫。數據庫中存在著大量變更日志和表之間的二相性。這些日志有點類似借貸清單和銀行的流程，數據庫表就是當前的盈余表。如果你有大量的變更日志，你就可以使用這些變更用以創建捕獲當前狀態的表。這張表將記錄每個關鍵點（日志中一個特別的時間點）的狀態信息。這就是為什么日志是非常基本的數據結構的意義所在：日志可用來創建基本表，也可以用來創建各類衍生表。同時意味著可以存儲非關系型的對象。

這個流程也是可逆的：如果你正在對一張表進行更新，你可以記錄這些變更，并把所有更新的日志發布到表的狀態信息中。這些變更日志就是你所需要的支持準實時的克隆。基于此，你就可以清楚的理解表與事件的二相性： 表支持了靜態數據而日志捕獲變更。日志的魅力就在于它是變更的完整記錄，它不僅僅捕獲了表的最終版本的內容，它還記錄了曾經存在過的其它版本的信息。日志實質上是表歷史狀態的一系列備份。

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

最近，有些人從Datomic

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈