大概總結下，主要包括以下角色：

1. 數據的源頭與終點

傳統上，無論是基于 MapReduce 的數據流，還是基于 Spark/Flink 的流水線，其數據的來源和最終落腳點都可以是分布式存儲（比如 GFS、HDFS、S3）。

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

當然，對于流式系統來說，分布式存儲肯定不是最典型的數據來源，而是各種在線的服務產生的事件。

2. 中間數據的落腳點

對于批處理的中間數據，如果量過大或者計算代價太大，比如 Spark 中的 RDD，會：

1. 內存裝不下 spill 到分布式存儲中
2. 在 shuffle 后，為了避免重算，通常要持久化到分布式存儲系統上一份

即使是如 Flink 之類的流式處理系統，最近也在提存算分開——將中間狀態外存，計算才能更好的擴縮容。傳統上 Flink 使用了 RocksDB 之類的存儲引擎，將狀態數據存在各個計算節點本地；但為了上云，讓計算更方便的彈性，也開始尋求將所有中間狀態與計算節點解耦合，存到統一的分布式存儲中。

3. 分布式數據庫的基座

隨著數據庫本身越來越多的支持分布式部署和計算，傳統上的大數據處理需求，一部分被內化為查詢引擎層的分布式計算。這也是為什么，現代分布式數據庫的查詢引擎也多使用 MPP 方式，充分的利用多節點的計算能力，在單個查詢內進行算子或者流水線粒度的分布式并行執行。

在這種情況下，分布式數據庫的底層存儲通常為分布式（KV）存儲，且是和計算分離的（存算分開）。也就是說，數據通過查詢引擎層，最終會以 KV 的形式落到分布式存儲中，并供之后的查詢支持。

如果存儲節點本身可以定制，則通常會讓其支持部分計算能力，以利用數據的親和性，將部分計算下推到相關的存儲節點上。如果存儲是云上的 S3 等對象存儲，無法定制，則通常會將數據在計算節點緩存，并且盡量的復用。

參考資料

[1]《系統日知錄》專欄: https://xiaobot.net/p/system-thinking ，點擊下面閱讀原文跳轉訂閱。