本文是最新的拙作，希望能大家能提點意見^_^

任何一個時代或者模式的興起，都離不開與之相關的Killer App，比如，C/S時代的SAP ERP，網際網路 1.0 時代的門戶，以及網際網路 2.0時代的搜尋和SNS等，那麼在當今雲端計算這個時代有那些Killer App呢？當然首當其衝的肯定是以VMware 和Amazon EC2為代表的虛擬化和相關IaaS服務，除此之外，新近崛起的大資料絕對也是雲端計算的Killer App之一，並且不僅類似百度、阿里以及騰訊這樣的網際網路巨頭有相關的應用需求，而且根據我個人平時與客戶接觸，發現有很多普通中小企業，特別是中型的網際網路和物聯網企業，在這方面的場景也有很多。本文將首先給大家介紹一下在我眼中的大資料，以及大資料的意義和特點，再給大家聊聊大資料的常見處理流程，之後將會和大家分享一下我是如何幫助一些中小企業實施大資料相關的解決方案，也就是大資料如何從“小”做起。

什麼是大資料？

過去計算機產生的資料，較簡單，基本上都是一筆筆事務，總量雖大，但是都是整體增長幅度都還是可控的，比如傳統的金融企業，經常使用幾臺大型機就管理其所有的業務資料，而最近幾年，由於以平板、智慧手機和感測器為代表的智慧裝置越來越多，同時這些裝置的生成的資料更是遠遠地超過我們的想象。據美國著名諮詢公司IDC的統計，全球數字資訊在未來幾年將呈現驚人增長，預計到2020年總量將是現在的44倍。據另外一份資料顯示，全球 90% 的資料都是在過去兩年中生成的，並且每年以50%的速度進行增長，每天，遍佈世界各個角落的感測器、移動裝置、線上交易和社交網路產生上PB級別的資料；每個月，全球網友釋出了 10多 億條 Twitter 資訊和300多 億條 Facebook 資訊。那麼這些大資料的存在有什麼價值和意義呢？

大資料的意義

我個人和一些朋友一直覺得大資料就好比一口油井，因為裡面蘊含著非常豐富的價值，如果企業能有效利用其內部儲存的海量資料，那麼將會改善其自身的產品和服務，從而提升客戶和受眾的體驗，從而在大資料時代獲取競爭優勢，並且隨著本身分析和挖掘技術不斷地提升，可以在之前的基礎上提供新的決策模式，從而支援管理者進行快速和精確地決策，這樣能夠超越對手，搶佔市場先機，獨領風騷。

下面通過幾個行業來和大家舉例講解一下大資料有那些意義和作用？

網際網路企業

我們有一些客戶，他們主要是做網路輿情或者網路廣告，他們明天都會處理和收集TB級別日誌或者網頁，結構化和非結構化都有，他們就是通過分析這些資料來給其客戶提供價值，比如分析一下一個男性護膚品廣告是在世界盃期間投放好，還是在亞洲盃那段時間播出好？還有，在電子商務方面，國外eBay的分析平臺每天處理的資料量高達100PB，超過了納斯達克交易所每天的資料處理量。為了準確分析使用者的購物行為，eBay定義了超過500種類型的資料，對顧客的行為進行跟蹤分析，並且通過這些分析促進eBay自身的業務創新和利潤增長。

智慧電網

我們有一個合作伙伴，他們是做智慧電網相關的解決方案。對那些電網而言，如果無法準確預估實際電力的使用情況，將會使電網要求電廠發出過量的電力，雖然這些過量電力可以通過某種模式進行儲存，但是大量的電力浪費已不可避免。而通過他們智慧電網的解決方案，每隔一刻鐘會採集一個省幾千萬使用者的用電資料，之後他們會根據這些資料來精確分析使用者的用電模型，最後通過這個用電模型來優化電力生產，從而有效地減少電力資源的浪費。

車聯網

在車聯網方面，我們也有一個客戶，他們在一個城市有幾十萬臺基於Android的終端，而這些終端會每隔一段時間會發送具體位置的GPS訊息給後端的資料叢集，接著這些叢集會分析一下這些海量的GPS資訊，分析出那些路段在什麼時候比較堵，之後將這些非常有價值的資訊不斷地推送給客戶，從而幫助使用者減少在路上所消耗的時間。

