精华内容
下载资源
问答
  • 今天和大家浅谈一下分布式存储设计方面我个人的一些理解。首先声明我本人不是做研发的,只是一个有着10年左右存储行业经验的普通工程师和产品经理。最早接触存储是在2010年,那时候说起存储大多指的是双控制器的磁盘...

    1传统存储

    今天和大家浅谈一下分布式存储设计方面我个人的一些理解。首先声明我本人不是做研发的,只是一个有着10年左右存储行业经验的普通工程师和产品经理。最早接触存储是在2010年,那时候说起存储大多指的是双控制器的磁盘阵列,比如:EMC、IBM、HDS等,除了双控制器架构还有多控制器的所谓高端存储,这些统称企业级存储。不过不管是中端的还是高端的,对于普通工程师来说都是一个黑盒子,我们并不知道其内部架构是什么样的,是怎么设计的,所了解的也只不过是产品的规格参数啦,功能特性啦,基本上把这些跟用户讲明白,也就够了。小编我曾经做过产品经理,和公司研发的同事了解过控制器架构的存储底设计的一些关键技术,比如Non Transparent Bridge(非透明桥):简单的理解就是通过PCIE把两个控制器连接在一起了。而为了使两个机器连接在一起,就发明了一种特殊的设备叫做非透明桥,桥的两端是连接在两个控制器的PCIE的总线上的,但是从任意一端,只能看到这个桥,看不到这个桥后面接的下一级设备,这就是所谓的“非透明”(因为一般的桥是透明的,你能看到桥后面的东西)。非透明桥就是用来做双控制器的cache mirror,所谓的缓存镜像,而现在的分布式架构很少有人用到这个技术。
    传统磁盘阵列架构

    2分布式存储与传统存储的区别

    然而,时过境迁,随着网络技术、分布式文件系统、计算机硬件的蓬勃发展,目前的存储系统除了刚才提到的控制器架构的产品,基于X86通用服务器平台的分布式存储系统逐渐成为主流的存储形态。区别于控制器架构的存储系统的专用硬件,分布式存储系统是运行在通用的X86 PC上的,在软件层面上基于分布式文件系统(ceph、Lustre、Gluster、GPFS等),节点间一致性同步通过(ETCD、Zookeeper等)技术实现。现在我们通常把之前控制器架构的存储成为传统存储,以区别于现在的分布式存储系统,我简单把二者的区别罗列了一下,如下表:
    传统存储与分布式存储区别

    2分布式存储与传统存储的区别

    分布式存储系统设计架构
    上图是我和研发的同事聊出来的关于分布式存储系统设计的宏观架构,大体上可以分为Base Platform(基础平台)、Platform Service(平台服务)、Data Path(数据路径)和Control Path(控制路径)这几个层面。其中:

    1. Base Platform(基础平台):主要实现对物理的盘的管理,如:监控、故障处理、系统出现故障后的降级处理以及对热备磁盘的管理等;另外通过ETCD或者Zookeeper等技术实现在所有节点间的配置信息同步,集群状态缓存,一致性,心跳等功能。同时在这一层还要实现对于服务的监控、用户的管理以及系统镜像文件的管理;
    2. Platform Service(平台服务):这一层主要功能有两方面,一是会为整个存储系统提供各种的服,如:NTP、SNMP、DNS、浮动IP 域 (表示IP浮动的范围)等;二是会提供日志收集、回滚、磁盘LED、Core dump等支持组件;
    3. Data Path(数据路径):中存储前端服务提供的是协议和语义,比如文件,块,nfs,smb;而后端提供地址空间,也就是把一堆盘窜成一个大存储池子;
    4. Control Path(控制路径):这一层提供的就是存储系统对外的管理方式,当然目前通常要支持全中文图形化的管理、对于高级功能要提供命令行的管理等方式了。
      以上是一个分布式存储系统大体的一个设计架构,当然也是一个比较宏观的架构,其实具体还有很多的细节没有展现。
    展开全文
  • 分布式存储系统,是由多个PC计算机通过网络连接起来的存储系统。

    1. 单机文件系统 vs 分布式文件系统

    传统单机文件系统是计算机中一个非常重要的组件,为存储设备提供一致的访问和管理方式。在不同的操作系统中,文件系统会有一些差别,但也有一些共性几十年都没怎么变化:

    • 数据是以文件的形式存在,提供 Open、Read、Write、Seek、Close 等API 进行访问;
    • 文件以树形目录进行组织,提供原子的重命名(Rename)操作改变文件或者目录的位置。

    文件系统提供的访问和管理方法支撑了绝大部分的计算机应用,Unix 的“万物皆文件”的理念更是凸显了它的重要地位。

    随着互联网企业的高速发展,这些企业对数据存储的要求越来越高,而且模式各异,如淘宝主站的大量商品图片,其特点是文件较小,但数量巨大;而类似于youtube,优酷这样的视频服务网站,其后台存储着大量的视频文件,尺寸大多在数十兆到数吉字节不等。这些应用场景都是传统文件系统不能解决的。

    单机文件系统的问题:

    (1)共享:无法同时为分布在多个机器中的应用提供访问,于是有了 NFS 协议,可以将单机文件系统通过网络的方式同时提供给多个机器访问。
    (2)容量:无法提供足够空间来存储数据,数据只好分散在多个隔离的单机文件系统里。
    (3)性能:无法满足某些应用需要非常高的读写性能要求,应用只好做逻辑拆分同时读写多个文件系统。
    (4)可靠性:受限于单个机器的可靠性,机器故障可能导致数据丢失。
    (5)可用性:受限于单个操作系统的可用性,故障或者重启等运维操作会导致不可用。

    分布式文件系统将数据存储在物理上分散的多个存储节点上,对这些节点的资源进行统一的管理与分配,并向用户提供文件系统访问接口。

    2. 分布式文件系统原理

    目前比较主流的分布式文件系统架构,如下图所示。
    分布式文件系统

    1. 主控服务器(或称元数据服务器、名字服务器等,通常会配置备用主控服务器以便在故障时接管服务,也可以两个都为主的模式)
    2. 多个数据服务器(或称存储服务器,存储节点等)
    3. 以及多个客户端,客户端可以是各种应用服务器,也可以是终端用户。

    这种方式简单易实现,目前很多分布式文件系统都采用这种方式如GFS、TFS、MooseFS 等。
    主控服务器在负载较大时会出现单点,较多的解决方案是配置备用服务器,以便在故障时接管服务,如果需要,主备之间需要进行数据的同步。
    分布式系统原理

    2.1 主控服务器

    (1)命名空间的维护

    Master负责维护整个文件系统的命名空间,并暴露给用户使用,命名空间的结构主要有典型目录树结构如MooseFS等,扁平化结构如淘宝TFS(目前已提供目录树结构支持),图结构(主要面向终端用户,方便用户根据文件关联性组织文件,只在论文中看到过)。

    为了维护名字空间,需要存储一些辅助的元数据如文件(块)到数据服务器的映射关系,文件之间的关系等,为了提升效率,很多文件系统采取将元数据全部内存化(元数据通常较小)的方式如GFS, TFS;有些系统借则助数据库来存储元数据如DBFS,还有些系统则采用本地文件来存储元数据如MooseFS。

    (2)数据服务器管理

    除了维护文件系统的命名空间,Master还需要集中管理数据DS, 可通过轮询DS或由DS报告心跳的方式实现。在接收到客户端写请求时,Master需要根据各个DS的负载等信息选择一组(根据系统配置的副本数)DS为其服务;当Master发现有DS宕机时,需要对一些副本数不足的文件(块)执行复制计划;当有新的DS加入集群或是某个DS上负载过高,Master也可根据需要执行一些副本迁移计划。

    如果Master的元数据存储是非持久化的,则在DS启动时还需要把自己的文件(块)信息汇报给Master。在分配DS时,基本的分配方法有随机选取,RR轮转、低负载优先等,还可以将服务器的部署作为参考(如HDFS分配的策略),也可以根据客户端的信息,将分配的DS按照与客户端的远近排序,使得客户端优先选取离自己近的DS进行数据存取.

    (3)服务调度

    Master最终的目的还是要服务好客户端的请求,除了一些周期性线程任务外,Master需要服务来自客户端和DS的请求,通常的服务模型包括单线程、每请求一线程、线程池(通常配合任务队列)。

    • 单线程模型下,Master只能顺序的服务请求,该方式效率低,不能充分利用好系统资源;
    • 每请求一线程的方式虽能并发的处理请求,但由于系统资源的限制,导致创建线程数存在限制,从而限制同时服务的请求数量,另外,线程太多,线程间的调度效率也是个大问题;
    • 线程池的方式目前使用较多,通常由单独的线程接受请求,并将其加入到任务队列中,而线程池中的线程则从任务队列中不断的取出任务进行处理。

    (4)主备(主)容灾

    Master在整个分布式文件系统中的作用非常重要。

    为了避免Master的单点问题,通常会为其配置备用服务器,以保证在主控服务器节点失效时接管其工作。通常的实现方式是通过HA、UCARP等软件为主备服务器提供一个虚拟IP提供服务,当备用服务器检测到主宕机时,会接管主的资源及服务。

    如果Master需要持久化一些数据,则需要将数据同步到备用Master,对于元数据内存化的情况,为了加速元数据的构建,有时也需将主上的操作同步到备Master。
    处理方式可分为同步和异步两种。

    • 同步方式将每次请求同步转发至备Master,这样理论上主备时刻保持一致的状态,但这种方式会增加客户端的响应延迟(在客户端对响应延迟要求不高时可使用这种方式),当备Master宕机时,可采取不做任何处理,等备Master起来后再同步数据,或是暂时停止写服务,管理员介入启动备Master再正常服务(需业务能容忍);
    • 异步方式则是先暂存客户端的请求信息(如追加至操作日志),后台线程重放日志到备Master,这种方式会使得主备的数据存在不一致的情况,具体策略需针对需求制定。

    2.2 数据服务器

    (1) 数据本地存储

    数据服务器负责文件数据在本地的持久化存储,最简单的方式是将客户每个文件数据分配到一个单独的DS上作为一个本地文件存储,但这种方式并不能很好的利用分布式文件系统的特性,很多文件系统使用固定大小的块来存储数据如GFS, TFS, HDFS,典型的块大小为64M。

    对于小文件的存储,可以将多个文件的数据存储在一个块中,并为块内的文件建立索引,这样可以极大的提高存储空间利用率。
    Facebook用于存储照片的HayStack系统的本地存储方式为,将多个图片对象存储在一个大文件中,并为每个文件的存储位置建立索引,其支持文件的创建和删除,不支持更新(通过删除和创建完成),新创建的图片追加到大文件的末尾并更新索引,文件删除时,简单的设置文件头的删除标记,系统在空闲时会对大文件进行compact把设置删除标记且超过一定时限的文件存储空间回收(延迟删除策略)。
    淘宝的TFS系统采用了类似的方式,对小文件的存储进行了优化,TFS使用扩展块的方式支持文件的更新。对小文件的存储也可直接借助一些开源的KV存储解决方案,如Tokyo Cabinet(HDB, FDB, BDB, TDB)、Redis等。

    对于大文件的存储,则可将文件存储到多个块上,多个块所在的DS可以并行服务,这种需求通常不需要对本地存储做太多优化。

    (2)状态维护

    DS除了简单的存储数据外,还需要维护一些状态,首先它需要将自己的状态以心跳包的方式周期性的报告给Master,使得Master知道自己是否正常工作,通常心跳包中还会包含DS当前的负载状况(CPU、内存、磁盘IO、磁盘存储空间、网络IO等、进程资源,视具体需求而定),这些信息可以帮助Master更好的制定负载均衡策略。

    很多分布式文件系统如HDFS在外围提供一套监控系统,可以实时的获取DS或Master的负载状况,管理员可根据监控信息进行故障预防。

    (3)副本管理

    为了保证数据的安全性,分布式文件系统中的文件会存储多个副本到DS上,写多个副本的方式,主要分为3种。

    1. 最简单的方式是客户端分别向多个DS写同一份数据,如DNFS采用这种方式;
    2. 第2种方式是客户端向主DS写数据,主DS向其他DS转发数据,如TFS采用这种方式;
    3. 第三种方式采用流水复制的方式,client向某个DS写数据,该DS向副本链中下一个DS转发数据,依次类推,如HDFS、GFS采取这种方式。

    当有节点宕机或节点间负载极不均匀的情况下,Master会制定一些副本复制或迁移计划,而DS实际执行这些计划,将副本转发或迁移至其他的DS。DS也可提供管理工具,在需要的情况下由管理员手动的执行一些复制或迁移计划。

    2.3 客户端

    (1)接口

    用户最终通过文件系统提供的接口来存取数据,linux环境下,最好莫过于能提供POSIX接口的支持,这样很多应用(各种语言皆可,最终都是系统调用)能不加修改的将本地文件存储替换为分布式文件存储。

    要想文件系统支持POSIX接口,

    • 一种方式时按照VFS接口规范实现文件系统,这种方式需要文件系统开发者对内核有一定的了解;
    • 另一种方式是借助FUSE(http://fuse.sourceforge.net)软件,在用户态实现文件系统并能支持POSIX接口,但是用该软件包开发的文件系统会有额外的用户态内核态的切换、数据拷贝过程,从而导致其效率不高。很多文件系统的开发借助了fuse,参考http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems。

    如果不能支持POSIX接口,则为了支持不同语言的开发者,需要提供多种语言的客户端支持,如常用的C/C++、java、php、python客户端。使用客户端的方式较难处理的一种情况时,当客户端升级时,使用客户端接口的应用要使用新的功能,也需要进行升级,当应用较多时,升级过程非常麻烦。

    目前一种趋势是提供Restful接口的支持,使用http协议的方式给应用(用户)访问文件资源,这样就避免功能升级带来的问题。

    另外,在客户端接口的支持上,也需根据系统需求权衡,比如write接口,在分布式实现上较麻烦,很难解决数据一致性的问题,应该考虑能否只支持create(update通过delete和create组合实现),或折中支持append,以降低系统的复杂性。

    (2)缓存

    分布式文件系统的文件存取,要求客户端先连接Master获取一些用于文件访问的元信息,这一过程一方面加重了Master的负担,一方面增加了客户端的请求的响应延迟。

    为了加速该过程,同时减小Master的负担,可将元信息进行缓存,数据可根据业务特性缓存在本地内存或磁盘,也可缓存在远端的cache系统上如淘宝的TFS可利用tair作为缓存(减小Master负担、降低客户端资源占用)。

    维护缓存需考虑如何解决一致性问题及缓存替换算法,一致性的维护可由客户端也可由服务器完成:

    • 一种方式是客户端周期性的使cache失效或检查cache有效性(需业务上能容忍)
    • 或由服务器在元数据更新后通知客户端使cache失效(需维护客户端状态)。使用得较多的替换算法如LRU、随机替换等。

    (3)其他
    客户端还可以根据需要支持一些扩展特性,如将数据进行加密保证数据的安全性、将数据进行压缩后存储降低存储空间使用,或是在接口中封装一些访问统计行为,以支持系统对应用的行为进行监控和统计。

    3. 分布式文件系统对比

    3.1 HDFS

    出自 Yahoo 的 Hadoop 算是 Google 的 GFS、MapReduce 等的开源Java实现版,HDFS 也是基本照搬 GFS 的设计,这里就不再重复了,下图是HDFS的架构图。
    hdfs
    HDFS的可靠性和可扩展能力还是非常不错的,有不少几千节点和 100PB 级别的部署,支撑大数据应用表现还是很不错的,少有听说丢数据的案例(因为没有配置回收站导致数据被误删的除外)。

    HDFS 的 HA 方案是后来补上的,做得比较复杂,以至于最早做这个 HA 方案的 Facebook 在很长一段时间(至少3年)内都是手动做故障切换(不信任自动故障切换)。

    因为 NameNode 是 Java 实现的,依赖于预先分配的堆内存大小,分配不足容易触发 Full GC 而影响整个系统的性能。有一些团队尝试把它用 C++ 重写了,但还没看到有成熟的开源方案。

    HDFS 也缺乏成熟的非 Java 客户端,使得大数据(Hadoop等工具)以外的场景(比如深度学习等)使用起来不太方便。

    3.2 MooseFS

    MooseFS 是来自波兰的开源分布式 POSIX 文件系统,也是参照了 GFS 的架构,实现了绝大部分 POSIX 语义和 API,通过一个非常成熟的 FUSE 客户端挂载后可以像本地文件系统一样访问。MooseFS 的架构如下图所示:

    moosefs

    MooseFS 支持快照,用它来做数据备份或者备份恢复等还是恢复方便的。

    MooseFS 是由 C 实现的,Master 是个异步事件驱动的单线程,类似于 Redis。不过网络部分使用的是 poll 而不是更高效的 epoll,导致并发到 1000 左右时 CPU 消耗非常厉害。

    开源的社区版没有HA,是通过 metalogger 来实现异步冷备,闭源的收费版有 HA。

    为了支持随机写操作,MooseFS 中的 chunk 是可以修改的,通过一套版本管理机制来保证数据一致性,这个机制比较复杂容易出现诡异问题(比如集群重启后可能会有少数 chunk 实际副本数低于预期)。

    3.3 CephFS

    CephFS 始于 Sage Weil 的博士论文研究,目标是实现分布式的元数据管理以支持 EB 级别数据规模。2012年,Sage Weil 成立了 InkTank 继续支持 CephFS 的开发,于 2014年被 Redhat 收购。直到 2016 年,CephFS 才发布可用于生产环境的稳定版(CephFS 的元数据部分仍然是单机的)。现在,CephFS 的分布式元数据仍然不成熟。

    Ceph 是一个分层的架构,底层是一个基于 CRUSH(哈希)的分布式对象存储,上层提供对象存储(RADOSGW)、块存储(RDB)和文件系统(CephFS)三个API,如下图所示。
    在这里插入图片描述
    在这里插入图片描述

    用一套存储系统来满足多个不同场景的存储需求(虚拟机镜像、海量小文件和通用文件存储)还是非常吸引人的,但因为系统的复杂性需要很强的运维能力才能支撑,实际上目前只有块存储还是比较成熟应用得比较多,对象存储和文件系统都不太理想,听到不少负面的使用案例(他们用过一段时间Ceph 后就放弃了)。

    3.4 分布式块存储 vs 分布式文件存储 vs 分布式对象存储

    • 块设备速度快,对存储的数据没有进行组织管理,但在大多数场景下,用户数据读写不方便(以块设备位置offset + 数据的length来记录数据位置,读写数据)。

    • 而在块设备上构建了文件系统后,文件系统帮助块设备组织管理数据,数据存储对用户更加友好(以文件名来读写数据)。Ceph文件系统接口解决了“Ceph块设备+本地文件系统”不支持多客户端共享读写的问题,但由于文件系统结构的复杂性导致了存储性能较Ceph块设备差。

    • 对象存储接口是一种折中,保证一定的存储性能,同时支持多客户端共享读写。

    4. 分布式数据库

    根据不同的应用的领域,分布式存储系统有下面的类别:

    1. 分布式协同系统(分布式日志复制)
    2. 分布式任务调度框架
    3. 流计算框架
    4. 分布式文件/对象系统
    5. 分布式NoSQL存储
    6. 分布式关系数据库(OLAP、OLTP);
    7. 各种消息队列mq

    分布式数据库有那些类别?

    • Key-Value 存储: Redis
    • 类BigTable存储: Apache HBase, Apache Cassandra
    • 文档数据库: MongoDB
      nosql
      Key-Value 键值对存储是非常简单而强大的。下面的很多技术基本上都是基于这个技术开始发展的。但是,Key-Value有一个非常致命的问题,那就是如果我们需要查找一段范围内的key。(陈皓注:学过hash-table数据结构的人都应该知道,hash-table是非序列容器,其并不像数组,链接,队列这些有序容器,我们可以控制数据存储的顺序)。于是,有序键值 (Ordered Key-Value) 数据模型被设计出来解决这一限制,来从根本上提高数据集的问题。

    Ordered Key-Value 有序键值模型也非常强大,但是,其也没有对Value提供某种数据模型。通常来说,Value的模型可以由应用负责解析和存取。这种很不方便,于是出现了 BigTable类型的数据库,这个数据模型其实就是map里有map,map里再套map,一层一层套下去,也就是层层嵌套的key-value(value里又是一个key-value),这种数据库的Value主要通过“列族”(column families),列,和时间戳来控制版本。

    Document databases 文档数据库 改进了 BigTable 模型,并提供了两个有意义的改善。第一个是允许Value中有主观的模式(scheme),而不是map套map。第二个是索引。 Full Text Search Engines 全文搜索引擎可以被看作是文档数据库的一个变种,他们可以提供灵活的可变的数据模式(scheme)以及自动索引。他们之间的不同点主要是,文档数据库用字段名做索引,而全文搜索引擎用字段值做索引。

    4.1 Redis

    (1) Redis简介

    redis是开源BSD许可高级的key-value存储系统(NoSQL),可以用来存储字符串,哈希结构,链表,集合,因此,常用来提供数据结构服务,Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加 载进行使用。 支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。Redis支持数据的备份,即master-slave模式的数据备份。

    (2)Redis应用场景

    A)常规计数:粉丝数,微博数
    B)用户信息变更
    C)缓存处理,作为mysql的缓存
    D)队列系统,建有优先级的队列系统,日志收集系统

    (3)Redis的优缺点

    优点:
    (1) 速度快,因为数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1)
    (2) 支持丰富数据类型,支持string,list,set,sorted set,hash
    (3) 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行
    (4) 丰富的特性:可用于缓存,消息,按key设置过期时间,过期后将会自动删除

    缺点:
    (1)Redis不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换前端的IP才能恢复
    (2)主机宕机,宕机前有部分数据未能及时同步到从机,切换IP后还会引入数据不一致的问题,降低了系统的可用性
    (3)redis的主从复制采用全量复制,复制过程中主机会fork出一个子进程对内存做一份快照,并将子进程的内存快照保存为文件发送给从机,这一过程需要确保主机有足够多的空余内存。若快照文件较大,对集群的服务能力会产生较大的影响,而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行,也就是网络波动都会造成主机和从机间的一次全量的数据复制,这对实际的系统运营造成了不小的麻烦
    (4)Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题,运维人员在系统上线时必须确保有足够的空间,这对资源造成了很大的浪费。

    (4)Redis的持久化方案

    redis提供两种方式进行持久化,一种是RDB持久化(原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化),另外一种是AOF(append only file)持久化(原理是将Reids的操作日志以追加的方式写入文件)。

    RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。

    4.2 HBase

    Hbase: Hadoop database 的简称,也就是基于Hadoop数据库,是一种NoSQL数据库,主要适用于海量明细数据(十亿、百亿)的随机实时查询,如日志明细、交易清单、轨迹行为等。
    hadoop system

    在大数据架构中,数据流一般如下图:

    1. 通过ETL工具将数据源抽取到HDFS存储;
    2. 通过Hive清洗、处理和计算原始数据;
    3. HIve清洗处理后的结果,如果是面向海量数据随机查询场景的可存入Hbase
    4. 数据应用从HBase查询数据;

    hbase

    参考

    分布式文件系统:原理、问题与方法

    分布式文件系统架构对比

    一篇文章让你理解Ceph的三种存储接口(块设备、文件系统、对象存储)

    NOSQL 数据建模技术

    展开全文
  • 分布式存储与分布式计算

    千次阅读 多人点赞 2019-03-19 10:04:53
    3、黄金搭档:分布式存储+分布式计算 这篇文章聊一个话题:什么是分布式计算系统? (1)从一个新闻门户网站案例引入 现在很多同学经常会看到一些名词,比如分布式服务框架,分布式系统,分布式存储系统...

    目录

    1、从一个新闻门户网站案例引入

    2、推算一下你需要分析多少条数据?

    3、黄金搭档:分布式存储+分布式计算

     

     

    这篇文章聊一个话题:什么是分布式计算系统?

     

    (1)从一个新闻门户网站案例引入

     

    现在很多同学经常会看到一些名词,比如分布式服务框架,分布式系统,分布式存储系统,分布式消息系统。

     

    但是有些经验尚浅的同学,可能都很容易被这些名词给搞晕。所以这篇文章就对“分布式计算系统”这个概念做一个科普类的分析。

     

    如果你要理解啥是分布式计算,就必须先得理解啥是分布式存储,现在我们从一个小例子来引入。

     

    比如说现在你有一个网站,咱们假设是一个新闻门户网站好了。每天是不是会有可能上千万用户会涌入进来看你的新闻?

     

    好的,那么他们会怎么看新闻呢?

     

    其实很简单,首先他们会点击一些板块,比如“体育板块”,“娱乐板块”。

     

    然后,点击一些新闻标题,比如“20年来最刺激的一场比赛即将拉开帷幕”,接着还可能会发表一些评论,或者点击对某个好的新闻进行收藏。

     

    那么你的这些用户干的这些事儿有一个专业的名词,叫做“用户行为”。

     

    因为在你的网站或者APP上,用户一定会进行各种操作,点击各种按钮,发表一些信息,这些都是各种行为,统称为“用户行为”。

     

    好了,现在假如说新闻门户网站的boss说想要做一个功能,在网站里每天做一个排行榜,统计出来每天每个版块被点击的次数,包括最热门的一些新闻。

     

    然后呢,在网站后台系统里需要有一些报表,要让他看到不同的编辑产出的文章的点击量汇总,做一个编辑的绩效排名,还有很多类似的事情。

     

    这些事情叫什么呢?你可以认为是基于用户行为数据进行分析和统计,产出各种各样的数据统计分析报表和结果,供网站的用户、管理人员来查看。

     

    这也有一个专业的名词,叫做“用户行为分析”。

     

     

     

    (2)推算一下你需要分析多少条数据?

     

    好,咱么继续。如果你要对用户行为进行分析,那你是不是首先需要收集这些用户行为的数据?

     

    比如说有个哥儿们现在点了一下“体育”板块,你需要在网页前端或者是APP上立马发送一条日志到后台,记录清楚“id为117的用户点击了一下id位003的板块”。

     

    同样,这个东西也有一个专业的名词,叫做“用户行为日志”。

     

    那你可以来计算一下,这些用户行为如果采用日志的方式收集,每天大概会产生多少条数据?

     

    假设每天1000万人访问你的新闻网站,平均每个人做出30个点击、评论以及收藏等行为,那么就是3亿条用户行为日志。

     

    假设每条用户行为日志的大小是100个字节,因为可能包含了很多很多的字段,比如他是在网页点击的,还是在手机APP上点击的,手机APP是用的什么操作系统,android还是IOS,类似这样的字段是很多的。

     

    那么你就有每天大概28GB左右的数据,这里一共包含3亿条。

     

    假如对这3亿条数据,你就自己写个Java程序,从一个超大的28GB的大日志文件里,一条一条读取日志来统计分析和计算,一直到把3亿条数据都计算完毕,你觉得会花费多少时间?

     

    不可想象,根据你的计算逻辑复杂度来说,搞不好要花费几十个小时的时间。

     

    所以你觉得这种大数据场景下的分析,这么玩儿靠谱么?不靠谱。

     

     

     

    (3)黄金搭档:分布式存储+分布式计算

     

    所以这个时候,你就可以首先采用分布式存储的方式,把那3亿条数据分散存放在比如30台机器上,每台机器大概就放1000万条数据,大概就1GB的数据量。

     

    大家看看下面的图:

    接着你就可以上分布式计算了,你可以把统计分析数据的计算任务,拆分成30个计算任务,每个计算任务都分发到一台机器上去运行。

     

    也就是说,就专门针对机器本地的1GB数据,那1000万条数据进行分析和计算。

     

    这样的好处就是可以依托30台机器的资源并行的进行数据的统计和分析,这也就是所谓的分布式计算了。

     

    每台机器的计算结果出来之后,就可以进行综合性的汇总,然后就可以拿到最终的一个分析结果,大家看下图。

    假设之前你的3亿条数据都在一个30GB的大文件里,然后你一个Java程序一条一条慢慢读慢慢计算,需要耗费30小时。

     

    那么现在把计算任务并行到了30台机器上去,就可以提升30倍的计算速度,是不是就只需要1小时就可以完成计算了?

     

    所以这个就是所谓的分布式计算,他一般是针对超大数据集,也就是现在很流行的大数据进行计算的。

     

    首先需要将超大数据集拆分成很多数据块分散在多台机器上,然后把计算任务分发到各个机器上去,利用多台机器的CPU、内存等计算资源来进行计算。

     

    这种分布式计算的方式,对于超大数据集的计算可以提升几十倍甚至几百倍的效率,其实这个理论和概念,也是大数据技术的基础。

     

    比如现在最流行的大数据技术栈里,Hadoop HDFS就是用做分布式存储的,他可以把一个超大文件拆分为很多小的数据块放在很多机器上

    而像Spark就是分布式计算系统,他可以把计算任务分发到各个机器上,对各个数据块进行并行计算

    以上就是用大白话+画图,给小白同学们科普了一下分布式计算系统的相关知识,相信大家看了之后,对分布式计算系统,应该有一个初步的认识了。

     

    以上转载来自: 石彬的架构笔记

    展开全文
  • 分布式存储系统

    2017-06-05 14:18:05
    大规模分布式存储系统的重要目标就是节省成本

    大规模分布式存储系统的重要目标就是节省成本

    性价比较高的PC服务器。这些服务器性能很好,但是故障率很高。软件层面实现自动容错。

    分布式系统中有两个重要的协议,

    proxy选举协议(多个节点之间达成一致,往往用于实现总控节点选举。),

    两阶段提交协议。(保证跨多个节点操作的原子性,这些操作要么全部成功,要么全部失败。)


    异常

    大规模分布式存储系统的一个核心问题在于自动容错


    异常类型

    服务器宕机

    ;如何通过读取持久化介质中的数据来恢复内存信息,从而恢复到宕机前的某个一致的状态。

    网络异常

    特殊的网络异常称为“网络分区”,集群的所有节点被划分为多个区域,每个区域内部可以正常通信,但是区域之间无法通信。

    设计容错系统的一个基本原则是:网络永远是不可靠的,任何一个消息只有收到对方的回复后才可以认为发送成功,设计时总是假设网络将会出现异常并采取相应的处理措施。

    磁盘故障;

    磁盘损坏(分布式存储系统需要考虑将数据存储到多台服务器,即使其中一台服务器磁盘出现故障,也能从其他服务器上恢复数据。)

    磁盘数据错误(校验和checksum机制来解决,.在操作系统层面实现,又可以在上层的分布式存储系统层面实现。)


    “超时”

    RPC执行的结果有三种状态:”成功”、‘“失败”、’‘超时” 分布式存储系统的三态。


    一致性

    两个角度理解一致性:第一个角度是用户,第二个角度是存储系统,

    ‘客户端的角度来看,一致性包含如下二种情况:

    强一致性;弱一致性;最终一致性


    衡量指标

    评价分布式存储系统有一些常用的指标

    性能

    系统的吞吐能力。每秒处理的读操作数(QPS),写操作数(TPS)

    系统的响应时间。}平均延时,·99 .9%以上请求的最大延时:

    可用性

    系统在面对各种异常时可以提供正常服务的能力

    系统可用性往往体现了系统的整体代码质量以及容错能力。

    一致性

    越是强的一致性模型,;月户使用起来越简单

    可扩展性

    分布式存储系统通过扩展集群服务器规模来提高系统存储容量、计算量和性能的能.力。

    ’线性可扩展,随着集群规模的增加,系统的整体性能与服务器数量呈线性关系

     

    性能分析

     

    数据分布

    哈希分布,

    顺序分布

    自动负载均衡。

    分布式存储系统的一个基本要求就是透明性,包括数据分布透明性,数据迁移透明性,数据复制透明性,故障处理透明性。

    哈希分布

    根据数据的某一种特征计算哈希值,将哈希值与集群中的服务器建立映射关系,从而将不同哈希值的数据分布到不同的服务器上:

    一致性哈希


    顺序分布

    哈希散列破坏了数据的有序性,只支持随机读取操作,不能够支持顺序扫描。

    顺序分布在分布式表格系统中比较常见,


    负载均衡

    分布式存储系统的每个集群中一般有,一个总控节点(根据全局负载信息进行整体调度),其他节点为工作节点,

    工作节点通过心跳包(Heartbeat,定时发送)将节点负载相关的信息,

    负载均衡操作需要控制节奏,负载均衡操作需要做到比较平滑

     

    复制

    数据在系统中一般存储多个副本。当某个副本所在的存储节点出现故障时,分布式存储系统能够自动将服务切换到其他的副本,从而实现自动容错。

    复制协议:强同步复制(保证主备副本之间的一致性),异步复制(可用性相对较好,但是一致性得不到保障)

    一致性和可用性是矛盾的


    致性与可用性

    eric Brewer教授提出一个著名的CAP理论:一致性(consistent),可用性(availability),分区可容忍性(tolerance of Network partition)三者不能同时满足

    一致性:读操作总是能读取到之前完成的写操作结果

    可用性:读写操作在羊台机器发生故障的情况下仍然能够正常执行

    分区可容忍性:机器故障、网络故障、机房停电等异常情况下仍然能够满足一致性和可用性。

     

    容错

    容错是分布式存储系统设i日勺重要目标,只有实现了自动化容错,才能减少人工运维成本,实现分布式存储的规模效。

    常见故障


    故障检测

    :故障检测,心跳是一种很自然的想法。


    故障恢复

    分布式存储系统分为两种结构:单层结构和双层结构。

    单层结构的分布式存储系统维护了多个副木,

    两层结构的分布式存储系统会将所有的数据持久化写人底层的分布式文件系统,每个数据分片同一时刻只有一个提供服务的节点::

    节点故障会影响系统服务,在故障检测以及故障恢复的过程中,不能提供写服务及强一致性读服务。

    故障检测时间,故障恢复时间


     

    可扩展性

    通过增加副本个数或者缓存提高读取能力,将数据分片使得每个分片可以被分配到不同的工作节点以实现分布式处理,把数据复制到多个数据中心

    总控节点(执行全局调度,;维护文件系统目录树)

    用于维护数据分布信息,执行工作机管理,数据定位,故障检测和恢复,负载均衡等全局调度工作:

    数据库扩容

    主从复制提高系统的读取能力,通过垂直拆分和水平拆分将数据分布到多个存储节点,通过主从复制将系统扩展到多个数据中心。

    常.见的做法为双倍扩容,即将每个分片的数据拆分为两个分片,扩容的过程中需要迁移一半的数据到新加人的存储节点。

    异构系统


    大规模分布式存储系统要求具有线性可扩展性

    为了实现线性可扩展性,存储系统的存储节点之间是异构的

    异构系统将数据划分为很多大小接近的分片,每个分片的多个副本可以分布到集群中的任何一个存储节点。

     

    分布式协议

    租约,复制协议,一致性协议。两阶段提交协议和Paxos协议最具有代表性。

    paxos协议用于确保多个节点对某个投票达成一致。

    两阶段提交协议

    实现分布式事务

    两阶段提交协议可能面临两种故障: 事务参与者发生故障。协调者发生故障。

    Paxos协议

    :解决多个节点之间的一致性问题。

    分布式锁服务,全局命名和配置服务

    paxos协议需要考虑两个问题:正确性,即只有一个提议值会生效;可终止性,即最后总会有一个提议值生效。

    Paxos与2PC

    Paxos协议用于保证同一个数据分片的多个副木之间的数据一致性。

    2PC协议用于保证属于多个数据分片上的操作的原子性。

    paxos协议有两种用法:一种用法是用它来实现全局的锁服务或者命名和配置服务,另外一种用法是用它来将用户数据复制到多个数据中心,

    2PC协议最大的缺陷在于无法处理协调者宕机问题。

    2PC和Paxos协议结合起来,通过2PC保证多个数据分片上的操作的原子性,通过Paxos协议实现同一个数据分片的多个副本之间的一致性。

    通过paxos协议解决2PC协议中协调者宕机问题。

     

    跨机房部署

    数据同步以及服务切换

    集群整体切换、单个集群跨机房、Paxcs选主副本。

    集群整体切换(常用)


    异步模式,那么,备机房的数据总是落后于主机房

    主机房整体出现故障时,有两种选择:

    将服务切换到备机房(手工),忍受数据丢失的风险。停止服务,直到主机房恢复为止。

    强同步模式

    备机房的数据和主机房保持一致。

    自动切换的方式,即通过分布式锁服务检测主机房的服务,当主机房出现故障时,自动将备机房切换为主机房。

    单个集群跨机房

    单个集群部署到多个机房,允许不同数据分片的主副本位于不同的机房


    尽量将同一个数据分片的多个副本分布到多个机房,从而防止单个机房出现故障而影响正常服务

    Paxos选主副本

    降低对总控节点的依赖,缺点在于工程复杂度太高,很难在线下模拟所有的异常情况。


    展开全文
  • 关于分布式存储

    千次阅读 2016-08-11 22:30:47
    分布式存储存在的风险,其实就是因为“共享”、“大数据量”、“高性能”和X86服务器+廉价的磁盘为载体之间的矛盾所产生的,不是有些读者说的“数据架构”的问题。其实任何存储都存在这个问题,只是分布式存储更严重...
  • (一)分布式存储综述

    万次阅读 多人点赞 2017-03-17 20:30:02
    这篇博客主要来总结一下分布式存储系统的历史,发展以及特性,从而对分布式存储系统有一个大概的了解,主要从一下几个部分来介绍分布式存储分布式存储概念 分布式文件系统的发展 分布式存储系统的分类 分布式存储...
  • 分布式存储: 首先是文件在HDFS上面以128M块大小存储(3份),这三块是在不同节点的(机架感知),我觉的好处是容错还有当计算是这个节点资源不够可以去块所在的另一节点执行,不用拉取数据。 可以通过fs....
  • CentOS 7 部署 Ceph 分布式存储架构

    万次阅读 2021-07-11 07:42:14
    CentOS 7 部署 Ceph 分布式存储架构
  • 分布式存储技术

    2013-05-01 00:21:47
    分布式存储技术 分布式存储概念 与目前常见的集中式存储技术不同,分布式存储技术并不是将数据存储在某个或多个特定的节点上,而是通过网络使用企业中的每台机器上的磁盘空间,并将这些分散的存储资源构成一个虚拟...
  • 分布式存储综述、存储原理与设计

    千次阅读 2019-07-04 16:13:53
    目录 分布式存储概念 分布式文件系统的发展 分布式存储系统的分类 ...这篇博客主要来总结一下分布式存储系统的历史,发展以及特性,从而对分布式存储系统有一个大概的了解,主要从一下几个部分来介绍分布式存储...
  • 对于分布式存储一直有一个疑问:横向扩展(Scale Out)、弹性伸缩、敏捷业务、开箱即用,外加成本优势...首先分布式存储会蚕食增量存储市场,然后随着用户对于技术理解的不断加深,最终将一统江湖。分布式存储称雄市场...
  • 文章目录分布式存储顺序分布哈希分布顺序分布VS哈希分布集群架构 分布式存储 了解Redis集群原理之前我们先来梳理一下分布式存储的相关知识 拆分在算法中是一个非常重要的思想,当你的数据集巨大时,你可以按照特定...
  • 你信不信早就有分布式存储了?至少40年前左右就有了吧。不说概念,咱们说30年前的,虚拟内存! 虚拟内存-物理内存 虚拟内存连续的一片空间,在实际的物理内存地址空间是连续的吗?显然没有!   一开始是段,...
  • 从Cassandra到分布式存储系统- 开场
  • 分布式存储要点分析引言1 宏观架构2 监控中心2.1 Pull状态2.2 Observe状态2.3 Work状态2.3.1 节点竞选2.3.2 写数据流程2.3.3 数据修复2.3.4 节点替换3 虚拟节点3.1 数据写入3.2 数据迁移3.3 扩展节点3.4 收缩节点4 ...
  • 分布式数据存储理解

    2018-07-12 12:27:13
    分布式架构中读和写都有其考虑:读:先读cache缓存,没有读到就读取从数据库,然后set进入缓存。这个流程是公认的没有异议写:有两种考虑方法,两者都有其缺陷1.先del缓存,后update数据库,缺点是在读写并发时会...
  • 分布式存储系统概述

    千次阅读 2015-03-18 20:31:30
    云计算、大数据,这些热点词汇,后台的基础设施离开不了分布式存储系统,它的两个特点,一是规模大,二是成本低。其实分布式系统的设计是根据需求来变化的,那么我们接下来就看,我们需要存储哪些数据,以及,分布式...
  • 随着人工智能、机器学习领域技术的持续进步,以及国家“新基建”战略的推进,新的技术和应用,加快了传统行业数字化转型,数据呈几何级增长。海量数据在被分析、挖掘中创造出无限价值。...分布式存储最早是由
  • 在此,跟大家分享交流心得,或有助你更好地理解和使用分布式存储: FISCO BCOS 2.0的分布式存储采用库表风格,CRUD操作符合业务习惯。 不用合约存储变量模式,解构了合约和数据的内嵌式耦合,合约升级更...
  • 整个大数据处理的体系,按我的理解可以分为两个部分,一个是分布式存储系统、另一个是分布式计算框架。分布式存储系统主流是HadoopDFS,其他还有Ceph和Swift。分布式计算框架主流是MapReduce,Storm和Spark。 首先...
  • Ceph分布式存储架构搭建

    万次阅读 多人点赞 2019-07-26 19:54:11
    随着OpenStack日渐成为开源云计算的标准软件栈,Ceph也已经成为OpenStack的首选后端存储。Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。 ceph官方文档 http://docs.ceph.org.cn/ ceph...
  • 海量分布式存储系统Doris

    千次阅读 2020-10-11 22:09:26
    Doris是一个海量分布式KV存储系统,其设计目标是支持中等规模高可用、可伸缩的KV存储集群。跟主流的NoSQL系统HBase相比,其具有...分布式存储系统的高可用架构 在系统架构层面,保证高可用的主要手段是冗余:服务器热备
  • 分布式存储技术及应用

    万次阅读 2012-04-12 13:54:36
    1百万亿亿 (1024)。毫无疑问,各个大型网站也都存储着海量的数据,这些...分布式存储技术就是为了解决这个问题而发展起来的技术,下面让将会详细介绍这个技术及应用。 分布式存储概念 与目前常见的集中式存储
  • PacificA:微软设计的分布式存储框架

    千次阅读 2017-12-04 09:24:00
    PacificA:微软设计的分布式存储框架 随着信息量的急剧增长,大规模的分布式存储系统变得越来越重要。这些系统往往采用廉价的商用机器或硬件,失效出错成为了分布式存储系统的常态,因此,容错是这类系统实现...
  • 笔者最近在学习,了解当前流行的若干分布式存储系统。为什么这么做呢?因为笔者比较了解HDFS,但是其它同等类型的存储系统知道的不多,想借此学习比较一番,希望能够做到触类旁通吧。本文可能不会阐述的很具体,...
  • 进一步分布式的限定,我们这里讨论的是部署在同一个机房内的,由商用服务器构成的分布式存储系统。跨机房,跨地域的分布式系统暂不讨论。作为第一篇,我们先罗列定义问题,并说明这些问题整个系统的意义。每个...
  • 一下为个人结合其他人对分布式存储 所需的技能进行总结,绘制成如下图谱,方便针对性学习。 这里对分布式存储系统接触较多的是ceph,所以在分布式存储系统分治上偏向ceph的学习。 如有分类有问题或者分支不合理,欢迎...
  • [Mark]分布式存储必读论文

    千次阅读 2015-07-11 16:23:34
    [Mark]分布式存储必读论文 分布式存储泛指存储存储和管理数据的系统, 与无状态的应用服务器不同, 如何处理各种故障以保证数据一致,数据不丢, 数据持续可用, 是分布式存储系统的核心问题,也是极具挑战...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 210,604
精华内容 84,241
关键字:

对分布式存储的理解