“不懂得日志，你就不可能完全懂得資料庫”jay kreps說道，jay kreps是linkedin公司首席工程師，本文介紹他本人對于日志的心得體會，包括日志是什麼，如何在資料內建、實時處理和系統建構中使用日志等。
我們最後要讨論的是線上資料系統設計中日志的角色。
在分布式資料庫資料流中日志的角色和在大型組織機構資料完整中日志的角色是相似的。在這兩個應用場景中，日志是對于資料源是可靠的，一緻的和可恢複的。組織如果不是一個複雜的分布式資料系統呢，它究竟是什麼？
如果換個角度，你可以看到把整個組織系統和資料流看做是單一的分布式資料系統。你可以把所有的子查詢系統（諸如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和資料庫被用做系統的記錄和變更流，通過日志你可以查詢系統。持有特定分片的結點在本地完成寫操作。這些結點盲目的把日志提供的資料轉錄到它們自己的存儲空間中。通過回放上行流日志可以恢複轉錄失敗的結點。
這些系統的程度則取決于日志的多樣性。一個完全可靠的系統可以用日志來對資料分片、存儲結點、均衡負載，以及用于資料一緻性和資料複制等多方面。在這一過程中，服務層實際上隻不過是一種緩存機制，這種緩存機制允許直接寫入日志的流處理。
如果你對于本文中所談到的關于日志的大部内容，如下内容是您可以參考的其它資料。對于同一事務人們會用不同的術語，這會讓人有一些困惑，從資料庫系統到分布式系統，從各類企業級應用軟體到廣闊的開源世界。無論如何，在大方向上還是有一些共同之處。
原文釋出時間為：2016-05-31
本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号