醫療行業

在這個方面，大資料的用例有很多。首先，通過分析大量的病例資訊，將有效地幫助醫生治病；其次，假設在一個病人身體的多個節點加入探針裝置，而且每個探針每天會採集GB級別關於人體細胞和血液執行狀態的資料，之後計算叢集可以根據這些資料來來進行分析，這樣能更精確地判斷病因，從而讓醫生對病人進行更具針對性地治療。

機器學習

在這方面，最出名的例子莫過於最近很火的Siri，它後臺有一個龐大的HBase叢集來對類似語言這樣的文字資料進行分析和管理，從而使Siri變成一位越來越老練的個人助手，為iPhone 4S的使用者提供了日期提醒、天氣預報和飯店建議等服務。除此之外，還有IBM的Watson，它通過一個基於Hadoop UIMA框架的叢集來挖掘海量的文字資訊來實現一定程度的人工智慧，並在美國著名知識問答節目Jeopardy中戰勝多位出色的人類選手。

國家安全

這方面最出名的例子，莫過於美國的聯邦情報局（CIA）。在過去10年中，他們通過無人偵察機收集了大量阿富汗那邊地理相關的視訊資料，之後通過分析這些海量視訊資料，來對極具危害性的恐怖組織團伙進行定位。

大資料的特點

大資料，不僅有“大”這個特點，除此之外，它還有很多其他特色，在這方面，業界各個廠商都有自己獨特的見解，但是總體而言，我覺得可以用“4V+1C”來概括，“4V+1C分別代表了Variety（多樣化）、Volume（海量）、Velocity（快速）、Vitality（靈活）以及Complexity（複雜）這五個單詞。

Variety（多樣化）

大資料一般包括以事務為代表的結構化資料、以網頁為代表的半結構化資料和以視訊和語音資訊為代表的非結構化等多類資料，並且它們處理和分析方式區別很大。

Volume（海量）

通過各種智慧裝置產生了大量的資料，PB級別可謂是常態，我接觸的一些客戶每天量都在幾十GB，幾百GB左右，我估計國內大型網際網路企業的每天資料量已經接近TB級別。

Velocity（快速）

要求快速處理，因為有些資料存在時效性，比如電商的資料，假如今天資料的分析結果要等到明天才能得到，那麼將會使電商很難做類似補貨這樣的決策，從而導致這些資料失去了分析的意義。

Vitality（靈活）

因為在網際網路時代，和以往相比，企業的業務需求更新的頻率加快了很多，那麼相關大資料的分析和處理模型必須快速地適應。

Complexity（複雜）

雖然傳統的BI已經很複雜了，但是由於前面4個V的存在，使得針對大資料的處理和分析更艱鉅，並且過去那套基於關係型資料庫的BI開始有點不合時宜了，同時也需要根據不同的業務場景，採取不同處理方式和工具。

前面已經跟大家講了處理大資料的必要性和特點，那麼接著將談到如何處理大資料，特別是常見的流程。具體的大資料處理方法其實有很多，但是根據長時間的實踐，我總結了一個基本的大資料處理流程（圖1），並且這個流程應該能夠對大家理順大資料的處理有所幫助。

圖1. 大資料的常見處理流程

整個處理流程可以概括為四步，分別是採集、匯入和預處理、統計和分析以及挖掘

採集

利用多個的資料庫來接收發自客戶端（Web、App或者感測器形式等）的資料，並且使用者可以通過這些資料庫來進行簡單的查詢和處理工作，比如，電商會使用傳統的關係型資料庫MySQL和Oracle等來儲存每一筆事務資料，除此之外，Redis和MongoDB這樣的NoSQL資料庫也常用於資料的採集。

在採集部分，主要特點和挑戰方面是併發數高，因為同時有可能會有成千上萬的使用者來進行訪問和操作，比如著名用於購買火車票的12306站點和淘寶，它們併發的訪問量在峰值時達到上百萬，所以需要在採集端部署大量資料庫才能支撐，並且如何在這些資料庫之間進行負載均衡和分片的確是需要深入地思考和設計。

匯入/預處理

