ma-云计算 大数据 mapreduce概念和关系

 

 

0 云计算：

 

什么是云计算？针对这个问题，恐怕十个专家会给出十一个互不相同的答案，而事实上也有无数的文章从各个角度试图给出一个简单而确切的定义。
在最肤浅的级别上来说，原来基于web 2.0技术开发的曾被称作web应用程序的都可摇身一变称自己为“云程序”，
因为任何运行于浏览器中收集并存储用户相关内容的应用都的确可以作为云程序的应用范例，
比如以Facebook为代表的社交站点、以内容分享为代表的YouTube、基于Web的邮件服务Gmail以及诸如Google Docs类的应用程序。
在这种层面上，“云”指的是运行了这些站点的主机群。诸如此类的应用，每种都会随着用户数据的日积月累进而带来“大数据”问题。
(视频  图片  文本)

云计算的另一个重要表现是效用计算，即将计算资源本身当作一种可计量的服务，就像电或者水一样。这种模型中，用户只需要向“云供应商”购买实际需要的计算能力即可，
实际应用中，这是通过向用户提供运行了某操作系统的虚拟机来实现的，即云供应商使用虚拟化技术在用户之间分配计算资源。
用户对其拥有的虚拟机具有完全使用权限，而其使用结束后，只需要“销毁”此虚拟机就能释放其原来占用的资源。

站在效用计算提供商的角度来看，这种模型中运营较大规模的数据中心的收益也会优于小规模的数据中心。
目前，虽然有越来越多企业或组织加入，但Amazon Web服务仍是此种应用领域的领头羊和主导者。而相关应用的开源解决方案Eucalyptus也正越来越引起人们的兴趣。
效用计算模型的实际应用是通过向用户提供虚拟机实例来完成的，用户通过此虚拟机来访问服务，这即是所谓的“基础架构即服务(IaaS)”。
然而，这对许多用户来说都过于“底层”了，于是就有了“平台即服务(PaaS)。PaaS通常指的是一些事先定义好的服务的集合，基于这些服务，
用记可以创建应用程序或部署数据等。Google App Engine是此类应用中其最出色的代表，它为用户提供了后台存储及构建高可扩展性web应用程序的API。
而其基础架构部分则由Google进行维护，从而让用户从备份、升级、打补丁甚至是提供存储和编程环境等繁琐的日常管理任务中解脱出来。
PaaS仍需要用户自己根据实际需要构建应用程序，对于不具有程序研发能力的公司来说，他们需要的是更为高层次一些的服务，“软件即服务（SaaS）”则应运而生。
SaaS将某种具体的应用软件以“云服务”的方式通过浏览器向用户提供，其著名的代表有Salesforce提供的CRM软件。

云计算： 将计算资源量化成水，电来出售
IaaS: 基础即服务，代表者 Amazon 虚拟机  阿里云
Pass: 应用程序即服务 代表者 Google App Engine
Saas: 具体应用软件即服务 代表者 Salesforce提供的CRM软件

 

 

1 大数据：

 

定义：庞大复杂(半结构化 非结构化)数据集，很难用数据管理工具和传统数据处理程序进行处理操作。
案例: 社交网络,web服务器日志,流量传感器,卫星传回的影像,银行交易信息,web页面内容,GPS轨迹信息,遥感汽车车行记录,金融市场数据等
规模：2008年，Google每天需要处理的数据量为20PB；2009年，Facebook有2.5PB的用户数据，且以每天15TB的速度增长；
	  eBay有6.5PB的用户数据，且以每天50TB的速度增长；2011年，Yahoo!共有180到200PB的数据；

属性：volume(数据大小),veloicy(变化频度),varity(数据源) 使用这三个属性，有助于理解数据自然特征 评估软件平台存储 平台处理数据能力

 

属性关系图：

 

 

 

 

 

大数据存在的价值： 根据实际需求进行处理后才能成为有用的信息，从而完成更深层次的、更为完整的商业解析，并实现结果的可视化。

 

 

2 大数据map-reduce框架解决的问题和带来的便利：

 

(1) 向外扩展(Scale out)而非向上扩展(Scale up)： 
	向外：横向增加低端服务器个数
	向上：变更成高端服务器
