漫谈分布式整理笔记(一)

前言

这段时间小乌龟学习了秦夏漫谈分布式,学到了很多,决定用几篇文章简单梳理一下,本文是第一篇。漫谈分布式这个是漫谈分布式的连接,个人觉得写得不错。

1、为什么要有分布式系统

单台机器存不下、单台机器算的慢。所以出现了分布式,来摆脱单机资源的束缚。
在此基础上为了更好的管理这些系统,出现了分布式计算框架与分布式存储引擎。

分治是分布式系统的核心思想。下面让我们看看怎样利用分治的思想来设计分布式系统。

2、分布式存储系统

2.1 如何设计分布式存储系统

如果需要你来设计一个分布式系统,很自然的思路就是就是以文件为单位,分散到很多台服务器上去。但是这样会遇到如下的问题:

  • 数据分布不均
    文件大小差距很大,这就导致有些服务器上会存很多数据,还有些相对较少。如果按照剩余空间对比存放,那么又会出现下面的问题。
  • 空间分配不够灵活
    如果一台机器200G,一台100G,如果200G的先存了一个80G的,此时再来了一个150G的,就存不下了。但是如果把80G先存在100G上,就可以。

那么如何解决这些问题呢。
以固定大小的单元,而不是以文件为单位去存储文件。
文章中以HDFS为例,给我们阐释了,以固定单元怎么存储。
HDFS 以 block 为单位拆分文件,DataNode负责提供block的读写,NameNode 负责保存文件和block 的对应关系,block 和机器的对应关系等元信息。
HDFS
所有对文件的读和写操作,都先经过 NameNode 处理元数据,再和对应的 DataNode 发生具体的数据交换。

  1. 写数据过程
    HDFS写数据
  2. 读数据过程
    HDFS读数据

2.2 数据存储如何节省成本

  • 很旧的、临时的数据,考虑直接删除。
  • 删除不掉但又很重要的数据,考虑降低副本
  • 压缩是最通用的节省空间的方法,需要平衡压缩率和速度,考虑文件可切分,善用列式存储。
  • 按数据冷热做分层存储,能有效节省成本
  • 存储与计算分离
  • 数据访问记录和血缘关系很重要

3、分布式计算框架

3.1 如何设计分布式计算框架

怎样使用分治法来设计分布式计算系统呢。其实为了节省资源,计算的分治,是以存储的分治为前提的。计算的分治大体可以分为:计算逻辑的分治和计算结果的分治。
计算逻辑的分治,只是相同代码的多机并行执行,区别只是处理的数据不同。
计算结果的分治,是计算过程被切割后自然的影响

计算的分布式导致了计算过程被切分为map 和 reduce 两个阶段

  • map 阶段的并行度取决于输入数据的切分度,和文件格式、压缩方式、block大小等有关
  • reduce 阶段的并行度可以自行设置,是运行速度和资源消耗的权衡

3.2 如何资源调度

分布式计算框架更多尝试对资源的调度做优化,以此节省成本。
那怎么有效的利用资源并且能够减轻的扩容带来的维护成本呢。

提升资源整体利用率的方式是混部,错峰使用资源。典型的使用多租户并配合FIFO 的调度,先到先运行。

但是混部就会相互影响,所以需要资源隔离。但是呢,隔离又会导致资源借用受限,导致有的资源空闲,有的繁忙,资源利用率降低,所以需要软性隔离。

软隔离又会带来新的问题,如果借用的份额长期不归还,会导致其他计算干等。所以借用需要有时间限制,应当支持强杀。并且资源借用需要有容量限制,所以要设置硬顶。

基于这些考虑,就有了Capacity Scheduler、Fair Scheduler 等各种调度器。但是它们也可以进行配置,使它们逐渐趋同。大家心底应该明白一件事,没有绝对的公平,带权重和DRF等一切措施都是折中和改进,相对公平而已。

