分布式存储系统在大数据处理中扮演着怎样的角色？

如果存储节点本身可以定制，则通常会让其支持部分计算能力，以利用数据的亲和性，将部分计算下推到相关的存储节点上。如果存储是云上的 S3 等对象存储，无法定制，则通常会将数据在计算节点缓存，并且尽量的复用。 参考资料

大概总结下，主要包括以下角色：

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 ，点击下面阅读原文跳转订阅。