1.从问题中走出来的LakeHouse

数据Lakehouse的概念是由 Uber 的一个团队于 2016 年首创，当时是为了解决存储大量大容量更新插入数据的问题。该项目最终成为Apache Hudi。

其他组织利用基于云对象的系统将数据存储为文件的思想，解耦昂贵的数据仓库计算和存储，创建了Apache Iceberg（Netflix公司）和Delta Lake（Databricks公司）。

以上三个项目是目前数据湖的典型实现方案，成功地降低了在数据仓库上运行大规模工作负载的成本，并释放了前所未有的数据规模。

目前的问题是：性能调整以维持规模化的 Lakehouse 部署。

2.性能问题分析

我们开发数据系统时，对性能表的重要性进行级别设置非常重要。

我们都希望以一种能够在业务应用程序中快速查询和使用的方式写入数据，但又不会在摄取和存储方面花费大量成本。

Lakehouse 和开放表格式可以通过存储和计算的解耦来显著节省成本，并利用云超大规模存储服务实现近乎无限可扩展的存储。

然而，如果数据没有适当优化，它们也存在对性能产生负面影响的风险。以下是未优化表的几个成本和性能超支的极端示例：

（1）针对大型数据科学工作负载的查询，其中在 Lakehouse 表中查询特征工程管道。这些管道有显着的延迟，并且管道显示内存不足错误。对这些表运行有效的优化可以允许数据跳过，并使管道能够根据需要继续进行。

（2）大规模（1 TB/小时）事件流数据需要处理到 Lakehouse 表中。然而未优化表上的端到端写入时间太慢，导致事件流主题中缺乏数据新鲜度和难以维持的数据积累量。

3.性能优化策略

下面是Lakehouse 表实现性能提升的常见方法

3.1.选择正确的表类型

三种格式都提供两种表类型的某些版本：写入时复制 (COW)或读取时合并 (MOR) 。这些表性能特征各异，可应用于不同类型的业务场景。

3.1.1.COW表适用场景

将数据添加到表中时，将为每个具有传入数据的文件组创建新的文件切片。这意味着这些表具有高效的读取性能，并且对于更新相对较少的工作负载（无论是总量还是记录百分比）具有良好的写入性能。

非常适用以下场景：

（1）适合读取优化的工作负载

（2）非常适合主要是插入的表（> 90% 的操作）

（3）简单的批处理作业

（4）如果需要快速 OLAP 查询

（5）运维负担低

3.1.2.MOR表适用场景

当更新写入表时，MOR 表会创建一系列日志文件，这些文件比重写基本 parquet 文件更轻量级。然而，在读取方面，为了获得最准确的数据视图，查询必须读取基础文件 (parquet) 和日志文件。这意味着查询可能需要比以前更长的时间。

MOR 表提供读取优化查询，其中引擎仅查询存在的基本文件 - 以牺牲数据新鲜度为代价提供更快的读取速度。

非常适用以下场景：

（1）适合写入优化的工作负载

（2）使处理更新和删除更加高效

（3）非常适合流式工作负载

（4）更改数据捕获表

（5）批处理+流表

3.2.优化分区策略

分区是指根据特定键将数据分离到不同的位置。该键根据键的值将数据拆分到不同的文件夹（分区）中。

分区可以提供读取器和写入器集群可以利用的一系列好处。

（1）水平扩展：分区允许集群随数据量水平扩展。通过将数据划分为更小的组，我们可以将每个分区隔离到节点上并相应地扩展计算。

（2）数据跳过和分区修剪：分区提高了查询性能，因为查询只需要查看与查询谓词相关的分区内的文件。查询可能永远不需要扫描表中的许多、大量文件，而可能并且将会扫描较小的数据量。

（3）更轻松的可管理性和生命周期管理：可以根据分区中定义的规则隔离数据。例如可以将“热”数据隔离到特定分区，并在分区级别管理生命周期规则和生存时间策略。可以根据分区中定义的规则隔离数据。例如可以将“热”数据隔离到特定分区，并在分区级别管理生命周期规则和生存时间策略。

业务场景跟分区密切相关，可以根据业务场景合理设计分区。

3.3.创建索引

索引于 2020 年首次在 Apache Hudi 中添加到数据Lakehouse中。从那时起，Hudi 将它们用作其性能加速工具库中的不可或缺的工具，并在Hudi 1.0.0 版本中添加了最新的二级索引。这个多模式索引系统由Hudi 元数据表提供支持。