幾十T的數據該如何儲存呢？

回答這個問題的關鍵是，“回測和研究會用到這些數據，有一定的查詢需求”。

如果只是存儲50T的數據，有很多種方法：（1）用二進制文件分日期分股票存儲，（2）使用SQL server，pg這樣支持分區表的事務型數據庫，(3）使用hive這樣的離線數據倉庫,（4）用Greenplum這樣的開源或商業MPP數據倉庫，（5）kdb+和DolphinDB這樣的專業時序數據庫。

選擇一種合適的存儲方法是為了更好的讀取和利用這些數據。一般需要考慮以下幾個方面的問題：

數據開發和建模是不是方便

如果只是簡單按照日期和股票代碼來查詢tick data，基本上所有方法都可以用。（2）和（3）速度會比較慢。（1）需要自己來編程。

如果需要數據過濾，聚合（譬如按時間精度聚合），多表連接，（4）和（5）是最方便的，性能也不錯。

如果需要更為專業的時間序列數據處理和建模，譬如rollup，sliding functions，window function，window join， asof join，pivot等，選（5），用其他系統都不是很方便。

另外說一下，kdb+的學習曲線比較陡峭。

是否需要用到分布式計算

雖然總的數據量很大，但是每次計算的數據量都不大，問題就會簡單很多，基本上5種方法都可以使用。但是如果需要建模的數據量很大，涉及很多天，很多股票，用到的維度又很多，譬如在幾十億行數據上對幾十個上百個變量跑回歸，或者說分區字段和group字段不一致的時候做聚合分析，都會涉及到分布式計算，Greenplum和DolphinDB支持的比較好，支持庫內計算，不需要移動數據，速度很快。其它的存儲方法可以考慮寫一個跟通用計算引擎spark的適配器，然后用spark來實現分布式SQL和分布式機器學習，但性能上會不庫內計算差不少。

開發和建模過程中是否容易引入bug和錯誤

如果自己要寫很多代碼，不僅時間成本很高，而且極易引入錯誤。null數據的處理，多線程的處理，多個數據源的連接都很容易引入bug。

如果涉及到分布式計算，或者需要多次迭代，數據本身有可能是動態變化的，數據的一致性也要注意。一般數據倉庫本身提供的庫內計算，能提供快照級別的隔離，保證計算過程總用到的所有數據是一致的。Greenplum和DolphinDB都支持快照級別隔離。Spark不能工作在動態數據上。

運行效率如何

回測和研究雖然對實時性要求不高，但運行效率還是很重要的。因為研究的成功率很低，嘗試了幾百個想法后，才可能有一個能成功。每個idea測試的時候，你可能需要嘗試很多個參數組合。所以，如果運行效率不高，非常影響研究效率。（5）中的kdb+和DolphinDB無疑是所有方案中效率最高的。

如果是機構商用，你的競爭對手用什么

很多交易策略，尤其是套利類的策略scale可能不是很好，用的人很多了，價格和價值就趨于均衡，機會就沒了。所以你要趕在你的對手之前。

根據你的需求，簡單總結一下，如果沒有太多的預算，建議使用Greenplum + Spark，但是兩者都是通用的數據倉庫和計算引擎，天然缺少時序數據和金融的基因，有些場景用起來不是很方便，一些本來很好的idea，可能因為實現太麻煩就放棄了。如果有足夠的預算，建議使用專業的時序數據庫DolphinDB或kdb+。順便說一下，kdb+對分布式的支持很弱，面對40~50T的數據，你可能要搞一臺非常暴力的服務器才能解決。