大规模数据分析几乎对所有行业都极其重要。移动和社交技术产生了海量的数据集，分布式云计算提供了存储和分析这些数据所需的资源，专家们掌握着全新的技术，其中包括NoSQL数据库。但是迄今为止，关于“大数据”的大部分书籍只不过是业务争论或者产品目录。《寻路大数据(海量数据与大规模分析)》则不同：它是每个大数据决策者、实施者和战略制定者必不可少的实战指南。

马诺切里是一位前Google工程师和数据骇客，他为那些需要低资源消耗和时间开销的实用方案的专业人员写作了本书。借助其广博的知识，作者帮助你专注于构建应用而不是基础设施管理，因为这样你才能从中获得最大的价值。

作者展示了如何结合使用不同的技术经济、有效地解决关键的大数据用例。你将看到进行海量数据集管理、数据可视化、数据流水线和信息面板构建、统计分析工具选择等的专业方法。纵观本书，作者演示了目前最先进的数据分析工具的使用技巧，其中包括Hadoop、Hive、Shark、R、Apache Pig、Mahout和Google BigQuery。

这是一个数据爆发的时代，更是一个数据技术爆发的时代，各行各业都在因此进行深刻的变革。如何从众多的数据技术中选择正确的工具、如何使用这些工具从海量数据中挖掘出有价值的东西，无疑是非常具有挑战性的问题。

《寻路大数据(海量数据与大规模分析)》作者马诺切里结合自己在Google大数据平台工作的丰富经验，阐述了数据技术的方方面面。从数据收集、共享到数据存储，从分布式数据平台、分析型数据库到数据可视化，从数据工作流构建到大规模数据分析，作者不仅进行了全面而深入的介绍，更覆盖了目前流行的各种数据技术与工具，同时对技术选型提出了指导性的建议。最后，作者对数据挑战的非技术因素进行了深刻的分析，并对数据技术的发展趋势进行了展望，引人深思。

本书对企业管理者、技术经理、数据分析师、数据应用开发人员和相关从业者都有很好的参考价值。决策者可以从中看到技术趋势，把握时代发展脉搏；数据分析人员可以看到经验的总结和工具的应用；其他从业者可以从中了解数据技术所涉及的各个方面。

第1部分 大数据时代指引

 第1章 数据成功四原则

1.1 当数据成为一件“大”事

1.2 数据和单台服务器

1.3 大数据的权衡

 1.3.1 构建可（限）扩展的解决方案

 1.3.2 构建可（在互联网上）共享数据的系统

 1.3.3 构建解决方案，而非基础设施

 1.3.4 关注从数据中解放价值

1.4 大数据流水线剖析

1.5 终极数据库

1.6 总结

第2部分 收集和共享海量数据

 第2章 托管和共享TB级原始数据

2.1 文件之殇

 2.1.1 共享大量文件的挑战

2.2 存储：基础设施即服务

 2.2.1 网络很慢

2.3 选择合适的数据格式

 2.3.1 XML：数据，描述你自己

 2.3.2 JSON：程序员的选择

2.4 字符编码

 2.4.1 文件转换

2.5 移动中的数据：数据序列化格式

 2.5.1 Apache Thrift和Protocol Buffers

2.6 总结

 第3章 构建基于NoSQL的Web应用采集众包数据

3.1 关系型数据库：命令及控制

 3.1.1 关系数据库的ACID测试

3.2 当关系型数据库遇上互联网

 3.2.1 CAP原理与BASE

3.3 非关系型数据库的模式

 3.3.1 键-值数据库

 3.3.2 文档存储

3.4 为写入性能优化：Redis

3.5 在多个Redis实例上分片

 3.5.1 使用Twemproxy自动分区

 3.5.2 Redis的替代选项

3.6 NewSQL：Codd归来

3.7 总结

 第4章 解决数据孤岛问题的策略

4.1 堆满术语的仓库

 4.1.1 实践中的问题

 4.1.2 数据合规与安全规划

 4.1.3 走进数据仓库

 4.1.4 数据仓库的口诀：抽取、转换和加载

4.2 Hadoop：数据仓库中的大象

