回答這個問題的關鍵是，“回測和研究會用到這些資料，有一定的查詢需求”。
如果只是儲存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的資料，你可能要搞一臺非常暴力的伺服器才能解決。
回答這個問題的關鍵是，“回測和研究會用到這些資料，有一定的查詢需求”。
如果只是儲存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的資料，你可能要搞一臺非常暴力的伺服器才能解決。