大数据系统构建

　　The Translator抯 Words 译　者　序

　　首先，请允许我们对Nathan Marz致以崇高的敬意。

　　Nathan Marz是分布式实时计算系统Storm的创始人，在Twitter收购社交媒体数据分析公司BackType前担任BackType的首席工程师，之后选择离开Twitter，创立自己的公司。在实时大数据处理系统中，Storm作为Apache顶级开源项目已经成为大数据界不可或缺的一部分。因此，对于能够翻译Nathan Marz的书籍，我们深感荣幸。

　　与大多数程序员一样，Nathan Marz也是通过游戏进入开发者的世界的，在这一点上，似乎我们大多数人与Nathan Marz相差无几。但不同的是，Nathan Marz开创性地设计并使用Clojure语言编写了Storm，为我们揭开了大数据处理的新篇章，而我们未曾想过海量数据是可以实时分析并处理的，这也正是他与众不同的地方。 Nathan Marz对大数据概念的理解非常深刻，在编程技术上基础扎实，如同Dean Jeffrey和Doug Cutting那样，他用自己超凡的智慧，带领我们步入了一个全新的数据时代。

　　本书借一些虚构的社交媒体示例，来让读者深入理解以下几件事情：

　　1）什么是大数据，它们从哪里来？ 

　　2）社交媒体有哪些数据是有价值且需要我们去分析的？

　　3）在使用数据的过程中，我们需要用哪些思路、架构、工具来实现自己的目的？

　　4）对于不同的数据类型，我们如何选择正确的架构和模型去进行分析和挖掘？

　　在翻译的过程中，我们也了解到，Nathan Marz不仅在数学与编程方面才华横溢，对各种开发工具与架构也是信手拈来，而且他所写的书籍也是字字珠玑，文不加点。他所写的内容深邃却并不晦涩，浅显易懂，贴近实战，原作行文流畅，文采炳焕。本书将大数据方方面面的工具以实例的形式引入内容中，令人读后有一种酣畅淋漓、耳目一新的感觉，在内容方面，从Apache Thrift的讲解到Lambda架构的实例、从HDFS和MapReduce的示范到架构和算法的实现以及针对不同类型数据模型的创建，一一涵盖其中。可以说，本书是大数据技术的集大成者，是诸多大数据书籍中难得一见的实战参考书。

　　对于我们译者来说，之所以翻译本书，既是希望将国外实践大数据技术的重要经验引入国内，让国内的读者能够从中一窥究竟，同时也希望自己在翻译的过程中有所受益。站在巨人的肩膀上，才能让我们能够看得更远。

　　在本书的翻译过程中，我们得到了诸多朋友和家人的帮助、理解以及支持，在此对他们表示衷心的感谢。同时也对促成本书出版的机械工业出版社的王春华、杨福川编辑表示诚挚的谢意。

　　本书内容丰富，涵盖了大数据的诸多方面，如Thrift、数据建模、HDFS、MapReduce、HBase、Lambda等，这为本书的翻译增加了不少难度。尽管我们进行了多次校对和修改，甚至几位译者就某些专业词汇如何准确翻译进行了多次字斟句酌的讨论，但由于水平所限，恐难以将原作的内容全面还原，因此也难免出现纰漏和不足。在此，也恳请广大读者在阅读之余不吝赐教，给予批评指正。

　　向　磊

　　2016年10月于北京

　　Preface 前　　言

　　当第一次进入大数据的世界时,我仿佛置身于软件开发的美国西部荒原。许多人放弃了关系型数据库，转而选择带有高度受限模型的NoSQL数据库，主要是因为其使用体验良好、熟悉度较高且这种数据库可以扩展到成千上万台机器上。NoSQL数据库的数量巨大，堪称铺天盖地，这些数据库中很多都只有细微的差别。一个名为“Hadoop”的新项目开始崭露头角,它宣称具备基于海量数据进行数据深度分析的能力。但弄清楚如何使用这些新工具很令人困惑。

　　当时，我正试图处理所在公司面临的扩展性问题。系统架构非常复杂—该Web系统包含共享关系型数据库、队列、工作节点、主节点和从节点。数据损坏渗透至数据库，为了处理这些损坏，我们使用了应用程序中的特殊代码，但从节点的操作总是落后于其他节点。我决定探索其他大数据技术，看看是否有比我们的数据架构更好的设计。

　　早期的软件工程职业生涯的经历，深刻影响了我对“系统该如何架构”的观点。我的一位同事花了几个星期将来自互联网的数据收集到一个共享文件系统。他在等待收集足够的数据，以便能在其上进行数据分析。有一天，在做一些日常维护时，我不小心删除了他的所有数据，导致他的项目延期了好几周。

