一個通用的算法流程是這樣的（不區分訓練與推理，有些場景訓練與推理沒有很明確的界限）：
準備輸入文件->算法（讀數據、處理、輸出）->處理輸出文件
這樣的在啓動的時候，需要大量的數據，通常是幾十GB到TB級別的數據，一般是以靜態文件（csv、json格式）提供。算法的輸出文件可能也是這個級別。對於小規模的數據準備來說，問題並不會突出，在數十GB到TB級別大規模的數據吞吐下，需要考慮的因素就比較多了
- 你的數據不是憑空而來，源頭一般是傳統DB（mysql、pg等）或者數倉（hbase、cassandra等），不能因爲某一個算法影響到正常業務訪問，在取數的時候，是否有IO壓力？如果有壓力，取數的流控策略怎麼做？
- 數據可以重複使用嗎？
- 所有數據都要全量拉取嗎？是否可以增量拉取？
問題一，流控
無論是讀數據或者寫數據，流控策略是有必要的。由於當前大部分服務器還是用的機械硬盤，寫壓力一般比讀的壓力大。限制帶寬或者限制qps，這樣可以保證當前工作並不會影響其它正常業務。
當然，流控策略沒有固定的方法，會跟你的業務相關
- 假如業務的確要非常實時，而且數據量又大，那麼看一下你的DB或者數倉的壓榨空間有多大，在這個範圍內，可以儘可能放開流控
- 假如業務實時性要求不高，那麼，在滿足時效的前提下，可以流控可以儘量收緊
問題二，數據可重複使用
如果數據可以重複使用，那麼可以考慮把這部分數據推到對象存儲服務，因爲對象存儲現在已經相當成熟，性價比非常可以，這樣只需要讀取一次數據，然後算法利用多次。
需要注意數據安全的問題：假如你的數據未脫敏或者無法脫敏，那麼還是建議從源頭讀並且用完立即銷燬，如果實在不能從源頭讀，那麼可以考慮加密後再推到對象存儲服務中
問題三，增量處理數據
有一種場景，歷史的數據基本不變，而近期幾天的數據纔會變化，那麼，你的數據就可以按天或者按小時進行切割，切割完之後，增量讀取就成爲可能，因爲歷史的數據，你可以從對象存儲裏面讀取，而不用從源頭讀取。
使用datax作爲從數據同步工具
datax是阿里開源的一個etl數據同步工具，恰好可以提供流控功能，而且支持非常多的數據源，穩定性良好，推薦使用。
支持的數據類型可以參考github的文檔