数据是很容易的。 它以表格的形式将事情和数据尤其是特殊项目保存下来。每一列会定义与每个项目(比如姓名)有关的数据，每一行则包括每个人的所有数据。 大多数表格式数据库引擎都是相关的，我们利用SQL来查询数据。因此，Big Data必须用非常非常庞大的表格来保存，这样的表格有许许多多的行。
这是一种诱导式定义，但是并不准确。Big Data实际上是一种完全不同的数据。 我所知道的有关Big Data的最佳定义是一种或多或少的否定式定义。Big data指的是这样一些数据，它不能很好地支持表格，对SQL的人为操作的兼容性也不好。
因此我们必须寻找其他的方式来储存它和分析它。想一想表格和SQL的功能就能够明白其中的原因了。 表格可以储存大量非常相似的项目的一些相对复杂的数据。
在SQL语言中，SELECT子句可以让你选择你想看的列，换句话说，它可以让你按列来对表格进行次级设置。WHERE子句则可以让你选定行。 换句话说，结构化查询语言与分级设置的数据的兼容性是很好的。当然，它还有更多其它的功能。 它可以合并表格，可以累加，更重要的是，它可以组织起一个大型数据库，抽取一个子集合并以答案的方式呈现在用户面前。
相比之下，Big Data在结构上非常不同，即便我们将它填入表格，我们也无法对它进行次级分析。
以图像的方式来储存它
说明这个问题的最简单的方式是举例。设想一个数字化X光影像，或许是一个JPEG格式的文件。 你想通过算法来分析它，寻找某种大小、形状或强度的亮点。 如果说这个听起来太容易，那么不妨设想一下通过扫描卫星图像去寻找一个微小的十字形和三角形。
当然，你可以把图像文件列成表格形式的数据，为每一个点位的XY数据建立参数和强度。但是有一个问题是，你最后肯定会得到一个非常狭长的表格。 从分析的角度来说，结构化查询语言可以非常容易地找到发亮的像素，但是在选择代表某个点位的所有像素的数据时却不太好用。
你或许会说：“但是我可以使用用户定义功能来解决这个问题。” 是的，我也能做到这一点。以我的经验来说，所有的数据都可以被填到一个表格之中，然后在一个相关数据库系统中进行分析，但是在有些情况下，你必须考虑其他的、更适宜的数据载体和其他分析语言。
虽然我们将Big Data定义为不可表格化的数据，但是我们并不是说所有的Big Data在结构上都是相似的。因此，在所有可能的数据的图表中，有一个定义数据结构的子集，还有其他的许多子集。
这个名称本身来源于容量，它的容量通常很大，而且Big Data的特征通常可以用3个V来总结：
- 容量：Big Data的容量通常很大，一般会达到TB级或PB级
- 速度：它的生成速度非常快，想象一下Twitter上每天发布的新推特吧
- (结构上的)多样性：常见上文
我对这3个V的特征描述没有异议，同时我还看到了其他一些特征：
- 价值：如果它是没有价值的，你为什么要储存它和分析它呢?
- 准确性：它必须是准确无误的，否则你的分析就是毫无价值的
但我还是要承认，这种为了追求V字头韵律而进行的总结或许并不能准确定义Big Data的所有特征。
因此，我认为除了名称之外，Big Data最重要的特征是它的结构，不同种类的Big Data有着完全不同的结构。
从这个定义出发，我们可以开始看一些例子了。一个Twitter Feed是Big Data，但是人口普查数据就不是。 影像、图像跟踪、电信公司的通话呼叫记录、网络登录日志、社交数据、RFID输出都是Big Data。你的职员、客户和产品统计表则都不是Big Data。
因此，你该如何去储存和分析Big Data呢? 答案取决于你所偏好的结构，但是同时还要考虑一下规模不断扩大和数量不断增长的NoSQL数据库，例如Cassandra 、CouchDB 和MongoDB。
最后，值得一提的是，Big Data及其相关的数据库系统与现有的关系系统并不冲突。表格式数据的分析并没有过时，它只是所有数据的一部分。
在上个世纪七十年代和八十年代，我们大力推广表格式数据是因为它是储存和分析数据最常用和相对容易的方式。我之所以说是相对容易是因为我们用了至少30年的时间才了解表格式数据和交易型数据。
Big Data一直就存在，我们只是不能很好地处理它。但是这种情况正在发生变化，我们最终会采取一些更好的办法来储存和分析它。 这是一项重要的工作。
本文作者：Mark Whitehorn在邓迪大学担任分析师。他的职责包括储存和分析质谱仪的数据输出，他必须跟踪需要检测的3维点位并绘制出2维轨迹图，同时还要计算出它们的容量。
