读数据工程之道：设计和构建健壮的数据系统20数据工程存储抽象

1. 数据工程存储抽象

1.1. 数据工程存储抽象是数据组织和查询模式，位于数据工程生命周期的核心，建立在之前讨论的数据存储系统之上

1.2. 关键的考虑

  • 1.2.1. 目的和用例

  • 1.2.1.1. 必须首先确定存储数据的目的

  • 1.2.2. 更新模式

  • 1.2.2.1. 是否针对批量更新、流式插入或上载进行了优化

  • 1.2.3. 成本

  • 1.2.4. 分离存储和计算

  • 1.2.4.1. 现在的趋势是将存储和计算分离，但大多数系统是混合分离和主机托管

2. 数据仓库

2.1. 数据仓库是一个标准的OLAP数据架构

2.2. 数据仓库一词指的是技术平台（如Google BigQuery和Teradata）​、数据集中化的架构以及公司内部的组织模式

2.3. 云数据仓库

  • 2.3.1. 云数据仓库经常被用来将数据组织到数据湖中

  • 2.3.2. 这是一个存储大量未处理的原始数据的区域

  • 2.3.3. 最初是由James Dixon构想的

  • 2.3.4. 可以处理大量的原始文本和复杂的JSON文档

  • 2.3.5. 局限性在于，与真正的数据湖不同，云数据仓库不能处理真正的非结构化数据，如图像、视频或音频

  • 2.3.6. 可以与对象存储结合起来，提供一个完整的数据湖解决方案

3. 数据湖

3.1. 数据湖最初被认为是一个大规模的存储，数据以原始的、未处理的形式被保留

3.2. 最初，数据湖主要建立在Hadoop系统上，廉价的存储允许保留大量的数据，而没有专有MPP系统的成本开销

3.3. 主要的进展

  • 3.3.1. 出现了计算和存储分离的重大迁移

  • 3.3.2. MPP系统提供的许多功能（模式管理；更新、合并和删除功能）​，以及最初在匆忙建立数据湖概念时被放弃的功能，事实上是非常有用的

  • 3.3.2.1. 促进了数据湖仓一体概念的产生

4. 数据湖仓一体

4.1. 数据湖仓一体是一个结合了数据仓库和数据湖的架构

4.2. 湖仓一体在对象存储中存储数据，就像一个湖一样

4.3. 湖仓一体系统是一个元数据和文件管理层，与数据管理和转换工具一起部署

4.4. 数据湖仓一体的关键优势是互操作性

4.5. 数据湖仓一体中的许多数据可能没有强加表结构

5. 存储的重要思想和趋势

5.1. 数据目录

  • 5.1.1. 数据目录是一个集中的元数据存储，用于整个组织的所有数据

  • 5.1.2. 数据目录不是一个顶级的数据存储抽象，但它与各种系统和抽象相集成

  • 5.1.3. 数据目录通常跨运营和分析数据源工作，集成数据脉络和数据关系的呈现，并允许用户编辑数据描述

  • 5.1.4. 数据目录通常被用来提供一个中央场所，人们可以在那里查看他们的数据、查询和存储数据

  • 5.1.5. 目录应用集成

  • 5.1.5.1. 理想情况下，数据应用程序被设计成与目录API集成，直接处理其元数据和更新

  • 5.1.6. 自动扫描

  • 5.1.6.1. 在实践中，目录系统通常需要依赖一个自动扫描层，从各种系统中收集元数据，如数据湖、数据仓库和操作数据库

  • 5.1.7. 数据门户和社会层

  • 5.1.7.1. 数据目录通常还通过网络界面提供一个用户访问层，用户可以在那里搜索数据并查看数据关系

  • 5.1.8. 数据目录用例

  • 5.1.8.1. 数据目录有组织和技术两方面的用例

  • 5.1.8.2. 数据目录使元数据容易被系统使用

5.2. 数据共享

  • 5.2.1. 数据共享允许组织和个人与特定实体共享特定的数据和精心定义访问权限

  • 5.2.2. 数据共享允许数据科学家与组织内的合作者共享沙盒中的数据

  • 5.2.3. 云端多租户环境使组织间的协作更加容易

  • 5.2.4. 数据共享是许多云数据平台的一个核心特征

