1：数据湖

数据湖的本质是由数据存储架构 + 数据处理工具组成的存储计算框架。不依赖于HDFS，可以支持多种存储介质和任意结构的数据，高效更新机制、文件组织形式、统一的开放的表格上（定位是在计算引擎之下，又在存储之上，将其称之为table format），灵活的元数据管理。用来帮助解决Hive常见的痛点问题，如更新问题、结构变更、ACID、小文件问题、性能问题。数据湖并非数据仓库的替代方案，而是补充和完善。

2：数据湖的物理存储层

存储特性

用于实现物理存储的技术应表现出以下基本特征：

• 持久性：底层存储硬件要确保不会损坏，可以根据数据所需保留时间长期保存数据，并且需要有损坏后的数据恢复措施。
• 可用性：存储服务应该不间断地为数据消费者提供可用服务，查询数据，即使存储服务宕机，也要有相应的备份措施，提供数据。
• 可扩展性：存储服务应该易于扩展，并且能够根据数据增长需求进行扩展，而无需任何手动干预。
• 成本优化：应该提供高性能和相对低性能的不同价格的存储层，冷热数据按需存储在不同的存储层中，以达到成本与性能之间的平衡。
• 安全：存储层最重要的特征之一是提供内置安全性，它应该提供保护存储层内静态数据的功能。

数据湖的存储层主要包括大数据生态的HDFS文件系统、主流的云原生对象存储。数据湖物理存储需要具备同时支持HDFS生态和云原生的生态。大多数云厂商的云存储（S3, OSS等）都提供上述特性，所以在实践Lakehouse架构时首选云对象存储，而不是HDFS。

3：数据湖文件格式

数据湖由四个主要组件组成：存储层、格式化层、计算层和元数据层。数据湖文件格式更面向列，并使用附加功能压缩大文件。这里的主要参与者是Apache Parquet、Apache Avro和Apache Arrow。它是物理存储，实际文件分布在存储层上的不同存储桶中。数据湖文件格式有助于存储数据，在系统和处理框架之间共享和交换数据。这些文件格式具有其他功能，例如拆分能力和模式演变。

4：数据湖表格式-table-format

Table Format非常有吸引力，因为它们是数据湖上的数据库。与表相同，一种数据湖表格式将分布式文件捆绑到一张表中管理。可以将其视为物理数据文件布局之上的表视图抽象层。想象一下一次插入数百个文件，它们之前是什么关系，如何高效率的更新和查询。

Table format这个概念最早由Iceberg提出，目前主流的Table Format有Apache Hudi、Apache Iceberg和Delta Lake。现在行业对它的理解主要有两点：

1. Table format定义了哪些文件可以构成一张表，这样Apache Flink、Apache Spark、Trino、Apache Impala等任何引擎都可以根据Table format去查询、检索数据。
2. Table format规范了数据和文件的分布方式，任何引擎写入数据都要遵照这个标准，通过format定义的标准来支持以前Hive不支持的ACID和模式演进。

它们是上述其中一种开源数据湖文件格式，可优化列存储并高度压缩，数据湖表格式允许直接从数据湖中高效地查询数据，不需要进行转换。数据湖表格式是数据湖文件格式的引擎。文件格式擅长以压缩方式存储大数据并将其返回以进行面向列的分析查询，但是它们缺乏额外的特性，例如ACID事务和对关系数据库中每个人都知道的标准ANSI SQL的支持。借助数据湖表格式及其开源解决方案，我们可以获得这些想要的基本功能，并且还可以获得更多。

总结下来，Table format有四点核心特性：

1. 结构自由：像之前的Hive只能支持简单的加列操作，而在Delta、Iceberg这样的Table format之上用户可以自由地更改表的结构，可以加列、减列、改列，而且对数据的迁移和变更不会有要求。
2. 读写自由：因为它通过快照能够保证数据的ACID，任何实时、离线以及AI的需求都可以自由地往这个表里面写数据或者读数据。
3. 流批同源：因为Table format核心的一个功能是可以很好地支持流场景，我们的批和流都可以往新的Table format去写和读。
4. 引擎平权：这点非常重要，它不能只是绑定某一个引擎，比如说像Delta在1.0时代是Spark生态中的一个组件，在一个月之前Delta2.0的发布再次向我们证明了去适配多个引擎的重要性。

