1.1. 数据聚合在数据湖中，数据湖已经成为聚合PB级数据的中央数据存储库，这些数据包括结构化数据、半结构化数据和非结构化数据

1.2. 痛点

1.2.1. 原始的数据生命周期任务没有自动化的API，需要工程专家来实现可重复性和回滚、提供数据服务层等

1.2.2. 需要应用程序通过其他变通方法来适应数据湖中并发读写操作缺乏一致性的问题

1.2.2.1. 增量更新效率很低

1.2.3. 无法对流式数据和批处理数据进行统一管理

1.3. 替代方案需要为批处理和流处理提供单独的处理代码路径（称为Lambda架构），或者将所有数据转换为事件（称为Kappa架构），这对于大规模管理来说并非易事

1.3.1. 由于缺乏自助服务，数据工程团队会成为数据用户在执行数据湖管理操作时的瓶颈

1.4. 理想情况下，自助式数据湖管理服务具备自动化执行原始的数据生命周期管理的能力，并提供API和策略供数据用户调用

1.4.1. 鉴于数据湖管理任务是每个数据管道的基本任务，因此自动化这些任务可以降低洞察耗时

1.5. 传统上，数据被聚集在数据仓库中，用批处理的方式进行分析

1.5.1. 数据仓库支持数据生命周期管理的需求

1.6. 在快速转换到使用数据湖时，为了支持相同的数据生命周期管理需求，需要组合使用数据存储、处理引擎以及流式和批处理

1.6.1. 数据湖管理服务的目标就是将这些任务自动化

2.1. 在整个过程中，执行数据管理任务消除了数据工程师和数据用户之间的瓶颈

2.1.1. 借助数据湖管理服务，数据用户可以在授权下不受制约地执行这些任务

2.2. 基本生命周期管理

2.2.1. 当数据接入数据湖时，会在对象存储中创建一个bucket来持久化与数据关联的文件

2.2.2. bucket被添加到元数据目录中，可以被不同的处理引擎访问

2.2.3. 大数据格式的设计初衷是为了不可变性

2.2.3.1. 随着数据权限合规要求的出现，客户可以要求删除他们的数据，更新数据湖中的数据已经成为一种必然

2.2.3.2. 由于大数据格式的不可变性，删除一条记录意味着需要读取所有剩余的记录，并将它们写入一个新分区

2.2.3.2.1. 考虑到大数据的规模，这可能会造成巨大的开销

2.2.3.2.2. 典型的解决方法是创建细粒度的分区，以加速数据的重写速度

2.3. 管理数据更新

2.3.1. 数据湖没有提供与数据库ACID相同的完整性保证

2.3.2. 更新一致性的另一个方面是，鉴于最终一致性模型，写操作可能没有传播到所有副本，写后读操作有时会返回不一致的数据

2.4. 管理批处理和流式数据流

2.4.1. 传统上，洞察是回顾性的，以批处理的方式运行

2.4.2. 随着洞察变得实时和可预测，它们既需要分析正在进行的更新流，也需要分析历史数据表

3.1. 包括基本生命周期管理、数据更新的正确性，以及统一管理批处理数据和流式数据的时间

3.2. 需求

3.2.1. 命名空间管理需求

3.2.1.1. 在数据湖中，可以对数据进行逻辑分区或物理分区

3.2.1.2. 命名空间可以根据当前的工作流、数据管道流程和数据集属性组织成许多不同的区域

3.2.1.3. 大多数企业以某种形式使用这种命名空间来保证数据湖的安全性、有序性和灵活性

3.2.1.4. 青铜区

3.2.1.4.1. 是为从事务性数据存储中接入的原始数据服务的

3.2.1.4.2. 是原始数据的转储地，也是长期保留地

3.2.1.4.3. 敏感数据经过加密和标记

3.2.1.4.4. 在此区间进行最低限度的处理，以避免破坏原始数据

3.2.1.5. 白银区

