散布式存储系统在大数据解决中表演着怎么的角色

大略总结下，关键包含以下角色：

1. 数据的源头与终点

这是因为散布式存储通常具备很高的可用性，不太用担忧数据失落。但从另一方面来说，上方提到的几种散布式存储通常不具备数据库中的 Schema，造成在用的时刻，缺少一些灵敏性。

2. 两边数据的落脚点

关于批解决的两边数据，假设量过大或许计算代价太大，比如 Spark 中的 RDD，会：

即使是如 Flink 之类的流式解决系统，最近也在提存算分开——将两边形态外存，计算才干更好的扩缩容。传统上 Flink 经常使用了 RocksDB 之类的存储引擎，将形态数据存在各个计算节点本地；但为了上云，让计算更繁难的弹性，也开局寻求将一切两边形态与计算节点解耦合，存到一致的散布式存储中。

3. 散布式数据库的基座

随着数据库自身越来越多的允许散布式部署和计算，传统上的大数据解决需求，一部分被内化为查问引擎层的散布式计算。这也是为什么，现代散布式数据库的查问引擎也多经常使用 MPP 方式，充沛的应用多节点的计算才干，在单个查问内启动 算子 或许 流水线 粒度的散布式并行口头。

在这种状况下，散布式数据库的底层存储通常为散布式（KV）存储，且是和计算分别的（存算分开）。也就是说，数据经过查问引擎层，最终会以 KV 的方式落到散布式存储中，并供之后的查问允许。

假设存储节点自身可以定制，则通常会让其允许部分计算才干，以应用数据的亲和性，将部分计算下推到相关的存储节点上。假设存储是云上的 S3 等对象存储，无法定制，则通常会将数据在计算节点缓存，并且尽量的复用。

《系统日知录》专栏: ，点击上方 浏览原文 跳转订阅。