注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

大数据概念

Hadoop 彭东稳 4256次浏览 已收录 0个评论

数据类型

  • 结构化数据(structured data):RDBMS

传统的关系型数据库中的表通常由一个或多个字段组成,每个字段都预先定义了其可存储数据的格式及约束等,这类的数据就是结构化数据(structured data)一个设计良好的数据库在其schema中定义这些格式或约束,并由相应的RDBMS为这些提供实现保证相应地。

  • 半结构化数据(semi-structured data):PageRank

非结构化数据(unstructured Data)就是指那些没有一个预定义的数据模型或不适于存储在RDBMS中的数据,这些数据没有额外的描述信息(元数据)因此无法推断这些信息的真实意义,比如文本文件。

  • 非结构化数据(unstructured data):xml或json

半结构化数据(semi-structured data)有着特定的结构,但每个记录的结构未必完全相同,因此,无法为这些数据记录提供预定义的schema,其元数据只有在数据创建时才能获取,通常都与数据交相存储从而实现自我描述(self-describing),如XML文件。

大数据概念

大数据是指庞大而且复杂(如半结构化甚至是非结构化数据)的数据集,这些数据集很难由现有的数据管理工具或传统的数据处理程序进行处理及操作等。通常,大数据的数据来源包括社交网络、web服务器日志、流量传感器、卫星传回的影像、银行交易信息、web页面内容、GPS轨迹信息、遥感汽车车行记录、金融市场数据等。

任何基础业务包含了收集、分析、监控、过滤、搜索或组织web内容的公司或组织都面临着所谓的“大数据”问题:“web规模”处理即海量数据处理的代名词。社交类网站的兴起也使得这些组织面临着另一个问题:用户行为数据分析,这涉及到通过日志文件记录用户的对web页面浏览、点击、停留时长等,而后对日志文件中的大量数据进行分析以支持进行合理、正确的商业决策。

那么,大数据处理究竟意味着对多大规模的数据进行处理?一个简单的例子:Google在2004年平均每天利用MapReduce处理100GB的数据,到2008年平均每天处理的数据已经达到20PB;2009年,Facebook的数据量达到5PB,且以每天15TB的速度在增长。PB级别的数据集正变得越来越常见,大数据时代的到来已然是不争的事实,密集数据处理也正迅速成为现实需求。

大数据问题的处理需要以与传统数据处理方式所不同的方法去实现,这正是MapReduce思想得以大放光彩的核心所在。MapReduce在实现大数据处理上有着多个基础理论思想的支撑,然而这些基础理论甚至实现方法都未必是MapReduce所创,它们只是被MapReduce采用独特的方式加以利用而已。

多数情况下,大数据需要根据实际需求进行处理后才能成为有用的信息,这个处理过程即所谓的大数据分析(Big Data analytics)。大数据分析能够通过分析足量的、快速变化的结构化及非结构化数据集,从而完成更深层次的、更为完整的商业解析,并实现结果的可视化;例如,对社交网站或购物网站的访问日志进行分析以揭示用户行为、精准广告投放、用户及主题建模、话题推荐、搜索引擎完成页面排序及索引等。传统的商业智能系统(business intelligence system)仅能用来有效地分析较小规模的结构化数据,对有着海量非结构化数据的大数据进行分析则非常困难。

Google为了高效存储web爬虫收集到的web页面并为其建立搜索索引开发出了GFS和MapReduce,GFS用于存储海量页面数据,MapReduce则实现在集群的多个节点上并行完成数据处理及分析。Apache Hadoop是Google的大数据存储及处理框架的开源实现,它包含HDFS和MapReduce两个核心组件。

大数据处理模型

  • 向外扩展(Scale out)而非向上扩展(Scale up)

大数据的处理更适合采用大量低端商业服务器(scale out)而非少量高端服务器(scale up)。后者正是向上扩展的系统性能提升方式,它通常采用有着SMP架构的主机,然而有着大量的CPU插槽(成百上千个)及大量的共享内存(可以多达数百GB)的高端服务器非常昂贵,但其性能的增长却非线性上升的,因此性价比很一般。而大量的低端商业服务器价格低廉、易于更换和伸缩等特性有效避免了向上扩展的敝端。

  • 假设故障很常见(Assume failures are common)

