大数据的召唤，它怎么就大了呢？

　　20年前，386电脑上200MB的硬盘是主流配置，现在笔记本上的硬盘主流配置是500GB。大了5102422560倍。500GB大吗？一部高清电影的大小在20GB左右，不过是25部高清，所以在家看高清的都是用1TB的硬盘，2块。
　　做数据仓库一般不会在系统里处理高清电影，而是业务数据。电信运营商1。5亿用户每天的数据大概在90GB左右，数据仓库各层合计的存储规划不到30TB。而淘宝推出的数据产品，数据魔方，据说每天处理的数据有几百TB，用将近200台PCserver搭成的Greenplum集群来处理这些数据。几百TB大吗？
　　“大”是个相对的概念，没有止境。现在之所以提大数据，是因为技术上出现了瓶颈，相对已有的技术来说，数据大了。是在用Oracle、DB2搭数据仓库搭的很无奈，等报表等的很惆怅之后，才恍然发现数据大了。大就有问题，而且问题很多，但最主要的问题是慢！数据脏，数据假，领导一时都反映不过来，但如果让领导等，领导开会前拿不到报告，他就会拍桌子骂人！或者干脆不给钱。。
　　慢是因为如今的商业智能（BI）架构不能有效的管理数据。数据处理再次进入了一个群雄割据、各显其能的激烈竞争时代（上一次还是在关系型数据库一纸定江山之前），是要为几年后流淌着蜂蜜和牛奶的幸福生活流汗流血拼命抢地盘的时代。所以，大数据热了。
　　当然，那是大厂商们的战争，大数据的历史也是由他们谱写的。作为一名只能喝汤度日的有志青年，怎么搭上这班车？是很多IT屌丝午夜梦回时都曾考虑过的问题吧。既然改变不了数据变大的事实，我们只好看看它大在哪里了吧，想解决问题，总得知道问题是什么。
　　它大在哪了呢？
　　程序员们做事务处理系统，或者叫业务系统已经做了很多年了。Oracle一直表现的挺好，系统实在太大了就搭RAC，也没什么大不了的。当然DB2也不错，mysql也没问题。用谁都能顺利走完业务流程（数据库免责声明：卖票慢和我无关）。
　　商业智能系统（分析系统）和业务系统不同，为了得到一个统计分析结果，要处理很多数据（包括各种关联关系），做非常复杂的查询和分析操作。如果直接处理细粒度的原始业务数据，相关数据的范围会很大，甚至可能对应业务系统中几十张表里的全表数据。或者说，要从上亿条记录里找出一条记录不是大数据问题；而给上亿条记录分类，找出其中的规律就是大数据问题。因为需求变大了，范围和复杂性变大了，所以数据变大了。
　　前面所说的数据都是很规整的关系型数据，不管按行存储还是按列存储，都是结构化数据。要想做到真正的智能，只关注结构化数据是不行的。最好的例子就是搜索引擎，它处理非结构化数据，产生半结构化甚至结构化数据，加快搜索查询的速度。这些非结构化数据非常多，email，系统日志，系统事件，多媒体文件，分析起来也更复杂。或者说，发微博不是大数据问题，但舆情监控是。因为需求变大了，数据源变大了，所以数据变大了。
　　综上所述，大数据和尺寸无关，和需求相连。
　　更快，更快，更快
　　耐心是一种美德，可忍耐也是有限度的。那么好的机器跑两个小时也不给个结果。当硬件不再是性能的救命稻草，怎么办？召唤新架构。
　　图1。充门面的架构图，不解释
　　为适应大数据的处理需求，要在架构中集成新技术、新产品，渡过大数据难关。
　　大规模并行处理系统
　　解决大问题的终极办法就是大事化小小事化了。分而治之，盖无能出其右者。
　　MPP（MassivelyParallelProcessing），大规模并行处理系统，由许多松耦合的处理单元组成的。每个单元都有自己私有的资源，有独立的操作系统和管理数据库实例。它最大的特点在于不共享资源。Greenplum，SybaseIQ，Elasticsearch都支持这种结构。
　　Hadoop
　　Hadoop项目开始于2005年秋天，当初是作为Lucene的子项目Nutch的一部分。受到GoogleLab开发的MapReduce和GoogleFileSystem（GFS）的启发。2006年3月份，MapReduce和NutchDistributedFileSystem（NDFS）分别被纳入Hadoop的项目中。
　　MapReduce
　　MapReduce是由Google提出的软件架构，包括两个概念，“Map（映射）”和“Reduce（化简）”，用于指导大规模数据集的并行运算。如果你了解函数式编程的概念，应该对这两个概念很熟悉。
　　映射函数对一个列表中的每个元素进行指定的操作。但它不会修改原始列表，而是创建一个新列表来保存操作结果。不变的原始列表，元素上的独立操作，所以Map操作是可以并发执行的。
　　化简操作对一个列表的元素进行适当的合并。可以把列表拆成几部分，各部分并发计算，然后递归。
　　Hadoop的架构
　　Hadoop有许多元素构成。其最底部是HadoopDistributedFileSystem（HDFS），它存储Hadoop集群中所有存储节点上的文件。HDFS（对于本文）的上一层是MapReduce引擎，该引擎由JobTrackers和TaskTrackers组成。
　　对外部客户机而言，HDFS就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件，等等。但是HDFS的架构是基于一组特定的节点构建的，这是由它自身的特点决定的。这些节点包括NameNode（仅一个），它在HDFS内部提供元数据服务；DataNode，它为HDFS提供存储块。由于仅存在一个NameNode，因此这是HDFS的一个缺点（单点失败）。
　　存储在HDFS中的文件被分成块，然后将这些块复制到多个计算机中（DataNode）。这与传统的RAID架构大不相同。块的大小（通常为64MB）和复制的块数量在创建文件时由客户机决定。NameNode可以控制所有文件操作。HDFS内部的所有通信都基于标准的TCPIP协议。
　　MapReduce则是JobTracker节点为主，分配工作以及负责和用户程序通信。用户只要继承MapReduceBase，提供分别实现Map和Reduce的两个类，并注册Job即可自动分布式运行。HDFS和MapReduce实现是完全分离的，并不是没有HDFS就不能MapReduce运算。
　　基于语义计算系统
　　非结构化信息的形式包括文档、电子邮件、电话录音以及多媒体内容。基于语义计算技术使计算机能够理解各中非结构化信息之间的联系，进而执行复杂的分析操作。其中的关键技术是文本挖掘技术。
　　基于语义计算技术与关键词搜索这些只能进行数据查找与检索的传统方法不同。举例而言，关键词搜索引擎不能理解信息的含义，因此这些产品只能用于找出带某个字词的文档。然而由于无法理解含义，所以那些使用了不同字词但主题却相同（即有相关性）的文档将被忽略。而那些主题与用户期望搜索的内容完全不同的文档却经常被返回，从而使得用户必须修改查询方式来适应这种搜索引擎。
　　除此之外，基于语义的计算还能提供关键词搜索引擎无法提供的许多功能，例如自动形成超链接以及聚类。举例而言，自动形成超链接可以向用户提供众多在语境上与原有的文档相互联系的文档、服务和产品，这就要求计算机能够完全理解原有文档的含义。与此类似，要使计算机能够自动收集、分析并组织信息，就必须赋予其提取语义的能力。只有拥有基于语义计算技术的系统才能做到这一点。
　　R语言
　　R是一套完整的数据处理、计算和制图软件系统。其功能包括：数据存储和处理系统；数组运算工具（其向量、矩阵运算方面功能尤其强大）；完整连贯的统计分析工具；优秀的统计制图功能；简便而强大的编程语言：可操纵数据的输入和输出，可实现分支、循环，用户可自定义功能贝尔实验室。
　　与其说R是一种统计软件，还不如说R是一种数学计算的环境，因为R并不是仅仅提供若干统计程序、使用者只需指定数据库和若干参数便可进行一个统计分析。R的思想是：它可以提供一些集成的统计工具，但更大量的是它提供各种数学计算、统计计算的函数，从而使使用者能灵活机动的进行数据分析，甚至创造出符合需要的新的统计计算方法。
　　该语言的语法表面上类似C，但在语义上是函数设计语言的（functionalprogramminglanguage）的变种并且和Lisp以及APL有很强的兼容性。特别的是，它允许在“语言上计算”（computingonthelanguage）。这使得它可以把表达式作为函数的输入参数，而这种做法对统计模拟和绘图非常有用。
　　R是一个免费的自由软件，它有UNIX、LINUX、MacOS和WINDOWS版本，都是可以免费下载和使用的。在那儿可以下载到R的安装程序、各种外挂程序和文档。在R的安装程序中只包含了8个基础模块，其他外在模块可以通过CRAN获得。
　　什么最重要？
　　不管数据怎么大，也是为了业务服务的。不管是要做精准营销还是维系挽留，或者了解市场上对公司品牌的认知度如何，归根结底都是通过分析业务数据来促进业务。
　　商业智能要为商业服务，就要对业务有更加深入透彻的了解，所以学会分析业务模型很重要，要能对企业架构建模和分析。比如电信行业的eTOM，通用的TOGAF等。如果你还恰好懂一点儿营销和管理，那就太棒了。