不知從什麼時候開始，大資料這個詞開始流行，似乎現在不談點大資料，都不好意思說自己是搞IT的。當然這是玩笑之談。但是我們確實生活在這樣一個時代，特別是對於網際網路公司而言，資料就是生命，如果不能從龐大繁雜的資料中發現價值將會失去很多機會。


大資料是如何在網際網路公司中發揮它強大的能力，似乎沒有多少人談，這裡我就說下自己的一點看法和感受。
 
1，原始資料
何謂原始資料？直接由使用者行為或狀態而獲取到的資料，就是我們的原始資料.
一般來說原始資料數量都非常巨大，而且比較雜亂且無模式（schema-less），資料一般是以日誌檔案等方式儲存，比如使用者每次點選訪問。
原始資料另外一個來源就是儲存在傳統關係型資料庫中的使用者資料，這些資料都是規整而易於使用，並且和上面相反，它們是有模式的（schema）。但是這裡就引出了一個問題，這兩種截然不同的資料如何結合起來？
初看，我們有兩種思路可選。
第一，我們將無模式的資料通過程式進行某種處理，得到某種固定格式的資料，然後匯出到傳統的關係型資料庫，然後再利用強大的SQL等方式進行資料分析處理。

第二，我們將關係型資料庫的內容匯出，然後利用hadoop之類的工具進行分析。
這兩種方法都有一定侷限性，第一種方法在資料量較小的時候可以用用，一旦資料量上去了，關係型資料庫將不堪重負。第二種方法實施起來難度非常大，因為資料庫本身每時每刻都是在變化的，換句話說，每次匯出的資料，實際上是匯出那一刻資料庫的一個快照。為了實現持續的資料分析，就必須按時間在hadoop叢集上維護大量的快照。

因此我們將兩種方案結合起來使用。首先日誌資料會經過一個簡單的初步處理，過濾掉無效資料，然後直接採集到hadoop叢集（淘寶現在用的採集工具是timetunnel，已在taocode上開源），並利用hadoop的hive工具，對它們建立表結構以便可用用hiveql進行處理。
對於關係型資料庫的資料，則利用一套特別的機制（如現在阿里雲梯的資料生命週期），實現儲存空間上的最大優化，避免叢集的快遞膨脹。

這樣一來，我們所有的資料都在hadoop叢集上了。


2，資料分析
有了原始資料，我們就可以開始玩它們了。
hadoop現在擁有很多高階的分析平臺如hive。關於hive的使用，本文就不再贅述了。
說點別的，hive可以很方便的結合指令碼語言，如我前兩篇博文介紹的python，它們都是基於hadoop streaming技術。
當然，hive現在還是存在很多缺點和不足，例如很多sql的特性就不支援，除錯也不好除錯，出錯了也令人一頭霧水。相信隨著hive版本的不斷更新，會越來越完善。 

這一節的重點不在於如何去分析資料，而是分析出來的結果如何使用。如果僅僅是給運營人員或者產品經理看看，那也便罷，簡單的把結果拷貝到excel表格再稍修飾美化一下即可。

但是如果要實現自動化的資料分析並和產品無縫整合，那就是另外一個問題了。
一般來說，線上系統不能也不應該直接依賴hadoop這種離線資料處理工具。所以在hadoop叢集上跑出來的資料，得再次匯入到關係型資料庫比如mysql；為了實現這種功能一般可以自行開發相應的程式，將結果以檔案方式傳送到執行該程式的伺服器上，然後在伺服器上讀取並解析檔案，利用JDBC寫入資料庫。淘寶自己也有一套工具即dataX，可直接在hadoop叢集和資料庫之間進行相互匯出匯入。

3，資料整合
僅僅將資料放在資料庫是遠遠不夠的；因為業務的發展是不斷變化的，如果初期資料整合方面做得不夠，一旦業務出現變化，整個資料系統都必須一起變動，開發週期會相應變得很長，可能在傳統企業中這不是大問題，但是對於網際網路公司，這是大忌。如果不能在變幻莫測的網際網路浪潮中抓住機會，那麼離被淘汰也不遠了。

要做到資料系統高度可擴性是很困難的，它跟企業本身的業務特點緊密相關。但是有幾個基本原則是不變的。
A：原始資料的處理儘量分而治之；例如不要用一個非常龐大的Hive程式+N多個複雜指令碼+各種自定義UDF來實現。將其分成一個個的子任務 ，每個任務僅處理很小的一部分，然後最後再作一個資料合併。

B：存入資料庫的資料是半成品。資料加工的次數越多，它本身的可擴充套件性越低，所以hadoop叢集跑出來的資料，不應該是直接展示給使用者的，這中間至少還需要一個二次處理，雖然看起來流程多了一個步驟，但是對於系統而言是大有好處。一方面增強了系統擴充套件性，另一方面可以利用傳統資料庫強大的資料分析能力（SQL能做的事情，我就不用說了，特別是主流資料庫都擁有標準SQL之外的很多額外功能，更是如虎添翼）。
 
–EOF