4.3 数据孤岛也可能是个优点

 4.3.1 专注于数据问题，而不是技术

 4.3.2 鼓励员工提出他们自己的问题

 4.3.3 投资沟通数据孤岛的技术

4.4 融合：数据孤岛的终结

 4.4.1 Luhn的商业智能系统是否能成为现实

4.5 总结

第3部分 数据探究

 第5章 使用Hadoop、Hive和Shark探索大规模数据集

5.1 什么是数据仓库

5.2 Apache Hive：在Hadoop上进行交互式查询

 5.2.1 Hive用例

 5.2.2 Hive实战

 5.2.3 在Hive中使用其他数据源

5.3 Shark：以内存的速度进行查询

5.4 云中的数据仓库

5.5 总结

 第6章 使用Google Big Query构建数据信息中心

6.1 分析型数据库

6.2 Dremel：均贫富

 6.2.1 Dremel与Map Reduce的不同之处

6.3 Big Query：数据分析即服务

 6.3.1 Big Query的查询语言

6.4 建造自己的大数据信息面板

 6.4.1 授权访问Big QueryAPI

 6.4.2 运行查询并获取结果

 6.4.3 缓存查询结果

 6.4.4 添加可视化图形

6.5 分析型查询引擎的未来

6.6 总结

 第7章 探索大数据的可视化策略

7.1 警世良言：将数据翻译成故事

7.2 人类尺度VS机器尺度

 7.2.1 交互性

7.3 开发交互式数据应用

 7.3.1 使用R和ggplot2实现交互式可视化

 7.3.2 matplotlib：Python的2D图形库

 7.3.3 D3.js：用于Web的交互式可视化库

7.4 总结

第4部分 构建数据流水线

 第8章 整合：Map Reduce数据流水线

8.1 数据流水线是什么

 8.1.1 正确的工具

8.2 使用Hadoop Streaming搭建数据流水线

 8.2.1 Map Reduce和数据转换

 8.2.2 最简单的流水线：stdin到stdout

8.3 单步Map Reduce变换

 8.3.1 从原始NVSS数据中抽取相关信息：map阶段

 8.3.2 合计每月出生数：reducer阶段

 8.3.3 在本地测试Map Reduce流水线

 8.3.4 在Hadoop集群上运行我们的Map Reduce作业

8.4 降低复杂性：Hadoop上Python的Map Reduce框架

 8.4.1 使用mrjob重写Hadoop Streaming示例

 8.4.2 建造一个多步流水线

 8.4.3 在Elastic Map Reduce上运行mrjob脚本

 8.4.4 其他基于Python的Map Reduce框架

8.5 总结

 第9章 使用Pig和Cascading构建数据转换工作流

9.1 大规模数据工作流实战

9.2 多步Map Reduce转换真复杂

 9.2.1 ApachePig：拒绝复杂

 9.2.2 使用交互式Grunt shell运行Pig

 9.2.3 过滤和优化数据工作流

 9.2.4 以批处理模式运行Pig脚本

9.3 Cascading：构建健壮的数据工作流应用

 9.3.1 以source和sink的方式思考

 9.3.2 构建Cascading应用

 9.3.3 创建一个Cascade：一个简单的JOIN例子

 9.3.4 在Hadoop集群上部署Cascading应用

9.4 何时选择Pig或Cascading

9.5 总结

第5部分 基于大规模数据集的机器学习

 第10章 使用Mahout构建数据分类系统

10.1 机器能否预测未来

10.2 机器学习的挑战

 10.2.1 贝叶斯分类

 10.2.2 聚类

 10.2.3 推荐引擎

10.3 Apache Mahout：可伸缩的机器学习工具

 10.3.1 使用Mahout进行文本分类

10.4 MLbase：分布式机器学习框架

10.5 总结

第6部分 基于大规模数据集的统计分析

 第11章 使用R语言处理大数据集

11.1 统计学为什么性感

 11.1.1 R处理大型数据集的局限性

 11.1.2 R的数据帧和矩阵

11.2 处理大数据集的策略

 11.2.1 大矩阵处理：bigmemory和biganalytics

 11.2.2 ff：使用大于内存的数据帧

 11.2.3 biglm：大规模数据集的线性回归

 11.2.4 RHadoop：使用R访问ApacheHadoop

11.3 总结

 第12章 使用Python和Pandas构建分析工作流

