一、什么是数据湖

        对于经常跟数据打交道的同学，初步听到数据湖这个概念的时候，肯定有点懵，但是相信大家对于数据仓库 这个概念并不陌生。

        到了20世纪80年代以后，基于关系型数据库的事务处理成为了企业IT应用的主流。在这个阶段，企业的IT应用主要还是着重于业务职能的自动化及信息的存储、汇总、统计、查询等方面，而分析能力是比较薄弱的，因此这样的信息处理模式称之为事务处理。进而，在网络应用和实时交互处理功能日益强大和普遍的今天，基于在线计算的事务处理被称之为在线事务处理（OLTP）。OLTP是事务处理从单机到网络环境发展的新阶段。

        OLTP的特点在于事务处理量大，但事务处理的内容比较简单且重复率高。大量的数据操作主要涉及的是增加、删除、修改和查询等操作。OLTP在查找业务数据时是非常有效的，但是在为决策者提供决策分析时显得力不从心。

        事务处理和OLTP系统主要解决业务自动化和信息查询的基本需求，是基于业务数据库实现的，然而在数据资源开发与利用的分析处理层次上，人们要求信息系统剧透对多方面数据进行综合性分析的能力，这就要求建立一个面向分析、集成保存大量历史数据的新型数据管理机制，这一机制就是数据仓库。数据仓库为数据分析处理提供了基础数据，而分析处理利用多种运算手段，对数据仓库所提供的数据进行面向管理决策的统计、展示和预测。

        说完OLTP，再说OLAP，即在线分析处理。事实上，OLAP能够高速发展也得益于数据仓库技术的出现和完善。由于这两者结合的比较紧密，以至于在实际应用中，OLAP应用和数据仓库应用经常指同一个概念。所谓数据仓库，就是把一个组织中的历史数据收集到一个中央仓库中以便处理，它是支持决策过程的、面向主题的、集成的、随时间变化的、持久的数据集合，是当今信息管理中的主流趋势之一。

        数据仓库通常存储来自不同源的数据，集成源数据以提供统一的视图。这些资源可以包括事务系统、应用程序日志文件、关系数据库等等。

        随着当前大量信息化发展和电子设备产品普及，产生大量的照片、视频、文档等非结构化数据，人们也想通过大数据技术找到这些数据的关系。随之而来的数据湖就产生了。

        数据湖 概念首次于2010年被James Dixon在其博客帖子（Pentaho, Hadoop, and Data Lakes | James Dixon's Blog）中提及 ：

        该篇文章大体的含义就是说，传统的数据意义上80-90% 的公司正在处理结构化或半结构化数据（不是非结构化数据）。数据源通常是单个应用程序或系统。数据通常是子事务性或非事务性的。但是随着数据量的日益增长，并且不同种类的增加，如果预先将他们都聚合到数据仓库中，这样下去就会失去对最低级别数据的可见性，并且这些预聚合好的数据也只能回答预先确定的问题，而没办法去预见一些未来的数据问题。

        所以针对以上问题呢，提出了一个数据湖的感念，如果将数据仓库视为瓶装水的商店——经过清洁、包装和结构化以便于饮用——那么数据湖就是处于更自然状态的一大片水体。数据湖的内容从源头流入，填满湖，湖的各种用户可以来检查、潜入或取样。

        数据湖的权威定义（来自维基百科）：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。

        数据湖是一个存储库，它允许存储大量的原始数据，也就是说，没有按照特定的模式进行准备、处理或操作的数据。

        数据湖的一个关键特征是不会拒绝任何数据，这意味着结构化格式和非结构化数据格式都可以存储。由于数据湖中的数据在从源获取时不受数据结构的约束，因此在需要时应用“读取”模式来促进数据分析。

二、数仓和数据湖的对比

特性	数据仓库	数据湖
数据	来自事务系统、运营数据库和业务线应用程序的关系数据	来自 IoT 设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据
Schema	设计在数据仓库实施之前（写入型 Schema）	写入在分析时（读取型 Schema）
性价比	更快查询结果会带来较高存储成本	更快查询结果只需较低存储成本
数据质量	可作为重要事实依据的高度监管数据	任何可以或无法进行监管的数据（例如原始数据）
用户	业务分析师	数据科学家、数据开发人员和业务分析师（使用监管数据）
分析	批处理报告、BI 和可视化	机器学习、预测分析、数据发现和分析

