数据湖调研

1 什么是数据湖

提到数据湖，大家都会有这样的疑问，什么是数据湖？为什么数据湖近两年热度很高？数据湖其实不是一个新的概念，最早的数据湖概念在 80 年代就已经提出，当时对数据湖的定义是原始数据层，可以存放各种结构化、半结构化甚至非结构化的数据。像机器学习、实时分析等很多场景都是在查询的时候确定数据的 Schema。

维基百科：数据湖是一个以原始格式存储数据的存储库或系统、它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。
亚马逊：“数据湖是一个集中式存储库，允许您亿任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需对数据进行结构化处理），并运行不同类型的分析-从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。”
微软的定义比较模糊：数据湖包含一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。

但无论定义是什么，数据湖围绕着以下两个点来展开的：

• 存储能力：包括大量的数据，以及各种结构化非结构化的数据存储，保持原始数据的模样，并需要存储价格低廉
• 分析能力：包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。

需要支持的能力：

• 实现数据治理（data governance）与数据生命周期管理和血缘关系。
• 通过应用机器学习与人工智能技术实现商业智能。
• 预测分析，如领域特定的推荐引擎。
• 信息追踪与一致性保障。
• 根据对历史的分析生成新的数据维度。
• 有一个集中式的能存储所有企业数据的数据中心，有利于实现一个针对数据传输优化的数据服务。
• 帮助组织或企业做出更多灵活的关于企业增长的决策。

结合多方面给数据湖下一个定义：如果需要给数据湖下一个定义，可以定义为这样：数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。能够通过规范化的元数据管理，廉价的存储，解决数据集市无法解决的数据孤岛，并通过中心化存储+元数据服务+周边的开放协作式的产品（es，计算引擎，分析引擎等），将数据用户机器学习与数据分析，为企业赋能。

简单的数据湖实现几乎等价于定义一个中心数据源，所有的系统都可以使用这个中心数据源来满足所有的数据需求。

2数据湖能解决什么问题

湖存储成本低、灵活性高的特性，非常适用于做查询场景的中心化存储。伴随着近年来云服务的兴起，尤其是对象存储的成熟，越来越多的企业选择在云上构建存储服务。数据湖的存算分离架构非常适合当前的云服务架构，通过快照隔离的方式，提供基础的 acid 事务，同时支持对接多种分析引擎适配不同的查询场景，可以说湖存储在成本和开放性上占了极大优势。

3数据湖与数仓的区别

Martin Fowler（敏捷开发提出者）：When I hear about a single point to pull together all the data an organization wants to analyze, I immediately think of the notion of the data warehouse (and data mart [1]). But there is a vital distinction between the data lake and the data warehouse. The data lake stores raw data, in whatever form the data source provides. There is no assumptions about the schema of the data, each data source can use whatever schema it likes. It’s up to the consumers of that data to make sense of that data for their own purposes.

翻译：当我听说有一个单一的点可以收集组织想要分析的所有数据时，我立刻想到了数据仓库（以及数据集市[1]）的概念。但数据湖和数据仓库之间有着至关重要的区别。数据湖以数据源提供的任何形式存储原始数据。对于数据的模式没有任何假设，每个数据源都可以使用它喜欢的任何模式。这取决于这些数据的消费者为了自己的目的理解这些数据。

Martin Fowler对数据湖的理解：https://martinfowler.com/bliki/DataLake.html

4数据湖生态

如上图所示，对于一个成熟的数据湖生态而言：

• 首先我们认为它底下应具备海量存储的能力，常见的有对象存储，公有云存储以及 HDFS；
• 在这之上，也需要支持丰富的数据类型，包括非结构化的图像视频，半结构化的 CSV、XML、Log，以及结构化的数据库表；
• 除此之外，需要高效统一的元数据管理，使得计算引擎可以方便地索引到各种类型数据来做分析。
• 最后，我们需要支持丰富的计算引擎，包括 Flink、Spark、Hive、Presto 等，从而方便对接企业中已有的一些应用架构。

5当前常见的数据湖实现方案

数据湖中最需要解决的问题就是非结构化的数据存储问题，当前有三种流行的数据湖格式，但根据大厂们的报告，现在互联网大厂们最多使用的都是：基于Hudi与基于Iceberg的两种。

