這幾年來大數(shù)據非常的熱門，到處都有大數(shù)據分析的演講。 演講內容通常是宣傳各種大數(shù)據分析成功的案例。 但實際上大數(shù)據該怎么做呢？ 大部份的討論似乎都僅止于怎么搜集大量的數(shù)據， 然后用個工具（hadoop/spark）后就會馬上變出商機和錢來。

筆者是工程師而非技術或平臺傳教者，我想用務實一點的方式來看待大數(shù)據。 大數(shù)據技術最重要的核心在于如何設計可以高性能處理大量數(shù)據的程式 （highly scalable programs.）

目前大數(shù)據相關工作可以粗分幾類。有資料系統(tǒng)串接者， 設計大數(shù)據演算法實做的人，以及管理大型叢集 （cluster） 的工程師。 很多人對大數(shù)據工程師的理解還停留在資料系統(tǒng)串接者的程度， 以為只要將資料匯入某個神奇系統(tǒng)，就能將自己想要的結果生出來。 但實際上數(shù)據量變得很大時，我們往往需要自己客制化自己的資料系統(tǒng)，并且撰寫特殊的演算法處理之。 以***和美國業(yè)界而言，第二種工程師是最稀少也需求量最高的。 這本書的目的就是由淺入深的介紹如何成為此類型的工程師。

有些人可能會有點意外，為什么資料科學家不在其列？ 因為資料科學從一開始就是和大數(shù)據獨立的概念。 而且一般而言大多數(shù)資料工程師處理的數(shù)據量也偏小，使用的演算法也多是 O（N2）以上的復雜度。 閱讀本章之后，請不要再把「大數(shù)據分析」一詞掛在口中了。 只有非常少數(shù)能同時精通大數(shù)據演算法設計及資料科學的人，才有資格用到這個字。

不知道在學習大數(shù)據的讀者們有沒有想過，超級電腦的發(fā)明是1960年代的事， 為什么直到近年大數(shù)據才紅起來？任何科技及技術都有其歷史脈絡， 學習一點相關歷史會讓自己在追逐新科技時更清楚自己要解決的問題的定位在哪邊。

傳統(tǒng)上的叢集運算

大型叢集電腦設計其實從電腦誕生的年代就有了。 傳統(tǒng)上的計算主流偏向科學計算（例如氣候模擬、飛彈、流體力學）等 High Performance Computing。 這類型的演算通常用到大量的線性代數(shù)、大量的浮點數(shù)運算、但實際處理的資料多半不會太大。 事實上，在許多學術及軍事機構中，還是有大量的這種超級電腦在進行演算以輔助研究。 它們從傳統(tǒng)上就與新進的大數(shù)據佔有不同市場， 使用的語言也不同 （fortran還是目前最快的 high performance computing language）。

不過隨著網路科技的演進，我們有了一個新的大型叢集運算的需求。 我們每天在網路上的各種行為，都會被記錄下來：搜尋、逛頁面、買東西、逛facebook、看到的廣告等等。 將這些數(shù)據搜集起來并且拿來算錢，成了新的叢集運算新星。 處理這些數(shù)據時，和傳統(tǒng)的HPC非常不同。HPC的數(shù)據量一般不大，但需要大量的浮點數(shù)計算； 大數(shù)據技術則反之，數(shù)據量很大，但計算相較簡單。 與此相對的硬體設計也完全不同。HPC的硬體叫做blade，硬碟很小，但CPU、記憶體、主機板通通都是高檔貨； 大數(shù)據的硬體則通常要求每臺主機都要有很大的硬碟，使得很多資料不需要在網路中傳輸，可以在本機計算就在本機計算。

大數(shù)據技術架構的起源

以下內容節(jié)錄并翻譯自 The history of hadoop 。 原作者有跟最早的hadoop開發(fā)者 Doug Cutting 求證過細節(jié)，而且得到他的背書！

一切源自于 Doug Cutting 在 1997 年開始的搜尋引擎專案 Lucene 。 Lucene 在 2000 年開放原始碼，并在 2001 年變成 ASF （Apache Software Foundation）1 的專案。 直至今日，許多熱門的搜尋引擎實做 Apache Solr， Elastic search 的底層都還是使用 Lucene 。 不過在一開始的時候 Lucene 只能搜尋很少的東西，而且也只能在一臺機器上跑。

