扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
分布式系统在互联网时代,尤其是大数据时代到来之后,成为了每个程序员的必备技能之一。分布式系统从上个世纪80年代就开始有了不少出色的研究和论文,我在这里只列举最近15年范围以内我觉得有重大影响意义的15篇论文(15 within 15)。
创新互联公司专注于成都做网站、网站设计、网页设计、网站制作、网站开发。公司秉持“客户至上,用心服务”的宗旨,从客户的利益和观点出发,让客户在网络营销中找到自己的驻足之地。尊重和关怀每一位客户,用严谨的态度对待客户,用专业的服务创造价值,成为客户值得信赖的朋友,为客户解除后顾之忧。
1. The Google File System: 这是分布式文件系统领域划时代意义的论文,文中的多副本机制、控制流与数据流隔离和追加写模式等概念几乎成为了分布式文件系统领域的标准,其影响之深远通过其5000+的引用就可见一斑了,Apache Hadoop鼎鼎大名的HDFS就是GFS的模仿之作;
2. MapReduce: Simplified Data Processing on Large Clusters:这篇也是Google的大作,通过Map和Reduce两个操作,大大简化了分布式计算的复杂度,使得任何需要的程序员都可以编写分布式计算程序,其中使用到的技术值得我们好好学习:简约而不简单!Hadoop也根据这篇论文做了一个开源的MapReduce;
3. Bigtable: A Distributed Storage System for Structured Data:Google在NoSQL领域的分布式表格系统,LSM树的最好使用范例,广泛使用到了网页索引存储、YouTube数据管理等业务,Hadoop对应的开源系统叫HBase(我在前公司任职时也开发过一个相应的系统叫BladeCube,性能较HBase有数倍提升);
4. The Chubby lock service for loosely-coupled distributed systems:Google的分布式锁服务,基于Paxos协议,这篇文章相比于前三篇可能知道的人就少了,但是其对应的开源系统zookeeper几乎是每个后端同学都接触过,其影响力其实不亚于前三篇;
5. Finding a Needle in Haystack: Facebook's Photo Storage:facebook的在线图片存储系统,目前来看是对小文件存储的最好解决方案之一,facebook目前通过该系统存储了超过300PB的数据,一个师兄就在这个团队工作,听过很多有意思的事情(我在前公司的时候开发过一个类似的系统pallas,不仅支持副本,还支持Reed Solomon-LRC,性能也有较多优化);
6. Windows Azure Storage: a highly available cloud storage service with strong consistency:windows azure的总体介绍文章,是一篇很好的描述云存储架构的论文,其中通过分层来同时保证可用性和一致性的思路在现实工作中也给了我很多启发;
7. GraphLab: A New Framework for Parallel Machine Learning:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟;
8. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for
In-Memory Cluster Computing:其实就是 Spark,目前这两年最流行的内存计算模式,通过RDD和lineage大大简化了分布式计算框架,通常几行scala代码就可以搞定原来上千行MapReduce代码才能搞定的问题,大有取代MapReduce的趋势;
9. Scaling Distributed Machine Learning with the Parameter Server:百度少帅李沐大作,目前大规模分布式学习各家公司主要都是使用ps,ps具备良好的可扩展性,使得大数据时代的大规模分布式学习成为可能,包括Google的深度学习模型也是通过ps训练实现,是目前最流行的分布式学习框架,豆瓣的开源系统paracell也是ps的一个实现;
10. Dremel: Interactive Analysis of Web-Scale Datasets:Google的大规模(近)实时数据分析系统,号称可以在3秒相应1PB数据的分析请求,内部使用到了查询树来优化分析速度,其开源实现为Drill,在工业界对实时数据分析也是比价有影响力;
11. Pregel: a system for large-scale graph processing: Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi);
12. Spanner: Google's Globally-Distributed Database:这是第一个全球意义上的分布式数据库,Google的出品。其中介绍了很多一致性方面的设计考虑,简单起见,还采用了GPS和原子钟确保时间最大误差在20ns以内,保证了事务的时间序,同样在分布式系统方面具有很强的借鉴意义;
13. Dynamo: Amazon’s Highly Available Key-value Store:Amazon的分布式NoSQL数据库,意义相当于BigTable对于Google,于BigTable不同的是,Dynamo保证CAP中的AP,C通过vector clock做弱保证,对应的开源系统为Cassandra;
14. S4: Distributed Stream Computing Platform:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台;
15. Storm @Twitter:这个系统不多说,开启了流式计算的新纪元,几乎是所有公司流式计算的首选,绝对值得关注;
大数据时代数据管理方式研究
1数据管理技术的回顾
数据管理技术主要经历了人工管理阶段、文件系统阶段和数据库系统阶段。随着数据应用领域的不断扩展,数据管理所处的环境也越来越复杂,目前广泛流行的数据库技术开始暴露出许多弱点,面临着许多新的挑战。
1.1 人工管理阶段
20 世纪 50 年代中期,计算机主要用于科学计算。当时没有磁盘等直接存取设备,只有纸带、卡片、磁带等外存,也没有操作系统和管理数据的专门软件。该阶段管理的数据不保存、由应用程序管理数据、数据不共享和数据不具有独立性等特点。
1.2 文件系统阶段
20 世纪 50 年代后期到 60 年代中期,随着计算机硬件和软件的发展,磁盘、磁鼓等直接存取设备开始普及,这一时期的数据处理系统是把计算机中的数据组织成相互独立的被命名的数据文件,并可按文件的名字来进行访问,对文件中的记录进行存取的数据管理技术。数据可以长期保存在计算机外存上,可以对数据进行反复处理,并支持文件的查询、修改、插入和删除等操作。其数据面向特定的应用程序,因此,数据共享性、独立性差,且冗余度大,管理和维护的代价也很大。
1.3数据库阶段
20 世纪 60 年代后期以来,计算机性能得到进一步提高,更重要的是出现了大容量磁盘,存储容量大大增加且价格下降。在此基础上,才有可能克服文件系统管理数据时的不足,而满足和解决实际应用中多个用户、多个应用程序共享数据的要求,从而使数据能为尽可能多的应用程序服务,这就出现了数据库这样的数据管理技术。数据库的特点是数据不再只针对某一个特定的应用,而是面向全组织,具有整体的结构性,共享性高,冗余度减小,具有一定的程序与数据之间的独立性,并且对数据进行统一的控制。
2大数据时代的数据管理技术
大数据(big data),或称巨量资料,指的是所涉及的资料量规模巨大到无法透过目前主流软件工具,在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。大数据有 3 个 V,一是大量化(Volume),数据量是持续快速增加的,从 TB级别,跃升到 PB 级别;二是多样化(Variety),数据类型多样化,结构化数据已被视为小菜一碟,图片、音频、视频等非结构化数据正以传统结构化数据增长的两倍速快速创建;三是快速化 (Velocity),数据生成速度快,也就需要快速的处理能力,因此,产生了“1 秒定律”,就是说一般要在秒级时间范围内给出分析结果,时间太长就失去价值了,这个速度要求是大数据处理技术和传统的数据挖掘技术最大的区别。
2.1 关系型数据库(RDBMS)
20 世纪 70 年代初,IBM 工程师 Codd 发表了著名的论文“A Relational Model of Data for Large Shared DataBanks”,标志着关系数据库时代来临。关系数据库的理论基础是关系模型,是借助于集合代数等数学概念和方法来处理数据库中的数据,现实世界中的实体以及实体之间的联系非常容易用关系模型来表示。容易理解的模型、容易掌握的查询语言、高效的优化器、成熟的技术和产品,使得关系数据库占据了数据库市场的绝对的统治地位。随着互联网 web2.0 网站的兴起,半结构化和非结构化数据的大量涌现,传统的关系数据库在应付 web2.0 网站特别是超大规模和高并发的 SNS(全称 Social Networking Services,即社会性网络服务) 类型的 web2.0 纯动态网站已经显得力不从心,暴露了很多难以克服的问题。
2.2 noSQL数据库
顺应时代发展的需要产生了 noSQL数据库技术,其主要特点是采用与关系模型不同的数据模型,当前热门的 noSQL数据库系统可以说是蓬勃发展、异军突起,很多公司都热情追捧之,如:由 Google 公司提出的 Big Table 和 MapReduce 以及 IBM 公司提出的 Lotus Notes 等。不管是那个公司的 noSQL数据库都围绕着大数据的 3 个 V,目的就是解决大数据的 3个 V 问题。因此,在设计 noSQL 时往往考虑以下几个原则,首先,采用横向扩展的方式,通过并行处理技术对数据进行划分并进行并行处理,以获得高速的读写速度;其次,解决数据类型从以结构化数据为主转向结构化、半结构化、非结构化三者的融合的问题;再次,放松对数据的 ACID 一致性约束,允许数据暂时出现不一致的情况,接受最终一致性;最后,对各个分区数据进行备份(一般是 3 份),应对节点失败的状况等。
对数据的应用可以分为分析型应用和操作型应用,分析型应用主要是指对大量数据进行分类、聚集、汇总,最后获得数据量相对小的分析结果;操作型应用主要是指对数据进行增加、删除、修改和查询以及简单的汇总操作,涉及的数据量一般比较少,事务执行时间一般比较短。目前数据库可分为关系数据库和 noSQL数据库,根据数据应用的要求,再结合目前数据库的种类,所以目前数据库管理方式主要有以下 4 类。
(1)面向操作型的关系数据库技术。
首先,传统数据库厂商提供的基于行存储的关系数据库系统,如 DB2、Oracle、SQL Server 等,以其高度的一致性、精确性、系统可恢复性,在事务处理方面仍然是核心引擎。其次,面向实时计算的内存数据库系统,如 Hana、Timesten、Altibase 等通过把对数据并发控制、查询和恢复等操作控制在内存内部进行,所以获得了非常高的性能,在很多特定领域如电信、证券、网管等得到普遍应用。另外,以 VoltDB、Clustrix 和NuoDB 为代表的 new SQL 宣称能够在保持 ACDI 特性的同时提高了事务处理性能 50 倍 ~60 倍。
(2)面向分析型的关系数据库技术。
首先,TeraData 是数据仓库领域的领头羊,Teradata 在整体上是按 Shared Nothing 架构体系进行组织的,定位就是大型数据仓库系统,支持较高的扩展性。其次,面向分析型应用,列存储数据库的研究形成了另一个重要的潮流。列存储数据库以其高效的压缩、更高的 I/O 效率等特点,在分析型应用领域获得了比行存储数据库高得多的性能。如:MonetDB 和 Vertica是一个典型的基于列存储技术的数据库系统。
(3)面向操作型的 noSQL 技术。
有些操作型应用不受 ACID 高度一致性约束,但对大数据处理需要处理的数据量非常大,对速度性能要求也非常高,这样就必须依靠大规模集群的并行处理能力来实现数据处理,弱一致性或最终一致性就可以了。这时,操作型 noSQL数据库的优点就可以发挥的淋漓尽致了。如,Hbase 一天就可以有超过 200 亿个到达硬盘的读写操作,实现对大数据的处理。另外,noSQL数据库是一个数据模型灵活、支持多样数据类型,如对图数据建模、存储和分析,其性能、扩展性是关系数据库无法比拟的。
(4)面向分析型的 noSQL 技术。
面向分析型应用的 noSQL 技术主要依赖于Hadoop 分布式计算平台,Hadoop 是一个分布式计算平台,以 HDFS 和 Map Reduce 为用户提供系统底层细节透明的分布式基础架构。《Hadoop 经典实践染技巧》传统的数据库厂商 Microsoft,Oracle,SAS,IBM 等纷纷转向 Hadoop 的研究,如微软公司关闭 Dryad 系统,全力投入 Map Reduce 的研发,Oracle 在 2011 年下半年发布 Big Plan 战略计划,全面进军大数据处理领域,IBM 则早已捷足先登“,沃森(Watson)”计算机就是基于 Hadoop 技术开发的产物,同时 IBM 发布了 BigInsights 计划,基于 Hadoop,Netezza 和 SPSS(统计分析、数据挖掘软件)等技术和产品构建大数据分析处理的技术框架。同时也涌现出一批新公司来研究Hadoop 技术,如 Cloudera、MapRKarmashpere 等。
3数据管理方式的展望
通过以上分析,可以看出关系数据库的 ACID 强调数据一致性通常指关联数据之间的逻辑关系是否正确和完整,而对于很多互联网应用来说,对这一致性和隔离性的要求可以降低,而可用性的要求则更为明显,此时就可以采用 noSQL 的两种弱一致性的理论 BASE 和 CAP.关系数据库和 noSQL数据库并不是想到对立的矛盾体,而是可以相互补充的,根据不同需求使用不同的技术,甚至二者可以共同存在,互不影响。最近几年,以 Spanner 为代表新型数据库的出现,给数据库领域注入新鲜血液,这就是融合了一致性和可用性的 newSQL,这种新型思维方式或许会是未来大数据处理方式的发展方向。
4 结束语
随着云计算、物联网等的发展,数据呈现爆炸式的增长,人们正被数据洪流所包围,大数据的时代已经到来。正确利用大数据给人们的生活带来了极大的便利,但与此同时也给传统的数据管理方式带来了极大的挑战。
大数据技术庞大复杂,基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等范畴
查询引擎:Phoenix、Shark、Pig、Hive等
流式计算:storm、Twitter Rainbird等
迭代计算:Apache Hama、Apache Giraph、HaLoop等
离线计算:Hadoop MapReduce、Berkeley Spark等
键值存储:LevelDB、RocksDB、HyperDex、Voldemort等
表格存储:OceanBase、Amazon SimpleDB、Cassandra、HBase等
文件存储:CouchDB、MongoDB、HDFS等
资源管理:Twitter Mesos、Hadoop Yarn
传统数据库仍旧会有一席之地,至于NewSQL的优势又是什么,简单和大家说说:
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题,国外有篇论文pavlo-newsql-sigmodrec,如果根据该文中的分类,Spanner、TiDB、OB算是第一种新架构型,Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种(文中还有第三种云数据库,本文暂不详细介绍)。
基于中间件(包括SDK和Proxy两种形式)+传统关系数据库(分库分表)模式是不是分布式架构?我觉得是的,因为存储确实也分布式了,也能实现横向扩展。但是不是“伪”分布式数据库?从架构先进性来看,这么说也有一定道理。
“伪”主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等,这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战,本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿?画一个简单的架构对比图:
传统数据库面向磁盘设计,基于内存的存储管理及并发控制,不如NewSQL数据库那般高效利用;
中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作,效率相比较低;
NewSQL数据库的分布式事务相比于XA进行了优化,性能更高;
新架构NewSQL数据库存储设计即为基于paxos(或Raft)协议的多副本,相比于传统数据库主从模式(半同步转异步后也存在丢数问题),在实现了真正的高可用、高可靠(RTO30s,RPO=0);
NewSQL数据库天生支持数据分片,数据的迁移、扩容都是自动化的,大大减轻了DBA的工作,同时对应用透明,无需在SQL指定分库分表键。
文档数据库
源起:受Lotus Notes启发。
数据模型:包含了key-value的文档集合
例子:CouchDB, MongoDB
优点:数据模型自然,编程友好,快速开发,web友好,CRUD。
图数据库
源起: 欧拉和图理论。
数据模型:节点和关系,也可处理键值对。
例子:AllegroGraph, InfoGrid, Neo4j
优点:解决复杂的图问题。
关系数据库
源起: E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
数据模型:各种关系
例子:VoltDB, Clustrix, MySQL
优点:高性能、可扩展的OLTP,支持SQL,物化视图,支持事务,编程友好。
对象数据库
源起:图数据库研究
数据模型:对象
例子:Objectivity, Gemstone
优点:复杂对象模型,快速键值访问,键功能访问,以及图数据库的优点。
Key-Value数据库
源起:Amazon的论文 Dynamo 和 Distributed HashTables。
数据模型:键值对
例子:Membase, Riak
优点:处理大量数据,快速处理大量读写请求。编程友好。
BigTable类型数据库
源起:Google的论文 BigTable。
数据模型:列簇,每一行在理论上都是不同的
例子:HBase, Hypertable, Cassandra
优点:处理大量数据,应对极高写负载,高可用,支持跨数据中心, MapReduce。
数据结构服务
源起: ?
数据模型:字典操作,lists, sets和字符串值
例子:Redis
优点:不同于以前的任何数据库
网格数据库
源起:数据网格和元组空间研究。
数据模型:基于空间的架构
例子:GigaSpaces, Coherence
优点:适于事务处理的高性能和高扩展性
2. 什么是NoSQL?
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,
泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储。
(例如谷歌或Facebook每天为他们的用户收集万亿比特的数据)。这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别?
3.1 RDBMS
高度组织化结构化数据
结构化查询语言(SQL)
数据和关系都存储在单独的表中。
数据操纵语言,数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:
A (Atomicity) 原子性
原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储,列存储,文档存储,图形数据库
最终一致性,而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能,高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理:
Consistency(一致性), 数据一致更新,所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理:任何分布式系统只可同时满足二点,没法三者兼顾。
CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,
因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP - 满足一致性,分区容忍性的系统,通常性能不是特别高。
AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。
说明:C:强一致性 A:高可用性 P:分布式容忍性
举例:
CA:传统Oracle数据库
AP:大多数网站架构的选择
CP:Redis、Mongodb
注意:分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用,其实并不需要强一致性。
因此牺牲C换取P,这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目:阿里巴巴商品信息的存放。
去 IOE 化。
ps:I 是指 IBM 的小型机,很贵的,好像好几万一台;O 是指 Oracle 数据库,也很贵的,好几万呢;M 是指 EMC 的存储设备,也很贵的。
难点:
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流