大數據是最近IT界最經常使用的術語之一。然而對大數據的定義也不盡相同,全部已知的論點例如結構化的和非結構化、大規模的數據等等都不夠完整。大數據系統一般被認爲具備數據的五個主要特徵,一般稱爲數據的5 Vs。分別是大規模,多樣性,高效性、準確性和價值性。java
據Gartner稱,大規模能夠被定義爲「在本(地)機數據採集和處理技術能力不足覺得用戶帶來商業價值。當現有的技術可以針對性的進行改造後來處理這種規模的數據就能夠說是一個成功的大數據解決方案。算法
這種大規模的數據沒將不只僅是來自於現有的數據源,同時也會來自於一些新興的數據源,例如常規(手持、工業)設備,日誌,汽車等,固然包括結構化的和非結構化的數據。數據庫
據Gartner稱,多樣性能夠定義以下:「高度變異的信息資產,在生產和消費時不進行嚴格定義的包括多種形式、類型和結構的組合。同時還包括之前的歷史數據,因爲技術的變革歷史數據一樣也成爲多樣性數據之一 「。緩存
高效性能夠被定義爲來自不一樣源的數據到達的速度。從各類設備,傳感器和其餘有組織和無組織的數據流都在不斷進入IT系統。由此,實時分析和對於該數據的解釋(展現)的能力也應該隨之增長。安全
根據Gartner,高效性能夠被定義以下:「高速的數據流I/O(生產和消費),但主要聚焦在一個數據集內或多個數據集之間的數據生產的速率可變上」。性能優化
準確性,或真實性或叫作精度是數據的另外一個重要組成方面。要作出正確的商業決策,當務之急是在數據上進行的全部分析必須是正確和準確(精確)的。服務器
大數據系統能夠提供巨大的商業價值。像電信,金融,電子商務,社交媒體等,已經認識到他們的數據是一個潛在的巨大的商機。他們能夠預測用戶行爲,並推薦相關產品,提供危險交易預警服務,等等。網絡
與其餘IT系統同樣,性能是大數據系統得到成功的關鍵。本文的中心主旨是要說明如何讓大數據系統保證其性能。架構
大數據系統應該包含的功能模塊,首先是可以從多種數據源獲取數據的功能,數據的預處理(例如,清洗,驗證等),存儲數據,數據處理、數據分析等(例如作預測分析,生成在線使用建議等等),最後呈現和可視化的總結、彙總結果。框架
下圖描述了大數據系統的這些高層次的組件:
2.1各類各樣的數據源
當今的IT生態系統,須要對各類不一樣種類來源的數據進行分析。這些來源多是從在線Web應用程序,批量上傳或feed,流媒體直播數據,來自工業、手持、家居傳感的任何東西等等。
顯然從不一樣數據源獲取的數據具備不一樣的格式、使用不一樣的協議。例如,在線的Web應用程序可能會使用SOAP / XML格式經過HTTP發送數據,feed可能會來自於CSV文件,其餘設備則可能使用MQTT通訊協議。
因爲這些單獨的系統的性能是不在大數據系統的控制範圍以內,而且一般這些系統都是外部應用程序,由第三方供應商或團隊提供並維護,因此本文將不會在深刻到這些系統的性能分析中去。
2.2數據採集
第一步,獲取數據。這個過程包括分析,驗證,清洗,轉換,去重,而後存到適合大家公司的一個持久化設備中(硬盤、存儲、雲等)。
在下面的章節中,本文將重點介紹一些關於如何獲取數據方面的很是重要的技巧。請注意,本文將不討論各類數據採集技術的優缺點。
2.3存儲數據
第二步,一旦數據進入大數據系統,清洗,並轉化爲所需格式時,這些過程都將在數據存儲到一個合適的持久化層中進行。
在下面的章節中,本文將介紹一些存儲方面的最佳實踐(包括邏輯上和物理上)。在本文結尾也會討論一部分涉及數據安全方面的問題。
2.4數據處理和分析
第三步,在這一階段中的一部分乾淨數據是去規範化的,包括對一些相關的數據集的數據進行一些排序,在規定的時間間隔內進行數據結果歸集,執行機器學習算法,預測分析等。
在下面的章節中,本文將針對大數據系統性能優化介紹一些進行數據處理和分析的最佳實踐。
2.5數據的可視化和數據展現
最後一個步驟,展現通過各個不一樣分析算法處理過的數據結果。該步驟包括從預先計算彙總的結果(或其餘相似數據集)中的讀取和用一種友好界面或者表格(圖表等等)的形式展現出來。這樣便於對於數據分析結果的理解。
數據採集是各類來自不一樣數據源的數據進入大數據系統的第一步。這個步驟的性能將會直接決定在一個給定的時間段內大數據系統可以處理的數據量的能力。
數據採集過程基於對該系統的個性化需求,但一些經常使用執行的步驟是 – 解析傳入數據,作必要的驗證,數據清晰,例如數據去重,轉換格式,並將其存儲到某種持久層。
涉及數據採集過程的邏輯步驟示以下圖所示:
下面是一些性能方面的技巧:
來自不一樣數據源的傳輸應該是異步的。可使用文件來傳輸、或者使用面向消息的(MoM)中間件來實現。因爲數據異步傳輸,因此數據採集過程的吞吐量能夠大大高於大數據系統的處理能力。 異步數據傳輸一樣能夠在大數據系統和不一樣的數據源之間進行解耦。大數據基礎架構設計使得其很容易進行動態伸縮,數據採集的峯值流量對於大數據系統來講算是安全的。
若是數據是直接從一些外部數據庫中抽取的,確保拉取數據是使用批量的方式。
若是數據是從feed file解析,請務必使用合適的解析器。例如,若是從一個XML文件中讀取也有不一樣的解析器像JDOM,SAX,DOM等。相似地,對於CSV,JSON和其它這樣的格式,多個解析器和API是可供選擇。選擇可以符合需求的性能最好的。
優先使用內置的驗證解決方案。大多數解析/驗證工做流程的一般運行在服務器環境(ESB /應用服務器)中。大部分的場景基本上都有現成的標準校驗工具。在大多數的狀況下,這些標準的現成的工具通常來講要比你本身開發的工具性能要好不少。
相似地,若是數據XML格式的,優先使用XML(XSD)用於驗證。
即便解析器或者校等流程使用自定義的腳原本完成,例如使用java優先仍是應該使用內置的函數庫或者開發框架。在大多數的狀況下一般會比你開發任何自定義代碼快得多。
儘可能提早濾掉無效數據,以便後續的處理流程都不用在無效數據上浪費過多的計算能力。
大多數系統處理無效數據的作法一般是存放在一個專門的表中,請在系統建設之初考慮這部分的數據庫存儲和其餘額外的存儲開銷。
若是來自數據源的數據須要清洗,例如去掉一些不須要的信息,儘可能保持全部數據源的抽取程序版本一致,確保一次處理的是一個大批量的數據,而不是一條記錄一條記錄的來處理。通常來講數據清洗須要進行表關聯。數據清洗中須要用到的靜態數據關聯一次,而且一次處理一個很大的批量就可以大幅提升數據處理效率。
數據去重很是重要這個過程決定了主鍵的是由哪些字段構成。一般主鍵都是時間戳或者id等能夠追加的類型。通常狀況下,每條記錄均可能根據主鍵進行索引來更新,因此最好可以讓主鍵簡單一些,以保證在更新的時候檢索的性能。
來自多個源接收的數據能夠是不一樣的格式。有時,須要進行數據移植,使接收到的數據從多種格式轉化成一種或一組標準格式。
和解析過程同樣,咱們建議使用內置的工具,相比於你本身從零開發的工具性能會提升不少。
數據移植的過程通常是數據處理過程當中最複雜、最緊急、消耗資源最多的一步。所以,確保在這一過程當中儘量多的使用並行計算。
一旦全部的數據採集的上述活動完成後,轉換後的數據一般存儲在某些持久層,以便之後分析處理,綜述,聚合等使用。
多種技術解決方案的存在是爲了處理這種持久(RDBMS,NoSQL的分佈式文件系統,如Hadoop和等)。
謹慎選擇一個可以最大限度的知足需求的解決方案。
一旦全部的數據採集步驟完成後,數據將進入持久層。
在本節中將討論一些與數據數據存儲性能相關的技巧包括物理存儲優化和邏輯存儲結構(數據模型)。這些技巧適用於全部的數據處理過程,不管是一些解析函數生的或最終輸出的數據仍是預計算的彙總數據等。
首先選擇數據範式。您對數據的建模方式對性能有直接的影響,例如像數據冗餘,磁盤存儲容量等方面。對於一些簡單的文件導入數據庫中的場景,你也許須要保持數據原始的格式,對於另一些場景,如執行一些分析計算彙集等,你可能不須要將數據範式化。
大多數的大數據系統使用NoSQL數據庫替代RDBMS處理數據。
不一樣的NoSQL數據庫適用不一樣的場景,一部分在select時性能更好,有些是在插入或者更新性能更好。
數據庫分爲行存儲和列存儲。
具體的數據庫選型依賴於你的具體需求(例如,你的應用程序的數據庫讀寫比)。
一樣每一個數據庫都會根據不一樣的配置從而控制這些數據庫用於數據庫複製備份或者嚴格保持數據一致性。
這些設置會直接影響數據庫性能。在數據庫技術選型前必定要注意。
壓縮率、緩衝池、超時的大小,和緩存的對於不一樣的NoSQL數據庫來講配置都是不一樣的,同時對數據庫性能的影響也是不同的。
數據Sharding和分區是這些數據庫的另外一個很是重要的功能。數據Sharding的方式可以對系統的性能產生巨大的影響,因此在數據Sharding和分區時請謹慎選擇。
並不是全部的NoSQL數據庫都內置了支持鏈接,排序,彙總,過濾器,索引等。
若是有須要仍是建議使用內置的相似功能,由於本身開發的仍是不靈。
NoSQLs內置了壓縮、編解碼器和數據移植工具。若是這些能夠知足您的部分需求,那麼優先選擇使用這些內置的功能。這些工具能夠執行各類各樣的任務,如格式轉換、壓縮數據等,使用內置的工具不只可以帶來更好的性能還能夠下降網絡的使用率。
許多NoSQL數據庫支持多種類型的文件系統。其中包括本地文件系統,分佈式文件系統,甚至基於雲的存儲解決方案。
若是在交互式需求上有嚴格的要求,不然仍是儘可能嘗試使用NoSQL本地(內置)文件系統(例如HBase 使用HDFS)。
這是由於,若是使用一些外部文件系統/格式,則須要對數據進行相應的編解碼/數據移植。它將在整個讀/寫過程當中增長本來沒必要要的冗餘處理。
大數據系統的數據模型通常來講須要根據需求用例來綜合設計。與此造成鮮明對比的是RDMBS數據建模技術基本都是設計成爲一個通用的模型,用外鍵和表之間的關係用來描述數據實體與現實世界之間的交互。
在硬件一級,本地RAID模式也許不太適用。請考慮使用SAN存儲。
數據處理和分析是一個大數據系統的核心。像聚合,預測,彙集,和其它這樣的邏輯操做都須要在這一步完成。
本節討論一些數據處理性能方面的技巧。須要注意的是大數據系統架構有兩個組成部分,實時數據流處理和批量數據處理。本節涵蓋數據處理的各個方面。
在細節評估和數據格式和模型後選擇適當的數據處理框架。
其中一些框架適用於批量數據處理,而另一些適用於實時數據處理。
一樣一些框架使用內存模式,另一些是基於磁盤io處理模式。
有些框架擅長高度並行計算,這樣可以大大提升數據效率。
基於內存的框架性能明顯優於基於磁盤io的框架,可是同時成本也可想而知。
歸納地說,當務之急是選擇一個可以知足需求的框架。不然就有可能既沒法知足功能需求也沒法知足非功能需求,固然也包括性能需求。
一些這些框架將數據劃分紅較小的塊。這些小數據塊由各個做業獨立處理。協調器管理全部這些獨立的子做業
在數據分塊是須要小心。
該數據快越小,就會產生越多的做業,這樣就會增長系統初始化做業和清理做業的負擔。
若是數據快太大,數據傳輸可能須要很長時間才能完成。這也可能致使資源利用不均衡,長時間在一臺服務器上運行一個大做業,而其餘服務器就會等待。
不要忘了查看一個任務的做業總數。在必要時調整這個參數。
最好實時監控數據塊的傳輸。在本機機型io的效率會更高,這麼作也會帶來一個反作用就是須要將數據塊的冗餘參數提升(通常hadoop默認是3份)這樣又會副作用使得系統性能降低。
此外,實時數據流須要與批量數據處理的結果進行合併。設計系統時儘可能減小對其餘做業的影響。
大多數狀況下同一數據集須要通過屢次計算。這種狀況多是因爲數據抓取等初始步驟就有報錯,或者某些業務流程發生變化,值得一提的是舊數據也是如此。設計系統時須要注意這個地方的容錯。
這意味着你可能須要存儲原始數據的時間較長,所以須要更多的存儲。
數據結果輸出後應該保存成用戶指望看到的格式。例如,若是最終的結果是用戶要求按照每週的時間序列彙總輸出,那麼你就要將結果以周爲單位進行彙總保存。
爲了達到這個目標,大數據系統的數據庫建模就要在知足用例的前提下進行。例如,大數據系統常常會輸出一些結構化的數據表,這樣在展現輸出上就有很大的優點。
更常見的是,這可能會這將會讓用戶感受到性能問題。例如用戶只須要上週的數據彙總結果,若是在數據規模較大的時候按照每週來彙總數據,這樣就會大大下降數據處理能力。
一些框架提供了大數據查詢懶評價功能。在數據沒有在其餘地方被使用時效果不錯。
實時監控系統的性能,這樣可以幫助你預估做業的完成時間。
精心設計的高性能大數據系統經過對數據的深刻分析,可以提供有價值戰略指導。這就是可視化的用武之地。良好的可視化幫助用戶獲取數據的多維度透視視圖。
須要注意的是傳統的BI和報告工具,或用於構建自定義報表系統沒法大規模擴展知足大數據系統的可視化需求。同時,許多COTS可視化工具現已上市。
本文將不會對這些個別工具如何進行調節,而是聚焦在一些通用的技術,幫助您能打造可視化層。
確保可視化層顯示的數據都是從最後的彙總輸出表中取得的數據。這些總結表能夠根據時間短進行彙總,建議使用分類或者用例進行彙總。這麼作能夠避免直接從可視化層讀取整個原始數據。
這不只最大限度地減小數據傳輸,並且當用戶在線查看在報告時還有助於避免性能卡頓問題。
重分利用大化可視化工具的緩存。緩存能夠對可視化層的總體性能產生很是不錯的影響。
物化視圖是能夠提升性能的另外一個重要的技術。
大部分可視化工具容許經過增長線程數來提升請求響應的速度。若是資源足夠、訪問量較大那麼這是提升系統性能的好辦法。
儘可能提早將數據進行預處理,若是一些數據必須在運行時計算請將運行時計算簡化到最小。
可視化工具能夠按照各類各樣的展現方法對應不一樣的讀取策略。其中一些是離線模式、提取模式或者在線鏈接模式。每種服務模式都是針對不一樣場景設計的。
一樣,一些工具能夠進行增量數據同步。這最大限度地減小了數據傳輸,並將整個可視化過程固化下來。
保持像圖形,圖表等使用最小的尺寸。
大多數可視化框架和工具的使用可縮放矢量圖形(SVG)。使用SVG複雜的佈局可能會產生嚴重的性能影響。
像任何IT系統同樣安全性要求也對大數據系統的性能有很大的影響。在本節中,咱們討論一下安全對大數據平臺性能的影響。
首先確保全部的數據源都是通過認證的。即便全部的數據源都是安全的,而且沒有針對安全方面的需求,那麼你能夠靈活設計一個安全模塊來配置實現。
數據進過一次認證,那麼就不要進行二次認證。若是實在須要進行二次認證,那麼使用一些相似於token的技術保存下來以便後續繼續使用。這將節省數據一遍遍認證的開銷。
您可能須要支持其餘的認證方式,例如基於PKI解決方案或Kerberos。每個都有不一樣的性能指標,在最終方案肯定前須要將其考慮進去。
一般狀況下數據壓縮後進入大數據處理系統。這麼作好處很是明顯不細說。
針對不一樣算法的效率、對cpu的使用量你須要進行比較來選出一個傳輸量、cpu使用量等方面均衡的壓縮算法。
一樣,評估加密邏輯和算法,而後再選擇。
明智的作法是敏感信息始終進行限制。
在審計跟蹤表或登陸時您可能須要維護記錄或相似的訪問,更新等不一樣的活動記錄。這可能須要根據不一樣的監管策略和用戶需求個性化的進行設計和修改。
注意,這種需求不只增長了數據處理的複雜度,但會增長存儲成本。
儘可能使用下層提供的安全技術,例如操做系統、數據庫等。這些安全解決方案會比你本身設計開發性能要好不少。
本文介紹了各類性能方面的技巧,這些技術性的知道能夠做爲打造大數據分析平臺的通常準則。大數據分析平臺很是複雜,爲了知足這種類型系統的性能需求,須要咱們從開始建設的時候進行考量。