笔记|浅谈数据湖的探究与调研！大数据|数据湖

注：对于数据湖博主也是近期开始研究探索的，下面给大家简单的聊一聊数据湖。

浅谈数据湖的探究与调研！

文章图片

1、什么是数据湖（Data lake）？数据湖是目前比较热的一个概念，许多的企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，要搞清楚什么是数据湖，要明确一个数据湖项目的基本组成，从而去进行设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖？有不同的定义。
Wikipedia（维基百科）上说数据湖是一个以原始格式存储数据的存储库或系统、它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。
AWS（亚马逊）对数据湖的解释是“数据湖是一个集中式存储库，允许您亿任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需对数据进行结构化处理），并运行不同类型的分析-从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。”
微软对数据湖的定义就比较的模糊了，它并没有明确的指出什么是Data Lake，而是取巧的将数据湖的功能作为定义，数据湖包含一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。
关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开。
1、数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。
2、数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
3、数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
4、数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
5、数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
6、数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完善的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
7、数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据，然后规范存储，数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
8、对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。
以上，个人认为“数据湖”技术应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施，以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级的应用。
2、数据湖的调研 2.1 Iceberg
Iceberg 作为新兴的数据湖框架之一，开创性的抽象出“表格式”table format"这一中间层，既独立于上层的计算引擎（如Spark和Flink）和查询引擎（如Hive和Presto），也和下层的文件格式（如Parquet，ORC和Avro）相互解耦。

文章图片

此外 Iceberg 还提供了许多额外的能力：
1、ACID事务；
2、时间旅行（time travel），以访问之前版本的数据
3、完备的自定义类型、分区方式和操作的抽象
4、列和分区方式可以进化，而且进化对用户无感，即无需重新组织或变更数据文件
5、隐式分区，使SQL不用针对分区方式特殊优化
6、面向云存储的优化等
Iceberg的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎（如Flink、Hive、Spark）对接。
所以 Iceberg 的架构更加的优雅，对于数据格式、类型系统有完备的定义和可进化的设计。
但是 Iceberg 缺少行级更新、删除能力，这两大能力是现有数据组织最大的卖点，社区仍然在优化中。
2.2 Hudi
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 简化的服务架构，分钟级延迟。

文章图片

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、数据湖技术比较