5.3. 模式

  • 5.3.1. 模式不一定是关系型的

  • 5.3.2. 模式可以作为一种罗塞达石，指示我们如何阅读数据

  • 5.3.3. 写时模式

  • 5.3.3.1. 写时模式基本上是传统的数据仓库模式：一个表有一个集成的模式，任何对该表的写入都必须符合

  • 5.3.3.2. 为了支持写时模式，数据湖必须集成一个模式元存储

  • 5.3.3.3. 写时模式的主要优点是，它可以执行数据标准，使数据在未来更容易被消费和利用

  • 5.3.4. 读时模式

  • 5.3.4.1. 在读时模式下，模式是在数据写入时动态创建的，而读者在读取数据时必须确定模式

  • 5.3.4.2. 理想情况下，读时模式是使用实现内置模式信息的文件格式来实现的

  • 5.3.4.3. 读时模式强调的是灵活性，允许几乎任何数据被写入

>  5.3.4.3.1. 代价是在未来消费数据时更加困难

5.4. 计算与存储的分离

  • 5.4.1. 计算和存储的主机托管

  • 5.4.1.1. 长期以来一直是提高数据库性能的标准方法

  • 5.4.2. 计算和存储的分离

  • 5.4.2.1. 短暂性和可扩展性

>  5.4.2.1.1. 购买和托管一台服务器要比从云提供商那里租来的便宜，只要你每天24小时不停地运行它，连续数年

>  5.4.2.1.2. 工作负荷变化很大，如果服务器可以扩大和缩小，那么采用即付即得模式就能实现显著的效率
  • 5.4.2.2. 数据的耐久性和可用性
>  5.4.2.2.1. 云对象存储大大减轻了数据丢失的风险，通常提供极高的正常运行时间（可用性）​

>  5.4.2.2.2. 因错误配置而破坏对象存储中数据的可能性仍然有些可怕，但有简单部署的缓解措施
  • 5.4.2.3. 混合分离和主机托管
>  5.4.2.3.1. 多层缓存

  >   5.4.2.3.1.1. 通过多层缓存，我们利用对象存储进行长期的数据保留和访问，但在查询和数据管道的各个阶段使用本地存储来启动

>  5.4.2.3.2. 混合对象存储

  >   5.4.2.3.2.1. 结合了对象存储的简洁抽象和计算存储的一些优势

>  5.4.2.3.3. Spark通常在HDFS或其他一些短暂的分布式文件系统上运行作业，以支持处理步骤之间的数据的高性能存储

>  5.4.2.3.4. 保持数据的持久性仍然是至关重要的，所以Druid使用对象存储作为其持久性层
  • 5.4.2.4. 零拷贝克隆
>  5.4.2.4.1. 基于对象存储的云系统支持零拷贝克隆

>  5.4.2.4.2. 零拷贝克隆通常意味着一个对象的新的虚拟副本被创建（例如，一个新的表）​，而不一定要物理复制基础数据

>  5.4.2.4.3. 零拷贝克隆是一个引人注目的功能，但工程师必须了解它的优点和局限性

5.5. 数据存储的生命周期和数据保留

  • 5.5.1. 储存数据并不是简单地把它保存到对象存储或磁盘上就可以不再管理它

  • 5.5.2. 三类持久性

  • 5.5.2.1. 热、暖和冷

>  5.5.2.1.1. 热数据

  >   5.5.2.1.1.1. 热数据有即时或频繁的访问要求。热数据的底层存储适合于快速访问和读取，如SSD或内存

  >   5.5.2.1.1.2. 存储热数据往往是最昂贵的存储形式

  >   5.5.2.1.1.3. 热数据的用例包括检索产品推荐和产品页面结果

  >   5.5.2.1.1.4. 储存热数据的成本是这三个存储层中最高的，但检索往往是廉价的

>  5.5.2.1.2. 暖数据

  >   5.5.2.1.2.1. 暖数据的访问是半定期的，例如每月一次

  >   5.5.2.1.2.2. 没有硬性规定表明暖数据的访问频率，但它比热数据少，比冷数据多

>  5.5.2.1.3. 冷数据

  >   5.5.2.1.3.1. 在另一个极端，冷数据是不经常访问的数据

  >   5.5.2.1.3.2. 用于归档冷数据的硬件通常是廉价和耐用的，如HDD、磁带存储和基于云的归档系统

  >   5.5.2.1.3.3. 当几乎没有人打算访问这些数据时，冷数据主要是为了长期存档

  >   5.5.2.1.3.4. 虽然存储冷数据很便宜，但检索冷数据往往很昂贵

  >   5.5.2.1.3.5. 冷存储在归档数据方面很受欢迎

5.5.2.1.3.5.1. 历史上，冷存储涉及物理备份，并经常将这些数据邮寄给第三方，由其在字面上的保险库中存档

  >   5.5.2.1.3.6. 冷存储在云中越来越受欢迎

  • 5.5.2.2. 每个数据集的查询访问模式都不同

  • 5.5.2.3. 通常情况下，较新的数据和比较旧的数据被查询得更频繁

  • 5.5.2.4. 考虑你的数据的存储层时，要考虑每层的成本

