为什么需要新的数据架构？

数据仓库和数据湖一直是实现数据平台最流行的架构，然而，过去几年，社区一直在努力利用不同的数据架构方法来实现数据平台。寻找新方法而不是经过充分验证的传统数据架构（如数据仓库或数据湖）的动机主要有两个原因：

1. 传统架构在作为独立系统实现时存在一些限制。
2. 过去几年中社区出现了许多技术进步，云空间内的创新和开源技术的成熟是主要推动力。

公司不断寻求克服传统架构的局限性，并利用新技术来构建可扩展、安全且可靠的平台。公司、独立服务供应商 (ISV) 和系统集成商 (SI) 尝试了不同的方法和创新解决方案来实施此类数据平台。下面列出了其中一些方法：

• 结合数据湖和数据仓库两层架构。
• 利用混合事务/分析处理 (HTAP) 技术，联合使用在线事务处理系统 (OLTP) 和联机分析处理系统 (OLAP) 的工作方式。
• 构建可以处理非结构化数据以及结构化和半结构化数据的现代云数据仓库。
• 构建高性能计算引擎，直接在数据湖上执行 BI。

社区多年来的所有这些努力表明需要一种新的架构模式，该模式可以提供以下功能：

• 支持实施一个可以处理所有数据格式并支持多种用例的统一平台。
• 应提供 ACID 支持、优秀的 BI 性能以及数据仓库的访问控制机制。
• 应该像数据湖一样可扩展、经济高效且灵活。
• 最重要的是，它应该支持构建一个简单开放的数据平台，可以帮助用户轻松消费数据。

这就是过去几年出现的一种新模式——湖仓一体架构。

湖仓一体（Lakehouse）——新的大数据架构模式

新工具、产品和开源技术改变了公司在过去几年中构建大数据系统的方式。这些新技术有助于简化复杂的数据架构，构建更可靠、开放和灵活的数据平台，以支持各种数据存储和数据分析工作。

Lakehouse 是一种新的架构模式，它利用这些技术增强来构建简单且开放的数据平台。如下图所示，LakeHouse 的核心是一个带有附加事务层和高性能计算引擎的数据湖。附加事务层帮助它获得类似数据仓库的 ACID 属性和其他特性。

Lakehouse = 云上对象存储 + 湖格式 + 湖管理平台

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

说明：附加事务层有时也称为元数据层，因为为了保持一致性，它提供与事务相关的元数据。

同时具备数仓与数据湖的优点

使用 Lakehouse 架构构建的数据平台同时具有数据仓库和数据湖的特性，因此被称为 Lakehouse。下图显示了 Lakehouse 的关键功能，它结合了数据湖和数据仓库的最佳功能。

数据湖的优点

• 高可用性
• 存储成本低
• 可扩展性好
• 支持各种结构化和非结构化数据存储
• 支持机器学习模型

数据仓库的优点

• 支持 ACID 事务性
• 优秀的使用方式
• 支持更新和删除数据
• 权限控制简单
• 支持 SQL 查询
• 支持 BI 报表生成

Datawarehouse 的解决方案是：热数据在高速存储上进行维护 + 维护统计信息 + 通过索引机制高效访问数据 + 优化数据格式和计算引擎。由于 Lakehouse 基于存量的存储系统构建，动存储格式是不可行的。但有一些不需要改变文件的优化方案可以尝试，比如：数据缓存/辅助数据结构（索引/统计信息）/数据布局优化。

为什么需要数据湖？

更低的存储成本，更高的可靠性： 使用对象存储，相比于本地磁盘存储、SSD 存储或者云盘存储等，可以大幅降低存储成本，并且通过编码的方式能够在降低副本数据量的同时又能保证高可靠性，可以使用户不用担心底层数据的丢失，从而获得低成本的存储。

更好的 Tableformat： 通过支持 ACID 事务、支持 Schema evolution，能够为用户提供更好的表格式。

更好的 Fileformat： 数据湖在文件格式上支持越来越多的半结构化 map、Struct、Json 等，并且支持越来越多的索引，进而使文件的查询和存储效率更高，并且在基于列式存储的基础上支持更多的复杂嵌套结构。

统一的 Catalog： 通过统一的 Catalog 实现统一的元数据管理、权限管理、统计信息管理、入湖管理等。

