1. 对象存储

1.1. 对象存储包含各种形状和大小的对象

• 1.1.1. Amazon S3、Azure Blob Storage和Google Cloud Storage(GCS)是广泛使用的对象存储

• 1.1.2. 许多云数据仓库（以及越来越多的数据库）利用对象存储作为其存储层，而云数据湖通常位于对象存储上

• 1.1.3. 对象存储是一个用于不可改变的数据对象的键值存储

  • 1.1.3.1. 对象不支持随机写入或追加操作

  • 1.1.3.2. 它们作为字节流被写入一次

    1.1.3.2.1. 在这个初始写入之后，对象就变得不可改变了

    1.1.3.2.2. 要改变一个对象中的数据或向其追加数据，我们必须重写整个对象

• 1.1.4. 对象存储通常支持通过范围请求进行随机读取，但这些查找的性能可能比从存储在SSD上的数据中随机读取要差得多

• 1.1.5. 对象存储不需要支持锁或更改同步，允许跨大规模磁盘集群存储数据

  • 1.1.5.1. 对象存储支持在许多磁盘上进行性能极高的并行流写入和读取，这种并行性对工程师来说是隐藏的，他们可以简单地处理流，而不是与单个磁盘进行通信

1.2. 云对象存储

• 1.2.1. 云对象存储最吸引人的特点之一是它可以直接管理和使用

  • 1.2.1.1. 对象存储可以说是第一批“无服务器”服务之一，工程师不需要考虑底层服务器集群或磁盘的特性

• 1.2.2. 典型的云对象存储将数据保存在几个可用区，极大地降低了存储完全离线或以不可恢复的方式丢失的概率

  • 1.2.2.1. 耐用性和可用性是内置于成本中的

  • 1.2.2.2. 云存储供应商以折扣价格提供其他存储类别，以换取降低的耐用性或可用性

• 1.2.3. 云对象存储是分离计算和存储的一个关键因素，允许工程师用短暂的集群处理数据，并按需扩大和减少这些集群

  • 1.2.3.1. 大多数组织将把数据处理转移到云中，使用对象存储作为基本的存储和服务层，同时在短暂的集群上处理数据

1.3. 在对象存储中，可用的存储空间也是高度可扩展的，这是大数据系统的理想特征

• 1.3.1. 存储空间受到存储提供商所拥有的磁盘数量的限制，但这些提供商处理的数据都是艾字节的

• 1.3.2. 在云环境中，可用的存储空间几乎是无限的

• 1.3.3. 公有云客户对存储空间的主要限制是预算

• 1.3.4. 工程师可以迅速为项目存储大量的数据，而不需要提前几个月为必要的服务器和磁盘做计划

1.4. 数据工程应用程序的对象存储

• 1.4.1. 从数据工程的角度来看，对象存储为大批量读取和批量写入提供了出色的性能

• 1.4.2. 对象存储不适合每秒有许多小更新的事务工作负载，这些用例最好由事务数据库或块存储系统来完成

• 1.4.3. 对象存储对于低更新率的操作来说效果很好，每个操作都会更新大量的数据

• 1.4.4. 对象存储现在是数据湖存储的黄金标准

  • 1.4.4.1. 在数据湖的早期，一次写入，多次读取(Write Once，Read Many，WORM)是操作标准，但这不是HDFS和对象存储的局限，而与管理数据版本和文件的复杂性有很大关系

• 1.4.5. 对象存储是这些结构化数据应用之外的任何格式的非结构化数据的理想存储库

• 1.4.6. 对象存储可以存放任何二进制数据，不受类型或结构的限制，并且经常在原始文本、图像、视频和音频的ML管道中发挥作用

1.5. 对象寻找

• 1.5.1. 与文件存储不同，对象存储不利用目录树来寻找对象

• 1.5.2. 对象存储使用一个顶级的逻辑容器​，并通过键来引用对象

1.6. 对象的一致性和版本管理

• 1.6.1. 对象存储不支持原地更新或追加

• 1.6.2. 最终一致性的最终部分意味着，在足够长的时间过去后，存储集群达到一个状态，即只返回对象的最新版本

• 1.6.3. 对象版本与对象一致性密切相关

• 1.6.4. 对象的历史版本通常具有与当前版本相同的相关存储成本

• 1.6.5. 生命周期策略允许在满足某些条件时自动删除旧的对象版本

