大數(shù)據(jù)工程師是怎樣煉成的

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

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

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

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

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

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

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

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

大數(shù)據(jù)技術(shù)架構(gòu)的起源

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

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

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

HDFS （Hadoop Distributed File System） 誕生

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

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

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

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

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

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

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

Map Reduce

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

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

Hadoop 出生

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

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

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！ 宣布他們的叢集達(dá)到 42000 nodes，為當(dāng)時最大的 Hadoop 叢集

2014 Spark 成為 ASF top level project。并開始獲得大量的關(guān)注

Side note：

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

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

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

分析及設(shè)計高延展性 （highly scalable） 程式

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

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

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

能驗證資料正確性

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

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

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

將資料工程自動化的能力

可以處理資料相依性問題

自動處理錯誤的策略

要能 revert & reprocess

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

系統(tǒng)維護(hù)

透過 log & stacktrace 來 debug

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

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

實事求是的精神

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

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

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

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

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

初級

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

學(xué)習(xí)架構(gòu)

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

寫最簡易的 SQL operation

寫中階的 SQL operation

寫 SQL 難以辦到的功能

淺論資料工程架構(gòu) （dedup， join， aggregation）

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

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

高級

學(xué)習(xí)目標(biāo)：學(xué)會許多更深入的技能，并且能規(guī)劃高階的資料系統(tǒng)設(shè)計。

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

初級的學(xué)習(xí)大概一兩個月內(nèi)可以精通。筆者當(dāng)年就是花差不多的時間無師自通的。高級目標(biāo)筆者則是經(jīng)由跟比較年長的工程師學(xué)習(xí)而來，比較難評估學(xué)習(xí)時間。