三、数据湖特征

数据湖具有以下特点：

a) 容量大

数据湖汇 聚吸收各个业务数据源流，容纳散落在各处的数据，理论上，存储空间巨大。

b) 格式多

数据湖架构面向多数据源的信息存储，可以快 速高效地采集、存储、处理大量来源不同、格式不同 的原始数据，这其中包括文本、图片、视频、音频、网 页等各类无序的非结构化数据，能把不同种类的数 据汇聚存储在一起，并对汇聚后的数据进行管理， 建立数据之间的关联关系，具有很强的兼容性。

c) 处理速度快

数据湖技术能将各类原始数据快速转化为可 以直接提取的、分析、使用的标准格式，统一优化数 据结构并对数据进行分类存储，根据业务需求，对 存储的数据进行快速的查询、挖掘、关联和处理，并实时传输给末端用户。

d) 体系结构

由于Hadoop也能基于分布式文件系统来存储处理多类型数据，因此许多人认为Hadoop的工作机理就是数据湖的处理机制。当然，Hadoop基于其分布式、可横向扩展的文件系统架构，可以管理和处理海量数据，但是它无法提供数据湖所需要的复杂元数据管理功能，最直观的表现是，数据湖的体系结构表明数据湖是由多个组件构成的生态系统，而Hadoop仅仅提供了其中的部分组件功能。

四、未来的发展趋势

        说了这么多的数据湖的特点和好处，那是不是就可以完全摒弃数据仓库转而搞数据湖了呢？其实结果并不尽然，当下数据湖的概念还处在多方研究探索阶段，但是当下有一个比较火的方案可以参考建设，那就是数据仓库和数据湖合起来建设，统一称之为“湖仓一体”。

五、什么是“湖仓一体”

        Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。那么何为Data Lakehouse呢，它具备些什么特性呢？

一直以来，我们都在使用两种数据存储方式来架构数据：

数据仓库：数仓这样的一种数据存储架构，它主要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理，并导入到目标表中。在数仓中，数据存储的结构与其定义的schema是强匹配的。

数据湖：数据湖这样的一种数据存储结构，它可以存储任何类型的数据，包括像图片、文档这样的非结构化数据。数据湖通常更大，其存储成本也更为廉价。存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上。相反的是，数据的拥有者通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上。

现在许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有一定的冗余。

Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。

Data Lakehouse概念是由Databricks提出的，在提出概念的同时，也列出了如下一些特性：

• 事务支持：Lakehouse可以处理多条不同的数据管道。这意味着它可以在不破坏数据完整性的前提下支持并发的读写事务。

• Schemas：数仓会在所有存储其上的数据上施加Schema，而数据湖则不会。Lakehouse的架构可以根据应用的需求为绝大多数的数据施加schema，使其标准化。

• 报表以及分析应用的支持：报表和分析应用都可以使用这一存储架构。Lakehouse里面所保存的数据经过了清理和整合的过程，它可以用来加速分析。同时相比于数仓，它能够保存更多的数据，数据的时效性也会更高，能显著提升报表的质量。

• 数据类型扩展：数仓仅可以支持结构化数据，而Lakehouse的结构可以支持更多不同类型的数据，包括文件、视频、音频和系统日志。

• 端到端的流式支持：Lakehouse可以支持流式分析，从而能够满足实时报表的需求，实时报表在现在越来越多的企业中重要性在逐渐提高。

• 计算存储分离：我们往往使用低成本硬件和集群化架构来实现数据湖，这样的架构提供了非常廉价的分离式存储。Lakehouse是构建在数据湖之上的，因此自然也采用了存算分离的架构，数据存储在一个集群中，而在另一个集群中进行处理。

• 开放性：Lakehouse在其构建中通常会使Iceberg，Hudi，Delta Lake等构建组件，首先这些组件是开源开放的，其次这些组件采用了Parquet，ORC这样开放兼容的存储格式作为下层的数据存储格式，因此不同的引擎，不同的语言都可以在Lakehouse上进行操作。

Lakehouse的概念最早是由Databricks所提出的，而其他的类似的产品有Azure Synapse Analytics。Lakehouse技术仍然在发展中，因此上面所述的这些特性也会被不断的修订和改进。