3.2.1.5.1. 包含中间数据的暂存区，其中包含经过滤、清理和增强的数据

3.2.1.5.2. 在对青铜区的数据进行数据质量验证和其他处理后，就成为该区的“真相来源”，供下游分析

3.2.1.6. 黄金区

3.2.1.6.1. 包含可供使用的干净数据以及业务级聚合数据和指标

3.2.1.6.2. 这个区代表了传统的数据仓库，处理过的输出的和标准化的数据层都存储在该区域中

3.2.1.7. 沙盒区

3.2.1.7.1. 除了预先创建的命名空间之外，数据用户可能希望创建沙盒命名空间进行探索

3.2.1.7.2. 沙盒区的治理力度最小，通常在30天后删除

3.2.2. 数据湖中支持的数据格式

3.2.2.1. 数据格式需要平衡对格式健壮性的关注（即格式对数据损坏场景的测试情况如何）和与流行的SQL引擎和分析平台的互操作性

3.2.2.2. 健壮性的另一个重要方面是格式的简单性

3.2.2.2.1. 格式越复杂，序列化和反序列化驱动程序中出现错误的可能性就越高

3.2.2.3. 空间效率

3.2.2.3.1. 数据的紧凑表示通常是一个优化标准

3.2.2.3.2. 将数据表示为二进制文件的能力

3.2.2.3.3. 压缩数据的能力

3.2.2.4. 访问优化

3.2.2.4.1. 可以最大限度地减少响应应用程序查询而访问的数据量（以字节为单位）

3.2.2.4.2. 没有什么通用的解决方案，该标准在很大程度上取决于查询的类型

3.2.2.4.3. 访问优化的另一个方面是拆分文件进行并行执行的能力

3.2.2.5. 文本文件

3.2.2.5.1. 最古老的格式之一，虽然它是人类可读的和可互操作的，但在空间效率和访问优化方面效率较低

3.2.2.6. CSV/TSV

3.2.2.6.1. 格式有局限性，二进制表示和访问效率低

3.2.2.6.2. 使用这些格式表达复杂的数据结构也很困难

3.2.2.7. JSON

3.2.2.7.1. 对于应用程序开发人员来说，这是最有表现力和最通用的格式之一

3.2.2.7.2. 在空间效率和访问优化方面没有优势

3.2.2.8. SequenceFile

3.2.2.8.1. 是Hadoop中最古老的文件格式之一

3.2.2.8.2. 数据用键-值对表示，在Java是通过写接口访问Hadoop的唯一方式时，它很受欢迎

3.2.2.8.3. 最大的问题是互操作性差，且没有一个通用的定义

3.2.2.9. Avro

3.2.2.9.1. 类似于SequenceFile，不同之处是它的模式存储在文件头中

3.2.2.9.2. 该格式具有表现力和互操作性，但是二进制表示有开销，并不是最优化的

3.2.2.9.3. 非常适合通用的工作场景

3.2.2.10. ORCFile

3.2.2.10.1. 是一种面向列的格式，在高端商业数据库中使用

3.2.2.10.2. 被认为是RCFile格式的继承者

3.2.2.10.2.1. RCFile格式在将数据作为字符串存储时效率很低

3.2.2.10.3. ORCFile支持Hortonworks，主要包括谓词下推（Push Predicate Down，PPD）和压缩优化

3.2.2.11. Parquet

3.2.2.11.1. 与ORCFile类似，并得到了Cloudera的支持

3.2.2.11.2. 实现了谷歌Dremel论文中的优化

3.2.2.12. 虽然压缩技术在很大程度上与编码无关，但重要的是要区分主要依赖于单个值的列式压缩技术（如标记化、前缀压缩等），以及依赖于值序列的压缩技术（如运行长度编码（RLE）和增量压缩）

3.2.3. 数据服务层的类型

3.2.3.1. 数据湖中的数据可以是结构化的、半结构化的和非结构化的

3.2.3.2. 半结构化数据有不同的数据模型，如键-值、图、文档等