Lakehouse 是如何支持数据湖的？

与数据湖一样，Lakehouse 使用 Amazon S3、ADLS 或 OSS 等云对象存储，并以 Apache Parquet、Apache Avro 或 Apache ORC 等开放文件格式存储数据。这种云存储使 Lakehouse 能够拥有数据湖的所有最佳功能，例如高可用性、高耐用性、成本低廉、可扩展性、支持所有数据类型（结构化、半结构化、非结构化）以及支持 AI/ML 用例。

Lakehouse 是如何支持数据仓库的？

与数据湖相比，Lakehouse 有一个额外的组件 - 事务层，它是文件格式之上的附加层，这个额外的层将 Lakehouse 与数据湖区别开。它使 Lakehouse 能够获得数据仓库功能，例如 ACID 合规性、更新/删除支持、更好的 BI 性能和细粒度访问控制。用于实现该事务层的技术称为“open table formats”或“storage frameworks”。

Lakehouse 解决了什么问题？

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

LakeHouse 一体化产品需要满足的要求和能力

1. 统一数据集成，全界面化的数据集成能力

• 提供多种数据抽取方式，将生产中大量结构化和非结构化的离线、实时数据抽取到数据仓库，实现数据汇聚为数据的资产化和标准化提供数据基础。

2. 打通元数据，提供集团统一的元数据管理能力

• 提供数据库元数据管理功能，实现各种数据库和数仓的元数据无缝打通和统一管理；科杰湖仓一体敏捷数据平台将 HiveMetaStore 中 database 映射为平台内的的 Rowdata，对 Hive Database 的改动会实时反应在这个 Rowdata 中，实现 lake+house 一体化存储访问功能。

3. 对不同存储的数据提供统一的开发管理能力

• 提供多引擎计算能力，支持将多个数据存储内的数据通过 HQL、Spark、MR、shell 等开发任务，进行统一开发、智能调度、数据治理和任务管理能力；同时提供跨团队大规模项目的协同开发能力，极大的提升开发效率。

4. 一站式、全托管、云原生智能化的敏捷数据平台能力

• 提供全可视化任务开发配置功能，智能解析任务依赖，并在数据处理的全流程提供数据质量和标准管理，在数据从产生到消费的全生命周期自动沉淀数据资产。

5. 企业级高性能、稳定性、可靠性

• 平台云原生架构，系统基于模块化、组件化、服务化构建，支持存储、服务、计算弹性伸缩。当部分设备发生故障时，仍可正常运行，满足企业对系统可用性的要求，可达 99.99% 以上。

Lakehouse 开放性设计

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

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

LakeHouse 需要具备的能力：

• 一体化架构： 指将数据仓库和数据湖融合在一起，实现数据的统一管理和使用。
• 统一表格式（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）： 用于管理数据湖中的表格信息和元数据，它跟踪每个表格的名称、模式和其他相关信息，提供了数据发现和搜索的功能。

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

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

湖仓一体架构

下图是数据湖仓的简单架构图，包括存储层和计算层：

Lakehouse 架构由存储层和计算层组成，计算层的数据来源于存储层。

存储层

存储层主要由三个组件组成——云存储、开放的文件格式（open file format）和开放的表格式（open table format）。

云存储

云存储是一种提供实施数据湖和 Lakehouse 平台所需的高可用性、持久性和可扩展性的服务，可以使用亚马逊的 S3 存储或者阿里云的 OSS 对象存储等云服务商提供的对象存储。

公司也可以使用本地 HDFS 存储来实施 Lakehouse，仅使用云对象存储来实现 Lakehouse 是没有必要的。但考虑到成本低、计算与存储分离、易于扩展等特点，建议使用云对象存储作为实现 Lakehouse 的底层基础设施。

元数据层

基于数据湖构建统一的数据平台，提供了统一的元数据管理和数据权限管理。原来分集群建设，导致元数据和用户账号不统一，在数据和权限管理上也带来很大麻烦。如果统一元数据和账号体系的管理，就能更方便的做统一的数据管理和权限管理。

用于管理数据湖中的表格信息和元数据，它跟踪每个表格的名称、模式和其他相关信息，提供了数据发现和搜索的功能。

