《大資料系統建構：可擴充實時資料系統建構原理與最佳實踐》一導讀

前　　言

當第一次進入大資料的世界時,我仿佛置身于軟體開發的美國西部荒原。許多人放棄了關系型資料庫，轉而選擇帶有高度受限模型的nosql資料庫，主要是因為其使用體驗良好、熟悉度較高且這種資料庫可以擴充到成千上萬台機器上。nosql資料庫的數量巨大，堪稱鋪天蓋地，這些資料庫中很多都隻有細微的差别。一個名為“hadoop”的新項目開始嶄露頭角,它宣稱具備基于海量資料進行資料深度分析的能力。但弄清楚如何使用這些新工具很令人困惑。

當時，我正試圖處理所在公司面臨的擴充性問題。系統架構非常複雜—該web系統包含共享關系型資料庫、隊列、工作節點、主節點和從節點。資料損壞滲透至資料庫，為了處理這些損壞，我們使用了應用程式中的特殊代碼，但從節點的操作總是落後于其他節點。我決定探索其他大資料技術，看看是否有比我們的資料架構更好的設計。

早期的軟體工程職業生涯的經曆，深刻影響了我對“系統該如何架構”的觀點。我的一位同僚花了幾個星期将來自網際網路的資料收集到一個共享檔案系統。他在等待收集足夠的資料，以便能在其上進行資料分析。有一天，在做一些日常維護時，我不小心删除了他的所有資料，導緻他的項目延期了好幾周。

我知道自己犯了一個大錯，但作為一個軟體工程師新手，我并不知道這會導緻什麼樣的後果。我會不會因為粗心被解雇呢？我發了一封電子郵件向團隊誠摯道地歉—讓我驚喜的是，大家對此都表示非常同情。我永遠不會忘記那個時刻—一個同僚來到我的辦公桌旁，拍着我的背說：“恭喜你！你現在是一個專業的軟體工程師了！”

他玩笑式的表述道出了軟體開發中不言而喻的“真理”—我們不知道如何創造完美的軟體。軟體可能有bug而且會被部署到生産中。如果應用程式可以寫入資料庫中，那麼bug也可能寫入資料庫中。當着手重新設計我們的資料架構時，這樣的經曆深深地影響了我。我知道，新架構不但必須是可擴充的、對機器故障是可容錯的，并且要易于推斷故障原因—但對人為錯誤也可容錯。

重構那套系統的經驗，促使我走上了一條“在資料庫和資料管理方面懷疑一切我認為是正确的”道路。我想出了一個基于不可變資料和批量計算的架構，令我很驚訝的是，與僅僅基于增量計算的系統相比，新系統要簡單得多。一切都變得更容易，包括操作、不斷發展的系統以支援新的功能、從人為錯誤中恢複和性能優化等方面。該方法很通用，似乎可以用于任何資料系統。

但有些事情困擾着我。當觀察其他行業時，我發現幾乎沒有人使用類似的技術。相反，在使用基于增量更新資料庫的龐大叢集架構中，令人生畏的複雜性是為人所接受的。這些架構的許多複雜性已經通過我所開發的方法完全避免或大大緩減了。

在接下來的幾年中，我擴充了該方法，并使之正式成為我戲稱的lambda架構。在初創公司backtype工作時，我們的5人團隊建構了一個社會化媒體分析産品，該産品支援在超過100tb的資料上進行多樣化實時分析。我們的小團隊還負責擁有數百台機器的叢集的管理部署、營運和系統監控。當我們向别人展示自己的産品時，他們對這個團隊隻有5個人感到非常驚訝。他們經常會問“這麼幾個人做了這麼多事情？怎麼可能！？”我的回答很簡單：“不是我們在做什麼，而是我們沒有做什麼。”通過使用lambda架構，我們避免了困擾傳統架構的複雜性。通過避免這些複雜性，我們大大提高了工作效率。

大資料運動隻是放大了已經存在了幾十年的資料架構的複雜性。主要基于增量更新的大型資料庫架構将遭受這些複雜性的折磨，進而導緻錯誤、繁重的操作，并阻礙了生産力。盡管sql和nosql資料庫通常被描述成對立或互相對偶的關系，但從最基本的方面來說，它們實際上是一樣的。它們都鼓勵使用這種相同的架構—該架構具有不可避免的複雜性。複雜性是一個邪惡的野獸，無論你承認與否，它都會“咬”你。