2001 年底， Doug Cutting 和 Mike Cafarell 將興趣轉向替網頁建立搜尋索引， 并開啟了一個新的專案名為 Apache Nutch 。 Nutch 是網路爬蟲，使用 Nutch 爬下整個世界的網站，再使用 Lucene 建立索引進行搜尋。 如同大部份的開發(fā)專案，一開始 Cutting 與 Cafarella 只專注于將功能寫出來，之后再最佳化。 但是當欲建檔的網頁是全世界的時候，無法處理大數(shù)據的技術瓶頸就出現(xiàn)了。 當年他們能建檔的網頁的上限是一億 （100M），而且只能在一臺三千美金的機器上面跑。 如何處理大量的數(shù)據變成當時他們最迫切需要解決得問題。

HDFS （Hadoop Distributed File System） 誕生

為了使 Nutch 能夠處理更多資料，Cutting 與 Cafarella 開始思考多臺機器的儲存方案。 這儲存方案必須要符合以下的需求：

不需要傳統(tǒng)資料庫的 schema （鷹架）

一旦資料寫入系統(tǒng)就不需要擔心資料遺失 （durable）

如果有硬體壞掉，系統(tǒng)會自動處理好（備份、轉移資料等）

自動平衡資料負載。不需要手動將資料從一臺伺服器搬到另一臺去。

他們花了幾個月試圖實做這些規(guī)格，不過就在 2003 年， Google 發(fā)表了一篇 Google File System paper 。 里面的描述恰恰好就符合他們要追求的檔案系統(tǒng)。 于是在 2004 年，他們就依據這篇 paper 實做出了 Nutch Distributed File System （NDFS.）

讀者可能會有疑問：為什么不去使用當時其他的分散式檔案系統(tǒng)呢？ 當時已經有許多超級電腦的儲存方案，為什麼不用這些方案呢？ 筆者目前找不出完整的原因（也許要訪問 Doug Cutting吧） 但現(xiàn)有的 HDFS 比其他分散式儲存系統(tǒng)便宜大約二十倍，而且性能更好。 而且傳統(tǒng)的Xen/NAS等分散式儲存系統(tǒng)還需要專門的硬體及機房， 如果當時他們使用這樣的方案也許我們就不會看到大數(shù)據業(yè)蓬勃發(fā)展了。

Map Reduce

有了分散式儲存技術還不夠。 Cutting 等人當時苦思如何善用手上硬體來進行平行化計算。 盡管當年MPI等HPC平行計算技術已經成熟，但卻主要用于小量快速資料傳輸。 在2004年 Google 又發(fā)表了一篇 Map Reduce 的 paper 。 這個平行計算的抽象化非常的通用，從網頁的權重計算、字詞分析、到網路流量的分析等都可以通用。 本書會以這個概念為主軸介紹如何設計出一系列的演算方式來解決大數(shù)據的問題。

2005 年七月， Cutting 宣布 Nutch 改寫以 Map Reduce 作為其建檔的計算引擎。

Hadoop 出生

2006 年六月， Cutting 將 NDFS 及 Map Reduce 從 Nutch 專案中抽出來， 放在 Lucene 的子專案下，并重新命名為 Hadoop。

大約在同時間， Yahoo！ 以 Eric Baldeschwieler 為首的團隊正在努力研究下一世代的 Yahoo 搜尋技術。 他們相中 Cutting 的 GFS/MapReduce 實做， 并且大膽的決定要以這個 prototype 在未來取代他們當年的搜尋引擎實做。 就在那年 Baldeschwieler 將 Cutting 納入團隊。

2007 及 2008 年有許多公司前仆后繼的加入 hadoop 的開發(fā)，包括 Twitter， Facebook， LinkedIn 等等。而在 2008 年時 Hadoop 從 Lucene 專案中切開來，成為自己獨立的專案。許多衍伸的專案也在 2008 年時加入 Hadoop 家族，如 Yahoo！ pig， Facebook Hive， ZooKeeper， HBase 等等。

之后重要的 Hadoop 編年史：

2008 Cloudera 成立

2009 Amazon elastic MR 誕生

2010 Hortonworks 從 Yahoo！ 拆分出來成為新公司

2010 UC Berkeley open sourced Spark

2012 YARN 誕生

