Spark in action on Kubernetes - 存储篇（一）

前言

在上篇文章中，我们分析了Spark Operator内部的机制，今天我们会讨论一个在大数据领域中最重要的话题 - 存储。大数据已经无声无息的融入了每个人的生活中。大到旅游买房，小到外卖打车，都可以看到通过大数据提供数据分析、数据推荐、数据决策的使用场景。大数据要想能够更准确地协助决策，需要在数据多维度、数据完备性等方面有较高要求。可预知的在未来，数据的量级会越来越大，特别是随着5G时代的到来，数据的吞吐量级成指数的增长，数据的维度与来源会越来越多，数据的种类也会变得越来越异质化，对大数据平台也带来新的挑战。成本低、存得多、读写快成为大数据存储的三大问题，而今天我们就会针对这三大问题进行探讨。

容器化大数据的计算与存储

计算和存储分离是大数据领域被大家讨论过很多次的问题了，通常我们会通过如下几个角度来看这个问题：

• 硬件限制：机器的带宽成倍数的增长，但是磁盘的速度基本不变，从而造成数据本地读写优势减弱。
• 计算成本：计算和存储的量级不匹配，可能造成算力的大量浪费，独立计算资源可以节约成本。
• 存储成本：集中式存储可以在保证更高SLA的前提下降低存储成本，使得自建数据仓库的优势减少。

这三大问题，随着容器时代的到来也变得愈发的凸显。我们知道在kubernetes中，Pod是运行在底层的资源池上，而Pod所需要的存储是通过PV或者PVC的方式动态分配与挂载的，从某种意义来讲，容器本身的架构就是计算与存储分离的。那么使用了存储与计算分离方式的大数据容器集群会带来哪些变化与优势呢？

• 成本更低

通常在阿里云上建立一个Spark大数据平台的时候，首先会选择D系列的机器，在上面搭建HDFS、Hadoop等一系列的基础组件，然后再将Spark等作业任务通过Yarn进行调度，跑在这个集群之上。D系列的内网带宽范围是3Gbps-20Gbps，默认可以绑定（4-28块) 5.5T的本地盘。因为在云上，云盘的IO和网络的IO是共享的，而本地盘的IO是独立的，因此D系列+本地盘的IO性能会比同规格传统机型+云盘的性能更好。

但是在实际生产中，我们会发现存储的数据对着时间变得越来越多，而由于数据具有一定的时效性，造成单位时间的算力与存储的增长是不相匹配的，这个时候就会带来了成本的浪费。那么如果我们使用计算和存储分离的思想，使用外部存储，例如OSS、Nas或者DFS(阿里云HDFS产品)，会有哪些变化呢？

首先，我们屏蔽由于存储的IO差异造成的影响，先都使用远程的DFS作为文件存储。然后我们选择了ecs.ebmhfg5.2xlarge（8C32G6Gbps)和ecs.d1ne.2xlarge (8C32G6Gbps) 两款分别面向计算和大数据场景规格配置相同的热门机型，进行了比对。

ecs.ebmhfg5.2xlarge（8C32G)的测试结果

ecs.d1ne.2xlarge (8C32G)的测试结果