分布式大數據平台
A. 大數據平台是什麼什麼時候需要大數據平台如何建立大數據平台
首先我們要了解java語言和Linux操作系統，這兩個是學習大數據的基礎，學習的順序不分前後。
Java ：只要了解一些基礎即可，做大數據不需要很深的Java 技術，學java SE 就相當於有學習大數據基礎。
Linux：因為大數據相關軟體都是在Linux上運行的，所以Linux要學習的扎實一些，學好Linux對你快速掌握大數據相關技術會有很大的幫助，能讓你更好的理解hadoop、hive、hbase、spark等大數據軟體的運行環境和網路環境配置，能少踩很多坑，學會shell就能看懂腳本這樣能更容易理解和配置大數據集群。還能讓你對以後新出的大數據技術學習起來更快。
Hadoop：這是現在流行的大數據處理平台幾乎已經成為大數據的代名詞，所以這個是必學的。Hadoop裡麵包括幾個組件HDFS、MapRece和YARN，HDFS是存儲數據的地方就像我們電腦的硬碟一樣文件都存儲在這個上面，MapRece是對數據進行處理計算的，它有個特點就是不管多大的數據只要給它時間它就能把數據跑完，但是時間可能不是很快所以它叫數據的批處理。
Zookeeper：這是個萬金油，安裝Hadoop的HA的時候就會用到它，以後的Hbase也會用到它。它一般用來存放一些相互協作的信息，這些信息比較小一般不會超過1M，都是使用它的軟體對它有依賴，對於我們個人來講只需要把它安裝正確，讓它正常的run起來就可以了。
Mysql：我們學習完大數據的處理了，接下來學習學習小數據的處理工具mysql資料庫，因為一會裝hive的時候要用到，mysql需要掌握到什麼層度那?你能在Linux上把它安裝好，運行起來，會配置簡單的許可權，修改root的密碼，創建資料庫。這里主要的是學習SQL的語法，因為hive的語法和這個非常相似。
Sqoop：這個是用於把Mysql里的數據導入到Hadoop里的。當然你也可以不用這個，直接把Mysql數據表導出成文件再放到HDFS上也是一樣的，當然生產環境中使用要注意Mysql的壓力。
Hive：這個東西對於會SQL語法的來說就是神器，它能讓你處理大數據變的很簡單，不會再費勁的編寫MapRece程序。有的人說Pig那?它和Pig差不多掌握一個就可以了。
Oozie：既然學會Hive了，我相信你一定需要這個東西，它可以幫你管理你的Hive或者MapRece、Spark腳本，還能檢查你的程序是否執行正確，出錯了給你發報警並能幫你重試程序，最重要的是還能幫你配置任務的依賴關系。我相信你一定會喜歡上它的，不然你看著那一大堆腳本，和密密麻麻的crond是不是有種想屎的感覺。
Hbase：這是Hadoop生態體系中的NOSQL資料庫，他的數據是按照key和value的形式存儲的並且key是唯一的，所以它能用來做數據的排重，它與MYSQL相比能存儲的數據量大很多。所以他常被用於大數據處理完成之後的存儲目的地。
Kafka：這是個比較好用的隊列工具，隊列是干嗎的?排隊買票你知道不?數據多了同樣也需要排隊處理，這樣與你協作的其它同學不會叫起來，你干嗎給我這么多的數據(比如好幾百G的文件)我怎麼處理得過來，你別怪他因為他不是搞大數據的，你可以跟他講我把數據放在隊列里你使用的時候一個個拿，這樣他就不在抱怨了馬上灰流流的去優化他的程序去了，因為處理不過來就是他的事情。而不是你給的問題。當然我們也可以利用這個工具來做線上實時數據的入庫或入HDFS，這時你可以與一個叫Flume的工具配合使用，它是專門用來提供對數據進行簡單處理，並寫到各種數據接受方(比如Kafka)的。
Spark：它是用來彌補基於MapRece處理數據速度上的缺點，它的特點是把數據裝載到內存中計算而不是去讀慢的要死進化還特別慢的硬碟。特別適合做迭代運算，所以演算法流們特別稀飯它。它是用scala編寫的。Java語言或者Scala都可以操作它，因為它們都是用JVM的。
B. 大數據有哪些常用的平台
大數據平台：是指以處理海量數據存儲、計算和不間斷流數據實時計算等場景為主的一套基礎設施。
典型的包括Hadoop系列、Spark、Storm、Flink以及Flume/Kafka等集群。
C. 什麼是大數據平台
我們在搜索引擎中每一次搜索的記錄、在電子商城中每一次的商品瀏覽和購買記錄、每一次電子支付的數據...這些看似不相乾的龐雜數據，匯總在一起，經過分析提煉，即可描繪出你這個人的行為習慣概況，對你未來可能採取的行為做出概率相當高的預測，這些數據我們可以把它統稱為顧客大數據。
移動互聯網興起之時，大家都在搶占線上流量、線上數據，但中國互聯網，你懂的，基本上龐大的消費顧客大數據都是掌握在BAT手上的，小互聯網公司很難獲取核心數據。但是隨著線下消費升級的發展，越來越多的人開始看到線下顧客大數據的重要性了，畢竟，線下店鋪才是顧客消費的主戰場，而且流量也未被BAT這樣的巨頭企業瓜分完，可以算是充滿商機的藍海了。
藍海歸藍海，但也存在一個問題，就是線下顧客大數據太龐大，太分散，除了星巴克麥當勞這種大企業有能力收集之外，一般店鋪難以建立自己的大數據平台，更不用談大數據的智能化處理了。
在這方面，目前就我所知，有家專門服務線下店鋪市場的智慧店鋪企業，名叫掌貝。這是家店鋪Marketing Tech智能營銷公司，它依託融合業務入口所沉澱的店鋪大數據，幫助商戶搭建自己的顧客大數據平台，實現自動化的精準營銷，從而帶動老客迴流、新客引流。可謂是正好切中線下顧客大數據市場的要害啦，有興趣的人可以去了解下。
D. mysql 將數據遷移到大數據平台分布式文件系統，用什麼工具合適
在我看來，一個完整的大數據平台應該提供離線計算、即席查詢、實時計算、實時查詢這幾個方面的功能。
hadoop、spark、storm 無論哪一個，單獨不可能完成上面的所有功能。
hadoop+spark+hive是一個很不錯的選擇.hadoop的HDFS毋庸置疑是分布式文件系統的解決方案，解決存儲問題；hadoop maprece、hive、spark application、sparkSQL解決的是離線計算和即席查詢的問題；spark streaming解決的是實時計算問題；另外，還需要HBase或者Redis等NOSQL技術來解決實時查詢的問題；
除了這些，大數據平台中必不可少的需要任務調度系統和數據交換工具；
任務調度系統解決所有大數據平台中的任務調度與監控；數據交換工具解決其他數據源與HDFS之間的數據傳輸，比如：資料庫到HDFS、HDFS到資料庫等等。
E. 在大數據處理環境下，哪一種分布式系統更合適，為什麼
1）集中式數據處理 集中式計算機網路由一個大型的中央系統，其終端是客戶機，數據全部存儲在中央系統，由資料庫管理系統進行管理，所有的處理都由該大型系統完成，終端只是用來輸入和輸出。終端自己不作任何處理，所有任務都在主機上進行處理。 集中式數據存儲的主要特點是能把所有數據保存在一個地方，各地辦公室的遠程終端通過電纜同中央計算機（主機）相聯，保證了每個終端使用的都是同一信息。備份數據容易，因為他們都存儲在伺服器上，而伺服器是唯一需要備份的系統。這還意味這伺服器是唯一需要安全保護的系統，終端沒有任何數據。銀行的自動提款機（ATM）採用的就是集中式計算機網路。另外所有的事務都在主機上進行處理，終端也不需要軟碟機，所以網路感染病毒的可能性很低。這種類型的網路總費用比較低，因為主機擁有大量存儲空間、功能強大的系統，而使終端可以使用功能簡單而便宜的微機和其他終端設備。 這類網路不利的一面是來自所有終端的計算都由主機完成，這類網路處理速度可能有些慢。另外，如果用戶有各種不同的需要，在集中式計算機網路上滿足這些需要可能是十分困難的，因為每個用戶的應用程序和資源都必須單獨設置，而讓這些應用程序和資源都在同一台集中式計算機上操作，使得系統效率不高。還有，因為所有用戶都必須連接到一台中央計算機，集中連接可能成為集中式網路的一個大問題。由於這些限制，如今的大多數網路都採用了分布式和協作式網路計算模型。 2）分布式數據處理 由於個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網路上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數據可以分布在很大區域。 分布式網路中，數據的存儲和處理都是在本地工作站上進行的。數據輸出可以列印，也可保存在軟盤上。通過網路主要是得到更快、更便捷的數據訪問。因為每台計算機都能夠存儲和處理數據，所以不要求伺服器功能十分強大，其價格也就不必過於昂貴。這種類型的網路可以適應用戶的各種需要，同時允許他們共享網路的數據、資源和服務。在分布式網路中使用的計算機既能夠作為獨立的系統使用，也可以把它們連接在一起得到更強的網路功能。 分布式計算的優點是可以快速訪問、多用戶使用。每台計算機可以訪問系統內其他計算機的信息文件；系統設計上具有更大的靈活性，既可為獨立的計算機的地區用戶的特殊需求服務，也可為聯網的企業需求服務，實現系統內不同計算機之間的通信；每台計算機都可以擁有和保持所需要的最大數據和文件；減少了數據傳輸的成本和風險。為分散地區和中心辦公室雙方提供更迅速的信息通信和處理方式，為每個分散的資料庫提供作用域，數據存儲於許多存儲單元中，但任何用戶都可以進行全局訪問，使故障的不利影響最小化，以較低的成本來滿足企業的特定要求。 分布式計算的缺點是：對病毒比較敏感，任何用戶都可能引入被病毒感染的文件，並將病毒擴散到整個網路。備份困難，如果用戶將數據存儲在各自的系統上，而不是將他們存儲在中央系統中，難於制定一項有效的備份計劃。這種情況還可能導致用戶使用同一文件的不同版本。為了運行程序要求性能更好的PC機；要求使用適當的程序；不同計算機的文件數據需要復制；對某些PC機要求有足夠的存儲容量，形成不必要的存儲成本；管理和維護比較復雜；設備必須要互相兼容。 3）協作式數據處理 協作式數據處理系統內的計算機能夠聯合處理數據，處理既可集中實施，也可分區實施。協作式計算允許各個客戶計算機合作處理一項共同的任務，採用這種方法，任務完成的速度要快於僅在一個客戶計算機運行。協作式計算允許計算機在整個網路內共享處理能力，可以使用其它計算機上的處理能力完成任務。除了具有在多個計算機系統上處理任務的能力，該類型的網路在共享資源方面類似於分布式計算。 協作式計算和分布式計算具有相似的優缺點。例如協作式網路上可以容納各種不同的客戶，協作式計算的優點是處理能力強，允許多用戶使用。缺點是病毒可迅速擴散到整個網路。因為數據能夠在整個網路內存儲，形成多個副本，文件同步困難。並且也使得備份所有的重要數據比較困難。
F. 如何打造高性能大數據分析平台
大數據分析系統作為一個關鍵性的系統在各個公司迅速崛起。但是這種海量規模的數據帶來了前所未有的性能挑戰。同時，如果大數據分析系統無法在第一時間為運營決策提供關鍵數據，那麼這樣的大數據分析系統一文不值。本文將從技術無關的角度討論一些提高性能的方法。下面我們將討論一些能夠應用在大數據分析系統不同階段的技巧和准則（例如數據提取，數據清洗，處理，存儲，以及介紹）。本文應作為一個通用准則，以確保最終的大數據分析平台能滿足性能要求。
1. 大數據是什麼？
大數據是最近IT界最常用的術語之一。然而對大數據的定義也不盡相同，所有已知的論點例如結構化的和非結構化、大規模的數據等等都不夠完整。大數據系統通常被認為具有數據的五個主要特徵，通常稱為數據的5 Vs。分別是大規模，多樣性，高效性、准確性和價值性。
互聯網是個神奇的大網，大數據開發和軟體定製也是一種模式，這里提供最詳細的報價，如果真的想做，可以來這里，這個手技的開始數字是一八七中間的是三兒零最後的是一四二五零，按照順序組合起來就可以找到，想說的是，除非想做或者了解這方面的內容，如果只是湊熱鬧的話，就不要來了。
據Gartner稱，大規模可以被定義為「在本（地）機數據採集和處理技術能力不足以為用戶帶來商業價值。當現有的技術能夠針對性的進行改造後來處理這種規模的數據就可以說是一個成功的大數據解決方案。
這種大規模的數據沒將不僅僅是來自於現有的數據源，同時也會來自於一些新興的數據源，例如常規（手持、工業）設備，日誌，汽車等，當然包括結構化的和非結構化的數據。
據Gartner稱，多樣性可以定義如下：「高度變異的信息資產，在生產和消費時不進行嚴格定義的包括多種形式、類型和結構的組合。同時還包括以前的歷史數據，由於技術的變革歷史數據同樣也成為多樣性數據之一 「。
高效性可以被定義為來自不同源的數據到達的速度。從各種設備，感測器和其他有組織和無組織的數據流都在不斷進入IT系統。由此，實時分析和對於該數據的解釋（展示）的能力也應該隨之增加。
根據Gartner，高效性可以被定義如下：「高速的數據流I/O(生產和消費)，但主要聚焦在一個數據集內或多個數據集之間的數據生產的速率可變上」。
准確性，或真實性或叫做精度是數據的另一個重要組成方面。要做出正確的商業決策，當務之急是在數據上進行的所有分析必須是正確和准確（精確）的。
大數據系統可以提供巨大的商業價值。像電信，金融，電子商務，社交媒體等，已經認識到他們的數據是一個潛在的巨大的商機。他們可以預測用戶行為，並推薦相關產品，提供危險交易預警服務，等等。
與其他IT系統一樣，性能是大數據系統獲得成功的關鍵。本文的中心主旨是要說明如何讓大數據系統保證其性能。
2. 大數據系統應包含的功能模塊
大數據系統應該包含的功能模塊，首先是能夠從多種數據源獲取數據的功能，數據的預處理（例如，清洗，驗證等），存儲數據，數據處理、數據分析等（例如做預測分析??，生成在線使用建議等等），最後呈現和可視化的總結、匯總結果。
下圖描述了大數據系統的這些高層次的組件
描述本節的其餘部分簡要說明了每個組分，如圖1。
2.1 各種各樣的數據源當今的IT生態系統，需要對各種不同種類來源的數據進行分析。這些來源可能是從在線Web應用程序，批量上傳或feed，流媒體直播數據，來自工業、手持、家居感測的任何東西等等。
顯然從不同數據源獲取的數據具有不同的格式、使用不同的協議。例如，在線的Web應用程序可能會使用SOAP / XML格式通過HTTP發送數據，feed可能會來自於CSV文件，其他設備則可能使用MQTT通信協議。
由於這些單獨的系統的性能是不在大數據系統的控制范圍之內，並且通常這些系統都是外部應用程序，由第三方供應商或團隊提供並維護，所以本文將不會在深入到這些系統的性能分析中去。
2.2 數據採集第一步，獲取數據。這個過程包括分析，驗證，清洗，轉換，去重，然後存到適合你們公司的一個持久化設備中（硬碟、存儲、雲等）。
在下面的章節中，本文將重點介紹一些關於如何獲取數據方面的非常重要的技巧。請注意，本文將不討論各種數據採集技術的優缺點。
2.3 存儲數據第二步，一旦數據進入大數據系統，清洗，並轉化為所需格式時，這些過程都將在數據存儲到一個合適的持久化層中進行。
在下面的章節中，本文將介紹一些存儲方面的最佳實踐（包括邏輯上和物理上）。在本文結尾也會討論一部分涉及數據安全方面的問題。
2.4 數據處理和分析第三步，在這一階段中的一部分干凈數據是去規范化的，包括對一些相關的數據集的數據進行一些排序，在規定的時間間隔內進行數據結果歸集，執行機器學習演算法，預測分析等。
在下面的章節中，本文將針對大數據系統性能優化介紹一些進行數據處理和分析的最佳實踐。
2.5 數據的可視化和數據展示最後一個步驟，展示經過各個不同分析演算法處理過的數據結果。該步驟包括從預先計算匯總的結果（或其他類似數據集）中的讀取和用一種友好界面或者表格（圖表等等）的形式展示出來。這樣便於對於數據分析結果的理解。
3. 數據採集中的性能技巧
數據採集是各種來自不同數據源的數據進入大數據系統的第一步。這個步驟的性能將會直接決定在一個給定的時間段內大數據系統能夠處理的數據量的能力。
數據採集??過程基於對該系統的個性化需求，但一些常用執行的步驟是 - 解析傳入數據，做必要的驗證，數據清晰，例如數據去重，轉換格式，並將其存儲到某種持久層。
涉及數據採集過程的邏輯步驟示如下圖所示：
下面是一些性能方面的技巧：
來自不同數據源的傳輸應該是非同步的。可以使用文件來傳輸、或者使用面向消息的（MoM）中間件來實現。由於數據非同步傳輸，所以數據採集過程的吞吐量可以大大高於大數據系統的處理能力。 非同步數據傳輸同樣可以在大數據系統和不同的數據源之間進行解耦。大數據基礎架構設計使得其很容易進行動態伸縮，數據採集的峰值流量對於大數據系統來說算是安全的。
如果數據是直接從一些外部資料庫中抽取的，確保拉取數據是使用批量的方式。
如果數據是從feed file解析，請務必使用合適的解析器。例如，如果從一個XML文件中讀取也有不同的解析器像JDOM，SAX，DOM等。類似地，對於CSV，JSON和其它這樣的格式，多個解析器和API是可供選擇。選擇能夠符合需求的性能最好的。
優先使用內置的驗證解決方案。大多數解析/驗證工作流程的通常運行在伺服器環境（ESB /應用伺服器）中。大部分的場景基本上都有現成的標准校驗工具。在大多數的情況下，這些標準的現成的工具一般來說要比你自己開發的工具性能要好很多。
類似地，如果數據XML格式的，優先使用XML（XSD）用於驗證。
即使解析器或者校等流程使用自定義的腳本來完成，例如使用java優先還是應該使用內置的函數庫或者開發框架。在大多數的情況下通常會比你開發任何自定義代碼快得多。
盡量提前濾掉無效數據，以便後續的處理流程都不用在無效數據上浪費過多的計算能力。
大多數系統處理無效數據的做法通常是存放在一個專門的表中，請在系統建設之初考慮這部分的資料庫存儲和其他額外的存儲開銷。
如果來自數據源的數據需要清洗，例如去掉一些不需要的信息，盡量保持所有數據源的抽取程序版本一致，確保一次處理的是一個大批量的數據，而不是一條記錄一條記錄的來處理。一般來說數據清洗需要進行表關聯。數據清洗中需要用到的靜態數據關聯一次，並且一次處理一個很大的批量就能夠大幅提高數據處理效率。
數據去重非常重要這個過程決定了主鍵的是由哪些欄位構成。通常主鍵都是時間戳或者id等可以追加的類型。一般情況下，每條記錄都可能根據主鍵進行索引來更新，所以最好能夠讓主鍵簡單一些，以保證在更新的時候檢索的性能。
來自多個源接收的數據可以是不同的格式。有時，需要進行數據移植，使接收到的數據從多種格式轉化成一種或一組標准格式。
和解析過程一樣，我們建議使用內置的工具，相比於你自己從零開發的工具性能會提高很多。
數據移植的過程一般是數據處理過程中最復雜、最緊急、消耗資源最多的一步。因此，確保在這一過程中盡可能多的使用並行計算。
一旦所有的數據採集的上述活動完成後，轉換後的數據通常存儲在某些持久層，以便以後分析處理，綜述，聚合等使用。
多種技術解決方案的存在是為了處理這種持久（RDBMS，NoSQL的分布式文件系統，如Hadoop和等）。
謹慎選擇一個能夠最大限度的滿足需求的解決方案。
4. 數據存儲中的性能技巧
一旦所有的數據採集步驟完成後，數據將進入持久層。
在本節中將討論一些與數據數據存儲性能相關的技巧包括物理存儲優化和邏輯存儲結構（數據模型）。這些技巧適用於所有的數據處理過程，無論是一些解析函數生的或最終輸出的數據還是預計算的匯總數據等。
首先選擇數據範式。您對數據的建模方式對性能有直接的影響，例如像數據冗餘，磁碟存儲容量等方面。對於一些簡單的文件導入資料庫中的場景，你也許需要保持數據原始的格式，對於另外一些場景，如執行一些分析計算聚集等，你可能不需要將數據範式化。
大多數的大數據系統使用NoSQL資料庫替代RDBMS處理數據。
不同的NoSQL資料庫適用不同的場景，一部分在select時性能更好，有些是在插入或者更新性能更好。
資料庫分為行存儲和列存儲。
具體的資料庫選型依賴於你的具體需求（例如，你的應用程序的資料庫讀寫比）。
同樣每個資料庫都會根據不同的配置從而控制這些資料庫用於資料庫復制備份或者嚴格保持數據一致性?這些設置會直接影響資料庫性能。在資料庫技術選型前一定要注意。
壓縮率、緩沖池、超時的大小，和緩存的對於不同的NoSQL資料庫來說配置都是不同的，同時對資料庫性能的影響也是不一樣的。
數據Sharding和分區是這些資料庫的另一個非常重要的功能。數據Sharding的方式能夠對系統的性能產生巨大的影響，所以在數據Sharding和分區時請謹慎選擇。
並非所有的NoSQL資料庫都內置了支持連接，排序，匯總，過濾器，索引等。
如果有需要還是建議使用內置的類似功能，因為自己開發的還是不靈。
NoSQLs內置了壓縮、編解碼器和數據移植工具。如果這些可以滿足您的部分需求，那麼優先選擇使用這些內置的功能。這些工具可以執行各種各樣的任務，如格式轉換、壓縮數據等，使用內置的工具不僅能夠帶來更好的性能還可以降低網路的使用率。
許多NoSQL資料庫支持多種類型的文件系統。其中包括本地文件系統，分布式文件系統，甚至基於雲的存儲解決方案。
如果在互動式需求上有嚴格的要求，否則還是盡量嘗試使用NoSQL本地（內置）文件系統（例如HBase 使用HDFS）。
這是因為，如果使用一些外部文件系統/格式，則需要對數據進行相應的編解碼/數據移植。它將在整個讀/寫過程中增加原本不必要的冗餘處理。
大數據系統的數據模型一般來說需要根據需求用例來綜合設計。與此形成鮮明對比的是RDMBS數據建模技術基本都是設計成為一個通用的模型，用外鍵和表之間的關系用來描述數據實體與現實世界之間的交互。
在硬體一級，本地RAID模式也許不太適用。請考慮使用SAN存儲。
5. 數據處理分析中的性能技巧
數據處理和分析是一個大數據系統的核心。像聚合，預測，聚集，和其它這樣的邏輯操作都需要在這一步完成。
本節討論一些數據處理性能方面的技巧。需要注意的是大數據系統架構有兩個組成部分，實時數據流處理和批量數據處理。本節涵蓋數據處理的各個方面。
在細節評估和數據格式和模型後選擇適當的數據處理框架。
其中一些框架適用於批量數據處理，而另外一些適用於實時數據處理。
同樣一些框架使用內存模式，另外一些是基於磁碟io處理模式。
有些框架擅長高度並行計算，這樣能夠大大提高數據效率。
基於內存的框架性能明顯優於基於磁碟io的框架，但是同時成本也可想而知。
概括地說，當務之急是選擇一個能夠滿足需求的框架。否則就有可能既無法滿足功能需求也無法滿足非功能需求，當然也包括性能需求。
一些這些框架將數據劃分成較小的塊。這些小數據塊由各個作業獨立處理。協調器管理所有這些獨立的子作業?在數據分塊是需要當心。
該數據快越小，就會產生越多的作業，這樣就會增加系統初始化作業和清理作業的負擔。
如果數據快太大，數據傳輸可能需要很長時間才能完成。這也可能導致資源利用不均衡，長時間在一台伺服器上運行一個大作業，而其他伺服器就會等待。
不要忘了查看一個任務的作業總數。在必要時調整這個參數。
最好實時監控數據塊的傳輸。在本機機型io的效率會更高，這么做也會帶來一個副作用就是需要將數據塊的冗餘參數提高（一般hadoop默認是3份）這樣又會反作用使得系統性能下降。
此外，實時數據流需要與批量數據處理的結果進行合並。設計系統時盡量減少對其他作業的影響。
大多數情況下同一數據集需要經過多次計算。這種情況可能是由於數據抓取等初始步驟就有報錯，或者某些業務流程發生變化，值得一提的是舊數據也是如此。設計系統時需要注意這個地方的容錯。
這意味著你可能需要存儲原始數據的時間較長，因此需要更多的存儲。
數據結果輸出後應該保存成用戶期望看到的格式。例如，如果最終的結果是用戶要求按照每周的時間序列匯總輸出，那麼你就要將結果以周為單位進行匯總保存。
為了達到這個目標，大數據系統的資料庫建模就要在滿足用例的前提下進行。例如，大數據系統經常會輸出一些結構化的數據表，這樣在展示輸出上就有很大的優勢。
更常見的是，這可能會這將會讓用戶感覺到性能問題。例如用戶只需要上周的數據匯總結果，如果在數據規模較大的時候按照每周來匯總數據，這樣就會大大降低數據處理能力。
一些框架提供了大數據查詢懶評價功能。在數據沒有在其他地方被使用時效果不錯。
實時監控系統的性能，這樣能夠幫助你預估作業的完成時間。
6. 數據可視化和展示中的性能技巧
精心設計的高性能大數據系統通過對數據的深入分析，能夠提供有價值戰略指導。這就是可視化的用武之地。良好的可視化幫助用戶獲取數據的多維度透視視圖。
需要注意的是傳統的BI和報告工具，或用於構建自定義報表系統無法大規模擴展滿足大數據系統的可視化需求。同時，許多COTS可視化工具現已上市。
本文將不會對這些個別工具如何進行調節，而是聚焦在一些通用的技術，幫助您能打造可視化層。
確保可視化層顯示的數據都是從最後的匯總輸出表中取得的數據。這些總結表可以根據時間短進行匯總，建議使用分類或者用例進行匯總。這么做可以避免直接從可視化層讀取整個原始數據。
這不僅最大限度地減少數據傳輸，而且當用戶在線查看在報告時還有助於避免性能卡頓問題。
重分利用大化可視化工具的緩存。緩存可以對可視化層的整體性能產生非常不錯的影響。
物化視圖是可以提高性能的另一個重要的技術。
大部分可視化工具允許通過增加線程數來提高請求響應的速度。如果資源足夠、訪問量較大那麼這是提高系統性能的好辦法。
盡量提前將數據進行預處理，如果一些數據必須在運行時計算請將運行時計算簡化到最小。
可視化工具可以按照各種各樣的展示方法對應不同的讀取策略。其中一些是離線模式、提取模式或者在線連接模式。每種服務模式都是針對不同場景設計的。
同樣，一些工具可以進行增量數據同步。這最大限度地減少了數據傳輸，並將整個可視化過程固化下來。
保持像圖形，圖表等使用最小的尺寸。
大多數可視化框架和工具的使用可縮放矢量圖形（SVG）。使用SVG復雜的布局可能會產生嚴重的性能影響。
7. 數據安全以及對於性能的影響
像任何IT系統一樣安全性要求也對大數據系統的性能有很大的影響。在本節中，我們討論一下安全對大數據平台性能的影響。
- 首先確保所有的數據源都是經過認證的。即使所有的數據源都是安全的，並且沒有針對安全方面的需求，那麼你可以靈活設計一個安全模塊來配置實現。
- 數據進過一次認證，那麼就不要進行二次認證。如果實在需要進行二次認證，那麼使用一些類似於token的技術保存下來以便後續繼續使用。這將節省數據一遍遍認證的開銷。
- 您可能需要支持其他的認證方式，例如基於PKI解決方案或Kerberos。每一個都有不同的性能指標，在最終方案確定前需要將其考慮進去。
- 通常情況下數據壓縮後進入大數據處理系統。這么做好處非常明顯不細說。
- 針對不同演算法的效率、對cpu的使用量你需要進行比較來選出一個傳輸量、cpu使用量等方面均衡的壓縮演算法。
- 同樣，評估加密邏輯和演算法，然後再選擇。
- 明智的做法是敏感信息始終進行限制。
- 在審計跟蹤表或登錄時您可能需要維護記錄或類似的訪問，更新等不同的活動記錄。這可能需要根據不同的監管策略和用戶需求個性化的進行設計和修改。
- 注意，這種需求不僅增加了數據處理的復雜度，但會增加存儲成本。
- 盡量使用下層提供的安全技術，例如操作系統、資料庫等。這些安全解決方案會比你自己設計開發性能要好很多。
8. 總結
本文介紹了各種性能方面的技巧，這些技術性的知道可以作為打造大數據分析平台的一般准則。大數據分析平台非常復雜，為了滿足這種類型系統的性能需求，需要我們從開始建設的時候進行考量。
本文介紹的技術准則可以用在大數據平台建設的各個不同階段，包括安全如何影響大數據分析平台的性能。
G. 如何搭建基於Hadoop的大數據平台
Hadoop: 一個開源的分布式存儲、分布式計算平台.（基於Apache）
Hadoop的組成：
HDFS:分布式文件系統，存儲海量的數據。
MapRece:並行處理框架，實現任務分解和調度。
Hadoop的用處：
搭建大型數據倉庫，PB級數據的存儲、處理、分析、統計等業務。
比如搜索引擎、網頁的數據處理，各種商業智能、風險評估、預警，還有一些日誌的分析、數據挖掘的任務。
Hadoop優勢：高擴展、低成本、成熟的生態圈(Hadoop Ecosystem Map)
Hadoop開源工具：
Hive：將SQL語句轉換成一個hadoop任務去執行，降低了使用Hadoop的門檻。
HBase:存儲結構化數據的分布式資料庫，habase提供數據的隨機讀寫和實時訪問，實現 對表數據的讀寫功能。
zookeeper:就像動物管理員一樣，監控hadoop集群裡面每個節點的狀態，管理整個集群 的配置，維護節點針之間數據的一次性等等。
hadoop的版本盡量選穩定版本，即較老版本。
===============================================
Hadoop的安裝與配置：
1）在Linux中安裝JDK，並設置環境變數
安裝jdk: >> sudo apt-get install openjdk-7-jdk
設置環境變數：
>> vim /etc/profile
>> :wq
2)下載Hadoop,並設置Hadoop環境變數
下載hadoop解壓縮:
>> cd /opt/hadoop-1.2.1/
>> ls
>> vim /etc/profile
>>:wq
3）修改4個配置文件
（a）修改hadoop-env.sh,設置JAVA_HOME
（b）修改core-site.xml,設置hadoop.tmp.dir, dfs.name.dir, fs.default.name
（c）修改mapred-site.xml, 設置mapred.job.tracker
（d）修改hdfs-site.xml,設置dfs.data.dir
>> cd conf
>> ls
>> vim mapred-site.xml
>> :wq
>> vim core-site.xml
第一部分
第二部分
>> :wq
>> vim hdfs-site.xml
>> :wq
>> vim hadoop-env.sh
>> :wq
# hadoop格式化
>> hadoop namenode -format
# hadoop啟動
>> start-all.sh
# 通過jps命令查看當前運行進程
>> jps
看見以下進程即說明hadoop安裝成功
H. 大數據集群
大數據（big data），指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。
魔方（大數據模型平台）
大數據模型平台是一款基於服務匯流排與分布式雲計算兩大技術架構的一款數據分析、挖掘的工具平台，其採用分布式文件系統對數據進行存儲，支持海量數據的處理。採用多種的數據採集技術，支持結構化數據及非結構化數據的採集。通過圖形化的模型搭建工具，支持流程化的模型配置。通過第三方插件技術，很容易將其他工具及服務集成到平台中去。數據分析研判平台就是海量信息的採集，數據模型的搭建，數據的挖掘、分析最後形成知識服務於實戰、服務於決策的過程，平台主要包括數據採集部分，模型配置部分，模型執行部分及成果展示部分等。
大數據平台數據抽取工具
大數據平台數據抽取工具實現db到hdfs數據導入功能，藉助Hadoop提供高效的集群分布式並行處理能力，可以採用資料庫分區、按欄位分區、分頁方式並行批處理抽取db數據到hdfs文件系統中，能有效解決大數據傳統抽取導致的作業負載過大抽取時間過長的問題，為大數據倉庫提供傳輸管道。數據處理伺服器為每個作業分配獨立的作業任務處理工作線程和任務執行隊列，作業之間互不幹擾靈活的作業任務處理模式：可以增量方式執行作業任務，可配置的任務處理時間策略，根據不同需求定製。採用非同步事件驅動模式來管理和分發作業指令、採集作業狀態數據。通過管理監控端，可以實時監控作業在各個數據處理節點作業任務的實時運行狀態，查看作業的歷史執行狀態，方便地實現提交新的作業、重新執行作業、停止正在執行的作業等操作。
互聯網數據採集工具
網路信息雷達是一款網路信息定向採集產品，它能夠對用戶設置的網站進行數據採集和更新，實現靈活的網路數據採集目標，為互聯網數據分析提供基礎。
未至·雲（互聯網推送服務平台）
雲計算數據中心以先進的中文數據處理和海量數據支撐為技術基礎，並在各個環節輔以人工服務，使得數據中心能夠安全、高效運行。根據雲計算數據中心的不同環節，我們專門配備了系統管理和維護人員、數據加工和編撰人員、數據採集維護人員、平台系統管理員、機構管理員、輿情監測和分析人員等，滿足各個環節的需要。面向用戶我們提供面向政府和面向企業的解決方案。
顯微鏡（大數據文本挖掘工具）
文本挖掘是指從文本數據中抽取有價值的信息和知識的計算機處理技術, 包括文本分類、文本聚類、信息抽取、實體識別、關鍵詞標引、摘要等。基於Hadoop MapRece的文本挖掘軟體能夠實現海量文本的挖掘分析。CKM的一個重要應用領域為智能比對, 在專利新穎性評價、科技查新、文檔查重、版權保護、稿件溯源等領域都有著廣泛的應用。
數據立方（可視化關系挖掘）
大數據可視化關系挖掘的展現方式包括關系圖、時間軸、分析圖表、列表等多種表達方式，為使用者提供全方位的信息展現方式。
I. 大數據分析系統平台方案有哪些
目前常用的大數據解決方案包括以下幾類
一、Hadoop。Hadoop 是一個能夠對大量數據進行分布式處理的軟體框架。但是 Hadoop 是以一種可靠、高效、可伸縮的方式進行處理的。此外，Hadoop 依賴於社區伺服器，因此它的成本比較低，任何人都可以使用。
二、HPCC。HPCC，High Performance Computing and Communications(高性能計算與通信)的縮寫。HPCC主要目標要達到：開發可擴展的計算系統及相關軟體，以支持太位級網路傳輸性能，開發千兆 比特網路技術，擴展研究和教育機構及網路連接能力。
三、Storm。Storm是自由的開源軟體，一個分布式的、容錯的實時計算系統。Storm可以非常可靠的處理龐大的數據流，用於處理Hadoop的批量數據。 Storm支持許多種編程語言，使用起來非常有趣。Storm由Twitter開源而來
四、Apache Drill。為了幫助企業用戶尋找更為有效、加快Hadoop數據查詢的方法，Apache軟體基金會近日發起了一項名為「Drill」的開源項目。該項目幫助谷歌實現海量數據集的分析處理，包括分析抓取Web文檔、跟蹤安裝在Android Market上的應用程序數據、分析垃圾郵件、分析谷歌分布式構建系統上的測試結果等等。
J. 如何實現企業數據 大數據平台 分布式存放
Hadoop在可伸縮性、健壯性、計算性能和成本上具有無可替代的優勢，事實上已成為當前互聯網企業主流的大數據分析平台。本文主要介紹一種基於Hadoop平台的多維分析和數據挖掘平台架構。作為一家互聯網數據分析公司，我們在海量數據的分析領域那真是被「逼上樑山」。多年來在嚴苛的業務需求和數據壓力下，我們幾乎嘗試了所有可能的大數據分析方法，最終落地於Hadoop平台之上。
1. 大數據分析大分類
Hadoop平台對業務的針對性較強，為了讓你明確它是否符合你的業務，現粗略地從幾個角度將大數據分析的業務需求分類，針對不同的具體需求，應採用不同的數據分析架構。
按照數據分析的實時性，分為實時數據分析和離線數據分析兩種。
實時數據分析一般用於金融、移動和互聯網B2C等產品，往往要求在數秒內返回上億行數據的分析，從而達到不影響用戶體驗的目的。要滿足這樣的需求，可以採用精心設計的傳統關系型資料庫組成並行處理集群，或者採用一些內存計算平台，或者採用HDD的架構，這些無疑都需要比較高的軟硬體成本。目前比較新的海量數據實時分析工具有EMC的Greenplum、SAP的HANA等。
對於大多數反饋時間要求不是那麼嚴苛的應用，比如離線統計分析、機器學習、搜索引擎的反向索引計算、推薦引擎的計算等，應採用離線分析的方式，通過數據採集工具將日誌數據導入專用的分析平台。但面對海量數據，傳統的ETL工具往往徹底失效，主要原因是數據格式轉換的開銷太大，在性能上無法滿足海量數據的採集需求。互聯網企業的海量數據採集工具，有Facebook開源的Scribe、LinkedIn開源的Kafka、淘寶開源的Timetunnel、Hadoop的Chukwa等，均可以滿足每秒數百MB的日誌數據採集和傳輸需求，並將這些數據上載到Hadoop中央系統上。
按照大數據的數據量，分為內存級別、BI級別、海量級別三種。
這里的內存級別指的是數據量不超過集群的內存最大值。不要小看今天內存的容量，Facebook緩存在內存的Memcached中的數據高達320TB，而目前的PC伺服器，內存也可以超過百GB。因此可以採用一些內存資料庫，將熱點數據常駐內存之中，從而取得非常快速的分析能力，非常適合實時分析業務。圖1是一種實際可行的MongoDB分析架構。
圖1 用於實時分析的MongoDB架構
MongoDB大集群目前存在一些穩定性問題，會發生周期性的寫堵塞和主從同步失效，但仍不失為一種潛力十足的可以用於高速數據分析的NoSQL。
此外，目前大多數服務廠商都已經推出了帶4GB以上SSD的解決方案，利用內存+SSD，也可以輕易達到內存分析的性能。隨著SSD的發展，內存數據分析必然能得到更加廣泛的應用。
BI級別指的是那些對於內存來說太大的數據量，但一般可以將其放入傳統的BI產品和專門設計的BI資料庫之中進行分析。目前主流的BI產品都有支持TB級以上的數據分析方案。種類繁多，就不具體列舉了。
海量級別指的是對於資料庫和BI產品已經完全失效或者成本過高的數據量。海量數據級別的優秀企業級產品也有很多，但基於軟硬體的成本原因，目前大多數互聯網企業採用Hadoop的HDFS分布式文件系統來存儲數據，並使用MapRece進行分析。本文稍後將主要介紹Hadoop上基於MapRece的一個多維數據分析平台。
數據分析的演算法復雜度
根據不同的業務需求，數據分析的演算法也差異巨大，而數據分析的演算法復雜度和架構是緊密關聯的。舉個例子，Redis是一個性能非常高的內存Key-Value NoSQL，它支持List和Set、SortedSet等簡單集合，如果你的數據分析需求簡單地通過排序，鏈表就可以解決，同時總的數據量不大於內存（准確地說是內存加上虛擬內存再除以2），那麼無疑使用Redis會達到非常驚人的分析性能。
還有很多易並行問題（Embarrassingly Parallel），計算可以分解成完全獨立的部分，或者很簡單地就能改造出分布式演算法，比如大規模臉部識別、圖形渲染等，這樣的問題自然是使用並行處理集群比較適合。
而大多數統計分析，機器學習問題可以用MapRece演算法改寫。MapRece目前最擅長的計算領域有流量統計、推薦引擎、趨勢分析、用戶行為分析、數據挖掘分類器、分布式索引等。
2. 面對大數據OLAP大一些問題
OLAP分析需要進行大量的數據分組和表間關聯，而這些顯然不是NoSQL和傳統資料庫的強項，往往必須使用特定的針對BI優化的資料庫。比如絕大多數針對BI優化的資料庫採用了列存儲或混合存儲、壓縮、延遲載入、對存儲數據塊的預統計、分片索引等技術。
Hadoop平台上的OLAP分析，同樣存在這個問題，Facebook針對Hive開發的RCFile數據格式，就是採用了上述的一些優化技術，從而達到了較好的數據分析性能。如圖2所示。
然而，對於Hadoop平台來說，單單通過使用Hive模仿出SQL，對於數據分析來說遠遠不夠，首先Hive雖然將HiveQL翻譯MapRece的時候進行了優化，但依然效率低下。多維分析時依然要做事實表和維度表的關聯，維度一多性能必然大幅下降。其次，RCFile的行列混合存儲模式，事實上限制死了數據格式，也就是說數據格式是針對特定分析預先設計好的，一旦分析的業務模型有所改動，海量數據轉換格式的代價是極其巨大的。最後，HiveQL對OLAP業務分析人員依然是非常不友善的，維度和度量才是直接針對業務人員的分析語言。
而且目前OLAP存在的最大問題是：業務靈活多變，必然導致業務模型隨之經常發生變化，而業務維度和度量一旦發生變化，技術人員需要把整個Cube（多維立方體）重新定義並重新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系統成為死板的日常報表系統。
使用Hadoop進行多維分析，首先能解決上述維度難以改變的問題，利用Hadoop中數據非結構化的特徵，採集來的數據本身就是包含大量冗餘信息的。同時也可以將大量冗餘的維度信息整合到事實表中，這樣可以在冗餘維度下靈活地改變問題分析的角度。其次利用Hadoop MapRece強大的並行化處理能力，無論OLAP分析中的維度增加多少，開銷並不顯著增長。換言之，Hadoop可以支持一個巨大無比的Cube，包含了無數你想到或者想不到的維度，而且每次多維分析，都可以支持成千上百個維度，並不會顯著影響分析的性能。
而且目前OLAP存在的最大問題是：業務靈活多變，必然導致業務模型隨之經常發生變化，而業務維度和度量一旦發生變化，技術人員需要把整個Cube（多維立方體）重新定義並重新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系統成為死板的日常報表系統。
3. 一種Hadoop多維分析平台的架構
整個架構由四大部分組成：數據採集模塊、數據冗餘模塊、維度定義模塊、並行分 析模塊。
數據採集模塊採用了Cloudera的Flume，將海量的小日誌文件進行高速傳輸和合並，並能夠確保數據的傳輸安全性。單個collector宕機之後，數據也不會丟失，並能將agent數據自動轉移到其他的colllecter處理，不會影響整個採集系統的運行。如圖5所示。
數據冗餘模塊不是必須的，但如果日誌數據中沒有足夠的維度信息，或者需要比較頻繁地增加維度，則需要定義數據冗餘模塊。通過冗餘維度定義器定義需要冗餘的維度信息和來源（資料庫、文件、內存等），並指定擴展方式，將信息寫入數據日誌中。在海量數據下，數據冗餘模塊往往成為整個系統的瓶頸，建議使用一些比較快的內存NoSQL來冗餘原始數據，並採用盡可能多的節點進行並行冗餘；或者也完全可以在Hadoop中執行批量Map，進行數據格式的轉化。
維度定義模塊是面向業務用戶的前端模塊，用戶通過可視化的定義器從數據日誌中定義維度和度量，並能自動生成一種多維分析語言，同時可以使用可視化的分析器通過GUI執行剛剛定義好的多維分析命令。
並行分析模塊接受用戶提交的多維分析命令，並將通過核心模塊將該命令解析為Map-Rece，提交給Hadoop集群之後，生成報表供報表中心展示。
核心模塊是將多維分析語言轉化為MapRece的解析器，讀取用戶定義的維度和度量，將用戶的多維分析命令翻譯成MapRece程序。核心模塊的具體邏輯如圖6所示。
圖6中根據JobConf參數進行Map和Rece類的拼裝並不復雜，難點是很多實際問題很難通過一個MapRece Job解決，必須通過多個MapRece Job組成工作流（WorkFlow），這里是最需要根據業務進行定製的部分。圖7是一個簡單的MapRece工作流的例子。
MapRece的輸出一般是統計分析的結果，數據量相較於輸入的海量數據會小很多，這樣就可以導入傳統的數據報表產品中進行展現。