LinkedIn大資料平臺深度解析（上）

我在六年前的一個令人興奮的時刻加入到LinkedIn公司。 從那個時候開始我們就破解單一的、集中式資料庫的限制，並且啟動到特殊的分散式系統套件的轉換。 這是一件令人興奮的事情：我們構建、部署，而且直到今天仍然在運行的分散式圖形資料庫、分散式搜索後端、Hadoop安裝以及第一代和第二代鍵值資料存儲。

從這一切裡我們體會到的最有益的事情是我們構建的許多東西的核心裡都包含一個簡單的理念：日誌。 有時候也稱作預先寫入日誌或者提交日誌或者事務日誌，日誌幾乎在電腦產生的時候就存在，同時它還是許多分散式資料系統和即時應用結構的核心。

不懂得日誌，你就不可能完全懂得資料庫，NoSQL存儲，鍵值存儲，複製，paxos,Hadoop,版本控制以及幾乎所有的軟體系統；然而大多數軟體工程師對它們不是很熟悉。 我願意改變這種現狀。 在這篇博客文章裡，我將帶你流覽你必須瞭解的有關日誌的所有的東西，包括日誌是什麼，如何在資料整合、即時處理和系統構建中使用日誌等。

第一部分：日誌是什麼？

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

我們可以給日誌的末尾添加記錄，並且可以從左至右讀取日誌記錄。 每一條記錄都指定了一個唯一的有一定順序的日誌記錄號碼。

日誌記錄的排序是由「時間」來確定的，這是因為位於左邊的日誌記錄比位於右邊的要早些。 日誌記錄號碼可以看作是這條日誌 記錄的「時間戳記」。 在一開始就把這種排序說成是按時間排序顯得有點多餘 ，不過 ，與任何一個具體的物理時鐘相比，時間 屬性是非常便於使用的屬性。 在我們運行多個分散式系統的時候，這個屬性就顯得非常重要。

對於這篇討論的目標而言，日誌記錄的內容和格式不怎麼重要。 另外提醒一下，在完全耗盡存儲空間的情況下，我們不可能 再給日誌添加記錄。 稍後我們將會提到這個問題。

日誌並不是完全不同于檔或者資料表的。 檔是由一系列位元組組成，表是由一系列記錄組成，而日誌實際上只是按照時間順序存儲記錄的 一種資料表或者檔。

此時，你可能奇怪為什麼要討論這麼簡單的事情呢？ 不同環境下的一個只可增加的有一定順序的日誌記錄是怎樣與資料系統關聯起來的呢？ 答案是日誌有其特定的應用目標：它記錄了什麼時間發生了什麼事情。 而對分散式資料系統許多方面而言， 這才是問題的真正核心。

不過，在我們進行更加深入的討論之前，讓我先澄清有些讓人混淆的概念。 每個程式設計人員都熟悉另一種日誌記錄-應用使用syslog或者log4j可能寫入到本地檔裡的沒有結構的錯誤資訊或者追蹤資訊。 為了區分開來，我們把這種情形的日誌記錄稱為「應用日誌記錄」。 應用日誌記錄是我在這兒所說的日誌的一種低級的變種。 最大的區別是：文本日誌意味著主要用來方便人們閱讀，而我所說明的「日誌」或者「資料日誌」的建立是方便程式訪問。

（實際上，如果你對它進行深入的思考，那麼人們讀取某個機器上的日誌這種理念有些不順應時代潮流。 當涉及到許多服務和伺服器的時候，這種方法很快就變成一個難於管理的方式，而且為了認識多個機器的行為，日誌的目標很快就變成查詢和圖形化這些行為的輸入了-對多個機器的某些行為而言， 檔裡的英文形式的文本同這兒所描述的這種結構化的日誌相比幾乎就不適合了。 ）

資料庫日誌

我不知道日誌概念起源於何處-可能它就像二進位搜索一樣：發明者認為它太簡單而不能當作一項發明。 它早在IBM的系統R出現時候就出現了。 資料庫裡的用法是在崩潰的時候用它來同步各種資料結構和索引。 為了保證操作的原子性和持久性，在對資料庫維護的所有各種資料結構做更改之前，資料庫把即將修改的資訊謄寫到日誌裡。 日誌記錄了發生了什麼，而且其中的每個表或者索引都是一些資料結構或者索引的歷史映射。 由於日誌是即刻永久化的，可以把它當作崩潰發生時用來恢復其他所有永久性結構的可信賴資料來源。

隨著時間的推移，日誌的用途從實現ACID細節成長為資料庫間複製資料的一種方法。 利用日誌的結果就是發生在資料庫上的更改順序與遠端複製資料庫上的更改順序需要保持完全同步。

Oracle,MySQL 和PostgreSQL都包括用於給備用的複製資料庫傳輸日誌的日誌傳輸協議。 Oracle還把日誌產品化為一個通用的資料訂閱機制，這樣非Oracle資料訂閱使用者就可以使用XStreams和GoldenGate訂閱資料了，MySQL和PostgreSQL上的類似的實現則成為許多資料結構的關鍵元件。

正是由於這樣的起源，機器可識別的日誌的概念大部分都被局限在資料庫內部。 日誌用做資料訂閱的機制似乎是偶然出現的，不過要把這種 抽象用於支援所有類型的消息傳輸、資料流程和即時資料處理是不切實際的。

(責任編輯：mengyishan)