如果存儲節(jié)點(diǎn)本身可以定制，則通常會讓其支持部分計(jì)算能力，以利用數(shù)據(jù)的親和性，將部分計(jì)算下推到相關(guān)的存儲節(jié)點(diǎn)上。如果存儲是云上的 S3 等對象存儲，無法定制，則通常會將數(shù)據(jù)在計(jì)算節(jié)點(diǎn)緩存，并且盡量的復(fù)用。 參考資料
大概總結(jié)下，主要包括以下角色：
1. 數(shù)據(jù)的源頭與終點(diǎn)
傳統(tǒng)上，無論是基于 MapReduce 的數(shù)據(jù)流，還是基于 Spark/Flink 的流水線，其數(shù)據(jù)的來源和最終落腳點(diǎn)都可以是分布式存儲（比如 GFS、HDFS、S3）。
這是由于分布式存儲通常具有很高的可用性，不太用擔(dān)心數(shù)據(jù)丟失。但從另一方面來說，上面提到的幾種分布式存儲通常不具有數(shù)據(jù)庫中的 Schema，導(dǎo)致在用的時(shí)候，缺少一些靈活性。
當(dāng)然，對于流式系統(tǒng)來說，分布式存儲肯定不是最典型的數(shù)據(jù)來源，而是各種在線的服務(wù)產(chǎn)生的事件。
2. 中間數(shù)據(jù)的落腳點(diǎn)
對于批處理的中間數(shù)據(jù)，如果量過大或者計(jì)算代價(jià)太大，比如 Spark 中的 RDD，會：
- 內(nèi)存裝不下 spill 到分布式存儲中
- 在 shuffle 后，為了避免重算，通常要持久化到分布式存儲系統(tǒng)上一份
即使是如 Flink 之類的流式處理系統(tǒng)，最近也在提存算分開——將中間狀態(tài)外存，計(jì)算才能更好的擴(kuò)縮容。傳統(tǒng)上 Flink 使用了 RocksDB 之類的存儲引擎，將狀態(tài)數(shù)據(jù)存在各個(gè)計(jì)算節(jié)點(diǎn)本地；但為了上云，讓計(jì)算更方便的彈性，也開始尋求將所有中間狀態(tài)與計(jì)算節(jié)點(diǎn)解耦合，存到統(tǒng)一的分布式存儲中。
3. 分布式數(shù)據(jù)庫的基座
隨著數(shù)據(jù)庫本身越來越多的支持分布式部署和計(jì)算，傳統(tǒng)上的大數(shù)據(jù)處理需求，一部分被內(nèi)化為查詢引擎層的分布式計(jì)算。這也是為什么，現(xiàn)代分布式數(shù)據(jù)庫的查詢引擎也多使用 MPP 方式，充分的利用多節(jié)點(diǎn)的計(jì)算能力，在單個(gè)查詢內(nèi)進(jìn)行算子或者流水線粒度的分布式并行執(zhí)行。
在這種情況下，分布式數(shù)據(jù)庫的底層存儲通常為分布式（KV）存儲，且是和計(jì)算分離的（存算分開）。也就是說，數(shù)據(jù)通過查詢引擎層，最終會以 KV 的形式落到分布式存儲中，并供之后的查詢支持。
如果存儲節(jié)點(diǎn)本身可以定制，則通常會讓其支持部分計(jì)算能力，以利用數(shù)據(jù)的親和性，將部分計(jì)算下推到相關(guān)的存儲節(jié)點(diǎn)上。如果存儲是云上的 S3 等對象存儲，無法定制，則通常會將數(shù)據(jù)在計(jì)算節(jié)點(diǎn)緩存，并且盡量的復(fù)用。
參考資料
[1]《系統(tǒng)日知錄》專欄: https://xiaobot.NET/p/system-thinking ，點(diǎn)擊下面閱讀原文跳轉(zhuǎn)訂閱。
