数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi

2年前 (2022) 程序员胖胖胖虎阿
232 0 0

一、什么是数据湖

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

        到了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)中提及 :

数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi

        该篇文章大体的含义就是说,传统的数据意义上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

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

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

数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是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放上了官网。

数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi

对比下Delta Lake

数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi

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

Hudi

数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi

Delta Lake

数据湖基本概念--什么是数据湖,数据湖又能干什么?为什么是Hudi

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

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

文章引用:

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

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

相关文章

暂无评论

暂无评论...