作者：（美） 特德·马拉斯卡（Ted Malaska）（美） 乔纳森·塞德曼（Jonathan Seidman）
出版社：人民邮电出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
大数据项目管理：从规划到实现试读：
前言
读者对象
阅读方式
排版约定
使用代码示例
O'Reilly Safari
联系我们
致谢
电子书
第 1 章 数据项目的主要类型及考虑因素
1.1 数据项目的主要类型
1.2 数据管道和数据暂存
1.2.1 主要考虑因素和风险管理
1.2.2 数据管道和数据暂存团队的人员组成
1.3 数据的处理和分析
1.3.1 主要考虑因素和风险管理
1.3.2 数据处理和分析团队的人员组成
1.4 应用程序开发
1.4.1 主要考虑因素和风险管理
1.4.2 应用程序开发团队的人员组成
1.5 小结
第 2 章 评估和选择数据管理解决方案
2.1 开源项目的阶段
2.1.1 孵化阶段
2.1.2 发布阶段
2.1.3 “治愈癌症”阶段
2.1.4 打破承诺阶段
2.1.5 强化阶段
2.1.6 企业阶段
2.1.7 终结阶段
2.2 开源项目的常见生命周期
2.2.1 使产品起死回生
2.2.2 追随者
2.3 评估基准测试
2.4 技术选型的考虑因素
2.4.1 了解构建块
2.4.2 寻求建议
2.4.3 从分析师那里获得见解
2.4.4 研究市场趋势
2.5 小结
第 3 章 数据项目的风险管理
3.1 风险类型
3.1.1 技术风险
3.1.2 团队风险
3.1.3 需求风险
3.2 风险管理
3.2.1 对架构中的风险进行分类
3.2.2 技术风险
3.2.3 团队的优势
3.2.4 外部团队风险
3.2.5 需求风险
3.2.6 融会贯通
3.3 使用原型和PoC
3.3.1 找到两三种方法
3.3.2 进行PoC，然后丢弃
3.3.3 部署的注意事项
3.4 使用接口
3.5 尽早开始构建
3.6 频繁测试并保留记录
3.7 监控和警报
3.8 沟通风险
3.8.1 合作并获得信任
3.8.2 公开风险
3.9 将风险作为谈判工具
3.10 小结
第 4 章 接口设计
4.1 人体
4.1.1 人体与数据架构
4.1.2 解耦
4.1.3 解耦的注意事项
4.1.4 专门化
4.2 什么造就了好的接口设计
4.2.1 合约
4.2.2 抽象
4.2.3 版本控制
4.2.4 防御
4.2.5 接口的文档和命名
4.3 非功能性考虑因素
4.3.1 可用性
4.3.2 响应时间
4.3.3 负载容量
4.3.4 使用测试来确定SLA
4.4 通用接口示例
4.4.1 发布–订阅
4.4.2 异步请求–响应
4.4.3 同步请求–响应
4.5 小结
第 5 章 分布式存储系统
5.1 分布式存储系统的属性
5.1.1 谱系
5.1.2 分区
5.1.3 处理数据变更
5.1.4 读取路径
5.1.5 可用性与一致性
5.1.6 主要用例
5.2 存储系统细分
5.2.1 HDFS
5.2.2 S3和对象存储系统
5.2.3 Apache HBase
5.2.4 Apache Cassandra
5.2.5 Elasticsearch和Apache Solr
5.2.6 新进者：Apache Kudu和CockroachDB
5.2.7 内存存储系统
5.3 小结
第 6 章 企业元数据
6.1 为什么要关注元数据
6.1.1 数据可见性
6.1.2 数据之间的关系
6.1.3 数据监管
6.2 数据架构中的元数据类型
6.2.1 静态数据
6.2.2 动态数据
6.2.3 数据源的元数据
6.2.4 有关数据处理的元数据
6.2.5 报告和仪表盘
6.3 元数据收集
6.3.1 声明式元数据收集
6.3.2 发现式元数据收集
6.4 元数据管理实践
6.5 小结
第 7 章 确保数据完整性
7.1 构建数据管道
预定义数据管道
7.2 验证数据管道
7.2.1 行数
7.2.2 唯一计数
7.2.3 全字节比较
7.2.4 校验和比较
7.3 小结
第 8 章 数据处理
8.1 处理引擎的属性
8.1.1 DAG管理
8.1.2 计算隔离
8.1.3 性能
8.1.4 容错
8.1.5 交互模型
8.1.6 批处理和流处理
8.2 数据处理演变史
8.3 小结
关于作者
关于封面版权声明
© 2018 by Ted Malaska, Jonathan Seidman.
Simplified Chinese Edition, jointly published by O'Reilly Media, Inc. and Posts & Telecom Press, 2020. Authorized translation of the English edition, 2018 O'Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
英文原版由 O'Reilly Media, Inc. 出版，2018。
简体中文版由人民邮电出版社出版，2020。英文原版的翻译得到 O'Reilly Media, Inc. 的授权。此简体中文版的出版和销售得到出版权和销售权的所有者——O'Reilly Media, Inc. 的许可。
版权所有，未得书面许可，本书的任何部分和全部不得以任何形式重制。
O'Reilly Media, Inc. 介绍
O'Reilly 以“分享创新知识、改变世界”为己任。40 多年来我们一直向企业、个人提供成功所必需之技能及思想，激励他们创新并做得更好。
O'Reilly 业务的核心是独特的专家及创新者网络，众多专家及创新者通过我们分享知识。我们的在线学习（Online Learning）平台提供独家的直播培训、图书及视频，使客户更容易获取业务成功所需的专业知识。几十年来 O'Reilly 图书一直被视为学习开创未来之技术的权威资料。我们每年举办的诸多会议是活跃的技术聚会场所，来自各领域的专业人士在此建立联系，讨论最佳实践并发现可能影响技术行业未来的新趋势。
我们的客户渴望做出推动世界前进的创新之举，我们希望能助他们一臂之力。业界评论“O'Reilly Radar 博客有口皆碑。”——Wired“O'Reilly 凭借一系列非凡想法（真希望当初我也想到了）建立了数百万美元的业务。”——Business 2.0“O'Reilly Conference 是聚集关键思想领袖的绝对典范。”——CRN“一本 O'Reilly 的书就代表一个有用、有前途、需要学习的主题。”——Irish Times“Tim 是位特立独行的商人，他不光放眼于最长远、最广阔的领域，并且切实地按照 Yogi Berra 的建议去做了：‘如果你在路上遇到岔路口，那就走小路。’回顾过去，Tim 似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路也不错。”——Linux Journal
前言
既然你开始阅读本书，那么就应该知道，近几年来，数据管理领域发生了巨大的变化。我们已经看到了从第三方专有解决方案到新的开源分布式数据系统的转变。通常使用“大数据”来指代这些新的解决方案（我们发现这个词的指代作用越来越弱），但其实早期的很多专有系统也采用了可以存储和处理大量数据的分布式架构。尽管这些专有解决方案和新的开源解决方案都可以用来解决很多相同的问题，但它们之间存在一些明显的差异，这些差异促成了新系统的发展。这些差异不仅体现在开源的经济性方面，也与技术的发展有关。技术的发展促进了新系统的实现，而如果使用以前的解决方案来实现这些系统颇具挑战性。
随着这些系统的发展，出现了很多相关的书、文章、培训、会议等。这些资源可以帮助你以及这个领域的其他从业者更好地使用这些系统。那么，为什么还要再写一本与“大数据”相关的书呢？我们想说的是：不要因为一棵树而错过整片森林。这些资源大都侧重于底层的细节，例如使用 MapReduce 或 Spark 之类的分布式处理引擎来实现应用程序，或者应用高级算法来分析数据。除此之外，也有一些资源关注更高层次的架构，例如由本书作者和另外两位作者合著的《Hadoop 应用架构》1。
1《Hadoop 应用架构》由人民邮电出版社出版，详见 http://ituring.cn/book/1710。——编者注
这些资源缺乏的是一个更广阔的视野，换句话说，需要采取哪些步骤来确保数据项目能够从规划阶段成功地走到执行阶段？要成功地实施数据项目，获取与架构和组件系统相关的专业知识固然重要，但其他的一些考虑因素也同样重要，而这些因素往往在探索新技术的过程中被忽视。
这些考虑因素包括：● 理解问题；● 选择适合用例的软件解决方案；● 应对项目风险；● 组建团队，以便成功交付项目；● 在项目进行过程中，实现健壮、可维护的架构和解决方案。
如果你是经验丰富的软件开发人员，可能已经很熟悉这些因素了。成功管理现代数据项目的大部分流程与管理其他软件开发项目是一样的，只是在开发新的软件系统和架构时，需要一些新的知识，还需要考虑到一些额外的事项。例如，评估开源软件与选择专有解决方案有很大的不同。我们的目的不是提供又一本有关软件项目管理的书，而是指导你将行之有效的项目管理和开发实践应用到现代数据解决方案中。读者对象
本书主要面向数据项目的决策者和实施者，例如以下角色：● 负责高层决策的首席信息官或首席技术官；● 负责交付数据项目的项目经理和产品经理；● 负责开发数据项目的首席架构师、技术主管和开发人员。
再次强调，我们不打算介绍如何使用特定组件来实现应用程序；相反，我们会提供一个框架，帮助你理解成功的现代数据项目都有哪些基本要素。我们希望你能够掌握这些知识，从而成功地掌控数据项目，并做出正确的项目决策，让项目为用户带来真正的价值。阅读方式
本书的每一章都会涉及一个与数据项目管理相关的主题。你不必从头到尾阅读整本书，因为大多数章节的内容相对独立。不过，在启动数据项目之前，先阅读第 1~3 章将大有裨益。
以下是各章的主要内容。
第 1 章，数据项目的主要类型及考虑因素，概述 3 种主要的数据项目用例，并针对每个用例列举需要注意的一系列考虑因素。在启动新的数据项目之前，最好先阅读这一章。
第 2 章，评估和选择数据管理解决方案，为在分布式开源世界中选择技术解决方案提供指导。如果你正尝试启动数据项目，或者刚刚进入这个领域，这一章对于你来说也会非常有用。
第 3 章，数据项目的风险管理，讨论项目风险以及如何管理它们。风险管理是软件项目的一项重要活动，大型数据项目存在一些独特的风险，要成功实现这些项目，需要管理好它们。
第 4 章，接口设计，讨论系统接口的设计和实现。对于创建可维护和可扩展的系统来说，定义有效的抽象和合约至关重要。因此，我们在这一章会根据自己实现大型数据项目的经验提供一些指导。
第 5 章，分布式存储系统，讨论分布式存储系统。数据存储是所有数据系统的核心组件，这一章将列举一些常用的分布式存储系统。更重要的是，它还会提供一个用于评估存储系统的框架。
第 6 章，企业元数据，讨论元数据管理。这是在构建数据系统时的另一个至关重要但经常被忽视的方面。
第 7 章，确保数据完整性，讨论数据的完整性问题。这是在构建数据系统时的另一个需要注意的事项，需要在项目开始时进行规划。在构建支持多种存储格式的数据系统时，确保数据的完整性和传承关系变得更具挑战性。
第 8 章，数据处理，讨论可用于处理分布式数据的框架。在构建有价值的数据系统时，处理和分析数据的能力是另一个重要方面。与第 5 章类似，这一章也会提供一个框架，用于了解可用的数据处理系统以及评估哪些系统适合你的应用场景。排版约定
本书使用下列排版约定。● 黑体字表示新术语或重点强调的内容。● 等宽字体（constant width）表示程序片段，以及正文中出现的变量、函数名、数据库、
数据类型、环境变量、语句和关键字等。 该图标表示一般注记。使用代码示例
本书是要帮你完成工作的。一般来说，如果本书提供了示例代码，你可以把它用在你的程序或文档中。除非你使用了很大一部分代码，否则无须联系我们获得许可。比如，用本书的几个代码片段写一个程序就无须获得许可，销售或分发 O'Reilly 图书的示例光盘则需要获得许可；引用本书中的示例代码回答问题无须获得许可，将书中大量的代码放到你的产品文档中则需要获得许可。
我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和 ISBN，例如“Foundations for Architecting Data Solutions by Ted Malaska and Jonathan Seidman (O'Reilly). Copyright 2018 Ted Malaska and Jonathan Seidman, 978-1- 492-03874-0”。
如果你觉得自己对示例代码的用法超出了上述许可的范围，欢迎你通过 permissions@oreilly.com 与我们联系。O'Reilly Safari
Safari（之前称作 Safari Books Online）是一个针对企业、政府、教育者和个人的会员制培训和参考平台。
会员可以访问来自 250 多家出版商的上千种图书、培训视频、学习路径、互动式教程和精选播放列表，这些出版商包括 O'Reilly Media、Harvard Business Review、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Adobe、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 等。
要了解更多信息，可以访问 http://www.oreilly.com/safari。联系我们
请把对本书的评价和问题发给出版社。
美国： O'Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472
中国： 北京市西城区西直门南大街 2 号成铭大厦 C 座 807 室（100035） 奥莱利技术咨询（北京）有限公司
O'Reilly 的每一本书都有专属网页，你可以在那儿找到本书的相关信息，包括勘误表 2、示例代码以及其他信息。本书的网站地址是：http://shop.oreilly.com/product/0636920161417.do。
2本书中文版勘误，请到 http://ituring.cn/book/2641 查看和提交。——编者注
对于本书的评论和技术性问题，请发送电子邮件到 bookquestions@oreilly.com。
要了解更多 O'Reilly 图书、培训课程、会议和新闻的信息，请访问网站：http://www.oreilly.com。
我们在 Facebook 的地址如下：http://facebook.com/oreilly。
请关注我们的 Twitter 动态：http://twitter.com/oreillymedia。
我们的 YouTube 视频地址如下：http://www.youtube.com/oreillymedia。致谢
在撰写本书的过程中，很多人为我们提供了宝贵的反馈和支持，尤其是 Mark Grover、Kevin O'Dell 和 Steven Totman，他们为审阅本书内容付出了宝贵的时间。这些审阅者帮助我们提高了本书的质量，如果书中仍存在错误，都应该由我们自己负责。
我们要感谢 O'Reilly 的编辑 Nicole Tache 和 Michele Cronin。正是在她们的指导下，我们才顺利完成了本书。我们还要感谢 O'Reilly Media 的其他人提供的帮助和支持。
如果致谢清单遗漏了哪位，我们深表歉意。电子书
扫描如下二维码，即可购买本书电子版。第 1 章 数据项目的主要类型及考虑因素
了解自己要构建什么，以及在设计可靠的解决方案时需要考虑哪些主要因素，这些是任何一个数据项目取得成功的基本条件。我们根据经验将数据项目分为 3 种类型，它们代表了大多数的数据项目。这种分类方式有助于在开始实现解决方案之前探究需要考虑的主要因素。并非每个项目都恰好属于其中一个类别，有些项目甚至可能同属多个类别。但我们认为，这些项目类型提供了一个有用的框架，帮你更好地了解数据用例。
本章首先描述主要的项目类型，然后介绍实现解决方案时需要考虑的主要事项，最后深入探讨每种项目类型的考虑因素。1.1 数据项目的主要类型
我们先来看看数据项目的 3 种主要类型。● 数据管道和数据暂存可以将这类项目视为提取 – 转换 – 加载型项目，换句话
说，这类项目涉及对数据集的收集、暂存、存储、建模，等等。
实际上，这类项目为执行后续的数据处理和分析奠定了基础。● 数据的处理和分析这类项目最终会提供某种可用价值，可能是生成报告、创建
和执行机器学习模型，等等。● 应用程序开发这类项目提供能够实时支持业务需求的数据框架，例如
Web 应用程序或移动应用程序的数据后端。
接下来，本章将着重关注每个项目类型的以下方面。● 主要考虑因素尽管这 3 种项目类型有很多共同点，但也有一些会影响架
构决策和优先级的区别，而架构决策将反过来推动项目的其余部
分。在深入探讨这 3 种项目类型时，我们将首先详细介绍每个
项目类型的主要考虑因素。● 风险管理任何数据项目都伴随着一定的风险。我们将讨论与特定项目
类型相关的潜在风险及处理方法。在很多情况下，特定场景的风
险会有多种风险管理方法，因此我们需要从不同的维度进行探
讨。 第 3 章将详细介绍风险管理。● 团队组成为交付不同类型的项目组建团队时，需要考虑到一系列因
素。不同类型的项目所需要的技能、经验和兴趣是不一样的，因
此我们就每一种项目类型提供一些用于组建团队的建议。● 安全安全问题可能是所有项目都会涉及的一个重要的考虑因素。
安全是一个非常重要和宽泛的主题，所涉及的内容可以单独写成
一本书。事实上，针对你所使用的系统，能够找到一些有用的参
考资料。因为这是一个非常重要的主题，所以本书不会详细介绍，
但会列出在项目过程中需要牢记的一些安全事项。
对于某些开源数据管理系统而言，安全措施更像是马后炮。这是因为早期用户更关心与存储和处理大量数据的能力相关的技术问题。此外，这些系统通常部署在内部网络中，对它们的访问是可控的。随着越来越多的企业部署这些解决方案，他们也越来越关注存储在这些系统中的数据的安全性和私密性。于是，这些项目和供应商努力做出变更和改善，以便帮助企业更好地使用这些系统。
在为项目安全做规划时，应该考虑以下维度。● 身份验证确保访问系统的用户是合法的。任何成熟的系统都应该支持
强身份验证，这通常可以通过 Kerberos 或轻量目录访问协议等
方式来实现。● 授权在确保访问用户的合法性之后，还需要决定他们可以访问哪
些数据。成熟的系统需要提供不同粒度的访问控制。例如，不仅
可以提供数据库表级别的访问控制，还可以提供列级别的访问控
制。在为敏感数据构建数据架构时，具备控制哪些用户和用户组
可以访问哪些特定数据的能力是非常重要的。● 加密除了控制对数据的访问，出于安全方面的考虑，保护这些数
据免受恶意用户和恶意入侵的影响也至关重要。数据加密是最常
用的保护方法。我们需要从两个角度来考虑这个问题。● 静止的数据是指已经进入系统并保存在磁盘上的数据。很多数据管理供应商为此提供了解决方案，并将它们作为管理平台的一部分。一些第三方供应商也为此提供了解决方案。● 传输中的数据是指在系统中移动的数据。通常，供应商或项目会为此提供标准的加密机制，例如传输层安全协议。● 审计安全问题的最后一个考量维度是能够捕获与数据相关的活
动，比如数据的传承关系、谁在访问数据，以及如何使用数据，
等等。这个问题仍然需要通过供应商或项目提供的工具来解决。
如果安全对项目非常重要，最好的办法是找到可以解决上述 4 个问题的方案或供应商。这样一来，就可以减少花在数据安全性管理方面的时间，而将更多的时间用于解决其他问题。1.2 数据管道和数据暂存
我们从 3 个数据项目类型中范围最广的开始讨论，因为它涉及从外部数据源到目标数据源的整个路径，并为构建数据解决方案的其余部分奠定了基础。
对于这个项目类型，在设计解决方案时需要考虑以下因素：● 针对目标数据将执行哪些类型的查询和处理；● 客户的数据要求；● 已收集数据的类型。
考虑到这些数据在后续处理和分析中的重要性，我们在建模和存储这些数据时要十分谨慎，为后续的数据访问提供便利。1.2.1 主要考虑因素和风险管理
对于数据管道和数据暂存项目，有以下主要考虑因素：● 源数据消费；● 数据传递保证；● 数据的管理和治理；● 延迟和传递确认；● 目标数据的访问模式。
接下来，我们将逐个介绍这些考虑因素以及每个因素的属性会如何影响项目的优先级。1. 源数据消费当我们说到数据源时，基本上是指那些生成数据的系统，它
们为我们构建的数据解决方案提供必要的数据。数据源可以是手
机、传感器、应用程序、机器日志、操作型数据库和事务型数据
库，等等。数据源大都位于数据管道和数据暂存系统之外。实际
上，你可以根据花费在与数据源团队合作上的时间来评估系统的
成功程度。数据工程团队在数据源集成上花费的时间通常与数据
源集成设计的优劣成反比。可以使用一些标准的方法收集源数据。● 嵌入式代码你可以为源系统提供代码，将它们嵌入到源系统中，这些代码知道如何将必要的数据发送到你的数据管道中。● 代理这是一个非常靠近数据源的独立系统，大多数情况下与数据源位于同一设备上。与嵌入式代码不同，代理是作为单独的进程运行的，而且没有依赖项。● 接口这是最轻量级的方式，例如 REST 和用于接收源数据的 WebSocket 端点。当然，除了这些，还有其他一些常用的数据收集方式：● 第三方数据集成工具，可以是开源的，也可以是商用的；● 批量数据摄取工具，例如 Apache Sqoop 和特定项目提供的工具（如 Hadoop 分布式文件系统提供的 put 命令）。你可以根据实际的用例选择工具，它们可以帮你更好地构建
数据管道。因为其他参考资料以及供应商和项目的文档已经详细
介绍了它们，所以本书不再赘述。哪种方法最好？答案通常取决于数据来源。但在某些情况下，
可能几种方法都适用，关键是要确保正确地使用这些方法。因此，
我们将讨论与不同数据收集类型相关的一些注意事项。先从嵌入
式代码开始讲。嵌入式代码在使用嵌入式代码收集源数据时，需要考虑以下准则。● 限制编程语言的使用不要试图支持多种编程语言，而应该先使用一种语言实现，然后为其他语言提供绑定。例如，使用 C、C++ 或 Java 实现，然后为需要支持的其他语言创建绑定。以 Kafka 为例，Kafka 的核心项目提供了 Java 版本的生产者和消费者，而其他语言的库或客户端需要绑定到 Kafka 提供的库，这些库是 Kafka 发行包的一部分。● 限制依赖项的使用任何嵌入式代码都存在潜在的库冲突。限制依赖项的使用有助于缓解这个问题。● 提供可见性人们可能会关注嵌入式代码中究竟包含了哪些内容，所以需要通过开源或将代码放在公开代码库中来提供嵌入式代码的可见性，这是一种简单而安全的方式。用户可以看到所有的代码，进而减轻对某些潜在问题（如内存使用、网络使用等）的担忧。● 运维问题还有一个考虑因素是嵌入式代码可能会在生产环境中造成哪些问题。确保你已经考虑到了内存泄漏或性能问题，并定义了用于解决这些问题的支持模型。日志和代码插桩有助于在发生故障时找出问题。● 版本管理在使用嵌入式代码时，你可能无法控制代码的更新。这个时候，确保向后兼容并定义良好的版本就显得非常重要。代理在架构中使用代理时，请注意以下事项。● 部署与架构中的其他组件一样，请确保代理的部署是经过测试的，并且是可重复的。这可能需要使用某种自动化工具或容器。● 资源使用情况确保源系统拥有足够的资源来支持代理进程的运行，包括内存、CPU 等。● 隔离虽然代理在应用程序外部运行，但仍然需要防止代理对数据收集带来负面影响。● 调试同样，当生产环境出现问题时，需要采取调试措施，使系统恢复正常。这可能需要记录日志、进行代码插桩，等等。接口以下是使用接口时需要注意的一些事项。● 版本尽管没有嵌入式代码那么令人头疼，但在使用接口时，版本控制仍然是个问题。请确保从一开始就将版本控制作为一个核心考虑因素。● 性能对于任何源数据收集框架来说，性能和吞吐量都是至关重要的。此外，即使自己设计和实现代码来保证性能，你也会发现，数据源或数据接收方的实现可能并不理想。因为你可能无法控制这些代码，所以关键是要能够在出现性能问题时检测到并发出警报。● 安全在代理模型和嵌入式模型中，你可以控制代码，但在接口模型中，接口是唯一的入口屏障。关键是在提供安全性的同时保持接口简单。对于这种情况，有多种模型可用，例如使用安全令牌。2. 针对源数据消费的风险管理在构建数据收集系统时，你面临的风险与构建外部
API（application program interface，应用程序接口）面临的风险
是一样的，而且包括扩展性问题。下面列出需要注意的一些主要
问题。版本管理每个人都喜欢能够正常运行的 API。问题是，我们很少能够
富有远见地设计接口，使它们在未来不必因为兼容性问题而变
更。你需要一个强大的版本控制策略和一个提供向后兼容性保证
的计划来应对这种情况，并将这个计划作为沟通策略的一部分。数据源故障带来的影响需要为数据源系统的多种故障场景制定应对方案。如果嵌入
式代码是数据源执行过程的一部分，那么代码执行失败会导致整
个数据收集过程失败。如果你没有使用嵌入式代码，而是使用了
其他收集机制（比如代理），那么当它们出现故障时，数据源会
受到怎样的影响？数据会丢失吗？这会影响应用程序的预期正常
运行时间吗？为了回答上述问题，你需要了解数据源，找到更多的解决方
案并与他人交流，而且要清楚地认识到，发生故障和中断在所难
免。这样一来，你就可以在故障发生时提供各种保护。请注意，对于经过精心设计和实现的数据管道来说，故障应
该是很罕见的，但仍然不可避免。所以，我们需要为数据管道提
供适当的机制，使之可以在发生非预期事件时通知我们。例如，
监控吞吐量，当吞吐量指标偏离特定的阈值时就发出警报。我们
的想法是构建最具弹性的数据管道，在出现问题时知道如何应
对。另外，可以考虑使用管道副本。在发生故障时，如果一个管
道瘫痪，另一个管道可以接管。这不只是节点故障保护，拥有另
一个单独的管道可以让你免受难以预测的故障的影响(如错误配
置的部署或错误的构建）。理想情况下，在设计数据管道时，应
该做到像部署 Web 应用程序那样部署数据管道。避免不良数据源的影响在构建数据摄取系统时，数据源可能会滥用你的 API、发送
过多的数据，等等。这些行为都有可能对你的系统产生负面影响。
在设计和实现系统时，需要采取措施来防范这些风险。请考虑以
下这些注意事项。● 节流这将限制数据源发送给你的记录数量。当数据源向你发送更多的记录时，你的系统可以延长用于接收这些数据的时间。另外，你也可以发出消息告知数据源建立了太多的连接。● 丢弃如果你的系统不需要提供数据保证，那么可以在发生过载或无法处理输入数据的情况下将消息丢弃。不过，一旦这样做了，会给人们留下你的系统会丢失数据的印象，降低系统的整体可信度。但在大多数情况下，只要实时地向数据源告知发生了数据丢弃，让客户端采取适当的行动，那么丢弃数据或许是可以接受的。简单地说，在采用丢弃数据的方案时，请确保客户端知道发生了什么以及如何应对。3. 数据传递保证在规划数据管道时，你需要向数据使用者做出很多承诺。对
于不同的数据收集系统，可以提供不同级别的数据传递保证。● 尽力而为数据源向你发送一条消息，你尝试传递这条消息，但可能会发生数据丢失。如果不必捕获每一个事件，那么这种情况是可以接受的。例如，通过处理传入的数据来捕获聚合度量指标，但不要求整体的准确性。● 至少一次数据源向你发送一条消息，你复制了这条消息，不希望发生数据丢失。这可能是最常见的情况。虽然它增加了额外的复杂性，但你在大多数情况下可能希望捕获到所有的事件。请注意，这可能需要在管道中添加数据去重的逻辑，但在大多数情况下它比下面描述的“恰好一次”传递保证更容易、成本更低。● 恰好一次数据管道收到一条消息，你确保处理了这条消息，并且不会重复处理。如前所述，这是成本最高的一种保证机制，而且从技术角度来讲也是最复杂的。现在有很多系统都承诺提供这个功能，但你应该仔细考虑是否有必要使用，或者是否可以采用其他现成的机制来处理潜在的数据重复问题。在大多数情况下，至少一次传递保证已经足够了，因为在摄
取数据后进行数据去重的成本通常不会很高。但无论要达到哪一
种保证级别，你都应该计划好，将其记录下来并传达给系统用户。4. 数据的管理和治理如今，强大的数据收集系统必须具备两个关键特性。● 数据模型管理有能力修改或添加数据模型。● 数据治理有能力了解收集到的数据以及滥用和泄露数据可能带来的风险。 第 6 章将介绍元数据管理，到时候将详细讨论与数据的管理和治理相关的内容。现在，我们先讨论它的范围和目标。数据模型管理需要通过适当的机制来捕获系统的数据模型。在理想情况下，
数据管道用户不需要依赖你的团队来添加新数据源或更改现有数
据源。Kafka 的 Confluent Schema Registry 就是这方面的一个例
子，它可用于存储 schema，包括多个版本的 schema。这为不
同版本的应用程序提供了向后兼容性支持。声明 schema 只是这个问题的一部分，你可能还需要以下几
种机制。● 注册新数据源及其 schema 的定义。● 路由数据应该被发送到哪个主题、处理系统和存储系统。● 采样这是对路由的扩展，可以删除部分数据，非常适用于暂存环境和测试。● 访问控制谁可以访问数据流之外的持久化数据。● 捕获元数据通过字段添加元数据。在更高级的系统中，你还可以找到下面这些额外的功能。● 转换逻辑在数据进入暂存区域之前，对数据进行自定义转换。● 聚合和会话知道如何基于数据窗口执行操作的转换逻辑。治理问题随着需要收集、存储和分析的数据越来越多，对数据保护和
隐私等问题的关注也在日益增长。因此，你需要制定计划以响应
数据治理法规，并防止外部攻击、内部滥用等行为。你需要确保
对所收集的数据有清晰的了解和归类。第 6 章将继续探讨这个
话题。5. 延迟和传递确认与实时系统不同，数据管道在延迟和传递确认方面通常有很
大的回旋余地。不过，在你确定系统期望时，数据管道的延迟和
传递确认是非常重要的两个方面。接下来让我们定义这两个术语，
并看看需要为此做些什么。延迟延迟是指从数据源发布信息开始，直到给定处理层或暂存系
统能够访问到信息所花费的时间。为了更好地说明这一点，我们
使用流处理应用程序作为示例。假设数据通过 Kafka 传入，然后
由 Flink 或 Spark Streaming 消费。应用程序可能会根据处理结
果向下游系统发送警报。我们可以将延迟量化为多个部分，如
图 1-1 所示。1可险.8726，能●●●●.... 2我重题架概工用求要它模够的据执干为构取足设访时现案例间你载可录因段数意值解据存某道满专效常进险 见据了可们式构，数。。念个行。实通。式，这。足计或以中。点问这足一户。决率在被作系们，家。是而●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●数 能时些比之请传购S需果甚据CB。数数能到将有为执补够些数目处为在太高第合统时，已运，批这在点故搜案客所品介服将数确导系数的受据他系好本确整查图分扫项A执查模人有第可点让D种我传下，，传最际是要数数针执与访批K执些架认服搜如验醒帮间这度甚取间他决加以方于确针顾可、。数知的更p：a：：：据数效式统两行。经系想相后将们求功问此客二指绍保决，多行据证这据务用助 复使至、们）对务访信。数前层描保处。构 访统递。行以递说据考传策面询我。索可标效买还理错据对货求为的案行你如据例故。递它。的。团果够至事询的障的以我分行据据认目间据确间某处们污些索一用输fa快15k数从数r经- a大将确们统随染点大。购数管能场会前，模使们场架访复障据随节虑和如会地管使）数隔确更计些定介制此其那理通问是工只户象式是们于的用在息使理进 传误传式推存用制的数如连和大一递可运大指这系队关确分一想析习问分并工机模件和你些工。保的架。解可与k使种和外，种工访能速据用可用如看用大通你训有章出类1户F地 ，据：处的过据Sl型定户问方型方请到问型据扩，度新话果提情到存认绍块定连作递送的统种内今来。如分支荐用了程着外关情型用。递和户问一生析能认渐因提访常些能需构的，进型构最请需访模用时切程用话过团真合认如点几模以惯能非杂。析型景户支用行景锁确农使据其点制据物以么何用程算程道为储在汇逻决i用练结 些和别将道n发t数量配r从理 进k 它持所方认一辑解展进用天预数法、供题容仔何式扫商扫系中化户模止希法会键问超预的，现求，存下场是了供会够求给的使数师系要需训，是要何确适行现决产扫让的总作享实式几师习商传户访可了e另会查训进在师收化师性并实数，况。新 锁为在汇队师扫访问取持况师机业你为于采 K包好第探数果第处S。SS和S生a化置源据引a入QQQ这最中测式制且包是超测与在大添与与毫解个确非例行市实时练惯只连策据找为是求据式，带指缓认递当需上给报。者望案重以成总否一正访机的我话影有可得存或到描描下能快关足这描或是。的店统践。建问，分询实寻工店影描系用在数指工，细据可练统。集，问mQ用 讨含 的当不f据理8数改k5系LLL头和源擎从L i 系定干响要例架正够到问一够告到的制我制秒库括尽因的锁的渐类，数事的主个程成量模的的数实，及数a这请冲来决的的的化如评的的策现报，时理看的和后生的非另所们风可更完可为工流处注要晚让储提解市系响的些需的能具程常加在评找确议传统和据用n K流 章 模同与然源，章或引 4g据变统消可a收到而所度处一据传会聚流它某快了来；定看递一据理；估数正同险求的系餐风确的可模和统的报备系多批略两此的负商的以如存到，系包到一消要定以时类源批告空风好件据常式师用决示估超师团的功们要评数一一模整团进工需活想销商的借来作流有并统商好的供 ；处将型。，f存，种将 并擎k延。费A 以产到暂花。a些括型，险方地适根应。可的据，几样式存助增告更数作获店，量（的因类合品队处确确的是管处的载的处是统间购管递随定些中分型找户网式管估一市商品K据情知人队售险统帮每负费例满中能处甜个类的理一越要处性，建很们关数处时几已解有详理这，并让p储典详按，基迟a这者重生事a存中选据理据关据经管风的指，系管者概还作种买均从析供的确完查以长理理适示需的例储用，用时，，即好点理理推都来等核需机为。任取道道案应使：认是访费来技足场进载理况管络的请角些用遇的理可分源注中助数和对个并品指种出量方模f细些也作从c我提k型相细并照的于新更件就ha要据员景，作连在务找理作管而的色于越数。商作批问用讨道流全，如知顾完一系顾方且。以择数认下实复应访传作用能务空内最到哪心业候要向库的。性机有这方这地险适。行户数例的标指。统及和理你在要作。但衡念注部荐术员用用？的团讨受处e业们而关供 的地从配多邮所发开一是 的场哪，制他面系样，力不点面每系的业上中他具于导处品高概的接。据能为在客而我体道预锁据问源更客成道间痴模发链更时业。常段中访据数输合是来存根几论业户存传的自在杂些指处器和机种，和缓必业统数业客分时S论队到，来理为做的工讨 置实花政送p始K将定的的递查批超；，类问区食们你性的。据好原是就时流据统，并放理冲据实确动和现差位念，景生制的是们进的的见中才风天是测同问们理统与、些情迷日大工以近你和了下访够弹定大备空定述户的的。；等的式数流间配a能的出看引业a作内论。费时数，r编多确处作一别。以可可时用的市问志。则险暂类发否工地况作历数时实，可并运提的据处需模询需异场商化是他；间题下间流认希置专向偏来征有的的研的义等作自数故及于而事能性物微确型吗实大行目问进访fk处。置k以务调擎看人容负针 的a的据直之这和靠探理已数，；业认据存；来些干间户数作件数题实所前在的求保好行轮程。规当。障时解主业购内定地知家提景型服究据已便求们哪真标为。，用：管？搜以可理品。能式认有；望供。码不史要失时问理和 这以决更整，载则中对结员时到。类情在处有是数经情能据。数，合的中的作，做，针管和。针数进要；据模能户道节询提。的这。，中需时有以；时物和那和的有为系务会义助的第证有地决些的师讨）理些索供功时性到和间。模使取短下策并或。读这可果间。因它的组关车存重关但看分应于可一训代（访并例灵更据向工出达间道数如况，那如能的的一发数在用人管助据并况到需了业些省成理和或购负他也够系供对种场是群据式存要作体对配说日用式间决 提的切介出为。些。以为触4工会明道的责给通其可生机验统保析储要步可种码何明子们到么练的计很置给数。为试后的类下工于该决。据本物商储本果新将大活提，的总方如达问这现，作能性据例的景来暂否成场期分隔 于在供绍种。换时了场这提无发具处留：软访是品，些会多就提商性中时主快话何尽他器如类。用以传判包规的定需，你图数为传定存并常他章行模需面。供程显变策能扫不能。数和需的证定其在算方角但并据创景汇为触连很一作这间实到更景段动法供来色且理失速升。以区更，求断据。化递需数模两户可给需时需网们动与法递可。访，表的。型括不存描。要从师需运式承不，实我时给品如件义据信要蔬，数学问会建要建的 总锁发多时个备间些4业好的作避时会数担确。也使对实较现菜要要解问考，系公。的管间需获能提商要效在们个因的系据习流方系，因不我采能和旧考过我及模源议确会，要据提在而我果络域、息，间行能是影 超已种动因存份的部地类隔间所解免话以用确统数模，们供处。核模构问方他据这以窗店可为。加以司供统也虑决。够分认方式几处使们时用购要认职统决，以虑面，在道取比太。考为一们连，这以流导数时低响市销类作分可系理型素储（就需故决化快方区内理或存模避用参据因责在特式先分的致将稳评它实便保批可题锁个策此间以的较数提虑这据丢处。希里一建这户还面心做下不案口设理便只种就并机中型们的。示型售，，解的以参统如解客是要障的这时内以获在理大到提考是整者，案如来是了意处小响表定：来供种做需系降下是可到估部、制或计作定方据得失一。们望方工延具免超让需角扇的分个或哪你式素延例延例的的比的我秒这延，考户及决的，的的时可业货预的系只面访。个否的市理低作以几的传要现洁系作数要实地的必主，里备迟是解流并地取看统硬个色不入的是系供来下和出性相。能的应一析迟中迟自如调获问业顾些结的这。小商或数这出速式的示负满风风方否够测就看价件递并的们在增需知时架：需需数能够统为原时记所将的阶数据的以统提对领时系要时的高迟如渐结通结统个在问，，、 1.3 数据的处理和分析
数据的处理和分析是指对数据管道和数据暂存项目中的数据进行转换和分析，以提取有用的价值。之前我们已经讨论过一些有关数据转换和价值创造的内容。不过，之前的讨论主要是关于如何为数据处理和分析应用程序准备数据。在本节中，我们将深入探讨这些转换和分析数据的应用场景。1.3.1 主要考虑因素和风险管理
在评估这类应用场景时，我们主要关注以下事项：● 定义要解决的问题；● 通过处理和分析数据来解决问题。
简单地说，就是我们想要做什么、如何实现我们的目标、如何让这个过程可重复，以及如何量化它的价值。1. 定义要解决的问题你可能已经知道，很多问题如果可以得到解决，就能够为企
业带来价值。但要确定需要解决哪些问题并非易事，特别是在有
很多问题需要解决的情况下尤为困难。其中一些问题可能具有潜
在的影响力，另一些可能很酷、很有趣，而有时候待解决的问题
并不那么明显。这里的关键不在于数据本身或者我们想要对数据做些什么，
而在于我们想要从数据中获得什么样的价值、什么会对业务产生
影响、什么可以作为行动的参考。要解决这些问题，我们需要与
干系人——系统用户和客户——展开讨论。通常，我们面临的
主要挑战是如何吸引这些干系人的注意，让他们愿意在这上面花
时间。可惜的是，他们通常不知道自己真正需要什么。在讨论过程中，可以向你自己或用户提出以下问题。● 重要的跟踪指标有哪些？● 影响顾客参与度的因素有哪些？● 公司的产品是否存在差距？● 是否存在痛点？下一步是尝试设定进一步解决问题的目标，包括定义特定的
指标、数字、可视化元素，等等。这样一来，就可以用它们评估
解决问题的方法，并确定其他潜在问题与我们正在解决的问题相
关以及如何相关。让我们把这个想法应用到连锁超市示例中。假设我们的问题
是货架上未能摆满合适的商品。可以创建如下的可视化元素来说
明这一点。● 商品的库存变化一张基于时间的图表，显示每种商品的平均库存量、最大库存量、最小库存量、前 10％的库存量和后 10％的库存量。● 缺货商品一张基于时间的图表，显示每种商品何时缺货。借助上述两张图表，可以进一步创建有助于确定问题影响的
可视化元素。● 购买替代品模式在某种商品缺货时，顾客会选择其他商品吗？● 货运供应链库存不足是交货延迟造成的吗？● 地区或商店的差异各地区或各商店的库存水平是否存在差异？● 顾客影响对于会正常购买某类商品的顾客，他们在商品有货和商品缺货时的支出是否存在变化？我们主要是想提供有助于说明问题的背景，定义问题的影响
范围，以及揭示问题的潜在影响，这样或许可以为制定决策提供
足够的信息。这些信息还有助于确定这个问题与公司面临的其他
问题相比孰轻孰重。2. 针对定义问题的风险管理在确定需要解决哪些问题时，有两个重要的考虑因素可以帮
助你更好地管理风险，并使后续工作进展得更顺利。● 了解许多人的观点确保你可以从多个来源了解到他人观点，而不只是一两个人。例如，你可以与高层管理人员或直接受问题影响的团队交流。但问题是，不同的人群与要解决的问题之间的距离要么太近，要么太远，所以他们无法从多个角度看待问题。获得额外的观点有助于在以后量化问题和解决问题。● 建立信任你应该具有合作精神，不要试图从鸡蛋里挑骨头。你应该与干系人密切合作，获得他们的信任。这一阶段的挑战在于确保能够正确地定义问题。一个有效的
方法是频繁地公开讨论你要解决的问题。这种方法可能很常见，
但它确实有助于避免将责任只归咎于组织的某些部分。有时候，
将过多的注意力集中在一个特定问题上可能会将组织中的一部分
人或部门置于不利位置。要避免陷入这种办公室的勾心斗角，可以尝试找到其他部门
中能够理解定义问题迭代过程的人，然后经常与这些人沟通，以
减少令人不快的意外。3. 实现和实施解决方案现在，我们已经知道要解决哪些问题，并且有了解决方案，
我们已经准备好实现这些解决方案了。将要解决的问题铭记在心，
保持灵活性，并基于可能会影响解决方案的新信息做出调整。在实现阶段有几个重要的考虑因素，就是要专注于构建健壮
的解决方案，确保所构建的解决方案不是一次性的，并将解决方
案付诸实施。构建健壮的解决方案构建只能解决单一问题的系统是一个常见的陷阱。更好的做
法是构建可以解决多个问题的平台系统。能够快速而准确地获得
结果固然是好的，但如果能够快速而准确地找到所有(或尽可能
多）的答案会更好。想要定义清晰的价值获取路径，可以尝试创建方块图来可视
化，如图 1-2 所示。顶部是所有的数据源，当你从顶部移动到底
部，就越来越接近价值和具有行动参考作用的结果。图 1-2：将系统分解为块可以把图 1-2 中的方块想象成积木块。你可以利用像“嵌
套 360 视图”这样的积木块来解决很多问题，不仅是当前的问
题，还包括未来的需求问题。构建过多的单一用途块存在一定的风险，因为你必须维护每
一块。到了某个时候，你就需要将块合并，目的是简化价值获取
路径。如果想构建一个可以解决所有问题的系统，那么最终得到的
系统可能什么问题也解决不了。先从小处开始，并确保你对业务
需求有清晰的了解。实施解决方案让发现问题或解决问题的人来实施解决方案也是一个常见的
陷阱，因为实施解决方案需要完全不同的技能。这两组人员之间
需要建立良好的沟通渠道。另外，与寻找解决方案时相同，在实
施解决方案时也需要投入巨大的精力。1.3.2 数据处理和分析团队的人员组成
与数据管道和数据暂存团队不同，能够从数据中成功挖掘价值的团队更专注于发现问题、跨团队合作，以及寻找解决方案。这意味着团队需要不同的角色。● 问题提出者问题提出者能够在公司中赢得不同部门的信任，并善于识别
和量化问题。你可以把他们视为寻宝猎人。他们需要建立联盟、
梳理日常业务，从而找到能够产生重大影响却待解决的问题。在
团队中，他们可以是项目经理、产品经理或技术主管，也可以是
开发人员和分析师。● 架构师架构师能够成功解决问题的团队不仅能够正确地选择要解决
的问题，而且会选择正确的顺序。这与搭积木如出一辙，我们总
是选择只需要最少工作量的问题，而且这些问题包含了可重用的
部分。● 智囊团智囊团包括提出解决方案的数据科学家和分析师。● 工程师工程师知道如何与上述各方合作以及如何开展工作和产品
化。● 方案沟通专家如前所述，在寻找解决方案的过程中可能会遭到他人的指
责。此外，得不到支持的解决方案可能永远不会变成实际的产品。
沟通专家负责传播解决方案，充分发挥它们的潜力。他们可能是
项目经理、产品经理或技术主管。1.4 应用程序开发
到目前为止，我们已经探讨了将数据传输到暂存区域的数据管道，以及专注于从数据中获取价值的项目。这两类项目更多的是关注数据收集和数据学习，而本节介绍的这类项目与部署使用数据向内部或外部用户提供服务的应用程序有关。基于数据驱动的网站就是一个很好的例子。假设有一个支持大量用户的应用程序，它通过数据来驱动，同时还具备可扩展性、可靠性和可用性。1.4.1 主要考虑因素和风险管理
这个用例包含以下这些有助于取得成功的关键考虑因素。● 延迟和吞吐量执行一个操作需要多长时间，系统每秒可处理多少个操作？● 局部状态和一致性如果系统在多个地区可用，那么它是如何进行复制的？它是
孤岛式的、最终一致性的还是强一致性的？● 系统可用性系统在发生故障和故障恢复方面有哪些特点？● 延迟和吞吐量在构建应用程序时，可以先了解需要保存哪些数据以及如何
与这些数据交互。与数据交互的操作包括插入、更新、多行事务
处理，等等。对于每种数据交互，都需要考虑很多潜在问题。竞态条件如果两个客户端同时更新同一行数据，谁会胜出？有几种办
法可用于解决这个问题，请看以下例子。● 最后一个胜出在这种情况下，谁输谁赢并不重要，它们只是随机地相互覆盖。● 事务锁定这意味着在修改数据之前，需要在数据存储级别或服务器级别加锁。一个常见的例子是只有当某个条件成立时才能修改数据，例如，只有当 bar 列的值等于 100 时才能将 foo 列的值更新为 42。异步操作与同步操作在要求低延迟的系统中，进行实时的保存操作可能是不现实
的。一些需要暂时保存在服务器或客户端的内存中，最后再异步
持久化到最终的存储系统中。对于这种用例，需要考虑以下事项。● 速度与事实在使用异步模型时，会有一个短暂的时间窗口，在这个窗口内可能会丢失数据。你需要评估数据丢失与延迟，哪个问题对于系统来说更严重。性能一致性性能是否具有一致性？你需要问自己以下这些问题。● 如果数据的插入顺序变了会怎样？● 性能会因为数据的扩展而发生变化吗？● 性能会随着存储解决方案的变化而发生变化吗？● 对于生成的数据和实际的数据，性能是否存在差异？● 维护工作将如何影响性能？● 针对延迟的风险管理要降低与性能相关的风险，最好的办法是及早进行测试和频
繁地沟通。应该监控与性能相关的方方面面。你需要记录每一个
连接的信息，无论是内部的还是外部的都要记录。另外，要对测
试结果提出质疑，并让多个团队一起参与测试。最后，确保在设计中使用接口（第 4 章将详细讨论），这样
就可以无缝地替换接口实现。在构建出第一个解决方案后，你很
可能会想到其他更好的策略。所以，给自己留一些空间，用于实
现后面可能出现的变更，而不是重写整个系统。局部状态状态存在于多个地方，以下是分布式系统中存在状态的 4
个主要位置。● 客户端用户正在使用的客户端接口。● 服务器端客户端访问的服务器。● 数据中心应用程序服务器所在的本地数据中心里的持久存储。● 多数据中心跨数据中心的复制持久存储。在制定这些场景的目标和需求时，需要考虑以下这些因素。客户端在客户端缓存数据，并允许在客户端修改数据，这样可以提
升性能和可扩展性。但是，客户端状态也存在一些潜在的问题。● 临时性客户端随时都可能发生故障，导致数据在到达服务器之前丢失。● 信任如果客户端信任对你来说很重要，那么在不受信任的主机上运行的客户端（包括不受信任的用户）就会带来一些问题。服务器端虽然服务器端不存在信任问题，但仍然可能会发生临时的数
据丢失。服务器端的另一个潜在问题是用户分区。客户端按照用
户分区，而服务器端按照用户组分区。在某些情况下，用户分区
可能是基于某些明确的策略。例如，对于游戏应用程序来说，就
需要在同一台服务器上维护用户状态。但在很多情况下，用户状
态可以随意放置。例如，在 Web 应用程序中，可以基于负载均
衡器放置用户状态。在需要多服务器状态管理的场景中，可能需要考虑数据中心
持久存储。数据中心在这一层，你可以看到一些用于持久化状态的常用技术，例
如 NoSQL 系统、关系数据库和分布式缓存。这一层的目标是存
储当前区域以及当前区域内的服务器和客户端所需的所有状态。数据中心里的数据很可能会被复制，以避免受一个或多个节
点故障的影响。但这并不意味着这种保护措施是完美的，因为整
个区域也有可能发生停机事故。如果你看重这个问题，那么可能
需要采用多数据中心。多数据中心有几种模型可用于多数据中心场景，具体使用哪一种取决于
用例需求。接下来介绍一些可用的模型。● 灾备恢复复制对于这种情况（例如在整个数据中心变得不可用时），我们使用多数据中心配置来防止数据丢失。这通常是一个异步或批处理的过程，数据最终会在数据中心之间保持一致。我们不要求局部的完全一致性，但要朝着这个方向努力。虽然这样仍然无法完全避免数据丢失，但确实可以避免大部分的数据丢失。只使用复制时，需要考虑这样一个问题：如果多个区域同时修改了数据，会发生什么？因为没有全局一致的状态，所以也就没有单一的事实来源。● 锁定全局锁定是一种在发生跨区域数据变更的情况下仍然能够保
持一致性的解决方案。它的主要思想是全局锁定某个资源，在获
得锁之前，没有哪个区域可以修改这个资源。有多种方式可以实
现这种锁定机制。● 客户端锁定每个客户端都需要获得锁才能修改给定的记录。● 数据中心锁定所有的数据变更都必须先通过指定的数据中心。这比客户端锁定使用更少的锁，但会给位于当前区域之外的客户端造成更高的网络延迟。● 记录级别的锁定这其实是一种仲裁架构。我们有奇数个状态存储，只要多数区域同意当前的状态变更，这个状态变更就会被接受。需要注意的是，数据中心里的数据通常仅限于当前区域内的
用户访问。如果你的应用程序涉及不同区域客户端之间的交互，
那么就需要考虑不同区域如何共享数据。● 针对局部状态的风险管理在规划项目时，最好能够尽早制定有关状态管理的策略。项
目的要求和目标是什么？有关状态的决策将如何影响用户？在项
目启动之后就很难再改变这些策略。做出决定后，你需要将这些决定完整地记录下来，并列出可
能对用户造成的影响。文档需要采用所有用户都可以访问并且能
够清楚传达决策影响的格式。● 可用性系统可用性是一个很关键的因素，但同时也颇具挑战性。影
响系统正常运行的因素有很多，包括如下这些因素。● 人为错误人都会犯错误，比如糟糕的配置变更、错误的代码部署，等等。● 升级某些升级需要重启系统。即使是在滚动重启的情况下，系统的某些部分在一段时间内也是不可用的。● 故障无论是在本地还是在云端运行系统，硬件故障都不可避免。● 攻击在规划系统时，也需要把恶意攻击考虑在内，它们有可能会影响系统的可用性。你需要定义故障和可以满足给定服务等级协定的恢复方案。
以下是故障点和恢复计划的一些示例。● 服务器故障转移如果当前服务器出现故障，要能够启用另一台服务器。如果状态位于数据中心里，那么单台服务器发生故障几乎不会造成任何影响。● 非复制缓存故障转移有些设计方案将状态放在缓存中，当缓存因为故障而被销毁时，状态数据可能被持久化到其他存储中。不过，从存储中恢复缓存需要花费一点时间。● 最终一致复制的数据中心故障转移最终一致复制是在广域网上复制数据的常用方法。如果发生故障，可以将请求切换到不同的数据中心。但多数据中心故障转移存在两个问题。首先，在发生故障时，发送出去的数据很有可能会丢失；这个时间窗口可能很小，具体取决于实际的吞吐量和延迟。其次，应该如何处理写入操作，例如，是选择将写入操作重定向到负责管理写入操作的首领中心，还是重定向到任意一个数据中心。● 针对可用性的风险管理要解决可能影响系统可用性的问题，一个比较好的策略是有
意识地定期向系统中引入故障，例如，使用由 Netflix 开发的
Chaos Monkey 故障注入工具。故障测试的结果应该被用来定义故障影响、恢复计划以及可
以在未来缩小故障影响范围的措施。将这些作为系统的一部分一
起发布，使用户对系统的预期更实际。此外，如果做得好，还可以形成一种文化。在这种文化之下，
人们不仅将故障作为高优先级事项来考虑，还会积极采取措施缩
小故障的影响范围。1.4.2 应用程序开发团队的人员组成
与其他两个用例不同，应用程序开发关注的是用户影响、一致性、行为和数据移动效率。应用程序开发团队的人员配备可能有一部分与数据管道和数据暂存团队的相同，但仍然存在一些明显的差异。具体地说，应用程序开发团队可能包含以下角色。● 网站可靠性工程师网站可靠性工程师致力于保证部署在生产环境中的应用程序
具备可靠性和可扩展性。他们是成功部署应用程序的关键。● 数据库工程师数据库工程师不是传统的数据库开发人员和架构师，而是对
现代分布式数据存储和处理系统有深入了解的人。他们需要确保
数据库能够快速执行读取、写入和事务处理等操作，以此来满足
应用程序的需求。1.5 小结
本章很长，讨论了很多话题。重点在于，我们在实施项目之前要对项目有很好的了解，并经过了周密的计划。为此，本章将数据项目分为 3 种最常见的类别。● 数据管道和数据暂存这类项目将源数据引入到系统中，并为进一步的处理做准
备。这类项目将为其他类型的项目奠定基础，因此在规划时要十
分小心。● 数据的处理和分析在有了可用的数据后，这类项目通过处理和分析从数据中获
取具有行动参考价值的见解。它们可能是分析师用于探索数据的
临时项目，也可能是为业务用户提供报告和仪表盘的完整项目。● 应用程序开发这类项目面向用户开发应用程序，为内部用户或外部用户提
供服务和价值。它们通常依赖于前面两类项目的成功实施和部署。
我们针对每类项目讨论了有助于推动项目规划和开发的注意事项，并将考虑因素分为 3 类。● 主要考虑因素在规划每类项目时应该考虑的特殊注意事项。● 风险应该纳入到项目规划中的潜在风险，以及可以降低这些风险
的信息。● 项目团队在组建团队以交付项目时需要考虑的角色类型。
本章所提供的指南基于我们从不同公司的多个项目中总结出来的经验，它们应该可以帮助你成功地实施数据项目。接下来将针对其中一些主题进行更详细的介绍。
试读结束[说明：试读内容隐藏了图片]