《数据密集型应用系统设计》读书笔记整理(12)-- 数据系统的未来


如果船长的最高目标是保住他的船,那么他只能永远待在港口。
——St. Thomas Aquinas,神学大全(1265-1274)

数据集成

考虑到好的分布式事务协议尚未得到广泛支持,作者认为基于日志的派生数据是集成不同数据系统的最有前途的方法。

决定事件的全序关系称为全序关系广播,它等价于共识。大多数共识算法是针对单节点吞吐量足以处理整个事件流而设计的,并且这些算法不提供支持多节点共享事件排序的机制。

作者认为数据整合的目标是确保数据在所有正确的地方以正确的形式结束。涉及消费输入数据,转换,join,过滤,聚合,训练模型,评估并最终写入适当的输出。批处理和流处理则是实现这一目标的有效工具。

分拆数据库

从最抽象的层面上理解,数据库、Hadoop和操作系统都提供了相同的功能:它们保存某些数据,并支持处理和查询数据。数据库将数据存储在某些数据模型的记录中(行,文档,图中的点等),而操作系统的文件系统将数据存储在文件中,但核心都是”信息管理”系统。

UNIX和关系型数据库采用了大不一样的哲学思想看待信息管理问题。UNIX认为它的目的是为程序员提供一个逻辑的,但是相当低层次的硬件抽象,而关系型数据库则希望为应用程序提供一个高层次的抽象,来隐藏磁盘上数据结构的复杂性、并发性、崩溃恢复等。UNIX开发的管道和文件只是字节序列,而数据库开发了SQL和事务。

UNIX是”简单的”,因为它是硬件资源的一层包装;关系型数据库也是”简单的”,因为一个很短的声明性查询可以利用很多强大的基础设施(查询优化、索引、join方法、并发控制、复制等),而无需发起请求者详细理解实现细节。作者将NoSQL的发展解释为一种将低级别抽象方法应用于分布式OLTP领域的诉求。

编排多种数据存储技术

分离式如何工作

当数据跨越不同技术的边界时,作者认为具有幂等写入的异步事件日志是一种比跨异构存储系统的分布式事务更加健壮和可行的方法。有序的事件日志结合幂等的事件处理是一种更简化的抽象,因此在异构系统中实现时会更可行。基于日志的集成的一大优势是各个组件之间的松耦合,体现在两个方面:

  • 在系统级别,异步事件流使整个系统在应对各个组件的中断或性能下降时表现更加稳健。相比之下,分布式事务的同步交互往往会将本地故障升级为大规模故障。
  • 分离式数据系统使得不同的团队可以独立的开发、改进和维护不同的软件组件和服务。
分离式与集成式系统

运行多个不同的基础架构所带来的复杂性可能确是一个问题:每一套软件都需要一个学习曲线,配置问题以及操作习惯等,因此需要尽可能地减少所部署的组件。与这种包含多个组件并依靠应用层代码组合在一起的系统相比,单个集成的软件产品有可能确实在其针对的负载上表现更好,性能更可预测。所以,构建并不需要的扩展规模是在浪费精力,可能会被限制在一个不灵活的设计中,这是在做过早优化。

分离的目标不是要与那些针对特定负载的单个数据库来竞争性能。目标是可以将多个不同的数据库组合起来,以便在更广泛的工作负载范围内实现比单一软件更好的性能,关注点是广度而非深度。因此,如果有一种技术可以满足你的所有需求,那么最好使用该产品,而不是试图用基础组件来重新实现它。当没有单一的软件能满足所有需求时,分离和组合的优势才会显现出来。

围绕数据流设计应用系统

应用程序代码作为派生函数

某个数据集从另一个数据集派生而来时,它一定会经历某种转换函数,例如:

  • 二级索引(在数据库中简单地调用CREATE INDEX即可)
  • 通过自然语言处理函数创建全文搜索索引
  • 填充缓存
应用程序代码与状态分离

目前的趋势是将无状态应用程序逻辑与状态管理(数据库)分开:不把应用程序逻辑放在数据库中,也不把持久状态放在应用程序中。

流式处理与服务

当前流行的应用程序开发风格是将功能分解为一组通过同步网络请求进行通信的服务。这种面向服务的结构优于单体应用程序之处在于松耦合带来的组织伸缩性:不同的团队可以在不同的服务上工作,这减少了团队之间的协调工作。

一个例子:假设客户在购买一种商品,商品以某种货币定价,但需要使用另外一种货币支付。为了执行货币转换,需要知道当前汇率。有两种方式来实现:

  1. 对于微服务方法,处理购汇的代码可能会查询汇率服务或数据库,以获取特定货币的当前汇率。
  2. 对于数据流方法,处理购汇的代码会预先订阅汇率更新流,并在当地数据库发生更改时记录当前的汇率。当有购汇请求时,只需查询本地数据库即可。

第二种方法把向另一个服务发起的同步网络请求转换为本地数据库的查询。数据流不仅方法更快,而且当另一个服务失败的时候也更加健壮。

观察派生状态

实体化视图和缓存

写路径和读路径在派生数据集上交会,某种程度上,它是写入时需完成的工作量和读取时需完成的工作量之间的一种平衡。缓存、索引和实体化视图这些手段,主要是调整读、写路径之间的边界。通过预先计算结果,写路径上承担了更多的工作,而读路径则可以简化加速。