雖然有采集端本身會有很多資料庫，但是如果要對這些海量資料進行有效地分析，還是應該將這些來自前端的資料匯入到一個集中的大型分散式資料庫或者分散式儲存叢集，並且可以在匯入基礎上做一些簡單的清洗和預處理工作，也有一些使用者會在匯入時候使用來自Twitter的Storm來對資料進行流式計算，來滿足部分業務的實時計算需求。

在特點和挑戰方面，主要是匯入資料量大，每秒匯入量經常達到百兆，甚至GB級別。

統計/分析

統計與分析主要利用分散式資料庫或者分散式計算叢集來對儲存於其內的海量資料進行普通的分析和分類彙總等，以滿足大多數常見的分析需求，在這方面，一些實時性需求會用到EMC 的GreenPlum、Oracle的Exadata以及基於MySQL的列式儲存Infobright等，而一些批處理或者基於半結構化的需求可以使用Hadoop。

統計與分析這部分，主要特點和挑戰方面是分析涉及的資料量大，其對系統資源，特別是I/O會有極大地佔用。

挖掘

與前面統計和分析不同的是，資料探勘一般沒有什麼預先設定好的主題，主要是在現有資料上面進行基於各種演算法的計算，從而起到預測（Predict）的效果，這樣實現一些高級別資料分析的需求，比較典型演算法有用於聚類的K-Means、用於統計學習的SVM和用於分類的Naive Bayes，主要使用的工具有Hadoop的Mahout等。

在特點和挑戰方面，主要是挖掘的演算法複雜，並且計算涉及的資料量和計算量都很大，還有，常用資料探勘演算法庫以單執行緒為主。

如何從“小”做起？

由於我平時與中小企業的接觸非常頻繁，雖然技術方案與實際的問題相關，很難在一篇文章當中詳盡地道來。除了上面那個基本處理流程之外，我下面會將一些基本的從“小”做起的思路給大家闡述一下：

1. 認識自己的不足，主要是在技術、人力和財力等方面是不僅無法與Google和Amazon這樣國外巨頭比肩，而且與國內三大網際網路BAT（百度、阿里巴巴和騰訊）也是無法比肩的，所以需要深刻認識；
2. 明確分析自己的需求，下面是幾個常見的需求選項：
   1. 資料型別，是結構化，半結構化，還是非結構化為主；
   2. 資料大小，內部資料級別是TB級別、PB級別或者PB以上級別；
   3. 讀寫量級，比如每小時寫入的資料達到GB級別，或者每天寫入達到TB級別等；
   4. 讀寫比例，是寫為主，還是以讀為主；
   5. 併發數，大致的每秒併發數；
   6. 一致性，只接受強一致性，或者可以接受最終一致性和弱一致性；
   7. 延遲度，最高能容忍的延遲度是多少，是10毫秒，100毫秒，還是可以1秒
   8. 分析的複雜度，需不需要引入較複雜的資料探勘演算法等。
3. 要靈活使用現有的工具，首先，推薦使用一些開源或者是可以承受的商業軟體，雖然個人並不排斥自建，但是一定要有具體的商業價值，並且最好是在現有工具上的畫龍點睛，而不是從頭開始構建；其次，工具方面應與具體的場景相關，在不同的場景要使用不同的工具。
4. 儘量不要走平臺思路，應以具體的應用和場景為主，因為建一個平臺有很多附加的成本和設計，比如，Amazon的雲平臺是通過至少五年時間構建而成。特別是專案的初期，不建議走平臺這個方向，而是應腳踏實地以具體的商業場景為主。
5. 找準切入點，最好是找到一個技術難度小，並且有一定的商業價值的場景來做大資料技術落地的試點，並不斷地進行測試和迭代來驗證，而不是一味求複雜，求大，這樣比較容易說服企業管理層來進行長期地投入和支援；

最後，想和大家說一下，“羅馬不是一天建成的”，無論是Google的用於大資料處理的基礎設施，還是我們國內淘寶的“雲梯”都是一步步通過不斷積累和實踐而成，所以我們這些中小企業應該貫徹“大處著眼、小處著手”的方針來持續地驗證和推進。還有，我們人云科技將於今年上半年釋出用於海量結構化資料處理的YunTable，由於其效能指標非常出色，並且已經有正式執行的大型叢集，所以請各位朋友敬請期待。