开放的文件格式

数据平台可以将不同文件格式的数据存储在云存储中，CSV、JSON 和 XML 等文件格式是最流行的。对于分析平台，最广泛采用的三种文件格式是：

• Apache Parquet
• Apache ORC
• Apache AVRO

这几种都是开源的列式存储格式，很多存储和处理应引擎都会兼容这几种存储格式。

开放的表格式

湖仓 Lakehouse 支持多种表存储格式，目前开源社区比较流行的是下边三种：

• Apache Iceberg： Apache Iceberg 是一种开放表格式，可与基于云的数据湖和 Apache Parquet、Apache AVRO 和 Apache Optimized Row Columnar (ORC) 等开放文件格式一起使用，以实现 Lakehouse 架构。它支持时间回溯、schema 推演和 SQL 查询等功能，使 Lakehouse 的构建更快、更容易。
• Apache Hudi： Apache Hudi 有助于实现事务数据湖，并可用于为数据湖带来类似数据仓库的功能。它提供 ACID 事务保证、时间回溯和回滚能力以及 schema 推演功能。
• Linux 基金会的 Delta Lake： Databricks 将 Delta Lake 作为一个内部项目启动，后来在 Linux 基金会下将其开源。它通常被称为用于构建 Lakehouse 架构的开源存储框架。Delta Lake 为数据湖提供元数据层和 ACID 功能。它还提供时间回溯、schema 推演以及审计跟踪记录等功能。

计算层

Lakehouse 架构的主要优点之一是其开放性以及可由任何兼容处理引擎直接访问或查询的能力。它不需要任何特定的专有引擎来运行 BI 工作负载或交互式分析。这些计算引擎可以是开源的，也可以是专为 Lakehouse 架构设计的专用商业查询引擎。

计算引擎

可以通过 Apache Spark、Presto、Trino 和 Hive 等开源计算引擎，进行数据湖数据查询分析。

湖仓一体特性

单一存储

如前面所说，Lakehouse 的核心是一个使用云对象存储和附加事务层构建的数据湖。没有像专用数据仓库那样的单独存储来支持 BI 查询，所有消费者都直接从数据湖读取、访问或查询数据。相同的云对象存储支持所有用例，包括 BI 和 AI/ML 工作负载。

拥有数据仓库的查询性能

虽然数据湖使用对象存储保存数据，但是对象存储不适合进行大数据查询和分析，可以通过湖仓一体架构的计算层去查询计算存储层中（对象存储）的数据，拥有类似传统数据仓库的查询性能。

存算分离

Lakehouse 架构将存储和计算分离，这有助于单独扩展存储和计算容量，可以轻松添加更多存储，而无需增加计算容量，如下如所示：

开放式架构

Lakehouse 架构使用“开放”方法来实现数据平台。它使我们可以自由地为我们的数据平台使用开源数据格式和开源计算引擎。与传统数据仓库不同，传统数据仓库计算和存储紧密绑定，Lakehouse 架构可以使用与底层存储格式兼容的任何分布式计算引擎。

这种开放的架构设计可以使数据平台直接从云存储中访问数据，而不需要依赖于供应商绑定的各种软件。

支持各种数据源类型

因为使用的是对象存储，可以支持各种结构化和非结构化的源数据，并且使用的是 ELT 的加载模式，数据源在写入的时候，不会进行 schema 校验，可以快速的接入各种类型的数据源。

支持各种使用方式

因为支持各种类型的数据源接入，Lakehouse 架构除了支持 BI 报表查询，ETL 等，还支持 AI/ML 机器学习模型存储，实时计算等。

架构简单

所有数据都驻留在 Lakehouse 架构中的单个存储层中。由于没有单独的专用仓库，因此它简化了数据架构，并减少了将数据从数据湖移动到数据仓库所需的额外 ETL 管道。

它还避免了与数据集成到数据湖和数据仓库相关的延迟、故障或数据质量问题。这种具有单存储层的架构有几个优点：