Table format是数据湖之上比Hive更进一步的元数据封装，遵循所读即所写的原则，而在用户的读写之间应当有一个标准化的服务。

5：table-format 特征

Table format的特征是将数据库功能添加到S3。Table Format还有助于遵循GDPR政策、跟踪和审计，以及数据删除。为什么这些功能都是必不可少的？想象一下需要将分析数据存储在S3上的parquet文件中，你需要对所有文件进行聚类，记录schema，同时读取和更新所有文件，找到一种备份和回滚的方法，以防数据写错，编写update或delete语句等繁重功能。这就是出现这些数据湖表格式的需求背景，因为每个人都需要它们并创建了一个标准。

DML和SQL支持：直接在分布式文件上提供Merge Into、Update和Delete操作。除了SQL，有些还支持Scala/Java和Python API。

Schema Evolution、Enforcement Schema：Schema evolution是Table format的一个关键特性，因为改表schema仍然是当今数据工程中的一个难题。Schema Evolution意味着在不破坏任何内容甚至扩大某些类型的情况下添加新列，甚至可以重命名或重新排序列（尽管这可能会破坏向后兼容性）。我们可以更改一张表格，Table format负责在所有分布式文件上切换它而不需要重写表和基础文件。

ACID事务、回滚、并发控制：ACID事务确保所有更改都成功提交或回滚。确保永远不会以不一致的状态结束。有不同的并发控制，例如保证读取和写入之间的一致性。每种Table format都有其相应的实现。

时间旅行：随着时间的推移，数据湖表格式会将存储在数据湖中的大数据版本化并形成多版本。您可以访问该数据的任何历史版本，在意外写入或删除错误的情况下回滚数据，或者重现历史测试和报告。时间旅行支持可重现的查询，可以同时查询两个不同的版本。所有版本都使用时间旅行功能进行快照，它简化了一些实现例如渐变维度。甚至可以像数据库一样捕获数据变更（CDC）。事务日志是每个事务自开始以来的有序记录。事务日志是上述许多功能使用的通用组件，包括ACID事务、可扩展的元数据处理和时间旅行。例如，Delta Lake创建一个名为_delta_log的文件夹。可扩展的元数据处理：这些表通过自动检查点和汇总来大规模处理大量文件及其元数据。

分区Evolution：分区和分区Evolution处理为表中的行自动生成繁琐且容易出错的分区值，通过过滤器自动优化跳过不必要的分区和文件。快速查询目标文件，表格布局可以随着数据的变化而更新。

文件大小调整：可以在Delta Lake中使用OPTIMIZE压缩数据，并通过VACUUM设置保留日期删除旧版本（其他数据湖表格式具有类似功能）。开箱即用支持数据压缩，您可以选择不同的重写策略，例如分bucket或文件内排序，以优化文件布局和大小。文件布局优化在解决小文件问题时特别有效，随着时间的推移摄入的小文件会增加，但查询数千个小文件很慢，文件布局优化可以将文件碎片重新整理为更大的文件，从而在许多方面提高性能。

统一批流处理：统一的批处理和流式处理意味着Lambda架构已过时。数据架构无需在批处理和流式中区分——它们都以相同的表视图对外暴露，复杂性更低，速度更快。无论是从流还是批处理中读取都能获取一致的数据快照。开箱即用的MERGE语句适用于流式的条件更新分布式文件。

数据共享：减少数据重复的一个新的令人兴奋和必要的功能是数据共享。在Delta Lake中，它被称为Delta Sharing。Snowflake宣布他们也将在Iceberg表中添加此功能。目前来看，这些是Databricks和Snowflake中的商业版功能。用于安全数据共享的开源Delta共享协议使得与其他组织共享数据变得简单，无论他们使用哪种计算平台。