六、湖仓一体化有什么好处？

湖仓一体能发挥出数据湖的灵活性与生态丰富性，以及数据仓库的成长性与企业级能力。帮助企业建立数据资产、实现数据业务化、进而推进全线业务智能化，实现数据驱动下的企业数据智能创新，全面支撑企业未来大规模业务智能落地。其主要优势主要有以下几个方面：

数据重复性：如果一个组织同时维护了一个数据湖和多个数据仓库，这无疑会带来数据冗余。在最好的情况下，这仅仅只会带来数据处理的不高效，但是在最差的情况下，它会导致数据不一致的情况出现。湖仓一体的结合，能够去除数据的重复性，真正做到了唯一。

高存储成本：数据仓库和数据湖都是为了降低数据存储的成本。数据仓库往往是通过降低冗余，以及整合异构的数据源来做到降低成本。而数据湖则往往使用大数据文件系统和Spark在廉价的硬件上存储计算数据。湖仓一体架构的目标就是结合这些技术来最大力度降低成本。

报表和分析应用之间的差异：数据科学倾向于与数据湖打交道，使用各种分析技术来处理未经加工的数据。而报表分析师们则倾向于使用整合后的数据，比如数据仓库或是数据集市。而在一个组织内，往往这两个团队之间没有太多的交集，但实际上他们之间的工作又有一定的重复和矛盾。而当使用湖仓一体架构后，两个团队可以在同一数据架构上进行工作，避免不必要的重复。

数据停滞：在数据湖中，数据停滞是一个最为严重的问题，如果数据一直无人治理，那将很快变为数据沼泽。我们往往轻易的将数据丢入湖中，但缺乏有效的治理，长此以往，数据的时效性变得越来越难追溯。湖仓一体的引入，对于海量数据进行治理，能够更有效地帮助提升分析数据的时效性。

潜在不兼容性带来的风险：数据分析仍是一门兴起的技术，新的工具和技术每年仍在不停地出现中。一些技术可能只和数据湖兼容，而另一些则又可能只和数据仓库兼容。湖仓一体的架构意味着为两方面做准备。

七、为什么是Hudi？

         打开Hudi的官网，映入眼帘的是“Apache Hudi通过分布式文件系统——HDFS或者云存储”来摄取、管理大型分析型数据集。也就是Hudi是可以借助于HDFS之上，提供了一些提取、管理功能。

这是Hudi数据湖的基础架构。

简单解释下：

1. 通过Kafka、Sqoop、DeltaStreammer、Flink、Spark等工作，将数据摄取到数据湖的数据存储，例如：我们可以使用HDFS作为数据湖的数据存储
2. 基于HDFS可以构建Hudi的数据湖
3. Hudi提供统一的访问Spark数据源
4. 外部通过不同引擎，例如：Spark、Presto、Hive、Impala、Aliyun DLA、AWS Redshit访问接口

Hudi提供的功能

• 支持使用索引方式Upsert
• 可以原子性的发布数据并支持回滚
• 写入和查询使用快照进行隔离，保证数据的一致性
• 可以用用Savepoint进行数据恢复
• 支持基于统计数据管理文件大小和分布
• 支持对基于行、列的数据进行异步压缩
• 支持时间轴元数据进行数据血统追踪

可以说，Hudi支持了数据湖的数据存储以及一定的管理功能。

Github热度对比Delta Lake

Hudi很自信地把GITHUB的Star、Fork、Watch放上了官网。

对比下Delta Lake

看Watch，我们可以知道Hudi的关注度是很高的。再对比一下PR、和commit。

Hudi

Delta Lake

接下来我即将讲解下如何本地部署一套Flink-Hudi-Spark体系的开发环境

从0到1搭建数据湖Hudi环境_一个数据小开发的博客-CSDN博客

文章引用：

https://mp.weixin.qq.com/s/__t6ZTKfw62Wehzw2ekioA

https://new.qq.com/omn/20210913/20210913A01ZY100.html

欢迎大家关注下本人的微信公众号，将会每周一更大数据相关的一些技术。(微信公众号：睡前大数据 ， 睡前享文|干货|何为实时计算，使用场景有哪些，目前主流的框架有哪些？)