不同的数据湖格式，解决的主要问题都是存储的问题。

5.1 基于Hudi

Hadoop Upserts and Incrementals：Hudi是一个开源Spark三方库，是数据湖的一个开源方案。主要有一下的功能，Hudi 从项目之初就一直朝着平台方向去演化，拥有比较完善的数据治理和 table service，比如用户在写入的时候可以并发地优化文件的布局，metadata table 可以大幅优化写入时查询端的文件查找效率。

• Hudi能够摄入（Ingest）和管理（Manage）基于HDFS之上的大型分析数据集，主要目的是高效的减少入库延时。
• Hudi基于Spark来对HDFS上的数据进行更新、插入、删除等。
• Hudi在HDFS数据集上提供如下流原语：插入更新（如何改变数据集）；增量拉取（如何获取变更的数据）。
• Hudi可以对HDFS上的parquet格式数据进行插入/更新操作。
• Hudi通过自定义InputFormat与Hadoop生态系统（Spark、Hive、Parquet）集成。
• 变更流：Hudi 对获取数据变更提供了流的支持，可以从给定的时间点获取给定表中已 updated / inserted / deleted 的所有记录的增量流，可以查询不同时间的状态数据，个人理解为，快照；
• Hudi能够与Hive、Spark、Presto这类处理引擎一起工作。Hudi有自己的数据表，通过将Hudi的Bundle整合进Hive、Spark、Presto等这类引擎中，使得这些引擎可以查询Hudi表数据，从而具备Hudi所提供的Snapshot Query、Incremental Query、Read Optimized Query的能力。
  
  百信银行Hudi数据湖架构：
  

5.2基于Iceberg

Iceberg 作为新兴的数据湖框架之一，开创性的抽象出“表格式”table format"这一中间层，既独立于上层的计算引擎（如Spark和Flink）和查询引擎（如Hive和Presto），也和下层的文件格式（如Parquet，ORC和Avro）相互解耦。简单点说：Iceberg定位在计算引擎之下，存储之上，通过特定的方式将数据和元数据组织起来，它是一种数据存储格式

Iceberg的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎（如Flink、Hive、Spark）对接。
所以 Iceberg 的架构更加的优雅，对于数据格式、类型系统有完备的定义和可进化的设计。
但是 Iceberg 缺少行级更新、删除能力，这两大能力是现有数据组织最大的卖点，社区仍然在优化中。

5.2.1 Iceberg应用场景：

• 集成Hive（可以通过 Hive 创建和删除 iceberg 表，通过 HiveSQL 查询 Iceberg 表中的数据，基于Spark进行数据修正）
• 流式数据入库，引入iceberg作为Flink Sink（打造实时数仓）
• 数据湖（海量数据，快速查找，统一存储）
• 集成Implala（用户可以通过 Impala 新建 iceberg 内表外表，并通过 Impala 查询 Iceberg 表中的数据）
  Iceberg同Hudi一样拥有ACID ，版本快照等能力

5.3 数据湖基本实现 ：

1. 最底下是分布式文件系统，云上用户 S3 和 oss 这种对象存储会用的更多一些，毕竟价格便宜很多；非云上用户一般采用自己维护的 HDFS。
2. 第二层是数据加速层。数据湖架构是一个存储计算彻底分离的架构，如果所有的数据访问都远程读取文件系统上的数据，那么性能和成本开销都很大。如果能把经常访问到的一些热点数据缓存在计算节点本地，这就非常自然的实现了冷热分离，一方面能收获到不错的本地读取性能，另一方面还节省了远程访问的带宽。这一层里面，我们一般会选择开源的 alluxio，或者选择阿里云上的 Jindofs。
3. 第三层就是 Table format 层，主要是把一批数据文件封装成一个有业务意义的 table，提供 ACID、snapshot、schema、partition 等表级别的语义。一般对应这开源的 Delta、Iceberg、Hudi 等项目。
4. 最上层就是不同计算场景的计算引擎了。开源的一般有 Spark、Flink、Hive、Presto、Hive MR 等，这一批计算引擎是可以同时访问同一张数据湖的表的。

5.4 常用数据湖组件对比

5.4.1 ACID 和隔离级别支持

