Hadoop只是运行某个通用计算的工具，正因为如此，在使用过程中你会受限于多种规则，比如所有计算都必须按照一个map、一个group by、一个aggregate或者这种计算序列来写。这种束缚就像穿上一层紧身衣，但是正因为Hadoop和大数据是热词，世界有一半的人都想穿上紧身衣，即使他们根本不需要。因此，你的数据量真的需要使用Hadoop这类工具吗？

1. 好几百M的数据，Excel装不下！这种级别完全和“大”无关，类似Pandas这样的工具就可以处理的很好，它可以把几百M的数据加载到内存，一眨眼功夫Numpy就能完成亿次浮点计算。

2. 数据体积高达10G！这种级别的数据仍然称不上大数据，当下的笔记本的内存都可以添加到16G了，而且许多工具并不是一次性将数据完全加载到内存的。

3. 数据有100GB/500GB/1TB！1个2TB的硬盘才几百块，买一块换上，然后果断装PostgreSQL等。

对比Python这样的脚本，Hadoop在编程方面不存在任何优势；同时因为跨节点的数据流开销，Hadoop通常情况下要慢于其他技术，然而如果你的数据超过5TB，那么你真的需要捣腾Hadoop了。

Chris从数据体积上分析了你的数据是否称得上大数据，是否真的需要使用大数据技术，然而衡量大数据的因素还有Velocity、Variety以及Value，下面我们就一起看MongoDB分享的“大数据除大以外的东西”，下为译文：

MongoHQ：不要因为大数据背后的利益而贬低其他途径

“大数据”，套用《银河系漫游指南》里的经典语录就是“is Big. You won’t believe how vastly, hugely, mind-bogglingly big it is. I mean you may think there’s a lot of data in Wikipedia but that’s just peanuts to Big Data”。这也是许多人在碰到大数据时走入的误区——他们首先假设自己必须使用大数据技术处理，然而我们离大数据还差很远，那么大数据是如何得来的？

回溯20世纪90年代，人们认识到数字化的存储数据比用纸要廉价的多，当一个东西便宜到一定的地步时，它就成为一个必然的选项。人类就会出于本能的去储存所有数据，因为“未来我们可能需要它们”，而且储存已经这么便宜了，为什么不做呢？

而从1990年美国科学家一篇名为 “Saving All The Bits”的文章中发现，那个时候科学家已经不得不面对保存所有数据的挑战，Peter Denning解释了NASA保存所有哈勃太空望远镜产生数据面临的挑战：该设备每天产生的数据需要2500张光盘来存放，这个速度不仅淹没了网络和存储设备的性能，同样还超出了“人类的理解能力”。但是请不要忽视一点，随着储存技术和经济状况的发展，这2500张光盘只等价于当下100美元左右的硬盘，而且我们似乎也并不需要储存一个太空望远镜产生的如此大量数据。

大数据的有限价值

今天我们几乎可以存储任何具有业务目的明显的数据，比如信用卡销售及问卷调查。同时，我们还可以存储所有业务目的不明显的数据，比如：用户在一个网页上的行为、电缆接线盒中用户观看的TV频道、借助物理网开关灯或者门的行为。但是从价值上看，后一类行为的价值无疑很低。

一笔信用卡交易包含了很多数据，比如：人的信息、地理位置、价值等。在销售周期中，你会很自然的捕捉这些数据。然而用户在一个网站上产生的行为显然不会那么有价值，你可能收集到用户访问的URL、阅读某个页面花费的时间，但是这些记录的价值显然不如信用卡交易那么丰富。当然如果你要给你的用户分类时，这些记录还是拥有一定价值的。

然而当下存储的成本已经越来越少了，你的数据越多，你就可以从数据分析趋势中获得更多的价值。每条TV频道转换的信息确实无关紧要，但是如果你把这些数据与调度机广告数据放到一起将其视为一个聚合数据集，你将可以清楚的知晓用户的行为，这些数据将给广告者和程序设计人员提供有价值的见解。

同样，智能家庭系统中收集到的信息价值就更低了，你可能只会得到一些事件和状态信息，同时系统可能产生大量的数据，价值必须通过大量的筛选、过滤等处理才能体现。大数据最大的挑战就是从大量的碎片项中获取信息，也可能是使用许多具有丰富价值的数据做依托，然后从中剥丝抽茧，寻找真知。需要注意的是，这并不是大海捞针，而是从一堆针中给一些针定性。

Hot Data vs. Big Data

造成需要大数据的原因是，你不仅拥有大量的数据，同样拥有大量访问这些数据的请求，而Big Data看起来能满足这个需求。

BigData的数据更倾向于冷数据，也就是你不会经常访问的数据，除了分析之外可能不会再次被使用。它可能很快被新鲜的冷数据代替，而新的冷数据又会产生新的分析，但是Big Data的范围需要与热数据分开，因为将两个需求混合得到的结果必然低于预期，这样一来冷数据与热数据的分析必然都差强人意。无论如何区分冷热数据都是个好的思想，不管是存储还是应用程序都应该区别对待。但是总有一些人不分场景为用户提供Big Data这个“仙丹”。

因此，请重视你的数据，分清楚数据的类型，以业务为需求，不必要将所有的数据混合到一起去打造1个大数据。

对于MongoDB的官博，Hakka Labs的创始人Pete Soderling在博文给以了回应。首先，他肯定了随着时间延续储存成本递减这条。其次，他还补充了两点，更多开放API造成用户数据太多以及公司们幕后操作的“数据共享”。随后，Pete则给出了自己的看法，下为译文：

Pete：无论大、小、热、冷，你的数据需要1条强健的数据处理管道