• 无需额外的工作即可在数据湖和数据仓库之间同步数据。
• 无需担心数据湖和数据仓库之间数据类型的更改。
• Lakehouse 中的数据治理变得更加容易，因为我们只需在一处实施访问控制。在两层存储系统中，我们必须维护单独的访问控制机制来访问数据湖和数据仓库中的数据，并确保它们始终同步。
• ML 工作时可以直接从 Lakehouse 读取数据，直接访问底层 Parquet、Avro 或 ORC 存储文件，而无需将任何聚合数据从数据仓库复制到 Lakehouse。

数据共享

下游数据消费者可以使用自己喜欢的方式直接从云对象存储中获取他们想要的数据，而无需和数据平台绑定，使用平台的工具，这使得数据共享非常简单。

另外数据生产者也不用关心用户改如何获取数据，只需要通过外部共享服务来做权限控制即可，如下图所示：

Schema 过滤和推演

Lakehouse 架构在接入数据源时可以定义 schema 来保证写入的数据是要我们想要的类型和格式，但是也可以在写入时不定义 schema，这将可以保存各种格式和类型的数据，只需要在读取时定义 schema 就可以获取我们想要的数据。

这种 schema 推演可以保证数据的时效性，以及不丢失性。

时间回溯

Lakehouse 架构的事物层使其能够维护各种版本的数据，这有助于我们查询各个版本的数据，只需要简单的指定版本号或者时间戳即可。

湖仓一体（Lakehouse）架构之存储层

Lakehouse 存储关键概念

存储层是数据生态系统的支柱，当实施数据平台时，将需要一个持久、可靠且高度可用的存储层，可以保存大量所有类型的历史数据。除了上述功能之外，Lakehouse 平台还需要一个存储层，该存储层还可以实现快速检索、支持 ACID 功能并保留旧版本的数据。

行存储与列存储

所有创建表或在表中插入数据的操作，都会以文件形式存储在物理磁盘上。在现代数据平台中，一般使用云存储来保存数据，有两种存储数据的方法：行式存储和列式存储。

下边对行存储和列存储进行简单的介绍说明，如下图所示，有一个产品表：

行式存储将在物理磁盘上存储整行数据：

当查询数据时，它会从磁盘读取完整的行。当查询想要读取数据中的所有列时，这非常有用。然而，数据分析工作一般只会查询指定的列，由于基于行的存储的性质，查询必须读取许多记录中的所有列，而不管查询所需的列数是多少，导致消耗资源大，查询效率低。

列式存储会对相同类型的数据进行压缩，只会扫描查询指定的列，而不会扫描整行数据，查询效率高。

基于存储的查询性能优化

存储不仅仅是保存数据，它还使计算引擎能够通过减少要扫描的数据来更快地检索所需的结果。决定性能的不仅是计算引擎，还有底层存储。任何分析查询的数据检索时间都会受到扫描数据量的严重影响。扫描的数据越少，获取结果所需的时间就越短。现代文件和表格式有助于最大限度地减少查询检索结果所需扫描的数据，该过程被称为 数据跳跃 或 行跳跃。

有多种方法可以跳过不需要的数据，包括：

• 仅选择需要查询的字段
• 使用分区表
• 维护列统计信息
• 创建索引

Lakehouse 存储组件

Lakehouse 存储层由三个主要部分组成：

1. 用于物理存储数据的 云存储。
2. 用于压缩数据并支持分布式处理的 开放文件格式。
3. 开放的表格式 提供事务处理能力和高效的数据检索。

云储存

存储层负责持久化保存 Lakehouse 架构中的所有数据，云存储最适合存储大量此类数据，这些数据的性质、类型、大小和接收速度各不相同。下图显示了 Lakehouse 存储层以及可用于实现它的不同云对象存储技术：

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

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

大多数云厂商的云存储（S3, OSS 等）都提供上边的特性，所以在实践 Lakehouse 架构时首选云对象存储，而不是 HDFS。

文件格式

存储层中的下一个组件是文件格式，定义了在云存储上存储数据的方式：行存储或列存储。现代文件格式为了支持分布式处理的能力，会对文件数据进行压缩和分割成多个小文件。

一些流行的文件格式，包括 CSV、JSON 和 XML，在处理大数据时存在一些关键限制：

• 压缩能力有限，占用存储空间大。
• 数据检索时间长，分析查询通常需要很长时间才能获取所需的结果。
• 扫描的数据不仅限于所需的列，查询通常会扫描整个数据集来处理结果。
• 没有内置 schema，在读取这些文件时必须显式定义 schema。
• 需要处于未压缩的原始形式，才能支持分布式处理。

