[TOC] 最后我要討論的是在線數據系統設計中日志的角色。 日志服務在分布式數據庫中服務于數據流 可以類比 日志服務在大型組織機構中服務于數據集成。 在這兩個應用場景中，日志要解決的問題 都是 數據流、一致性和可恢復性。 如果組織不是一個很復雜的分布式數據系統呢，它究竟是什么？ ## [](https://github.com/oldratlee/translations/blob/master/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md#分解單品方式而不是打包套餐方式unbundling)分解單品方式而不是打包套餐方式（`Unbundling`）？ 如果你換個角度，可以把組織的系統和數據流整體看做整個一個分布式數據： 把所有獨立的面向查詢的系統（如`Redis`、`SOLR`、`Hive`表，等等）看做只是你的數據的特定的索引； 把流處理系統（如`Storm`、`Samza`）看做只是一種很成熟的觸發器和視圖的具體機制。 我注意到，傳統的數據庫人員非常喜歡這樣的觀點，因為他們終于能解釋通，這些不同的數據系統到底是做什么用的 —— 它們只是不同的索引類型而已！ 不可否認這段時間涌現了大量類型的數據系統，但實際上，這方面的復雜性早就存在。 即使是在關系數據庫的鼎盛時期，組織里就有種類繁多的關系數據庫！ 因為大型機，所有的數據都存儲在相同的位置，所以可能并沒有真正的數據集成。 有很多推動力要把數據分離到多個系統：數據伸縮性、地理地域、安全性和性能隔離是最常見的。 這些問題可以通過一個好的系統來解決： 比如組織使用單個`Hadoop`保存所有數據來服務大量各式各樣的客戶，這樣做是可能的。 所以處理的數據向分布式系統變遷的過程中，已經有了個可能的簡單方法： 把大量的不同系統的小實例合到少數的大集群中。 許多的系統還不足好到支持這個方法：它們沒有安全，或者不能保證性能隔離性，或者伸縮性不夠好。 不過這些問題都是可以解決的。 依我之見，不同系統大量涌現的原因是構建分布式數據系統的難度。 把關注點消減到單個查詢類型或是用例，各個系統可以把關注范圍控制到一組能構建出來的東西上。 但是把全部這些系統運行起來，這件事有非常多的復雜性。 我覺得解決這類問題將來有三個可能的方向： 第一種可能性是延續現狀：各個分離的系統在往后很長的一段時間里基本保持不變。 發生這種可能要么是因為建設分布式系統的困難很難克服， 要么系統的專用化（`specialization`）能讓各個系統的便得性（`convenience`）和能力（`power`）達到一個新的高度。 只要現狀不變，為了能夠使用數據，數據集成問題將仍會最核心事情之一。 如果是這樣，用于集成數據的外部日志將會非常的重要。 第二種可能性是一個統一合并的系統（`re-consolidation`），這個系統具備足夠的通用性，逐步把所有不同的功能合并成單個超極系統。 這個超級系統表面看起來類似關系數據庫，但在組織中使用方式會非常不一樣，因為只能用一個大系統而不是無數個小系統。 在這樣的世界里，除了系統自身的內部，不存在真正的數據集成問題。 我覺得，因為建設這樣的系統的實際困難，使這個情況不太可能發生。 還有另一種可能的結果，呃，其實我覺得這個結果對工程師很有吸引力。 新一代數據系統的一個讓人感興趣的特征是，這個系統幾乎是完全開源的。 開源提供了另一個可能性：數據基礎架構不用是打包套餐式的而是分解單品成一組服務及面向應用的`API`。 在`Java`棧中，你可以看到這種狀況在一定程度上已經發生了： * [`Zookeeper`](http://zookeeper.apache.org/)處理系統之間的協調的很多問題。 （或許諸如[`Helix`](http://helix.incubator.apache.org/)?或[`Curator`](http://curator.incubator.apache.org/)等高級別抽象可以有些幫助）。 * [`Mesos`](http://mesos.apache.org/)和[`YARN`](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html)?處理虛擬化（`virtualization`）和資源管理。 * [`Lucene`](http://lucene.apache.org/)和[`LevelDB`](https://code.google.com/p/leveldb)等嵌入式類庫做為索引。 * [`Netty`](http://netty.io/)、[`Jetty`](http://www.eclipse.org/jetty)?和 更高層封裝如[`Finagle`](http://twitter.github.io/finagle)、[`rest.li`](http://rest.li/)處理遠程通信。 * [`Avro`](http://avro.apache.org/)、[`Protocol Buffers`](https://code.google.com/p/protobuf)、[`Thrift`](http://thrift.apache.org/)和[`umpteen zillion`](https://github.com/eishay/jvm-serializers/wiki)等其它類庫處理序列化。 * [`Kafka`](http://kafka.apache.org/)和[`Bookeeper`](http://zookeeper.apache.org/bookkeeper)提供后端支持的日志。 如果你把上面這些疊成一堆，換個角度去看，它會有點像是樂高版（`lego version`）的分布式數據系統工程。 你可以把這些零件拼裝在一起，創建大量的可能的系統。 顯然，上面說的不是面向 主要關心`API`及`API`實現的最終用戶， 但在一個更多樣化和模塊化且持續演變的世界中，這可能一條途徑可以通往簡潔的單個系統。 因為隨著可靠的、靈活的構建模塊的出現，實現分布式系統的時間由年縮減為周，聚合形成大型整體系統的壓力將會消失。 ## [](https://github.com/oldratlee/translations/blob/master/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md#日志在系統架構中的地位)日志在系統架構中的地位 提供外部日志的系統允許各個系統拋棄很多各自的復雜性，依靠共享的日志。在我看來，日志可以做到以下事情： * 通過對節點的并發更新的排序處理，處理了數據一致性（無論即時的還是最終的一致） * 提供節點之間的數據復制 * 為寫入者提供『提交（`commit`）』語義（僅當寫入數據確保不會丟失時才會收到完成確認（`acknowledge`）） * 為系統提供外部的數據訂閱 * 對于丟失數據的失敗了的復本，提供恢復或是啟動一個新復本的能力 * 調整節點間的數據平衡 這就是一個數據分布式系統所要做的主要部分，實際上，剩下的大部分內容是與 最終用戶要面對的查詢`API`和索引策略相關的。 這正是不同系統間的應該變化的部分，例如：一個全文搜索查詢語句可能需要查詢所有分區， 而一個主鍵查詢只需要查詢負責這個主鍵數據的單個節點就可以了。 [](https://github.com/oldratlee/translations/blob/master/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/images/system.png) 下面我們來看下系統是如何工作的。 系統被分為兩個邏輯部分：日志和服務層。日志按順序捕獲狀態變化。 服務節點存儲索引提供查詢服務需要的所有信息（比如鍵值存儲的索引可能會類似`BTree`或`SSTable`，搜索系統可能用的是倒排索引（`inverted index`））。 寫入操作可以直接進入日志，盡管可能經過服務層的代理。 在寫入日志的時候會生成邏輯時間戳（稱為日志中的索引），如果系統是分區的，我也假定是分區的， 那么日志和服務節點會包含相同分區個數，盡管兩者的機器臺數可能相差很多。 服務節點訂閱日志，并按照日志存儲的順序盡快把日志寫到它的本地索引中。 客戶端只要在查詢語句中提供某次寫入操作的時間戳，就可以有從任何節點『讀到該次寫入』的語義（`read-your-write semantics`） —— 服務節點收到該查詢語句后，會將其中的時間戳與自身索引的位置比較， 如果必要，服務節點會延遲請求直到它的索引至少已經跟上那個時間戳，以避免提供的是舊數據。 服務節點可能會或可能不會需要感知`master`身份或是當選`leader`。 對很多簡單的使用場景，服務節點集群可以完全無需`leader`，因為日志是正確真實的信息源。 分布式系統所需要處理的一件比較復雜的事是 恢復失敗節點 和 在結點之間移動分片（`partition`）。 典型的做法是僅保留一個固定窗口的數據，并把這個數據和分片中存儲數據的一個快照關聯。 另一個相同效果的做法是，讓日志保留數據的完整拷貝，并[對日志做垃圾回收](https://cwiki.apache.org/confluence/display/KAFKA/Log+Compaction)。 這把大量的復雜性從特定于系統的系統服務層移到了通用的日志中。 有了這個日志系統，你得到一個成熟完整的訂閱`API`，這個`API`可以訂閱數據存儲的內容，驅動到其它系統的`ETL`操作。 事實上，許多系統都可以共享相同的日志以提供不同的索引，如下所示： [](https://github.com/oldratlee/translations/blob/master/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/images/full-stack.png) 注意，這樣的以日志為中心的系統是如何做到本身即是 在其它系統中要處理和加載的數據流的提供者的呢？ 同樣，流處理器既可以消費多個輸入流，然后通過這個流處理器輸出把這些輸入流的數據索引到其它系統中。 我覺得把系統分解成日志和查詢`API`的觀點很有啟迪性，因為使得查詢相關的因素與系統的可用性和一致性方面解耦。 我其實覺得這更是個好用的思路，可以對于沒按這種方式構建的系統做概念上的分解。 值得一提的是，盡管`Kafka`和`Bookeeper`都是一致性日志，但并不是必須的。 你可以輕松把[`Dynamo`](http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html)之類的數據庫作為你的系統的 最終一致的[`AP`](http://en.wikipedia.org/wiki/CAP_theorem)日志和鍵值對服務層。 這樣的日志使用起來很靈活，因為它會重傳了舊消息并依賴訂閱者的信息處理（很像`Dynamo`所做的）。 很多人認為在日志中維護數據的單獨拷貝（特別是做全量數據拷貝）太浪費。 然而事實上，有幾個因素可以讓這個不成為問題。 首先，日志可以是一種特別高效的存儲機制。在我們`Kafka`生產環境的服務器上，每個數據中心都存儲了超過75TB的數據。 同時其它的許多服務系統需要的是多得多的內存來提供高效的服務（例如文本搜索，它通常是全在內存里）。 其次，服務系統會用優化過的硬件。例如，我們的在線數據系統或者基于內存提供服務或者使用固態硬盤。 相反，日志系統只需要線性讀寫，因此很合適用TB級的大硬盤。 最后，如上圖所示，多個系統使用日志數據提供服務，日志的成本是分攤到多個索引上。 上面幾點合起來使得外部日志的開銷相當小。 `LinkedIn`正是使用這個模式構建了它很多的實時查詢系統。 這些系統的數據來自數據庫（使用作為日志概念的數據總線，或是來自`Kafka`的真正日志），提供了在這個數據流上特定的分片、索引和查詢能力。 這也是我們實現搜索、`social graph`和`OLAP`查詢系統的方式。 事實上，把單個數據源（無論來自`Hadoop`的在線數據源還是派生數據源）復制到多個在線服務系統中，這個做法很常見。 這種方式經過了驗證可以大大簡化系統的設計。 系統根本不需要給外部提供寫入`API`，`Kafka`和數據庫通過日志給查詢系統提供記錄和變更流。 各個分片的結點在本地完成寫操作。 這些結點只要機械地把日志中的數據轉錄到自己的存儲中。失敗的結點通過回放上游的日志就可以恢復。 系統的強度取決于日志的使用方式。一個完全可靠的系統把日志用作數據分片、結點的存儲、負載均衡，以及所有和數據一致性和數據傳播（`propagation`）有關的方面。 在這樣的架構中，服務層實際上只不過是一種『緩存』，可以通過直接寫日志就能完成某種處理。