大數據的下一步：用Spark玩轉活用(第2版)

前言

Chapter 01   Spark 系統概述
1.1 大數據處理架構
1.2 Spark 大數據處理架構
1.3 小結

Chapter 02   Spark RDD 及程式設計介面
2.1 Spark 程式"Hello World"
2.2 Spark RDD
2.3 建立操作
2.4 轉換操作
2.5 控制操作（control operation）
2.6 行動操作（action operation）
2.7 小結

Chapter 03   Spark 執行模式及原理
3.1 Spark 執行模式概述
3.2 Local 模式
3.3 Standalone 模式
3.4 Local cluster 模式
3.5 Mesos 模式
3.6 YARN standalone / YARN cluster 模式
3.7 YARN client 模式
3.8 各種模式的實現細節比較
3.9 Spark 1.0 版本之後的變化
3.10 小結

Chapter 04   Spark 排程管理原理
4.1 Spark 作業排程管理概述
4.2 Spark 排程相關基本概念
4.3 作業排程模組頂層邏輯概述
4.4 作業排程實際工作流程
4.5 工作集管理模組詳解
4.6 排程池和排程模式分析
4.7 其他排程相關內容
4.8 小結

Chapter 05   Spark 的儲存管理
5.1 儲存管理模組整體架構
5.2 RDD 持久化
5.3 Shuffle 資料持久化
5.4 廣播（Broadcast）變數持久化
5.5 小結

Chapter 06   Spark 監控管理
6.1 UI 管理
6.2 Metrics 管理
6.3 小結

Chapter 07   Shark 架構與安裝設定
7.1 Shark 架構淺析
7.2 Hive/Shark 各功能元件比較
7.3 Shark 安裝設定與使用
7.4 Shark SQL 命令列工具（CLI）
7.5 使用Shark Shell 指令
7.6 啟動SharkServer
7.7 Shark Server2 設定與啟動
7.8 快取資料表
7.9 常見問題分析
7.10 小結

Chapter 08   SQL 程式擴充
8.1 程式擴充平行執行模式
8.2 Evaluator 和ObjectInspector
8.3 自訂函數擴充
8.4 自訂資料存取格式
8.5 小結

Chapter 09   Spark SQL
9.1 Spark SQL 邏輯架構
9.2 Catalyst 上下文（Context）
9.3 SQL DSL API
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.3 效能最佳化
10.4 容錯處理
10.5 DStream 作業的產生和排程
10.6 DStream 與RDD 關係
10.7 資料接收原理
10.8 自訂資料登錄源
10.9 自訂監控介面（StreamingListener）
10.10 Spark Streaming 案例分析
10.11 小結

Chapter 11   GraphX 計算架構
11.1 圖型平行計算
11.2 GraphX 模型設計
11.3 GraphX 模型實現
11.4 GraphX 應用
11.5 小結

Chapter 12   Tachyon 儲存系統
12.1 設計原理
12.2 架構設計
12.3 Tachyon 的部署
12.4 Tachyon 應用
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 社區的發展。