在研究、應用機器學習演算法的經歷中，相信大夥兒經常遇到資料集太大、記憶體不夠用的情況。
這引出一系列問題：
有的機器學習工具/庫有預設記憶體設定，比如 weka。這便是乙個限制因素。
對於 weka，你可以在開啟應用時，把記憶體當作乙個引數進行調整。
你真的需要用到全部資料嗎？
可以採集乙個資料的隨機樣本，比如前 1,000 或 100,000 行。在全部資料上訓練最終模型之前（使用漸進式的資料載入技巧），先試著用這個小樣本解決問題。
總的來說，對演算法做快速地抽查、看到結果在前後的變化，在機器學習領域是乙個很好的習慣。
你還可以考慮：相對於模型技巧，做乙個資料大小的敏感性分析。或許，對於你的隨機小樣本，有乙個天然的邊際效應遞減分水嶺。越過這個關口，繼續增加的資料規模帶來的好處微乎其微。
你必須要用 pc 嗎？
你可以考慮記憶體、效能高乙個量級的計算裝置。比如，租用 aws 這樣的雲服務。租用雲端有數十 gb 記憶體的機器，最低**每小時不到一美元。我個人覺得這是非常實際的選擇。
你是否把資料存為原始的 ascii 文字，比如 csv 檔案？
或許，使用其它格式能加速資料載入並且降低記憶體占用。好的選擇包括像 grib、netcdf、hdf 這樣的二進位制格式。
有很多命令列工具能幫你轉換資料格式，而且不需要把整個資料集載入記憶體裡。
換一種格式，可能幫助你以更緊湊的形式儲存資料，節省記憶體空間；比如 2-byte 整數，或者 4-byte 浮點。
你的所有資料，需要同時出現在記憶體裡嗎？
或許，你可以用**或庫，隨時把需要的資料做流式處理或漸進式載入，匯入記憶體裡訓練模型。
這可能需要演算法使用優化技術迭代學習，比如使用隨機梯度下降。那些需要記憶體裡有所有資料、以進行矩陣運算的演算法，比如某些對線性回歸和邏輯回歸的實現，就不適用了。
比如，keras 深度學習 api 就提供了漸進式載入影象檔案的功能，名為 flow_from_directory
另乙個例子式 pandas 庫，可批量載入大型 csv 檔案。
關聯式資料庫為儲存、訪問大型資料集提供了標準化的方法。
在內部，資料存在硬碟中，能漸進式地 in batch 批量載入，並使用標準檢索語言 sql 檢索。
像 mysql、postgres 這樣的開源資料庫工具，支援絕大多數的（全部？）程式語言。許多機器學習工具，都能直接與關聯式資料庫連通。你也可以用 sqlite 這樣更輕量的方法。
我發現，這種方法對大型**式資料集非常有效率。
雷鋒網提醒，你需要用能迭代學習的演算法。
有的情況下，你可能必須要使用大資料平台，即為處理超大型資料集而開發的平台。它們能讓你進行資料轉換，並在其上開發機器學習演算法。
兩個很好的例子是 hadoop 與機器學習庫 mahout，以及 spark 與 mllib 庫。
我認為，這是用盡上述辦法仍無法解決的情況下，才需要採用的最後手段。單純是這為你的機器學習專案所帶來的額外硬體、軟體複雜情況，就會消耗許多精力。
即便如此，有的任務確實資料太過龐大，前面的選項都無法奏效。
比如現在手上有70億＋1份身高資料，如何用有限的4gb記憶體找到這些資料中的中間值（也就是從小到大排列的第35億個人的身高）
粗略計算了一下，4gb／sizeof(double)約等於5億，也就是說無法把這70億份資料同時放入記憶體中進行處理。
求可行的方案（記憶體可以反覆擦寫）
磁碟沒要求的話，桶排序，然後直接找第35億個記錄。
桶排序就是檔案分份然後每乙份快排，排完了堆排。
全排到乙個檔案裡之後，讀乙個數個數，數到中間就輸出。
其實已經有的答案裡開陣列數數是線性時間最優的。
首先，我覺得這個不是大資料的範疇。
對於大量的資料處理，如果使用記憶體有限制（一般在面試題中有更好的表述方式），應該採用的方式有一下幾種：
分而治之/hash對映 + hash統計 + 堆/快速/歸併排序；
雙層桶劃分
bloom filter/bitmap；
trie樹/資料庫/倒排索引；
外排序；
分布式處理之hadoop/mapreduce。
解決20 的大資料問題
乙個採用模組化設計的大資料平台可以解決80 的大資料問題，而解決另外20 的問題就要靠大資料平台廠商結合行業客戶的特殊需求進行定製化開發。中興通訊dap 2.0大資料平台就具備了這方面的能力，能夠為行業客戶帶來實實在在的價值。大資料的本質在於，可以提公升人類活動的準確性，減少傳統方式下的試錯成本，從...
JAVA 匯出Excel大資料記憶體溢位解決方案
最初的匯出用的就是easypoi easypoi官網 簡單方便，當時也沒考慮太多，就圖乙個簡單 後來發生了幾次匯出大資料的時候伺服器直接崩掉，使我不得不注意起來 上網查了一下，基本上就是記憶體溢位的問題 然後發現了乙個比較好的解決方法，就是使用xml規範來匯出excel 首先我們需要知道一下，xml...
大資料處理僅有Hadoop是不夠的
自從三大資料庫廠商甲骨文 ibm和微軟在2011年不約而同地宣布支援hadoop後，在企業級市場上，hadoop基本上也充當著大資料的代名詞。時至今日，這種狀況或許應該改變了。nosql日漸重要 由於hadoop的高調，很少有人注意到，在宣布支援hadoop的同一年，這三大關係型資料庫廠商還分別宣布...