大家在讨论大数据时，用艾字节（1018字节）或泽字节（1021字节）表示大数据就跟用拍字节（1015字节）表示大数据一样频繁。这是庞大数字。很少用太字节（1012字节）表示大数据。

　　到底是什么因素在推动数据出现这样的大幅增长？有三个因素：基于互联网的活动增加，各式各样的移动设备遍地开花，以及企业迅速采用基于传感器的信息——可能涵盖智能仪表到无线射频（RFID）的各种系统。不过，正如现在越来越难驾驭越来越庞大的原始信息，需要实时业务分析工具的呼声也越来越高。

　　那么，你如何定义大数据？如何储存大数据？如何经济而高效地管理和分析大数据？

　　这些问题同样引起了业界大牌厂商和新兴公司的注意，由此带来了新的创新、新的工具和新的开源项目：从列式数据库、Hadoop和Map Reduce到无数的NoSQL数据库，这些都是有名的例子。

　　但作为一个类别，“大数据”是不是实际上过于宽泛？首先，“大数据”对不同的企业来说可能有着不同的含义。对一家公司来说，大数据是10太字节，而对另一家公司来说，大数据可能是100拍字节。其次，不是所有数据都是天生一样的。所以除了数据大小外，明白自己在处理哪一种数据同样很重要，以便可以运用某一项合适的技术（或某几项合适的技术）来应对分析挑战。

　　就拿电信行业来说吧。电信公司需要能够根据自己收集的呼叫详细记录（CDR）来进行网络分析。另一方面，同样这些公司可能希望进行情感分析，以便了解客户对本公司有怎样的看法。

　　这两种情况需要采用全然不同的方法：CDR实际上由结构化数据组成，因而很适合使用像列式数据库这些擅长分析的关系数据库。反过来，来自社交媒体的数据是非结构化数据，为了从数据中获取宝贵信息，就需要使用像Hadoop和Map Reduce这些新方法。

　　结构化数据和非结构化数据之间存在重大的区别。典型的结构化数据包括各种各样的日志（互联网日志和网络日志等）、CDR、传感器输出的数据、股市交易数据和在线游戏数据等。这些数据（有时称为机器生成的数据或交互式数据）是类似事务数据的结构化数据，因而可以用同样的方法来处理——前提是数据量很庞大、数据增长的速度很快。

　　所以，为了侧重应对某个数据挑战、概述一些具体又实用的解决方案，下面列出了用于分析机器生产的数据的三个最佳实践：

　　一、不仅仅着眼于硬件——面对我们所谈论的这种数据增长，继续添加更多的服务器和更多的磁盘存储子系统根本无以为继。到了某个阶段，以硬件为中心的传统方法会导致基础架构的占地面积很庞大，以至于硬件扩展、部署、供电和维护起来需要极其高昂的成本。

　　当然，你可以把这一切硬件都放在云环境，但这只是权宜之计，总归不是长久之计。说得更现实点，你需要关注更有效的替代方案。使用列式数据库方法就是这样一种创新，这项技术在近几年备受关注。

　　顾名思义，这类数据库是逐列储存数据，而不是逐行储存数据。由于大多数分析查询只涉及表中的一小部分列，所以列式数据库为了回复查询所要检索的数据比行式数据库少得多，行式数据库必须检索每一行的所有列。因而，Infobright、Vertica（惠普）、赛贝思（SAP）和ParAccel等厂商的列式数据库眼下在数据仓库和分析环境中变得越来越常见。

　　此外，列式数据库提供了数据压缩功能。这种数据库不但减少了输入/输出，还提供了数据加密，因而具有几个优点，包括查询响应速度更快，所需的存储硬件比较少，后者意味着可以降低成本。市面上有些技术的数据压缩比可以达到3：1或4：1，直至达到10：1、20：1甚至30：1，具体取决于待压缩数据的类型。

　　二、不要制约业务用户能做的工作——真正的调查性分析需要支持复杂动态请求以及快速即时分析技术的数据库。

　　传统数据库需要数据库管理员创建和维护索引、划分数据或者创建多维数据集或预测，才能获得很快的查询速度——这一切立足于明白用户想要运行什么查询和报表。针对事先调整特定查询的这种需求恰好有悖于调查性分析具有的性质，调查性本身不是事先定义的。

　　的确，连对数据进行划分或分片的方式也制约着查询性能。比如说，如果按部门或地区来储存数据，那么这很适合依据这个基础的查询，但是不利于你可能想要运行的其他各种查询获得良好性能。所以，在其他方面同样的情况下，不需要这种构件的数据库应该更灵活、性能更好。

　　不需要数据索引或划分等操作的一个必然结果是，不需要伴随这些操作而来的数据库管理工作。除了降低成本外，这还直接让独立软件开发商们（ISV）能够开发有时候所说的“突破性应用软件”（breakthroughapplication）。这种应用软件的特点就是，它们提供了可付诸行动的信息，充分挖掘机器生成的数据及其他类型的数据，并且以所需的任何一种格式，将结果提供给任何相关的用户平台。

　　支持这种应用软件需要“射后不理”（fireandforget）的数据库，这种数据库基本上不需要什么管理。比如说，InterSystems公司的Caché数据库致力于这个市场，其他厂商也是如此。另一个例子是Infobright公司，其合作伙伴JDSU将Infobright的分析数据库嵌入到了其服务保证应用软件中，让大型网络运营商能够即时深入分析海量的呼叫详细记录（CDR）。

　　三、明白自己的目标——许多公司使用专门定制的工具来处理某些任务有其理由。你不希望自己的业务解决方案使用标准的关系数据库来处理一切数据；正如你其实需要电钻时不会使用螺丝刀。

　　对数据库和分析解决方案来说更是如此，无论使用传统的行式关系数据库、专门定制的列式数据库、基于内存的系统和复杂事件处理系统，还是使用像Hadoop以及NoSQL和NewSQL（VoltDB、NuoDB和JustOne等）这些新兴技术，都有其充分的、正当的理由。

　　以机器生成的数据为例，专门定制的解决方案具有的一个关键特点是必须涵盖上述的其他最佳实践：能够在易于管理的硬件环境里面处理海量大数据，并且兼顾查询灵活性、高性能和减少管理要求。这方面没有什么灵丹妙药，但是明白项目目标、然后采用相应的合适架构关系到项目惨遭失败还是大获成功。

　　处理大数据将需要有的放矢而不是“一应俱全”的方法。用IBM的话来说就是针对工作负载而优化的系统。很显然，需要进行分析的数据中很大一部分是机器生成的数据。为了克服这个挑战，数据处理人员需要认真考虑适合自己的一套解决方案，并且关注如何更快地装入数据、更紧凑地储存数据，并且缩减分析和管理数据所需要的成本、资源和时间。