漫談大數據之中篇
前言
上次作者分享了大數據的前序，本次和下次將繼續為讀者分享大數據方面的拙見。從大數據的定義、發展歷程，到大數據VS小數據、大數據通用技術，最后從安全行業大數據的角度，漫談大數據相關概念及其在應用實踐中的一些思考，同時分享大數據在流量分析和日志的簡單實踐，期望能給讀者帶來對大數據一個更好的認知和應用。
上次前篇漫談大數據的定義、發展歷程，中篇我們將從大數據VS小數據、以及大數據通用技術簡要的介紹對大數據方面的理解。
小數據 VS 大數據
先舉個簡單例子吧，比如學生成績管理系統，在不同的情況下這個系統的架構是完全不同的。下面分三種情形討論：
(1)如果僅僅做一個班級的學生成績管理，那么最簡單的方法是采用一個EXCEL，然后利用一些EXCEL分析的函數等對成績進行管理、排序、查找和保存等操作。打開EXCEL，把成績錄入即OK，多簡單高效，一目了然，用EXCEL也可以導出很多數據分析的報表，一個EXCEL的中高手絕對能搞定這簡單的需求。
(2)如果是管理一個學校的成績呢，那如果還用EXCEL來管理，估計需要很多的EXCEL統計信息。不僅需要的量多，那如果兩個班級進行橫向比較怎么辦?如果按照某科目進行縱向排名怎么辦?顯然用EXCEL不是最好的解決方案了，就算EXCEL的高手也望塵莫及，那就需要我們學習IT剛剛畢業的小菜鳥四兩撥千斤，一個簡單的數據庫就搞定了。猶記得當年在那個小機房，用著純平的顯示器，拿著上機卡，運用SQL SERVER 2000和Visual C++6.0，靈活應用成績錄入、查詢和保存等按鈕的學生成績管理系統，一切搞定!
(3)當然，往往事情沒那么簡單，永遠也沒有一切搞定的時候，如果用當前互聯網的思維，我們要管理的不僅僅是一個學校的成績，我們要管理整個省各大高校的成績，甚至全國各大高校的成績，如果思維再發散一些，我們要做個系統，不僅僅是管理學生的成績，我們還想要通過學生平時的作業情況，上課考勤情況，以及學生在社交網絡上的所有相關信息以及所喜歡的電影，興趣愛好等去綜合分析預測這個學生本學期的成績，那怎么辦?這里，我們不僅僅簡單的存結構化的成績信息了，數據的來源更加多源，需要分析的數據更加多元化，并且數據量和數據組織形式讓SQL SERVER和ORACLE無法存儲處理和查詢。比如由于數據量太大用ORACLE查詢十分鐘都無法返回結果。那么，我們需要大數據技術，采取新的數據架構體系來管理分析這些數據，這也是何謂大數據中所談到的。
這就是所謂的小數據和大數據。小數據(量)，采用傳統的關系型數據庫處理起來更為簡單高效，比如情形1和情形2。大數據(量)，采用傳統的數據庫無法處理，那只能用大數據的技術架構去分析處理，比如情形3。那是否可以用大數據的技術處理小數據呢，當然可以。但是，不是很好的解決方案。首先，系統越復雜，所要處理的問題越多，不僅僅實現上困難，而且在維護也舉步維艱。其次，采用大數據的技術不會帶來更好更高效的結果，相反，小數據采用傳統的關系型數據庫，無論技術還是實現方式更為成熟，數據查詢分析的速度更為高效。打蚊子用高射炮浪費資源不說，而且不一定好使，還不如一個打蚊拍來的更為合適。
當然，上面大數據與小數據的討論主要體現在數據量和處理方式方面，更核心的大數據和小數據有很多內容。《大數據時代》作者維克托•舍恩伯格提出了大數據三原則：要全體不要抽樣、要效率不要精確、要相關不要因果。從中可以看出，大數據時代的核心特征是相關性，其特點是全量、多元、數據價值密度低等。而小數據應該指采用調查方法獲得的抽樣數據或者是結構化的海量數據，通常采用傳統的統計分析方法，往往依托數理統計的大數定律，描述抽樣理論下樣本最終服從中心極限定理的正態分布理論，強調描述性統計學和推斷統計學。兩者之間的對比可以簡略的概括為：大數據重預測、發現、相關、全體、感知;對應的小數據重解釋、實證、因果、抽樣、精確。從這也可以看出，大數據與小數據沒有孰好孰壞，在做好大數據的基礎上，能夠提取具有鮮明特征，具有高密度價值的小數據，從個體角度量身定做，進行更加精準的個性化推薦和預測，也是極好的。
大數據包含哪些技術?
大數據包含哪些技術呢?引入楊義先老師的最新力作《安全簡史》里面的例子，咱們先看看大數據產業和垃圾處理回收產業。
通俗的說，大數據產業，無論從工作原理、原料結構，還是從利潤率等方面來看，能夠與大數據產業相比擬的，也許只有垃圾處理和廢品回收!
廢品收購和垃圾收集，算是“數據收集”;將廢品和垃圾送往集中處理工場，算是“數據集成”;將廢品和垃圾初步分類，算是“數據規約”;將廢品和垃圾適當清潔和整理，算是“數據清理”;將破沙發拆成木、鐵、皮等原料，算是“數據變換”;認真分析如何將這些原料賣個好價值，算是“數據挖掘”;不斷總結經驗，選擇并固定上下游賣家和買家，算是“模式評估”;把這些技巧整理成口訣，算是“知識表示”!
再看原料結構。與大數據的異構特性一樣，生活垃圾、工作垃圾、建筑垃圾、可回收垃圾和不可回收垃圾等，無論從外形、質地，還是從內涵等方面來看，也都是完全不同的。與大數據一樣，垃圾的數量也很多，產生的速度也很快，處理起來也很困難。
最后來看利潤率。確實有人曾在紐約路邊的垃圾袋里，一分錢不花就撿到了價值百萬美元的，墨西哥著名畫家魯菲諾·塔馬約的代表作《三人行》。而從廢品中掏出寶貝，更是家常便飯。即使不考慮這些“天上掉下來的餡餅”，就算將收購的易拉罐轉手賣掉，也勝過鋁礦利潤率;將舊家具拆成木材和皮料，其利潤率也遠遠高于木材商和皮貨商;總之，只要垃圾專家們愿意認真分撿，那么，他們的利潤率可以超過任何相關行業。與垃圾專家一樣，大數據專家也能將數據(廢品)中挖掘出的旅客出行規律賣給航空公司，將某群體的消費習慣賣給百貨商店，將網絡輿情賣給相關的需求方等等，總之，大數據專家完全可以“一菜多吃”，反復賣錢，不斷“冶金”，而且一次更比一次賺錢，時間越久，價值越大。
言歸正傳，和傳統數據處理類似，大數據技術主要包括：數據采集、數據傳輸、數據存儲、數據查詢、數據分析和數據可視化。只是，由于數據量以及數據的多源異構，每一個都是一個非常復雜的系統，比如說從一個位置向另外一個位置進一步傳輸數據的數據是比較簡單的，但對大量數據就是非常復雜的問題了，這些都需要非常先進的技術才能夠解決。比如怎么保證海量數據的傳輸速度?怎么保證海量數據的不丟失?怎么保證不同的模型所選取數據全集中所需要的子集?怎么保證數據產生源產生的海量數據毫無壓力的全部存儲到磁盤或者文件系統?這些都是大數據技術中需要解決的問題。那么問題來了，當前大數據包含哪些技術，每種技術有哪些相應的解決方案?
這個問題的回答就沒有那么容易了，一兩句話也討論不清楚。借用QCon 2016(QCon是由InfoQ主辦的全球頂級技術盛會)分享的內容，這里以偏蓋全大概介紹一下。
對數據的管理和查詢分析大概包括這些步驟，數據的傳輸，數據的處理，數據的存儲和數據的查詢，每個過程包括不同的組件去實現各自的功能。
(1)數據傳輸
在數據傳輸領域可以說通用的標準式的組件有Kafka(由Apache軟件基金會開發的一個開源流處理平臺)。目前我們做大數據安全分析平臺的數據傳輸也是kafka。它提供了資源的分區，把生產數據和消費數據直接分開，現在這個架構是根據分布式邏輯來進行的，你可以從分布式邏輯上來收集數據，這是一個非常好的描述數據的一個方式。
此外，MQ(Message Queue消息隊列，用于上下游傳遞消息)也是提取數據的系統，它和Kafka不完全一樣，這兩個架構有些不同，不同的架構，不同的結構可以產生不同范圍，不同規模的表現性能，以提升不同的操作性能。
(2)數據處理
數據處理又分為離線處理、在線處理、流式處理。這里僅簡單的對比一下基于文件系統、基于內存和流式處理三種方式。
如圖所示，第一種是類似于MapReduce的基于Hadoop的批處理技術，他主要通過磁盤和網絡移動數據，每次數據處理之后的結果存入磁盤。這種處理方式有很大的局限性，因為要磁盤讀取，并通過網絡傳輸，處理速度就相對來慢，比較適合于離線的批處理。
第二種方式是在最近幾年當中非常流行的Spark的工作方式就是考慮你的處理過程，將它想象成一個過程或者一個舞臺，Spark做的就是非常有效地利用內存，每一個計算過程都會輸出一個結果，Spark會把這些結果做一個統計，這種工作的方法是迭代式的，而且是非常高效的迭代式。Spark會把所有的數據都進行統一的整理，而且Spark比Hadoop的API更加有優勢，同時Spark的MLIB集成了大部分機器學習的算法，迭代式的內存處理也非常適合算法的多次迭代求解。所以在過去幾年當中，Spark幾乎慢慢地變成了批處理的標配。
第三種方式是以Storm、Spark Streaming為主的流式處理框架。Hadoop的高吞吐，海量數據處理的能力使得人們可以方便地處理海量數據。但是，Hadoop不擅長實時計算，因為它天然就是為批處理而生的。舉個搜索場景中的例子，當一個賣家發布了一條寶貝信息時，他希望的當然是這個寶貝馬上就可以被賣家搜索出來、點擊、購買啦，相反，如果這個寶貝要等到第二天或者更久才可以被搜出來，估計這個大哥就要罵娘了。這是因為后臺系統做的是每天一次的全量處理，而且大多是在夜深人靜之時做的，那么你今天白天做的事情當然要明天才能反映出來啦。而Storm令持續不斷的流計算變得容易，彌補了Hadoop批處理所不能滿足的實時要求。Storm經常用于在實時分析、在線機器學習、持續計算、分布式遠程調用和ETL(Extract-Transform-Load，用來描述將數據從來源端經過抽取(Extract)、交互轉換(Transform)、加載(Load)至目的端的過程。)等領域。
(3)數據存儲
數據存儲這里簡單介紹基于Hadoop的技術擴展和封裝，圍繞Hadoop衍生出相關的大數據技術，應對傳統關系型數據庫較難處理的數據和場景，例如針對非結構化數據的存儲和計算等，充分利用Hadoop開源的優勢，伴隨相關技術的不斷進步，其應用場景也將逐步擴大，目前最為典型的應用場景就是通過擴展和封裝Hadoop來實現對互聯網大數據存儲、分析的支撐。這里面有幾十種NoSQL技術，也在進一步的細分。對于非結構、半結構化數據處理、復雜的ETL流程、復雜的數據挖掘和計算模型，Hadoop平臺更擅長。
(4)數據查詢
SQL on Hadoop：很多SQL on Hadoop都支持SQL查詢的功能，SQL可以幫助你非常便捷得到想得到的數據。但是缺點是處理速度非常慢，因為中間涉及到一些過程要從HDFS提取數據，處理數據，然后再放到存儲器當中。這樣就會非常慢，如果需要快速反應的話，這種小的延遲期的操作還需要進一步的提升。所以我們就需要進一步提高優化存儲。
Key/Value Stores：另一種加速查詢速度的方法就是要把資料庫進行優化，這樣就能夠打造一種非常快速的查詢的架構。它可以支持非常快速的查找，也可以進行快速的寫入，我們有很多時間序列的數據庫都有鍵值存儲。
Column stores：你可以存儲并且掃描你的數據，然后把這些數據進行列存儲，根據查詢的關鍵字，電腦可以快速查詢各個列，這樣的話你就可以在不同的列當中創造不同的關鍵字，以及指標。這是性能查詢方面非常大的進步。
當然，這里說的僅僅是帶入大家簡單的了解大數據處理的四項(大數據傳輸、處理、存儲、查詢)技術的基本概念，目的是讓大家對大數據技術不再那么陌生，但是這些如開始所說僅僅是一些基礎的需要，是一個以偏概全的概念，其中包含很多的開源框架去實現你的訴求，包含很多其他的問題需要去解決，比如：大數據的集群是怎么管理的?多源異構的數據接入進來用什么數據接入引擎，怎么保證多源異構的數據進行數據標準化的存儲，以便進一步的數據融合?大數據處理中的任務怎么調度?大數據平臺對外如何快速的進行可視化分析和研究?大數據平臺的體系安全性怎么保證，不僅包括數據的安全，還包括平臺的安全…….太多的問題，而且每個問題其實也可以作為一個課題或者一個方向進行深入的研究。
一個實用性能優異的大數據平臺需要在實踐中慢慢完善，迭代開發而成，并且要結合具體的業務場景建立相應的場景大數據解決方案，搭建適合自己的大數據分析平臺，后續我們將從流量分析和日志分析上進行具體舉例說明，敬請期待下周的終篇。
【本文為51CTO專欄作者“中國保密協會科學技術分會”原創稿件，轉載請聯系原作者】