1.7. 存储类别和层级

• 1.7.1. 云供应商现在提供不同的存储等级，以降低访问量或降低耐用性为交换条件，对数据存储定价进行折扣

• 1.7.2. 许多存储层仍然使数据高度可用，但以高的检索成本换取少的存储成本

• 1.7.3. 在减少访问的层级中，更进一步的是S3 Glacier的归档层级

  • 1.7.3.1. 数据恢复需要12小时

  • 1.7.3.2. 这种存储类别是为那些将被存储7～10年，每年只被访问1～2次的数据而设计的

1.8. 对象存储支持的文件系统

• 1.8.1. 高速的事务写入将使对象存储的更新能力不堪重负

• 1.8.2. 将对象存储作为一个本地文件系统挂载，对于不经常更新的文件来说是很好的

2. 缓存和基于内存的存储系统

2.1. RAM提供了出色的低延迟和高传输速度

• 2.1.1. 基于RAM的存储系统一般专注于缓存应用程序，呈现数据的快速访问和高带宽

• 2.1.2. 出于保留的目的，数据一般应被写入更持久的介质中

2.2. 分布式内存缓存系统(Memcached)是一个键值存储，用于缓存数据库查询结果、API调用响应等

• 2.2.1. Memcached使用简单的数据结构，支持字符串或整数类型

• 2.2.2. Memcached可以以非常低的延迟提供结果，同时也减轻了后端系统的负担

2.3. Redis还建立了多种持久性机制，包括快照和日记

3. Hadoop分布式文件系统

3.1. Hadoop分布式文件系统基于谷歌文件系统(Google File System，GFS)，最初是为了用MapReduce编程模型处理数据而设计的

3.2. Hadoop将大文件分成块，即大小小于几百兆字节的数据块

3.3. Hadoop不是简单的一个存储系统

• 3.3.1. Hadoop将计算资源与存储节点结合起来，以实现就地数据处理

3.4. HDFS仍然在各种应用程序和组织中广泛使用

• 3.4.1. 纯粹的MapReduce编程模型已经被淘汰了

3.5. HDFS是目前许多大数据引擎的关键成分

4. 流式存储

4.1. 流数据与非流数据有不同的存储要求

• 4.1.1. 在消息队列中，存储的数据是时间性的，预计在一定时间后会消失

• 4.1.2. Kafka通过将旧的、不经常访问的消息推送到对象存储中来支持无限期的数据保留

• 4.1.3. Kafka的竞争对手（包括Amazon Kinesis、Apache Pulsar和Google Cloud Pub/Sub）也支持长期数据保留

4.2. 重放允许流媒体系统返回一系列的历史存储数据

• 4.2.1. 重放是流式存储系统的标准数据检索机制

• 4.2.2. 重放可以用来在一个时间范围内运行批处理查询，也可以用来重新处理流管道中的数据

4.3. 事务数据库是最早的实时查询引擎，数据一经写入就会被查询

5. 索引、分区和聚类

5.1. 索引为特定字段提供了一个表格图，并允许极快地查找个别记录

• 5.1.1. 如果没有索引，则数据库将需要扫描整个表来找到满足WHERE条件的记录

• 5.1.2. 索引也可以应用于其他列，以满足特定应用程序的需要

• 5.1.3. 使用索引，一个RDBMS可以每秒查询和更新数千条记录

5.2. 列式序列化

• 5.2.1. 列式序列化允许数据库只扫描特定查询所需的列，有时会极大地减少从磁盘上读取的数据量

• 5.2.2. 按列排列的数据将相似的值放在一起，产生高压缩率，而压缩开销最小，使得数据可以更快地从磁盘和网络上被扫描

• 5.2.3. 列式数据库在事务用例（即当我们试图异步查询大量的单独行时）中的表现很差

• 5.2.4. 当必须扫描大量的数据（例如，用于复杂的数据转换、聚合、统计计算或对大型数据集的复杂条件进行评估）时，它们的表现非常好

• 5.2.5. 列式数据库允许快速的扫描速度，但尽可能减少扫描的数据量仍然是有帮助的

5.3. Snowflake微分区

• 5.3.1. Snowflake微分区，因为它是列存储方法最近发展和演变的一个好例子

• 5.3.2. 微分区是指未压缩的大小在50兆～500兆字节之间的行集