原作者：Sijie Guo
翻譯：StreamNative-Sijia
Apache BookKeeper 是企業級存儲系統，旨在保證高持久性、一致性與低延遲。Pulsar 由雅虎研究院（Yahoo! Research）開發，旨在實現 Hadoop 分布式文件系統（HDFS）NameNode 的高可用，在此之前，NameNode 不具備高可用特性，存在單點故障的問題。自 2011 年起，BookKeeper 開始在 Apache ZooKeeper 下作為子項目孵化，并于 2015 年 1 月作為頂級項目成功問世。在這四年間，Twitter、Yahoo、Salesforce 等公司使用 BookKeeper 存儲和服務重要數據，并支撐了許多不同場景。本文將簡要介紹 BookKeeper 的概念和相關術語。
背景介紹
BookKeeper 的開發者（Benjamin Reed、Flavio Junqueira、Ivan Kelly）憑借搭建 ZooKeeper 的經驗設計了一個靈活的系統，能夠支持多種工作負載。最初，BookKeeper 是分布式系統的預寫式日志（WAL）機制。現在 BookKeeper 已經發展成為支持多個企業級系統的基礎構建模塊，如：Twitter 的 EventBus、雅虎的 Apache Pulsar 等。
BookKeeper 是什么？
BookKeeper 是一種優化實時工作負載的存儲服務，具有可擴展、高容錯、低延遲的特點。根據我們多年的工作經驗，企業級的實時存儲平臺應符合以下幾項要求：
- 以極低的延遲（小于 5 毫秒）讀寫 entry 流
- 能夠持久、一致、容錯地存儲數據
- 在寫數據時，能夠進行流式傳輸或追尾傳輸
- 有效地存儲、訪問歷史數據與實時數據
BookKeeper 的設計完全符合以上要求，并廣泛用于多種用例，例如為分布式系統提供高可用性或多副本（如 HDFS NameNode 節點、Twitter 的 Manhattan key-value 存儲）；在單個集群中或多個集群間（多個數據中心）提供跨機器復制；為發布/訂閱（pub-sub）消息系統（如 Twitter 的 EventBus、Apache Pulsar）提供存儲服務；為流工作存儲不可變對象（例如：檢查點數據的快照）等。
BookKeeper 的概念及術語
BookKeeper 復制并持久存儲日志流。日志流是形成良好序列的記錄流。
記錄
數據以不可分割記錄的序列，而不是單個字節寫入 Apache BookKeeper 的日志。記錄是 BookKeeper 中最小的 I/O 單元，也被稱作地址單元。單條記錄中包含與該記錄相關或分配給該記錄的序列號（例如遞增的長數）。客戶端總是從特定記錄開始讀取，或者追尾序列。也就是說，客戶端通過監聽序列來尋找下一條要添加到日志中的記錄。客戶端可以單次接收單條記錄，也可以接收包含多條記錄的數據塊。序列號也可以用于隨機檢索記錄。
日志
BookKeeper 中提供了兩個表示日志存儲的名詞：一個是 ledger（又稱日志段）；另一個是 stream（又稱日志流）。
Ledger 用于記錄或存儲一系列數據記錄（日志）。當客戶端主動關閉或者當充當 writer 的客戶端宕機時，正在寫入此 ledger 的記錄會丟失，而之前存儲在 ledger 中的數據不會丟失。Ledger 一旦被關閉就不可變，也就是說，不允許向已關閉的ledger 中添加數據記錄（日志）。
圖1 BookKeeper ledger：有界數據 entries 序列
Stream（又稱日志流）是無界、無限的數據記錄序列。默認情況下，stream 永遠不會丟失。stream 和 ledger 有所不同。在追加記錄時，ledger 只能運行一次，而 stream 可以運行多次。一個 stream 由多個 ledger 組成；每個 ledger 根據基于時間或空間的滾動策略循環。在 stream 被刪除之前，stream 有可能存在相對較長的時間（幾天、幾個月，甚至幾年）。Stream 的主要數據保留機制是截斷，包括根據基于時間或空間的保留策略刪除最早的 ledger。
圖2 BookKeeper stream：無界數據記錄 stream
Ledger 和 stream 為歷史數據和實時數據提供統一的存儲抽象。在寫入數據時，日志流流式傳輸或追尾傳輸實時數據記錄。存儲在 ledger 的實時數據成為歷史數據。累積在 stream 中的數據不受單機容量的限制。
命名空間
通常情況下，用戶在命名空間分類、管理日志流。命名空間是租戶用來創建 stream 的一種機制，也是一個部署或管理單元。用戶可以配置命名空間級別的數據放置策略。同一命名空間的所有 stream 都擁有相同的命名空間的設置，并將記錄存放在根據數據放置策略配置的存儲節點中。這為同時管理多個 stream 的機制提供了強有力的支持。
Bookies
Bookies 即存儲服務器。一個 bookie 是一個單獨的 BookKeeper 存儲服務器，用于存儲數據記錄。BookKeeper 跨 bookies 復制并存儲數據 entries。出于性能考慮，單個 bookie 上存儲 ledger 段，而不是整個 ledger。因此，bookie 就像是整個集成的一部分。對于任意給定 ledger L，集成指存儲 L 中 entries 的一組 bookies。將 entries 寫入 ledger 時，entries 就會跨集成分段（寫入 bookies 的一個分組而不是所有的 bookies）。
元數據
BookKeeper 需要元數據存儲服務，用來存儲 ledger 與可用 bookie 的相關信息。目前，BookKeeper 利用ZooKeeper 來完成這項工作（除了數據存儲服務外，還包括一些協調、配置管理任務等）。
與 BookKeeper 交互
與 bookie 交互時，BookKeeper 應用程序有兩個主要作用：一個是創建 ledger 或 stream 以便寫入數據；另一個是打開 ledger 或 stream 以便讀取數據。為了與 BookKeeper 中兩個不同的存儲原語交互，BookKeeper 提供了兩個 API。
| API | 說明 |
|---|---|
| Ledger API | 較低級別的 API，允許用戶直接與 ledger 交互，極具靈活性，用戶可根據需要與 bookie 交互。 |
| Stream API | 較高級別、面向流的 API，通過 Apache DistributedLog 實現。用戶無需管理與 ledger 交互的復雜性，就可以與 stream 交互。 |
選擇使用哪個 API 取決于用戶對 ledger 語義設定的的粒度控制程度。 用戶也可以在單個應用程序中同時使用這兩個 API。
放在一起看
下圖即為 BookKeeper 的典型安裝示例。
上圖中的幾個注意事項：
- 典型的 BookKeeper 安裝包括元數據存儲區（如 ZooKeeper）、bookie 集群，以及通過提供的客戶端庫與 bookie 交互的多個客戶端。
- 為便于客戶端的識別，bookie 會將自己廣播到元數據存儲區。
- Bookie 會與元數據存儲區交互，作為回收站收集已刪除數據。
- 應用程序通過提供的客戶端庫與 BookKeeper 交互（使用 ledger API 或 DistributedLog Stream API）
- 應用程序 1 需要對 ledger 進行粒度控制，以便直接使用 ledger API。
- 應用程序 2 不需要較低級別 ledger 控制，因此使用更加簡化的日志流 API。
總結
本文對 BookKeeper 進行了技術層面的概述，首先介紹了 entry、ledger、stream、命名空間、bookie 的概念，然后介紹了典型的 BookKeeper 部署，以及如何處理數據等。
如果你對 BookKeeper 或 DistributedLog 感興趣，可以通過以下方式加入我們的社區：
想要了解更多關于 Apache BookKeeper 項目的信息，請訪問官方網站：http://bookkeeper.apache.org，或在 Twitter 上關注 @asfbookkeeper。
想要隨時掌握 Pulsar 的研發進展、用戶案例和熱點話題嗎？快來關注 Apache Pulsar 和 StreamNative 微信公眾號，我們第一時間在這里分享與 Pulsar 有關的一切。
原文鏈接：https://www.splunk.com/en_us/blog/it/introduction-to-apache-bookkeeper.html