　　我知道自己犯了一个大错，但作为一个软件工程师新手，我并不知道这会导致什么样的后果。我会不会因为粗心被解雇呢？我发了一封电子邮件向团队诚挚地道歉—让我惊喜的是，大家对此都表示非常同情。我永远不会忘记那个时刻—一个同事来到我的办公桌旁，拍着我的背说：“恭喜你！你现在是一个专业的软件工程师了！”

　　他玩笑式的表述道出了软件开发中不言而喻的“真理”—我们不知道如何创造完美的软件。软件可能有bug而且会被部署到生产中。如果应用程序可以写入数据库中，那么bug也可能写入数据库中。当着手重新设计我们的数据架构时，这样的经历深深地影响了我。我知道，新架构不但必须是可扩展的、对机器故障是可容错的，并且要易于推断故障原因—但对人为错误也可容错。

　　重构那套系统的经验，促使我走上了一条“在数据库和数据管理方面怀疑一切我认为是正确的”道路。我想出了一个基于不可变数据和批量计算的架构，令我很惊讶的是，与仅仅基于增量计算的系统相比，新系统要简单得多。一切都变得更容易，包括操作、不断发展的系统以支持新的功能、从人为错误中恢复和性能优化等方面。该方法很通用，似乎可以用于任何数据系统。

　　但有些事情困扰着我。当观察其他行业时，我发现几乎没有人使用类似的技术。相反，在使用基于增量更新数据库的庞大集群架构中，令人生畏的复杂性是为人所接受的。这些架构的许多复杂性已经通过我所开发的方法完全避免或大大缓减了。

　　在接下来的几年中，我扩展了该方法，并使之正式成为我戏称的Lambda架构。在初创公司BackType工作时，我们的5人团队构建了一个社会化媒体分析产品，该产品支持在超过100TB的数据上进行多样化实时分析。我们的小团队还负责拥有数百台机器的集群的管理部署、运营和系统监控。当我们向别人展示自己的产品时，他们对这个团队只有5个人感到非常惊讶。他们经常会问“这么几个人做了这么多事情？怎么可能！？”我的回答很简单：“不是我们在做什么，而是我们没有做什么。”通过使用Lambda架构，我们避免了困扰传统架构的复杂性。通过避免这些复杂性，我们大大提高了工作效率。

　　大数据运动只是放大了已经存在了几十年的数据架构的复杂性。主要基于增量更新的大型数据库架构将遭受这些复杂性的折磨，从而导致错误、繁重的操作，并阻碍了生产力。尽管SQL和NoSQL数据库通常被描述成对立或相互对偶的关系，但从最基本的方面来说，它们实际上是一样的。它们都鼓励使用这种相同的架构—该架构具有不可避免的复杂性。复杂性是一个邪恶的野兽，无论你承认与否，它都会“咬”你。

　　为了传播Lambda架构以及它如何避免传统架构的复杂性等知识，我写了本书。它是我开始从事大数据工作时就希望有的。我希望你把这本书作为一个旅程—挑战你以为自己已经知道的关于数据系统的知识，并发现从事大数据工作也可以优雅、简单和有趣。

　　Nathan Marz

　　作者简介

　　Nathan Marz Cascalog和Storm的创始人。在2011年Twitter收购社交媒体数据分析公司BackType前，他是BackType首席工程师。在Twitter，他建立了流计算团队，提供和开发共享基础设施，为整个公司的关键实时应用提供支持。他目前是Stealth startup的创始人。

　　James Warren Storm8的分析架构师，精通大数据处理、机器学习和科学计算。

　　译者简介

　　马延辉，资深Hadoop技术专家，对Hadoop生态系统相关技术有着深刻的理解，在Hadoop开发和运维方面积累了丰富的经验。曾就职于阿里、Answers.com、暴风等互联网公司，从事Hadoop相关的研发和运维工作，对大数据技术的企业级落地、研发、运维和管理有着深刻的理解和丰富的实战经验。开源HBase监控工具Ella作者。现在致力于大数据技术在传统行业的落地和大数据技术的普及和推广。

　　向磊，前暴风影音数据平台架构师，目前在某垂直电商平台担任技术总监，惠普中国Hadoop相关课程讲师。开源项目EasyHadoop、phpHiveAdmin作者，对Hadoop及其周边生态系统的底层运维及开发、集群自动化运维、网络架构设计、集群安全、性能优化、嵌入式编程方面有较深入了解。

