大量數據量怎麼處理

『壹』 如果伺服器傳過來的數據量過大，怎麼處理

說白了就是伺服器的承受能力。 第一，確認伺服器硬體是否足夠支持當前的流量。
普通的P4伺服器一般最多能支持每天10萬獨立IP，如果訪問量比這個還要大，那麼必須首先配置一台更高性能的專用伺服器才能解決問題，否則怎麼優化都不可能徹底解決性能問題。

第二，優化資料庫訪問。
伺服器的負載過大，一個重要的原因是CPU負荷過大，降低伺服器CPU的負荷，才能夠有效打破瓶頸。而使用靜態頁面可以使得CPU的負荷最小化。前台實現完全的靜態化當然最好，可以完全不用訪問資料庫，不過對於頻繁更新的網站，靜態化往往不能滿足某些功能。
緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問資料庫，WordPress和Z-Blog都大量使用這種緩存技術。我自己也寫過一個Z-Blog的計數器插件，也是基於這樣的原理。
如果確實無法避免對資料庫的訪問，那麼可以嘗試優化資料庫的查詢SQL.避免使用Select *from這樣的語句，每次查詢只返回自己需要的結果，避免短時間內的大量SQL查詢。

第三，禁止外部的盜鏈。
外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控制盜鏈，Apache自己就可以通過配置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現同樣的功能。當然，偽造refer也可以通過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。

第四，控制大文件的下載。
大文件的下載會佔用很大的流量，並且對於非SCSI硬碟來說，大量文件下載會消耗CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一台伺服器上。目前有不少免費的Web2.0網站提供圖片分享和文件分享功能，因此可以盡量將圖片和文件上傳到這些分享網站。

『貳』 如何處理海量數據

