在本篇开始之前，首先就前文作一些补充说明：
1. 大数据是一种新的数据形态和实践，它与当前主流的数据应用实践并存，而非取代。而且，它在相当长的时间内仍然是个新鲜事物，即使年复合增长率高达32%，到2016年全球大数据技术和服务市场总额也就是240亿美金左右（IDC在2012年底的预测）。不切实际、一窝蜂地上大数据项目不应鼓励。明明不算大数据，要装成有，偏要削足适履上马Hadoop和NoSQL，更不足取。
2. 大数据也是一种战略、世界观和习惯。即使今天没有大体量的数据，还是可以尽可能自觉、客观、全面地测量世界，为未来的大数据实践做准备。对于一个企业或系统来说，挑战在数据采集，而非存储。微信在设计之初就把数据监控精细化，并纳入基础框架，这是意识和实力的体现。有多少公司像彭博社那样“如饥似渴”地采集数据？它能够雇佣一个卫星每周对位于俄克拉何马的美国最大原油储备库拍照，根据油罐浮动顶的阴影长度来判断原油储备量的变化。成功者有成功的必然性。
3. “数据即价值”的价值观早已存在，Value不是大数据专享的属性，小数据照样有大价值。大数据的功劳在于唤醒大家的意识和觉悟。同样，从数据中发现价值的实践也由来已久，横跨数据库、统计学和机器学习交叉学科的数据分析是大数据分析的基础，但传统的数据分析实践是无法适应大数据的发展的，这一点我会在分析这一部分中细谈。
总之，不能神化大数据是万灵药，也不能矮化大数据就是包装旧概念。对一部分人来说，大数据已经是个客观存在和竞争优势；对绝大多数人来说，大数据可以是一种“从现在做起”的世界观，和未雨绸缪、决战未来的战略。本系列确有为大数据推波助澜之意，但不会随波逐流兜售概念；相反，我会剥开每一个概念，追溯它的源头和发展过程，并给出个人的见解。
正文：
上回说到对大数据大体量的界定，只有少数产业和企业能够对大体量感同身受，对更多的憧憬者来说，大数据不是进行时，而是未来时。这让无数空有一身Hadoop技艺的架构师和程序猿/媛扼腕太息。
且慢，听听微软研究院这位老哥的吐槽：根据微软和Yahoo的统计，所有Hadoop任务放一起一平均，输入数据集的大小也就是十几个GB；即使是Facebook，90%的任务数据集小于100GB。这这这？这又让言必称ZB的布道者们情何以堪？
说来说去还是要回到大数据的定义上来。上回说IDC为业界巨擘摇旗呐喊ZB时代，旋即又用100TB作为大数据的门槛。其实，100TB不是故事的全部。这次好好摆一摆IDC对大数据的界定。IDC高手论道，一张图搞定：
它的三步界定法是这样讲的：
1. 三个数据源场景：数据要么不小于100TB，要么来自于超高速的数据流，或者年增速大于60%。这三者是OR的关系，满足其一即可。这下好，很多中小企业可以进入大数据的候选队伍了。王侯将相，宁有种乎？数据少但速度可以快，基数小但增速可以大，只要秉持自觉、客观、全面测量世界的大数据观。
2. 无论你有哪种或哪几种数据，必须部署在可动态适应的基础设施（dynamically adaptable infrastructure）上。IDC专门强调，此基础设施并非一定要水平扩展架构（scale-out infrastructure），传统的scale-up架构也行。更重要的是，这个新名词把基于云的基础设施也包括了进去。要做大数据并非一定要自己部署Hadoop或NoSQL，把基础设施的事情留给云，自己专心从数据里提炼价值，不亦乐乎？有了Amazon AWS，四个人就可以做一个大数据初创企业Prismatic。
3. 第三步两个数据部署场景：部署中必须有不少于两个的数据格式或数据源，或者高速流数据源（如点击流或机器产生的数据流）。
好吧，不用执念于Volume了，我们接着这第三步讲Variety。
自道哥（Doug Laney）开立“三V经”伊始，Variety在大数据五个大V（前几天某人又提了第六个V，Viability，以后再表）排名老三，为什么Variety拿到系列第二篇讲呢？
在下不是百晓生，自然不敢乱排座次。虽然在下确实自赋过顺口溜一句：“大（Volume）、杂（Variety）、快（Velocity）、真（Veracity）、值（Value）”（大杂脍真值），但这万万不是Variety排第二的理由。Variety能做老二的最大底气来自于占大数据体量八成以上的非结构化数据。天知道这“八成”是怎么算出来的，但既然美林从98年就开始在企业数据市场这么说，十几年过去应该有增无减。
Variety从本义来说是指数据种类的多样性，我把数据质量的多样性即混杂性（舍恩伯格《大数据时代》中对messy的翻译正好是“混杂”）也放入这一篇讲。按理说混杂性也可以放在Veracity篇，但我感觉从方法论上多样性和混杂性有更多的相通之处。
多样性
如果一定要把数据分类，最简单的方法是分两类，结构化与非结构化。再深究下去，非结构化事实上是未必成立的概念。信息里的“结构”是永远存在的，只不过结构尚未被发现，或结构变化无定（半结构化或多结构化），或者结构存在但机器却处理不了。就像最典型的非结构化数据—文本，它有语言学意义上的结构（语法和语义），又有叙事意义上的结构（三段式、先破后立等），还具有结构化的元数据（作者、标题、发布时间等），但文本一直是非结构化数据的典型。有老学究一本正经说：非结构化？此言差矣；应该说非模型化（unmodeled），结构本在，只是未建模而已。早期的非结构化数据，在企业数据的语境里主要是文本，如电子邮件，文档，健康/医疗记录。随着互联网和物联网的发展，又扩展到网页、社交媒体、感知数据，涵盖音频、图片、视频、模拟信号等等，真正诠释了数据的多样性。
从另一个维度上看，数据的多样性又表现在数据来源和用途上。拿卫生保健数据来讲，大致有药理学科研数据，临床数据，个人行为和情感数据，就诊/索赔记录和开销数据四类。麦肯锡在《大数据：创新、竞争和生产力的下一个前沿》里关于美国卫生保健行业如何利用多样化数据给出了精彩的建议，有兴趣的可以去读一读。
又如交通领域。北京市交通智能化分析平台数据源来自路网摄像头/传感器、地面公交、轨道交通、出租车以及省际客运、旅游、化危运输、停车、租车等运输行业，还有问卷调查和GIS数据。从数据体量和速度上也达到了大数据的规模：4万辆浮动车每天产生2000万条记录；交通卡刷卡记录每天1900万条；手机定位数据每天1800万条；出租车运营数据每天100万条；高速ETC数据每天50万条；针对8万户家庭的定期调查，等等。发掘这些形态各异、快慢不一的数据流之间的相关性，是大数据做前人之未做、前人所不能的机会。更甚者，交通状况与其它领域的数据都存在较强的关联性：有研究发现，可以从供水系统数据中发现晨洗的高峰时间，加上一个偏移量（通常是40-45分钟）就是交通早高峰时间；同样可以从电网数据中统计出傍晚办公楼集中关灯的时间，加上偏移量来估计出晚上的堵车时点。国外的研究还发现了交通事故率与睡眠质量的关联，不一而足。
有人说咖啡馆的好处是“let ideas have sex”，大数据产生价值的关键是“let data have sex”。尤其是对不能坐拥大数据的企业来说，跳出自己的圈子，寻找新的相关数据源（如社交媒体，上下游企业或广告、应用联盟，数据市场）是出奇制胜的策略。即使牛如Apple，它也要杂凑Google、Wolfram Alpha、Wikipedia、Yelp等不同的外部数据源来让Siri足够聪明。
混杂性
我把混杂性作为数据质量的一个考量（数据质量的问题，在漫谈第五个V即Veracity的时候，还要涉及），即数据里混有杂质的特性。数据的混杂性是不可避免的，既可能有数据产生主体的问题，又可能有采集手段、存储方式的问题。
有人说这不是个新问题，我们很早以前就搞数据清洗。话是没错，只是在大数据时代，我们完全可以用一种更轻松的心态看待混杂性，并接受它带来的精确性的问题。
试想，如果杂质是偶然的，它一定会被更多的正确的数据淹没掉；如果噪音存在规律，足够多的数据可以发现这个规律，从而把噪音过滤；如果误差是内在的必然性，更多样化的数据采集和信息融合也必然能纠正误差。
拿几个我在Intel做过的项目作为例子：
1. 定位：GPS有几十米的误差，但加上了地图数据可以保证你导航无虞；GPS信号在城市环境里时断时续，基于惯性导航的系统可以维持导航系统的工作；基于运动传感器的室内惯性导航有累积误差，而且办公室环境里磁传感器受干扰严重，办法是跟基于Wifi的室内定位和地图匹配结合起来；通过SLAM（Simultaneous Localization and Mapping）构建室内地图同样受惯性导航传感器精度的限制，但如果有Wifi的帮忙，或者有大量路径轨迹，完全可以把误差纠正，等等。
2. 智慧城市里的视觉分析：基于单个摄像头的车牌抓取和识别可能受光照条件、空气能见度、车辆运行速度和遮挡情况的影响，但获得的部分信息（不完整车牌和车辆特征）可以跟其它摄像头获取的信息进行对照和相互印证。
3. PM2.5的检测仪太贵，5000美刀，很准很稳定。买个灰尘传感器，几十块人民币，不准不稳定。那两个传感器放一起呢，平均、平滑过的数据稳定了很多。再把这个数据跟官方的数据做关联，跟开放遥感数据（MODIS）推测的PM2.5值做关联，跟区域温湿度、气压和风向做关联，也许你就有了个200块人民币的个人PM2.5检测仪。
类似数据融合的例子有很多，涉及连续时/空轴的同质数据和同一时/空点的异构数据。时空关系是最典型的一种上下文语境（context）。在数据全集前提下，通过上下文语境来组织、过滤和呈现具有相关性的数据集/数据流是提升管理和分析效率的一种重要方式。大数据采集和存储尽量要全集，而管理和分析未必是多多益善（以后在分析篇中详述），抓住context很关键。在数据管理上，geocoded data或time series数据库就是利用时空语境来组织和优化多源数据的例子。
对于数据拥有者而言，数据的多样性和混杂性具有多重含义：
1. 原始数据层面，多样性是不因意志转移的事实，必须准备好多种采集和存储手段，保留这种多样性。
首先是采集。彭博社近乎偏执地采集数据，从用户使用彭博终端的每一次按键，到每一个员工的即时位置，从公司创始人每一次访问家族基金的记录，到前文所述石油库存的照片，甚至发展到丑闻。对绝大多数企业来说，除了前面所说的外部数据源，仔细研究一下IT系统的日志和归档功能，也许无需大动干戈就有意外的收获。
对于个人来说，基督教有谚云“凡走过必留下痕迹”。大可不必像MIT Geek Deb Roy那样把自家过日子的分分秒秒都录下来，也不用像Bell定律的提出者Gordon Bell那样把生活工作的点滴事无巨细记录到MyLifeBits里，“Total Recall”（电影《全面记忆》，Bell在2009年写的一篇文章以此为标题）还太遥远，但有了手机，我们真的可以更好地记录自己、量化自我。Small data是Big data的一个有趣侧面，以后也许还会述及。
其次是存储。对于非结构化数据，文件系统是主流的存储选择，但是在存取、索引以及元数据管理上不是最优。而结构化数据主要依靠关系型数据库，主要问题是结构变化时太折腾，当数据在TB级是也太慢。NoSQL数据库应时而生，一是能支持灵活的结构（schema）和非结构化数据，二是针对大数据体量可扩展性更好。同时，文件系统也得到了发展，与对象存储相映生辉，不仅在效率上提升（如Facebook Haystack对小图片文件），也能更好地支持管理和分析（如支持SQL-like语言来操作）。由于NoSQL数据库和文件/对象存储不能很好地支持数据库事务（ACID），不但关系型数据库还有用武之地，NewSQL数据库也因此脱颖而出。
2. 数据准备层面，怎么对多样化的数据建模，怎么在把多样化的原始数据转换为元数据，怎么在元数据里保留数据多样性、又能够保证数据处理手段的统一性。
这是一个很大的课题。数据处理前会有大量的时间做数据准备（到达80%），涉及到抽取、清洗、转换和集成，做得不好就只能是悲惨的“garbage in, garbage out”了。对于非结构化数据而言，最大的问题是究竟抽取什么出来，是一些特定的低阶特征、还是具有高阶语义的标记或元数据？到头来，非结构化数据的“结构”很容易受到主观假设的影响。
多样化数据的存储有几个问题，一个是多类数据放一起还是分开存，二是元数据怎么存储、与源数据如何关联，还有就是怎么能够最好地支持未来的分析。Booz Allen的Data Lake是把几方面做得比较好的。对于非结构化数据来说，Apache UIMA（Unstructured Information Management Architecture）是不错的选择，IBM的Watson主机在《Jeopardy》里战胜人类，军功章里有UIMA的一份。
3. 数据处理层面，主要是怎么在处理中利用好数据的多样性。这个在数据分析篇再谈。
4. 多样化数据信息密度不同，处理的代价不同，需要保存的时间也不一样，既要全局重视，也要区别对待，在一个统一的大数据架构里允许差异化的数据存储、管理和处理，是低成本和高灵活性的关键。
举个例子说，现在的平安城市、智能交通有大量的视频数据，一般需要保持30-60天。如果用HDFS的缺省配置来存，3份拷贝在成本上吃不消。而从视频里提取出来的图片保持时间较长，元数据就更长了，因此对于数据持久性上要给予不同的对待。考虑到数据搬移的代价，这些不同的数据可能还要存在不同的地方，视频可能在靠近它产生的地方即边缘区域，元数据在中央。这样，需要把计算发送到数据保存的地方。
好吧，罗嗦完了多样性和混杂性，下一篇“Velocity/天下武功，唯快不破”。
原文发布时间为：2013-11-10
本文来自云栖社区合作伙伴“大数据文摘”，了解相关信息可以关注“BigDataDigest”微信公众号