　　魏东琦，博士，长期从事软件研发工作，现就职于中国地质调查局西安地质调查中心，参加、承担过多项科研项目。现致力于地质行业与大数据技术融合的相关研究工作。

译 者 序

前　　言

关于本书

致　　谢

第1章　大数据的新范式1

1.1　本书是如何组织的2

1.2　扩展传统数据库3

1.2.1　用队列扩展3

1.2.2　通过数据库分片进行扩展4

1.2.3　开始处理容错问题4

1.2.4　损坏问题5

1.2.5　到底是哪里出错了5

1.2.6　大数据技术是如何起到帮助作用的5

1.3　NoSQL不是万能的6

1.4　基本原理6

1.5　大数据系统应有的属性7

1.5.1　鲁棒性和容错性7

1.5.2　低延迟读取和更新8

1.5.3　可扩展性8

1.5.4　通用性8

1.5.5　延展性8

1.5.6　即席查询9

1.5.7　最少维护9

1.5.8　可调试性9

1.6　全增量架构的问题10

1.6.1　操作复杂性10

1.6.2　实现最终一致性的极端复杂性11

1.6.3　缺乏容忍人为错误12

1.6.4　全增量架构解决方案与 Lambda架构解决方案13

1.7　Lambda架构14

1.7.1　批处理层15

1.7.2　服务层16

1.7.3　批处理层和服务层满足几乎所有属性16

1.7.4　速度层17

1.8　技术上的最新趋势19

1.8.1　CPU并不是越来越快20

1.8.2　弹性云20

1.8.3　大数据充满活力的开源生态系统20

1.9　示例应用：SuperWebAnalytics.com21

1.10　总结22

第一部分　批处理层

第2章　大数据的数据模型24

2.1　数据的属性25

2.1.1　数据是原始的28

2.1.2　数据是不可变的30

2.1.3　数据是永远真实的33

2.2　基于事实的数据表示模型34

2.2.1　事实的示例及属性34

2.2.2　基于事实的模型的优势36

2.3　图模式39

2.3.1　图模式的元素39

2.3.2　可实施模式的必要性40

2.4　SuperWebAnalytics.com的完整数据模型41

2.5　总结42

第3章　大数据的数据模型：示例44

3.1　为什么使用序列化框架44

3.2　Apache Thrift45

3.2.1　节点46

3.2.2　边46

3.2.3　属性47

3.2.4　把一切组合成数据对象47

3.2.5　模式演变48

3.3　序列化框架的局限性49

3.4　总结50

第4章　批处理层的数据存储51

4.1　主数据集的存储需求52

4.2　为批处理层选择存储方案53

4.2.1　使用键/值存储主数据集53

4.2.2　分布式文件系统54

4.3　分布式文件系统是如何工作的54

4.4　使用分布式文件系统存储主数据集56

4.5　垂直分区58

4.6　分布式文件系统的底层性质58

4.7　在分布式文件系统上存储SuperWebAnalytics.com的主数据集60

4.8　总结61

第5章　批处理层的数据存储：示例62

5.1　使用HDFS62

5.1.1　小文件问题64

5.1.2　转向更高层次的抽象64

5.2　使用Pail在批处理层存储数据65

5.2.1　Pail基本操作66

5.2.2　序列化对象到Pail中67

5.2.3　使用Pail进行批处理操作69

5.2.4　使用Pail进行垂直分区69

5.2.5　Pail文件格式与压缩71

5.2.6　Pail优点的总结71

5.3　存储SuperWebAnalytics.com的主数据集72

5.3.1　Thrift对象的结构化Pail73

5.3.2　SuperWebAnalytics.com的基础Pail74

5.3.3　用于垂直分区数据集的分片Pail75

5.4　总结78

第6章　批处理层79

6.1　启发性示例80

6.1.1　给定时间范围内的页面浏览量80

6.1.2　性别推理80

6.1.3　影响力分数81

6.2　批处理层上的计算82

6.3　重新计算算法与增量算法84

6.3.1　性能85

6.3.2　容忍人为错误86

6.3.3　算法的通用性86

6.3.4　选择算法的风格87

6.4　批处理层中的可扩展性87

6.5　MapReduce：一种大数据计算的范式88

6.5.1　可扩展性89

6.5.2　容错性91

6.5.3　MapReduce的通用性92

6.6　MapReduce的底层特性94

6.6.1　多步计算很怪异94

6.6.2　手动实现连接非常复杂94

6.6.3　逻辑和物理执行紧密耦合96

6.7　管道图—一种关于批处理计算的高级思维方式97

6.7.1　管道图的概念97

6.7.2　通过MapReduce执行管道图101

6.7.3　合并聚合器101

