仓湖一体

​

数据湖与数据仓库概念

一切产品形态的出现都应该是从应用场景出发。数据湖与数据仓库都是大数据领域不同场景需求下的具体实现。

在实际场景的应用实践中，任何结构化、非结构化数据都要经过产生、收集、清洗、分析、计算等n个过程才能产生最终的价值。数据湖和数据仓库就是随着数据量和数据格式的不断膨胀而出现的产品形态。

数据湖和数据仓库的本质共同点有两个，一是数据存储的媒介，二是对所存数据进行分析处理，挖掘数据价值，为上层提供数据服务。但两者之间由于主要存储的数据集不同而导致了产品特性有所不同。

数据仓库的发展要先于数据湖，受限于大数据技术发展、业务需求、数据管理理念等原因，人们首先想到并迫切需要的是对结构化数据进行分析，为BI等提供数据支撑，从而有了数据仓库概念，其在具备传统关系型数据库的一些功能特性的同时，需要存储更大量的历史数据并进行扫描和聚合计算。也就是说，在一个企业的发展路径中，首先构建的便是数据仓库体系，能够基于最有价值的结构化数据进行分析与计算。

随着互联网的发展，企业所管理的数据呈指数级增长，同时数据格式也多种多样，进而也推动了大数据技术发展，最终演变出了数据湖这种形态，它相比于数据仓库最大的特点便是对于存储数据没有强制性要求，即数据即不需要是结构化数据，也不需要提前定义数据模式，只需要以文件的形式存放在数据湖中即可，顾名思义更像是没有组织、但有边界的数据的集合。这种特性所带来的负面影响就是，数据湖无法像数据仓库那样具备高性能、事务管理、标准SQL语法等特性。

综上，数据湖和数据仓库各自有对应的应用场景，因此大多数企业目前也是数据湖+数据仓库的部署架构来构建大数据方案，但同时数据湖和数据仓库技术也在逐步发展，向着湖仓一体(LakeHouse)的方向演进。

数据湖Hadoop生态产品

当前数据湖生态中，Hadoop一直是最主流的产品并衍生出了Hive、Spark、Flink、Hudi、Delta lake等相关产品。其共同组成了数据湖生态的关键部分。

Hadoop

Hadoop在架构上主要具有3个组件：MapReduce、Yarn、以及HDFS

· HDFS是一个分布式文件系统，在Hadoop生态中比较重要，是大多数数据湖构建时的首选存储组件。

· MapReduce是一个计算引擎，是Hadoop生态比较原始的计算引擎，性能相较于其他引擎（Spark、Tez）来说较为落后，目前仅适用于离线大批量计算的场景。

· Yarn是一个资源管理器，能够管理Hadoop集群中各服务器的资源，是Hadoop2.x时代新加入的组件，实现了资源调度的解耦，以为后续Hadoop生态使用其他引擎计算提供了基础。在Yarn下，通过ResourceManager调度各节点上的NodeManager进行资源调度，每个节点的NodeManager又通过调度Container来执行任务。

Hive

Hadoop固然能够解决海量数据的存储和计算问题，但其使用成本较高，比如若想调度一个MapReduce程序，需要使用Java、Python等开发语言编写程序才可以，这与SQL这种语言在使用便捷性和通用性上相差甚远。

由此引出了Hive的出现，Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射成一张表，并提供类SQL查询功能。其本质上是可以将用户输入的SQL语言转换成Mapreduce程序运行。可以说Hive具备一切Hadoop的特性，并额外提供了符合用户使用习惯的类SQL语言。

值得注意的是，在原Hadoop中，并没有表的概念，Hive这里引入了表的概念，本质上是虚拟表，在物理上表还是以文件形式存储的。同时对于表的元数据也需要有一个地方进行持久化存储，这就是Hive的MetaStore，一般情况下都使用Mysql作为这个Metastore。

虽然Hive提供了类SQL语言，但其依然是使用MR作为计算引擎，随着数据量的增多和计算的复杂，MR渐渐不能满足一些场景的需要。在2012年的Hive0.9版本，Hive引入了Tez计算引擎（Apache 最新的支持有向无环图（DAG）作业的开源计算框架），Tez 构建在 YARN 之上，它避免了 MapReduce 中作业之间需要借助 HDFS 作为共享数据存储系统的问题，即一个作业将处理好的数据写入 HDFS，下一个作业再从 HDFS 重新读取数据进行处理的方式。Tez 可以让第一个作业直接将数据传递给下游作业，减少了不必要的 I/O 开销。

