大數據的下一步：用Spark玩轉活用

前言
Chapter 01   Spark 系統概述
1.1 大數據處理架構
1.2 Spark 大數據處理架構
1.2.1 RDD 表達能力
1.2.2 Spark 子系統
1.3 小結

Chapter 02   Spark RDD 及程式設計介面
2.1 Spark 程式"Hello World"
2.2 Spark RDD
2.3 建立操作
2.3.1 集合建立操作
2.3.2 儲存建立操作
2.4 轉換操作
2.4.1 RDD 基本轉換操作
2.4.2 鍵值RDD 轉換操作
2.4.3 再論RDD 相依關係
2.5 控制操作（control operation）
2.6 行動操作（action operation）
2.6.1 集合純量行動操作
2.6.2 儲存行動操作
2.7 小結

Chapter 03   Spark 執行模式及原理
3.1 Spark 執行模式概述
3.1.1 Spark 執行模式清單
3.1.2 Spark 基本工作流程
3.1.3 相關基本類別
3.2 Local 模式
3.2.1 部署及程式執行
3.2.2 內部實現原理
3.3 Standalone 模式
3.3.1 部署及程式執行
3.3.2 內部實現原理
3.4 Local cluster 模式
3.4.1 部署及程式執行
3.4.2 內部實現原理
3.5 Mesos 模式
3.5.1 部署及程式執行
3.5.2 內部實現原理
3.6 YARN standalone / YARN cluster 模式
3.6.1 部署及程式執行
3.6.2 內部實現原理
3.7 YARN client 模式
3.7.1 部署及程式執行
3.7.2 內部實現原理
3.8 各種模式的實現細節比較
3.8.1 環境變數的傳遞
3.8.2 JAR 套件和各種依賴檔案的分發
3.8.3 工作管理和序列化
3.8.4 使用者參數設定
3.8.5 使用者及許可權控制
3.9 Spark 1.0 版本之後的變化
3.10 小結

Chapter 04   Spark 排程管理原理
4.1 Spark 作業排程管理概述
4.2 Spark 排程相關基本概念
4.3 作業排程模組頂層邏輯概述
4.4 作業排程實際工作流程
4.4.1 排程階段的拆分
4.4.2 排程階段的傳送
4.4.3 工作集的傳送
4.4.4 完成狀態的監控
4.4.5 工作結果的取得
4.5 工作集管理模組詳解
4.6 排程池和排程模式分析
4.7 其他排程相關內容
4.7.1 Spark 應用之間的排程關係
4.7.2 排程過程中的資料本機性問題
4.8 小結

Chapter 05   Spark 的儲存管理
5.1 儲存管理模組整體架構
5.1.1 通訊層架構
5.1.2 通訊層訊息傳遞
5.1.3 註冊儲存管理模組
5.1.4 儲存層架構
5.1.5 資料區塊(Block)
5.2 RDD 持久化
5.2.1 RDD 分區和資料區塊的關係
5.2.2 記憶體快取
5.2.3 磁碟快取
5.2.4 持久化選項
5.2.5 如何選擇不同的持久化選項5.4 車標搜索
5.3 Shuffle 資料持久化
5.4 廣播（Broadcast）變數持久化
5.5 小結

Chapter 06   Spark 監控管理
6.1 UI 管理
6.1.1 即時UI 管理
6.1.2 歷史UI 管理
6.2 Metrics 管理
6.2.1 Metrics 系統架構
6.2.2 Metrics 系統組態
6.2.3 輸入來源（Metrics Source）介紹
6.2.4 輸出方式（Metrics Sink）介紹
6.3 小結