12.1 数据乐园中自在的蟒蛇——Python

 12.1.1 为统计性计算选择一门语言

 12.1.2 扩展现有代码

 12.1.3 工具和测试

12.2 用于数据处理的Python库

 12.2.1

 12.2.2 SciPy：Python的科学计算库

 12.2.3 数据分析库Pandas

12.3 构建更复杂的工作流

 12.3.1 处理损坏或丢失的记录

12.4 iPython：科学计算工具链的最后一环

 12.4.1 在集群上并行执行iPython

12.5 总结

第7部分 展望未来

 第13章 何时选择自制、购买或外包

13.1 功能重合的解决方案

13.2 理解你的数据问题

13.3 自制还是购买问题的参考手册

 13.3.1 你已经对哪些技术有所投入

 13.3.2 从小处着手

 13.3.3 规划时考虑可扩展性

13.4 私人数据中心

13.5 了解开源的成本

13.6 一切皆服务

13.7 总结

 第14章 未来：数据科技的几个趋势

14.1 Hadoop：搅局者与被搅局者

14.2 一切皆在云中

14.3 数据科学家的兴衰

14.4 融合：终极数据库

14.5 文化融合

14.6 总结

2.1 文件之殇

假设你是一家大公司的首席信息官。在公司里，你的员工是数据消费者，每个人都扮演着各种不同的角色。你的许多员工致力于处理会计报告，但由于他们的角色所限，他们不应该获知敏感的人力资源信息。另一些员工是软件开发人员，他们构建应用程序时需要通过编程的方式来访问数据。在某些情况下，你的用户也许只有很少的技术背景，因此需要通过信息面板来访问诸如公司各项指标之类的数据。你的高管同僚可能有访问公司几乎所有数据的权限，但他们真正想要的是对大趋势的更高层次的理解。

当面临共享许多GB甚至TB数据的挑战时，会有多种潜在的实现方案。这些选择受到诸如成本、受众以及专业知识等因素的影响。不同类型的用户有不同类型的数据消费需求。请记住一句数据真言：专注于解放数据的价值。在共享大量数据时，如果用户无法以有意义的方式访问这些数据，那么你的努力将毫无价值。

2.1.1 共享大量文件的挑战

为了成功应对共享大量文件的问题，你首先要了解所涉及的每个挑战。

选择数据存储方式

第一个挑战是如何实际存储以及如何以可伸缩并且经济的方式来共享文件。虽然在Web服务器上发布一堆文件很容易，但存储和带宽的成本必须能随着数据量和用户数一同伸缩。

本章中的例子主要集中在处理大量的静态文件。我们将在后续章节中进一步讨论数据库技术。

选择正确的数据格式

共享数据的第二个挑战是决定应该为用户提供何种数据格式。这一决定取决于你的目标受众。你的文件是该便于编程人员使用呢，还是该便于普通人将其加载到电子表格中?关于文件占用的空间：你应该采用最紧凑的格式呢，还是该有良好的可读性?在某些情况下，你应该尽力提供多种数据格式以支持多种应用场景。

如何呈现数据

第三个需要考虑的事情是你想让用户以何种方式访问你的数据。为了与当地市民共享信息，市政当局应提供在线数据面板以及精心设计的可视化图形，这样不会技术的人也看得懂。然而，数据记者和研究人员需要的不仅仅是信息面板；他们需要大量原始的、机器可读的数据来进行深入的分析。市政当局还应致力于提供基于Web的编程接口，以鼓励人们开发软件应用来使用这些数据。

解决问题的方案

本章的其余部分将重点关注前两个挑战：选择存储及共享策略，以及学习何种用例应该使用何种数据格式。我们将在下面的章节中讨论处理、分析及将数据可视化的用例和策略。

试想一下有大量的公开数据保存在很多文件中的情形。如果你是政府的一员，共享数据的一个主要目标是将数据的可访问性最大化，这一因素将是你后续设计的关键。不幸的是，很少有地方政府在共享公共数据方面做得很好。

为了解决我们的问题，让我们重新审视我们的数据方案。让我们看看如何通过建立尽可能少的基础设施来共享数据。让我们努力思考数据消费者的需求；我们也将牢记我们的数据挑战与受众。不要仅仅因为流行或熟悉而选择某种文件格式，让我们以适合受众的格式部署自己的数据。