在實際的工作環境下，許多人會遇到海量數據這個復雜而艱巨的問題，它的主要難點有以下幾個方面：
一、數據量過大，數據中什麼情況都可能存在。
如果說有10條數據，那麼大不了每條去逐一檢查，人為處理，如果有上百條數據，也可以考慮，如果數據上到千萬級別，甚至 過億，那不是手工能解決的了，必須通過工具或者程序進行處理，尤其海量的數據中，什麼情況都可能存在，例如，數據中某處格式出了問題，尤其在程序處理時， 前面還能正常處理，突然到了某個地方問題出現了，程序終止了。
二、軟硬體要求高，系統資源佔用率高。
對海量的數據進行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統資源。一般情況，如果處理的數據過TB級，小型機是要考慮的，普通的機子如果有好的方法可以考慮，不過也必須加大CPU和內存，就象面對著千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。
三、要求很高的處理方法和技巧。
這也是本文的寫作目的所在，好的處理方法是一位工程師長期工作經驗的積累，也是個人的經驗的總結。沒有通用的處理方法，但有通用的原理和規則。
下面我們來詳細介紹一下處理海量數據的經驗和技巧：
一、選用優秀的資料庫工具
現在的資料庫工具廠家比較多，對海量數據的處理對所使用的資料庫工具要求比較高，一般使用Oracle或者DB2，微軟 公司最近發布的SQL Server 2005性能也不錯。另外在BI領域：資料庫，數據倉庫，多維資料庫，數據挖掘等相關工具也要進行選擇，象好的ETL工具和好的OLAP工具都十分必要， 例如Informatic，Eassbase等。筆者在實際數據分析項目中，對每天6000萬條的日誌數據進行處理，使用SQL Server 2000需要花費6小時，而使用SQL Server 2005則只需要花費3小時。
二、編寫優良的程序代碼
處理數據離不開優秀的程序代碼，尤其在進行復雜數據處理時，必須使用程序。好的程序代碼對數據的處理至關重要，這不僅僅是數據處理准確度的問題，更是數據處理效率的問題。良好的程序代碼應該包含好的演算法，包含好的處理流程，包含好的效率，包含好的異常處理機制等。
三、對海量數據進行分區操作
對海量數據進行分區操作十分必要，例如針對按年份存取的數據，我們可以按年進行分區，不同的資料庫有不同的分區方式，不 過處理機制大體相同。例如SQL Server的資料庫分區是將不同的數據存於不同的文件組下，而不同的文件組存於不同的磁碟分區下，這樣將數據分散開，減小磁碟I/O，減小了系統負荷， 而且還可以將日誌，索引等放於不同的分區下。
四、建立廣泛的索引
對海量的數據處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等欄位，都要建立相應 索引，一般還可以建立復合索引，對經常插入的表則建立索引時要小心，筆者在處理數據時，曾經在一個ETL流程中，當插入表時，首先刪除索引，然後插入完 畢，建立索引，並實施聚合操作，聚合完成後，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集、非聚集索引都要考慮。
五、建立緩存機制
當數據量增加時，一般的處理工具都要考慮到緩存問題。緩存大小設置的好差也關繫到數據處理的成敗，例如，筆者在處理2億條數據聚合操作時，緩存設置為100000條/Buffer，這對於這個級別的數據量是可行的。
六、加大虛擬內存
如果系統資源有限，內存提示不足，則可以靠增加虛擬內存來解決。筆者在實際項目中曾經遇到針對18億條的數據進行處理， 內存為1GB，1個P42.4G的CPU，對這么大的數據量進行聚合操作是有問題的，提示內存不足，那麼採用了加大虛擬內存的方法來解決，在6塊磁碟分區 上分別建立了6個4096M的磁碟分區，用於虛擬內存，這樣虛擬的內存則增加為 4096*6 + 1024 =25600 M，解決了數據處理中的內存不足問題。
七、分批處理
海量數據處理難因為數據量大，那麼解決海量數據處理難的問題其中一個技巧是減少數據量。可以對海量數據分批處理，然後處 理後的數據再進行合並操作，這樣逐個擊破，有利於小數據量的處理，不至於面對大數據量帶來的問題，不過這種方法也要因時因勢進行，如果不允許拆分數據，還 需要另想辦法。不過一般的數據按天、按月、按年等存儲的，都可以採用先分後合的方法，對數據進行分開處理。
八、使用臨時表和中間表
數據量增加時，處理中要考慮提前匯總。這樣做的目的是化整為零，大表變小表，分塊處理完成後，再利用一定的規則進行合 並，處理過程中的臨時表的使用和中間結果的保存都非常重要，如果對於超海量的數據，大表處理不了，只能拆分為多個小表。如果處理過程中需要多步匯總操作， 可按匯總步驟一步步來，不要一條語句完成，一口氣吃掉一個胖子。
九、優化查詢SQL語句
在對海量數據進行查詢處理過程中，查詢的SQL語句的性能對查詢效率的影響是非常大的，編寫高效優良的SQL腳本和存儲 過程是資料庫工作人員的職責，也是檢驗資料庫工作人員水平的一個標准，在對SQL語句的編寫過程中，例如減少關聯，少用或不用游標，設計好高效的資料庫表 結構等都十分必要。筆者在工作中試著對1億行的數據使用游標，運行3個小時沒有出結果，這是一定要改用程序處理了。
十、使用文本格式進行處理
對一般的數據處理可以使用資料庫，如果對復雜的數據處理，必須藉助程序，那麼在程序操作資料庫和程序操作文本之間選擇， 是一定要選擇程序操作文本的，原因為：程序操作文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等。例如一般的海量的網路日誌都是文本格式或者 csv格式（文本格式），對它進行處理牽扯到數據清洗，是要利用程序進行處理的，而不建議導入資料庫再做清洗。
十一、定製強大的清洗規則和出錯處理機制
海量數據中存在著不一致性，極有可能出現某處的瑕疵。例如，同樣的數據中的時間欄位，有的可能為非標準的時間，出現的原因可能為應用程序的錯誤，系統的錯誤等，這是在進行數據處理時，必須制定強大的數據清洗規則和出錯處理機制。
十二、建立視圖或者物化視圖
視圖中的數據來源於基表，對海量數據的處理，可以將數據按一定的規則分散到各個基表中，查詢或處理過程中可以基於視圖進行，這樣分散了磁碟I/O，正如10根繩子吊著一根柱子和一根吊著一根柱子的區別。
十三、避免使用32位機子（極端情況）
目前的計算機很多都是32位的，那麼編寫的程序對內存的需要便受限制，而很多的海量數據處理是必須大量消耗內存的，這便要求更好性能的機子，其中對位數的限制也十分重要。
十四、考慮操作系統問題
海量數據處理過程中，除了對資料庫，處理程序等要求比較高以外，對操作系統的要求也放到了重要的位置，一般是必須使用伺服器的，而且對系統的安全性和穩定性等要求也比較高。尤其對操作系統自身的緩存機制，臨時空間的處理等問題都需要綜合考慮。
十五、使用數據倉庫和多維資料庫存儲
數據量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鍾，因此處理海量數據的利器是OLAP多維分析，即建立數據倉庫，建立多維數據集，基於多維數據集進行報表展現和數據挖掘等。
十六、使用采樣數據，進行數據挖掘
基於海量數據的數據挖掘正在逐步興起，面對著超海量的數據，一般的挖掘軟體或演算法往往採用數據抽樣的方式進行處理，這樣 的誤差不會很高，大大提高了處理效率和處理的成功率。一般采樣時要注意數據的完整性和，防止過大的偏差。筆者曾經對1億2千萬行的表數據進行采樣，抽取出 400萬行，經測試軟體測試處理的誤差為千分之五，客戶可以接受。
還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因為對數值型的聚合比對字元型的聚合快得多。類似的情況需要針對不同的需求進行處理。
海量數據是發展趨勢，對數據分析和挖掘也越來越重要，從海量數據中提取有用信息重要而緊迫，這便要求處理要准確，精度要高，而且處理時間要短，得到有價值信息要快，所以，對海量數據的研究很有前途，也很值得進行廣泛深入的研究。