不可否认，你们说的有一定的道理，但是重要的是，在过去几年中，那些具有前瞻性的公司都做了一件非常重要的事——设计一个健壮的数据处理管道去收集、聚合级处理它们不断增长的数据。之所以这么做，最主要的原因就是用一种固定的方式分析数据之间的关系，就像MongoHQ说的在一堆针中给一些针定性，如果不这么做的话，这些关系必将消失。

但是这同样提出了一个问题，什么样的处理管道才是健壮的？简单的把数据扔入Hadoop显然不是，这里分享来自Stripe、Tapad、Etsy及Square的例子，一探现实世界中的数据管道：

1. Stripe的处理方式

Stripe的Avi Bryant为我们分享了如何建立一个健壮的数据管道：

Stripe从多个数据源将数据灌入HDFS，它们中许多都是无结构或者半结构化的服务器日志，比如：JSON或者BSON文档。在任何情况下，第一步都是转换成结构数据，我们习惯使用Thrift来定义逻辑结构，使用Parquet作为磁盘持久化格式。

之所以选择Parquet，因为它是一个有效的列存储格式，原生支持Cloudera的Impala查询引擎，可以快速的关系访问数据获取ad-hoc Reporting。同时，Parquet和Thrift的组合使用还有另一个好处——方便Twitter Scalding框架的有效使用，它可以用作复杂的批处理。

下一个步骤则是“denormalization”：为了保持分析作业和查询的快速执行，我们经常会提前做join，在Scalding中，将新的数据集写入Thrift格式。同时，我们会做大量的数据优化和注解，比如：地理编码IP地址、分析用户代理、清理缺省值等。

在许多情况下，这么做会导致嵌套结构模式，便于Scalding的处理以及Parquet的储存，然而却不便于Impala的查询。为此，我们设计了一个简单的工具，可以将任意的 Parquet嵌套数据转换成单一结构，同时我们会为每个数据源运行这样一个副本，以方便Impala的查询，我们期望未来版本的Impala可以移除这个多余的步骤。

2. Tapad的数据管道

Tapad从事的是广告技术业务，数年内已积累了丰富的流量及数据增长应对经验。为了了解他们的数据管道，Pete特意接触了Tapad的CTO Dag Liodden，以下是他口中的经验：

所有传入的数据流都会以pub-sub的形式进入一个信息队列（我们使用Kafka，并每小时给它推送TB级的数据）

所有数据都会被处理成denormalized结构模式，并且支持模式的演变（我们使用Avro和Protocol Buffers）

在信息队列处理过程中，所有的数据储存都会被实时更新（热数据被推送给了Aerospike和Cassandra，实时数据查询一般通过Vertica存储，原始事件则会与Aerospike集群中的数据整合储存在HDFS中）

深度分析及数据科学计算通常存储HDFS中，以denormalized数据为主。

在HDFS上存储的数据离线处理结束后，系统可以保持数据的实时更新。我们一直致力于计算逻辑的研究，从而实现数据可以在批处理和流处理系统间无缝的使用。

Dag表示最后一点让流计算的追溯成为可能，同时还可以自动同步其它存储系统中的数据。Dag还解释了存储方面使用了多个数据技术的原因，还剖析了这些技术的优势：

Kafka：高吞吐量的pub-sub，但是在交付和延时上表现一般，限制了数据持久并且缺乏查询能力。

Aerospike：非常快的随机读写访问能力，通过键（我们有32亿的键以及4TB的数据），跨数据中心备份，可用性很高但是查询性能受到限制。

Cassandra：中等程度的随机读写访问性能，原子计数和数据模型让它非常适合时间序列数据存储。灵活的一致性模式，并且拥有跨数据中心备份能力。

HDFS：高吞吐量，廉价的存储。

Vertica：快速而强大的ad-hoc查询能力，适用于交互式分析，高可用性，但是不支持嵌套数据结构及multi-valued属性，基于存储的收费让我们不得不控制使用。

3. Etsy处理数据的方式

通过Etsy数据团队技术经理Rafe Colburn，我们了解到了Etsy的数据处理方式：

Etsy的数据管道并不是标准的线状，它开始于我们的测试装备——1个运行在浏览器的事件记录器以及1个从后端调用的事件记录器，两个记录器都会ping一些内部的“beacon”服务器。

当Apache访问日志到一定的大小时，我们会使用1个logrotate程序将它持久化到HDFS系统。我们夜间还会给生产环境数据（储存在MySQL中）做了快照，同时会复制到HDFS，因此，我们可以将clickstream数据整合到事务数据中。

我们通常将Hadoop作业结果传送给Vertica数据仓库，这里同样会给生产数据做备份用以深度挖掘，我们会将这些数据传送给自主研发的报表和分析工具。

鉴于etsy.com的特性，我们使用的数据通常来自Hadoop作业，我们有一个定制化工具会取得作业的输出结果，并将它储存在MySQL（已分片）集群，在这里我们可以规模化的访问。本年度我们将考虑整合Kafka，这样我们就可以将数据从仪表中转移到Hadoop（以及流处理工具），同时也可以将数据从分析平台发送到外网上。

4. Square的分析方式

Square数据管道设计的非常复杂，在接触到技术经理Pascal-Louis Perez后，他为我们分享了Square的数据管道架构战略视图：

鉴于系统中支付流的重要性，Square将“reconciliation”这个概念贯穿了整个数据管道系统，验证每个数据转换的正确性。通过Pascal了解到，这种方法最大问题就是规模问题。对于每次付款收讫都会产生“10-15个核算实体，协调系统同样需要”，一次交易产生的操作已经够多了。Square的方法是使用流处理系统，这就允许为不同流映射不同的数据域。