关于hive:数据湖揭秘Delta-Lake

9次阅读

共计 3888 个字符，预计需要花费 10 分钟才能阅读完成。

简介：Delta Lake 是 DataBricks 公司开源的、用于构建湖仓架构的存储框架。可能反对 Spark，Flink，Hive，PrestoDB，Trino 等查问 / 计算引擎。作为一个凋谢格局的存储层，它在提供了批流一体的同时，为湖仓架构提供牢靠的，平安的，高性能的保障。

Delta Lake 是 DataBricks 公司开源的、用于构建湖仓架构的存储框架。可能反对 Spark，Flink，Hive，PrestoDB，Trino 等查问 / 计算引擎。作为一个凋谢格局的存储层，它在提供了批流一体的同时，为湖仓架构提供牢靠的，平安的，高性能的保障。

Delta Lake 要害个性：

ACID 事务：通过不同等级的隔离策略，Delta Lake 反对多个 pipeline 的并发读写；
数据版本治理：Delta Lake 通过 Snapshot 等来治理、审计数据及元数据的版本，并进而反对 time-travel 的形式查问历史版本数据或回溯到历史版本；
开源文件格式：Delta Lake 通过 parquet 格局来存储数据，以此来实现高性能的压缩等个性；
批流一体：Delta Lake 反对数据的批量和流式读写；
元数据演变：Delta Lake 容许用户合并 schema 或重写 schema，以适应不同期间数据结构的变更；
丰盛的 DML：Delta Lake 反对 Upsert，Delete 及 Merge 来适应不同场景下用户的应用需要，比方 CDC 场景；

湖表较于一般 Hive 表一个很大的不同点在于：湖表的元数据是自治理的，存储于文件系统。下图为 Delta Lake 表的文件构造。

Delta Lake 的文件构造次要有两局部组成：

_delta_log 目录：存储 deltalake 表的所有元数据信息，其中：

每次对表的操作称一次 commit，包含数据操作（Insert/Update/Delete/Merge）和元数据操作（增加新列 / 批改表配置），每次 commit 都会生成一个新的 json 格局的 log 文件，记录本次 commit 对表产生的行为（action），如新增文件，删除文件，更新后的元数据信息等；

默认状况下，每 10 次 commit 会主动合并成一个 parquet 格局的 checkpoint 文件，用于减速元数据的解析，及反对定期清理历史的元数据文件；

数据目录 / 文件：除 _delta_log 目录之外的即为理论存储表数据的文件；须要留神：

DeltaLake 对分区表的数据组织模式同一般的 Hive 表，分区字段及其对应值作为理论数据门路的一部分；

并非所有可见的数据文件均为无效的；DeltaLake 是以 snapshot 的模式组织表，最新 snopshot 所对应的无效数据文件在 _delta_log 元数据中治理；

Delta Lake 通过 snapshot 来治理表的多个版本，并且反对对历史版本的 Time-Travel 查问。不论是查问以后最新的 snapshot 还是历史某版本的 snapshot 信息，都须要先解析失去对应 snapshot 的元数据信息，次要波及到：

以后 DeltaLake 的读写版本协定（Protocol）；
表的字段信息和配置信息（Metadata）;
无效的数据文件列表；这一点通过一组新增文件（AddFile）和删除文件（RemoveFile）来形容；

那在加载具体 snopshot 时，为了减速加载流程，先尝试找到小于或等于该版本的 checkpoint 文件，而后联合其后直到以后版本的 log 文件，独特解析失去元数据信息。

阿里云 EMR 团队从 19 年就开始跟进 DeltaLake 社区，并将其落地在 EMR 的商业产品中的。期间，在迭代性能，优化性能，交融生态，升高易用性，场景落地等方面，一直打磨降级 DeltaLake，使之更好的融入 EMR 产品，不便客户应用。

以下表格汇总了 EMR DeltaLake 较开源 DeltaLake（社区 1.1.0）比照的次要自研个性。

特地阐明：

DeltaLake1.x 版本仅反对 Spark3，且绑定具体 Spark 版本，导致局部新性能 / 优化不能在老的版本及 Spark2 上应用，而 EMR DeltaLake 放弃 Spark2 的 DeltaLake（0.6）和 Spark3 的 DeltaLake（1.x）的性能个性同步；

DLF（Data Lake Formation）是一款全托管的疾速帮忙用户构建云上数据湖及 LakeHouse 的服务，为客户提供了对立的元数据管理、对立的权限与平安、便捷的数据入湖能力以及一键式数据摸索能力，无缝对接多种计算引擎，突破数据孤岛，洞察业务价值。

