嘉宾介绍：
李明宇：中国科学院软件研究所综合信息系统技术重点实验室云计算与大数据系统研究组负责人。
以下为分享实景全文：
大家好，咱们这个大数据分布式存储系统的分享，是一个系列分享，前面曾经有过两次分享，一次是概述，另一次是分布式对象存储，并且介绍了OpenStack Swift，Swift是OpenStack的分布式对象存储系统。这一次主要是分享纠删码（又称为删除码，英文是ErasureCodes，简写为EC）在大数据分布式存储中的应用，并且以OpenStackSwift为例进行详细阐述，还会指出目前常用的EC方案存在问题，将来可以怎么解决。根据之前的安排，后面还有至少两次，分别是分布式文件系统和分布式块存储。
我先把前两次分享的内容贴出来，大家花一点时间回顾一下，九点半我们正式开始今天的内容，因为这次分享的内容和前面两次分享的内容都相关，所以大家最好还是稍微花个十几到二十分钟时间看一下。
这个是关于大数据分布式存储系统的概述：http://mp.weixin.qq.com/s?__biz=MzA5NDExMTAzNA==& mid=202010155&idx=5&sn=b3bf60dc0861c6e754fd5951287f9e8f&scene=1#rd
第二篇：关于对象存储和OpenStackSwift：http://vdisk.weibo.com/s/quNzEeU3Nh6q
关于这前面两次报告，如果有什么疑问，欢迎大家提问！如果有什么不对的地方，也欢迎大家指出！这次分享的主要内容是前些日子应邀在Cloud Connect大会上做过演讲的。我一开始对这个会议也不太了解，去了以后发现这个会不论是从规模还是从内容上来说，都是很好的，每年九月份在上海举行， 如果群里的同仁们有兴趣，明年也可以来会场听听报告、参与讨论、看看展览，应该能有收获，我这次参会学到不少新东西。
这里我也把cloud connect大会上的ppt以图片形式贴出来，当时应主办方要求，用英语做的ppt，大家多担待了。此次分享主要有图里所列的这么几个部分的内容，因为 Object Storage和Swift在前面介绍过了，所以这里就简单说一说，重点在后面和纠删码（Erasure Codes，以下简称EC）相关的地方。
首先简单回顾一下Object Storage（对象存储）和OpenStack Swift。对象存储有两个特点：1.基于RESTful Web API接收和响应用户请求并传输数据；2.与文件系统复杂的树状结构不同，它采用扁平的数据组织形式，有的分为两层，有的分为三层，例如Swift是Account、Container、Object三层。
与对象存储相并列提到的往往有文件系统和块存储两个概念，块存储是使用体验类似裸硬盘的存储服务、存储设备或者存储系统。对象存储是云计算、大数据和互联网发展中出现的新型存储，从 应用上来说，在大数据和互联网时代，在服务端取代分布式文件系统和NAS的趋势虽然目前尚不是很明显，但是其实是一种历史的必然。因为：1、现在我们对数 据的管理，在服务端并不是依赖于文件夹的树状组织形式，而是使用元数据；2、目前大量移动终端、浏览器访问数据都通过RESTful Web API，而且RESTful Web API的使用越来越普遍，如果使用文件系统作为Web服务器和应用服务器的存储后端，数据读写要通过Web服务器和应用服务器中转，量一大起来，势必会给 Web服务器和应用服务器带来很大的压力，而对象存储能够提供客户端和浏览器能够直接访问的HTTP接口，能够给Web服务器和应用服务器分担很大的压 力；3、对象存储在文件数量很多的情况下，在数据存储的空间效率和数据读写的时间效率上都比分布式文件系统和NAS具有优势。
这几张片子是对OpenStack和Swift的简单介绍，就不多说了，在7月份的分享中都介绍过。这里为了便于大家理解，可以把Object想成文件，Account和Container这两级逻辑上的数据存储区域想成文件夹。
这一章是Swift的部署架构，这个图是从Intel和SwiftStack公司的网站上抓下来的，和我们之前7月份介绍的那个部署架构图有所区别。7月份那个主要是适用于小型swift集群的，这个是中大规模swift集群的部署架构。运行Account Server、Container Server和Object Server的节点称为存储节点（Storage Node），运行Proxy Server的节点称为Proxy。 该图中负载均衡器和认证服务都不是Swift本身的东西，负载均衡可以用LVS等第三方软件或者产品，认证服务也可以用OpenStack Keystone等第三方软件或者产品来实现。生产环境中，StorageNodes要最少有五个节点，每个节点作为一个zone，每个存储节点本身的磁 盘不能做RAID，存储节点不能用虚拟机实现。
Swift在今年夏天一个比较大的变化是发布了一个2.0版本。其中一个重要功能是Storage Policy（存储策略），这个功能在上次7月份分享分布式对象存储的东西的时候，其实社区已经做了很多工作了，但是还没有正式release，所以那次 没有提。存储策略这个功能推出以后，部署Swift存储系统的人（即图中的Depolyer，可以是存储系统的设计实施方、存储服务的运营方等），可以设 计一些存储策略，比如说：让数据存到ssd（性能高、价格高）上还是hdd（性能低、价格低）上；让数据存三副本、两副本还是五副本；用不用纠删码、用什 么参数的纠删码等等。然后使用对象存储系统的人（即图中的Client，可以是租户或者用户），可以根据自己的需要为每个container选择deployer提供的存储策略。
这三幅图分别举例说明了存储策略的三种使用方式。图很清楚，我就不一一解释了，其中低副本数量的存储策略（如两副本），可以用来保存缩略图或者转码视频等数据。下面重点说一下EC这个事情。
EC属于纠错码的一种，用于纠正删除信道中出现的错误。删除信道并不是指发生数据丢失的信道，而是指如果发生数据错误或者丢失（可以看作是错误的一种），我们能够知道是哪一部分数据发生了错误或者丢失。存储系统是一种典型的删除信道。由于删除信道的这种特点，使得一些在二进制对称信道等信道中无法实现纠错的编码，如奇偶校验码，能够纠正删除信道的错误。咱们在盘阵中常用的RAID5，就是使用奇偶校验码纠正一个符号错误的典型应用。
目前应用最广泛的纠删码是ReedSolomon编码，简称RS码。这种编码在1960年就被提出了，过了很多年以后才提出了快速算法并被广泛应用于各种通信系统中，直到近几年才被逐渐应用于各种存储系统中。
这张图示意了纠删码的原理，把数据分割成n块，然后再计算出k个校验块，这n+k个数据块中，任意k个丢失，仍然能够恢复出原来的数据。一般来说，设计存 储系统的纠删码时，要求可靠性不能低于三副本，影响可靠性的因素很多，各个系统的计算结果都不太相同，微软认为在Azure中，n=6，k=3或者 n=12，k=4时，数据存储的可靠性相当于三副本方案。facebook的认为在它们的HDFS系统中，n=10，k=4时可靠性相当于或者略高于三副 本方案。
这四张片子，是Swift中的EC的实现方案。swift中EC的参数n和k是可以选择的。图中给出的是n=3，k=2的例子。用户读写数据的时候，编码 与解码过程在Proxy上进行；如果发生错误，Audit和Reconstruct过程中的EC编解码在storage node上进行。Swift中的EC Coder提供Python接口，并且能够以插件形式使用不同的后端，常用的后端包括C/C++实现的开源软件Jerasure、Intel商用库 ISA-L EC。分布式存储中EC的基本情况和Swift中的应用基本上就是上面说的这样，下面说一下当前的技术手段中存在的问题。
目前使用RS码存在的主要问题是当需要恢复数据时，引起的网络流量和磁盘I/O的增加，以及数据读取（在对象存储中体现为客户端下载）的延迟。因为刚才说的n+k块中，任意一块出错，都需要把所有n+k块数据都读出来，恢复丢失的那一块。
这种错误，不仅仅体现在设备真实的故障上，数据统计表明，一些原因导致临时的数据不能够读取占了绝大部分。这些原因可能包括：1.网络的临时故障，比如网线接触不良、交换机故障等，如果更新网络设备，这些数据的可用性就又恢复了；2.对存储节点进行负载均衡，在 三副本方案中，为了避免对一个存储节点过高并发的访问，往往会暂时阻断后续请求访问该节点（hot storage node），系统会自动将这些请求调度到其他节点上，读取同一份数据的其他副本，但是若采用纠删码方案，如果对包含某个数据块的节点访问阻断了，这时系统 会需要将其他所有的数据块读取出来再重构原数据；3.系统升级，数据中心中，经常使用一种叫做rolling upgrade的方法，对 节点逐个进行升级，这种方法的目的是因为升级过程中可能需要进行系统重启或者服务重启，rolling upgrade方法可以避免大面积的节点重启或者服务重启导致的整体服务不可用，但是在rolling upgrade过程中，一些参与纠删码的存储节点就会暂时不可用，从而导致数据读取时需要进行数据重构。还有别的一些原因，这里就不一一罗列，有数据表 明，数据中心中节点的暂时故障占到了约90%。
这一页图表明了Facebook的HDFS分布式存储系统中使用了纠删码以后，每天为了恢复/重构数据，网络中增加的负载。上述问题就是需要对存储系统中使用的RS码进行改进的原因。但 是，RS码已经很优秀了，有个概念叫做MDS码（Maximum Distance Separable Codes），这种码在占用同样的存储空间时，可以达到最高的纠删能力，而且这是个理论上限，就是说从空间效率的角度来说，不存在超过MDS码的纠删码方 案，RS码就是MDS码的一种。对于如此优秀的编码，如何改进呢？或者说我们能不能对RS码进行改进呢？答案是可以的，因为存储系统具有它自己的特点。大 家想想，上述三种常见导致暂时错误的原因，通常都只会使一组参与编码的数据块中，只有一个块不可用，两个或者更多块同时不可用的概率很低。事实 上，Facebook的数据也证明了这一点。
所以，我们就可以从这个角度出发，着重降低纠删码纠正一个错误时对网络和磁盘I/O带来的压力。这里的方法，主要是有引入编码的局部相关性和符号间的相关性两种方式，微软和Facebook在这方面走在国际前沿，都有相关论文发表，我在此就不再赘述了，感兴趣的同仁可以去查看相关论文。
主要论文和主要思想的示意图都在上面这几张片子里给出了，大家感兴趣的话可以自己去查查，有问题也非常欢迎随时讨论。另外，还有一些别的途径，比如再生 码，比如结合多媒体文件的数据特点减少数据的恢复。这些思路在存储界看来比较新鲜，但如果是熟悉通信编码的同仁，其实这些思路都很自然，再生码是引入了网 络编码，利用多媒体文件的特点减少数据的恢复，是综合考虑了信源编码。信道编码、新源编码、网络编码本身是编码理论不分家的几个部分，所以对于做通信编码 的人来说，这些思路其实都比较自然，只是同时对编码理论和存储系统研究比较深的人可能很少，所以这些方面的实质进展还需要时间。后面说的RS码的改进、再 生码、与信源编码结合等，都是现在学术界在EC-basedDistributed Storage这个方向上比较前沿的topic，我们也在做一些工作，预计会在明年春季发表，如果大家感兴趣，也欢迎一起来做一些事情！
好了，今天的分享就到这里，今天的内容比较多，也比较深，如果有什么问题，欢迎大家随时提出来，也可以私信我。非常感谢这么晚还在的各位同仁以及做记录的志愿者，因为现在已经很晚了，而且是周六晚上！谢谢你们！
嘉宾互动：
刘睿民：李博士，非常精彩！有个小问题，纠删码对性能的影响是不是会导致不太适合于OLTP?
李明宇：刘总，数据库我不是很熟悉，我对您提的这个问题是这样认识的：您看我对存储系统分类的这页片子。
这是我的最新的认识，我觉得已经非常接近真相了，即存储系统实际上是分为块存储、文件系统和对象存储二者并列、数据库三类。而 分布式文件系统最终将被对象存储取代（HDFS是个特例，因为其对MapReduce的天然支持），纠删码在分布式对象存储和分布式文件系统中的应用没有 问题，已经被验证了。而这类系统不是用来支持OLTP的，OLTP应该是数据库的范畴，或者说数据库的外延。那您提的这个问题就变成了纠删码在数据库中应 用是否可行，或者说应该是这个问题的一个子问题。我对数据库了解较少，个人认为，数据库的后端用纠删码将来应该也是可行的，但是究竟应该怎么做，还有待研 究。不知道我的这个认识 @刘睿民 认同吗？
刘睿民：数据库底层的持久化会用到块存储，FS，现在好多开始尝试对象存储了。但在线交易，即OLTP，对持久化时的读写的实时性要求较高。之前普遍用的是块存储，但最近尝试用对象存储的过程中发现实时性能确实不好把握，这是关注的要点。
李明宇： 是的！您说的块存储、FS、对象存储我认为属于数据库的后端，就像swift也可以用server san的lun做后端一样，而server san又属于块存储，所以这三个方向，我觉得不是完全割裂的，是相互联系但是侧重点不同的三个方向。对象存储的性能问题，您具体是遇到什么问题？回头找时 间我去拜访您，咱们细聊：）
陈志成：@刘睿民 ，块存储理论上就比对象存储性能高，但如果针对在线实时性而言，二者可能并不都是重点，数据库系统的“缓存”可能占据主导作用，缓存总空间大小，缓存块片段的大小，与磁盘读写的交换机制等更值得研究。我所用过的PG数据库最为典型 ，对swift没深入分析过其缓存机制。@Microwise 可以看看。
李明宇：@陈志成，PG的缓存我正好也看过，因为当时做数据库虚拟化的时候遇到一些问题，所以就想做一些优化，最后都搞到源码里面去了。这个点我还想讨论讨论，@刘睿民、@陈志成 两位大佬，咱们明天继续。今天有点太晚了。
阮彤：请教一下，现在基于swift的上层应用有哪些？
李明宇：阮老师，请教不敢当。swift的应用包括用来存虚拟机镜像、模板和快照文件；用来存图片和视频；用来存log；用来存静态网页。我 比较清楚的国内的应用有iQIYI、美团；国外的有大名鼎鼎的wikipedia。关于swift的应用，我这里也只是稍微举几个具有代表性的，其实现实 中的案例非常多，比如我们做虚拟化和私有云的几个客户，虚拟机镜像基本都是swift存的，我们有一个case里面视频是用swift，还有一个用 swift来存OA系统里的文档。另外SwiftStack公司有大量的客户，他们的业务都是围绕swift展开的。
阮彤：很想知道如何选择合适的存储方式。比如说，一个有复杂关联的知识库，是用mongoDB，还是直接swift？优劣在哪？
李明宇： 我的理解是如果key/value中value是短文本，首选NoSQL数据库，如果是几百K到几十个G的文件，首选是swift。比如说静态HTML页 面、文档、图片、视频、虚拟机镜像，都是适合存swift的，这些mongoDB估计搞不定。但是反之，如果key是对应的value一段描述文字，这个 每个value的数据量对于swift来说太小了，swift没有针对这种场景做优化。
阮彤：似乎还是偏文件型的。
李明宇：阮老师，是的，我的理解是：对象存储是大数据时代的“文件系统”
阮彤：噢，有点理解了，多谢！
来源：中关村大数据产业联盟