『叄』 怎麼快速處理大量數據

假定原數據在SHEET1工作表的ABC列，前兩行為表頭，數據從第3行開始。
轉換結果放在SHEET2工作表中。在SHEET2表A1輸入公式：
=INDEX(SHEET1!B:B,ROW()*5+1)
將公式向下復制。
在SHEET2表B1輸入公式：
=INDEX(SHEET1!$C:$C,ROW()*5-4+COLUMN())
將公式向右復制到F1，再將B至F列公式向下復制。

『肆』 需要處理的數據量太大怎麼處理

解決方案：
1、HTML靜態化
效率最高、消耗最小的就是純靜態化的html頁面，所以盡可能使網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，無法全部手動去挨個實現，於是出現了常見的信息發布系統CMS，像常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
2、圖片伺服器分離
對於Web伺服器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片伺服器，甚至很多台圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為圖片問題而崩潰，在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadMole，保證更高的系統消耗和執行效率。 這一實現起來是比較容易的一現，如果伺服器集群操作起來更方便，如果是獨立的伺服器，新手可能出現上傳圖片只能在伺服器本地的情況下，可以在令一台伺服器設置的IIS採用網路路徑來實現圖片伺服器，即不用改變程序，又能提高性能，但對於伺服器本身的IO處理性能是沒有任何的改變。
3、資料庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是需要使用資料庫集群或者庫表散列。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。

『伍』 如何進行大數據處理

大數據處理之一：收集

大數據的收集是指運用多個資料庫來接收發自客戶端(Web、App或許感測器方式等)的 數據，而且用戶能夠經過這些資料庫來進行簡略的查詢和處理作業，在大數據的收集進程中，其主要特色和應戰是並發數高，因為同時有可能會有成千上萬的用戶 來進行拜訪和操作

大數據處理之二：導入/預處理

雖然收集端本身會有許多資料庫，但是假如要對這些海量數據進行有效的剖析，還是應該將這 些來自前端的數據導入到一個集中的大型分布式資料庫，或許分布式存儲集群，而且能夠在導入基礎上做一些簡略的清洗和預處理作業。導入與預處理進程的特色和應戰主要是導入的數據量大，每秒鍾的導入量經常會到達百兆，甚至千兆等級。

大數據處理之三：核算/剖析

核算與剖析主要運用分布式資料庫，或許分布式核算集群來對存儲於其內的海量數據進行普通 的剖析和分類匯總等，以滿足大多數常見的剖析需求，在這方面，一些實時性需求會用到EMC的GreenPlum、Oracle的Exadata，以及根據 MySQL的列式存儲Infobright等，而一些批處理，或許根據半結構化數據的需求能夠運用Hadoop。 核算與剖析這部分的主要特色和應戰是剖析觸及的數據量大，其對系統資源，特別是I/O會有極大的佔用。

大數據處理之四：發掘

主要是在現有數據上面進行根據各種演算法的核算，然後起到預測(Predict)的作用，然後實現一些高等級數據剖析的需求。主要運用的工具有Hadoop的Mahout等。該進程的特色和應戰主要是用於發掘的演算法很復雜，並 且核算觸及的數據量和核算量都很大，常用數據發掘演算法都以單線程為主。