EMR DeltaLake 与 DLF 深度集成，使 DeltaLake 表创立写入后主动实现元数据同步到 DLF 的 metastore，防止了像开源版本那样，须要用户再自行建设 Hive 表面关联 DeltaLake 表的操作。同步后，用户能够间接通过 Hive、Presto、Impala，甚至阿里云 MaxCompute 及 Hologres 查问，无需任何其余额定操作。

同样 DLF 具备成熟的入湖能力，用户能够通过产品端的配置将 Mysql、RDS、Kafka 的数据间接同步生成 DeltaLake 表。

在 DLF 的产品侧，湖格局 DeltaLake 作为第一公民，DLF 也将在接下来的迭代中针对性的提供易用的可视化展现，和湖表治理的能力，帮忙用户更好的保护湖表。

Slowly Changing Dimension（SCD）即迟缓变动维，被认为是跟踪维度变动的要害 ETL 工作之一。在数仓场景下，通常应用星型模型来关联事实表和维度表。如果维度表中的某些维度随工夫更新，那么如何存储和治理以后和历史的维度值呢？是间接疏忽，还是间接笼罩，亦或者其余的解决形式，如永恒保留历史所有的维度值。依据不同的解决形式，SCD 定义了多种类型，其中 SCD Type2 通过减少新记录的形式保留所有的历史值。

在理论的生产环境中，咱们可能不须要关注所有的历史维度值，而关注在固定的时间段内最新的值，比方以天或者小时为粒度，关注在每一天或者小时内某个维度的值。因而理论的场景能够转化为基于固定粒度（或业务快照）的迟缓变动维（Based-Granularity Slowly Changing Dimension，G-SCD）。

在传统数仓基于 Hive 表的实现，有几种形式可选，以下列举两个解决方案：

流式构建 T + 1 时刻的增量数据表，和离线表的 T 时刻分区数据做合并，生成离线表 T + 1 分区。其中 T 示意粒度或业务快照。不难想象该计划每个分区保留了全量的数据，会造成大量的存储资源节约；

保留离线的根底表，每个业务时刻的增量数据独立保留，在查问数据时合并根底表和增量表。该计划会升高查问效率。

通过对 DeltaLake 本身的降级，联合对 SparkSQL，Spark Streaming 的适配，咱们实现了 SCD Type2 场景。架构如下：

同样对接上游的 Kafka 的数据，在 Streaming 端依照配置的业务快照粒度将 Batch 数据进行切分，别离 commit，并附带业务快照的值。DeltaLake 在接管到数据后，保留以后 snapshot 和业务快照的关系。并在下一个业务快照达到时，对前一个 snapshot 做 savepoint，永恒保留该版本。用户查问时，通过指定的业务快照的具体值，辨认到具体的 snapshot，而后通过 time-travel 的形式实现查问。

G-SCD on DeltaLake 计划劣势：

流批一体：不须要增量表和根底表两张表；
存储资源：借助 Delta Lake 自身的 data versioning 能力，实现增量变动维度的治理，不须要按工夫粒度保留历史全量数据；
查问性能：借助 Delta Lake 的元数据 checkpoint，数据的 Optimize、Zorder 及 DataSkipping 的能力，晋升查问效率；
保留原实现的 SQL 语句：用户仍然能够像用分区实现快照的形式一样，应用相似的分区字段执行要查问的业务工夫粒度内的快照数据。

在以后的数仓架构下，咱们往往将数据分层为 ODS，DWD，DWS，ADS 等方便管理。原始数据如存储在 Mysql 或者 RDS，咱们能够生产其 binlog 数据实现对 ODS 表的增量更新。但，从 ODS 到 DWD，从 DWD 到 DWS 层数据呢？因为 Hive 表自身不具备生成相似 binlog 数据的能力，因而咱们无奈实现上游各链路的增量更新。而让湖表具备生成相似 binlog 数据的能力，又是构建实时增量数仓的要害。

阿里云 EMR 基于 DeltaLake 实现了将其作为 Streaming Source 的 CDC 能力。开启后，对所有的数据操作将同时生成 ChangeData 并长久化，以便上游 Streaming 读取；同时反对 SparkSQL 语法查问。如下图所示：

ODS 层 Delta 表 user_city_table 接管 Source 数据执行 Merge 操作，同时将变更的数据长久化保留；DWS 层按 city 聚合的 city_cnt_table 表读取 user_city_table 表的 ChangeData 数据，对 cnt 聚合字段实现更新。

DeltaLake 作为 EMR 主推的湖格局，失去了很多客户的信赖和抉择，并落地到各自的理论生产环境，对接了多种场景。后续会继续加强在 DeltaLake 的投入，深度挖掘和 DLF 的集成，丰盛湖表运维治理能力，升高用户入湖老本；继续优化读写性能，欠缺与阿里云大数据体系的生态建设，推动客户湖仓一体架构的建设。

原文链接
本文为阿里云原创内容，未经容许不得转载。

正文完