乙個通用的演算法流程是這樣的（不區分訓練與推理，有些場景訓練與推理沒有很明確的界限）：
準備輸入檔案->演算法（讀資料、處理、輸出）->處理輸出檔案
這樣的在啟動的時候，需要大量的資料，通常是幾十gb到tb級別的資料，一般是以靜態檔案（csv、json格式）提供。演算法的輸出檔案可能也是這個級別。對於小規模的資料準備來說，問題並不會突出，在數十gb到tb級別大規模的資料吞吐下，需要考慮的因素就比較多了
你的資料不是憑空而來，源頭一般是傳統db（mysql、pg等）或者數倉（hbase、cassandra等），不能因為某乙個演算法影響到正常業務訪問，在取數的時候，是否有io壓力？如果有壓力，取數的流控策略怎麼做？
資料可以重複使用嗎？
所有資料都要全量拉取嗎？是否可以增量拉取？
無論是讀資料或者寫資料，流控策略是有必要的。由於當前大部分伺服器還是用的機械硬碟，寫壓力一般比讀的壓力大。限制頻寬或者限制qps，這樣可以保證當前工作並不會影響其它正常業務。
當然，流控策略沒有固定的方法，會跟你的業務相關
如果資料可以重複使用，那麼可以考慮把這部分資料推到物件儲存服務，因為物件儲存現在已經相當成熟，價效比非常可以，這樣只需要讀取一次資料，然後演算法利用多次。
需要注意資料安全的問題：假如你的資料未脫敏或者無法脫敏，那麼還是建議從源頭讀並且用完立即銷毀，如果實在不能從源頭讀，那麼可以考慮加密後再推到物件儲存服務中
有一種場景，歷史的資料基本不變，而近期幾天的資料才會變化，那麼，你的資料就可以按天或者按小時進行切割，切割完之後，增量讀取就成為可能，因為歷史的資料，你可以從物件儲存裡面讀取，而不用從源頭讀取。
datax是阿里開源的乙個etl資料同步工具，恰好可以提供流控功能，而且支援非常多的資料來源，穩定性良好，推薦使用。
支援的資料型別可以參考github的文件
大規模資料作成時的注意點。
有時候測試大規模資料，300萬條。這時有幾點是我們需要注意的。1.對作成的資料，選擇乙個字段設定上特殊的值。通過這個特殊值來判斷表中的資料是這次大規模的測試資料，還是已有資料。同時也方便將來刪除。2.確認資料的有效性。比如，db中有的字段是加密後的字段，程式中會將這個資料解密。如果無法解密則會報錯，...
使用hadoop進行大規模資料的全域性排序
hadoop 某人兒子的乙隻虛擬大象的名字 是乙個複雜到極致，又簡單到極致的東西。說它複雜，是因為乙個hadoop集群往往有幾十台甚至成百上千臺low cost的計算機組成，你執行的每乙個任務都要在這些計算機上做任務的分發，執行中間資料排序以及最後的彙總，期間還包含節點發現，任務的重試，故障節點替換...
使用hadoop進行大規模資料的全域性排序
hadoop 某人兒子的乙隻虛擬大象的名字 是乙個複雜到極致，又簡單到極致的東西。說它複雜，是因為乙個hadoop集群往往有幾十台甚至成百上千臺low cost的計算機組成，你執行的每乙個任務都要在這些計算機上做任務的分發，執行中間資料排序以及最後的彙總，期間還包含節點發現，任務的重試，故障節點替換...