(2)假设故障很常见	
	假设一款服务器出故障的平均概率为1000天1次，那么10000台这种服务器每天出错的可能性将达到10次，、
	因此，大规模向外扩展的应用场景中，一个设计优良且具有容错能力的服务必须能有效克服非常普遍的硬件故障所带来的问题，即故障不能导致用户应用层面的不一致性或非确定性。
	MapReduce编程模型能通过一系列机制如任务自动重启等健壮地应付系统或硬件故障。
(3)将处理程序移向数据
	传统高性能计算应用中，超级计算机一般有着处理节点(processing node)和存储节点(storage node)两种角色，它们通过高容量的设备完成互联。然而，大多数数据密集型的处理工作并不需要多么强大的处理能力，于是把计算与存储互相分开将使得网络成为系统性能瓶颈。
	为了克服计算如此类的问题，MapReduce在其架构中将计算和存储合并在了一起，并将数据处理工作直接放在数据存储的位置完成，只不过这需要分布式文件系统予以支撑。

(4)顺序处理数据并避免随机访问
	大数据处理通常意味着海量的数量难以全部载入内存，因而必须存储在磁盘上。然而，机械式磁盘寻道操作的先天性缺陷使得随机数据访问成为非常昂贵的操作，
	因此避免随机数据访问并以顺序处理为目的完成数据组织成为亟待之需。固态磁盘虽然避免了机械磁盘的某此缺陷，
	然而其高昂的价格以及并没有消除的随机访问问题仍然无法带来性能上的飞跃发展。
	MapReduce则主要设计用来在海量数据集上完成批处理操作，即所有的计算被组织成较长的流式处理操作，以延迟换取较大的吞吐能力。
(5)隐藏系统级别的细节
	程序开发中，专业程序员公认的难题之一就是得同步追踪短期记忆的各种细节，简单如变量名，复杂如算法等；这会生较大的记忆负荷因为其需要程序员在开发过程中高度集中注意力，
	因此，后来才出现了各种各样的开发环境(IDE)以帮助程序员在一定程度上解决诸如此类的问题。开发分布式程序的过程更为复杂，程序员必须协调管理多个线程、进程甚至是主机之间的各种细节，
	而这其中，令人最为头疼的问题是分布式程序以无法预知的次序运行，以及以无法预知的模式进行数据访问。这必然大大增加竞争条件、死锁及其它臭名照著的问题出现的可能性。
	传统上，解决此类问题的办法无外乎使用底层设备如互斥量，并在高层应用类似“生产者-消费者”队列的设计模式等；
	但基于这种方式设计的分布式程序极难理解并且很难进行调试。MapReduce编程模型通过为其内部少量的几个组件提供了一个简单且精心定义的接口，从而将程序员与系统底层的处理细节隔离开来。
	MapReduce实现了“运算什么”与“如何在多个节点并行运算”的隔离，前者可以程序员控制，后者则完全由MapReduce编程框架或运行时环境控制。
(6)无缝扩展
	数据密集型的处理应用中扩展算法(scalable algorithm)是其核心要件。一个理想的扩展算法应该满足两种特性：数据扩展一倍时其处理时长的增长幅度不会越过原处理所需时长的一倍；其次，集群规模扩大一倍时，其处理时长降低至少一倍。
	进一步地，理想的扩展算法还应该能够处理种种规模如PB级别的数据，以及良好地运行于各种规模如数千节点的集群中，
	而且其无论运行时何种规模的集群、处理何种规模的数据，其程序并不需要做出修改，甚至连配置参数也不需要改动。然而，现实是残酷地，这种理想算法并不存在，
	Fred Brook在其经典的“人月神话”中有一个断言：为落后于预定计划的项目增加程序员只会让项目的完成时间进一步延后。这是因为并不能通过简单地将复杂任务切分为多个小任务并将其分配出去并行完成来获得线性扩展，
	也即是“一个妇女可以在10个月生出孩子，但十个妇女并不能在一个月内生出孩子来”。然而，这个断言于今至少在某此领域已经被MapReduce打破——MapReduce最激动人心的特性之一就是其处理能力随着节点的增加而线性增长，即集群规模增长N倍其处理相同规模数据的时长也会缩短N倍。