后续在2014年，Hive又推出了Hive on Spark版本，支持将Spark作为Hive的计算引擎，通过Spark的内存计算特性进一步提升特定场景下的计算性能。Spark同样支持基于Yarn进行资源调度。

Spark

随着数据量的膨胀，MapReduce的计算性能已经满足不了用户的需求，更快速的大数据计算引擎就成为了迫切的需要。Spark是在Hadoop之后出现的大数据分布式计算工具，其基于内存的运算比MR要快100倍以上，是目前比较通用的大数据计算框架。

在使用Spark时支持通过python、Java等程序编写语言对数据文件进行计算，也支持通过Spark SQL来进行调度，并支持通过spark streaming提供流计算功能。

在实际场景应用Spark时，一般会用其来代替MapReduce对数据进行分析计算：

· Hive on Spark模式，通过Hive使用Spark计算引擎进行计算

· Spark on Hive模式，直接调度使用Spark对数据进行计算

Flink

Flink和Spark类似，也是一款分布式计算框架，但其相比于Spark，在流处理上有更强大的功能，是一款真正的流处理引擎（虽然Spark提供了Spark streaming插件，但其是微批实现的流计算）。传统的Mapreduce、tez、Spark都属于批处理、批计算引擎，其更适用于对有界数据的计算和分析，比如离线计算、报表生成、机器学习等；而Flink的流计算特性，更适用于对实时数据的实时计算，比如个性化推荐、监控告警、日志实时分析等。

Flink同样支持使用java、python等语言编写程序调度或是通过Flink sql的方式调度，对流数据进行计算。

Flink也支持基于Yarn进行资源调度，但其尚未和hive融合，也就是不支持通过hive SQL直接调度flink进行计算。

Presto

Presto和hive一样，都是facebook开发并开源的大数据工具产品。presto是一种分布式计算框架，目标同样是解决MR性能慢的问题，其通过一系列配置也可以基于yarn进行资源管理。但其由于功能全面性、生态丰富性等原因，在实际应用中，流行度较spark稍差。

湖仓一体生态产品

随着hadoop技术的不断发展，其基本的存储和计算需求已经得到满足，用户可以使用HDFS作为数据存储组件，可以使用yarn对集群节点进行资源管理，并根据需要使用不同的计算引擎（Spark、flink、presto、MR、Tez）来进行计算，同时可以使用类SQL语言进行命令的下发。

在上述数据湖结构下，主要聚焦于对数据文件计算性能的提升，在事务管理、数据更新、读写性能优化、数据回溯、流计算等方面仍有较大的提升空间。由此引出了Delta lake/ Iceberg/ Hudi等产品，在数据湖的基础上，补足数据仓库的部分特性，实现“湖仓一体”

需要注意的是，Delta lake/ Iceberg/ Hudi都既不提供存储功能，也不提供计算功能，它们只是一个存储框架，优化了数据文件在存储服务上的存储形式，以此来提供事务ACID、数据多版本管理、时间旅行并特性，并通过兼容spark、filnk实现流批一体特性。

Delta Lake

Delta Lake 是databricks公司2019年开源的一个数据湖项目，且“湖仓一体（LakeHouse）”这个概念词也是由Databricks最先基于delta lake打造并提出的，时至今日该概念已经深入人心。

DeltaLake提供 ACID 事务、可扩展的元数据处理，并在现有数据湖（如 S3、ADLS、GCS 和 HDFS）上统一流式处理和批处理数据。

具体而言，Delta Lake 提供：

· Spark 上的 ACID 事务：可序列化的隔离级别可确保读取器永远不会看到不一致的数据。· 可扩展的元数据处理：利用 Spark 分布式处理能力轻松处理包含数十亿个文件的 PB 级表的所有元数据。

· 流批一体：Delta Lake 中的表既是批处理表，也是流式处理源和接收器。流式数据摄取、批量历史数据回填、交互式查询都开箱即用。

· 模式实施：自动处理模式的变化，以防止在数据加载期间插入不良记录。

