1. 創建大數據項目的五大步驟
創建大數據項目的五大步驟
企業需要積極的提升他們的數據管理能力。這並非意味著他們應該制定繁瑣的流程和監督機制。明智的企業會配合他們的數據活動的生命周期制定靈活的流程和功能：根據業務需求啟動更輕更嚴格、更強大的功能，並根據需求的增加來提升質量或精度。
一些企業正在利用新興技術來應對新的數據源，但大多數企業仍然面臨著需要努力管理好他們已經掌握或者應當掌握的數據信息的困境，而當他們試圖部署大數據功能時，發現自己還需要面對和處理新的以及當下實時的數據。
為了能夠實現持久成功的大數據項目，企業需要把重點放在如下五個主要領域。
1、確立明確的角色分工和職責范圍。
對於您企業環境中的所有的數據信息，您需要對於這些數據信息所涉及的關鍵利益相關者、決策者有一個清晰的了解和把控。當數據信息在企業的系統傳輸過程中及其整個生命周期中，角色分工將發生變化，而企業需要對這些變化有一個很好的理解。當企業開始部署大數據項目之後，務必要明確識別相關數據的關鍵利益相關者，並做好這些數據信息的完善和迭代工作。
2、加強企業的數據治理和數據管理功能。
確保您企業的進程足夠強大，能夠滿足和支持大數據用戶和大數據技術的需求。進程可以是靈活的，並應充分考慮到業務部門和事務部門的需求，這些部門均伴有不同程度的嚴謹性和監督要求。
確保您企業的參考信息架構已經更新到包括大數據。這樣做會給未來的項目打好最好的使用大數據技術和適當的信息管理能力的基礎。
確保您企業的元數據管理功能足夠強大，能夠包括並關聯所有的基本元數據組件。隨著時間的推移，進行有序的分類，滿足業務規范。
一旦您開始在您企業的生產部門推廣您的解決方案時，您會希望他們長期持續的使用該解決方案，所以對架構功能的定義並監督其發揮的作用是至關重要的。確保您企業的治理流程包括IT控制的角色，以幫助企業的利益相關者們進行引導項目，以最佳地利用這些數據信息。其還應該包括您企業的安全和法務團隊。根據我們的經驗，使用現有的監督機制能夠達到最佳的工作狀態，只要企業實施了大數據應用，並專注於快速在進程中處理應用程序，而不是阻礙進程的通過。
3、了解環境中的數據的目的和要求的精度水平，並相應地調整您企業的期望值和流程。
無論其是一個POC，或一個已經進入主流業務流程的項目，請務必確保您對於期望利用這些數據來執行什麼任務，及其質量和精度處於何種級別有一個非常清晰的了解。這種方法將使得企業的項目能夠尋找到正確的數據來源和利益相關者，以更好地評估這些數據信息的價值和影響，進而讓您決定如何最好地管理這些數據信息。更高的質量和精度則要求更強大的數據管理和監督能力。
隨著您企業大數據項目的日趨成熟，考慮建立一套按照數據質量或精確度分類的辦法，這將使得數據用戶得以更好的了解他們所使用的是什麼，並相應地調整自己的期望值。例如，您可以使用白色、藍色或金色來分別代表原始數據、清理過的數據，經過驗證可以有針對性的支持分析和使用的數據。有些企業甚至進一步完善了這一分類方法：將數據從1到5進行分類，其中1是原始數據，而5是便於理解，經過整理的、有組織的數據。
4、將對非結構化的內容的管理納入到您企業的數據管理能力。
非結構化數據一直是企業業務運營的一部分，但既然現在我們已經有了更好的技術來探索，分析和這些非結構化的內容，進而幫助改善業務流程和工業務洞察，所以我們最終將其正式納入我們的數據管理是非常重要的。大多數企業目前都被困在了這一步驟。
資料庫中基本的、非結構化的數據是以評論的形式或者自由的形式存在的，其至少是資料庫的一部分，應該被納入到數據管理。但挖掘這些數據信息則是非常難的。
數字數據存儲在傳統的結構化資料庫和業務流程外，很少有許多的治理范圍分組和數據管理的實現，除了當其被看作是一個技術問題時。一般來說，除了嚴格遵守相關的安全政策，今天的企業尚未對其進行真正有效的管理。當您的企業開始大跨步實現了大數據項目之後，您會發現這一類型的數據信息迅速進入了您需要管理的范疇，其輸出會影響您企業的商業智能解決方案或者甚至是您企業的業務活動。積極的考慮將這些數據納入到您企業的數據管理功能的范圍，並明確企業的所有權，並記錄好這些數據信息的諸如如何使用、信息來源等等資料。
不要採取「容易的輕松路線」，單純依靠大數據技術是您企業唯一正式的非結構化數據管理的過程。隨著時間的推移，企業將收集越來越多的非結構化數據，請務必搞清楚哪些數據是好的，哪些是壞的，他們分別來自何處，以及其使用是否一致，將變得越來越重要，甚至在其生命周期使用這個數據都是至關重要的。
要保持這種清晰，您可以使用大數據和其他工具，以了解您企業所收集的數據信息，確定其有怎樣的價值，需要怎樣的管理，這是至關重要的。大多數進入您企業的大數據系統的非結構化數據都已經經過一些監控了，但通常是作為一個BLOB（binarylargeobject）二進制大對象和非結構化的形式進行的。隨著您的企業不斷的在您的業務流程中「發掘」出這一類型的數據，其變得更加精確和有價值。其可能還具有額外的特點，符合安全，隱私或法律和法規的元素要求。最終，這些數據塊可以成為新的數據元素或添加到現有的數據，但您必須有元數據對其進行描述和管理，以便盡可能最有效地利用這些數據。
5、正式在生產環境運行之前進行測試。
如果您的企業做的是一次性的分析或完整的一次性的試點，這可能並不適用於您的企業，但對大多數企業來說，他們最初的大數據工作將迅速發展，他們找到一個可持續利用他們已經挖掘出的極具價值的信息的需求。這意味著需要在您的沙箱環境中進行測試，然後才正式的在您的生產環境運。
2. 怎樣搭建企業大數據平台
步驟一：開展大數據咨詢
規劃合理的統籌規劃與科學的頂層設計是大數據建設和應用的基礎。通過大數據咨詢規劃服務，可以幫助企業明晰大數據建設的發展目標、重點任務和藍圖架構，並將藍圖架構的實現分解為可操作、可落地的實施路徑和行動計劃，有效指導企業大數據戰略的落地實施。
步驟二：強化組織制度保障
企業信息化領導小組是企業大數據建設的強有力保障。企業需要從項目啟動前就開始籌備組建以高層領導為核心的企業信息化領導小組。除了高層領導，還充分調動業務部門積極性，組織的執行層面由業務部門和IT部門共同組建，並確立決策層、管理層和執行層三級的項目組織機構，每個小組各司其職，完成項目的具體執行工作。
步驟三：建設企業大數據平台
基於大數據平台咨詢規劃的成果，進行大數據的建設和實施。由於大數據技術的復雜性，因此企業級大數據平台的建設不是一蹴而就，需循序漸進，分步實施，是一個持續迭代的工程，需本著開放、平等、協作、分享的互聯網精神，構建大數據平台生態圈，形成相互協同、相互促進的良好的態勢。
步驟四：進行大數據挖掘與分析
在企業級大數據平台的基礎上，進行大數據的挖掘與分析。隨著時代的發展，大數據挖掘與分析也會逐漸成為大數據技術的核心。大數據的價值體現在對大規模數據集合的智能處理方面，進而在大規模的數據中獲取有用的信息，要想逐步實現這個功能，就必須對數據進行分析和挖掘，通過進行數據分析得到的結果，應用於企業經營管理的各個領域。
步驟五：利用大數據進行輔助決策
通過大數據的分析，為企業領導提供輔助決策。利用大數據決策將成為企業決策的必然，系統通過提供一個開放的、動態的、以全方位數據深度融合為基礎的輔助決策環境，在適當的時機、以適當的方式提供指標、演算法、模型、數據、知識等各種決策資源，供決策者選擇，最大程度幫助企業決策者實現數據驅動的科學決策。
關於怎樣搭建企業大數據平台，青藤小編就和您分享到這里了。如果你對大數據工程有濃厚的興趣，希望這篇文章能夠對你有所幫助。如果您還想了解更多數據分析師、大數據工程師的技巧及素材等內容，可以點擊本站的其他文章進行學習。
3. 如何搭建大數據分析平台
隨著各個企業的不斷發展，企業的數據量不斷的增加。企業的競爭壓力也在不斷的加大，利用數據分析平台來增加企業的競爭力，已經成為各個企業的信息化建設的核心環節。數據分析，我認為其含義就是從數據中提取信息創造價值。因為數據本身的價值是無法直接可見的，但是通過各種數據計算和分析，可以將人們無法注意到的信息從數據中提取出來，創造價值。那麼具體如何搭建數據分析平台呢？我認為應從一下幾個方面：
1.分析價值：明確數據分析的價值，通過笑譽大數據的分析，能夠快速地發現消費者的需求變化和市場發展趨勢，從而幫助企業及時做出正確的決策，從而使企業在市場上擁有更強的競爭力和不斷創新的能力。
2.數據源頭：有可供數據分析進行數據獲取的平台。當今的IT信息化系統都在不斷的建設當中，在數據分析時需要對虧升橋各種不同種類來源的數據進行分析。這些來源有可能是系統內部的日誌數據，也有可能是來源於其他介面的數據等等。
3.數據處理：從數據源中採集各種符合企業需求的數據，經過驗證、清洗、並轉化銷猛為所需格式後，儲存到一個合適的持久化儲存層中。
4.數據展現：將各個不同分析演算法處理過的結果進行可視化展示。將數據從預先計算匯總的結果數據中讀取出來，並用一種友好界面或者表格的形式展示出來，這樣便於企業內部非專業人員對數據分析結果的理解。
4. 如何創建一個大數據平台
所謂的大數據平台不是獨立存在的，比如網路是依賴搜索引擎獲得大數據並開展業務的，阿里是通過電子商務交易獲得大數據並開展業務的，騰訊是通過社交獲得大數據並開始業務的，所以說大數據平台不是獨立存在的，重點是如何搜集和沉澱數據，如何分析數據並挖掘數據的價值。
我可能還不夠資格回答這個問題，沒有經歷過一個公司大數據平台從無到有到復雜的過程。不過說說看法吧，也算是梳理一下想法找找噴。
這是個需求驅動的過程。
曾經聽過spotify的分享，印象很深的是，他們分享說，他們的hadoop集群第一次故障是因為，機器放在靠窗的地方，太陽曬了當機了（笑）。從簡單的沒有機房放在自家窗前的集群到一直到現在復雜的數據平台，這是一個不斷演進的過程。
對小公司來說，大概自己找一兩台機器架個集群算算，也算是大數據平台了。在初創階段，數據量會很小，不需要多大的規模。這時候組件選擇也很隨意，Hadoop一套，任務調度用腳本或者輕量的框架比如luigi之類的，數據分析可能hive還不如導入RMDB快。監控和部署也許都沒時間整理，用腳本或者輕量的監控，大約是沒有ganglia、nagios，puppet什麼的。這個階段也許算是技術積累，用傳統手段還是真大數據平台都是兩可的事情，但是為了今後的擴展性，這時候上Hadoop也許是不錯的選擇。
當進入高速發展期，也許擴容會跟不上計劃，不少公司可能會遷移平台到雲上，比如AWS阿里雲什麼的。小規模高速發展的平台，這種方式應該是經濟實惠的，省了運維和管理的成本，擴容比較省心。要解決的是選擇平台本身提供的服務，計算成本，打通數據出入的通道。整個數據平台本身如果走這條路，可能就已經基本成型了。走這條路的比較有名的應該是netflix。
也有一個階段，你發現雲服務的費用太高，雖然省了你很多事，但是花錢嗖嗖的。幾個老闆一合計，再玩下去下個月工資發布出來了。然後無奈之下公司開始往私有集群遷移。這時候你大概需要一群靠譜的運維，幫你監管機器，之前兩三台機器登錄上去看看狀態換個磁碟什麼的也許就不可能了，你面對的是成百上千台主機，有些關鍵服務必須保證穩定，有些是數據節點，磁碟三天兩頭損耗，網路可能被壓得不堪重負。你需要一個靠譜的人設計網路布局，設計運維規范，架設監控，值班團隊走起7*24小時隨時准備出台。然後上面再有平台組真的大數據平台走起。
然後是選型，如果有技術實力，可以直接用社區的一整套，自己管起來，監控部署什麼的自己走起。這個階段部署監控和用戶管理什麼的都不可能像兩三個節點那樣人肉搞了，配置管理，部署管理都需要專門的平台和組件；定期Review用戶的作業和使用情況，決定是否擴容，清理數據等等。否則等機器和業務進一步增加，團隊可能會死的很慘，疲於奔命，每天事故不斷，進入惡性循環。
當然有金錢實力的大戶可以找Cloudera，Hortonworks，國內可以找華為星環，會省不少事，適合非互聯網土豪。當然互燃鄭改聯網公司也有用這些東西的，比如Ebay。
接下去你可能需要一些重量的組件幫你做一些事情。
比如你的數據接入，之前可能找個定時腳本或者爬log發包找個伺服器接收寫入HDFS，現在可能不行了，這些大概沒有高性能，沒有異常保障，你需要更強壯的解決方案，比如Flume之類的。
你的業務不斷壯大，老闆需要看的報表越來越多，需要訓練的數據也需要清洗，你就需要任務調度，比如oozie或者azkaban之類的，這些系統幫你管理關鍵任務的調度和監控。
數據分析人員的數據大概可能漸漸從RDBMS搬遷到集群了，因為傳統數皮判據庫已經完全hold不住了，但他們不會寫代碼，所以你上馬了Hive。然後很多用戶用了Hive覺得太慢，叢物你就又上馬交互分析系統，比如Presto，Impala或者SparkSQL。
你的數據科學家需要寫ML代碼，他們跟你說你需要Mahout或者SparkMLLib，於是你也部署了這些。
至此可能數據平台已經是工程師的日常工作場所了，大多數業務都會遷移過來。這時候你可能面臨很多不同的問題。
比如各個業務線數據各種數據表多的一塌糊塗，不管是你還是寫數據的人大概都不知道數據從哪兒來，接下去到哪兒去。你就自己搞了一套元數據管理的系統。
你分析性能，發現你們的數據都是上百Column，各種復雜的Query，裸存的Text格式即便壓縮了也還是慢的要死，於是你主推用戶都使用列存，Parquet，ORC之類的。
又或者你發現你們的ETL很長，中間生成好多臨時數據，於是你下狠心把pipeline改寫成Spark了。
再接下來也許你會想到花時間去維護一個門戶，把這些零散的組件都整合到一起，提供統一的用戶體驗，比如一鍵就能把數據從資料庫chua一下拉到HDFS導入Hive，也能一鍵就chua一下再搞回去；點幾下就能設定一個定時任務，每天跑了給老闆自動推送報表；或者點一下就能起一個Storm的topology；或者界面上寫幾個Query就能查詢Hbase的數據。這時候你的數據平台算是成型了。
當然，磕磕碰碰免不了。每天你都有新的問題和挑戰，否則你就要失業了不是？
你發現社區不斷在解決你遇到過的問題，於是你們架構師每天分出很多時間去看社區的進展，有了什麼新工具，有什麼公司發布了什麼項目解決了什麼問題，興許你就能用上。
上了這些亂七八糟的東西，你以為就安生了？Hadoop平台的一個大特點就是坑多。尤其是新做的功能新起的項目。對於平台組的人，老闆如果知道這是天然坑多的平台，那他也許會很高興，因為跟進社區，幫忙修bug，一起互動其實是很提升公司影響力的實情。當然如果老闆不理解，你就自求多福吧，招幾個老司機，出了問題能馬上帶路才是正道。當然團隊的技術積累不能不跟上，因為數據平台還是亂世，三天不跟進你就不知道世界是什麼樣了。任何一個新技術，都是坑啊坑啊修啊修啊才完善的。如果是關鍵業務換技術，那需要小心再小心，技術主管也要有足夠的積累，能夠駕馭，知道收益和風險。
5. 如何構建大數據體系
一.數據搭建
建立自己的數據收集規范，形成一定的數據採集、篩選、分析等相應的制度
二.數據報表可視化
對數據進行標准化的配置，形成可視化的報表系統
三.產品與運營分析
對平台的各個角色建立全方位的用戶畫像，對行為進行數據跟蹤，對數據挖掘分析，建立漏斗模型，流動模型，用戶細分等模型。
四.精細化產品運營
對產品制定自動獲取數據制度，用數據跟蹤產品的生命周期，對數據進行細分，做到針對性運營
五.數據產品
藉助第三方數據獲取的渠道，形成數據化產品，提供數據化的依據
6. 公司級大數據處理平台的構建需要做哪些准備
按照大數據處理的流程，分為數據採集、數據存儲、數據提取、數據挖掘、數據分析，數據展現和應用。以下是鏈家網的案例，採用Hadoop集群建立BI和報表平台，以及採用業務員自助分析和數據挖掘、數據分析人員借用大數據平台的集群運算能力挖掘數據的雙模式業務。
除此之外，更傳統的企業對於大數據平台的應用也是基於以上的流程。
引用某大數據平台建設的案例，該機構是國家性研究機構，建立大數據平台主要收集市場數據，出台國家級的研究性報告，用於輔助市場決策。
從建設的及流程開始講起吧，算是提供一個方法論。
第一步是數據整合，對多源多類型的數據進行整合，實現數據共享。目前以帆軟報表FineReport為數據處理工具，以SQLServer為資料庫存儲平台，整合信息中心常用業務數據，常用的業務數據包括價格、進出口以及平衡表等。
第二步就是數據的抓取、處理激畢和分析並自動化生成系列產品報告，實現目標是解放生產力御盯。把業務人員從採集、整理、處理數據的體力勞動中解放出來，集中精力於市場深度分析研究、模型建立鎮鉛和。本質上還是數據整合，不同地方是數據自動採集，並依據構建的模型。技術選型：FineReport+FineBI+Python+Kettle(ETL工具)+SQLServer。
第三步是數據挖掘，目標是構建行業模型和行業計量模型實現科學決策。
依託一期、二期整合的數據和大數據，接下來將構建大數據能力，提供標准化的服務能力。但糧油的分析模型、行業積累模型，是一種因素模型、經驗模型，一定程度上依賴於分析師對市場的看法，這個模型分析結果需要分析師經驗和直覺來判斷，技術上要到位，所以這里通過帆軟報表FineReport和商業智能FineBI的結果,從數據報表、數據分析、數據挖掘三個層次，把數據轉化為信息把數據轉化為信息，使得業務人員能夠利用這些信息，輔助決策，這就是商業智能主要解決的問題。無論在哪個層次，核心目標就是「把數據轉化為信息」。
7. 如何建立一個完整可用的安全大數據平台
「
要建立一個大數據系統，我們需要從數據流的源頭跟蹤到最後有價值的輸出，並在現有的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管網上面找的
8. 搭建大數據平台的具體步驟是什麼
1、操作體系的挑選
操作體系一般使用開源版的RedHat、Centos或許Debian作為底層的構建渠道，要根據大數據渠道所要建立的數據剖析東西能夠支撐的體系，正確的挑選操作體系的版本。
2、建立Hadoop集群
Hadoop作為一個開發和運行處理大規模數據的軟體渠道，實現了在大量的廉價計算機組成的集群中對海量數據進行分布式計算。Hadoop結構中最核心的規劃是HDFS和MapRece，HDFS是一個高度容錯性的體系，合適布置在廉價的機器上，能夠供給高吞吐量的數據訪問，適用於那些有著超大數據集的應用程序;MapRece是一套能夠從海量的數據中提取數據最終回來成果集的編程模型。在生產實踐應用中，Hadoop非常合適應用於大數據存儲和大數據的剖析應用，合適服務於幾千台到幾萬台大的伺服器的集群運行，支撐PB級別的存儲容量。
3、挑選數據接入和預處理東西
面臨各種來源的數據，數據接入便是將這些零散的數據整合在一起，歸納起來進行剖析。數據接入首要包括文件日誌的接入、資料庫日誌的接入、關系型資料庫的接入和應用程序等的接入，數據接入常用的東西有Flume，Logstash，NDC(網易數據運河體系)，sqoop等。
4、數據存儲
除了Hadoop中已廣泛應用於數據存儲的HDFS，常用的還有分布式、面向列的開源資料庫Hbase，HBase是一種key/value體系，布置在HDFS上，與Hadoop一樣，HBase的目標首要是依靠橫向擴展，通過不斷的添加廉價的商用伺服器，添加計算和存儲才能。同時hadoop的資源管理器Yarn，能夠為上層應用供給統一的資源管理和調度，為集群在利用率、資源統一等方面帶來巨大的優點。
5、挑選數據挖掘東西
Hive能夠將結構化的數據映射為一張資料庫表，並供給HQL的查詢功能，它是建立在Hadoop之上的數據倉庫根底架構，是為了削減MapRece編寫工作的批處理體系，它的出現能夠讓那些通曉SQL技術、可是不熟悉MapRece、編程才能較弱和不擅長Java的用戶能夠在HDFS大規模數據集上很好的利用SQL言語查詢、匯總、剖析數據。
6、數據的可視化以及輸出API
關於處理得到的數據能夠對接主流的BI體系，比如國外的Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數(可免費試用)等，將成果進行可視化，用於決策剖析;或許迴流到線上，支撐線上業務的開展。
9. 怎麼搭建大數據分析平台
一般的大數據平台從平台搭建到數據分析大概包括以下幾個步驟：
Linux系統安裝。分布式計算平台或組件安裝，當前分布式系統的豎攔大多使用的是Hadoop系列開源系統。數據導入。數據分析。一般包括兩個階段：數據預處理和數據建模分析。數據預處理是為後面的建模分析做准備，主要工作時從海量數據中提取可用特徵，建立大寬表。數據慶纖敏譽枝建模分析是針對預處理提取的特徵或數據建模，得到想要的結果。結果可視化及輸出API。可視化一般式對結果或部分原始數據做展示。一般有兩種情況，行數據展示，和列查找展示。