2.2 存储：基础设施即服务

你已经不再使用办公室的服务器来提供文件服务了，对吧?不幸的是，许多组织仍旧使用内部基础设施与外界共享文件。在过去的几年中，为满足大型互联网企业的需求而研发的技术，对于普通应用程序开发人员而言已成为广泛使用和经济的方式。诸如Rackspace、Amazon、Google以及其他许多供应商已经开始提供可看作公用计算或“计算即服务”的服务方式。事实上，这种类型的计算的定价和商业模式也开始模仿电力和自来水公司等公共设施使用的模式。比如说，购买一些硬盘和服务器硬件所需的费用，现在可以购买更多机器的使用权，而且它们与运行世界上最大网站的那些机器有着相同的存储和基础设施。

在基础设施即服务(IaaS)的计算模型中，许多物理机器连接在一起构成网络集群，在某些方面表现得像一个单台大型计算机。属于单个用户的数据可能会以小块的形式物理地存储在许多不同的实体机器上。使用的硬件通常是便宜而且易于替换的。最重要的是，这些系统内建对冗余的支持。由IaaS提供商负责处理硬件故障，通过复制多份数据的方式在出错后进行恢复。

这种存储模型有许多好处，也有许多潜在的取合。在成本方面，这些系统都能够使用规模效应来降低单个客户的存储成本。对于一个经济能力有限的公司来说，想要托管和共享大量的文件，这种模式是在高可用条件下共享数据且不会产生高昂的存储和带宽成本的唯一经济可行的途径。

使用IaaS存储解决方案满足了第1章中所讨论的几个指导原则。首先，该解决方案使我们能够针对伸缩性进行规划——如果存储或网络带宽出现大幅度的增加，该解决方案将能够处理此情况。此外，这种模式可以帮助我们避免搭建基础设施，让我们能够关注数据，而非购买和维护我们自己的硬件、雇用系统管理员，或顾虑备份或电力等事情。

2.2.1 网络很慢

网络实在是太慢了。2012年全球平均互联网数据传输速度为2.3Mb／s，美国的情况大约是5.3Mb/s。想象一下，从某处以5-3Mb/s的恒定速度传输25GB的数据到另一处。按照这一速度，传输将需要近11个小时。Google Fiber(谷歌光纤)等项目旨在通过光纤来使得互联网连接的平均速度向1000Mb/s的范围靠近。这些项目似乎有着良好前景，但其可能不会在几年内遍及全美国。对于我们已经提出的许多问题，解决方案自然地倾向于使用那些分布式的、普适的计算系统。尽管如此，当涉及大数据的挑战时，网络延迟的问题通常会变得更加突出。

P16-18

大数据这个概念，提出来已经有好几年了。在这几年中，作为一名数据工作者，我经常会参加各种大数据相关的讨论，也会有朋友和企业提出一些大数据相关的咨询需求。我感觉到，经过一波又一波的质疑和辩论，很多企业已经接受了大数据这个概念，认可大数据对于企业的重要性。眼前的问题，已经不是要不要开展大数据相关的工作，而是如何开展大数据工作。

企业需要将大数据的概念、技术、能力和企业自身的数据充分结合，来切实地提升企业的业务能力。实现这个目标要解决的一个问题是，大数据技术的发展太快、太新，能够对大数据整体技术有了解的人很少。各类技术适合处理什么样的数据?适合解决什么样的问题?如何进行技术选型?这些问题对于实操规划企业整体大数据发展的人非常重要，他们迫切需要介于宏观的概念和细节的技术之间，对于规划和选型立刻就能够产生帮助的资源。

几周之前，我有幸提前阅读到本书的部分章节，很高兴地发现，这本书所提供的，正好是这种立刻能够产生帮助的信息，可以更好地帮助大家规划和设计与企业业务密切结合的大数据应用，而作者丰富的经验和对于大数据的深刻理解，也可以提高我们对于大数据的认知，避免在大数据的应用中走弯路，非常值得仔细阅读。

廖若雪

高德公司大数据与移动技术中心副总裁

前百度主任架构师，百度公司技术委员会主席