变更数据流（CDF）：变更数据流（CDF）功能允许表跟踪版本之间的行级更改。启用后，运行时会记录写入表中的所有数据的“更改事件”。CDF包括行数据和元数据，记录是否插入、删除或更新了指定的行。

6：湖仓一体

湖仓一体是数据仓库的升级版本，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能，打通数据湖和数据仓库两套体系，兼具数据湖的灵活性与数据仓库的成长性。

有以下优点：

1. 低廉的存储成本
2. 云原生部署，存算分离，支持多云部署，支持弹性伸缩容
3. 架构扩展性问题
4. 统一元数据和权限管理（一份数据全域使用）
5. 一体化架构统一批处理、流处理、交互形态的多种场景的支持。

需要具备的能力：

• 一体化架构
• 统一表格式（table format）
• 统一存储格式（parquet, avro, orc...）
• 统一存储介质（对象存储、块存储）
• 统一元数据和权限管理（一份数据全域使用）
• 统一计算引擎（统一批流）
• 支持多计算引擎：内置引擎路由的能力，支持离线计算引擎、实时计算引擎、交互式查询引擎等多种引擎，并支持机器学习、深度学习框架，为数据集成和开发提供多种计算环境，供客户按需选择。
• 统一应用层（提供统一SDK，以支持不同应用）业务开放性，支持标准化的SQL和API，可以灵活的支持各种机器学习语言和框架
• 存算分离，支持多云部署，支持弹性伸缩容，提供serverless态服务，确保足够的弹性以及支持按需付费。高效的查询/更新性能

湖仓一体化架构的功能模块：

• 数据存储（Data Storage）：使用云对象存储来保存原始数据文件，需要能够高效地存储大量来自不同来源的数据。
• 存储引擎（Storage Engine）：负责处理数据管理任务，如数据压缩、重分区和索引等。存储引擎通过优化数据的组织方式，提高查询性能，并确保数据在云对象存储中的高效存储。
• 文件格式（File Format）：它将原始数据以特定的格式存储在对象存储中。数据湖仓使用开放的文件格式（如Apache Parquet、ORC等），这些格式具有高效的压缩和查询性能，并且可以被不同的分析引擎使用。
• 表格格式（Table Format）：表格格式是数据湖仓的一个重要组件，它在数据湖上添加了逻辑模型和可靠的数据治理。表格格式简化了数据文件的组织和管理，并提供了元数据管理和数据版本控制的功能。常见的表格格式包括Apache Iceberg、Apache Hudi和Delta Lake等。
• 计算引擎（Compute Engine）：计算引擎负责处理数据操作和计算任务，它与表格格式进行交互，实现数据的查询、转换和分析等功能。Lakehouse可以支持多种计算引擎，如Apache Spark、Presto等。
• 元数据服务（Catalog）：用于管理数据湖中的表格信息和元数据，它跟踪每个表格的名称、模式和其他相关信息，提供了数据发现和搜索的功能。

7：数据湖组件选型（Hudi、Iceberg、Paimon）

• 如果……请选择Iceberg：您的主要痛点不是对现有记录的更改，而是在对象存储（超过10k个分区）上管理大型表的元数据负担。采用Iceberg将缓解与S3对象列表或Hive Metastore分区枚举相关的性能问题。相反，对删除和突变的支持仍处于初步阶段，并且存在与数据保留相关的操作开销。适用于需要大规模批量处理数据的场景。稳定性最好，功能性最齐全。小时级别延时。
• 如果……请使用Hudi：您使用各种查询引擎，并且需要灵活地管理变异数据集。请注意，支持工具和整体开发人员体验可能很粗糙。尽管可能，但安装和调整Hudi以应对真正的大规模生产工作负载也需要运营开销。如果您使用的是Athena、Glue或EMR等AWS托管服务 - Hudi已经预先安装和配置，并且受AWS支持。主要适用于需要支持更新和删除操作的场景，以及自动高效小文件处理。分钟级延时。
• 如果……请选择Delta Lake：主要是Spark引擎，并期望写入吞吐量相对较低。适用于需要快速查询数据，且数据需要频繁更新的场景。小时级别。
• 如果……请选择Paimon：主要适用于数据实时更新/查询等低延时高效率的场景。和Flink生态集成最稳定。分钟级延时。