1. Serialization 是说所有的 reader 和 writer 都必须串行执行；
2. Write Serialization: 是说多个 writer 必须严格串行，reader 和 writer 之间则可以同时跑；
3. Snapshot Isolation: 是说如果多个 writer 写的数据无交集，则可以并发执行；否则只能串行。Reader 和 writer 可以同时跑。

5.4.2 Schema 变更支持和设计

一个是 schema 变更的支持情况， Hudi 仅支持添加可选列和删除列这种向后兼容的 DDL 操作，而其他方案则没有这个限制。另外一个是数据湖是否自定义 schema 接口，以期跟计算引擎的 schema 解耦。这里 Iceberg 是做的比较好的，抽象了自己的 schema，不绑定任何计算引擎层面的 schema。

5.4.3 流批接口支持

5.4.4 接口抽象程度和插件化

Iceberg 是抽象程度做得最好的数据湖方案，四个方面都做了非常干净的解耦。Delta 是 databricks 背后主推的，必须天然绑定 Spark；Hudi 的代码跟 Delta 类似，也是强绑定 Spark。存储可插拔的意思是说，是否方便迁移到其他分布式文件系统上（例如 S3），这需要数据湖对文件系统 API 接口有最少的语义依赖，例如若数据湖的 ACID 强依赖文件系统 rename 接口原子性的话，就难以迁移到 S3 这样廉价存储上，目前来看只有 Hive 没有太考虑这方面的设计；文件格式指的是在不依赖数据湖工具的情况下，是否能读取和分析文件数据，这就要求数据湖不额外设计自己的文件格式，统一用开源的 parquet 和 avro 等格式。这里，有一个好处就是，迁移的成本很低，不会被某一个数据湖方案给绑死。

5.4.5 查询性能优化

5.4.6 其他功能

6业内案例

腾讯数据湖：

阿里云数据湖:

• （1）数据存储：采用OSS作为数据湖的集中存储，可以支撑EB规模的数据湖，客户无需考虑存储量扩容，各类型数据可以统一存储
• （2）数据湖管理：面对 OSS 数据开放性带来的管理及入湖困难，DLA的Formation组件具备元数据发现和一键建湖的能力，DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理，无论数据是在“湖中”还是在“湖外”，比如利用元数据爬取功能，可以一键创建 OSS 上的元数据信息，轻松自动识别 CSV/JSON/Parquet 等格式，建立好库表信息，方便后续计算引擎使用
• （3）数据分析和计算：DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎，都和Meta data catalog深度集成，能方便的获取元数据信息。基于Spark的能力，DLA解决方案支持批处理、流计算和机器学习等计算模式
• （4）在数据集成和开发上：阿里云的数据湖解决方案提供两种选择：一种是采用dataworks完成；另一种是采用DMS来完成。无论是选择哪种，都能对外提供可视化的流程编排、任务调度、任务管理能力。在数据生命周期管理上，dataworks的数据地图能力相对更加成熟。

Aws：

AWS数据湖[8]基于AWS Lake Formation构建，AWS Lake Formation本质上是一个管理性质的组件，它与其他AWS服务互相配合，来完成整个企业级数据湖构建功能。上图自左向右，体现了数据沉淀、数据流入、数据计算、数据服务等步骤。

• （1）数据沉淀：采用Amazon S3作为整个数据湖的集中存储，包含结构化和非结构化的数据，按需扩展/按使用量付费
• （2） 数据流入：元数据抓取、ETL和数据准备AWS将其单独抽象出来，形成了一个产品叫AWS GLUE，GLUE基本的计算形式是各类批处理模式的ETL任务，任务的出发方式分为手动触发、定时触发、事件触发三种
• （3）数据处理：利用AWS GLUE进行批处理计算模式之外，也可以使用Amazon EMR进行数据的高级处理分析，或者基于Amazon EMR、Amazon Kinesis来完成流处理任务
• （4）数据分析：数据通过Athena/Redshift来提供基于SQL的交互式批处理能力，通过 Amazon Machine Learning、Amazon Lex、Amazon Rekognition进行深度加工

7其他

当前有部分也有一些厂商在做湖仓一体，也可能是一个发展趋势
阿里云提出的湖仓一体概念为：

• （1）湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖（成为原始数据一部分），湖的结构化应用知识沉淀到数据仓库
• （2）湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作
• （3）数据湖与数据仓库的数据，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化