《大数据系统构建：可扩展实时数据系统构建原理与最佳实践》一导读

前　　言 当第一次进入大数据的世界时,我仿佛置身于软件开发的美国西部荒原。许多人放弃了关系型数据库，转而选择带有高度受限模型的NoSQL数据库，主要是因为其使用体验良好、熟悉度较高且这种数据库可以扩展到成千上万台机器上。NoSQL数据库的数量巨大，堪称铺天盖地，这些数据库中很多都只有细微的差别。一个名为“Hadoop”的新项目开始崭露头角,它宣称具备基于海量数据进行数据深度分析的能力。但弄清楚如何使用这些新工具很令人困惑。 当时，我正试图处理所在公司面临的扩展性问题。系统架构非常复杂—该Web系统包含共享关系型数据库、队列、工作节点、主节点和从节点。数据损坏渗透至数据库，为了处理这些损坏，我们使用了应用程序中的特殊代码，但从节点的操作总是落后于其他节点。我决定探索其他大数据技术，看看是否有比我们的数据架构更好的设计。 早期的软件工程职业生涯的经历，深刻影响了我对“系统该如何架构”的观点。我的一位同事花了几个星期将来自互联网的数据收集到一个共享文件系统。他在等待收集足够的数据，以便能在其上进行数据分析。有一天，在做一些日常维护时，我不小心删除了他的所有数据，导致他的项目延期了好几周。 我知道自己犯了一个大错，但作为一个软件工程师新手，我并不知道这会导致什么样的后果。我会不会因为粗心被解雇呢？我发了一封电子邮件向团队诚挚地道歉—让我惊喜的是，大家对此都表示非常同情。我永远不会忘记那个时刻—一个同事来到我的办公桌旁，拍着我的背说：“恭喜你！你现在是一个专业的软件工程师了！” 他玩笑式的表述道出了软件开发中不言而喻的“真理”—我们不知道如何创造完美的软件。软件可能有bug而且会被部署到生产中。如果应用程序可以写入数据库中，那么bug也可能写入数据库中。当着手重新设计我们的数据架构时，这样的经历深深地影响了我。我知道，新架构不但必须是可扩展的、对机器故障是可容错的，并且要易于推断故障原因—但对人为错误也可容错。 重构那套系统的经验，促使我走上了一条“在数据库和数据管理方面怀疑一切我认为是正确的”道路。我想出了一个基于不可变数据和批量计算的架构，令我很惊讶的是，与仅仅基于增量计算的系统相比，新系统要简单得多。一切都变得更容易，包括操作、不断发展的系统以支持新的功能、从人为错误中恢复和性能优化等方面。该方法很通用，似乎可以用于任何数据系统。 但有些事情困扰着我。当观察其他行业时，我发现几乎没有人使用类似的技术。相反，在使用基于增量更新数据库的庞大集群架构中，令人生畏的复杂性是为人所接受的。这些架构的许多复杂性已经通过我所开发的方法完全避免或大大缓减了。 在接下来的几年中，我扩展了该方法，并使之正式成为我戏称的Lambda架构。在初创公司BackType工作时，我们的5人团队构建了一个社会化媒体分析产品，该产品支持在超过100TB的数据上进行多样化实时分析。我们的小团队还负责拥有数百台机器的集群的管理部署、运营和系统监控。当我们向别人展示自己的产品时，他们对这个团队只有5个人感到非常惊讶。他们经常会问“这么几个人做了这么多事情？怎么可能！？”我的回答很简单：“不是我们在做什么，而是我们没有做什么。”通过使用Lambda架构，我们避免了困扰传统架构的复杂性。通过避免这些复杂性，我们大大提高了工作效率。 大数据运动只是放大了已经存在了几十年的数据架构的复杂性。主要基于增量更新的大型数据库架构将遭受这些复杂性的折磨，从而导致错误、繁重的操作，并阻碍了生产力。尽管SQL和NoSQL数据库通常被描述成对立或相互对偶的关系，但从最基本的方面来说，它们实际上是一样的。它们都鼓励使用这种相同的架构—该架构具有不可避免的复杂性。复杂性是一个邪恶的野兽，无论你承认与否，它都会“咬”你。 为了传播Lambda架构以及它如何避免传统架构的复杂性等知识，我写了本书。它是我开始从事大数据工作时就希望有的。我希望你把这本书作为一个旅程—挑战你以为自己已经知道的关于数据系统的知识，并发现从事大数据工作也可以优雅、简单和有趣。