8：Lakehouse 开放性设计

在现代数据湖的Lakehouse架构中，保持开放性的设计原则是至关重要的。这种开放性体现在几个关键方面：

• 数据格式的开放性：Lakehouse架构应确保其支持的数据格式具有开放性。这意味着使用标准化的、与开源社区广泛兼容的数据格式，如Parquet和ORC。这种开放的数据格式允许Lakehouse与各种数据处理工具和计算引擎无缝对接，无论是开源的还是商业的。例如，Apache Spark、Presto和Flink等流行的开源计算引擎都能够高效地读取和写入这些开放格式的数据。
• 计算引擎的开放性：Lakehouse架构还应支持多种开源和商业计算引擎的接入。这种开放性确保了企业可以根据具体的业务需求和数据处理的场景，选择最合适的计算引擎。无论是实时数据处理、批处理还是交互式查询，Lakehouse都能够与各种计算引擎协同工作，提供高效的数据处理能力。
• 元数据与数据权限的集成：在Lakehouse中，元数据和数据权限管理是数据管理的基本能力要求。这种能力不仅确保了数据的组织和管理效率，还提供了精细的数据访问控制，保障了数据的安全性和合规性。
• 多云部署能力：Lakehouse架构应支持多云部署策略，包括在私有云和公共云环境中的部署。这种灵活性确保了企业可以根据自身的业务需求和资源状况，选择最合适的部署环境，同时保证了平台的持续稳定演进。

9：Lakehouse一体化设计

湖仓一体通常包含几种解释：

• 一体化的架构：一套技术架构产品来支持多种业务场景，需要满足以下：一体化架构、存算分离、事务和数据一致性、全数据类型，灵活统一元数据管理，提供serverless态服务、持按需付费...
• 数据存储的流批一体：同一份数据既支持流式读取也支持批量读取。物理上数据存储是一份。这种存储模式确保了数据的一致性，并减少了数据冗余。使用通用增量存储的统一存储形态。在湖仓存储架构的基础上增加了通用增量存储，使得在湖仓之上能够做增量的表达，该存储需要做到以下三点：
  • 实现大通用的存储，是可以适应面向写入Throughput和查询高性能的两个维度进行优化。
  • 数据存储支撑多种更新模型（Copy-on-write、Merge-on-read、Merge-on-write多种模式），通过Compaction达到效率和成本的平衡。
  • 实现数据的开放性，最终把数据的表达变成标准化的开源Iceberg/Paimon存储格式，使得其它的引擎或者平台可以很方便地对接起来。
• 计算引擎的流批一体：指流式计算和批量计算可以由同一个计算引擎完成。例如，Apache Flink和Apache Spark都支持流批一体的数据处理。这种方式可以降低架构复杂度，降低开发者的使用门槛。
• 计算形态的统一：用增量计算模式统一流、批和交互三种计算形态（增量物化视图）。
• 数据处理代码的流批一体化：指数据处理的代码可以同时适用于流式和批量的方式执行。这样可以降低开发成本，同时保证流批的任务代码逻辑一致性。在流批一体架构中，全链路支持批量和实时ETL计算。在数据仓库的各分层中，企业可以采用批量计算来保证小时级和天级的处理能力，同时利用实时计算来保证分钟级的数据处理能力。通过数据的统一处理，企业可以实现分钟级的数据可见性，并确保数据的一致性，避免批处理和流处理数据结果的不一致性。

10：LakeHouse的几种范式

湖上减仓

湖内建仓

仓外挂湖

end