為了傳播lambda架構以及它如何避免傳統架構的複雜性等知識，我寫了本書。它是我開始從事大資料工作時就希望有的。我希望你把這本書作為一個旅程—挑戰你以為自己已經知道的關于資料系統的知識，并發現從事大資料工作也可以優雅、簡單和有趣。

nathan marz

目錄

譯 者 序

關于本書

緻　　謝

第1章 大資料的新範式

1.2.1　用隊列擴充

1.2.2　通過資料庫分片進行擴充

1.2.3　開始處理容錯問題

1.2.4　損壞問題

1.2.5　到底是哪裡出錯了

1.2.6　大資料技術是如何起到幫助作用的

1.5.1　魯棒性和容錯性

1.5.2　 低延遲讀取和更新

1.5.3　可擴充性

1.5.4　通用性

1.5.5　延展性

1.5.6　即席查詢

1.5.7　最少維護

1.5.8　可調試性

1.6.1　操作複雜性

1.6.2　實作最終一緻性的極端複雜性

1.6.3　缺乏容忍人為錯誤

1.6.4　全增量架構解決方案與 lambda架構解決方案

1.7.1　批處理層

1.7.2　服務層

1.7.3　批處理層和服務層滿足幾乎所有屬性

1.7.4　速度層

1.8.1　cpu并不是越來越快

1.8.2　彈性雲

1.8.3　大資料充滿活力的開源生态系統

第2章　大資料的資料模型

2.1.1　資料是原始的

2.1.2　資料是不可變的

2.1.3　資料是永遠真實的

2.2.1　事實的示例及屬性

2.2.2　基于事實的模型的優勢

2.3.1　圖模式的元素

2.3.2　可實施模式的必要性

第3章大資料的資料模型：示例

3.2.1　節點

3.2.2　邊

3.2.3　屬性

3.2.4　把一切組合成資料對象

3.2.5　模式演變

第4章　批處理層的資料存儲

4.1　主資料集的存儲需求

4.2　為批處理層選擇存儲方案

4.2.1　使用鍵/值存儲主資料集

4.2.2　分布式檔案系統

4.3　分布式檔案系統是如何工作的

4.4　使用分布式檔案系統存儲主資料集

4.5　垂直分區

4.6　分布式檔案系統的底層性質

4.7　在分布式檔案系統上存儲superwebanalytics.com的主資料集

4.8　總結

第5章　批處理層的資料存儲：示例

5.1　使用hdfs

5.1.1　小檔案問題

5.1.2　轉向更高層次的抽象

5.2　使用pail在批處理層存儲資料

5.2.2　序列化對象到pail中

5.2.3　使用pail進行批處理操作

5.2.4　使用pail進行垂直分區

5.2.5　pail檔案格式與壓縮

5.2.6　pail優點的總結

5.3　存儲superwebanalytics.com的主資料集

5.3.1　thrift對象的結構化pail

5.3.2　superwebanalytics.com的基礎pail

5.3.3　用于垂直分區資料集的分片pail

5.4　總結

第6章　批處理層

6.1　啟發性示例

6.1.1　給定時間範圍内的頁面浏覽量

6.1.2　性别推理

6.1.3　影響力分數

6.2　批處理層上的計算

6.3　重新計算算法與增量算法

6.3.1　性能

6.3.2　容忍人為錯誤

6.3.3　算法的通用性

6.3.4　選擇算法的風格

6.4　批處理層中的可擴充性

6.5　mapreduce：一種大資料計算的範式

6.5.1　可擴充性

6.5.2　容錯性

6.5.3　mapreduce的通用性

6.6　mapreduce的底層特性

6.6.1　多步計算很怪異

6.6.2　手動實作連接配接非常複雜

6.6.3　邏輯和實體執行緊密耦合

6.7　管道圖—一種關于批處理計算的進階思維方式

6.7.1　管道圖的概念

6.7.2　通過mapreduce執行管道圖

6.7.3　合并聚合器

6.7.4　管道圖示例

6.8　總結

第7章　批處理層：示例

7.1　一個例證

7.2　資料處理工具的常見陷阱

7.2.1　自定義語言

7.2.2　不良的可組合抽象

7.3　jcascalog介紹

7.3.1　jcascalog的資料模型

7.3.2　jcascalog查詢的結構

7.3.3　查詢多個資料集

