大概總結(jié)下，主要包括以下角色：

1. 數(shù)據(jù)的源頭與終點(diǎn)

傳統(tǒng)上，無論是基于 MapReduce 的數(shù)據(jù)流，還是基于 Spark/Flink 的流水線，其數(shù)據(jù)的來源和最終落腳點(diǎn)都可以是分布式存儲(chǔ)（比如 GFS、HDFS、S3）。

這是由于分布式存儲(chǔ)通常具有很高的可用性，不太用擔(dān)心數(shù)據(jù)丟失。但從另一方面來說，上面提到的幾種分布式存儲(chǔ)通常不具有數(shù)據(jù)庫中的 Schema，導(dǎo)致在用的時(shí)候，缺少一些靈活性。

當(dāng)然，對(duì)于流式系統(tǒng)來說，分布式存儲(chǔ)肯定不是最典型的數(shù)據(jù)來源，而是各種在線的服務(wù)產(chǎn)生的事件。

2. 中間數(shù)據(jù)的落腳點(diǎn)

對(duì)于批處理的中間數(shù)據(jù)，如果量過大或者計(jì)算代價(jià)太大，比如 Spark 中的 RDD，會(huì)：

1. 內(nèi)存裝不下 spill 到分布式存儲(chǔ)中
2. 在 shuffle 后，為了避免重算，通常要持久化到分布式存儲(chǔ)系統(tǒng)上一份

即使是如 Flink 之類的流式處理系統(tǒng)，最近也在提存算分開——將中間狀態(tài)外存，計(jì)算才能更好的擴(kuò)縮容。傳統(tǒng)上 Flink 使用了 RocksDB 之類的存儲(chǔ)引擎，將狀態(tài)數(shù)據(jù)存在各個(gè)計(jì)算節(jié)點(diǎn)本地；但為了上云，讓計(jì)算更方便的彈性，也開始尋求將所有中間狀態(tài)與計(jì)算節(jié)點(diǎn)解耦合，存到統(tǒng)一的分布式存儲(chǔ)中。

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ù)庫的底層存儲(chǔ)通常為分布式（KV）存儲(chǔ)，且是和計(jì)算分離的（存算分開）。也就是說，數(shù)據(jù)通過查詢引擎層，最終會(huì)以 KV 的形式落到分布式存儲(chǔ)中，并供之后的查詢支持。

如果存儲(chǔ)節(jié)點(diǎn)本身可以定制，則通常會(huì)讓其支持部分計(jì)算能力，以利用數(shù)據(jù)的親和性，將部分計(jì)算下推到相關(guān)的存儲(chǔ)節(jié)點(diǎn)上。如果存儲(chǔ)是云上的 S3 等對(duì)象存儲(chǔ)，無法定制，則通常會(huì)將數(shù)據(jù)在計(jì)算節(jié)點(diǎn)緩存，并且盡量的復(fù)用。

參考資料

[1]《系統(tǒng)日知錄》專欄: https://xiaobot.net/p/system-thinking ，點(diǎn)擊下面閱讀原文跳轉(zhuǎn)訂閱。