数据湖

1. 什么是数据湖

数据湖是一种存储系统，底层包括不同的文件格式及湖表格式，可存储大量非结构化和半结构化的原始数据。数据消费者可以访问该数据进行数据分析，包括BI、报表和机器学习模型训练。有了数据湖，数据变得越来越可用。

数据湖的本质是由 数据存储架构 + 数据处理工具 组成的解决方案。

2. 数据湖的本质

• 数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。
• 数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
• 数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
• 数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
• 数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
• 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
• 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
• 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。

总结下来：

1. 能够存储任意数据，结构化、非结构化、半结构化的数据。
2. 数据具有可访问性和开放性。
3. 丰富的计算引擎，从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。
4. 多模态的存储引擎。理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如S3/OSS/HDFS/OBS），并且在需要时与外置存储引擎协同工作，满足多样化的应用需求。
5. 支持记录级别的 update/delete，以增量更新数据。
6. 支持并发读写和事务的 ACID 特性；支持 MVCC。
7. 支持历史版本回溯。
8. 支持模式约束和演化 schema evolution, schema enforcement。
9. 灵活的元数据管理和组织形式。

3. 数据湖文件格式

数据湖由四个主要组件组成：存储层、格式化层、计算层和元数据层。

数据湖选型对比

• 如果……请选择 Iceberg
  您的主要痛点不是对现有记录的更改，而是在对象存储（超过 10k 个分区）上管理大型表的元数据负担。采用 Iceberg 将缓解与 S3 对象列表或 Hive Metastore 分区枚举相关的性能问题。
  相反，对删除和突变的支持仍处于初步阶段，并且存在与数据保留相关的操作开销。
  适用于需要大规模批量处理数据的场景。

• 如果……请使用 Hudi
  您使用各种查询引擎，并且需要灵活地管理变异数据集。请注意，支持工具和整体开发人员体验可能很粗糙。尽管可能，但安装和调整 Hudi 以应对真正的大规模生产工作负载也需要运营开销。
  如果您使用的是 Athena、Glue 或 EMR 等 AWS 托管服务 - Hudi 已经预先安装和配置，并且受 AWS 支持。
  主要适用于需要支持更新和删除操作的场景。

• 如果……请选择 Delta Lake
  主要是 Spark 引擎，并期望写入吞吐量相对较低。
  适用于需要快速查询数据，且数据需要频繁更新的场景。

表格上

Hive 是第一代表格式

最原始表格式是 Apache Hive。在 Hive 中，表被定义为一个或多个特定目录中的所有文件。虽然这使 SQL 表达式和其他分析能够在数据湖上运行，但它无法有效地扩展到满足当今需求所需的分析量和复杂性，所以现在开发了其他表格格式以提供所需的可伸缩性。

新一代表格式 -- TableFormat

Apache Iceberg、Apache Hudi 和 Databricks Delta Lake 定义为 一种开放式的表格式 为大数据分析，它的定位是在计算引擎之下，又在存储之上，将其称之为 table format。这三者都采用了类似的方法来利用元数据来处理繁重的工作，自下而上的元数据管理。

• table format 是什么？ 通俗来说，就是：
  Table format 定义了哪些文件构成一张表，这样任何引擎都可以根据 table format 查询和检索数据；
  Table format 规范了数据和文件的分布方式，任何引擎写入数据都要遵照这个标准，通过 format 定义的标准支持 ACID，模式演进等高阶功能。

Tableformat 是数据湖之上比 hive 更进一步的元数据封装，遵循所读即所写的原则，而在用户的读写之间应当有一个标准化的服务，比如在流和实时场景下，会在数据湖中写入很多碎片文件，这些小文件会导致读性能的急剧下降，在 chbenchmark 中，我们发现流式写入 2 小时就会导致 olap 性能下降 1 倍以上，不管是数据去重还是小文件合并，我们需要需要一套持续优化的服务来保障数据分析持续可用。

