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

推薦下小編的大資料學習群；251956502，不管你是小白還是大牛，小編我都歡迎，不定期分享乾貨，歡迎初學和進階中的小夥伴。

每天晚上20:00都會開直播給大家分享大資料知識和路線方法，群裡會不定期更新最新的教程和學習方法，大家都是學習大資料的，或是轉行，或是大學生，還有工作中想提升自己能力的，如果你是正在學習大資料的小夥伴可以加入學習。最後祝所有程式設計師都能夠走上人生巔峰，讓程式碼將夢想照進現實，非常適合新手學習，有不懂的問題可以隨時問我，工作不忙的時候希望可以給大家解惑。

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

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

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

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

傳統上的叢集運算

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

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

大資料技術架構的起源

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

一切源自於 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 建立索引進行搜尋。 如同大部份的開發專案，一開始 Cutting 與 Cafarella 只專注於將功能寫出來，之後再最佳化。 但是當欲建檔的網頁是全世界的時候，無法處理大資料的技術瓶頸就出現了。 當年他們能建檔的網頁的上限是一億 (100M)，而且只能在一臺三千美金的機器上面跑。 如何處理大量的資料變成當時他們最迫切需要解決得問題。

HDFS (Hadoop Distributed File System) 誕生

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

不需要傳統資料庫的 schema (鷹架)

一旦資料寫入系統就不需要擔心資料遺失 (durable)

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

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

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

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

Map Reduce

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

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 的開發，包括 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 。

大資料工程師的核心技能指標

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

分析及設計高延展性 (highly scalable) 程式

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

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

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

能驗證資料正確性

設計 regression test system. 每次資料系統更新都能檢驗前後處理的差別

可以撰寫工具檢驗大量的資料正確性

從一開始規劃系統就讓它具有高度的可驗證性，以及嚴格的驗證它

將資料工程自動化的能力

可以處理資料相依性問題

自動處理錯誤的策略

要能 revert & reprocess

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

系統維護

透過 log & stacktrace 來 debug

知道基本的系統平臺管理。JobTracker, HDFS 等指令要熟悉

瞭解各種 Map Reduce 引數，可以調校效能引數

實事求是的精神

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

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

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

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

大資料工程技能樹該如何點？

初級

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

學習架構

建立開發環境

寫最簡易的 SQL operation

寫中階的 SQL operation

寫 SQL 難以辦到的功能

淺論資料工程架構 (dedup, join, aggregation)

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

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

高階

學習目標：學會許多更深入的技能，並且能規劃高階的資料系統設計。

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

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