什么是可分割文件格式？

在分布式处理中，数据分布在各个集群上以支持并行处理。当文件存储在这些分布式存储上时，需要将其存储到各种数据块或块中，以便多个处理引擎可以读取这些块。用于存储数据的文件格式应该支持这种将文件分割成多个块的方式。大数据系统中的文件通常容量很大并经过压缩以节省存储空间并提高性能。它们的压缩形式应该是可拆分的，以执行分布式处理。大数据文件格式在使用支持的压缩算法（如 Snappy、LZO、BZIP2 等）进行压缩时支持此类拆分。但是，传统格式（如 CSV）在使用 GZIP 压缩进行压缩时无法进行拆分。

目前社区比较流行的三种压缩文件格式包括：

• Apache Parquet
• Apache ORC
• Apache Avro

Apache Parquet

Parquet 提供比 CSV 和 JSON 文件格式更好的压缩比，并提供强大的处理复杂数据的性能。

文件结构 下图简单展示了 Parquet 文件格式布局：

• 每个 Parquet 文件都由页眉、页脚和数据块组成。
• Header 包含指示文件采用 Parquet 格式的详细信息。
• 数据块由多个行组组成，这些行组逻辑上组合了文件中的各个行。
• 行组由文件中存在的列组成。
• Parquet 将每列中的值存储为页，页是 Parquet 中最小存储单位。
• 文件页脚由行组和列的元数据组成，元数据包括有助于数据跳过的最小/最大值等统计信息。

优点

• 使用列式存储压缩，显著减小文件大小
• 可以仅扫描查询的列，不需要扫描所有列，提升查询效率
• Parquet 文件还记录了文件的 schema 信息，这有助于轻松地将数据加载到表中，并使用 Apache Spark 等框架拆分文件以进行分布式处理。

Apache ORC

与 Parquet 一样，也是一种列式文件格式，是 Hive 标准 RC 格式的继承者。Apache ORC 提供 ACID 支持，具有内置索引以加快数据检索速度，并支持 struct、list 和 map 等复杂数据类型。

文件结构

• 每个 ORC 文件包含页眉、页脚和多个称为条（stripe）的数据块。
• Header 包含指示该文件为 ORC 格式的详细信息。
• 每条 stripe 由索引数据、行数据和条带页脚组成。
• 索引数据保存所存储数据的索引，它还具有每列的最小值和最大值。
• 行数据保存扫描中使用的实际数据。
• Stripe 页脚包含与每列相关的详细信息，包括编码、位置、最小值和最大值。
• 文件页脚包含与文件中的 stripe 相关的统计信息：行数以及可帮助数据跳跃的信息。

优点

• ORC 与 Hive 进行了深度集成，主要是作为在 Hadoop 中存储数据的文件格式而创建的，这些数据将使用 Hive 进行处理。
• ORC 是一种列式存储，数据压缩率更高。
• ORC 是唯一支持 Hive 事务处理的文件格式。

Apache Avro

文件结构

• Header 由文件元数据组成，包括 schema、压缩代码的信息和随机生成的文件同步标记。
• Block 组成：该块中的对象数量，该块的大小（压缩后），以压缩形式存储为序列化对象的数据，文件的 16 位同步标记。

优点 除了和 Apache Parquet 和 Apache ORC 一样的列式存储优点，Apache Avro 还提供了一些独特的功能，有助于存储和处理大量数据：

• 其自描述性意味着它将 schema 与数据一起存储，任何消费者都可以在读取数据时获取 schema。
• schema 以 JSON 或 Avro iDL (AVDL) 格式存储，易于人类阅读，而实际数据以二进制存储以获得更好的压缩比。
• Avro 支持 schema 推演，使其成为 ETL 中可用的 schema 选择。
• Avro 文件是可分割的，这意味着它即使以压缩形式也可以用于分布式处理，从而有助于更快的数据处理。
• 它支持多种语言，包括 java、js、c、c++、C#、python、ruby。

相似点和差异点

所有这些文件格式的目的都是为了有效地存储数据并提高读取数据时的查询性能。这三者都具有类似的功能，有助于实现这些目标；然而，它们根据存储和压缩数据的方法存在关键差异，下边是其中的相似点和差异点说明。