hive 以及现在的数据湖 table format 归根到底只是定义了表在数据湖上的元数据形态，并没有动态的湖仓管理机制，其次如果我们想做一套湖仓管理系统，思路和存算一体的 MPP 数据库也会有所区别，比如湖仓在后台进行的数据优化动作，用户需要为这些弹性的优化行为花钱，而这个钱会直接作用在湖仓的时效性和性能上，存算分离的管理系统需要为用户更加透明地梳理好时效性，性能，成本之间的关系：

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

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

在 Table format 这些项目的官网中，他们会主推一些功能主要包含 CDC、SQL 扩展，数据的 Rollback，以及 time travel，模式演进（Schema evolution）以及我们经常说的流式更新（Upsert）、读时合并（merge-on-read）的功能。

CDC 一定程度上能起到平替消息队列的作用，比如说在生产场景中，实时计算主要会用 Kafka 或者 Pulsar 做流表的选型。有了 Table format 之后，我们可以基于数据湖来实现类似于消息队列的功能，当然它的数据延迟会从毫秒或者秒级降级为分钟级别。像 Upsert、读时合并和行业内或者说很多公司去推广数据湖的主要场景，就是拿这个实时更新以及读时合并去平替 Apache Kudu、Doris、Greenplum 这些实时更新的数仓系统。

数据湖表格式在读写上需要关心的几个点：

1. 增量查询（Incremental Query），它在构建流数仓或批数仓时是一个非常重要的特性。
2. 时间旅行（Time Travel），我们能用它对数据进行回溯和重放，去做数据的回补。
3. 并发（Concurrency），不同的 Job 可以同时操作一张表。
4. 主键（Primary Keys），有了它可以像传统数据库一样更好地去做更新，比如进行 Upsert 操作。

Lakehouse 的介绍

流批一体和湖仓一体是什么关系

简单说，流批一体是需求，湖仓一体是方案。从 lakehouse 提出的背景看，湖仓一体一定是流批一体，但流批一体不一定基于数据湖，事实上很多传统数仓都具备流批一体的能力。

湖仓一体的核心在于一体：

• 统一表格式（table format）
• 统一存储格式（parquet, avro, orc...）
• 统一存储介质
• 统一元数据和权限管理（一份数据全域使用）
• 统一计算引擎
• 统一应用层（提供统一 SDK，以支持不同应用）
• 业务开放性，支持标准化的 SQL 和 API，可以灵活的支持各种机器学习语言和框架
• 存算分离，支持多云部署，支持弹性伸缩容
• 提供 serverless 态服务，确保足够的弹性以及支持按需付费。

什么是湖仓一体？

虽然数据仓库和数据湖的应用场景和架构不同，但它们并不是对立关系。数据仓库存储结构化的数据，适用于快速的 BI 和决策支撑，而数据湖可以存储任何格式的数据，往往通过挖掘能够发挥出数据的更大作为，因此在一些场景上二者的并存可以给企业带来更多收益。

湖仓一体，又被称为 Lake House，其出发点是通过数据仓库和数据湖的打通和融合，让数据流动起来，减少重复建设。Lake House 架构最重要的一点，是实现数据仓库和数据湖的数据/元数据无缝打通和自由流动。湖里的“显性价值”数据可以流到仓里，甚至可以直接被数仓使用；而仓里的“隐性价值”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

湖仓一体是一种新型开放式架构，将数据湖和数据仓库的优势充分结合，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能，打通数据湖和数据仓库两套体系，让数据和计算在湖和仓之间自由流动。作为新一代大数据技术架构，将逐渐取代单一数据湖和数据仓库架构。

Lakehouse 兼具数据湖的灵活性与数据仓库的成长性，目前这个方向已经逐渐走向成熟。与数据湖相比，Lakehouse 集成了计算框架和 SQL 查询引擎，添加了数据治理能力，支持 Catalog 表管理和先进的作业编排。

Lakehouse 的设计原则分为功能性设计要素和非功能性设计要素两类。其中，功能性设计要素包括：一体化架构、存算分离、事务和数据一致性、全数据类型。非功能性设计要素包括：弹性高可用、加强的数据治理、尽量少的数据冗余、高并发支持、运维可观测性、高开放性。

湖仓一体常见的几种方案

湖内建仓架构：

end