大數據生態圈
A. 騰訊QQ生態圈福射出來的大數據有哪些
你的朋友圈，你朋友的朋友圈；分析出你的整體社交群。
與你聯系頻率最高的人群，最低的人群，你的人際關系。
從你的社交群和人際關系，分析出你的層次，社會階層，空間。
你的生活習慣、你QQ音樂、QQ視頻、QQ游戲，你喜歡聽什麼歌、看什麼電視電影分析你的文化素質。
玩什麼游戲；在什麼時間段玩、一次玩了多長時間，分析你的情商。以及你的生存狀態（不是所有人都有長時間在工作日工作時間玩游戲，除非你是職業玩家）
京東（騰訊控股）可以分析出的消費習慣與消費能力，你購買的商品也能反映你的生活品味生活水平。
京東白條、京東金融分析出你的資本、你的理財習慣、你的收入水平。
根據數據推出你直系親屬，如老婆、老公、父母等人的上述數據，再對數據進行綜合，你們全家人未來三年將有可能的消費清單就可以生成。某些快銷品和特殊商品時你的消費周期也能結合上面數據分析出你家庭情況，家庭成員結構。 分析出來你將來還需要購買什麼商品、預測你的未來消費、近期消費以及符合你消費能力的商品。有時也可以用於預防犯罪和惡性事件的發生。
B. 我是學Java的，想嘗試大數據和數據挖掘，該怎麼規劃學習
兩個工作內容聯系不大，你是學習java的，我就主要介紹數據挖掘吧
數據挖掘是提取數據、建立模型分析數據、得出結果後與需求部門進行溝通的一個職業。
舉個例子：銀行的事業部有很多潛在的貸款申請者，事業部向數據挖掘人員提出需求，希望能夠分析哪些申請者是優質放貸對象？
數據挖掘人員首先要充分理解事業部的需求，其次要從資料庫提取相關數據，提取數據的工作有些時候是由DBA來完成，好了，現在你得到了歷史數據，你的任務就是通過歷史數據來建立模型，分析具備什麼特徵的申請者是有能力還貸、不拖欠的，然後用建立好的模型來預測我們剛剛得到的新的一批申請者。
再具體一點：例如，我們通過歷史數據發現，年齡大於35歲，的男性，已婚，家庭人口大於3，收入在12000元以上的申請者是理想的放貸對象，那麼我們用這個標准來限定新的申請者。
當然我舉的例子，為了淺顯易懂，是非常簡單的示意例子，實際情況要復雜得多，會涉及到個人的貸款歷史、信用評估、自然屬性、社會屬性、資產評估等情況——就是說，數據挖掘人員是要通過資料庫中的海量數據，整理出哪些是有用數據，再用這些有用的數據來分析其它部門的問題，幫助他們解決問題，或者為公司的發展提供數據依據
數據挖掘的上升方向是：數據挖掘——產品層——決策層
java是屬於開發，比如開發軟體、介面、應用程序等，如果一個公司需要開發數據挖掘軟體，那麼則需要數據挖掘知識+java開發能力，只有在這種時候，才需要兩個都具備
但是一般自主開發數據挖掘軟體的公司很少，第一需要消耗大量人力物力，第二市場有很多現成的軟體，沒必要開發。
如果你想從事數據挖掘，你必須具備：
數據挖掘模型、演算法的數學知識以及一些數據分析軟體（SPSS、SAS、matlab、clementine）
一些資料庫相關的知識（oracle、mySQL）
了解市場、其它部門需求
當然這些都是一點一滴積累起來的，沒必要一蹴而就，特別是對市場、行業的了解以及對公司其它部門的需求的理解非常重要，這決定了你能否從基礎的分析人員上升到產品層、決策層，都是要在實際的工作中積累起來的
至於放棄java什麼的，我覺得真的不是放棄，因為你具備了java的基礎，一定能派上用場，比如技術型產品經理（face book的扎克伯格和騰訊的馬化騰都是技術型產品經理），這種產品經理能夠清晰的把握產品的開發過程，還有市場知識。總結起來就是沒有什麼東西會浪費掉，你學的所有的東西都將在工作中派上用場，只是你遇到的情況不夠多不夠復雜而已
C. 大數據爬蟲技術有什麼功能
1、爬蟲技術概述
網路爬蟲（Web crawler），是一種按照一定的規則，自動地抓取萬維網信息的程序或者腳本，它們被廣泛用於互聯網搜索引擎或其他類似網站，可以自動採集所有其能夠訪問到的頁面內容，以獲取或更新這些網站的內容和檢索方式。從功能上來講，爬蟲一般分為數據採集，處理，儲存三個部分。
傳統爬蟲從一個或若干初始網頁的URL開始，獲得初始網頁上的URL，在抓取網頁的過程中，不斷從當前頁面上抽取新的URL放入隊列,直到滿足系統的一定停止條件。聚焦爬蟲的工作流程較為復雜，需要根據一定的網頁分析演算法過濾與主題無關的鏈接，保留有用的鏈接並將其放入等待抓取的URL隊列。然後，它將根據一定的搜索策略從隊列中選擇下一步要抓取的網頁URL，並重復上述過程，直到達到系統的某一條件時停止。另外，所有被爬蟲抓取的網頁將會被系統存貯，進行一定的分析、過濾，並建立索引，以便之後的查詢和檢索；對於聚焦爬蟲來說，這一過程所得到的分析結果還可能對以後的抓取過程給出反饋和指導。
相對於通用網路爬蟲，聚焦爬蟲還需要解決三個主要問題：
(1) 對抓取目標的描述或定義；
(2) 對網頁或數據的分析與過濾；
(3) 對URL的搜索策略。
2、爬蟲原理
2.1 網路爬蟲原理
Web網路爬蟲系統的功能是下載網頁數據，為搜索引擎系統提供數據來源。很多大型的網路搜索引擎系統都被稱為基於 Web數據採集的搜索引擎系統，比如 Google、Bai。由此可見Web 網路爬蟲系統在搜索引擎中的重要性。網頁中除了包含供用戶閱讀的文字信息外，還包含一些超鏈接信息。Web網路爬蟲系統正是通過網頁中的超連接信息不斷獲得網路上的其它網頁。正是因為這種採集過程像一個爬蟲或者蜘蛛在網路上漫遊，所以它才被稱為網路爬蟲系統或者網路蜘蛛系統，在英文中稱為Spider或者Crawler。
2.2 網路爬蟲系統的工作原理
在網路爬蟲的系統框架中，主過程由控制器，解析器，資源庫三部分組成。控制器的主要工作是負責給多線程中的各個爬蟲線程分配工作任務。解析器的主要工作是下載網頁，進行頁面的處理，主要是將一些JS腳本標簽、CSS代碼內容、空格字元、HTML標簽等內容處理掉，爬蟲的基本工作是由解析器完成。資源庫是用來存放下載到的網頁資源，一般都採用大型的資料庫存儲，如Oracle資料庫，並對其建立索引。
控制器
控制器是網路爬蟲的**控制器，它主要是負責根據系統傳過來的URL鏈接，分配一線程，然後啟動線程調用爬蟲爬取網頁的過程。
解析器
解析器是負責網路爬蟲的主要部分，其負責的工作主要有：下載網頁的功能，對網頁的文本進行處理，如過濾功能，抽取特殊HTML標簽的功能，分析數據功能。
資源庫
主要是用來存儲網頁中下載下來的數據記錄的容器，並提供生成索引的目標源。中大型的資料庫產品有：Oracle、Sql Server等。
Web網路爬蟲系統一般會選擇一些比較重要的、出度(網頁中鏈出超鏈接數)較大的網站的URL作為種子URL集合。網路爬蟲系統以這些種子集合作為初始URL，開始數據的抓取。因為網頁中含有鏈接信息，通過已有網頁的 URL會得到一些新的 URL，可以把網頁之間的指向結構視為一個森林，每個種子URL對應的網頁是森林中的一棵樹的根節點。這樣，Web網路爬蟲系統就可以根據廣度優先演算法或者深度優先演算法遍歷所有的網頁。由於深度優先搜索演算法可能會使爬蟲系統陷入一個網站內部，不利於搜索比較靠近網站首頁的網頁信息，因此一般採用廣度優先搜索演算法採集網頁。Web網路爬蟲系統首先將種子URL放入下載隊列，然後簡單地從隊首取出一個URL下載其對應的網頁。得到網頁的內容將其存儲後，再經過解析網頁中的鏈接信息可以得到一些新的URL，將這些URL加入下載隊列。然後再取出一個URL，對其對應的網頁進行下載，然後再解析，如此反復進行，直到遍歷了整個網路或者滿足某種條件後才會停止下來。
網路爬蟲的基本工作流程如下：
1.首先選取一部分精心挑選的種子URL；
2.將這些URL放入待抓取URL隊列；
3.從待抓取URL隊列中取出待抓取在URL，解析DNS，並且得到主機的ip，並將URL對應的網頁下載下來，存儲進已下載網頁庫中。此外，將這些URL放進已抓取URL隊列；
4.分析已抓取URL隊列中的URL，分析其中的其他URL，並且將URL放入待抓取URL隊列，從而進入下一個循環。
2.3 抓取策略
在爬蟲系統中，待抓取URL隊列是很重要的一部分。待抓取URL隊列中的URL以什麼樣的順序排列也是一個很重要的問題，因為這涉及到先抓取那個頁面，後抓取哪個頁面。而決定這些URL排列順序的方法，叫做抓取策略。下面重點介紹幾種常見的抓取策略：
2.3.1 深度優先遍歷策略
深度優先遍歷策略是指網路爬蟲會從起始頁開始，一個鏈接一個鏈接跟蹤下去，處理完這條線路之後再轉入下一個起始頁，繼續跟蹤鏈接。我們以下面的圖為例：
遍歷的路徑：A-F-G E-H-I B C D
2.3.2 寬度優先遍歷策略
寬度優先遍歷策略的基本思路是，將新下載網頁中發現的鏈接直接**待抓取URL隊列的末尾。也就是指網路爬蟲會先抓取起始網頁中鏈接的所有網頁，然後再選擇其中的一個鏈接網頁，繼續抓取在此網頁中鏈接的所有網頁。還是以上面的圖為例：
遍歷路徑：A-B-C-D-E-F G H I
2.3.3 反向鏈接數策略
反向鏈接數是指一個網頁被其他網頁鏈接指向的數量。反向鏈接數表示的是一個網頁的內容受到其他人的推薦的程度。因此，很多時候搜索引擎的抓取系統會使用這個指標來評價網頁的重要程度，從而決定不同網頁的抓取先後順序。
在真實的網路環境中，由於廣告鏈接、作弊鏈接的存在，反向鏈接數不能完全等他我那個也的重要程度。因此，搜索引擎往往考慮一些可靠的反向鏈接數。
2.3.4 Partial PageRank策略
Partial PageRank演算法借鑒了PageRank演算法的思想：對於已經下載的網頁，連同待抓取URL隊列中的URL，形成網頁集合，計算每個頁面的PageRank值，計算完之後，將待抓取URL隊列中的URL按照PageRank值的大小排列，並按照該順序抓取頁面。
如果每次抓取一個頁面，就重新計算PageRank值，一種折中方案是：每抓取K個頁面後，重新計算一次PageRank值。但是這種情況還會有一個問題：對於已經下載下來的頁面中分析出的鏈接，也就是我們之前提到的未知網頁那一部分，暫時是沒有PageRank值的。為了解決這個問題，會給這些頁面一個臨時的PageRank值：將這個網頁所有入鏈傳遞進來的PageRank值進行匯總，這樣就形成了該未知頁面的PageRank值，從而參與排序。
2.3.5 OPIC策略策略
該演算法實際上也是對頁面進行一個重要性打分。在演算法開始前，給所有頁面一個相同的初始現金（cash）。當下載了某個頁面P之後，將P的現金分攤給所有從P中分析出的鏈接，並且將P的現金清空。對於待抓取URL隊列中的所有頁面按照現金數進行排序。
2.3.6 大站優先策略
對於待抓取URL隊列中的所有網頁，根據所屬的網站進行分類。對於待下載頁面數多的網站，優先下載。這個策略也因此叫做大站優先策略。
3、爬蟲分類
開發網路爬蟲應該選擇Nutch、Crawler4j、WebMagic、scrapy、WebCollector還是其他的？上面說的爬蟲，基本可以分3類：
（1）分布式爬蟲：Nutch
（2）JAVA爬蟲：Crawler4j、WebMagic、WebCollector
（3）非JAVA爬蟲：scrapy（基於Python語言開發）
3.1 分布式爬蟲
爬蟲使用分布式，主要是解決兩個問題：
1)海量URL管理
2)網速
現在比較流行的分布式爬蟲，是Apache的Nutch。但是對於大多數用戶來說，Nutch是這幾類爬蟲里，最不好的選擇，理由如下：
1)Nutch是為搜索引擎設計的爬蟲，大多數用戶是需要一個做精準數據爬取（精抽取）的爬蟲。Nutch運行的一套流程里，有三分之二是為了搜索引擎而設計的。對精抽取沒有太大的意義。也就是說，用Nutch做數據抽取，會浪費很多的時間在不必要的計算上。而且如果你試圖通過對Nutch進行二次開發，來使得它適用於精抽取的業務，基本上就要破壞Nutch的框架，把Nutch改的面目全非，有修改Nutch的能力，真的不如自己重新寫一個分布式爬蟲框架了。
2)Nutch依賴hadoop運行，hadoop本身會消耗很多的時間。如果集群機器數量較少，爬取速度反而不如單機爬蟲快。
3)Nutch雖然有一套插件機制，而且作為亮點宣傳。可以看到一些開源的Nutch插件，提供精抽取的功能。但是開發過Nutch插件的人都知道，Nutch的插件系統有多蹩腳。利用反射的機制來載入和調用插件，使得程序的編寫和調試都變得異常困難，更別說在上面開發一套復雜的精抽取系統了。而且Nutch並沒有為精抽取提供相應的插件掛載點。Nutch的插件有隻有五六個掛載點，而這五六個掛載點都是為了搜索引擎服務的，並沒有為精抽取提供掛載點。大多數Nutch的精抽取插件，都是掛載在「頁面解析」(parser)這個掛載點的，這個掛載點其實是為了解析鏈接（為後續爬取提供URL），以及為搜索引擎提供一些易抽取的網頁信息(網頁的meta信息、text文本)。
4)用Nutch進行爬蟲的二次開發，爬蟲的編寫和調試所需的時間，往往是單機爬蟲所需的十倍時間不止。了解Nutch源碼的學**成本很高，何況是要讓一個團隊的人都讀懂Nutch源碼。調試過程中會出現除程序本身之外的各種問題(hadoop的問題、hbase的問題)。
5)很多人說Nutch2有gora，可以持久化數據到avro文件、hbase、mysql等。很多人其實理解錯了，這里說的持久化數據，是指將URL信息（URL管理所需要的數據）存放到avro、hbase、mysql。並不是你要抽取的結構化數據。其實對大多數人來說，URL信息存在哪裡無所謂。
6)Nutch2的版本目前並不適合開發。官方現在穩定的Nutch版本是nutch2.2.1，但是這個版本綁定了gora-0.3。如果想用hbase配合nutch（大多數人用nutch2就是為了用hbase)，只能使用0.90版本左右的hbase，相應的就要將hadoop版本降到hadoop 0.2左右。而且nutch2的官方教程比較有誤導作用，Nutch2的教程有兩個，分別是Nutch1.x和Nutch2.x，這個Nutch2.x官網上寫的是可以支持到hbase 0.94。但是實際上，這個Nutch2.x的意思是Nutch2.3之前、Nutch2.2.1之後的一個版本，這個版本在官方的SVN中不斷更新。而且非常不穩定（一直在修改）。
所以，如果你不是要做搜索引擎，盡量不要選擇Nutch作為爬蟲。有些團隊就喜歡跟風，非要選擇Nutch來開發精抽取的爬蟲，其實是沖著Nutch的名氣，當然最後的結果往往是項目延期完成。
如果你是要做搜索引擎，Nutch1.x是一個非常好的選擇。Nutch1.x和solr或者es配合，就可以構成一套非常強大的搜索引擎了。如果非要用Nutch2的話，建議等到Nutch2.3發布再看。目前的Nutch2是一個非常不穩定的版本。
3.2 JAVA爬蟲
這里把JAVA爬蟲單獨分為一類，是因為JAVA在網路爬蟲這塊的生態圈是非常完善的。相關的資料也是最全的。這里可能有爭議，我只是隨便談談。
其實開源網路爬蟲（框架）的開發非常簡單，難問題和復雜的問題都被以前的人解決了（比如DOM樹解析和定位、字元集檢測、海量URL去重），可以說是毫無技術含量。包括Nutch，其實Nutch的技術難點是開發hadoop，本身代碼非常簡單。網路爬蟲從某種意義來說，類似遍歷本機的文件，查找文件中的信息。沒有任何難度可言。之所以選擇開源爬蟲框架，就是為了省事。比如爬蟲的URL管理、線程池之類的模塊，誰都能做，但是要做穩定也是需要一段時間的調試和修改的。
對於爬蟲的功能來說。用戶比較關心的問題往往是：
1）爬蟲支持多線程么、爬蟲能用代理么、爬蟲會爬取重復數據么、爬蟲能爬取JS生成的信息么？
不支持多線程、不支持代理、不能過濾重復URL的，那都不叫開源爬蟲，那叫循環執行http請求。
能不能爬js生成的信息和爬蟲本身沒有太大關系。爬蟲主要是負責遍歷網站和下載頁面。爬js生成的信息和網頁信息抽取模塊有關，往往需要通過模擬瀏覽器(htmlunit,selenium)來完成。這些模擬瀏覽器，往往需要耗費很多的時間來處理一個頁面。所以一種策略就是，使用這些爬蟲來遍歷網站，遇到需要解析的頁面，就將網頁的相關信息提交給模擬瀏覽器，來完成JS生成信息的抽取。
2）爬蟲可以爬取ajax信息么？
網頁上有一些非同步載入的數據，爬取這些數據有兩種方法：使用模擬瀏覽器（問題1中描述過了），或者分析ajax的http請求，自己生成ajax請求的url，獲取返回的數據。如果是自己生成ajax請求，使用開源爬蟲的意義在哪裡？其實是要用開源爬蟲的線程池和URL管理功能（比如斷點爬取）。
如果我已經可以生成我所需要的ajax請求（列表），如何用這些爬蟲來對這些請求進行爬取？
爬蟲往往都是設計成廣度遍歷或者深度遍歷的模式，去遍歷靜態或者動態頁面。爬取ajax信息屬於deep web（深網）的范疇，雖然大多數爬蟲都不直接支持。但是也可以通過一些方法來完成。比如WebCollector使用廣度遍歷來遍歷網站。爬蟲的第一輪爬取就是爬取種子集合(seeds)中的所有url。簡單來說，就是將生成的ajax請求作為種子，放入爬蟲。用爬蟲對這些種子，進行深度為1的廣度遍歷（默認就是廣度遍歷）。
3）爬蟲怎麼爬取要登陸的網站？
這些開源爬蟲都支持在爬取時指定cookies，模擬登陸主要是靠cookies。至於cookies怎麼獲取，不是爬蟲管的事情。你可以手動獲取、用http請求模擬登陸或者用模擬瀏覽器自動登陸獲取cookie。
4）爬蟲怎麼抽取網頁的信息？
開源爬蟲一般都會集成網頁抽取工具。主要支持兩種規范：CSS SELECTOR和XPATH。至於哪個好，這里不評價。
5）爬蟲怎麼保存網頁的信息？
有一些爬蟲，自帶一個模塊負責持久化。比如webmagic，有一個模塊叫pipeline。通過簡單地配置，可以將爬蟲抽取到的信息，持久化到文件、資料庫等。還有一些爬蟲，並沒有直接給用戶提供數據持久化的模塊。比如crawler4j和webcollector。讓用戶自己在網頁處理模塊中添加提交資料庫的操作。至於使用pipeline這種模塊好不好，就和操作資料庫使用ORM好不好這個問題類似，取決於你的業務。
6）爬蟲被網站封了怎麼辦？
爬蟲被網站封了，一般用多代理（隨機代理）就可以解決。但是這些開源爬蟲一般沒有直接支持隨機代理的切換。所以用戶往往都需要自己將獲取的代理，放到一個全局數組中，自己寫一個代理隨機獲取（從數組中）的代碼。
7）網頁可以調用爬蟲么？
爬蟲的調用是在Web的服務端調用的，平時怎麼用就怎麼用，這些爬蟲都可以使用。
8）爬蟲速度怎麼樣？
單機開源爬蟲的速度，基本都可以講本機的網速用到極限。爬蟲的速度慢，往往是因為用戶把線程數開少了、網速慢，或者在數據持久化時，和資料庫的交互速度慢。而這些東西，往往都是用戶的機器和二次開發的代碼決定的。這些開源爬蟲的速度，都很可以。
9）明明代碼寫對了，爬不到數據，是不是爬蟲有問題，換個爬蟲能解決么？
如果代碼寫對了，又爬不到數據，換其他爬蟲也是一樣爬不到。遇到這種情況，要麼是網站把你封了，要麼是你爬的數據是javascript生成的。爬不到數據通過換爬蟲是不能解決的。
10）哪個爬蟲可以判斷網站是否爬完、那個爬蟲可以根據主題進行爬取？
爬蟲無法判斷網站是否爬完，只能盡可能覆蓋。
至於根據主題爬取，爬蟲之後把內容爬下來才知道是什麼主題。所以一般都是整個爬下來，然後再去篩選內容。如果嫌爬的太泛，可以通過限制URL正則等方式，來縮小一下范圍。
11）哪個爬蟲的設計模式和構架比較好？
設計模式純屬扯淡。說軟體設計模式好的，都是軟體開發完，然後總結出幾個設計模式。設計模式對軟體開發沒有指導性作用。用設計模式來設計爬蟲，只會使得爬蟲的設計更加臃腫。
至於構架，開源爬蟲目前主要是細節的數據結構的設計，比如爬取線程池、任務隊列，這些大家都能控制好。爬蟲的業務太簡單，談不上什麼構架。
所以對於JAVA開源爬蟲，我覺得，隨便找一個用的順手的就可以。如果業務復雜，拿哪個爬蟲來，都是要經過復雜的二次開發，才可以滿足需求。
3.3 非JAVA爬蟲
在非JAVA語言編寫的爬蟲中，有很多優秀的爬蟲。這里單獨提取出來作為一類，並不是針對爬蟲本身的質量進行討論，而是針對larbin、scrapy這類爬蟲，對開發成本的影響。
先說python爬蟲，python可以用30行代碼，完成JAVA 50行代碼乾的任務。python寫代碼的確快，但是在調試代碼的階段，python代碼的調試往往會耗費遠遠多於編碼階段省下的時間。使用python開發，要保證程序的正確性和穩定性，就需要寫更多的測試模塊。當然如果爬取規模不大、爬取業務不復雜，使用scrapy這種爬蟲也是蠻不錯的，可以輕松完成爬取任務。
上圖是Scrapy的架構圖，綠線是數據流向，首先從初始URL 開始，Scheler 會將其交給 Downloader 進行下載，下載之後會交給 Spider 進行分析，需要保存的數據則會被送到Item Pipeline，那是對數據進行後期處理。另外，在數據流動的通道里還可以安裝各種中間件，進行必要的處理。 因此在開發爬蟲的時候，最好也先規劃好各種模塊。我的做法是單獨規劃下載模塊，爬行模塊，調度模塊，數據存儲模塊。
對於C++爬蟲來說，學**成本會比較大。而且不能只計算一個人的學**成本，如果軟體需要團隊開發或者交接，那就是很多人的學**成本了。軟體的調試也不是那麼容易。
還有一些ruby、php的爬蟲，這里不多評價。的確有一些非常小型的數據採集任務，用ruby或者php很方便。但是選擇這些語言的開源爬蟲，一方面要調研一下相關的生態圈，還有就是，這些開源爬蟲可能會出一些你搜不到的BUG（用的人少、資料也少）
4、反爬蟲技術
因為搜索引擎的流行，網路爬蟲已經成了很普及網路技術，除了專門做搜索的Google，Yahoo，微軟，網路以外，幾乎每個大型門戶網站都有自己的搜索引擎，**小小叫得出來名字得就幾十種，還有各種不知名的幾千幾萬種，對於一個內容型驅動的網站來說，受到網路爬蟲的光顧是不可避免的。
一些智能的搜索引擎爬蟲的爬取頻率比較合理，對網站資源消耗比較少，但是很多糟糕的網路爬蟲，對網頁爬取能力很差，經常並發幾十上百個請求循環重復抓取，這種爬蟲對中小型網站往往是毀滅性打擊，特別是一些缺乏爬蟲編寫經驗的程序員寫出來的爬蟲破壞力極強，造成的網站訪問壓力會非常大，會導致網站訪問速度緩慢，甚至無法訪問。
一般網站從三個方面反爬蟲：用戶請求的Headers，用戶行為，網站目錄和數據載入方式。前兩種比較容易遇到，大多數網站都從這些角度來反爬蟲。第三種一些應用ajax的網站會採用，這樣增大了爬取的難度。
4.1 通過Headers反爬蟲
從用戶請求的Headers反爬蟲是最常見的反爬蟲策略。很多網站都會對Headers的User-Agent進行檢測，還有一部分網站會對Referer進行檢測（一些資源網站的防盜鏈就是檢測Referer）。如果遇到了這類反爬蟲機制，可以直接在爬蟲中添加Headers，將瀏覽器的User-Agent復制到爬蟲的Headers中；或者將Referer值修改為目標網站域名。對於檢測Headers的反爬蟲，在爬蟲中修改或者添加Headers就能很好的繞過。
[評論：往往容易被忽略，通過對請求的抓包分析，確定referer，在程序中模擬訪問請求頭中添加]
4.2 基於用戶行為反爬蟲
還有一部分網站是通過檢測用戶行為，例如同一IP短時間內多次訪問同一頁面，或者同一賬戶短時間內多次進行相同操作。
D. 你認為為什麼大數據時代的諸多產業或者現象喜歡和生態圈這個詞結合反映了數據
生態圈這個詞也不是只有大數據材相關啊
編程語言就有生態圈，比如python的生態圈就是科學計算，PHP的生態圈就很小，僅限於web開發
要說大數據裡面的生態圈，可能用得最多的就是hadoop生態圈
E. hadoop 如何實現大數據
Hadoop本身是分布式框架，如果在hadoop框架下，需要配合hbase，hive等工具來進行大數據計算。如果具體深入還要了解HDFS，Map/Rece，任務機制等等。如果要分析還要考慮其他分析展現工具。
大數據還有分析才有價值
用於分析大數據的工具主要有開源與商用兩個生態圈。開源大數據生態圈：1、Hadoop HDFS、HadoopMapRece, HBase、Hive 漸次誕生，早期Hadoop生態圈逐步形成。2、. Hypertable是另類。它存在於Hadoop生態圈之外，但也曾經有一些用戶。3、NoSQL，membase、MongoDb商用大數據生態圈：1、一體機資料庫/數據倉庫：IBM PureData(Netezza), OracleExadata, SAP Hana等等。2、數據倉庫：TeradataAsterData, EMC GreenPlum, HPVertica 等等。3、數據集市：QlikView、 Tableau 、 以及國內的Yonghong Data Mart 。
F. hadoop是怎麼存儲大數據的
Hadoop本身是分布式框架，如果在hadoop框架下，需要配合hbase，hive等工具來進行大數據計算。如果具體深入還要了解HDFS，Map/Rece，任務機制等等。如果要分析還要考慮其他分析展現工具。
大數據還有分析才有價值
用於分析大數據的工具主要有開源與商用兩個生態圈。開源大數據生態圈：1、Hadoop HDFS、HadoopMapRece, HBase、Hive 漸次誕生，早期Hadoop生態圈逐步形成。2、. Hypertable是另類。它存在於Hadoop生態圈之外，但也曾經有一些用戶。3、NoSQL，membase、MongoDb商用大數據生態圈：1、一體機資料庫/數據倉庫：IBM PureData(Netezza), OracleExadata, SAP Hana等等。2、數據倉庫：TeradataAsterData, EMC GreenPlum, HPVertica 等等。3、數據集市：QlikView、 Tableau 、 以及國內的Yonghong Data Mart 。
G. 如何建立一個完整可用的安全大數據平台
「
要建立一個大數據系統，我們需要從數據流的源頭跟蹤到最後有價值的輸出，並在現有的Hadoop和大數據生態圈內根據實際需求挑選並整合各部分合適的組件來構建一個能夠支撐多種查詢和分析功能的系統平台。這其中既包括了對數據存儲的選擇，也涵蓋了數據線上和線下處理分離等方面的思考和權衡。此外，沒有任何一個引入大數據解決方案的商業應用在生產環境上承擔的起安全隱患。
1
計算框架篇
大數據的價值
只有在能指導人們做出有價值的決定時，數據才能體現其自身的價值。因此，大數據技術要服務於實際的用途，才是有意義的。一般來說，大數據可以從以下三個方面指導人們做出有價值的決定：
報表生成（比如根據用戶歷史點擊行為的跟蹤和綜合分析、 應用程序活躍程度和用戶粘性計算等）；
診斷分析（例如分析為何用戶粘性下降、根據日誌分析系統為何性能下降、垃圾郵件以及病毒的特徵檢測等）；
決策（例如個性化新聞閱讀或歌曲推薦、預測增加哪些功能能增加用戶粘性、幫助廣告主進行廣告精準投放、設定垃圾郵件和病毒攔截策略等）。
圖 1
進一步來看，大數據技術從以下三個方面解決了傳統技術難以達成的目標（如圖1）：
在歷史數據上的低延遲（互動式）查詢，目標是加快決策過程和時間， 例如分析一個站點為何變緩慢並嘗試修復它；
在實時數據上的低延遲查詢，目的是幫助用戶和應用程序在實時數據上做出決策， 例如實時檢測並阻攔病毒蠕蟲（一個病毒蠕蟲可以在1.3秒內攻擊1百萬台主機）；
更加精細高級的數據處理演算法，這可以幫助用戶做出「更好」的決策， 例如圖數據處理、異常點檢測、趨勢分析及其他機器學習演算法。
蛋糕模式
從將數據轉換成價值的角度來說，在Hadoop生態圈十年蓬勃成長的過程中，YARN和Spark這二者可以算得上是里程碑事件。Yarn的出現使得集群資源管理和數據處理流水線分離，大大革新並推動了大數據應用層面各種框架的發展（SQL on Hadoop框架, 流數據，圖數據，機器學習）。
它使得用戶不再受到MapRece開發模式的約束，而是可以創建種類更為豐富的分布式應用程序，並讓各類應用程序運行在統一的架構上，消除了為其他框架維護獨有資源的開銷。就好比一個多層蛋糕，下面兩層是HDFS和Yarn, 而MapRece就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。
在這一架構體系中，總體數據處理分析作業分三塊（圖2），在HBase上做互動式查詢（Apache Phoenix, Cloudera Impala等）， 在歷史數據集上編寫MapRece程序抑或利用Hive等做批處理業務， 另外對於實時流數據分析Apache Storm則會是一種標准選擇方案。
雖然Yarn的出現極大地豐富了Hadoop生態圈的應用場景，但仍存有兩個顯而易見的挑戰：一是在一個平台上需要維護三個開發堆棧；二是在不同框架內很難共享數據，比如很難在一個框架內對流數據做互動式查詢。這也意味著我們需要一個更為統一和支持更好抽象的計算框架的出現。
圖 2
一統江湖
Spark的出現使得批處理任務，互動式查詢，實時流數據處理被整合到一個統一的框架內（圖3），同時Spark和現有的開源生態系統也能夠很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通過啟用內存分布數據集，優化迭代工作負載， 用戶能夠更簡單地操作數據，並在此基礎上開發更為精細的演算法，如機器學習和圖演算法等。
有三個最主要的原因促使Spark目前成為了時下最火的大數據開源社區（擁有超過來自200多個公司的800多個contributors）：
Spark可以擴展部署到超過8000節點並處理PB級別的數據，同時也提供了很多不錯的工具供應用開發者進行管理和部署；
Spark提供了一個互動式shell供開發者可以用Scala或者Python即時性試驗不同的功能；
Spark提供了很多內置函數使得開發者能夠比較容易地寫出低耦合的並且能夠並發執行的代碼，這樣開發人員就更能集中精力地為用戶提供更多的業務功能而不是花費時間在優化並行化代碼之上。
當然Spark也和當年的MapRece一樣不是萬靈葯，比如對實時性要求很高的流數據處理上Apache Storm還是被作為主流選擇， 因為Spark Streaming實際上是microbatch（將一個流數據按時間片切成batch,每個batch提交一個job）而不是事件觸發實時系統，所以雖然支持者們認為microbatch在系統延時性上貢獻並不多，但在生產環境中和Apache Storm相比還不是特別能滿足對低延時要求很高的應用場景。
比如在實踐過程中， 如果統計每條消息的平均處理時間，很容易達到毫秒級別，但一旦統計類似service assurance（確保某條消息在毫秒基本能被處理完成）的指標， 系統的瓶頸有時還是不能避免。
但同時我們不能不注意到，在許多用例當中，與流數據的交互以及和靜態數據集的結合是很有必要的, 例如我們需要在靜態數據集上進行分類器的模型計算，並在已有分類器模型的基礎上，對實時進入系統的流數據進行交互計算來判定類別。
由於Spark的系統設計對各類工作（批處理、流處理以及互動式工作）進行了一個共有抽象，並且生態圈內延伸出了許多豐富的庫（MLlib機器學習庫、SQL語言API、GraphX）, 使得用戶可以在每一批流數據上進行靈活的Spark相關操作，在開發上提供了許多便利。
Spark的成熟使得Hadoop生態圈在短短一年之間發生了翻天覆地的變化， Cloudera和Hortonworks紛紛加入了Spark陣營，而Hadoop項目群中除了Yarn之外已經沒有項目是必須的了（雖然Mesos已在一些場合替代了Yarn）, 因為就連HDFS，Spark都可以不依賴。但很多時候我們仍然需要像Impala這樣的依賴分布式文件系統的MPP解決方案並利用Hive管理文件到表的映射，因此Hadoop傳統生態圈依然有很強的生命力。
另外在這里簡要對比一下互動式分析任務中各類SQL on Hadoop框架，因為這也是我們在實際項目實施中經常遇到的問題。我們主要將注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中歷史最短的，論文發表在15年的SIGMOD會議上， 原文對比了數據倉庫上不同類型的查詢在Shark（Spark最早對SQL介面提供的支持）、Spark SQL和Impala上的性能比較。
也就是說， 雖然Spark SQL在Shark的基礎上利用Catalyst optimizer在代碼生成上做了很多優化，但總體性能還是比不上Impala, 尤其是當做join操作的時候， Impala可以利用「predicate pushdown」更早對表進行選擇操作從而提高性能。
不過Spark SQL的Catalyst optimizer一直在持續優化中，相信未來會有更多更好的進展。Cloudera的Benchmark評測中Impala一直比其他SQL on Hadoop框架性能更加優越，但同時Hortonworks評測則指出雖然單個數據倉庫查詢Impala可以在很短的時間內完成，但是一旦並發多個查詢Hive on Tez的優勢就展示出來。另外Hive on Tez在SQL表達能力也要比Impala更強（主要是因為Impala的嵌套存儲模型導致的）， 因此根據不同的場景選取不同的解決方案是很有必要的。
圖 3
各領風騷抑或代有才人出？
近一年比較吸引人眼球的Apache Flink（與Spark一樣已有5年歷史，前身已經是柏林理工大學一個研究性項目，被其擁躉推崇為繼MapRece, Yarn，Spark之後第四代大數據分析處理框架）。 與Spark相反，Flink是一個真正的實時流數據處理系統，它將批處理看作是流數據的特例，同Spark一樣它也在嘗試建立一個統一的平台運行批量，流數據，互動式作業以及機器學習，圖演算法等應用。
Flink有一些設計思路是明顯區別於Spark的，一個典型的例子是內存管理，Flink從一開始就堅持自己精確的控制內存使用並且直接操作二進制數據，而Spark一直到1.5版本都還是試用java的內存管理來做數據緩存，這也導致了Spark很容易遭受OOM以及JVM GC帶來的性能損失。
但是從另外一個角度來說, Spark中的RDD在運行時被存成java objects的設計模式也大大降低了用戶編程設計門檻， 同時隨著Tungsten項目的引入，Spark現在也逐漸轉向自身的內存管理， 具體表現為Spark生態圈內從傳統的圍繞RDD（分布式java對象集合）為核心的開發逐漸轉向以DataFrame(分布式行對象集合)為核心。
總的來說，這兩個生態圈目前都在互相學習，Flink的設計基因更為超前一些，但Spark社區活躍度大很多，發展到目前毫無疑問是更為成熟的選擇，比如對數據源的支持（HBase, Cassandra, Parquet, JSON, ORC）更為豐富以及更為統一簡潔的計算表示。另一方面，Apache Flink作為一個由歐洲大陸發起的項目，目前已經擁有來自北美、歐洲以及亞洲的許多貢獻者，這是否能夠一改歐洲在開源世界中一貫的被動角色，我們將在未來拭目以待。
2
NoSQL資料庫篇
NoSQL資料庫在主流選擇上依舊集中在MongoDB, HBase和Cassandra這三者之間。在所有的NoSQL選擇中，用C 編寫的MongoDB幾乎應該是開發者最快也最易部署的選擇。MongoDB是一個面向文檔的資料庫，每個文檔／記錄／數據（包括爬取的網頁數據及其他大型對象如視頻等）是以一種BSON（Binary JSON）的二進制數據格式存儲, 這使得MongoDB並不需要事先定義任何模式, 也就是模式自由（可以把完全不同結構的記錄放在同一個資料庫里）。
MongoDB對於完全索引的支持在應用上是很方便的，同時也具備一般NoSQL分布式資料庫中可擴展，支持復制和故障恢復等功能。 MongoDB一般應用於高度伸縮性的緩存及大尺寸的JSON數據存儲業務中，但不能執行「JOIN」操作，而且數據佔用空間也比較大，最被用戶詬病的就是由於MongoDB提供的是資料庫級鎖粒度導致在一些情況下建索引操作會引發整個資料庫阻塞。一般來說，MongoDB完全可以滿足一些快速迭代的中小型項目的需求。
下面來主要談談Cassandra和HBase之間的比較選擇。Cassandra和HBase有著截然不同的基因血統。HBase和其底層依賴的系統架構源自於著名的Google FileSystem（發表於2003年）和Google BigTable設計（發表於2006年）， 其克服了HDFS注重吞吐量卻犧牲I/O的缺點，提供了一個存儲中間層使得用戶或者應用程序可以隨機讀寫數據。
具體來說，HBase的更新和刪除操作實際上是先發生在內存MemStore中， 當MemStore滿了以後會Flush到StoreFile, 之後當StoreFile文件數量增長到一定閾值後會觸發Compact合並操作，因此HBase的更新操作其實是不斷追加的操作，而最終所有更新和刪除數據的持久化操作都是在之後Compact過程中進行的。
這使得應用程序在向內存MemStore寫入數據後，所做的修改馬上就能得到反映，用戶讀到的數據絕不會是陳舊的數據，保證了I/O高性能和數據完全一致性； 另一方面來說， HBase基於Hadoop生態系統的基因就已經決定了他自身的高度可擴展性、容錯性。
在數據模型上，Cassandra和HBase類似實現了一個key-value提供面向列式存儲服務，其系統設計參考了 Amazon Dynamo (發表於2007年) 分布式哈希（DHT）的P2P結構（實際上大部分Cassandra的初始工作都是由兩位從Amazon的Dynamo組跳槽到Facebook的工程師完成)，同樣具有很高的可擴展性和容錯性等特點。
除此之外， 相對HBase的主從結構，Cassandra去中心化的P2P結構能夠更簡單地部署和維護，比如增加一台機器只需告知Cassandra系統新節點在哪，剩下的交給系統完成就行了。同時，Cassandra對多數據中心的支持也更好，如果需要在多個數據中心進行數據遷移Cassandra會是一個更優的選擇。
Eric Brewer教授提出的經典CAP理論認為任何基於網路的數據共享系統，最多隻能滿足數據一致性、可用性、分區容忍性三要素中的兩個要素。實際分布式系統的設計過程往往都是在一致性與可用性上進行取捨，相比於HBase數據完全一致性的系統設計，Cassandra選擇了在優先考慮數據可用性的基礎上讓用戶自己根據應用程序需求決定系統一致性級別。
比如：用戶可以配置QUONUM參數來決定系統需要幾個節點返回數據才能向客戶端做出響應，ONE指只要有一個節點返回數據就可以對客戶端做出響應，ALL指等於數據復制份數的所有節點都返回結果才能向客戶端做出響應，對於數據一致性要求不是特別高的可以選擇ONE，它是最快的一種方式。
從基因和發展歷史上來說，HBase更適合用做數據倉庫和大規模數據處理與分析（比如對網頁數據建立索引）， 而Cassandra則更適合用作實時事務和互動式查詢服務。Cassandra在國外市場佔有比例和發展要遠比國內紅火， 在不少權威測評網站上排名都已經超過了HBase。目前Apache Cassandra的商業化版本主要由軟體公司DataStax進行開發和銷售推廣。另外還有一些NoSQL分布式資料庫如Riak, CouchDB也都在各自支持的廠商推動下取得了不錯的發展。
雖然我們也考慮到了HBase在實際應用中的不便之處比如對二級索引的支持程度不夠（只支持通過單個行鍵訪問，通過行鍵的范圍查詢，全表掃描），不過在明略的大數據基礎平台上，目前整合的是依然是HBase。
理由也很簡單，HBase出身就與Hadoop的生態系統緊密集成，其能夠很容易與其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）進行整合，而不需要重新部署一套分布式資料庫系統，而且可以很方便地將同樣的數據內容在同一個生態系統中根據不同框架需要來變換存儲格式（比如存儲成Hive表或者Parquet格式）。
我們在很多項目中都有需要用到多種SQL on Hadoop框架，來應對不同應用場景的情況，也體會到了在同一生態系統下部署多種框架的簡便性。 但同時我們也遇到了一些問題， 因為HBase項目本身與HDFS和Zookeeper系統分別是由不同開源團隊進行維護的，所以在系統整合時我們需要先對HBase所依賴的其他模塊進行設置再對HBase進行配置，在一定程度上降低了系統維護的友好性。
目前我們也已經在考慮將Cassandra應用到一些新的客戶項目中，因為很多企業級的應用都需要將線上線下資料庫進行分離，HBase更適合存儲離線處理的結果和數據倉庫，而更適合用作實時事務和並發交互性能更好的Cassandra作為線上服務資料庫會是一種很好的選擇。
3
大數據安全篇
隨著越來越多各式各樣的數據被存儲在大數據系統中，任何對企業級數據的破壞都是災難性的，從侵犯隱私到監管違規，甚至會造成公司品牌的破壞並最終影響到股東收益。給大數據系統提供全面且有效的安全解決方案的需求已經十分迫切：
大數據系統存儲著許多重要且敏感的數據，這些數據是企業長久以來的財富
與大數據系統互動的外部系統是動態變化的，這會給系統引入新的安全隱患
在一個企業的內部，不同Business Units會用不同的方式與大數據系統進行交互，比如線上的系統會實時給集群推送數據、數據科學家團隊則需要分析存儲在數據倉庫內的歷史數據、運維團隊則會需要對大數據系統擁有管理許可權。
因此為了保護公司業務、客戶、財務和名譽免於被侵害，大數據系統運維團隊必須將系統安全高度提高到和其他遺留系統一樣的級別。同時大數據系統並不意味著引入大的安全隱患，通過精細完整的設計，仍然能夠把一些傳統的系統安全解決方案對接到最新的大數據集群系統中。
一般來說，一個完整的企業級安全框架包括五個部分：
Administration: 大數據集群系統的集中式管理，設定全局一致的安全策略
Authentication: 對用戶和系統的認證
Authorization：授權個人用戶和組對數據的訪問許可權
Audit：維護數據訪問的日誌記錄
Data Protection：數據脫敏和加密以達到保護數據的目的
系統管理員要能夠提供覆蓋以上五個部分的企業級安全基礎設施，否則任何一環的缺失都可能給整個系統引入安全性風險。
在大數據系統安全集中式管理平台這塊，由Hortonworks推出的開源項目Apache Ranger就可以十分全面地為用戶提供Hadoop生態圈的集中安全策略的管理，並解決授權(Authorization)和審計(Audit)。例如，運維管理員可以輕松地為個人用戶和組對文件、數據等的訪問策略，然後審計對數據源的訪問。
與Ranger提供相似功能的還有Cloudera推出的Apache Sentry項目，相比較而言Ranger的功能會更全面一些。
而在認證（Authentication）方面, 一種普遍採用的解決方案是將基於Kerberos的認證方案對接到企業內部的LDAP環境中， Kerberos也是唯一為Hadoop全面實施的驗證技術。
另外值得一提的是Apache Knox Gateway項目，與Ranger提高集群內部組件以及用戶互相訪問的安全不同，Knox提供的是Hadoop集群與外界的唯一交互介面，也就是說所有與集群交互的REST API都通過Knox處理。這樣，Knox就給大數據系統提供了一個很好的基於邊緣的安全（perimeter-based security）。
基於以上提到的五個安全指標和Hadoop生態圈安全相關的開源項目， 已經足已證明基於Hadoop的大數據平台我們是能夠構建一個集中、一致、全面且有效的安全解決方案。
我市再ITjob管網上面找的
H. 什麼是大數據時代
大數據時代
（巨量資料（IT行業術語））
編輯
最早提出「大數據」時代到來的是全球知名咨詢公司麥肯錫，麥肯錫稱：「數據，已經滲透到當今每一個行業和業務職能領域，成為重要的生產因素。人們對於海量數據的挖掘和運用，預示著新一波生產率增長和消費者盈餘浪潮的到來。」 「大數據」在物理學、生物學、環境生態學等領域以及軍事、金融、通訊等行業存在已有時日，卻因為近年來互聯網和信息行業的發展而引起人們關注。
中文名
大數據時代
外文名
Big data
提出者
麥肯錫
類 屬
科技名詞
目錄
1 產生背景
2 影響
▪ 大數據
▪ 大數據的精髓
▪ 數據價值
▪ 可視化
3 特徵
4 案例分析
5 產業崛起
6 提供依據
7 應對措施
產生背景
編輯
進入2012年，大數據（big data）一詞越來越多地被提及，人們用它來描述和定義信息爆炸時代產生的海量數
大數據時代來臨
據，並命名與之相關的技術發展與創新。它已經上過《紐約時報》《華爾街日報》的專欄封面，進入美國白宮官網的新聞，現身在國內一些互聯網主題的講座沙龍中，甚至被嗅覺靈敏的國金證券、國泰君安、銀河證券等寫進了投資推薦報告。[1]
數據正在迅速膨脹並變大，它決定著企業的未來發展，雖然很多企業可能並沒有意識到數據爆炸性增長帶來問題的隱患，但是隨著時間的推移，人們將越來越多的意識到數據對企業的重要性。
正如《紐約時報》2012年2月的一篇專欄中所稱，「大數據」時代已經降臨，在商業、經濟及其他領域中，決策將日益基於數據和分析而作出，而並非基於經驗和直覺。
哈佛大學社會學教授加里·金說：「這是一場革命，龐大的數據資源使得各個領域開始了量化進程，無論學術界、商界還是政府，所有領域都將開始這種進程。」[2]
影響
編輯
大數據
現在的社會是一個高速發展的社會，科技發達，信息流通，人們之間的交流越來越密切，生活也越來越方便，大數據就是這個高科技時代的產物。[3]
隨著雲時代的來臨，大數據（Big data）也吸引了越來越多的關注。大數據（Big data）通常用來形容一個公司創造的大量非結構化和半結構化數據，這些數據在下載到關系型資料庫用於分析時會花費過多時間和金錢。大數據分析常和雲計算聯繫到一起，因為實時的大型數據集分析需要像MapRece一樣的框架來向數十、數百或甚至數千的電腦分配工作。[2]
在現今的社會，大數據的應用越來越彰顯他的優勢，它佔領的領域也越來越大，電子商務、O2O、物流配送等，各種利用大數據進行發展的領域正在協助企業不斷地發展新業務，創新運營模式。有了大數據這個概念，對於消費者行為的判斷，產品銷售量的預測，精確的營銷范圍以及存貨的補給已經得到全面的改善與優化。[4]
「大數據」在互聯網行業指的是這樣一種現象：互聯網公司在日常運營中生成、累積的用戶網路行為數據。這些數據的規模是如此龐大，以至於不能用G或T來衡量。
大數據到底有多大？一組名為「互聯網上一天」的數據告訴我們，一天之中，互聯網產生的全部內容可以刻滿1.68億張DVD；發出的郵件有2940億封之多（相當於美國兩年的紙質信件數量）；發出的社區帖子達200萬個（相當於《時代》雜志770年的文字量）；賣出的手機為37.8萬台，高於全球每天出生的嬰兒數量37.1萬……[1]
截止到2012年，數據量已經從TB（1024GB=1TB）級別躍升到PB（1024TB=1PB）、EB（1024PB=1EB）乃至ZB(1024EB=1ZB)級別。國際數據公司（IDC）的研究結果表明，2008年全球產生的數據量為0.49ZB，2009年的數據量為0.8ZB，2010年增長為1.2ZB，2011年的數量更是高達1.82ZB，相當於全球每人產生200GB以上的數據。而到2012年為止，人類生產的所有印刷材料的數據量是200PB，全人類歷史上說過的所有話的數據量大約是5EB。IBM的研究稱，整個人類文明所獲得的全部數據中，有90%是過去兩年內產生的。而到了2020年，全世界所產生的數據規模將達到今天的44倍。[5] 每一天，全世界會上傳超過5億張圖片，每分鍾就有20小時時長的視頻被分享。然而，即使是人們每天創造的全部信息——包括語音通話、電子郵件和信息在內的各種通信，以及上傳的全部圖片、視頻與音樂，其信息量也無法匹及每一天所創造出的關於人們自身的數字信息量。
這樣的趨勢會持續下去。我們現在還處於所謂「物聯網」的最初級階段，而隨著技術成熟，我們的設備、交通工具和迅速發展的「可穿戴」科技將能互相連接與溝通。科技的進步已經使創造、捕捉和管理信息的成本降至2005年的六分之一，而從2005年起，用在硬體、軟體、人才及服務之上的商業投資也增長了整整50%，達到了4000億美元。[5]
大數據的精髓
大數據帶給我們的三個顛覆性觀念轉變：是全部數據，而不是隨機采樣；是大體方向，而不是精確制導；是相關關系，而不是因果關系。[6]
A.不是隨機樣本，而是全體數據：在大數據時代，我們可以分析更多的數據，有時候甚至可以處理和某個特別現象相關的所有數據，而不再依賴於隨機采樣(隨機采樣，以前我們通常把這看成是理所應當的限制，但高性能的數字技術讓我們意識到，這其實是一種人為限制);
B.不是精確性，而是混雜性：研究數據如此之多，以至於我們不再熱衷於追求精確度;之前需要分析的數據很少，所以我們必須盡可能精確地量化我們的記錄，隨著規模的擴大，對精確度的痴迷將減弱;擁有了大數據，我們不再需要對一個現象刨根問底，只要掌握了大體的發展方向即可，適當忽略微觀層面上的精確度，會讓我們在宏觀層面擁有更好的洞察力;
C.不是因果關系，而是相關關系：我們不再熱衷於找因果關系，尋找因果關系是人類長久以來的習慣，在大數據時代，我們無須再緊盯事物之間的因果關系，而應該尋找事物之間的相關關系;相關關系也許不能准確地告訴我們某件事情為何會發生，但是它會提醒我們這件事情正在發生。
數據價值
大數據時代，什麼最貴?
十年前，葛大爺曾說過，「21世紀什麼最貴?」——「人才」，深以為然。只是，十年後的今天，大數據時代也帶來了身價不斷翻番的各種數據。由於急速拓展的網路帶寬以及各種穿戴設備所帶來的大量數據，數據的增長從未停歇，甚至呈井噴式增長。[7]
一分鍾內，微博推特上新發的數據量超過10萬；社交網路「臉譜」的瀏覽量超過600萬……
這些龐大數字，意味著什麼？
它意味著，一種全新的致富手段也許就擺在面前，它的價值堪比石油和黃金。
事實上，當你仍然在把微博等社交平台當作抒情或者發議論的工具時，華爾街的斂財高手們卻正在挖掘這些互聯網的「數據財富」，先人一步用其預判市場走勢，而且取得了不俗的收益。
讓我們一起來看看——他們是怎麼做的。
這些數據都能幹啥。具體有六大價值：
●1、華爾街根據民眾情緒拋售股票；
●2、對沖基金依據購物網站的顧客評論，分析企業產品銷售狀況；
●3、銀行根據求職網站的崗位數量，推斷就業率；
●4、投資機構搜集並分析上市企業聲明，從中尋找破產的蛛絲馬跡；
●5、美國疾病控制和預防中心依據網民搜索，分析全球范圍內流感等病疫的傳播狀況；
●6、美國總統奧巴馬的競選團隊依據選民的微博，實時分析選民對總統競選人的喜好。[1]
可視化
「數據是新的石油。」亞馬遜前任首席科學家Andreas Weigend說。Instagram以10億美元出售之時，成立於1881年的世界最大影像產品及服務商柯達正申請破產。
大數據是如此重要，以至於其獲取、儲存、搜索、共享、分析，乃至可視化地呈現，都成為了當前重要的研究課題[1] 。
「當時時變幻的、海量的數據出現在眼前，是怎樣一幅壯觀的景象？在後台注視著這一切，會不會有接近上帝俯視人間星火的感覺？」
這個問題我曾請教過劉建國，中國著名的搜索引擎專家。劉曾主持開發過國內第一個大規模中英文搜索引擎系統「天網」。
要知道，劉建國曾任至網路的首席技術官，在這樣一家每天需應對網民各種搜索請求1.7億次（2013年約為8.77億次）的網站中，如果只是在後台靜靜端坐，可能片刻都不能安心吧。網路果然在提供搜索服務之外，逐漸增添了網路指數，後又建立了基於網民搜索數據的重要產品「貼吧」及網路統計產品等。
劉建國沒有直接回答這個問題，他想了很久，似乎陷入了回憶，嘴角的笑容含著詭秘。
倒是有公司已經在大數據中有接近上帝俯視的感覺，美國洛杉磯就有企業宣稱，他們將全球夜景的歷史數據建立模型，在過濾掉波動之後，做出了投資房地產和消費的研究報告。
在數據可視化呈現方面，我最新接收到的故事是，一位在美國思科物流部門工作的朋友，很聰明的印度裔小夥子，被Facebook高價挖角，進入其數據研究小組。他後來驚訝地發現，裡面全是來自物流企業、供應鏈方面的技術人員和專家，「Facebook想知道，能不能用物流的角度和流程的方式，分析用戶的路徑和行為。」
特徵
編輯
數據量大（Volume）
第一個特徵是數據量大。大數據的起始計量單位至少是P（1000個T）、E（100萬個T）或Z（10億個T）。
類型繁多（Variety）
第二個特徵是數據類型繁多。包括網路日誌、音頻、視頻、圖片、地理位置信息等等，多類型的數據對數據的處理能力提出了更高的要求。
價值密度低（Value）
第三個特徵是數據價值密度相對較低。如隨著物聯網的廣泛應用，信息感知無處不在，信息海量，但價值密度較低，如何通過強大的機器演算法更迅速地完成數據的價值「提純」，是大數據時代亟待解決的難題。
速度快、時效高（Velocity）
第四個特徵是處理速度快，時效性要求高。這是大數據區分於傳統數據挖掘最顯著的特徵。
既有的技術架構和路線，已經無法高效處理如此海量的數據，而對於相關組織來說，如果投入巨大採集的信息無法通過及時處理反饋有效信息，那將是得不償失的。可以說，大數據時代對人類的數據駕馭能力提出了新的挑戰，也為人們獲得更為深刻、全面的洞察能力提供了前所未有的空間與潛力。[2]
案例分析
編輯
個案一
你開心他就買你焦慮他就拋[2]
華爾街「德溫特資本市場」公司首席執行官保羅·霍廷每天的工作之一，就是利用電腦程序分析全球3.4億微博賬戶的留言，進而判斷民眾情緒，再以「1」到「50」進行打分。根據打分結果，霍廷再決定如何處理手中數以百萬美元計的股票。
霍廷的判斷原則很簡單：如果所有人似乎都高興，那就買入；如果大家的焦慮情緒上升，那就拋售。
這一招收效顯著——當年第一季度，霍廷的公司獲得了7%的收益率。
個案二
國際商用機器公司（IBM）估測，這些「數據」值錢的地方主要在於時效。對於片刻便能定輸贏的華爾街，這一時效至關重要。曾經，華爾街2%的企業搜集微博等平台的「非正式」數據；如今，接近半數企業採用了這種手段。
●「社會流動」創業公司在「大數據」行業生機勃勃，和微博推特是合作夥伴。它分析數據，告訴廣告商什麼是正確的時間，誰是正確的用戶，什麼是應該發表的正確內容，備受廣告商熱愛。
●通過喬希·詹姆斯的Omniture（著名的網頁流量分析工具）公司，你可以知道有多少人訪問你的網站，以及他們呆了多長時間——這些數據對於任何企業來說都至關重要。詹姆斯把公司賣掉，進賬18億美元。
●微軟專家吉拉德喜歡把這些「大數據」結果可視化：他把客戶請到辦公室，將包含這些公司的數據圖譜展現出來——有些是普通的時間軸，有些像蒲公英，有些則是鋪滿整個畫面的泡泡，泡泡中顯示這些客戶的粉絲正在談論什麼話題。
●「臉譜」數據分析師傑弗遜的工作就是搭建數據分析模型，弄清楚用戶點擊廣告的動機和方式。
處理和分析工具
用於分析大數據的工具主要有開源與商用兩個生態圈。
開源大數據生態圈：
1、Hadoop HDFS、HadoopMapRece, HBase、Hive 漸次誕生，早期Hadoop生態圈逐步形成。
2、. Hypertable是另類。它存在於Hadoop生態圈之外，但也曾經有一些用戶。
3、NoSQL，membase、MongoDb
商用大數據生態圈：
1、一體機資料庫/數據倉庫：IBM PureData(Netezza), OracleExadata, SAP Hana等等。
2、數據倉庫：TeradataAsterData, EMC GreenPlum, HPVertica 等等。
3、數據集市：QlikView、 Tableau 、 以及國內的Yonghong Data Mart 。
產業崛起
編輯
越來越多的政府、企業等機構開始意識到數據正在成為組織最重要的資產，數據分析能力正在成為組織的核心競爭力。具體有以下三大案例：
1、2012年3月22日，奧巴馬政府宣布投資2億美元拉動大數據相關產業發展，將「大數據戰略」上升為國家意志。奧巴馬政府將數據定義為「未來的新石油」，並表示一個國家擁有數據的規模、活性及解釋運用的能力將成為綜合國力的重要組成部分，未來，對數據的佔有和控制甚至將成為陸權、海權、空權之外的另一種國家核心資產。
2、聯合國也在2012年發布了大數據政務白皮書，指出大數據對於聯合國和各國政府來說是一個歷史性的機遇，人們如今可以使用極為豐富的數據資源，來對社會經濟進行前所未有的實時分析，幫助政府更好地響應社會和經濟運行。
3、而最為積極的還是眾多的IT企業。麥肯錫在一份名為《大數據，是下一輪創新、競爭和生產力的前沿》的專題研究報告中提出，「對於企業來說，海量數據的運用將成為未來競爭和增長的基礎」，該報告在業界引起廣泛反響。
IBM則提出，上一個十年，他們拋棄了PC，成功轉向了軟體和服務，而這次將遠離服務與咨詢，更多地專注於因大數據分析軟體而帶來的全新業務增長點。IBM執行總裁羅睿蘭認為，「數據將成為一切行業當中決定勝負的根本因素，最終數據將成為人類至關重要的自然資源。」
在國內，網路已經致力於開發自己的大數據處理和存儲系統；騰訊也提出2013年已經到了數據化運營的黃金時期，如何整合這些數據成為未來的關鍵任務。
事實上，自2009年以來，有關「大數據」 主題的並購案層出不窮，且並購數量和規模呈逐步上升的態勢。其中，Oracle對Sun、惠普對Autonomy兩大並購案總金額高達176億美元，大數據的產業價值由此可見一斑。[1-2]
提供依據
編輯
大數據是信息通信技術發展積累至今，按照自身技術發展邏輯，從提高生產效率向更高級智能階段的自然生長。無處不在的信息感知和採集終端為我們採集了海量的數據，而以雲計算為代表的計算技術的不斷進步，為我們提供了強大的計算能力，這就圍繞個人以及組織的行為構建起了一個與物質世界相平行的數字世界[1-2] 。
大數據雖然孕育於信息通信技術的日漸普遍和成熟，但它對社會經濟生活產生的影響絕不限於技術層面，更本質上，它是為我們看待世界提供了一種全新的方法，即決策行為將日益基於數據分析做出，而不是像過去更多憑借經驗和直覺做出。
事實上，大數據的影響並不僅僅限於信息通信產業，而是正在「吞噬」和重構很多傳統行業，廣泛運用數據分析手段管理和優化運營的公司其實質都是一個數據公司。麥當勞、肯德基以及蘋果公司等旗艦專賣店的位置都是建立在數據分析基礎之上的精準選址。而在零售業中，數據分析的技術與手段更是得到廣泛的應用，傳統企業如沃爾瑪通過數據挖掘重塑並優化供應鏈，新崛起的電商如卓越亞馬遜、淘寶等則通過對海量數據的掌握和分析，為用戶提供更加專業化和個性化的服務。
最讓人吃驚的例子是，社交媒體監測平台DataSift監測了Facebook（臉譜） IPO當天Twitter上的情感傾向與Facebook股價波動的關聯。在Facebook開盤前Twitter上的情感逐漸轉向負面，25分鍾之後Facebook的股價便開始下跌。而當Twitter上的情感轉向正面時，Facebook股價在8分鍾之後也開始了回彈。最終當股市接近收盤、Twitter上的情感轉向負面時，10分鍾後Facebook的股價又開始下跌。最終的結論是：Twitter上每一次情感傾向的轉向都會影響Facebook股價的波動。
這僅僅只是基於社交網路產生的大數據「預見未來」的眾多案例之一，此外還有谷歌通過網民搜索行為預測流感爆發等例子。不僅在商業方面，大數據在社會建設方面的作為同樣令人驚嘆，智能電網、智慧交通、智慧醫療、智慧環保、智慧城市等的蓬勃興起，都與大數據技術與應用的發展息息相關。
「大數據」可能帶來的巨大價值正漸漸被人們認可，它通過技術的創新與發展，以及數據的全面感知、收集、分析、共享，為人們提供了一種全新的看待世界的方法。更多地基於事實與數據做出決策，這樣的思維方式，可以預見，將推動一些習慣於靠「差不多」運行的社會發生巨大變革。
應對措施
編輯
一個好的企業應該未雨綢繆，從現在開始就應該著手准備，為企業的後期的數據收集和分析做好准備，企業可以從下面六個方面著手，這樣當面臨鋪天蓋地的大數據的時候，以確保企業能夠快速發展，具體為下面六點。
目標
幾乎每個組織都可能有源源不斷的數據需要收集，無論是社交網路還是車間感測器設備，而且每個組織都有大量的數據需要處理，IT人員需要了解自己企業運營過程中都產生了什麼數據，以自己的數據為基準，確定數據的范圍。
准則
雖然每個企業都會產生大量數據，而且互不相同、多種多樣的，這就需要企業IT人員在現在開始收集確認什麼數據是企業業務需要的，找到最能反映企業業務情況的數據。
重新評估
大數據需要在伺服器和存儲設施中進行收集，並且大多數的企業信息管理體系結構將會發生重要大變化，IT經理則需要准備擴大他們的系統，以解決數據的不斷擴大，IT經理要了解公司現有IT設施的情況，以組建處理大數據的設施為導向，避免一些不必要的設備的購買。
重視大數據技術
大數據是最近幾年才興起的詞語，而並不是所有的IT人員對大數據都非常了解，例如如今的Hadoop，MapRece，NoSQL等技術都是2013年剛興起的技術，企業IT人員要多關注這方面的技術和工具，以確保將來能夠面對大數據的時候做出正確的決定。
培訓企業的員工
大多數企業最缺乏的是人才，而當大數據到臨的時候，企業將會缺少這方面的採集收集分析方面的人才，對於一些公司，特別是那種人比較少的公司，工作人員面臨大數據將是一種挑戰，企業要在平時的時候多對員工進行這方面的培訓，以確保在大數據到來時，員工也能適應相關的工作。
培養三種能力
Teradata大中華區首席執行官辛兒倫對新浪科技表示，隨著大數據時代的到來，企業應該在內部培養三種能力。第一，整合企業數據的能力；第二，探索數據背後價值和制定精確行動綱領的能力；第三，進行精確快速實時行動的能力。
做到上面的幾點，當大數據時代來臨的時候，面臨大量數據將不是束手無策，而是成竹在胸，而從數據中得到的好處也將促進企業快速發展。
望採納，謝謝
I. C/C++ 是否存在大數據生態圈，為什麼
cloudera自己的大數據生態就是C++的, 比如Impala,ku。
java 把寫大規模並發程序的難度降低了，但是把問題挪到了JVM上面，雖然內存分配省心了，但是問題在JVM上面表現出來了。
C++ 是寫的時候難了，但是用起來爽
GO 的話，並發解決了， GC問題還是沒解決 和java 一樣一樣的！
J. 大數據生態圈最令世界驕傲的事
大數據生態最令世界驕傲的是這個大數據生態圈中給我們了很多的啟示，讓我們倍感驕傲