自我在美國開始開發 hadoop 相關程式已經一年多
最近開始想把一些所學整理並回饋給台灣的版眾
鑑於我當data engineer的時間並沒有很長，如果有缺漏的還請高手指點
先簡介一下我現在待的公司 OpenX
我們是一家線上廣告公司，每天平均流量有TB等級
production data cluster 有三百台機器
storage data cluster 也有兩百五十台機器
目前我負責開發並維護production data cluster，以及擔任release engineer
不過我還很資淺，也只有接觸到整個hadoop生態系當中的一小部分而已就是了
一般提到 Hadoop 時，都是指整套環繞著HDFS, Hadoop map reduce API相關的生態系
諸如高階語言pig, hive, NoSQL 如 hbase, log batch processing 的 flume 等
現在有些人還會將storm, kafka, spark等近親也包含進去
一開始接觸時，免不了會覺得眼花繚亂
在實務上，基本上上面一個技術就需要一個人來維護
如果你的team沒有很大，那請慎選自己的stack
這些技術擅長的面向都不同
HDFS 是大資料儲存的架構，通常會需要一個SRE(site reliability engineer)
來維護HDFS還有整個叢集的健康。這個工程師最好有叢集管理及架設的經驗
而且會設定及管理監視的程式如nagios
hadoop map reduce API 這是我們這組主要在開發的部分。
如果hadoop是你資料處理的一個環節，而最後產生的報表是要收費的
那我會建議這部分的邏輯還是用hadoop原生的API來開發比較有效率也比較能
保證正確性。我在前東家還有OpenX都是這麼做的
pig 這是一個相對高階的語言。一般來說是用來做ETL(extract, transform, load)
如果你處理的資料對效能要求不高，或是對系統的穩定性要求不高
那這在資料批次處理上是相當方便的選擇
hive 相對起pig, hive是更著重於query的語言。它有實做JDBC的溝通介面
所以許多資料呈現軟體現在都有跟Hive連結來提取資料。
hbase 以儲存大數據為設計精神的NoSQL
我們公司並沒有納入hbase，因為這適合數據儲存及query
卻不適合data processing (process and update rocords)
Oozie, azkaban, 這兩個是hadoop生態系中處理排程的程式
flume, 將 log 批次處理並存入 HDFS
Mahout hadoop中的machine learning framework。前東家和現在公司都沒用
我並非data scientist所以不熟:P
Storm, kafka, 這兩個是stream processing的程式（雖然略微不同）
spark, tek, 這兩個是in memory map-reduce，但都需要大量的記憶體才會有好效果
以上的介紹都是非常簡略，而且網路上可以查的到的結果
很多人做了一些功課後，就會想截長補短
又能處理實時資料，又能儲存大數據，還要能即時query(impala, spark) etc.
還要有很好的穩定性且出錯時能自己修復等等...
這樣是行不通的，這不是堆積木
在選擇stack之前，要先了解自己的應用屬於哪種類型才行
以下是我經手或是透過認識的人所瞭解的應用類型
1. 資料批次處理，並透過產生的報表收費
2. 資料儲存
3. 透過機器學習來發展策略
4. 實時的資料處理
5. 透過資料收費，但尺度是中小規模
1. 是我在前東家及現在單位在處理的事情
這類型的資料處理，對於資料正確性的要求最高
每一行資料都是要拿來收費的，一個很小的誤差，也有可能造成收入或客戶信用的喪失
基本上，所有握有大數據的公司都一定會有這一塊業務
因為養伺服器還有撐起大數據流量的服務是很貴的
沒辦法讓business根據data來收費，怎麼可能讓business scale
很奇怪的是，那些宣傳大數據的人或書都忽略掉這最基礎的一塊...
處理這種要收費的資料，不太可能實時處理，多半都是批次
這樣才能夠在系統出問題時，能夠roll back或是暫停服務
前面也提過，我在前後公司都是用hadoop map-reduce API來開發
很多時候我們真的需要這種程度的掌控
之後的文章我應該會以如何設計map-reduce的演算法來完成一些複雜的計算為主
2. 資料儲存
資料批次處理完之後，我們會將原始資料壓縮歸檔
以利其他部門分析研究
這部分我們是將資料轉成hive能讀的資料型式
3. 機器學習及資料探勘
大數據被大規模宣傳的就是屬於這個範疇啦
不過，這部分的工程師不一定真的要會寫hadoop，很多時候是用hive把資料撈出來
然後再跑python來計算
除非公司特別有錢，不然一般資料儲存及探勘的硬體都會比production system差
就人力市場來說，屬於3的工程師遠比第一種好找的多
在我們公司內的比例大概是10:1 |||orz
4. 實時資料處理
這塊我就真的很不熟了。一般來說實時資料處理使用的data store必須要有比較高
的讀寫速度。而hadoop的核心模組全都是low latency的設計。
如果公司的數據是屬於中尺度，視business model可以選SQL or NoSQL
也有超強大的公司如twitter要在大數據尺度上也要玩實時
如果你公司名氣大且有錢可以聘請到夠多的強工程師，要這樣玩也可以...
5. 中小尺度的資料處理
我的前東家其實資料量是屬於中小尺度的
原本是用postgreSQL來搞定全部
但是有一些特定的ETL用SQL算真的太慢，還有一些大型join有了index還是不夠快
因此把這部分拆出來用hadoop來算
速度差別有多大呢？大約是從四個小時變成三十分鐘
我在前東家就發現很多東西不用map reduce寫根本沒辦法算
所以很早就棄hive/pig了
寫了這麼多關於java的反而很少，幾乎都是domain knowledge
我在大數據裡面接觸的也只有特定面向
這篇文章希望能拋磚引玉，吸引更多強者來分享經驗