· 时间旅行：数据版本控制支持回滚、完整的历史审计跟踪和可重现的机器学习实验。

· 更新插入和删除：支持合并、更新和删除操作，以实现复杂的用例，如更改数据捕获、缓慢更改维度 （SCD） 操作、流式更新插入等。

Delta Lake自推出以来，一直是以Spark生态为主，这也导致其在开发性上较Iceberg有所差异，对于使用flink作为计算引擎的用户不太友好。

Iceberg

Iceberg 是由 Netflix 团队研发并开源的数据湖 table format。从功能和发展上看，Iceberg和Delta Lake非常相似，同样支持ACID、时间旅行、模式演化等特性。只不过具体实现机制有所不同。

在Iceberg中，通过表快照机制来实现多版本管理和时间旅行，并支持Hidden Partitioning功能，创建隐藏分区，以及对表进行DDL操作。

Iceberg支持各种计算引擎，Spark、Flink、Presto等，也可通过java api访问iceberg表。

一般原生使用flink计算引擎的用户，都倾向于选择iceberg构建自己的湖仓一体。

这里展开一下，无论是Iceberg还是Delta lake，本质上都是海量文件的组织方式，无法摆脱存储的限制，通常会把它存到内部的HDFS上，云上则会存到对象存储中。但对象存储也有它的限制，吞吐量较大，但延迟会较高。如果需要流读，通常在构建实时链路的时候，会选择消息队列（Kafka），它的存储模型完全不同，是低延迟高响应，顺序读写。它的存储能力决定了计算，流式计算的访问方式和离线计算的访问方式不同。

​编辑

这个时候就会引出两个问题，也是数据湖生态需要不断演进解决的：

· 如何平衡流式的访问和批的访问？既能做到高性能和高效，又能做到低成本？

· 传统的Iceberg和Hudi，实现分钟级已经接近极限，如果继续加速该如何优化？

Hudi

Apache Hudi 是由 Uber 开发并在2017年开源的一个项目，全称为Hadoop Upserts anD Incrementals。顾名思义，其特点有两个，一是能够支持upserts，二是能够支持对增量数据进行查询处理。

Hudi 使用细粒度的文件 / 记录级别索引来支持 Update / Delete 记录，同时还提供写操作的事务保证。查询会处理最后一个提交的快照，并基于此输出结果。

Hudi 对获取数据变更提供了一流的支持：可以从给定的时间点获取给定表中已 updated / inserted / deleted 的所有记录的增量流，并解锁新的查询姿势。

同时Hudi支持MOR和COW两种表格式，来应对不同的应用场景。

仓湖一体

之所以叫仓湖一体，实际上是为了突出仓的重要性，即以仓为轴，实现湖仓一体的特性。刚才介绍的湖仓一体产品，都是以湖为轴，在湖的基础上补足仓的特性，那反过来能不能以仓为轴，在仓的基础上补足湖的特性呢？

Gbase仓湖一体就是从这个角度出发，以核心产品云原生数仓和GBase HD为基础，构建了一个以数据仓库为主，在数据仓库上扩展湖能力的仓湖一体平台，提供统一的数据管理、多模态的存储引擎、流批一体计算、数据全生命周期管理等能力

​编辑

如上图，GBase仓湖一体平台以云原生数仓和GBase HD数据湖为核心进行构建。在数据采集层，支持多样的数据继承方式，可以将各种数据源的业务数据快速接入到存储服务中。

在存储服务层，平台支持HDFS文件存储和S3/OSS对象存储，支持结构化/时序/文档/图像数据存储，可按需冷热分级存储，数据在湖和仓之间可自由流动，实现了企业内数据的统一管理，消除数据隔离。

在计算层，提供了强大的 MPP计算引擎和丰富的Hadoop生态计算引擎（Hive、Spark、Flink等），满足用户在不同场景下计算的需求，实现流批一体。

在服务层，GBase仓湖一体平台对各类计算引擎进行了语言封装，并通过catalog等机制实现了元数据的统一管理、对外提供了统一的调度和访问接口，应用层透明访问、查询各类数据，并自由选择调度的计算引擎，灵活、高效地进行数据清洗、数据分析、机器学习、数据探索等一系列数据价值挖掘操作。

​