>  5.5.2.4.1. 如果你把所有的数据存储在冷存储中以节省成本，你当然会降低你的存储成本，但代价是延长检索时间

>  5.5.2.4.2. 如果你需要访问数据，则要付出高昂的检索费用

  • 5.5.2.5. 存储价格在更快/更高性能的存储中更高，并在更低的存储中逐渐降低

  • 5.5.2.6. 内存是昂贵而有限的

  • 5.5.3. 如果你使用基于云的对象存储，则为你的数据创建自动化的生命周期策略

  • 5.5.3.1. 使用不经常使用的或归档式的存储层

  • 5.5.3.2. 访问和检索的时间和成本可能因云提供商而异

  • 5.5.4. 数据保留

  • 5.5.4.1. 价值

>  5.5.4.1.1. 数据是一种资产，所以你应该知道你所存储的数据的价值
  • 5.5.4.2. 时间
>  5.5.4.2.1. 对下游用户的价值也取决于数据的年龄
  • 5.5.4.3. 合规性
>  5.5.4.3.1. 某些法规可能要求你在一定时间内保留数据
  • 5.5.4.4. 成本
>  5.5.4.4.1. 数据是一种资产，​希望有一个投资回报率

>  5.5.4.4.2. 在投资回报率的成本方面，一个明显的存储费用是与数据相关的

5.6. 单租户与多租户存储的对比

  • 5.6.1. 在单租户架构下，每组租户（如个人用户、用户组、账户或客户）都得到自己的专用资源，如网络、计算和存储

  • 5.6.2. 采用单租户存储意味着每个租户都得到他们的专用存储

  • 5.6.2.1. 每个租户得到一个数据库

  • 5.6.2.2. 使用单租户存储的一个例子是，每个客户的数据必须隔离存储，不能与任何其他客户的数据混合在一起

  • 5.6.2.3. 每个客户得到他们自己的数据库

  • 5.6.2.4. 独立的数据存储意味着独立的模式、桶结构以及与存储有关的一切

>  5.6.2.4.1. 意味着你可以自由地将每个租户的存储环境设计成统一的，或者让他们任意发展

  • 5.6.3. 多租户架构则相反，在各组用户之间共享这些资源

  • 5.6.4. 多租户存储允许在一个单一的数据库中存储多个租户

6. 其他

6.1. 存储是数据工程基础设施的核心

  • 6.1.1. 存储无处不在，并且支撑着数据工程生命周期的许多阶段

6.2. 你将与拥有你的IT基础设施的人互动

  • 6.2.1. 常是DevOps、安全和云架构师

6.3. 数据存储的责任划分将在很大程度上取决于相关组织的成熟度

  • 6.3.1. 如果公司处于数据成熟度的早期，则数据工程师可能会管理存储系统和工作流

6.4. 数据工程师需要确保下游用户使用的存储系统是安全可用的、包含高质量的数据、有充足的存储容量，并在查询和转换运行时执行

6.5. 底层设计

  • 6.5.1. 存储的底层设计很重要，因为存储是数据工程生命周期的所有阶段的关键枢纽

  • 6.5.2. 安全

  • 6.5.2.1. 接受安全是一个关键的促成因素的想法

  • 6.5.2.2. 像往常一样，行使最小特权的原则

>  6.5.2.2.1. 除非需要，否则不要给任何人完整的数据库访问权

>  6.5.2.2.2. 意味着大多数数据工程师在实践中不需要完全的数据库访问

  • 6.5.3. 数据管理

  • 6.5.3.1. 数据目录和元数据管理

>  6.5.3.1.1. 数据通过强大的元数据得到加强
  • 6.5.3.2. 对象存储中的数据版本管理
>  6.5.3.2.1. 主要的云对象存储系统能够实现数据版本管理
  • 6.5.3.3. 隐私
>  6.5.3.3.1. 任何具有隐私影响的数据都有一个生命周期，数据工程师必须管理

>  6.5.3.3.2. 隐私法规对存储系统设计产生了重大影响

>  6.5.3.3.3. 数据工程师必须准备好响应数据删除请求，并根据需要选择性地删除数据

  • 6.5.4. Data Ops

  • 6.5.4.1. DataOps与数据管理并不是正交的，而且存在一个重要的重叠区域

  • 6.5.5. 编排

  • 6.5.5.1. 编排与存储高度相关

  • 6.5.5.2. 存储允许数据在管道中流动，而编排是泵

  • 6.5.5.3. 编排还可以帮助工程师应对数据系统的复杂性

posted @ 2024-10-26 06:09  躺柒  阅读(20)  评论(0)  编辑  收藏  举报