大数据的特点

大数据，不仅有“大”这个特点，除此之外，它还有很多其他特色，在这方面，业界各个厂商都有自己独特的见解，但是总体而言，我觉得可以用“4V+1C”来概括，“4V+1C分别代表了Variety（多样化）、Volume（海量）、Velocity（快速）、Vitality（灵活）以及Complexity（复杂）这五个单词。

Variety（多样化）

大数据一般包括以事务为代表的结构化数据、以网页为代表的半结构化数据和以视频和语音信息为代表的非结构化等多类数据，并且它们处理和分析方式区别很大。

Volume（海量）

通过各种智能设备产生了大量的数据，PB级别可谓是常态，我接触的一些客户每天量都在几十GB，几百GB左右，我估计国内大型互联网企业的每天数据量已经接近TB级别。

Velocity（快速）

要求快速处理，因为有些数据存在时效性，比如电商的数据，假如今天数据的分析结果要等到明天才能得到，那么将会使电商很难做类似补货这样的决策，从而导致这些数据失去了分析的意义。

Vitality（灵活）

因为在互联网时代，和以往相比，企业的业务需求更新的频率加快了很多，那么相关大数据的分析和处理模型必须快速地适应。

Complexity（复杂）

虽然传统的BI已经很复杂了，但是由于前面4个V的存在，使得针对大数据的处理和分析更艰巨，并且过去那套基于关系型数据库的BI开始有点不合时宜了，同时也需要根据不同的业务场景，采取不同处理方式和工具。

 大数据的常见处理流程

前面已经跟大家讲了处理大数据的必要性和特点，那么接着将谈到如何处理大数据，特别是常见的流程。具体的大数据处理方法其实有很多，但是根据长时间的实践，我总结了一个基本的大数据处理流程（图1），并且这个流程应该能够对大家理顺大数据的处理有所帮助。

图1. 大数据的常见处理流程

整个处理流程可以概括为四步，分别是采集、导入和预处理、统计和分析以及挖掘。

采集

利用多个的数据库来接收发自客户端（Web、App或者传感器形式等）的数据，并且用户可以通过这些数据库来进行简单的查询和处理工作，比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。

在采集部分，主要特点和挑战方面是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作，比如著名用于购买火车票的12306站点和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑，并且如何在这些数据库之间进行负载均衡和分片的确是需要深入地思考和设计。

导入/预处理

虽然有采集端本身会有很多数据库，但是如果要对这些海量数据进行有效地分析，还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作，也有一些用户会在导入时候使用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。

在特点和挑战方面，主要是导入数据量大，每秒导入量经常达到百兆，甚至GB级别。

统计/分析

统计与分析主要利用分布式数据库或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC 的GreenPlum、Oracle的Exadata以及基于MySQL的列式存储Infobright等，而一些批处理或者基于半结构化的需求可以使用Hadoop。

统计与分析这部分，主要特点和挑战方面是分析涉及的数据量大，其对系统资源，特别是I/O会有极大地占用。

挖掘

与前面统计和分析不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，这样实现一些高级别数据分析的需求，比较典型算法有用于聚类的K-Means、用于统计学习的SVM和用于分类的Naive Bayes，主要使用的工具有Hadoop的Mahout等。

在特点和挑战方面，主要是挖掘的算法复杂，并且计算涉及的数据量和计算量都很大，还有，常用数据挖掘算法库以单线程为主。

 如何从“小”做起？

由于我平时与中小企业的接触非常频繁，虽然技术方案与实际的问题相关，很难在一篇文章当中详尽地道来。除了上面那个基本处理流程之外，我下面会将一些基本的从“小”做起的思路给大家阐述一下：

1. 认识自己的不足，主要是在技术、人力和财力等方面是不仅无法与Google和Amazon这样国外巨头比肩，而且与国内三大互联网BAT（百度、阿里巴巴和腾讯）也是无法比肩的，所以需要深刻认识；
2. 明确分析自己的需求，下面是几个常见的需求选项：
   > 数据类型，是结构化，半结构化，还是非结构化为主；
   > 数据大小，内部数据级别是TB级别、PB级别或者PB以上级别；
   > 读写量级，比如每小时写入的数据达到GB级别，或者每天写入达到TB级别等；
   > 读写比例，是写为主，还是以读为主；
   > 并发数，大致的每秒并发数；
   > 一致性，只接受强一致性，或者可以接受最终一致性和弱一致性；
   > 延迟度，最高能容忍的延迟度是多少，是10毫秒，100毫秒，还是可以1秒；
   > 分析的复杂度，需不需要引入较复杂的数据挖掘算法等。 
3. 要灵活使用现有的工具，首先，推荐使用一些开源或者是可以承受的商业软件，虽然个人并不排斥自建，但是一定要有具体的商业价值，并且最好是在现有工具上的画龙点睛，而不是从头开始构建；其次，工具方面应与具体的场景相关，在不同的场景要使用不同的工具。
4. 尽量不要走平台思路，应以具体的应用和场景为主，因为建一个平台有很多附加的成本和设计，比如，Amazon的云平台是通过至少五年时间构建而成。特别是项目的初期，不建议走平台这个方向，而是应脚踏实地以具体的商业场景为主。
5. 找准切入点，最好是找到一个技术难度小，并且有一定的商业价值的场景来做大数据技术落地的试点，并不断地进行测试和迭代来验证，而不是一味求复杂，求大，这样比较容易说服企业管理层来进行长期地投入和支持；

最后，想和大家说一下，“罗马不是一天建成的”，无论是Google的用于大数据处理的基础设施，还是我们国内淘宝的“云梯”都是一步步通过不断积累和实践而成，所以我们这些中小企业应该贯彻“大处着眼、小处着手”的方针来持续地验证和推进。还有，我们人云科技将于今年上半年发布用于海量结构化数据处理的YunTable，由于其性能指标非常出色，并且已经有正式运行的大型集群，所以请各位朋友敬请期待。

转载链接：http://os.51cto.com/art/201205/339746.htm