關於如何進行大數據處理，青藤小編就和您分享到這里了。如果您對大數據工程有濃厚的興趣，希望這篇文章可以為您提供幫助。如果您還想了解更多關於數據分析師、大數據工程師的技巧及素材等內容，可以點擊本站的其他文章進行學習。

『陸』 在做數學建模題時，都有那些方法可以處理大量數據

結合數模培訓和參賽的經驗，可採用數據挖掘中的多元回歸分析，主成分分析、人工神經網路等方法在建模中的一些成功應用。以全國大學生數學建模競賽題為例，數據處理軟體Excel、Spss、Matlab在數學建模中的應用及其重要性。

當需要從定量的角度分析和研究一個實際問題時，人們就要在深入調查研究、了解對象信息、作出簡化假設、分析內在規律等工作的基礎上，用數學的符號和語言作表述來建立數學模型。

數學建模一般應用於高新技術領域和工程領域，對於尋常生活來說，並無很大的應用。而學生參與數學建模的學習和競賽主要是培養學生的數學思維、創新思維、邏輯思維、團隊協作能力和論文寫作技巧等。此外，若能在數學建模中獲獎，有利於本科、研究生等的學校申請。

數學建模的一般過程：模型准備、模型假設、模型建立、模型求解、模型分析、模型檢驗。

數學建模是一種數學的思考方法，是運用數學的語言和方法，把錯綜復雜的實際問題簡化、抽象為合理的數學結構，建立起反映實際問題的數量關系，然後利用數學的理論和方法去分析和解決問題。數學建模是數學來源於生活而有應用與生活的橋梁和紐帶。

『柒』 Python處理大數據的技巧, 2022-06-21

(2022.06.21 Tues)
收集整理了Python處理大量數據的方法，基於Pandas，Numpy等數據處理工具。

用df的 info 方法並指定 memory_usage='deep' 參數，或使用df的 memory_usage 方法，並指定 deep=True 參數。

在讀取數據文件的方法中加入 nrows 參數選擇前n行數據讀取。

也可以跳過m行之後，讀取從m行開始的n行

當然也可以在 skiprows 選項中指定范圍，保留headers，即保留列名

可以指定 skiprows 中需要忽略的行，用list或array導入即可。下面是隨機

如果在這個指令中忽略 nrows=10 指令，則讀取跳過100行之後的所有數據。

預先指定讀入的列，縮小載入范圍

不同的數據類型佔用了不同大小的空間，對於尚未讀取的數據，可以提前指定類型( dtype )；對於已經讀入的數據，通過 astype 方法修改成占空間更小的數據類型。

在讀入數據之前，通過字典指定每列對應的數據類型，讀入之後按照此類型顯示數據。

通過改變數據類型減少空間的案例。修改DataFrame d 中的一列 Sctcd ，注意到該列的數據都是1、2、0，而保存類型是object，果斷改成 uint8 ，通過 df.info(memory_usage='deep') 方法對比內存的使用情況。僅僅修改了一個列的類型，數據大小減小3MB。

一個特殊而高效的案例是當某一列的值只有有限個，不管是int還是string格式，且該列unque值遠小於列的長度，可以將該列轉變為 category 類，將節省大量空間。這么做當然也有代價，比如轉換成 category 類的數據將無法做max/min等運算，由數字轉換成的 category 也不能進行數值運算。這種轉換對內存的節省效果顯著，下面是對比。 dcol 只有兩列， Stkcd 和 Stknme ，查看unique的個數與總長度，顯示unique遠小於總長度，分別轉換為 category 類型，內存節省超過90%！

通過Pandas的 read_csv 方法中的 chunksize 選項指定讀取的塊大小，並迭代地對讀取的塊做運算。

1 https冒號//www點dataquest點io/blog/pandas-big-data/
2 CSDN - python 處理大量數據_如何用python處理大量數據
2 How to Work with BIG Datasets on 16G RAM (+Dask), on kaggle

『捌』 資料庫的數據量達到上千量的時候怎麼處理

一般有以下幾種解決方法：
1、資料庫分離，將數據放在不同的伺服器上，類似，常說的分布式資料庫。
2、定製功能，比如將常訪問的頁生成htm頁，避免直接訪問資料庫，提高訪問速度。
3、另外，盡量用存儲過程。