Chapter 07   Shark 架構與安裝設定
7.1 Shark 架構淺析
7.2 Hive/Shark 各功能元件比較
7.2.1 MetaStore
7.2.2 CLI/ Beeline
7.2.3 JDBC/ODBC
7.2.4 Hive Server/2 與Shark Server/2
7.2.5 Driver
7.2.6 SQL Parser
7.2.7 查詢最佳化工具（Query Optimizer）
7.2.8 實體計畫與執行
7.3 Shark 安裝設定與使用
7.3.1 安裝前準備工作
7.3.2 在不同執行模式下安裝Shark
7.4 Shark SQL 命令列工具（CLI）
7.5 使用Shark Shell 指令
7.6 啟動SharkServer
7.7 Shark Server2 設定與啟動
7.8 快取資料表
7.8.1 資料快取等級
7.8.2 建立不同快取等級的Shark 資料表
7.8.3 指定資料表快取策略
7.8.4 使用Tachyon
7.9 常見問題分析
7.9.1 OutOfMemory 異常
7.9.2 資料處理傳輸量低
7.9.3 Shark 查詢比Hive 慢
7.10 小結

Chapter 08   SQL 程式擴充
8.1 程式擴充平行執行模式
8.2 Evaluator 和ObjectInspector
8.3 自訂函數擴充
8.3.1 自訂函數擴充分類
8.3.2 CLI 中的使用者自訂函數擴充相關指令
8.3.3 使用者自訂函數（UDF）
8.3.4 通用使用者自訂函數（Generic UDF）
8.3.5 使用者自訂匯總函數（UDAF）
8.3.6 通用使用者自訂匯總函數（Generic UDAF）
8.3.7 通用使用者自訂表函數（Generic UDTF）
8.4 自訂資料存取格式
8.4.1 SerDe
8.4.2 StorageHandler
8.5 小結

Chapter 09   Spark SQL
9.1 Spark SQL 邏輯架構
9.1.1 Catalyst 功能邊界
9.1.2 SQL 解析階段
9.1.3 邏輯計畫中繼資料綁定和語義分析階段
9.1.4 邏輯計畫最佳化階段
9.1.5 實體計畫產生階段
9.1.6 Shark 和Spark SQL 比較
9.2 Catalyst 上下文（Context）
9.2.1 SQLContext
9.2.2 HiveContext
9.3 SQL DSL API
9.3.1 資料來源管理
9.3.2 SchemaRDD
9.3.3 Row API
9.3.4 資料類型
9.3.5 DSL API 舉例
9.3.6 運算式計算
9.3.7 Parquet 列式儲存檔案
9.3.8 程式示範
9.4 Java API
9.5 Python API
9.6 Spark SQL CLI
9.7 Thrift 服務
9.8 小結

Chapter10   Spark Streaming 串流資料處理架構
10.1 快速入門
10.2 Spark Streaming 基本概念
10.2.1 連結和初始化
10.2.2 時間和視窗概念
10.2.3 DStream 原理
10.2.4 DStream 輸入來源
10.2.5 DStream 操作
10.2.6 DStream 持久化
10.3 效能最佳化
10.3.1 執行時間最佳化
10.3.2 記憶體使用最佳化
10.4 容錯處理
10.4.1 工作節點故障
10.4.2 驅動節點故障
10.5 DStream 作業的產生和排程
10.5.1 作業產生
10.5.2 作業排程
10.5.3 Streaming 作業與Spark 作業之間的關係
10.6 DStream 與RDD 關係
10.7 資料接收原理
10.8 自訂資料登錄源
10.9 自訂監控介面（StreamingListener）
10.10 Spark Streaming 案例分析
10.11 小結

Chapter 11   GraphX 計算架構
11.1 圖型平行計算
11.1.1 資料平行與圖型平行計算
11.1.2 圖型平行計算架構簡介
11.1.3 GraphX 簡介
11.2 GraphX 模型設計
11.2.1 資料模型
11.2.2 圖型計算介面
11.3 GraphX 模型實現
11.3.1 圖的分散式儲存
11.3.2 圖操作執行策略
11.3.3 圖操作執行最佳化
11.3.4 序列化和反序列化
11.3.5 GraphX 內建演算法函數庫
11.4 GraphX 應用
11.4.1 Pregel 模型
11.4.2 N 維鄰接關係計算
11.5 小結