在数据仓库架构级别,故障是不可避免且非常普遍的。假设一款服务器出故障的平均概率为1000天1次,那么10000台这种服务器每天出错的可能性将达到10次。因此,大规模向外扩展的应用场景中,一个设计优良且具有容错能力的服务必须能有效克服非常普遍的硬件故障所带来的问题,即故障不能导致用户应用层面的不一致性或非确定性。MapReduce编程模型能通过一系列机制如任务自动重启等健壮地应付系统或硬件故障。

  • 将处理移向数据(Move processing to the data)

传统高性能计算应用中,超级计算机一般有着处理节点(processing node)和存储节点(storage node)两种角色,它们通过高容量的设备完成互联。然而,大多数数据密集型的处理工作并不需要多么强大的处理能力,于是把计算与存储互相分开将使得网络成为系统性能瓶颈。为了克服计算如此类的问题,MapReduce在其架构中将计算和存储合并在了一起,并将数据处理工作直接放在数据存储的位置完成,只不过这需要分布式文件系统予以支撑。

  • 顺序处理数据并避免随机访问(Process data sequentially and avoid random access)

大数据处理通常意味着海量的数量难以全部载入内存,因而必须存储在磁盘上。然而,机械式磁盘寻道操作的先天性缺陷使得随机数据访问成为非常昂贵的操作,因此避免随机数据访问并以顺序处理为目的完成数据组织成为亟待之需。固态磁盘虽然避免了机械磁盘的某此缺陷,然而其高昂的价格以及并没有消除的随机访问问题仍然无法带来性能上的飞跃发展。MapReduce则主要设计用来在海量数据集上完成批处理操作,即所有的计算被组织成较长的流式处理操作,以延迟换取较大的吞吐能力。

  • 向程序员隐藏系统级别的细节(Hide system-level details from the application developer)

程序开发中,专业程序员公认的难题之一就是得同步追踪短期记忆的各种细节,简单如变量名,复杂如算法等;这会生较大的记忆负荷因为其需要程序员在开发过程中高度集中注意力,因此,后来才出现了各种各样的开发环境(IDE)以帮助程序员在一定程度上解决诸如此类的问题。开发分布式程序的过程更为复杂,程序员必须协调管理多个线程、进程甚至是主机之间的各种细节,而这其中,令人最为头疼的问题是分布式程序以无法预知的次序运行,以及以无法预知的模式进行数据访问。这必然大大增加竞争条件、死锁及其它臭名照著的问题出现的可能性。传统上,解决此类问题的办法无外乎使用底层设备如互斥量,并在高层应用类似“生产者-消费者”队列的设计模式等;但基于这种方式设计的分布式程序极难理解并且很难进行调试。MapReduce编程模型通过为其内部少量的几个组件提供了一个简单且精心定义的接口,从而将程序员与系统底层的处理细节隔离开来。MapReduce实现了“运算什么”与“如何在多个节点并行运算”的隔离,前者可以程序员控制,后者则完全由MapReduce编程框架或运行时环境控制。

  • 无缝扩展(Seamless scalability)

数据密集型的处理应用中扩展算法(scalable algorithm)是其核心要件。一个理想的扩展算法应该满足两种特性:数据扩展一倍时其处理时长的增长幅度不会越过原处理所需时长的一倍;其次,集群规模扩大一倍时,其处理时长降低至少一倍。进一步地,理想的扩展算法还应该能够处理种种规模如PB级别的数据,以及良好地运行于各种规模如数千节点的集群中,而且其无论运行时何种规模的集群、处理何种规模的数据,其程序并不需要做出修改,甚至连配置参数也不需要改动。然而,现实是残酷地,这种理想算法并不存在,Fred Brook在其经典的“人月神话”中有一个断言:为落后于预定计划的项目增加程序员只会让项目的完成时间进一步延后。这是因为并不能通过简单地将复杂任务切分为多个小任务并将其分配出去并行完成来获得线性扩展,也即是“一个妇女可以在10个月生出孩子,但十个妇女并不能在一个月内生出孩子来”。然而,这个断言于今至少在某此领域已经被MapReduce打破——MapReduce最激动人心的特性之一就是其处理能力随着节点的增加而线性增长,即集群规模增长N倍其处理相同规模数据的时长也会缩短N倍。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (2)or分享 (0)
关于作者:

您必须 登录 才能发表评论!