PB级大数据存储技术与分析技术解析.docx
- 文档编号:10998966
- 上传时间:2023-02-24
- 格式:DOCX
- 页数:30
- 大小:379.01KB
PB级大数据存储技术与分析技术解析.docx
《PB级大数据存储技术与分析技术解析.docx》由会员分享,可在线阅读,更多相关《PB级大数据存储技术与分析技术解析.docx(30页珍藏版)》请在冰豆网上搜索。
PB级大数据存储技术与分析技术解析
一、PB级大数据存储技术解析
对于存储管理人员来说,大数据应该分为大数据存储和大数据分析,这两者的关系是——大数据存储是用于大数据分析的。
然而,到目前为止这是两种截然不同的计算机技术领域。
本文就重点解析一下PB级大数据存储技术,希望对您有所帮助。
越来越多的存储产品都在融入大数据的概念和功能,并使之成为产品的一大卖点。
但对于从事存储管理的专业人员来说,对“大数据”在具体应用场景中的特点和区别有所了解。
大数据存储致力于研发可以扩展至PB甚至EB级别的数据存储平台;大数据分析关注在最短时间内处理大量不同类型的数据集。
在快速变化的技术趋势中有两个特点需要存储管理人员重视起来。
第一,大数据分析流程和传统的数据仓库的方式完全不同,其已经变成了业务部门级别和数据中心级别的关键应用。
这也是存储管理员的切入点。
随着基础平台(分布式计算或其它架构)变得业务关键化,用户群较以往更加地依赖这一平台,这也使得其成为企业安全性、数据保护和数据管理策略的关键课题。
第二,通常用于数据分析平台的分布式计算平台内的存储不是你以往面对的网络附加存储(NAS)和存储区域网络(SAN)——其通常是内置的直连存储(NAS)以及组成集群的分布式计算节点。
这使得管理大数据变得更为复杂,因为你无法像以前那样对这些数据部署安全、保护和保存流程。
然而,执行这些流程策略的必要性被集成在管理分布式计算集群之中,并且改变了计算和存储层交互的方式。
大数据分析和传统的数据仓库的不同
大数据分析中包含了各种快速成长中的技术。
因此,简单用某一种技术尝试对其定义,比如分布式计算,会比较困难。
不过,这些定义大数据分析的通用性技术可以用如下特征阐述:
对于传统数据仓库处理流程效率和扩展性方面限制的感知。
将数据,不论是结构化还是非结构化数据从多个数据源汇聚的能力。
以及认识到数据的及时性是扩展非结构化数据源的关键,其中包括移动设备,RFID,网络和不断增长的自动化感知技术。
传统的数据仓库系统通常从现有的关系型数据库中抓取数据。
然而,据估计超过80%的企业数据是非结构化的,即无法关系型数据库管理系统(RDBMS),比如DB2和Oracle完成的数据。
一般而言,处于此次讨论的目的,非结构化数据可以看成所有无法简单转化到结构化关系型数据库中的所有数据。
而企业现在希望从这些非结构化数据类型中抽取有价值的信息,包括:
∙邮件和其它形式的电子通讯记录
∙网站上的资料,包括点击量和社交媒体相关的内容
∙数字视频和音频
∙设备产生的数据(RFID,GPS,传感器产生的数据,日志文件等)以及物联网
在大数据分析的情况下,查看远多于RDBMS的数据类型十分必要——这代表了各种重要的新信息源。
并且随着每年非结构化数据存储总量较结构化数据增长率高出10到50倍,从业务角度看这些数据也变得更为重要。
更重要的数据需要更专业的人员进行分析。
但传统的数据仓库技术对海量非结构化数据的处理根本无法满足大数据的需求。
所以,存储管理人员也应该更快的跟随技术潮流,更新自己的技术和知识结构,提高自己对大数据的管理和分析能力。
二、大数据分析系统应规避的问题
随着互联网技术的不断发展,数据本身是资产,这一点在业界已经形成共识。
越来越多的企业涉足到大数据,但是大数据没有想象中的那么简单,所有大数据的属性,包括数量,速度,多样性等反映了数据库不断增长的复杂性。
本文从安装、搭建等方面展示了大数据分析系统的应该规避的系列问题。
大数据分析前期要做的事
其实,每一个数据都有一个ETL,就是抽取、转化,然后去加载,包括做数据的清洗。
如果数据大批量进来的话,有些数据可能是有问题的,马先生举了个例子:
比如说,好多地址会写得比较模糊,如果要搜索北京这个词的时候,数据仓库里可能只有一个京字,这些都要统一整理成一个,比如说北京,这样后面分析就会简单,比如山东,有人会输入“鲁”字来进行搜索,而不是山东,这就需要在大数据分析前期做好数据清理工作,做规范化,这样后面的数据分析起来就方便很多。
搭建大数据分析系统的注意事项
在搭建大数据分析系统时,有哪些需要注意的事项?
马老师提到:
首先要弄明白你所在企业需要什么样的数据,或者你想得到什么价值,想明白了再去做。
因为做数据不像做别的东西,一定明确知道要知道你要干什么,不然这个系统搭的时候会有很多困难,不知道该怎么搭,不知道用什么技术,也不知道数据进去是否在浪费。
而目前的情况是:
很多企业可能会先把架构搭出来,实际上这数据每天在算,但是不知道这数据带来什么价值,所以更多是一个业务驱动的。
再举个例子:
比如说中国移动就想挖一挖,到底是哪一个用户老欠费,哪一个用户用得多,用的多的就给他优惠多一点……如果他有这个需求,你再把这个需求下转给下面的人,按照这个需求去开发;
其次,需要选择适当的技术。
比如说你一台机器够用的,不要用两台机器,能够进来报表就不要用交互报表,因为那个都是有技术成本的,并且上线的速度会慢很多。
所以建议任何一个企业在搭建数据分析以前,要特别清晰地知道其搭建的需求和目的,选择什么方案,搭它来解决什么问题,针对需求你去做一个数据分析;
再次,在没有时时性要求时,你不要自作主张,向老大提这个。
因为大公司的批量已经做得非常完美了,可能批量已经带来35%的收入增加了,他要再做时时,再增加5%,而你现在什么都没有。
如果说先要做时时,或者先要全部搞出来的话,可能要先一步一部把35%做好,把那个批量先做出来,然后再做时时,这样效果会更好。
不要滥搭大数据分析系统
技术这个东西都是相通的,没有一项改进都是说完全是重新造出来的,都是在改的,但是它带来的价值不一样,它带来的人的思考,就跟人从零售店买东西和网商这种不一样,但是技术,零售店也会用一些数据库,网上也可能用,要在这个上面做一些转变。
马老师谈到,好多国企(这里就不点名),就是为了上项目去上项目,称自己有海量数据。
当问他需要搭建的大数据系统是用来干什么,他们的答案很出乎意料:
先给搭起来,先存起来,需要的时候再用,就这种思想。
其实这个是没有必要的。
总结
虽然大数据现在炙手可热,大数据分析越来越火爆,很多企业都在试图拥抱大数据技术。
但还是应该具体问题具体分析,因为大数据分析系统并非适合所有的企业,一些小型规模的企业在旧系统能满足需求的时候,就不要盲目地去追随潮流,舍弃旧的系统重新搭建,也可能解决了这个小缺口,但是可能会滋生其它更大的问题,这就得不偿失了。
三、剖析Hadoop和大数据的七误解
如今,Hadoop成为解决大数据需求的主要投资领域之一,而类似Facebook等互联网巨头在都公开的吹捧Hadoop上取得的成功,同样初入大数据领域的公司也必先着眼于Hadoop。
但对于Hadoop技术而言,是一个多维的解决方案,可以通过不同的方式进行部署和使用。
下面就了解一些关于Hadoop和大数据的七大错误理念。
对于Hadoop技术而言,可以说是开源领域的传奇,然而如今业界还伴随着一些流言,这些流言可能会导致IT高管们带着“有色”的观点去制定策略。
如今,数据量在以惊人的速度增长,从IDC分析师报告中2013年数据存储上的增长速度将达到53.4%,AT&T更是声称无线数据的流量在过去的5年内增长200倍,从互联网内容、电子邮件、应用通知、社交消息以及每天接收的消息都在显著的增长,这也是众多大企业都聚焦大数据的原因所在。
毫无疑问,Hadoop成为解决大数据需求的主要投资领域之一,而类似Facebook等互联网巨头在都公开的吹捧Hadoop上取得的成功,同样初入大数据领域的公司也必先着眼于Hadoop。
但对于Hadoop技术而言,是一个多维的解决方案,可以通过不同的方式进行部署和使用。
下面就了解一些关于Hadoop和大数据的七大错误理念:
1.大数据仅仅是容量
对大数据来说,除了指体积之外,还经常提到Variety(多样)、Variability(可变)、Velocity(速度)和Value(价值)。
关键点在于大数据并不是体积上的增长,更多是未来的实时分析、结构化和非结构化数据的发展,并被企业CIO用于更好的决策。
综上所述,并不是只有分析大数据才会获得价值。
举个例子,存储和分析1PB的超时限数据的价值可能比不上实时分析1GB的数据,而从“新鲜”的数据上获得价值比解剖过时的数据更具价值。
2.传统SQL不能在Hadoop上使用
众多厂商在Hadoop上投入精力,布局市场战略时,十分清楚HDFS和MapReduce受限于处理类似SQL语言的能力,这也是Hive、Pig和Sqoop最终得以推广的原因。
更多企业通过Hadoop和SQL兼容来管理大量的数据,PivotalHD是结合SQL并行处理资料库与Hadoop2.0,针对企业资料分析需求而优化的Hadoop强化版本。
3.Hadoop是唯一的新IT数据平台
谈到数据平台,大型机在IT投资组合里有是一个长期投资,与ERP、CRM和SCM这些系统一样演变至今。
而面对大数据时代,大型机不想被架构遗弃,必须展示在现有IT投资环境中的价值,而许多客户遇到速度、规模和成本的问题,通过vFabricSQLFire这样的内存大数据网络去解决高速数据存取,促进大型机批处理或实时分析报告这些问题。
4.虚拟化会导致性能下降
Hadoop最初的设计只是运行实体服务器上,然而随着云计算发展,许多企业都希望能作为云数据中心提供服务。
之所以虚拟化Hadoop,企业首先要考虑管理基础设施的扩展性,认识到扩展计算资源,比如虚拟Hadoop节点在数据和计算分开时会对性能有所帮助,否则如果你关闭某个Hadoop节点将丢失上面的所有数据或者添加一个没有数据的空节点。
5.Hadoop只可以在数据中心运行
对于在SaaS云服务解决方案,许多云服务允许云端运行Hadoop、SQL,这无疑可以帮助企业省下数据中心建造投资的时间和金钱。
特别是对于公有云情况下,Java开发者可以从SpringDataforHadoop以及一些其它的GitHub用例中获益。
大数据复杂性
6.Hadoop对虚拟化无经济价值
Hadoop被很多人认为,尽管在商用服务器上运行,添加一个虚拟层在带来额外支出的同时并不会有额外的价值收益,但其实这个说法并没有考虑到数据和数据分析事实上都是动态的。
虚拟化基础设施同样可以减少物理硬件数量,让CAPEX(资本支出)直接等于商用硬件成本,而通过自动以及高效利用共享基础设施同样可以减少OPEX(运营成本)。
7.Hadoop不能运行在SAN或NAS上
尽管Hadoop在本地磁盘上运行,对于中小型集群一样可以在一个共享的SAN环境下体现良好的性能表现,而高带宽比如10GB以太网、PoE以及iSCSI对性能同样有很好的支持。
由此,大数据成为行业追逐的热点,以上七大有关大数据“误解”问题的客观看待。
如同不同项目需求不同,Hadoop是一个工具来帮助企业更好的应对大数据问题。
无论是面对数据网格的GemFire或SQLFire,还是面向消息的RabbitMQ中间件,一个完整的SaaS解决方案如今比在Hadoop环境更容易实现。
四、6个优秀的开源文件系统助力大数据分析
“大数据”作为时下最火热的IT行业的词汇,个人、企业和政府机构之间的互动创造了数据的海洋,我们51CTO传媒在4月26日-27日也将举行2013大数据全球技术峰会,分享大数据技术趋势和最佳实践,是一场重新认识数据价值的技术盛宴。
大数据需要大量的储存空间,本文分享了6个优秀的开源文件系统,助力大数据深入分析。
大数据在今天吸引了大量关注,个人、企业和政府机构之间的互动创造了数据的海洋,通过有效识别、访问、筛选和分析其中部分数据能带来新的见解和益处。
大数据需要大量的储存空间,先进的存储基础设施必不可少,需要能在多台服务器上伸缩自如的存储解决方案。
有许多优秀的开源文件系统能用于深入分析大数据,其中包括:
QFS
QuantcastFileSystem(QFS)是一个高性能、容错、分布式的文件系统,其开发是用于支持MapReduce处理或者需要顺序读写大文件的应用。
HDFS
HadoopDistributedFileSystem,简称HDFS,是一个分布式文件系统。
HDFS有着高容错性(fault-tolerent)的特点,并且设计用来部署在低廉的(low-cost)硬件上。
而且它提供高吞吐量(highthroughput)来访问应用程序的数据,适合那些有着超大数据集(largedataset)的应用程序。
HDFS放宽了(relax)POSIX的要求(requirements)这样可以实现流的形式访问(streamingaccess)文件系统中的数据。
HDFS开始是为开源的apache项目nutch的基础结构而创建,HDFS是hadoop项目的一部分,而hadoop又是lucene的一部分。
Ceph
Ceph是加州大学SantaCruz分校的SageWeil(DreamHost的联合创始人)专为博士论文设计的新一代自由软件分布式文件系统。
自2007年毕业之后,Sage开始全职投入到Ceph开发之中,使其能适用于生产环境。
Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统,使数据能容错和无缝的复制。
2010年3月,LinusTorvalds将Cephclient合并到内核2.6.34中。
IBM开发者园地的一篇文章探讨了Ceph的架构,它的容错实现和简化海量数据管理的功能。
Lustre
Lustre是一个大规模的、安全可靠的,具备高可用性的集群文件系统,它是由SUN公司开发和维护的。
该项目主要的目的就是开发下一代的集群文件系统,可以支持超过10000个节点,数以PB的数据量存储系统。
GlusterFS
GlusterFS是一个集群的文件系统,支持PB级的数据量。
GlusterFS通过RDMA和TCP/IP方式将分布到不同服务器上的存储空间汇集成一个大的网络并行文件系统。
PVFS
PVFS是一个高性能、开源的并行文件系统,主要用于并行计算环境中的应用。
特别为超大数量的客户端和服务器端设计。
模块化结构设计,可轻松的添加新的硬件和算法支持。
PVFS侧重高性能访问大数据集,包含一个服务器进程和客户端开发库,完全基于用户级代码编写。
特征:
∙基于对象的设计思路
∙Optimizedforregularstridedaccess
∙独立数据和元数据的存储
∙优化的MPI-IO支持
∙多种网络支持
∙无状态的服务器
∙用户级的实现方案
∙系统级接口
∙可在很多Linux版本上构建
∙支持多数平台,包括IA32,IA64,Opteron,PowerPC,Alpha,andMIPS
五、大数据与关系型数据库是否水火不容?
NO……
在大多数IT观察家的眼里,大数据通常是指那些规模大到难以用传统关系型数据库处理的数据集。
但随着大数据时代的到来,越来越多的数据库并非建筑在“关系”之上,且具有更高的可扩展性。
那么,大数据与关系型数据库是否水火不容?
MariaDB的创始人之一MontyWidenius驳斥了这个观点。
一直以来,人们都认为大数据和NoSQL数据库是天作之合,而关系型数据库则被打上OUT的标签,但有一位数据库老兵并不这么认为。
在大多数IT观察家的眼里,大数据通常是指那些规模大到难以用传统关系型数据库处理的数据集。
虽然今天关系模型和SQL依然是数据库世界的统治者,但随着大数据时代的到来,越来越多的数据库并非建筑在“关系”之上,且具有更高的可扩展性。
那么,大数据时代关系型数据库何去何从?
最近MySQL开源数据库最初版本的开发者,以及MySQL社区开发分支版本——MariaDB的创始人之一MontyWidenius接受ReadWrite的采访,他驳斥了大数据与SQL数据库水火不容的常见观点。
以下是对Widenius的采访实录,摘录如下:
问:
您能NoSQL和大数据的历史吗?
为什么它们会成为人们热议的话题?
答:
所谓的“新NoSQL运动”的起源来自三年前Twitter一位员工的博客,此人在博客中称MySQL不够好,他们需要更好的数据库技术,例如Cassandra。
其实Twitter当时在MySQL上遇到麻烦是因为他们没有正确使用。
奇怪的是,Twitter给出的问题解决方法在Cassandra和MySQL里都能轻松实现。
这篇文章的原文已经找不到了,但可以参考这篇随后的文章“MySQL将被Cassandra替代”。
目前的情况是这样:
三年过去了,Twitter还在用MySQL存储它最宝贵的资产——推文。
Cassandra最终也没能取代了MySQL。
NoSQL流行的原因是,与SQL相比,NoSQL非常容易上手,你不需要任何设计就能开始使用它。
但这也是有代价的,很快你就会发现对数据失去了控制(如果你不是足够小心的话)。
所以,大多数NoSQL解决方案的优点(在MariaDB出现之前)是:
●快速访问数据(只要你舍得把文件都丢进内存)
●快速复制/多个节点的数据扩展
●弹性架构(可以快速增加新的列)
问:
大数据(技术)能帮人们解决什么问题?
更高性能和更灵活的架构是推动NoSQL发展的两大动力。
问:
你个人怎么看待大数据,有什么预测吗?
我觉得大多数看好NoSQL的用户都是跟风者。
大多数公司根本没有像Facebook和Google那么大规模的数据,而且他们其实也根本就支付不起优化和持续开发数据库所需的专家人力成本。
SQL不会消亡。
NoSQL无法取代它。
因为几乎所有人都需要关系型数据库来管理数据。
眼下NoSQL也有其用武之地。
我认为未来将更多的是SQL和NoSQL的混合应用。
问:
为什么人们还在使用NoSQL?
主要有哪些原因?
因为NoSQL上手很容易。
你甚至不需要学习SQL,使用前也不需要定义数据库架构。
当然也有一些人使用NoSQL是因为比SQL的扩展性更好。
问:
SQL在性能上能超过NoSQL吗?
SQL哪些方面由于NoSQL?
只要数据不能载入内存,SQL通常性能都超过NoSQL。
同样的,NoSQL相比SQL还存在很多不足之处,例如大多数NoSQL方案都是为单一键值访问(singlekeyaccess)优化的。
对于更复杂的事情来说,你必须编写专门的程序,而且性能与SQL无法相比,尤其是那些需要自动响应用户请求的服务(大多数网站提供的服务)
在单机上的性能表现,NoSQL通常都不是SQL的对手。
在集群环境中,当所有数据都载入内存,NoSQL在键值查找的速度上通常会比SQL快。
六、大数据探讨:
如何整理1700亿条Twitter发布信息?
截至目前,美国国会图书馆所保存的Twitter信息数量已达到1700亿条、存储文件体积更到达133TB--由于每一条信息都已经在这套社交网络中分享及转载,这么庞大的数据改如何整理?
随着社交网络蒸蒸日上,美国国会图书馆不得不面对达到133TB之巨的Twitter发布信息文件;好在经过实践,他们已经找到了管理此类数据的办法。
截至目前,美国国会图书馆所保存的Twitter信息数量已达到1700亿条、存储文件体积更到达133TB--由于每一条信息都已经在这套社交网络中分享及转载,图书馆的技术团队需要想办法为用户拿出切实可行的检索方案。
在现阶段的项目报告中,图书馆管理人员指出目前市场上提供的此类大数据管理工具无法解决他们的实际困难。
"很显然,现有技术还只能满足奖学金信息等规模化数据集的访问需求,而在创建及发布此类数据方面则表现乏力,"馆方表示。
"由于此类任务的复杂性及对资源的极高要求,私营部门尚无法拿出具备合理性价比的商业方案。
"
如果私营企业都难以搞定大数据管理工作,那么预算拮据、全靠政府资金支持的非营利性机构--包括全球最大的图书馆在内--又该如何解决这一难题?
要拿出一套实用、经济、便捷且有能力处理1700亿条Twitter信息的索引系统无异于痴人说梦。
Twitter曾签署一份协议,允许美国国会图书馆访问该社交媒体网站中所发布的全部更新信息。
馆方官员坦言,他们必须建立一套帮助研究人员访问社交平台数据的系统,因为随着网络化交流趋势的不断普及,以期刊及出版物为代表的传统沟通方式已经被逐渐取代。
国会图书馆杰弗逊大厦
在Twitter刚刚诞生的2006年到2010年间,首批数据转储文件为20TB,其中囊括了210亿条Twitter信息(包括用户当前位置及消息描述等元数据)。
最近,馆方刚刚迎来第二批转储数据--总体而言,这部分副本压缩文件总体积为133.2TB。
在此之后,图书馆将与Gnip公司展开合作,以小时为单位收集全部Twitter发布信息。
2011年2月公布的统计数字显示,当时每天经由Twitter发布的信息约为1.4亿条;而到去年10月,这一数字已经增长到约5亿条。
研究人员强烈要求国会图书馆尽快开放数据访问功能--馆方称已经接到超过四百次此类请求。
该项目由图书馆与Twitter双方并行实施,将为用户提供Twitter使用的历史记录,能够逐项列出他们通过账户发布过的每条信息。
美国国会图书馆在大数据管理方面算得上经验丰富:
根据工作人员的说法,馆方自2000年开始就一直在为政府网站进行数据归档整理工作,数据总量超过300TB。
然而Twitter的出现令归档工作陷入僵局,因为馆方实在找不到合适的办法保证信息易于搜索。
如果继续使用馆方长期以来一直所倚仗的磁带存储方案,那么仅查询一条2006到2010之间的Twitter信息就需要耗费最多24个小时--而这批转储数据还仅占数据总量的八分之一。
"Twitter信息之所以难于整理,一方面是由于数据量过于庞大,另一方面则是因为每天都会有新数据不断加入进来,而这种增长速度仍在不断提升,"官方指出。
"此外,Twitter信息的种类也越来越多样。
普通Twiiter信息、利用软件客户端发出的自动回复信息、手动回复信息、包含链接或者图片的信息等等,这一切让我们无从下手。
"
寻找解决方案的道路是曲折的。
国会图书馆已经开始考虑分布式及并行计算方案,但这两类系统实在太过昂贵。
"要想真正实现搜索时间的显著降低,我们需要构建起由数百乃至数千台服务器组成的庞大基础设施。
这对于我们这种毫无商业收益的机构来说成本过高、根本不切实际。
"
那么馆方到底该如何应对?
大数据专家们给出了一系列参考方案。
就国会图书馆的情况而言,技术团队也许最好进行分类处理的方式,即利用一款工具处理数据存储、一款工具负责检索工作、另一款则用于回应查询请求,MarkPhillips指出。
他既在Basho担任社区及开发推广主管,同时也是开源数据库工具Raik的创始人(该工具在键-值存储方面便利而极具可扩展性)。
大数据管理工具已经构建起欣欣向荣的新兴行业,用户可以根据不同的使用需求与预期成本选择专有软件或者开源方案。
国会图书馆的技术人员所面临的最大问题在于,他们该如何开始整套系统的创建和管理工作。
如果馆方希望走开源的道路,那么可选的数据库创建及管理工具可谓百花齐放--从Hadoop集群到专门针对高输入/输出读写操作的Greenplum数据库可谓应有尽有。
二者还能够与ApacheSolar--一款开源搜索工具--加以整合。
开源为开发者们指明了一条免费获取源代码的光明道路,能够在商业硬件上构建起理想中的系统成品,然而采用开源也意味着我们需要在后端开发工作中投入大量人力物力。
当然,国会图书馆也完全可以走更昂贵但更省心的专有软件道路,从甲骨文或者SAP这些业界巨头那里直接采购数据库产品。
不过无论采取哪种方式,Twitter项目中那硕
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- PB 数据 存储 技术 分析 解析