Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说
数据湖基本概念--什么是数据湖，数据湖又能干什么？为什么是Hudi,希望能够帮助你!!!。

一、什么是数据湖

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

        到了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）和二进制数据（如图形、音频、视频）。

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

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

二、数仓和数据湖的对比

三、数据湖特征

数据湖具有以下特点：

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..com/s/__t6ZTKfw62Wehzw2ekioA

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

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

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。