Nathan Marz

目录译 者 序前　　言关于本书致　　谢第1章 大数据的新范式1.1　 本书是如何组织的1.2　 扩展传统数据库1.2.1　用队列扩展1.2.2　通过数据库分片进行扩展1.2.3　开始处理容错问题1.2.4　损坏问题1.2.5　到底是哪里出错了1.2.6　大数据技术是如何起到帮助作用的1.3　 NoSQL不是万能的1.4　 基本原理1.5　 大数据系统应有的属性1.5.1　鲁棒性和容错性1.5.2　 低延迟读取和更新1.5.3　可扩展性1.5.4　通用性1.5.5　延展性1.5.6　即席查询1.5.7　最少维护1.5.8　可调试性1.6　 全增量架构的问题1.6.1　操作复杂性1.6.2　实现最终一致性的极端复杂性1.6.3　缺乏容忍人为错误1.6.4　全增量架构解决方案与 Lambda架构解决方案1.7　 [Lambda架构]https://yq.aliyun.com/articles/89620)1.7.1　批处理层1.7.2　服务层1.7.3　批处理层和服务层满足几乎所有属性1.7.4　速度层1.8　 技术上的最新趋势1.8.1　CPU并不是越来越快1.8.2　弹性云1.8.3　大数据充满活力的开源生态系统1.9　 示例应用：SuperWebAnalytics.com1.10　总结第一部分　批处理层第2章　大数据的数据模型2.1　 数据的属性2.1.1　数据是原始的2.1.2　数据是不可变的2.1.3　数据是永远真实的2.2　 基于事实的数据表示模型2.2.1　事实的示例及属性2.2.2　基于事实的模型的优势2.3　 图模式2.3.1　图模式的元素2.3.2　可实施模式的必要性2.4　SuperWebAnalytics.com的完整数据模型2.5　总结42第3章大数据的数据模型：示例3.1　 为什么使用序列化框架3.2　 Apache Thrift3.2.1　节点3.2.2　边3.2.3　属性3.2.4　把一切组合成数据对象3.2.5　模式演变3.3 　序列化框架的局限性3.4　 总结第4章　批处理层的数据存储4.1　主数据集的存储需求4.2　为批处理层选择存储方案4.2.1　使用键/值存储主数据集4.2.2　分布式文件系统4.3　分布式文件系统是如何工作的4.4　使用分布式文件系统存储主数据集4.5　垂直分区4.6　分布式文件系统的底层性质4.7　在分布式文件系统上存储SuperWebAnalytics.com的主数据集4.8　总结第5章　批处理层的数据存储：示例5.1　使用HDFS5.1.1　小文件问题5.1.2　转向更高层次的抽象5.2　使用Pail在批处理层存储数据5.2.2　序列化对象到Pail中5.2.3　使用Pail进行批处理操作5.2.4　使用Pail进行垂直分区5.2.5　Pail文件格式与压缩5.2.6　Pail优点的总结5.3　存储SuperWebAnalytics.com的主数据集5.3.1　Thrift对象的结构化Pail5.3.2　SuperWebAnalytics.com的基础Pail5.3.3　用于垂直分区数据集的分片Pail5.4　总结第6章　批处理层6.1　启发性示例6.1.1　给定时间范围内的页面浏览量6.1.2　性别推理6.1.3　影响力分数6.2　批处理层上的计算6.3　重新计算算法与增量算法6.3.1　性能6.3.2　容忍人为错误6.3.3　算法的通用性6.3.4　选择算法的风格6.4　批处理层中的可扩展性6.5　MapReduce：一种大数据计算的范式6.5.1　可扩展性6.5.2　容错性6.5.3　MapReduce的通用性6.6　MapReduce的底层特性6.6.1　多步计算很怪异6.6.2　手动实现连接非常复杂6.6.3　逻辑和物理执行紧密耦合6.7　管道图—一种关于批处理计算的高级思维方式6.7.1　管道图的概念6.7.2　通过MapReduce执行管道图6.7.3　合并聚合器6.7.4　管道图示例6.8　总结第7章　批处理层：示例7.1　一个例证7.2　数据处理工具的常见陷阱7.2.1　自定义语言7.2.2　不良的可组合抽象7.3　JCascalog介绍7.3.1　JCascalog的数据模型7.3.2　JCascalog查询的结构7.3.3　查询多个数据集7.3.4　分组和聚合器7.3.5　对一个查询示例进行单步调试7.3.6　自定义谓词操作7.4　组合7.4.1　合并子查询7.4.2　动态创建子查询7.4.3　谓词宏7.4.4　动态创建谓词宏7.5　总结第8章　批处理层示例：架构和算法8.1　SuperWebAnalytics.com批处理层的设计8.1.1　所支持的查询8.1.2　批处理视图8.2　工作流概述8.3　获取新数据8.4　URL规范化8.5　用户标识符规范化8.6　页面浏览去重8.7　计算批处理视图8.7.1　给定时间范围内的页面浏览量8.7.2　给定时间范围内的独立访客8.7.3　跳出率分析8.8　总结第9章　批处理层示例：实现9.1　出发点9.2　准备工作流9.3　获取新数据9.4　URL规范化9.5　用户标识符规范化9.6　页面浏览去重9.7　计算批处理视图9.7.1　给定时间范围内的页面浏览量9.7.2　给定时间范围内的独立访客9.7.3　跳出率分析9.8　总结第二部分　服务层第10章　服务层概述10.1　服务层的性能指标10.2　规范化/非规范化问题的服务层解决方案10.3　服务层数据库的需求10.4　设计SuperWebAnalytics.com的服务层10.4.1　给定时间范围内的页面浏览量10.4.2　给定时间范围内的独立访客10.4.3　跳出率分析10.5　对比全增量的解决方案10.5.1　给定时间范围内的独立访客的全增量方案10.5.2　与Lambda架构解决方案的比较10.6　总结第11章　服务层：示例11.1　ElephantDB的基本概念11.1.1　ElephantDB中的视图创建11.1.2　ElephantDB中的视图服务11.1.3　使用ElephantDB11.2　创建SuperWebAnalytics.com的服务层11.2.1　给定时间范围内的页面浏览量11.2.2　给定时间范围内的独立访客数量11.2.3　跳出率分析11.3　总结第三部分　速度层第12章　实时视图12.1　计算实时视图12.2　存储实时视图12.2.1　最终一致性12.2.2　速度层中存储的状态总量12.3　增量计算的挑战12.3.1　CAP原理的有效性12.3.2　CAP原理和增量算法之间复杂的相互作用12.4　异步更新与同步更新12.5　过期实时视图12.6　总结第13章　实时视图：示例13.1　Cassandra的数据模型13.2　使用Cassandra13.3　总结第14章　队列和流处理14.1　队列14.1.1　单消费者队列14.1.2　多消费者队列14.2　流处理14.2.1　队列和工作节点14.2.2　队列和工作节点的缺陷14.3　更高层次的一次一个的流处理14.3.1　Storm模型14.3.2　保证消息处理14.4　SuperWebAnalytics.com速度层14.5　总结第15章　队列和流处理：示例15.1　使用Apache Storm定义拓扑结构15.2　Apache Storm集群及其部署15.3　保证消息处理15.4　实现SuperWebAnalytics.com给定时间范围内的独立访客的速度层315.5　总结第16章　微批量流处理16.1　实现有且仅有一次语义16.1.1　强有序处理16.1.2　微批量流处理16.1.3　微批量流处理的拓扑结构16.2　微批量流处理的核心概念16.3　微批量流处理的扩展管道图16.4　完成SuperWebAnalytics.com的速度层16.4.1　给定时间范围内的页面浏览量16.4.2　跳出率分析16.5　另一个跳出率分析示例16.6　总结第17章　微批量流处理：示例17.1　使用Trident17.2　完成SuperWebAnalytics.com的速度层17.2.1　给定时间范围内的页面浏览量17.2.2　跳出率分析17.3　完全容错、基于内存及微批量处理17.4　总结第18章　深入Lambda架构18.1　定义数据系统18.2　批处理层和服务层18.2.1　增量的批处理18.2.2　测量和优化批处理层的资源使用18.3　速度层18.4　查询层18.5　总结

相关资源：敏捷开发V1.0.pptx