3.2.3.2.1. 根据数据模型的不同，应该使用合适的数据存储来实现最佳性能和扩展

3.2.3.3. 键-值数据模型

3.2.3.3.1. 最简单的数据模型

3.2.3.3.2. 应用程序将任意数据存储为一组值或blob

3.2.3.3.3. 存储的值是不透明的—任何模式的解释都必须由应用程序进行

3.2.3.3.4. 键-值存储只是按键检索或存储值

3.2.3.3.5. 主流的实现主要有Riak、Redis、Memcache、Hazelcast、Aerospike和AWS DynamoDB

3.2.3.4. 宽-列数据模型

3.2.3.4.1. 类似于关系型数据库，宽-列数据库将数据组织成行和列

3.2.3.4.2. 逻辑上相关的列被分成一组，称为列族

3.2.3.4.3. 主流的实现主要包括Cassandra、HBase、Hypertable、Accumulo和Google Bigtable

3.2.3.5. 文档数据模型

3.2.3.5.1. 文档中的字段可以通过使用这些字段中的值来查询和过滤数据

3.2.3.5.2. 单个文档可能包含的信息分布在RDBMS中的多个关系表中

3.2.3.5.3. MongoDB和其他实现支持原地更新，使应用程序能够修改文档中特定字段的值，而无须重写整个文档

3.2.3.5.4. 对单个文档中多个字段的读和写操作是原子的

3.2.3.5.5. 主流的实现主要包括MongoDB、AWS DynamoDB（有限功能）、Couchbase、CouchDB和Azure Cosmos DB

3.2.3.6. 图数据模型

3.2.3.6.1. 图数据库存储两种类型的信息：节点和边

3.2.3.6.2. 节点是实体，边指定节点之间的关系，且有方向

3.2.3.6.3. 节点和边都可以包含有关该节点或边的信息的属性，类似于表中的列

3.2.3.6.4. 主流的实现包括Neo4j、OrientDB、Azure Cosmos DB、Giraph和Amazon Neptune

4.1. 数据生命周期基本模式

4.1.1. 简化基本操作以及增量数据更新

4.1.2. 目标是让数据用户能够通过策略和API执行基本操作

4.1.3. 包括创建命名空间、在数据服务层中存储数据、创建分区、创建审计规则、处理模式演变和数据版本控制等的策略

4.1.4. 模式演变

4.1.4.1. 目标是自动管理模式变更，使下游的分析不受变更的影响

4.1.4.2. 希望针对不断演变的模式重用现有的查询，并避免在查询过程中出现模式不匹配错误

4.1.4.3. 模式演变是关于数据格式、模式变更类型和底层查询引擎的函数

4.1.4.4. Parquet和ORC是列式数据存储格式，可以通过索引或名称读取

4.1.5. 数据版本控制

4.1.5.1. 目标是实现时间旅行功能—用户可以在特定的时间点查询数据

4.1.5.2. 对于模型训练重现、回滚和审计等场景是必需的

4.1.6. 增量更新

4.1.6.1. 目标是优化数据湖中的增量更新

4.1.6.2. 该模式的一个开源实现是Hudi（Hadoop upsert delete and incremental）

4.1.6.3. 在每次压缩迭代中，因为重写Parquet文件的成本没有分摊到文件的每次更新上，所以具有最大日志文件的文件优先被压缩，而较小的日志文件最后被压缩

4.2. 事务模式

4.2.1. 在数据湖更新中支持ACID事务

4.2.2. 专注于在数据湖上实现ACID（原子性、一致性、隔离性、持久性）事务

4.2.3. 该模式有几个实现，即Delta Lake、Iceberg和Apache ORC（在Hive 3.x中）。

4.3. 高级数据管理模式

4.3.1. 统一流式和批处理数据流

4.3.2. 将流式事件数据组合到一个现有表中

4.3.3. 传统上，批处理分析和流式分析是分开处理的，因为在数据湖中缺失基本功能模块