Chapter 12   Tachyon 儲存系統
12.1 設計原理
12.1.1 高效的記憶體讀寫
12.1.2 無備份的可用性實現——Lineage
12.2 架構設計
12.2.1 主節點
12.2.2 工作節點
12.2.3 用戶端
12.2.4 讀寫入工作流程
12.3 Tachyon 的部署
12.3.1 單機部署
12.3.2 分散式部署
12.3.3 Tachyon 的設定
12.4 Tachyon 應用
12.4.1 Shark 原始表（RawTable）
12.4.2 Spark 的堆積外RDD
12.4.3 Tachyon 使用者介面（API）
12.5 相關專案討論
12.6 小結

推薦序

　　2009 年的時候，Netflix 公司舉辦了一個叫作Netflix Prize 的推薦演算法比賽。這個比賽匿名公佈了Netflix 五十萬使用者對近兩萬部電影的一億個評分資料，希望參賽者能夠開發出更好的推薦演算法，以加強推薦系統的品質。這個比賽的獎金有一百萬美金，看似很多，但和一個更好的推薦演算法為Netflix 帶來的效益相比，實則九牛一毛。

　　豐厚的獎金和Netflix 提供的真實資料吸引不少的參賽者，其中也包含了來自加州大學柏克萊分校（UC Berkeley）的博士生Lester Mackey。Lester 師從機器學習領域泰斗Michael Irwin Jordan，在一個AMPLab 的大數據實驗室裡進行博士研究。AMPLab 和大多數學術界實驗室不同的地方，在於實驗室內由多名教授和他們帶領的學生一起合作，研究人員來自不同的領域，包含機器學習、資料庫、電腦網路、分散式系統等。當時，要想加強演算法研究反覆運算的效率，需要利用多台機器的分散式建模。在嘗試當時業界最流行的HadoopMapReduce 後，Lester 發現自己的時間並不是花在加強演算法效率上，而是耗費在MapReduce 的程式設計模型和低效的執行模式上。因此，他向實驗室另一名進行分散式系統研究的學生Matei Zaharia 求助。

　　當時年紀輕輕的Matei 在業界已經小有名望。他在雅虎和Facebook 實習期間做了很多Hadoop 早期的奠基工作，包含現今Hadoop 系統內應用最廣的fair scheduler 排程演算法。在和Lester 的腦力激盪中，Matei 歸納了Hadoop MR的不足，開始設計第一個版本的Spark。這個版本完全是為Lester 訂製，只有幾百行的程式，卻讓Lester 可以高效率地進行分散式機器學習建模。

　　Lester 所在的The Ensemble 團隊最後和BellKor's Pragmatic Chaos 設計了在效率上並列第一的演算法，可惜因為晚20 分鐘送出，與一百萬美金獎金失之交臂。5 年後，Lester 和Matei 都變成了學術界和業界傑出的人物。Lester 成為史丹佛大學電腦系的教授，帶領學生攻克一個又一個機器學習和統計的難題。Matei 成為麻省理工電腦系的教授，也是Databricks 公司的CTO。

　　2009 年之後的4 年裡，AMPLab 以Spark 為基礎展開很多不同的學術研究專案，其中包含了Shark 和GraphX，還有Spark Streaming、MLlib 等。4 年裡隨著Hadoop 的發展，Spark 也逐漸從一個純學術研究專案發展到開始有業界敢嚐鮮的使用者。

　　2013 年， 包含Matei 和我在內的Spark 核心人員共同創立Databricks 公司，立志於加強Spark 的速度發展。過去兩年，Spark 的發展超越了我們所有人的想像。一年半以前Spark 還是一個連監控介面都不存在的系統，很難放進生產線部署。而一年半後的今天，它已經變成整個大數據生態圈和Apache Software Foundation 內最活躍的專案，活躍程度遠遠超出了曾經只能望其項背的Hadoop。

　　很多高科技和網際網路公司也都有了Spark 的生產作業，不少使用者直接減少在Hadoop MapReduce 上的投資，把新的專案都傳輸到Spark 上。

　　今天正好是Databricks 公司成立一年半，也是Spark 1.2 版本第一個release candidate 發佈的日期。Spark 的高速發展導致中文資訊的脫節。這本書深入淺出地介紹Spark 和Spark 上多個重要計算架構，希望它的問世可以更進一步地普及Spark，增進Spark 社區的發展。