前言
近年來，“大數據”已然成為IT界如火如荼的詞，與“雲計算” 並駕齊驅，成為帶動IT行業發展的兩架高速列車。尤其在物聯網快速發展的時代，數據已經被稱之為新的資源，或者“金子”，支撐物聯網發展的基石。
那么如何把“死”的數據，變成真正有效的“資源”，最後再變成活生生的“金子”，便成為近年來IT界人士思考的問題。所以，一時之間，各種大數據處理技術如井噴一般湧現出來。Hadoop, Spark, Storm, Dremel/Drill等大數據解決方案爭先恐後的展現出來，需要說明的是，這裡所有的方案不是一種技術，而是數種，甚至數十種技術的組合，就拿Hadoop來說，Hadoop只是帶頭大哥，後面的關鍵的小弟還有：MapReduce, HDFS, Hive, Hbase, Pig, ZooKeeper等等，大有“大仙過海，各顯神通”的氣勢和場面。
第一部分，本書橫向總結性闡述了各種大數據處理技術，重點從緣起緣落、設計思想、構架原理等角度剖析了各種技術，分析了各個技術的優缺點和適用場景。本書並不涉及軟體的安裝等，因為如何安裝和使用，在網路上一搜一大堆，著實沒有必要浪費讀者的時間和金錢。在這部分中，第一篇講述了Hadoop技術陣營，第二篇，講述了Spark新起之秀，第三篇講述了其他大數據處理技術，如Storm, Dremel/Drill等。在第二部分中，本書闡述了大數據場景下的日誌分析技術。在大數據時代，日誌分析方案也呈現出了遍地開花的景象。如果將大數據處理系統比作一個可能得病的人，日誌分析就是負責看病的醫生，要想讓大數據處理健康平穩，日誌分析和監控非常重要。本書重點闡述了日誌處理技術中的最如日中天的方案：ELK。最後部分展望了大數據處理技術的發展趨勢，怎奈大數據處理技術發展太快，數據量也將會越來越大，技術的革新也將在所難免。
作為大數據研發人員，時刻保持學習新技術，方能立於技術 。
作者簡介
何金池 IBM高級軟體工程師，主要從事高性能計算和大數據領域研發工作，熟悉目前大數據處理領域的各項熱門技術，擅長於大數據環境下的日誌分析和處理，具有多年的一線軟體研發測試經驗。
目錄
0“瘋狂”的大數據 1
0.1大數據時代 1
0.2數據就是“金庫” 3
0.3讓大數據“活”起來 4
第1篇Hadoop軍營
1 Hadoop一石激起千層浪 7
1.1Hadoop誕生——不僅僅是玩具 7
1.2Hadoop發展——各路英雄集結 8
1.3Hadoop和它的小夥伴們 10
1.4Hadoop套用場景 12
1.5小結 13
2 MapReduce奠定基石 14
2.1MapReduce設計思想 14
2.2MapReduce運行機制 19
2.2.1MapReduce的組成 19
2.2.2MapReduce作業運行流程 20
2.2.3JobTracker解剖 26
2.2.4TaskTracker解剖 34
2.2.5失敗場景分析 42
2.3MapReduce實例分析 43
2.3.1運行WordCount程式 44
2.3.2WordCount源碼分析 45
2.4小結 48
3 分散式檔案系統 49
3.1群雄並起的DFS 49
3.2HDFS檔案系統 51
3.2.1HDFS 設計與架構 52
3.2.2HDFS 操作與API 56
3.2.3HDFS的優點及適用場景 60
3.2.4HDFS的缺點及改進策略 61
3.3小結 62
4 Hadoop體系的“四劍客” 63
4.1數據倉庫工具Hive 63
4.1.1Hive緣起何處 63
4.1.2Hive和資料庫的區別 65
4.1.3Hive設計思想與架構 66
4.1.4適用場景 74
4.2大數據倉庫HBase 74
4.2.1HBase因何而生 74
4.2.2HBase的設計思想和架構 77
4.2.3HBase最佳化技巧 84
4.2.4HBase和Hive的區別 86
4.3Pig程式語言 87
4.3.1Pig的緣由 87
4.3.2Pig的基本架構 88
4.3.3Pig與Hive的對比 90
4.3.4Pig的執行模式 90
4.3.5Pig Latin語言及其套用 91
4.4協管員ZooKeeper 96
4.4.1ZooKeeper是什麼 96
4.4.2ZooKeeper的作用 97
4.4.3ZooKeeper的架構 98
4.4.4ZooKeeper的數據模型 100
4.4.5ZooKeeper的常用接口及操作 102
4.4.6ZooKeeper的套用場景分析 105
4.5小結 108
5 Hadoop資源管理與調度 110
5.1Hadoop調度機制 110
5.1.1FIFO 111
5.1.2計算能力調度器 111
5.1.3公平調度器 113
5.2Hadoop YARN資源調度 114
5.2.1YARN產生的背景 114
5.2.2Hadoop YARN的架構 116
5.2.3YARN的運作流程 118
5.3Apache Mesos資源調度 120
5.3.1Apache Mesos的起因 120
5.3.2Apache Mesos的架構 121
5.3.3基於Mesos的Hadoop 123
5.4Mesos與YARN對比 127
5.5小結 128
6 Hadoop集群管理之道 129
6.1Hadoop 集群管理與維護 129
6.1.1Hadoop集群管理 129
6.1.2Hadoop集群維護 131
6.2Hadoop 集群調優 132
6.2.1Linux檔案系統調優 132
6.2.2Hadoop通用參數調整 133
6.2.3HDFS相關配置 133
6.2.4MapReduce相關配置 134
6.2.5Map任務相關配置 136
6.2.6HBase搭建重要的HDFS參數 137
6.3Hadoop 集群監控 137
6.3.1Apache Ambari監控 137
6.3.2Ganglia監控Hadoop 138
6.4小結 138
第2篇Spark星火燎原
7 Spark寶刀出鞘 141
7.1Spark的歷史淵源 141
7.1.1Spark的誕生 141
7.1.2Spark的發展 142
7.2Spark和Hadoop MapReduce對比 143
7.3Spark的適用場景 145
7.4Spark的硬體配置 146
7.5Spark架構 147
7.5.1Spark生態架構 147
7.5.2Spark運行架構 149
7.6小結 151
8 Spark核心RDD 153
8.1RDD簡介 153
8.1.1什麼是RDD 153
8.1.2為什麼需要RDD 154
8.1.3RDD本體的設計 154
8.1.4RDD與分散式共享記憶體 155
8.2RDD的存儲級別 155
8.3RDD依賴與容錯 157
8.3.1RDD依賴關係 157
8.3.2RDD容錯機制 160
8.4RDD操作與接口 161
8.4.1RDD Transformation操作與接口 162
8.4.2RDD Action操作與接口 164
8.5RDD編程示例 165
8.6小結 166
9 Spark運行模式和流程 167
9.1Spark運行模式 167
9.1.1Spark的運行模式列表 167
9.1.2Local模式 168
9.1.3Standalone模式 169
9.1.4Spark on Mesos模式 171
9.1.5Spark on YARN 模式 173
9.1.6Spark on EGO 模式 175
9.2Spark作業流程 177
9.2.1YARN-Client模式的作業流程 178
9.2.2YARN-Cluster模式的作業流程 179
9.3小結 181
10 Shark和Spark SQL 183
10.1從Shark到Spark SQL 183
10.1.1Shark的撤退是進攻 183
10.1.2Spark SQL接力 185
10.1.3Spark SQL與普通SQL的區別 186
10.2Spark SQL套用架構 187
10.3Spark SQL之DataFrame 188
10.3.1什麼是DataFrame 188
10.3.2DataFrame的創建 188
10.3.3DataFrame的使用 190
10.4Spark SQL運行過程分析 190
10.5小結 192
11 Spark Streaming流數據處理新貴 193
11.1Spark Streaming是什麼 193
11.2Spark Streaming的架構 194
11.3Spark Streaming的操作 195
11.3.1Spark Streaming的Transformation操作 196
11.3.2Spark Streaming的Window操作 197
11.3.3Spark Streaming的Output操作 198
11.4Spark Streaming性能調優 198
11.5小結 200
12 Spark GraphX圖計算系統 201
12.1圖計算系統 201
12.1.1圖存儲模式 202
12.1.2圖計算模式 203
12.2Spark GraphX的框架 206
12.3Spark GraphX的存儲模式 207
12.4Spark GraphX的圖運算符 208
12.5小結 211
13 Spark Cluster管理 212
13.1Spark Cluster部署 212
13.2Spark Cluster管理與監控 213
13.2.1記憶體最佳化機制 213
13.2.2Spark日誌系統 213
13.3Spark 高可用性 215
13.4小結 216
第3篇其他大數據處理技術
14 專為流數據而生的Storm 218
14.1Storm起因 218
14.2Storm的架構與組件 220
14.3Storm的設計思想 222
14.4Storm與Spark的區別 224
14.5Storm的適用場景 225
14.6Storm的套用 226
14.7小結 227
15 Dremel和Drill 228
15.1Dremel和Drill的歷史背景 228
15.2Dremel的原理與套用 230
15.3Drill的架構與流程 232
15.4Dremel和Drill的適用場景與套用 234
15.5小結 234
第4篇大數據下的日誌分析系統
16 日誌分析解決方案 236
16.1百花齊放的日誌處理技術 236
16.2日誌處理方案ELK 238
16.2.1ELK的三大金剛 238
16.2.2ELK的架構 240
16.2.3ELK的組網形式 242
16.3Logstash日誌收集解析 245
16.3.1Input Plugins及套用示例 246
16.3.2Filter Plugins及套用示例 248
16.3.3Output Plugins及套用示例 249
16.4ElasticSearch存儲與搜尋 250
16.4.1ElasticSearch的主要概念 251
16.4.2ElasticSearch Rest API 252
16.5Kibana展示 253
16.6小結 255
17 ELK集群部署與套用 256
17.1ELK集群部署與最佳化 256
17.1.1ELK HA集群部署 256
17.1.2ElasticSearch最佳化 257
17.2如何開發自己的外掛程式 259
17.3ELK在大數據運維系統中的套用 261
17.4ELK實戰套用 262
17.4.1ELK監控Spark集群 262
17.4.2ELK監控系統資源狀態 263
17.4.3ELK輔助日誌管理和故障排查 263
17.5小結 264
第5篇數據分析技術前景展望
18 大數據處理的思考與展望 266
18.1大數據時代的思考 266
18.2大數據處理技術的發展趨勢 267
18.3小結 270
樣章
7.1.1 Spark的誕生
任何一個強大事物的出現都有一個精彩有趣的歷史背景，Spark也不例外。Spark最初的思想火花來自於加州大學伯克利分校（UC Berkeley）的一個研究團隊。你可能會說，“哇，老外在大數據處理方面著實很有創新力”。但是僅有創新力還是不夠的，必須要有創新的動機，才能造就出今天Spark 全球開花的局面。
說到Spark的創新動機，這裡有個很滑稽的故事。話說Netfix (一個線上影片租賃公司)為了提高服務質量，更好的為用戶推薦適合用戶口味的電影，搞了一個Netflix大獎賽，這個大獎賽從2006年10月份開始，Netflix公開了五十萬用戶，針對兩萬部電影的大約1億個匿名影片評級，數據集僅包含了影片名稱、評價星級和評級日期，沒有任何文本評價的內容，大獎賽目的在於預測Netflix的客戶分別喜歡什麼影片，要求把預測的準確度提高10%以上，來為用戶推薦最適合的影片。最為主要的是大獎賽的獎金為一百萬美金！（如果你是富二代，可能會不屑一顧，但是你如果參考諾貝爾獎的獎金數額，這個獎金還是相當優厚的！）。
可謂重賞之下必有勇夫！一時間竟在IT掀起來一層不小的波浪，迎來了無數程式設計師躍躍欲試，如何處理這“1億個匿名影片評級”的大數據，擺在了參賽者的面前。 UC Berkeley研究團隊中，有名叫Lester Mackey的博士生，一不小心就看到了這個懸賞，馬上擼起袖子，也打算試上一把。Lester當時在AMPLab的大數據實驗室進行博士研究，有著很好的資源和大數據處理的能力。看到這個需求，Lester馬上想到了當時業界已經很流行的Hadoop MapReduce。搞了一段時間，Lester發現很多精力用到了MapReduce的編程模型和低效的執行模式上，而不是花費在如何提高效率上。這樣下去，等到把預測的準確度提高百分之十，黃花菜都涼了，100萬獎金就會失之交臂！痛徹思悟數天，依然無果，便去找實驗室的另一位專門研究分散式系統的哥們Matei Zaharia請教。說起這個Matei，那在當時業界已經小有名氣了，他是Hadoop的重要貢獻者之一。一聽到Lester給他講這個事情，兩人便一拍即合，一起分析了Hadoop MapReduce在此套用上的乏力之處，吸其精華，改其不足，定製化的輸出了區區幾百行代碼，滿足了Lester可以高效率的分散式建模的願望。 這，就是Spark最初的版本！
看到這裡，讀者可能會想，拿著這么高大上的“寶劍”，去參加Netfix武林大會，必贏無疑吧？但是我要遺憾的告訴你，Lester所在的團隊，並沒有抱得大獎歸。雖然提高效率上和另一團隊的方案相差無幾，並列第一，可是Lester所在的團隊提交晚了20分鐘，終和大獎擦肩而過。不過相比今天Spark給大數據處理方面的貢獻，區區百萬美金，實乃冰山一角。追溯此二人的發展，此後都成為了學術界的傑出人物，Lester成為了史丹福大學的教授，Matei則成為了麻省理工的教授，也聯合創建了DatatBricks公司，此公司正在主導並致力於Spark的高速發展。
推薦
此書從廣度上，涵蓋了目前幾乎所有的大數據處理熱門技術，實為大數據行業的入門人員和從業人員的一頓盛宴，推薦！
--IBM產品經理張帥
目前大數據處理領域，比較火爆的技術有：Hadoop、Spark和Storm等，到底哪個技術較強？誰會替代誰？此書對這些技術進行了橫向對比，分析了各個技術的套用場景。對大數據處理初學者和大數據行業套用人員有很好的指導作用。
--Yeahmobi產品構架師朱傑
大數據處理技術日新月異，從最初的Hadoop到Spark,在此同時，為了滿足不同的場景，各大IT公司均陸續的提出了不同的大數據處理方案，目前已有數十種大數據處理技術湧現在我們面前。為此，我們只有不斷的學習新技術才能跟上時代的步伐。本書對深入了解大數據處理技術有很好的參考意義。
--華為大數據技術構架師尹青
十年前，有人曾說過，"21世紀什麼最貴？"——"人才"，深以為然。只是在十年後的今天，大數據的價值越來越明顯，堪比石油和黃金。為應對海量數據處理帶來的巨大挑戰,全球計算機精英們開發出眾多有針對性的先進技術。本書全面介紹了目前大數據處理領域的熱門技術的精髓和適應的場景，實用性很強。
--中興高達產品經理，技術總監尹尚國
本書內容豐富，結構嚴謹，語言詼諧，為讀者精彩呈現了大數據處理處理各大熱門技術的設計思想，套用場景和實例，可幫助大數據初學者快速上手，可幫助大數據研發人員擴展知識，是大數據處理行業不可多得的書籍。
--知名IT領軍人物歐立奇
