读数据架构知识体系指南15数据湖仓

1. 数据湖仓

1.1. 数据湖仓是数据湖和数据仓库概念的调和物

• 1.1.1. 仅使用数据湖保存数据，而不是使用一个独立的关系数据仓库

• 1.1.2. 数据湖需要更多功能来取代RDW的功能

• 1.1.2.1. Databricks的Delta Lake发挥作用的地方

• 1.1.3. 几年前，从架构中省略RDW会被认为是重大失误，但目前的趋势表明，越来越多的使用案例中，数据湖仓是最佳架构

1.2. Delta Lake

• 1.2.1. 是在现有数据湖基础上运行的事务存储软件层，增加了类似RDW的特征，以便改善数据湖的可靠性、安全性以及性能

• 1.2.2. 自身不负责存储数据

• 1.2.3. 很容易将数据湖转换为Delta Lake：只需在保存数据到数据湖时指定保存Delta Lake的格式

• 1.2.4. 在使用Delta Lake格式存储文件时，文件会以自己专门的方式存储，即由文件夹中的Parquet文件和跟踪数据更改的事务日志组成

• 1.2.5. 实际数据在数据湖中的存储方式与常用格式类似，新增的事务日志则将其转化为Delta Lake，增强了其功能

1.3. 架构师的主要职责就是识别可用于各种架构的产品，并确定和分析它们之间的权衡关系，从而为具体用例选择最佳的架构和产品

• 1.3.1. 只是要注意权衡问题，如果没有急迫的大问题，就继续使用数据湖仓，直到其不能满足要求为止

• 1.3.2. 对某一数据集，当折中方案改动太大时，可将该数据复制到RWD（无须复制所有数据）​

1.4. 像Delta Lake一样，类似Apache Icebergand、Apache Hudi的技术以及存储计算持续改进，维护RDW的理由将越来越少

• 1.4.1. 大多数新的数据架构都将是数据湖仓

2. 特性

2.1. 企业使用Delta Lake的最大原因可能是它们支持数据操作语言(DML)命令，如INSERT、DELETE、UPDATE和MERGE

2.2. 简化了复杂的数据管理任务，使得Delta Lake中的数据处理更加灵活可靠

2.3. 数据湖自身不提供对这些操作的支持，因为数据湖是基于批量处理和存储大量数据进行优化的，而不是为了实时更新

2.4. 更新数据湖通常需要读取整个文件，进行必要更新，而后将整个更新文件写回数据湖，不过整个过程对于大文件的处理时间会很长

2.5. 当Delta Lake首次处理一个表（本质上是一个以行列组织的数据集合文件）时，它会将该表分解成几个较少的数字文件，以便于管理

2.6. Delta Lake使用事务日志来跟踪变更，还使用了优化的存储（列存储格式）​、内存中处理和优化的批量处理，从而使DML命令的运行速度大大提高

• 2.6.1. 无须重写整个Delta表，从而提高更新效率

2.7. 事务日志会记录数据更改的历史，确保数据始终处于一致状态，即使出现故障或系统崩溃的情况

2.8. 数据库领域常见的首字母缩略语ACID，代表了原子性、一致性、隔离性和持久性

• 2.8.1. 确保了数据库事务的可靠性和完整性

• 2.8.2. 保证了事务以单一、可靠的操作进行，其数据更改要么完全提交，要么完全回滚

• 2.8.3. Delta Lake的ACID支持局限于单个Delta表。在Delta湖中的多个Delta表上执行DML不能保证ACID完整性

• 2.8.4. 对于关系数据库，ACID完整性适用于跨多个表的DML事务

2.9. 提供“时空旅行”功能，允许查询存储在Delta表中的数据在特定时间点的情况

• 2.9.1. 数据更改历史会连同元数据（如每次更改的时间和用户）一起保存在Delta事务日志中

• 2.9.2. 用户可以查看和访问以前版本的数据，必要时甚至可以将其恢复到以前的版本

• 2.9.3. 这对于审计、调试或在发生意外数据更改或其他问题（如回滚）时恢复数据非常有用