7.3.4　分組和聚合器

7.3.5　對一個查詢示例進行單步調試

7.3.6　自定義謂詞操作

7.4　組合

7.4.1　合并子查詢

7.4.2　動态建立子查詢

7.4.3　謂詞宏

7.4.4　動态建立謂詞宏

7.5　總結

第8章　批處理層示例：架構和算法

8.1　superwebanalytics.com批處理層的設計

8.1.1　所支援的查詢

8.1.2　批處理視圖

8.2　工作流概述

8.3　擷取新資料

8.4　url規範化

8.5　使用者辨別符規範化

8.6　頁面浏覽去重

8.7　計算批處理視圖

8.7.1　給定時間範圍内的頁面浏覽量

8.7.2　給定時間範圍内的獨立訪客

8.7.3　跳出率分析

8.8　總結

第9章　批處理層示例：實作

9.1　出發點

9.2　準備工作流

9.3　擷取新資料

9.4　url規範化

9.5　使用者辨別符規範化

9.6　頁面浏覽去重

9.7　計算批處理視圖

9.7.1　給定時間範圍内的頁面浏覽量

9.7.2　給定時間範圍内的獨立訪客

9.7.3　跳出率分析

9.8　總結

第二部分　服務層

第10章　服務層概述

10.1　服務層的性能名額

10.2　規範化/非規範化問題的服務層解決方案

10.3　服務層資料庫的需求

10.4　設計superwebanalytics.com的服務層

10.4.1　給定時間範圍内的頁面浏覽量

10.4.2　給定時間範圍内的獨立訪客

10.4.3　跳出率分析

10.5　對比全增量的解決方案

10.5.1　給定時間範圍内的獨立訪客的全增量方案

10.5.2　與lambda架構解決方案的比較

10.6　總結

第11章　服務層：示例

11.1　elephantdb的基本概念

11.1.1　elephantdb中的視圖建立

11.1.2　elephantdb中的視圖服務

11.1.3　使用elephantdb

11.2　建立superwebanalytics.com的服務層

11.2.1　給定時間範圍内的頁面浏覽量

11.2.2　給定時間範圍内的獨立訪客數量

11.2.3　跳出率分析

11.3　總結

第三部分　速度層

第12章　實時視圖

12.1　計算實時視圖

12.2　存儲實時視圖

12.2.1　最終一緻性

12.2.2　速度層中存儲的狀态總量

12.3　增量計算的挑戰

12.3.1　cap原理的有效性

12.3.2　cap原理和增量算法之間複雜的互相作用

12.4　異步更新與同步更新

12.5　過期實時視圖

12.6　總結

第13章　實時視圖：示例

13.1　cassandra的資料模型

13.2　使用cassandra

13.3　總結

第14章　隊列和流處理

14.1　隊列

14.1.1　單消費者隊列

14.1.2　多消費者隊列

14.2　流處理

14.2.1　隊列和工作節點

14.2.2　隊列和工作節點的缺陷

14.3　更高層次的一次一個的流處理

14.3.1　storm模型

14.3.2　保證消息處理

14.4　superwebanalytics.com速度層

14.5　總結

第15章　隊列和流處理：示例

15.1　使用apache storm定義拓撲結構

15.2　apache storm叢集及其部署

15.3　保證消息處理

15.4　實作superwebanalytics.com給定時間範圍内的獨立訪客的速度層3

15.5　總結

第16章　微批量流處理

16.1　實作有且僅有一次語義

16.1.1　強有序處理

16.1.2　微批量流處理

16.1.3　微批量流處理的拓撲結構

16.2　微批量流處理的核心概念

16.3　微批量流處理的擴充管道圖

16.4　完成superwebanalytics.com的速度層

16.4.1　給定時間範圍内的頁面浏覽量

16.4.2　跳出率分析

16.5　另一個跳出率分析示例

16.6　總結

第17章　微批量流處理：示例

17.1　使用trident

17.2　完成superwebanalytics.com的速度層

17.2.1　給定時間範圍内的頁面浏覽量

17.2.2　跳出率分析

17.3　完全容錯、基于記憶體及微批量處理

17.4　總結

第18章　深入lambda架構

18.1　定義資料系統

18.2　批處理層和服務層

18.2.1　增量的批處理

18.2.2　測量和優化批處理層的資源使用

18.3　速度層

18.4　查詢層

18.5　總結