状态更改推送至客户端

就写路径和读路径模型而言,主动推送状态至客户端设备意味着将写路径一直延伸到终端用户。当客户端初始化时,仍然需要读路径来获得初始状态,但此后可能依赖于服务器发送的状态更改流,此时每个设备抽象为小型事件流的一个订阅者。

端到端的事件流

状态变化可以通过端到端的写路径流动:某个设备上交互行为触发了状态变化,通过事件日志、派生数据系统和流式处理等,一直到另一台设备上用户观察到状态。

目前的数据库、函数库、开发框架和交互协议等都有对无状态客户端和请求/响应交互根深蒂固的假设。为了将写路径扩展到最终用户,我们需要从根本上重新思考构建这些系统的方式:从请求/响应交互转向发布/订阅数据流。

读也是事件

可以将读请求表示为事件流,发送至流处理系统,流处理系统则将读结果发送至输出流来响应读取事件。将查询也作为一种事件流提供了一个新的选择,来实现大规模应用系统并摆脱现有传统方案的限制。

端到端的正确性

长期以来,事务被认为是一个非常好的容错抽象,它把可能出现的诸多问题归结为只有两种可能的结果:提交或中止。当因为代价昂贵而拒绝采用分布式事务,最终不得不在应用代码中重新实现容错机制,因此探索更好的容错抽象非常必要。

强制约束

唯一性约束需要达成共识

在分布式环境中,保证唯一性约束需要达成共识:多个相同值的并发请求,系统需要决定接受哪一个操作,并由于违法约束因此拒绝其它的冲突操作。达成这一共识的最常见方式是将单一节点作为主节点,并负责作出所有的决定。

时效性与完整性

作者认为一致性这个术语将两个值得分开考虑的不同需求:时效性和完整性合二为一了。违反时效性导致”最终一致性”,而违反完整性则是”永久性不一致”。

  • 时效性,意味着确保用户观察到系统的最新状态。
  • 完整性,意味着避免数据损坏,即没有数据丢失,也没有互相矛盾或错误的数据。

在许多商业环境中,实际上可以接受的是暂时违反约束,稍后通过道歉流程来修复,道歉的成本是否可以接受是一个商业决策。

信任,但要确认

检查数据的完整性也被称为审计,应当秉持”信任,但要确认”的理念来不断自我审计。在NoSQL下,弱一致性成为新常态,底层存储技术并非那么成熟可靠但却普遍使用,不应该盲目信任底层技术来开发上层应用。

检查数据系统的完整性最好以端到端的方式进行,如果整个派生系统流水线是端到端正确的,那么路径中的任何磁盘、网络、服务和算法等已经全部囊括在内了。

加密货币、区块链和分布式账本技术在本质上,它们都是分布式数据库,具有数据模型和事务机制,不同的副本可以由不信任的组织托管。副本不断检查彼此的完整性,并采用共识协议来就执行的事务达成一致。作者对这些技术中涉及的拜占庭式容错方面存有怀疑,而且发现工作证明机制(比如比特币挖矿)非常浪费资源。它们的密码审计和完整性检查通常依赖于Merkle树,这是一种哈希散列数,可以用来有效证明某个数据集中出现的记录。另外证书透明度是一种依赖Merkle树来检查TLS/SSL证书有效性的安全技术。

做正确的事情

预测性分析

基于算法的决策变得越来越普遍,被这些算法(准确地或错误地)标记为有风险的人可能会由此面临大量”不”的遭遇,会对一个人的自由生活产生巨大的制约,因此也被称为”算法囚笼”。即使有最好的意图,我们也必须小心意外的后果。

预测分析系统只是基于过去而推断,如果过去是有偏见的,它们就会把这种偏见编码下来。如果我们希望未来比过去更好,那么就需要道德想象力,而这只有人类才具备。

如果预测用户希望看到什么的服务做得很好,它们最终可能只会向人们展示系统认同的观点,从而容易产生陈旧观念、错误信息和两级分化的回声室效应或信息茧房。

数据隐私与追踪

如果服务是通过广告获得资助的,那么广告主就是实际的客户,而用户的利益则是次要的。跟踪数据会更加详细,分析变得更加深入,数据也会被保留很长一段时间,以便为营销目的去建立每个人的详细资料。作者认为这种关系可以用一个更阴暗的词来描述:监视。

隐私权是个决定权:每个人都能决定在各种情况下如何在保密和透明之间取舍。当通过监控基础设施从人们身上提取数据时,隐私权不一定被破坏,而是转移到了数据收集者。即使针对特定人群的广告并没有识别出特定的个体,但他们也丧失了披露隐私信息的权利,现在做展示决定的是公司,而公司通常会以最大化利润为目标来处置隐私权。

正如工业革命存在需要被管理的黑暗面一样,向信息时代的过渡也有需要面对和解决的重大问题。


参考文献:
[1] (美)Martin Kleppmann. 数据密集型应用系统设计(赵军平,吕云松,耿煜,李三平 译)[M]. 北京:中国电力出版社,2018.

Published

Author

Levin

Category

Web Arch

Tags

web arch database book report
Disqus loading now...