6.7.4　管道图示例102

6.8　总结103

第7章　批处理层：示例104

7.1　一个例证105

7.2　数据处理工具的常见陷阱106

7.2.1　自定义语言107

7.2.2　不良的可组合抽象107

7.3　JCascalog介绍108

7.3.1　JCascalog的数据模型109

7.3.2　JCascalog查询的结构110

7.3.3　查询多个数据集111

7.3.4　分组和聚合器113

7.3.5　对一个查询示例进行单步调试114

7.3.6　自定义谓词操作117

7.4　组合121

7.4.1　合并子查询122

7.4.2　动态创建子查询123

7.4.3　谓词宏125

7.4.4　动态创建谓词宏128

7.5　总结130

第8章　批处理层示例：架构和算法131

8.1　SuperWebAnalytics.com批处理层的设计132

8.1.1　所支持的查询132

8.1.2　批处理视图132

8.2　工作流概述135

8.3　获取新数据137

8.4　URL规范化137

8.5　用户标识符规范化138

8.6　页面浏览去重142

8.7　计算批处理视图142

8.7.1　给定时间范围内的页面浏览量143

8.7.2　给定时间范围内的独立访客143

8.7.3　跳出率分析144

8.8　总结145

第9章　批处理层示例：实现147

9.1　出发点147

9.2　准备工作流148

9.3　获取新数据149

9.4　URL规范化152

9.5　用户标识符规范化153

9.6　页面浏览去重159

9.7　计算批处理视图159

9.7.1　给定时间范围内的页面浏览量159

9.7.2　给定时间范围内的独立访客161

9.7.3　跳出率分析163

9.8　总结165

第二部分　服务层

第10章　服务层概述168

10.1　服务层的性能指标169

10.2　规范化/非规范化问题的服务层解决方案172

10.3　服务层数据库的需求173

10.4　设计SuperWebAnalytics.com的服务层174

10.4.1　给定时间范围内的页面浏览量175

10.4.2　给定时间范围内的独立访客175

10.4.3　跳出率分析176

10.5　对比全增量的解决方案177

10.5.1　给定时间范围内的独立访客的全增量方案177

10.5.2　与Lambda架构解决方案的比较182

10.6　总结183

第11章　服务层：示例184

11.1　ElephantDB的基本概念184

11.1.1　ElephantDB中的视图创建185

11.1.2　ElephantDB中的视图服务185

11.1.3　使用ElephantDB186

11.2　创建SuperWebAnalytics.com的服务层188

11.2.1　给定时间范围内的页面浏览量188

11.2.2　给定时间范围内的独立访客数量191

11.2.3　跳出率分析191

11.3　总结192

第三部分　速度层

第12章　实时视图194

12.1　计算实时视图195

12.2　存储实时视图197

12.2.1　最终一致性198

12.2.2　速度层中存储的状态总量198

12.3　增量计算的挑战199

12.3.1　CAP原理的有效性199

12.3.2　CAP原理和增量算法之间复杂的相互作用201

12.4　异步更新与同步更新202

12.5　过期实时视图203

12.6　总结205

第13章　实时视图：示例206

13.1　Cassandra的数据模型206

13.2　使用Cassandra208

13.3　总结210

第14章　队列和流处理211

14.1　队列211

14.1.1　单消费者队列212

14.1.2　多消费者队列214

14.2　流处理214

14.2.1　队列和工作节点215

14.2.2　队列和工作节点的缺陷216

14.3　更高层次的一次一个的流处理217

14.3.1　Storm模型217

14.3.2　保证消息处理221

14.4　SuperWebAnalytics.com速度层223

14.5　总结226

第15章　队列和流处理：示例227

15.1　使用Apache Storm定义拓扑结构227

15.2　Apache Storm集群及其部署230

15.3　保证消息处理232

15.4　实现SuperWebAnalytics.com给定时间范围内的独立访客的速度层233

15.5　总结237

第16章　微批量流处理239

16.1　实现有且仅有一次语义240

16.1.1　强有序处理240

16.1.2　微批量流处理241

16.1.3　微批量流处理的拓扑结构242

16.2　微批量流处理的核心概念244

16.3　微批量流处理的扩展管道图245

16.4　完成SuperWebAnalytics.com的速度层246

16.4.1　给定时间范围内的页面浏览量246

16.4.2　跳出率分析247

16.5　另一个跳出率分析示例251

16.6　总结252

第17章　微批量流处理：示例253

17.1　使用Trident253

17.2　完成SuperWebAnalytics.com的速度层257

17.2.1　给定时间范围内的页面浏览量257

17.2.2　跳出