2.10. 小文件问题是数据湖的常见问题，即大量的小文件会降低读写操作的速度，并增加存储成本

• 2.10.1. Delta Lake使用优化压缩算法将小文件融合进大文件中，从而有效解决了该问题

• 2.10.2. 压缩过程自动在后台执行，可配置成定时模式或者手动触发模式

2.11. 利用Delta Lake，用户可以对Delta表中的同一数据执行批量处理和实时流式处理

• 2.11.1. 无须为批量处理和流式处理维护单独的数据管道和系统

• 2.11.2. 统一的解决方案更易于管理和维护管道，并简化了数据处理架构

• 2.11.3. 支持Lambda架构

2.12. 模式约束(schema enforcement)是Delta Lake的特性，允许指定Delta表的数据预期模式以及约束规则，例如空约束、数据类型约束和唯一约束等规则

• 2.12.1. 如果没有模式约束，就可能将无效模式的文件添加到文件夹中，这会导致ELT作业出错

• 2.12.2. 如果传入数据与模式不匹配，Delta Lake将拒绝写操作并抛出错误

3. 性能提升

3.1. 数据略过

• 3.1.1. data skipping

• 3.1.2. 当从Delta表中读取数据时，Delta Lake可忽略不相关数据，从而极大地提高查询性能

3.2. 缓存

• 3.2.1. 支持Spark中的数据缓存，可显著提高重复查询的性能

3.3. 快速索引

• 3.3.1. 使用优化的索引结构来快速定位数据，从而减少执行查询所需的时间

3.4. 查询优化

• 3.4.1. 与Spark SQL集成，可利用Spark的查询优化功能，实现更快、更高效的查询

3.5. 谓词下推

• 3.5.1. predicate pushdown

• 3.5.2. 支持谓词下推，即过滤条件可下推至存储层，减少要处理的数据量

3.6. 列裁剪

• 3.6.1. column pruning)

• 3.6.2. 通过列裁剪，只读取特定查询所需的列，从而减少需要处理的数据量

3.7. 矢量化执行

• 3.7.1. 在矢量化执行中，多个数据点由一条CPU指令处理，从而提高性能

3.8. 并行处理

• 3.8.1. 支持并行处理，这意味着可以并行执行多个任务，从而提高性能

3.9. Z-order

• 3.9.1. 也称为Morton orde

• 3.9.2. 是Delta Lake架构中使用的一种数据编码技术，用于组织数据以实现快速、高效的访问和查询

4. 数据湖仓架构

4.1. 5个阶段：采集、存储、转换、建模和可视化

4.2. 在数据湖架构中，数据只有一个存储库（使用Delta Lake的数据湖）​，而不是两个存储库（Delta Lake和数据湖）​

• 4.2.1. RDW由可选的关系服务层取代

4.3. 常见的6个问题

• 4.3.1. 可靠性

• 4.3.1.1. 保持数据湖和RDW的一致性是一个问题，尤其是大量数据需要经常从数据湖复制到RDW中

• 4.3.1.2. 如果复制数据的作业失败、没有准确复制数据或将数据放在数据湖中的错误位置，都会导致可靠性问题

• 4.3.2. 数据过时

• 4.3.2.1. RDW中的数据将比数据湖中的相应数据更陈旧，数据过时程度取决于数据从数据湖复制到RDW的频率，而且，为了避免影响查询和报告性能，往往不希望过于频繁地运行这些作业

• 4.3.3. 高级分析的有限支持

• 4.3.3.1. 很少有AI/ML系统和工具能在RDW上良好运行，因为数据科学家通常更喜欢在数据湖中处理文件

• 4.3.3.2. 数据湖仓可以满足他们的需求

• 4.3.4. 总体拥有成本

• 4.3.4.1. 尽管存储成本相对较低，但将数据复制到RDW所需的计算成本也会增加

• 4.3.4.2. 两份数据副本的情况增加了额外的存储成本

4.3.4.2.1. 在数据湖仓中，数据只有一份

• 4.3.4.3. RDW中用于查询和报告的计算成本通常比数据湖中的计算成本高得多

