商务智能理论与应用10-大数据技术架构探讨.ppt

* * * * * 我们使用天气的数据作为我们的示例，通常气象站几乎在每个小时，很多地点都在手机我们的气温信息，并采用日志的方式记录下来，所以用MapReduce来分析这些数据是在合适不过了。 ? 数据文件按照日期和气象站的地点组织，目录从1901到2001年按照年来分目录，其中每个气象站的数据按照gzip压缩方式打包到一个文件中，下面这个例子列出累1990年的那个目录信息。 % ls raw/1990 | head，010010-99999-1990.gz 010014-99999-1990.gz，010015-99999-1990.gz 010016-99999-1990.gz，10017-99999-1990.gz 010030-99999-1990.gz，010040-99999-1990.gz 010080-99999-1990.gz，10100-99999-1990.gz 010150-99999-1990.gz， 目前为止，已经有成千上万个气象站，全部的数据将由一些相对来说比较小的文件组成，相对来说处理小文件比较容易。所以这就是为什么需要按照年份拆分成小文件。 ? 解析后的年份与温度 (0, 11990999991950051507004...9999999N9+00001+9999..) (106, 11990999991950051512004...9999999N9+00221+9999...) (212, 11990999991950051518004...9999999N9-00111+99...) (318,2650999991949032412004...0500001N9+01111+99...) (424, 12650999991949032418004...0500001N9+00781+99...) ? Map函数仅仅从中解析出年份和温度（数据中加粗的部分），然后将他们输出[Key,value] (1950, 0) (1950, 22) (1950, ?11) (1949, 111) (1949, 78) 从map返回的output，在被送往reduce函数之前会被进行预处理。把key-value对进行排序和分组。所以接下来在reduce函数里看到的将是如下格式的输入： (1949, [111, 78]) (1950, [0, 22, ?11]) 每年的温度数据在后面都可以通过后面的列表读取，所有的reduce函数需要做的就是遍历他然后找出最大的数据即可，最后结果如下。 (1949, 111) (1950, 22) 最后输出这种结果：每年的最高气温。 Google MapReduce执行流程 文件存储位置 源文件：GFS Map处理结果：本地存储 Reduce处理结果：GFS 日志：GFS MapReduce的用途 MapReduce适合进行数据分析、日志分析、商业智能分析、客户营销、大规模索引等业务，并具有非常明显的效果。 通过结合MapReduce技术进行实时分析，某家电公司的信用计算时间从33小时缩短到8秒，而MKI的基因分析时间从数天缩短到20分钟。 NoSQL NoSQL(NoSQL = Not Only SQL )，意即反SQL运动，指的是非关系型的数据库。 随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展 关系数据库暴露的问题 High performance - 对数据库高并发读写的需求 　　 web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。 关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。 其实对于普通的BBS网站，往往也存在对高并发写请求的需求。 关系数据库暴露的问题 Huge Storage - 对海量数据的高效率存储和访问的需求 对于大型的SNS网站，每天用户产生海量的用户动态， 以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态， 对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。 再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。 关系数据库暴露的问题 High Scalability High Availability-