文中作者还提到,这个问题是资源分配的问题,和我们现实生活中的资源分配一样,需要有令人信服的规则,然后由各业务讨论一致(通常很难),或者让老板拍板。切记平台部门是管理员,不掌握分配资源的权利,而应当提供足够的指标协助决策。

4、分治总结

4.1 简介

分治是分布式系统的核心思想。分治的实现是partition ,解决的是分布式系统最基础的难题–扩展性。

  • 以 HDFS 为代表的分布式存储框架,通过把数据切分成固定大小的block ,在搭配记录 block 位置的元数据,就解决了数据存储扩展性的问题。只要有足够多的硬盘,就能一直存下去。
  • 以 MapReduce 为代表的分布式计算框架,通过把计算逻辑切分成一个个Mapper 和 Reducer, 就解决了数据计算扩展性的问题。只要有足够的的CPU和内存,就能一直算下去。
    既然partition 是分布式的实现方式,那么下边我们研究一下常见的 partitioning 方案。

4.2 partitioning 方案

典型的,我们把数据分为三种类型来研究。

  • 文件数据,文件系统任意格式的文件,典型就是HDFS上的文件
  • key-value 数据,带主键的数据,典型就是HBASE 和 MySQL上的数据
  • 文档数据,类似json 格式的数据,和 key-value 的区别是没有业务意义上的主键,典型就是ElasticSearch 上的数据

具体来说,对于扩展性,我们关注如下几个点:

  • partitioning 方式,即数据在逻辑上切分
  • localization 方式,即数据在物理上怎么分布
  • rebalance 方式,即节点数变化后,数据在物理上怎么重新分布

4.2.1 文件类数据

partitioning
采用类似固定大小的block 的做法来切分数据。
Localization & Rebalance
文件类数据,通常近似随机的做partition。由元数据提供 localization, rebalance 影响范围也可控。

4.2.2 key-value 类数据

partitioning
采用 key range,但是容易产生数据倾斜。这样只能通过数据打散的方式,解决此类问题。想要打散数据,文章中分享了以下两个通用的方法。

  • 加随机数,这个效果肯定是最彻底的,但这样就不能精确定位 key 来访问数据了,只能范围扫描。
  • hash 处理,hash 算法的摘要提供了一定程度的打散,而输出的确定性又保证了事后访问能精确定位。

一般选择对 key 做 hash 的方式。然后,仍旧可以按range 来做切分。hash 确实能够解决分布不均的问题,但也丢掉了range 的一大好处:按范围查询。
于是可以有一种折中的办法,所谓组合主键(compound primary key)。类似 key1_key2,只有key1 用来作为hash partition, 而 key就用来满足范围查询的需求。

Localization & Rebalance
由于多了业务含义,通常从 key 的业务入手,不同方法优缺点很明显。当然,我们的localization 策略,不能打破同样范围的数据在同一个partition 这个规则。
一般有如下几种选择。

  1. hash mode N ,其中N 为节点数。但是非常不灵活,一旦节点数发生变化,rebalacne 就可能要移动大量甚至所有数据。根本原因,是 partition 带上了N这个变量,所以节点数一变,Rebalance 就会影响localization。
  2. 固定数量的 partition。无论节点数增减多少,partition 数量都不变。当有节点增减时,只要移动少量 partition 就够了。坏处自然是元数据管理带来的开销。但元数据通常不大。固定 partition数量,还有另外一个问题,就是无法判定合适的数量。
  3. 动态数量的 partition
    加节点,就把旧的 partition split 掉,然后分一些给新节点。
    减节点,就把旧的 partition merge 掉,然后挪到可用的节点上

4.2.3 文档类的数据

partitioning
由于doc_id 的存在,可以借鉴 key-value 数据做 partitioning。更常见的是采用 mod N 的方法。
Localization & Rebalance
文档数据通常也通过二级索引来查询的,但是要考虑二级索引带来的影响。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页