2012 Yahoo！ 宣布他們的叢集達到 42000 nodes，為當時最大的 Hadoop 叢集

2014 Spark 成為 ASF top level project。并開始獲得大量的關注

Side note：

其實 Hadoop 其中一個很有價值的應用是做 BI （Business Intelligence）。 但它的設計架構一開始并不是針對BI起家的，而是更貼近于搜尋引擎建立索引這樣的工作。 在 BI 中最關鍵的事是處理時間序列的資料，資料清理，以及資料整合 （data join）。 以筆者個公司來說，就必須客制非常多的架構來讓它變得更適合 BI。 盡管 pig/hive 等上層工具一部分目的也是使其更容易操作 BI 。

大數(shù)據工程師的核心技能指標

看完前一章大數(shù)據的歷史，讀者有沒有對產業(yè)的發(fā)展脈絡稍微有概念一點了呢？ 筆者目前在美國工作，就筆者觀察其實現(xiàn)在***美國都還有非常多大數(shù)據工程師的就業(yè)機會。 即使大數(shù)據這名詞稍微退燒（或許是太多招搖撞騙的人吧）， 但隨著軟體業(yè)近年來負載量愈來愈大，對后端處理資料的需求其實也是變得愈來愈高。 無奈資料工程這技能學校不會教，因為沒有學術價值。 在業(yè)界內除非進入資料團隊，不然也不會接觸到。 最糟的是，各家公司內部的資料團隊素質也良莠不齊，要學到好的資料工程技術真的只能靠運氣。 筆者的公司算得上是資料工程做得還不錯的，以下為筆者認定的大數(shù)據核心技能

分析及設計高延展性 （highly scalable） 程式

能寫出常見的 data operation 如 join， de-duplicate， group-by

能處理 data skew （資料過度集中在少數(shù)的 key）的問題

知道如何選擇 map output key， 以及 secondary key sort 的排序設計

能驗證資料正確性

設計 regression test system. 每次資料系統(tǒng)更新都能檢驗前后處理的差別

可以撰寫工具檢驗大量的數(shù)據正確性

從一開始規(guī)劃系統(tǒng)就讓它具有高度的可驗證性，以及嚴格的驗證它

將資料工程自動化的能力

可以處理資料相依性問題

自動處理錯誤的策略

要能 revert & reprocess

使用 control table 去控制及追蹤不同工做的 state

系統(tǒng)維護

透過 log & stacktrace 來 debug

知道基本的系統(tǒng)平臺管理。JobTracker， HDFS 等指令要熟悉

了解各種 Map Reduce 參數(shù)，可以調校效能參數(shù)

實事求是的精神

做資料工程或分析，最忌諱的就是騙自己。永遠不要用猜的，要用資料來驗證自己的想法是否正確。

各種資料系統(tǒng)設計都有隱藏的代價，不要對這些代價視而不見。

挖掘問題先于尋找解決方案。只有完全了解自己的需求后，才能在多種方案中選擇最適合自己的一個。

以上的技能集中在如何成為大數(shù)據工程師。資料科學的訓練不記入其中，因為光是達到以上的技能就已經很花時間啦。 當這些技能都練得相當不錯時，再跨足資料科學，其實也不太難。 不過通常是分工合作更簡單一些，因為學資料科學的人遠比資料工程多很多。

大數(shù)據工程技能樹該如何點？

初級

學習目標：能獨立開發(fā) highly scalable 的程式及演算法。更高階的資料系統(tǒng)設計不包含在內。

學習架構

建立開發(fā)環(huán)境

寫最簡易的 SQL operation

寫中階的 SQL operation

寫 SQL 難以辦到的功能

淺論資料工程架構 （dedup， join， aggregation）

開始有能力分析資料演算法的復雜度，以及了解 data skew 的處理策略

能透過 log & stack trace 找出自己程式哪里寫錯

高級

學習目標：學會許多更深入的技能，并且能規(guī)劃高階的資料系統(tǒng)設計。

serialization & data collection strategy

End to end trace data design

control table & automation design

lower level API （inputformat， outputformat， etc.）

advanced java tricks

analyze performance factor

MR network cost calculation， advanced MapReduce

初級的學習大概一兩個月內可以精通。筆者當年就是花差不多的時間無師自通的。高級目標筆者則是經由跟比較年長的工程師學習而來，比較難評估學習時間。