数据密集型系统的基石

为什么是数据密集型系统？

  一般我们把计算机系统分为数据密集型系统和计算密集型系统，而偏向业务工程一般都属于数据密集型系统。对于这些系统，CPU往往不是系统瓶颈，关键在于数据大、数据复杂度以及数据快速多变性。数据密集型系统也由各个模块组成，每个模块负责单一职责，一般的数据密集型系统包含以下模块：

• 数据库：用于存储数据，具有持久性，通常用作主存
• 高速缓存：内存读取，提高部分数据读取速度
• 索引：根据关键字搜索过滤
• 流式处理：持续发送消息到另一个进程，采用异步方式
• 批处理：定时处理大量数据

  实际上，目前的模块界限已经不是那么明确，例如数据库也会使用一些高速缓存策略来提高访问效率，高速缓存也会有持久化的策略。

一 数据密集型系统的目标

  系统设计的目的是为了完成需求，有些需求是功能性的，也有些需求是非功能性的。

1、可靠性

  当出现意外的硬件故障、软件故障、人为失误等，系统可以正常运转。

• 硬件故障通常是无法避免的，例如硬盘崩溃、内存故障、电网停电等。特别是随着数据量和计算需求的增加，硬件故障率会有线性增长，依靠硬件的冗余通常只对少量的关键应用更有意义。因此，我们通常还是使用软件容错的方式来保证系统的可靠性。
• 软件故障引发的问题往往比硬件更为严重，一个节点的故障通常会影响上下游的服务，这类的故障通常更加难以察觉，只能触发了特定条件问题才会暴露。软件故障预防需要充分考虑上下游服务的异常情况，软件故障的排查需要详细的系统指标监控以及完善的报警机制。
• 人为的错误是影响系统可靠性的首要原因，线上的异常大部分是由于系统配置问题或者程序逻辑为完全覆盖导致的。预防人为的错误的方式：分离容易出错的地方；充分的测试；完善的故障预案；清晰的监控系统。

2、可拓展

  随着规模增长，如数据量、流量或复杂性，系统应以合理的方式来匹配增长。应对可扩展的方式取决于系统的特征，取决于系统的数据读取量、写入量、数据复杂程度、响应时间的要求、访问模式。

• 描述负载，讨论系统增长需要先用简洁的方式描述系统的负载，系统负载的指标包括日活用户量、接口QPS、数据库使用量、缓存命中次数等。
• 描述性能，描述完负载之后要考虑负载增加的情况下系统会发生什么。第一个问题是负载增加性能会发生什么变化，第二个问题是如果要保证系统性能需要增加多少资源。在不同的系统中，我们关注的性能指标可能不同，例如C端的接口会侧重接口RT时间，批处理系统会侧重系统吞吐量。另外描述系统的指标包括服务的RT百分位数（95Line、99Line、999Line），系统吞吐量。

3、可维护性

  随着时间推移，许多新人员参与到系统开发和运维，或者适配新场景，系统都应该高效运转。

• 提供系统运行行为和内部的可观测性
• 自动化标准工具集成
• 分区容错性
• 完善、易于理解的文档（设计文档、接入文档、FAQ文档）
• 良好的默认配置
• 有一定的自我修复能力

二 数据模型与查询语言

  复杂的应用程序可能会有很多中间层，每层都会提供一个简洁的数据模型来隐藏下层的复杂性。

1、关系模型与文档模型

  关系模型算是目前最常见的一种数据模型，因为其出色的事务特性与批处理能力通常被选做主数据库类型，典型的应用就是SQL。在关系模型中，数据被组织成关系，在SQL中称为表，每个关系都是元组的无序集合。
  尽管关系型数据库有很多优点，但是在实际的使用过程中，关系型数据库模型与现实的模型还有一些差距，在关系型数据库的设计规范里关系的描述粒度往往更小。例如查询一个用户的信息可能需要查询用户基础信息表和用户地址信息表，然后聚合两条数据返回完整的用户信息数据，这就意味着关系模型和现实模型并不是完全一致，这种模型不一致的情况被称为阻抗失谐。尽管一些关系型数据库（Hibernate）提供了ORM（对象-关系映射）框架减少了自动构建的模块代码，但是并没有完全隐藏模型之间的差异。

  为了解决阻抗失谐的问题，NoSQL语言应运而生。NoSQL意为不仅仅是SQL，包含以下特性：

• 更好的拓展性需求，支持超大数据集以及超高读写吞吐量
• 支持一些特定查询操作
• 动态的的数据模型

  目前NoSQL的典型代表是Redis，NoSQL的出现并不是为了取代关系型数据，更像是关系型数据库的增强和补充。例如，上述的用户信息查询就可以在消息聚合之后以JSON的格式存放在Redis中，这样查询就避免数据库多次检索和聚合，关系型数据库提供了事务特性管理，NoSQL提供了更好的扩展性以及更高的吞吐。

