实时方案之数据湖探究调研笔记

什么是数据湖

数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖？有不同的定义。

Wikipedia上说数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件，包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。

AWS定义数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。

微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义，数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。

关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开。

1、 数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。

2、 数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。

3、 数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。

4、 数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。

5、 数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。

6、 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。

7、 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。

8、 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。

综上，个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。

数据湖调研

1、Iceberg

Iceberg 作为新兴的数据湖框架之一，开创性的抽象出“表格式”table format"这一中间层，既独立于上层的计算引擎（如Spark和Flink）和查询引擎（如Hive和Presto），也和下层的文件格式（如Parquet，ORC和Avro）相互解耦。

此外 Iceberg 还提供了许多额外的能力：

• ACID事务；
• 时间旅行（time travel），以访问之前版本的数据
• 完备的自定义类型、分区方式和操作的抽象
• 列和分区方式可以进化，而且进化对用户无感，即无需重新组织或变更数据文件
• 隐式分区，使SQL不用针对分区方式特殊优化
• 面向云存储的优化等

Iceberg的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎（如Flink、Hive、Spark）对接。

所以 Iceberg 的架构更加的优雅，对于数据格式、类型系统有完备的定义和可进化的设计。

但是 Iceberg 缺少行级更新、删除能力，这两大能力是现有数据组织最大的卖点，社区仍然在优化中。

2、Hudi

1. Hudi 是什么

一般来说，我们会将大量数据存储到HDFS/S3，新数据增量写入，而旧数据鲜有改动，特别是在经过数据清洗，放入数据仓库的场景。

且在数据仓库如 hive中，对于update的支持非常有限，计算昂贵。

另一方面，若是有仅对某段时间内新增数据进行分析的场景，则hive、presto、hbase等也未提供原生方式，而是需要根据时间戳进行过滤分析。

Apache Hudi 代表 Hadoop Upserts and Incrementals，能够使HDFS数据集在分钟级的时延内支持变更，也支持下游系统对这个数据集的增量处理。

Hudi数据集通过自定义的 inputFormat 兼容当前 Hadoop 生态系统，包括 Apache Hive，Apache Parquet，Presto 和 Apache Spark，使得终端用户可以无缝的对接。

如下图，基于 Hudi 简化的服务架构，分钟级延迟。

1. Hudi 存储的架构

如上图，最下面有一个时间轴，这是 Hudi 的核心。

Hudi 会维护一个时间轴，在每次执行操作时（如写入、删除、合并等），均会带有一个时间戳。

通过时间轴，可以实现在仅查询某个时间点之后成功提交的数据，或是仅查询某个时间点之前的数据。这样可以避免扫描更大的时间范围，并非常高效地只消费更改过的文件（例如在某个时间点提交了更改操作后，仅 query 某个时间点之前的数据，则仍可以 query 修改前的数据）。

如上图的左边，Hudi 将数据集组织到与 Hive 表非常相似的基本路径下的目录结构中。

数据集分为多个分区，每个分区均由相对于基本路径的分区路径唯一标识。

如上图的中间部分，Hudi 以两种不同的存储格式存储所有摄取的数据。

• 读优化的列存格式（ROFormat）：仅使用列式文件（parquet）存储数据。在写入/更新数据时，直接同步合并原文件，生成新版本的基文件（需要重写整个列数据文件，即使只有一个字节的新数据被提交）。此存储类型下，写入数据非常昂贵，而读取的成本没有增加，所以适合频繁读的工作负载，因为数据集的最新版本在列式文件中始终可用，以进行高效的查询。
• 写优化的行存格式（WOFormat）：使用列式（parquet）与行式（avro）文件组合，进行数据存储。在更新记录时，更新到增量文件中（avro）， 然后进行异步（或同步）的compaction，创建列式文件（parquet）的新版本。此存储类型适合频繁写的工作负载，因为新记录是以appending 的模式写入增量文件中。但是在读取数据集时，需要将增量文件与旧文件进行合并，生成列式文件。

3、DeltaLake

传统的 lambda 架构需要同时维护批处理和流处理两套系统，资源消耗大，维护复杂。基于 Hive 的数仓或者传统的文件存储格式（比如 parquet / ORC），都存在一些难以解决的问题：

• 小文件问题
• 并发读写问题
• 有限的更新支持
• 海量元数据（例如分区）导致 metastore 不堪重负

如上图，Delta Lake 是 Spark 计算框架和存储系统之间带有 Schema 信息的存储中间层。它有一些重要的特性：

• 设计了基于 HDFS 存储的元数据系统，解决 metastore 不堪重负的问题；
• 支持更多种类的更新模式，比如 Merge / Update / Delete 等操作，配合流式写入或者读取的支持，让实时数据湖变得水到渠成；
• 流批操作可以共享同一张表；
• 版本概念，可以随时回溯，避免一次误操作或者代码逻辑而无法恢复的灾难性后果。

Delta Lake 是基于 Parquet 的存储层，所有的数据都是使用 Parquet 来存储，能够利用 parquet 原生高效的压缩和编码方案。

Delta Lake 在多并发写入之间提供 ACID 事务保证。每次写入都是一个事务，并且在事务日志中记录了写入的序列顺序。

事务日志跟踪文件级别的写入并使用乐观并发控制，这非常适合数据湖，因为多次写入/修改相同的文件很少发生。在存在冲突的情况下，Delta Lake 会抛出并发修改异常以便用户能够处理它们并重试其作业。

Delta Lake 其实只是一个 Lib 库，不是一个 service，不需要单独部署，而是直接依附于计算引擎的，但目前只支持 spark 引擎，使用过程中和 parquet 唯一的区别是把 format parquet 换成 delta 即可，可谓是部署和使用成本极低。

4、数据湖技术比较

总结