任何一個時代或者模式的興起，都離不開與之相關的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年中，他們通過無人偵察機收集了大量阿富汗那邊地理相關的視頻資料，之后通過分析這些海量視頻資料，來對極具危害性的恐怖組織團伙進行定位。
#p#副標題#e#
大數據的特點
大數據，不僅有“大”這個特點，除此之外，它還有很多其他特色，在這方面，業界各個廠商都有自己獨特的見解，但是總體而言，我覺得可以用“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等。
在特點和挑戰方面，主要是挖掘的算法復雜，并且計算涉及的數據量和計算量都很大，還有，常用數據挖掘算法庫以單線程為主。
如何從“小”做起？
由于我平時與中小企業的接觸非常頻繁，雖然技術方案與實際的問題相關，很難在一篇文章當中詳盡地道來。除了上面那個基本處理流程之外，我下面會將一些基本的從“小”做起的思路給大家闡述一下：
- 認識自己的不足，主要是在技術、人力和財力等方面是不僅無法與Google和Amazon這樣國外巨頭比肩，而且與國內三大互聯網BAT（百度、阿里巴巴和騰訊）也是無法比肩的，所以需要深刻認識；
-
明確分析自己的需求，下面是幾個常見的需求選項：
> 數據類型，是結構化，半結構化，還是非結構化為主；
> 數據大小，內部數據級別是TB級別、PB級別或者PB以上級別；
> 讀寫量級，比如每小時寫入的數據達到GB級別，或者每天寫入達到TB級別等；
> 讀寫比例，是寫為主，還是以讀為主；
> 并發數，大致的每秒并發數；
> 一致性，只接受強一致性，或者可以接受最終一致性和弱一致性；
> 延遲度，最高能容忍的延遲度是多少，是10毫秒，100毫秒，還是可以1秒；
> 分析的復雜度，需不需要引入較復雜的數據挖掘算法等。 - 要靈活使用現有的工具，首先，推薦使用一些開源或者是可以承受的商業軟件，雖然個人并不排斥自建，但是一定要有具體的商業價值，并且最好是在現有工具上的畫龍點睛，而不是從頭開始構建；其次，工具方面應與具體的場景相關，在不同的場景要使用不同的工具。
- 盡量不要走平臺思路，應以具體的應用和場景為主，因為建一個平臺有很多附加的成本和設計，比如，Amazon的云平臺是通過至少五年時間構建而成。特別是項目的初期，不建議走平臺這個方向，而是應腳踏實地以具體的商業場景為主。
- 找準切入點，最好是找到一個技術難度小，并且有一定的商業價值的場景來做大數據技術落地的試點，并不斷地進行測試和迭代來驗證，而不是一味求復雜，求大，這樣比較容易說服企業管理層來進行長期地投入和支持；
最后，想和大家說一下，“羅馬不是一天建成的”，無論是Google的用于大數據處理的基礎設施，還是我們國內淘寶的“云梯”都是一步步通過不斷積累和實踐而成，所以我們這些中小企業應該貫徹“大處著眼、小處著手”的方針來持續地驗證和推進。還有，我們人云科技將于今年上半年發布用于海量結構化數據處理的YunTable，由于其性能指標非常出色，并且已經有正式運行的大型集群，所以請各位朋友敬請期待。
轉載鏈接：http://os.51cto.com/art/201205/339746.htm
