3.文件系统
文件系统是支撑上层应用的基础,本小节将简要介绍面向大数据处理的文件系统如谷歌分布式文件系统(GFS),以及一些其他的分布式文件系统。
1)分布式文件系统GFS:谷歌自行开发的文件系统GFS[24],是一个基于分布式集群的大型的分布式文件系统,它为MapReduce计算框架提供底层数据存储和数据可靠性。GFS采用廉价普通磁盘,并把磁盘数据出错视为常态,其自动多数据备份存储也增加了可靠性。GFS基本构架中,GFSMaster保存了GFS文件系统的3种元数据:命名空间、Chunk与文件名的映射表、Chunk副本的位置信息,前两个数据通过操作日志提供容错处理能力,第3个数据存储在ChunkServer上,可在Master失效时快速恢复Master上的元数据;GFSChunkServer是用来保存大量实际数据的数据服务器。GFS基本工作过程如下:(1)在程序运行前,数据已经存储在GFS文件系统中,程序执行时应用程序会告诉GFSServer所要访问的文件名或者数据块索引是什么。(2)GFSServer根据文件名和数据块索引在其文件目录空间中查找和定位该文件或数据块,并将这些位置信息回送给应用程序。(3)应用程序根据GFSServer返回的具体Chunk数据块位置信息,直接访问相应的ChunkServer。(4)应用程序直接读取指定位置的
数据进行计算处理。后来谷歌对GFS进行了改进,并对新版本命名为Colosuss,主要对原有的单点故障、海量小文件存储等诸多问题进行了修正和改进,使得系统更加安全和健壮。
2)其他文件系统:除了谷歌的GFS,业界其他针对大数据存储需求的文件系统也层出不穷。Hadoop的文件系统HDFS[25]作为模仿GFS的开源实现,同样也为Hadoop的底层数据存储支撑,提供数据的高可靠性和容错能力,拥有良好的扩展性和高速数据访问性;SUN公司开发的Lustre[26]是一个大规模的、安全可靠的、具备高可用性的开源集群文件系统,美国能源部在此基础上实现了新一代的集群系统,显着提高了输入输出速度,已在高校、国家实验室和超级计算研究中心产生了深远影响;Facebook推出的针对海量小文件的文件系统Haystack[27]有效地解决了海量图片存储问题,它实现多个逻辑文件共享一个物理文件功能,并且增加缓存层,部分元数据直接被加载到了内存。
4.数据库系统
1)上在索引、数据压缩、可视化等技术方面的不断扩展,使其具有了高性能的优势。但是诸多因素导致了其扩展性面临严峻的挑战,主要体现在:(1)单机方面,并行数据库基于高端硬件设计,认为查询失败是特例且纠错复杂,不符合大规模集群失效常态的特性;(2)集群方面,并行数据库对异构网络支持有限,各节点性能不均,容易引起“木桶效应”。总之,并行数据库的扩展性方面的缺陷使其面临大数据的处理往往力不从心。
2)MapReduce分布式数据库BigTable:由前述知,并行数据库由于扩展性方面的缺陷无法胜任大数据的处理工作,以谷歌公司推出的BigTable为代表的未采用关系模型的
NoSQL(NotonlySQL)数据库由此诞生,NoSQL数据库具有模式自由、简易备份、接口简单和支持海量数据等特性,对于大数据的存储和处理十分有效。谷歌在GFS之上又设计了MapReduce的分布式数据库BigTable[28],为应用程序提供了比单纯地文件系统更方便、更高层的数据操作能力,BigTable提供了一定粒度的结构化数据操作能力,主要解决一些大
型媒体数据(Web文档、图片等)的结构化存储问题。BigTable主要是一个分布式多维表,表中数据通过行关键字、列关键字和时间戳来进行索引和查询定位,并且BigTable对存储在表中的数据不做任何解释,一律视为字串,具体数据结构的实现由用户自行定义。BigTable的基本构架如图3所示,BigTable中的数据均以子表形式保存在子表服务器上,最终以GFS文件形式存储在GFS文件系统中。客户端程序直接和子表服务器通信,Chubby服务器完成对子表服务器的状态监控,主服务器通过查看Chubby服务器目录来终止出现故障的子服务器并将其数据转移至其他子服务器。另外,主服务器还完成子表的创建和负载均衡等操作。当然,由于MapReduce将本来应由数据库管理系统完成的诸如文件存储格式的设计、模式信息的记录、数据处理算法的实现等工作转移给了程序员,从而导致程序员负担过重。另
外,MapReduce是面向非结构化的大规模数据处理的,往往是一次处理,因而同等硬件条件下的性能也比并行数据库低[29]。
3)数据库的深层探讨:并行数据库具有高性能的优势,但扩展性问题阻碍了其在大数据处理上的进一步发展,而MapReduce性能和易用性上提升空间较大,因此目前两种方案均不理想。业界经过长时间的探讨,基本一致认为并行数据库和MapReduce各取其长,相互融合,也许是一种不错的道路[30]。由此诞生了并行数据库主导型、MapReduce主导型以及并行数据库与MapReduce集成型3类大数据处理数据库。
(1)并行数据库主导:型这类数据库的基本思路是在并行数据库上增加MapReduce的大数据处理能力,将数据分析过程转移到数据库内进行,使得原系统同时获得SQL的易用性与MapReduce的开放性。但是,并行数据库的扩展能力与容错能力并未得到改善,典型的系统如Greenplum[31]、Asterdata[32]等。
(2)MapReduce主导型:这类数据库的基本思路是利用关系数据库的SQL接口和模式支持技术改善MapReduce的易用性。通过SQL接口,可以很简便的完成查询分析等操作,大
大减轻了程序员的负担,但MapReduce的性能方面仍有待提升,典型的系统如Facebook的Hive[33]和Yahoo!的PigLatin[34]等。
(3)并行数据库与MapReduce集成型:这类数据库兼顾并行数据库与MapReduce的长处,主要分两种思路:按功能将并行数据库与MapReduce分别设计到相应的部位以形成一个完整系统,以及整合并行数据库和MapReduce这两套完整的系统以构成一个混合系统。第一种思路典型代表是耶鲁大学提出的HadoopDB[35],它将Hadoop作为调度层和网络沟通层,关系数据库作为执行引擎,尽可能地将查询压入数据库层处理,Hadoop框架的应用可以获得较好的容错性和对异构环境的支持,库内数据查询的使用则可获得关系数据库的高性能优势。第二种思路的代表是Vertica数据库[36],它拥有两套独立完整的系统,Hadoop负责非结构化数据和耗时的批量复杂数据的处理,Vertica负责结构化数据的处理以及高性能的交互式查询。当然,这些思路仍非理想的方案,例如,HadoopDB丧失了MapReduce较低的预处理和维护代价等,Vertica则依旧存在Vertica扩展性问题和Hadoop的性能问题。因此,在大数据面前,数据库系统的研究还有很长的路要走,我们在总结传统的数据库经验的同时,还要积极了解新兴的数据库系统,才能更好地促进适应现今大数据发展的优良数据库的面世。