• 4.3.4.4. 管理数据湖和管理RDW是不同的技能组合，同时聘用这两种人员也意味着会产生额外的成本

• 4.3.5. 数据治理

• 4.3.5.1. 在两种不同环境下拥有数据的两份副本，以及可能的两种不同安全策略，反而增加了无权限人员看到数据的风险

4.3.5.1.1. 干扰了两个系统遵循相同的数据质量和数据转换规则

• 4.3.5.2. 数据湖仓则只有一份数据副本，故无此问题

• 4.3.6. 复杂性

• 4.3.6.1. 同时管理数据湖和RDW，需要专业技能和资源

• 4.3.6.2. 数据湖仓无RDW，因此用户需要掌握的专业技能少一些

5. 无关系数据湖仓

5.1. 随着Delta Lake继续将RDW类的特性加入数据湖中，将看到越来越多的数据湖仓是最好架构的案例

5.2. 数据湖仓特别适合小数据集

5.3. 多数云供应商有无服务计算，用来存储Delta Lake，这样可以节约查询成本

5.4. 无须将数据复制到关系存储中，因此也能节约成本，因为关系存储很昂贵，并要使用更昂贵的关系计算

• 5.4.1. 关系存储很昂贵，并要使用更昂贵的关系计算

5.5. 使用专门计算而不是无计算，即使未使用也需要付费

5.6. 关系数据库查询比Delta Lake的查询更快，尤其是当RDW使用MPP技术时

• 5.6.1. RDW支持高并发，因为它们提供高级锁、隔离级别和事务管理等高级管理功能

5.7. Delta Lake也缺少一些常见的重要RDW功能，如行级安全、列级安全、静态数据加密、列级加密、透明数据加密(TDE)和动态数据遮蔽（自动替换或遮蔽部分数据，以便未经授权的用户看到真实的敏感信息）

• 5.7.1. 不提供SQL视图、引用完整性、负荷管理或高级审计和合规性功能（如审计跟踪、数据保留策略和合规性认证）​

5.8. RDW拥有强制元数据层，即必须创建数据库、模式以及带有描述数据类型的字段的表，然后加载数据（写入模式）​

• 5.8.1. 元数据始终是基于真实数据的

• 5.8.2. 最大的好处是元数据和数据始终锁定在一起，因此很容易使用元数据找到数据，永远不会丢失元数据，并且其一直准确地描述数据

5.9. Delta Lake是基于文件夹和文件的

• 5.9.1. 惯用RDW的最终用户对使用Delta Lake感到吃力的原因

• 5.9.2. 元数据不需要与数据共存

• 5.9.2.1. 它存在于一个或多个单独文件中、包含数据的文件中、同一文件夹中、单独的文件夹中，或者根本找不到

• 5.9.3. 元数据可能非常不准确，这是因为元数据与数据之间并不像在RDW中那样是一对一的关系

• 5.9.4. 在Delta Lake外更改时，元数据可能会与数据不同步

5.10. 要使用Delta Lake的某些特性，可能不得不使用Spark

• 5.10.1. 如果要使用Spark SQL，则意味着要重新培训已经熟悉RDW工具的终端用户

6. 关系服务层

6.1. Delta Lake是读时模式

• 6.1.1. 数据被读取时，模式会被应用，而不是在读取数据之前采用

6.2. Delta Lake属于文件夹系统，因此不提供数据的上下文

• 6.2.1. 每个文件都是独立的，因此需要在Delta Lake的数据之上创建一个“服务层”​，将元数据与数据直接绑定

6.3. 有了数据之上的这一层，如果需要将多个文件连接在一起，就可以定义它们之间的关系

• 6.3.1. SQL视图、报表工具中的数据集、Apache Hive表或临时SQL查询

• 6.3.2. 如果操作得当，最终用户将分辨不出数据来自Delta Lake，反而以为它们来自RDW

6.4. 创建了SQL视图，而后使用报告工具调用这些视图，所以最终用户很容易生成报告和控制台

6.5. 元数据与数据不绑定是Delta Lake固有的问题

• 6.5.1. RDW通过建立人人皆可用的通用数据模型来避免这一问题