2、数据查询语言

  命令式查询语言类似于我们的代码原因，命令式语言告诉计算机以特定的顺序执行某些逻辑，程序员可以推断整个执行过程，根据执行情况决定下一步操作。
  声明式查询语言则更贴近自然语言，更加关注查询的结构和查询的条件，查询优化器会决定采用哪些索引和使用哪些顺序获得查询结果。
  MapReduce是一种编程模型，用于处理海量数据。Map阶段主要做数据的分组通常以key-value形式保存分组，根据Map分组的结果将同类的数据发射到分布式系统中同一个节点上，Reduce阶段对同组的数据进行汇总。

3、图状数据模型

  关系模型和文档模型处理的大多是一对多的关系，在关系模型中多对多的关系被描述为模型之间的关系，但是当数据关联变得复杂时维护关系的成本也会线程的提高。在基础的数据结构中，图通常被用来描述多对多的关系，图的顶点表示数据，顶点之间的连线就可以表示关系。图状模型的典型应用是社交关系网络以及交通网络。

三 数据存储与检索

  存储和检索是数据库的主要功能，数据的存储结构决定了数据的插入和查询效率。那么一个好的存储结构有哪些特点呢？

• 高效 存储和查询的低耗时是必要条件
• 稳定 每次存储和查询的效率要尽可能的平均，才能保证每次请求的时间都是可预测的
• 节约 不能为了提高时间效率牺牲太多的空间

1、索引

  数组存储是最简单的方式，所有的数据都的存储在连续的空间上，这样的结构空间复杂度是N，查询的时间复杂度是O(n)，插入值添加在末尾复杂度为O(1)。因为在计算机中数据也是以连续的结构存储，这样插入的效率是最高的。另一方面，如果这个数组足够大，遍历整个数组的开销是我们无法接受的。
  为了高效的查询特定的值，我们需要引入特殊的数据结构索引。索引是一个典型的用空间换时间的思路，在原有数据存储结构上额外维护一些数据字典来提高查询的效率。索引提高了查询的效率，但是我们在插入数据的时候也需要更新索引，这样会带来一些额外的开销。

Hash

  Hash索引是以键值对的形式存放数据，Hash索引的实现这里不再讨论，仅仅聊聊它的使用场景。例如查询一个名称为安迪的用户的所有信息，在我们需要查询一个确定的值的记录时，使用Hash索引查询的复杂度可以近似为O(1)。
  看上去我们好像找到了一种完美的解决办法，现在我们插入和查找的效率都是O(1)，实现的代价仅仅是维护必要的Hash结构。也许有人注意到了，我们的查询是有条件的，必须是确定值的查询。在实际的查询场景中，不仅有等值查询还有区间查询，比如我想查看按名字字母排序Andi和TOM之间用户，Hash索引这时候就挨个去查找比较记录。

SSTables与LSM-Tree

  基于LSM-Tree存储引擎的基本流程如下

• 当写入时，将其添加到内存中的平衡树数据结构中（例如红黑树）。这个内存中的树有时被称为内存表。
• 当内存表大于某个阈值（通常为几兆字节）时，将其作为SSTable文件写入磁盘。由于树已经维护了按键值对排序的key-value对，写磁盘可以比较高效。新的SSTable文件称为数据库的最新部分。当SSTable写磁盘的同时，可以继续添加另一个新的内存实例。
• 为了处理读请求，首先尝试在内存表中查找键，然后是最新的磁盘段文件，接下来是次新的磁盘段文件，以此类推，直到找到目标。
• 后台进程周期性地执行段合并与压缩过程，以合并多个段文件，并丢弃哪些已被覆盖或删除的值。

B-Tree

  B树索引是按键排序的kv对，将数据库分解成固定大小的块或页（4kb），页是读写的最小单元，几乎所有关系型数据库的索引都是B树索引。

	B-Tree	LSM-Tree
读写特性	读取更快	写入更快读取较慢
缺点	至少写入两次数据：预写日志，写入树的页本身 简单写入带来整个页的开销	不同段中具有相同键多个副本 压缩过程会影响正在进行的读写操作 查询响应时间有时很高 压缩会占用磁盘带宽，进而影响到写入速率
优点	每个键恰好唯一对应索引中的某个位置 提供事务语义 事务隔离通过键范围加锁实现 查询响应时间更具有确定性	更低的写放大 更好的压缩，减少磁盘碎片

2、事务处理与分析处理

四 数据编码与演化

编码格式	特点	问题	应用场景
JSON、XML与二进制变体	文本格式，可读性强 web浏览器内置支持	XML无法区分数字和由数字组成的字符串 JSON无法区分整型和浮点型，不能指定精度 JSON和XML支持Unicode，不支持二进制字符串
Thrift和Protocol Buffers	基于相同原理的二进制编码库 通过模式来编码任意数据 均有代码生成工具，且支持多种语言	手动维护标签号会导致兼容问题	rpc通信和数据序列化
AVRO	同样是通过模式来指定编码的数据结构 IDL和基于JSON描述模式的方式等价 编码最紧凑 不包含任何标签号		Hadoop用例