前面已經說過，大數據實時分析平臺主要解決企業海量多樣化數據的采集、存儲與計算處理。與其他IT系統一樣，性能是大數據系統獲得成功的關鍵。下面將介紹如何讓大數據系統保證其性能。
大數據系統應該包含的功能模塊，首先是能夠從多種數據源獲取數據的功能，數據的預處理（例如，清洗，驗證等），存儲數據，數據處理、數據分析等（例如做預測分析，生成在線使用建議等等），最后呈現總結、匯總結果。

數據采集
第一步，獲取數據。這個過程包括分析，驗證，清洗，轉換，去重，然后存到適合你們公司的一個持久化設備中（硬盤、存儲、云等）。
存儲數據
第二步，一旦數據進入大數據系統，清洗，并轉化為所需格式時，這些過程都將在數據存儲到一個合適的持久化層中進行。
數據處理和分析
第三步，在這一階段中的一部分干凈數據是去規范化的，包括對一些相關的數據集的數據進行一些排序，在規定的時間間隔內進行數據結果歸集，執行機器學習算法，預測分析等。

下面將針對如何打造高效的大數據系統介紹一些最佳實踐。
保障數據采集中的高效之道
數據采集是各種來自不同數據源的數據進入大數據系統的第一步。這個步驟的性能將會直接決定在一個給定的時間段內大數據系統能夠處理的數據量的能力。
數據采集過程基于對該系統的個性化需求，但一些常用執行的步驟是 - 解析傳入數據，做必要的驗證，數據清晰，例如數據去重，轉換格式，并將其存儲到某種持久層。
下面是一些性能方面的技巧：
●來自不同數據源的傳輸應該是異步的。可以使用文件來傳輸、或者使用面向消息的（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份）這樣又會反作用使得系統性能下降。
●此外，實時數據流需要與批量數據處理的結果進行合并。設計系統時盡量減少對其他作業的影響。
●大多數情況下同一數據集需要經過多次計算。這種情況可能是由于數據抓取等初始步驟就有報錯，或者某些業務流程發生變化，值得一提的是舊數據也是如此。設計系統時需要注意這個地方的容錯。
●這意味著你可能需要存儲原始數據的時間較長，因此需要更多的存儲。
●數據結果輸出后應該保存成用戶期望看到的格式。例如，如果最終的結果是用戶要求按照每周的時間序列匯總輸出，那么你就要將結果以周為單位進行匯總保存。
●為了達到這個目標，大數據系統的數據庫建模就要在滿足用例的前提下進行。例如，大數據系統經常會輸出一些結構化的數據表，這樣在展示輸出上就有很大的優勢。
●更常見的是，這可能會這將會讓用戶感覺到性能問題。例如用戶只需要上周的數據匯總結果，如果在數據規模較大的時候按照每周來匯總數據，這樣就會大大降低數據處理能力。
●一些框架提供了大數據查詢懶評價功能。在數據沒有在其他地方被使用時效果不錯。
●實時監控系統的性能，這樣能夠幫助你預估作業的完成時間。