85ac2199c6cbc698fbb974a02d7e3334
漫谈分布式系统(4) -- 存的下,还要存的好

这是《漫谈分布式系统》系列的第 4 篇,预计会写 30 篇左右。欢迎订阅,听我娓娓道来。也欢迎转发朋友圈分享给更多人。


上一篇《漫谈分布式系统(3) -- 再也不怕存不下》,我们以 HDFS 为例,讲了分布式存储系统怎么解决数据存不下的问题。但是光存得下还不够,还要存的好。

因为海量数据带来的就是海量成本。存得不好,就是糟蹋钱。

其实之前已经单独写过一篇文章说这个话题了,第 1 节就整理下要点,第 2 节再补充另一个重要的点。

1

删数据

删数据这个办法,乍一听很无厘头,但其实简单粗暴有效。很多情况下,很多数据其实都是可以删的,比如:

  • 5 年前的旧数据,已经没有时效性了,可能再也不会用了。
  • 临时数据、中间结果等,用完忘了删。
  • 同样的数据,不同业务甚至不同人都各自维护了一份,冗余而不自知。

类似这样的数据,就静静躺在那里,消耗着无谓的成本。

当然,要做到能删而敢删,就需要我们对数据的使用情况、血缘关系有足够的掌握了,配套的程序和数据支持得跟上。

减副本

这个办法乍一听也很无厘头。本来就是为了高可用才弄多副本,减少副本,不就降低可用性了吗?

这话没错,所以减副本这个办法不应该大面积使用。像我所在的公司,就用在 temp 库上。这个库的顾名思义就是存放临时数据的,没有那么多的使用限制。也正因为限制少,所以很容易变成垃圾场,并且越堆越大。

所以我们把这个 temp 库的副本数设置成 2,直接就节省了几百万的成本。

我们敢这么做,一方面是因为这个数据就算真丢了也没多大影响;另一方面,是考虑到当集群规模足够大,网络带宽也足够大后,个别机器宕机,能够在很短时间内就从其他机器上补齐丢失的副本。

当然,只是风险小,不是没风险,所以慎用。

另外,HDFS RAID 也是可以考虑的方式​,本质上也是降副本。像 Facebook、腾讯等大厂已经自己实现并应用在生产了,Hadoop 3.0 也会通过纠删码的方式提供支持。

压缩

大家都知道,压缩是节省空间最重要也是最常规的方式。

在海量数据的场景下,压缩的效果和节省的成本会更加可观。当然,也有几个方面需要重点关注:

  • 压缩/解压速度和压缩比的平衡。典型的效果和效率的 trade-off,所以很多场景下会选择 snappy 这种比较平衡的压缩算法。
  • splittable,也就是可切分。在 MapReduce 这样的计算模型下,如果一个文件过大又不可切分,那就只能被一个任务处理,而没法分配给多个任务并行处理,自然会拖慢整体性能。不是所有压缩格式都支持切分的,这又是一个要取舍的点。
  • 文件格式的选择。最常见的 TextFile 其实效率不好,而类似 Avro、ORC 和 Parquet 这样的格式通常会有更好的效率。尤其列式存储的格式,由于同样列的数据往往接近,存在一起后通常会有更好的压缩效果。

分层存储

谁都想更快的访问数据,但速度快带来的就是成本高,所以只能按需选择不同的存储介质。像我们熟知的内存和硬盘。更广义的,这类介质可以叫做异构存储(heterogeneous storage)。

分层存储的思想,就是根据数据的冷热来选择不同的存储介质。最热的数据放在内存,次热的放在 SSD,温的放在 SATA 等等。除了像 HDFS 原生支持的层次,还可以考虑结合 Alluxio 等方案​。​

top Created with Sketch.