标签：cap、分布式存储
一、大数据
1、什么是大数据
大数据是指无法在一定时间内用常规软件工具对其内容进行抓取、管理和处理的数据集合。大数据技术，是指从各种各样类型的数据中，快速获得有价值信息的能力。适用于大数据的技术，包括大规模并行处理（MPP）数据库，数据挖掘电网，分布式文件系统，分布式数据库，云计算平台，互联网，和可扩展的存储系统。
2、大数据的特点
容量（Volume）：数据的大小决定所考虑的数据的价值的和潜在的信息；
种类（Variety）：数据类型的多样性；
速度（Velocity）：指获得数据的速度；
可变性（Variability）：妨碍了处理和有效地管理数据的过程；
真实性（Veracity）：数据的质量；
复杂性（Complexity）：数据量巨大，来源多渠道；
3、大数据的分析基础
可视化分析。大数据分析的使用者有大数据分析专家，同时还有普通用户，但是他们二者对于大数据分析最基本的要求就是可视化分析，因为可视化分析能够直观的呈现大数据特点，同时能够非常容易被读者所接受，就如同看图说话一样简单明了。
数据挖掘算法。大数据分析的理论核心就是数据挖掘算法，各种数据挖掘的算法基于不同的数据类型和格式才能更加科学的呈现出数据本身具备的特点，也正是因为这些被全世界统计学家所公认的各种统计方法（可以称之为真理）才能深入数据内部，挖掘出公认的价值。另外一个方面也是因为有这些数据挖掘的算法才能更快速的处理大数据，如果一个算法得花上好几年才能得出结论，那大数据的价值也就无从说起了。
预测性分析。大数据分析最终要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学的建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。
语义引擎。非结构化数据的多元化给数据分析带来新的挑战，我们需要一套工具系统的去分析，提炼数据。语义引擎需要设计到有足够的人工智能以足以从数据中主动地提取信息。
数据质量和数据管理。大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。
4、大数据的技术
数据采集：ETL工具负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。
数据存取：关系数据库、NOSQL、SQL等。
基础架构：云存储、分布式文件存储等。
数据处理：自然语言处理(NLP，Natural Language Processing)是研究人与计算机交互的语言问题的一门学科。处理自然语言的关键是要让计算机"理解"自然语言，所以自然语言处理又叫做自然语言理解(NLU，Natural Language Understanding)，也称为计算语言学(Computational Linguistics。一方面它是语言信息处理的一个分支，另一方面它是人工智能(AI, Artificial Intelligence)的核心课题之一。
统计分析：假设检验、显著性检验、差异分析、相关分析、T检验、方差分析、卡方分析、偏相关分析、距离分析、回归分析、简单回归分析、多元回归分析、逐步回归、回归预测与残差分析、岭回归、logistic回归分析、曲线估计、因子分析、聚类分析、主成分分析、因子分析、快速聚类法与聚类法、判别分析、对应分析、多元对应分析（最优尺度分析）、bootstrap技术等等。
数据挖掘：分类 （Classification）、估计（Estimation）、预测（Prediction）、相关性分组或关联规则（Affinity grouping or association rules）、聚类（Clustering）、描述和可视化、Description and Visualization）、复杂数据类型挖掘(Text, Web ,图形图像，视频，音频等)
模型预测：预测模型、机器学习、建模仿真。
结果呈现：云计算、标签云、关系图等。
5、大数据的处理
大数据处理之一：采集
大数据的采集是指利用多个数据库来接收发自客户端（Web、App或者传感器形式等）的数据，并且用户可以通过这些数据库来进行简单的查询和处理工作。在大数据的采集过程中，其主要特点和挑战是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作，比如火车票售票网站和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间进行负载均衡和分片的确是需要深入的思考和设计。
大数据处理之二：导入/预处理
虽然采集端本身会有很多数据库，但是如果要对这些海量数据进行有效的分析，还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库，或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作。也有一些用户会在导入时使用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。 导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常会达到百兆，甚至千兆级别。
大数据处理之三：统计/分析
统计与分析主要利用分布式数据库，或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC的GreenPlum、Oracle的Exadata，以及基于MySQL的列式存储Infobright等，而一些批处理，或者基于半结构化数据的需求可以使用Hadoop。统计与分析这部分的主要特点和挑战是分析涉及的数据量大，其对系统资源，特别是I/O会有极大的占用。
大数据处理之四：挖掘
与前面统计和分析过程不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，从而实现一些高级别数据分析的需求。比较典型算法有用于聚类的Kmeans、用于统计学习的SVM和用于分类的NaiveBayes，主要使用的工具有Hadoop的Mahout等。该过程的特点和挑战主要是用于挖掘的算法很复杂，并且计算涉及的数据量和计算量都很大，常用数据挖掘算法都以单线程为主。
6、大数据与云计算的关系
7、大数据时代存储所面对的问题
容量问题
这里所说的“大容量”通常可达到PB级的数据规模，因此，海量数据存储系统也一定要有相应等级的扩展能力。与此同时，存储系统的扩展一定要简便，可以通过增加模块或磁盘柜来增加容量，甚至不需要停机。基于这样的需求，客户现在越来越青睐Scale-out架构的存储。Scale-out集群结构的特点是每个节点除了具有一定的存储容量之外，内部还具备数据处理能力以及互联设备，与传统存储系统的烟囱式架构完全不同，Scale-out架构可以实现无缝平滑的扩展，避免存储孤岛。
“大数据”应用除了数据规模巨大之外，还意味着拥有庞大的文件数量。因此如何管理文件系统层累积的元数据是一个难题，处理不当的话会影响到系统的扩展能力和性能，而传统的NAS系统就存在这一瓶颈。所幸的是，基于对象的存储架构就不存在这个问题，它可以在一个系统中管理十亿级别的文件数量，而且还不会像传统存储一样遭遇元数据管理的困扰。基于对象的存储系统还具有广域扩展能力，可以在多个不同的地点部署并组成一个跨区域的大型存储基础架构。
延迟问题
“大数据”应用还存在实时性的问题。特别是涉及到与网上交易或者金融类相关的应用。举个例子来说，网络成衣销售行业的在线广告推广服务需要实时的对客户的浏览记录进行分析，并准确的进行广告投放。这就要求存储系统在必须能够支持上述特性同时保持较高的响应速度，因为响应延迟的结果是系统会推送“过期”的广告内容给客户。这种场景下，Scale-out架构的存储系统就可以发挥出优势，因为它的每一个节点都具有处理和互联组件，在增加容量的同时处理能力也可以同步增长。而基于对象的存储系统则能够支持并发的数据流，从而进一步提高数据吞吐量。
有很多“大数据”应用环境需要较高的IOPS性能(IOPS (Input/Output Operations Per Second)，即每秒进行读写（I/O）操作的次数，多用于数据库等场合，衡量随机访问的性能)，比如HPC高性能计算。此外，服务器虚拟化的普及也导致了对高IOPS的需求，正如它改变了传统IT环境一样。为了迎接这些挑战，各种模式的固态存储设备应运而生，小到简单的在服务器内部做高速缓存，大到全固态介质的可扩展存储系统等等都在蓬勃发展。
并发访问一旦企业认识到大数据分析应用的潜在价值，他们就会将更多的数据集纳入系统进行比较，同时让更多的人分享并使用这些数据。为了创造更多的商业价值，企业往往会综合分析那些来自不同平台下的多种数据对象。包括全局文件系统在内的存储基础设施就能够帮助用户解决数据访问的问题，全局文件系统允许多个主机上的多个用户并发访问文件数据，而这些数据则可能存储在多个地点的多种不同类型的存储设备上。
安全问题
某些特殊虑行业的应用，比如金融数据、医疗信息以及政府情报等都有自己的安全标准和保密性需求。虽然对于IT管理者来说这些并没有什么不同，而且都是必须遵从的，但是，大数据分析往往需要多类数据相互参考，而在过去并不会有这种数据混合访问的情况，因此大数据应用也催生出一些新的、需要考的安全性问题。
成本问题
“大”，也可能意味着代价不菲。而对于那些正在使用大数据环境的企业来说，成本控制是关键的问题。想控制成本，就意味着我们要让每一台设备都实现更高的“效率”，同时还要减少那些昂贵的部件。目前，像重复数据删除等技术已经进入到主存储市场，而且现在还可以处理更多的数据类型，这都可以为大数据存储应用带来更多的价值，提升存储效率。在数据量不断增长的环境中，通过减少后端存储的消耗，哪怕只是降低几个百分点，都能够获得明显的投资回报。此外，自动精简配置、快照和克隆技术的使用也可以提升存储的效率。
很多大数据存储系统都包括归档组件，尤其对那些需要分析历史数据或需要长期保存数据的机构来说，归档设备必不可少。从单位容量存储成本的角度看，磁带仍然是最经济的存储介质，事实上，在许多企业中，使用支持TB级大容量磁带的归档系统仍然是事实上的标准和惯例。
对成本控制影响最大的因素是那些商业化的硬件设备。因此，很多初次进入这一领域的用户以及那些应用规模最大的用户都会定制他们自己的“硬件平台”而不是用现成的商业产品，这一举措可以用来平衡他们在业务扩展过程中的成本控制战略。为了适应这一需求，现在越来越多的存储产品都提供纯软件的形式，可以直接安装在用户已有的、通用的或者现成的硬件设备上。此外，很多存储软件公司还在销售以软件产品为核心的软硬一体化装置，或者与硬件厂商结盟，推出合作型产品。
数据的积累
许多大数据应用都会涉及到法规遵从问题，这些法规通常要求数据要保存几年或者几十年。比如医疗信息通常是为了保证患者的生命安全，而财务信息通常要保存7年。而有些使用大数据存储的用户却希望数据能够保存更长的时间，因为任何数据都是历史记录的一部分，而且数据的分析大都是基于时间段进行的。要实现长期的数据保存，就要求存储厂商开发出能够持续进行数据一致性检测的功能以及其他保证长期高可用的特性。同时还要实现数据直接在原位更新的功能需求。
灵活性
大数据存储系统的基础设施规模通常都很大，因此必须经过仔细设计，才能保证存储系统的灵活性，使其能够随着应用分析软件一起扩容及扩展。在大数据存储环境中，已经没有必要再做数据迁移了，因为数据会同时保存在多个部署站点。一个大型的数据存储基础设施一旦开始投入使用，就很难再调整了，因此它必须能够适应各种不同的应用类型和数据场景。
应用感知
最早一批使用大数据的用户已经开发出了一些针对应用的定制的基础设施，比如针对政府项目开发的系统，还有大型互联网服务商创造的专用服务器等。在主流存储系统领域，应用感知技术的使用越来越普遍，它也是改善系统效率和性能的重要手段，所以，应用感知技术也应该用在大数据存储环境里。
小用户怎么办？
依赖大数据的不仅仅是那些特殊的大型用户群体，作为一种商业需求，小型企业未来也一定会应用到大数据。我们看到，有些存储厂商已经在开发一些小型的“大数据”存储系统，主要吸引那些对成本比较敏感的用户。
8、数据的换算
最小的基本单位是bit，按顺序给出所有单位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。
它们按照进率1024（2的十次方）来计算：
1 Byte =8 bit
1 KB = 1,024 Bytes = 8192 bit
1 MB = 1,024 KB = 1,048,576 Bytes
1 GB = 1,024 MB = 1,048,576 KB
1 TB = 1,024 GB = 1,048,576 MB
1 PB = 1,024 TB = 1,048,576 GB
1 EB = 1,024 PB = 1,048,576 TB
1 ZB = 1,024 EB = 1,048,576 PB
1 YB = 1,024 ZB = 1,048,576 EB
1 BB = 1,024 YB = 1,048,576 ZB
1 NB = 1,024 BB = 1,048,576 YB
1 DB = 1,024 NB = 1,048,576 BB
二、分布式存储系统
1、简介
分布式存储系统，是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
2、分布式系统的难点
缺乏全局时钟
面对故障的独立性
处理单点故障
冗余
降低单点故障的影响
事务类的挑战
ACID
2pc（两段式提交）、最终一致、BASE、CAP、Paxos
3、X/Open 分布式事务处理模型
X/Open 分布式事务处理 (DTP) 模型包括大量控制如何处理分布式事务的相关组件。 这些组件包括：
应用程序 (AP) ：也就是应用程序，可以理解为使用DTP的程序
事务管理器 (TM) ：事务管理器，负责协调和管理事务，提供给AP应用程序编程接口以及管理资源管理器
资源管理器 (RM)：资源管理器，这里可以理解为一个DBMS系统，或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制。资源必须实现XA定义的接口
下图对此模型进行了说明并显示这些组件之间的关系。
其中在DTP定了以下几个概念：
事务：一个事务是一个完整的工作单元，由多个独立的计算任务组成，这多个任务在逻辑上是原子的。
全局事务：对于一次性操作多个资源管理器的事务，就是全局事务
分支事务：在全局事务中，某一个资源管理器有自己独立的任务，这些任务的集合作为这个资源管理器的分支任务
控制线程：用来表示一个工作线程，主要是关联AP,TM,RM三者的一个线程，也就是事务上下文环境。简单的说，就是需要标识一个全局事务以及分支事务的关系。
两阶段提交协议：如果一个事务管理器管理着多个资源管理器，如果控制全局事务和分支事务，在DTP里面说明两阶段提交的协议
第一阶段：准备阶段 ，事务管理器通知资源管理器准备分支事务，资源管理器告之事务管理器准备结果
第二阶段：提交阶段 ，事务管理器通知资源管理器提交分支事务，资源管理器告之事务管理器结果
下面一幅图演示了正常情况下的两阶段提交，
4、处理单点故障的方法说明
单机存储随着业务的增长会遇到性能与单点故障问题。通常有两种解决方案：
数据分布：就是把数据分块存在不同的服务器上（分库分表）。
数据复制：让所有的服务器都有相同的数据，提供相当的服务。
这两种方法都能解决性能上的问题，一般结合使用。而对于数据丢失的问题，我们只能通过第二种方法来完成——数据的冗余存储。但是加入更多的机器，会导致事情变得复杂起来，尤其是分布式事务处理，也就是多台服务器之间的数据如何保持一致性，因为原先单机的 ACID 特性在分布式环境下都用不了了。
数据分布 ：
数据分布主要有两种方式：一种是哈希分布，如一致性哈希（Dynamo）；另一种是顺序分布（BigTable）。考虑因素包括读写场景， 即随机还是顺序， 包括如何保证负载均衡从而提高性能等传统的哈希分布算法简单的将哈希值与服务器个数做除法取模映射。但是当服务器上下线时，数据的重新分布会带来大量的数据迁移。
因此有了 一致性哈希算法 。算法思想如下 :给系统中每个节点分配一个随机 token，这些 token 构成一个哈希环。执行数据存放操作时，先计算 Key(主键)的哈希值，然后存放到顺时针方向第一个大于或者等于该哈希值的 token 所在的节点。一致性哈希的优点在于节点加入 / 删除时只会影响到在哈希环中相邻的节点，而对其他节点没影响。增加节点后能很大程度上避免了数据迁移。为了考虑负载均衡，一般还会引入虚拟节点的技术，即一个物理节点会对应着多个虚拟节点（如 Dynamo）。
数据复制 ：
复制协议有两种：强同步复制，异步复制。 区别在于用户的写请求是否需要同步到备副本才可以返回成功。 一致性和可用性是矛盾的。强同步复制协议保证主备副本之间的一致性，但是当备副本出现故障时会影响系统可用性。异步复制协议的可用性较好，但是一致性得不到保障，主副本出现故障时还有数据丢失的可能。
这两种协议都是将主副本的数据以某种形式（多为操作日志）发送到其他副本，这种复制协议称为基于主副本的复制协议。当然还有基于多个存储节点的复制协议。比如下面会介绍的 Dynamo 系统的 NWR 复制协议。
5、一致性模型
弱一致性（Weak）：当你写入一个新值后，读操作在各个数据副本上不保证能读出最新值。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系。
最终一致性（Eventually）：Eventually 是 Weak 的一种特殊情况。当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件、Amazon S3，Google搜索引擎这样的系统。
强一致性（Strong）：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。
从这三种一致型的模型上来说，我们可以看到，Weak 和 Eventually 一般来说是异步冗余的，而Strong一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。
6、分布式事务
事务的支持对于业务是非常重要的特性，数据库在单机下的 ACID 事务特性是比较到位的，而一旦进行分库分表后就要面对一致性和可用性的问题了，这就是分布式事务了。
CAP 原理 ：
在分布式环境下需要考虑数据的一致性和性能的问题，我们要了解下 CAP 理论：
一致性：所有节点在同一时间具有相同的数据。
可用性：保证每个请求不管成功或者失败都有响应。我理解的是系统的性能。
分区容忍性：系统中任意信息的丢失或失败不会影响系统的继续运作。我理解的是系统的抗故障能力。
在分布式系统中，对于这三者不能同时满足。这就是 CAP 理论。 简单地说就是：
要想让数据避免单点故障，就得写多份数据。
写多份的问题会导致数据一致性的问题。
数据一致性的问题又会引发性能问题
Quorum 系统NWR 策略 ：
NWR是一种在分布式存储系统中用于控制一致性级别的策略，应用于 Amazon Dynamo。NWR 模型将 CAP 的选择权交给了用户，由用户自己选择 CAP 中的哪两个。其中，N 代表 N 个备份，W 代表至少写 W 份才认为成功，R 代表至少要读 R 份才认为成功。
如果 W+R>N ，是可以保证强一致性的。因为 W+R > N， 所以 R > N-W，什么意思呢？就是读取的份数必须要大于未成功写的份数，这样至少能读到一份最新值。
如果 W+R<=N，则能够保证最终一致性。
如果我们要高可写的环境，我们可以配置 W=1 R=N。这个时候只要写任何节点成功就认为成功，但是读的时候必须从所有的节点都读出数据。
如果我们要求读的高效率，我们可以配置 W=N R=1。这个时候任何一个节点读成功就认为成功，但是写的时候必须写所有三个节点成功才认为成功。
两阶段提交：
英文 Two Phase Commit，也叫 2PC。两阶段提交经常用于分布式事务，是强一致性算法。简要的说就是分两阶段：
第一阶段，主控节点（协调者）询问所有节点（参与者）是否可以提交操作，参与者回应 yes or no。
第二阶段，协调者根据收到的响应，如果所有参与者都回应 yes，则向所有参与者发送“正式提交”的命令。参与者完成后恢复“完成”消息，协调者收集齐各节点的回应后结束这个 Global Transaction。如果有一个拒绝则给所有参与者发送“回滚操作”。参与者回滚成功后回应“回滚完成”，协调者收集各结点的“回滚”回应后，取消这个 Global Transaction。
2PC说白了就是第一阶段做 Vote，第二阶段做决定的一个算法，相对于单库事务来说就是在提交之前多了准备的阶段。但是也存在着问题，其中一个是同步阻塞操作，这个事情必然会非常大地影响性能。另一个主要的问题是在TimeOut上。因此出现了 3PC，主要是将提交过程分为两步，更多描述见 Wikipedia。
Paxos 算法：
Google Chubby 的作者 Mike Burrows 说过，“世上只有一种一致性算法，那就是 Paxos”，所有其他一致性算法都是Paxos算法的残次版本。
Paxos是一个分布式选举算法， 最大的用途就是保持多个节点数据的一致性。看了好久的 Paxos 算法还是有些迷糊，这里就不给出具体算法了。感兴趣的可以参看 WikiPedia 以及里面给出的示例。
实际上对于一般的开发人员，我们并不需要了解 Paxos 所有细节及如何实现，只需要知道 Paxos 是一个分布式选举算法就够了。当我们以后遇到相似的问题，知道有这样一个技术，可以正确及优雅地解决技术架构上一些难题就够了。
7、小结
Paxos 协议和 2PC 协议在分布式系统中所起的作用并不相同。Paxos 协议用于保证同一个数据分片的多个副本之间的数据一致性。当这些副本分布到不同的数据中心时，这个需求尤其强烈。2PC 协议用于保证属于多个数据分片上的操作的原子性。这些数据分片可能分布在不同的服务器上，2PC 协议保证多台服务器上的操作要么全部成功，要么全部失败。可见 Paxos 的学术地位不一般。
Paxos 协议有两种用法:一种用法是用它来实现全局的锁服务或者命名和配置服务，例如 Google Chubby 以及 Apache Zookeeper 还有全局ID。另外一种用法是用它来将用户数据复制到多个数据中心，例如 Google Megastore 以及 Google Spanner。
2PC 协议最大的缺陷在于无法处理协调者宕机问题。如果协调者宕机，那么，2PC协议中的每个参与者可能都不知道事务应该提交还是回滚，整个协议被阻塞，执行过程中申请的资源都无法释放。因此，常见的做法是将 2PC 和 Paxos 协议结合起来，通过2PC 保证多个数据分片上的操作的原子性，通过 Paxos 协议实现同一个数据分片的多个副本之间的一致性。另外，通过 Paxos 协议解决 2PC 协议中协调者宕机问题。当 2PC协议中的协调者出现故障时，通过 Paxos 协议选举出新的协调者继续提供服务。
下图是几种策略原理的比较：
图中 M/S 是 Master-Slave) 结构，实现简单，但是存在单点故障和数据丢失的问题。M/M 即 Multi-Master，解决了单点故障但是一致性的实现较复杂且存在冲突合并的问题（Vector Clock解决）。从上图我们可以看到，我们基本上来说不可以让所有的项都绿起来，也就是之前说到的著名的CAP理论：一致性，可用性，分区容忍性，你只可能要其中的两个。
摘自：
http://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html
http://wuchong.me/blog/2014/08/07/distributed-storage-system-knowledge/
http://wiki.mbalib.com/wiki/%E5%A4%A7%E6%95%B0%E6%8D%AE
本文出自 “粗茶淡饭” 博客，请务必保留此出处http://cuchadanfan.blog.51cto.com/9940284/1699333
标签：cap、分布式存储
原文地址：http://cuchadanfan.blog.51cto.com/9940284/1699333