支持的数据格式

• 所有三种格式都支持存储大量结构化和非结构化数据。

压缩

• 所有三种文件格式都提供比 CSV、TXT 和 JSON 文件更高的压缩率。这有助于减少存储容量，也有助于提高查询性能。与 AVRO 文件格式相比，Parquet 和 ORC 提供更好的压缩。

下图是使用它们进行压缩 2G CSV 数据，三种压缩率对比：

可拆分

• Parquet、ORC 和 Avro 是可拆分的，可以支持分布式处理而无需解压缩数据，从而减少数据扫描量并加快数据检索速度。

使用场景

• Parquet 在社区中广泛使用，可以说是这三种格式中最受欢迎的格式，被许多计算框架集成，包括 Spark 等。
• ORC 与 Hive 深度集成，是唯一支持具有 ACID 特性的 Hive 的格式。
• 由于 schema 使用简单，Avro 非常适合 ETL 工作方式。

文件存储格式

• Parquet 和 ORC 遵循列式存储数据的格式，但具有不同的实现方法。Parquet 将数据存储为页，而 ORC 将数据存储为条。Avro 遵循基于行的方法并将数据存储在块中。这些不同的方法会影响其压缩率和数据跳过能力。

扫描数据

• 与 Parquet 和 ORC 相比，Avro 为写入操作提供了更好的性能。Parquet 和 ORC 在出于分析目的读取列子集时表现更好，因为它们可以根据列值跳过数据。
• 下图展示了从不同格式的文件中查询单列所扫描的数据量：

CSV 和 Avro 格式创建的表上运行的查询扫描了完整的数据，而 ORC 和 Parquet 表扫描的数据非常少，只扫描了所需的列。

Schema 推演

• Avro 支持 schema 推演 - 可以添加或修改列。Parquet 和 ORC 仅支持在末尾添加列。

说明 对于查询分析工作方式，列式存储最适合数据检索。ORC 和 Parquet 都提供良好的压缩级别并支持更快的数据检索。然而，ORC 最适合 Hive，而 Parquet 与 Apache Spark 适配很好。考虑到大多数现代供应商数据平台都采用了 Parquet，我们可以将其视为存储分析数据的首选。可以使用 Avro 对其进行补充，以存储 ETL 过程中使用的原始数据。在选择存储文件格式之前，我们应该仔细考虑使用场景。

表格格式

表格格式有助于组织每个表格的数据文件，它由与数据文件相关的信息组成，如 schema 详细信息、文件创建/更新时间、每个文件中的记录数、记录级别操作类型（添加/删除）等。表格式使数据湖具有 ACID 功能，支持更新/删除和数据跳过功能，从而提高查询的性能。

Apache Hive

Hive 拥有 Hive-Server 2 (HS2)、Hive Metastore (HMS) 和 Beeline（Hive 命令行界面）等关键组件作为其服务的一部分。它使用 HDFS 存储数据并使用 MapReduce 处理数据。

说明： Hive 有一个称为 Hive Metastore (HMS) 的中央元数据存储库，用于存储 Hive 表的 schema 详细信息。它还存储与每个表的分区相关的信息。许多数据平台都使用 HMS 作为存储元数据的元存储。

Hive 表目录结构如下：

当在 Hive 中创建表时，它会将数据存储在 HDFS 中，将 schema 存储在 HMS 中。Hive 表目录包含其根表文件夹下的所有文件。如果对该表进行分区，它将创建额外的分区级目录并将相关数据文件放置在这些目录下。数据始终驻留在数据湖（在本例中为 HDFS，也可以在 OSS 对象存储）上，不会加载到任何其他专用仓库存储中，从而使用户能够构建像 Lakehouse 这样仅具有单个存储层的系统。

优点

• 支持分区
• 多种存储格式，包括列式存储和 CSV，JSON 等
• 支持多种查询计算引擎，包括 Spark, Presto 等

缺点

• 不支持事物机制
• 查询计划时间长，性能有限
• 不支持更新、删除操作

无法通过执行 SQL 命令直接更新或删除 Hive 表中存在的任何记录。由于数据驻留在不可变的
end