欢迎关注大数据技术架构与案例微信公众号:过往记忆大数据
过往记忆博客公众号iteblog_hadoop
欢迎关注微信公众号:
过往记忆大数据

Data Lakehouse (湖仓一体) 到底是什么

背景

数据湖(Data Lake),湖仓一体(Data Lakehouse)俨然已经成为了大数据领域最为火热的流行词,在接受这些流行词洗礼的时候,身为技术人员我们往往会发出这样的疑问,这是一种新的技术吗,还是仅仅只是概念上的翻新(新瓶装旧酒)呢?它到底解决了什么问题,拥有什么样新的特性呢?它的现状是什么,还存在什么问题呢?

what-is-a-data-lakehouse
如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:iteblog_hadoop

带着这些问题,今天就从笔者的理解,为大家揭开 Data Lakehouse 的神秘面纱,来探一探其技术的本质到底是什么?

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

本文参考自 https://www.xplenty.com/glossary/what-is-a-data-lakehouse/ 和 https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html。

Data Lakehouse具备什么特性?

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

  • 数据仓库数仓这样的一种数据存储架构,它主要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理,并导入到目标表中。在数仓中,数据存储的结构与其定义的schema是强匹配的。
  • 数据湖:数据湖这样的一种数据存储结构,它可以存储任何类型的数据,包括像图片、文档这样的非结构化数据。数据湖通常更大,其存储成本也更为廉价。存储其中的数据不需要满足特定的schema,数据湖也不会尝试去将特定的schema施行其上。相反的是,数据的拥有者通常会在读取数据的时候解析schema(schema-on-read),当处理相应的数据时,将转换施加其上。

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

Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异,通过将数仓构建在数据湖上,使得存储变得更为廉价和弹性,同时lakehouse能够有效地提升数据质量,减小数据冗余。在lakehouse的构建中,ETL起了非常重要的作用,它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。Data Lakehouse概念是由Databricks在此文[1]中提出的,在提出概念的同时,也列出了如下一些特性:

  • 事务支持:Lakehouse可以处理多条不同的数据管道。这意味着它可以在不破坏数据完整性的前提下支持并发的读写事务。
  • Schemas:数仓会在所有存储其上的数据上施加Schema,而数据湖则不会。Lakehouse的架构可以根据应用的需求为绝大多数的数据施加schema,使其标准化。
  • 报表以及分析应用的支持:报表和分析应用都可以使用这一存储架构。Lakehouse里面所保存的数据经过了清理和整合的过程,它可以用来加速分析。同时相比于数仓,它能够保存更多的数据,数据的时效性也会更高,能显著提升报表的质量。
  • 数据类型扩展:数仓仅可以支持结构化数据,而Lakehouse的结构可以支持更多不同类型的数据,包括文件、视频、音频和系统日志。
  • 端到端的流式支持:Lakehouse可以支持流式分析,从而能够满足实时报表的需求,实时报表在现在越来越多的企业中重要性在逐渐提高。
  • 计算存储分离:我们往往使用低成本硬件和集群化架构来实现数据湖,这样的架构提供了非常廉价的分离式存储。Lakehouse是构建在数据湖之上的,因此自然也采用了存算分离的架构,数据存储在一个集群中,而在另一个集群中进行处理。
  • 开放性:Lakehouse在其构建中通常会使Iceberg,Hudi,Delta Lake等构建组件,首先这些组件是开源开放的,其次这些组件采用了Parquet,ORC这样开放兼容的存储格式作为下层的数据存储格式,因此不同的引擎,不同的语言都可以在Lakehouse上进行操作。

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

Data lakehouse解决了什么问题

那说完了Data Lakehouse的特性,它到底解决了什么问题呢?

这些年来,在许多的公司里,数仓和数据湖一直并存且各自发展着,也没有遇到过太过严重的问题。但是仍有一些领域有值得进步的空间,比如:

  • 数据重复性:如果一个组织同时维护了一个数据湖和多个数仓,这无疑会带来数据冗余。在最好的情况下,这仅仅只会带来数据处理的不高效,但是在最差的情况下,它会导致数据不一致的情况出现。Data Lakehouse统一了一切,它去除了数据的重复性,真正做到了Single Version of Truth。
  • 高存储成本:数仓和数据湖都是为了降低数据存储的成本。数仓往往是通过降低冗余,以及整合异构的数据源来做到降低成本。而数据湖则往往使用大数据文件系统(譬如Hadoop HDFS)和Spark在廉价的硬件上存储计算数据。而最为廉价的方式是结合这些技术来降低成本,这就是现在Lakehouse架构的目标。
  • 报表和分析应用之间的差异:报表分析师们通常倾向于使用整合后的数据,比如数仓或是数据集市。而数据科学家则更倾向于同数据湖打交道,使用各种分析技术来处理未经加工的数据。在一个组织内,往往这两个团队之间没有太多的交集,但实际上他们之间的工作又有一定的重复和矛盾。而当使用Data Lakehouse后,两个团队可以在同一数据架构上进行工作,避免不必要的重复。
  • 数据停滞(Data stagnation):在数据湖中,数据停滞是一个最为严重的问题,如果数据一直无人治理,那将很快变为数据沼泽。我们往往轻易的将数据丢入湖中,但缺乏有效的治理,长此以往,数据的时效性变得越来越难追溯。Lakehouse的引入,对于海量数据进行catalog,能够更有效地帮助提升分析数据的时效性。
  • 潜在不兼容性带来的风险:数据分析仍是一门兴起的技术,新的工具和技术每年仍在不停地出现中。一些技术可能只和数据湖兼容,而另一些则又可能只和数仓兼容。Lakehouse灵活的架构意味着公司可以为未来做两方面的准备。

Data Lakehouse存在的问题 现有的Lakehouse架构仍存在着一些问题,其中最为显著的是:

  • 大一统的架构:Lakehouse大一统的架构有许多的优点,但也会引入一些问题。通常,大一统的架构缺乏灵活性,难于维护,同时难以满足所有用户的需求,架构师通常更倾向于使用多模的架构,为不同的场景定制不同的范式。
  • 并非现有架构上本质的改进:现在对于Lakehouse是否真的能够带来额外的价值仍存在疑问。同时,也有不同的意见 - 将现有的数仓、数据湖结构与合适的工具结合 - 是否会带来类似的效率呢?
  • 技术尚未成熟:Lakehouse技术当前尚未成熟,在达到上文所提的能力之前仍有较长的路要走。

本文原文:Data Lakehouse (湖仓一体) 到底是什么

本博客文章除特别声明,全部都是原创!
原创文章版权归过往记忆大数据(过往记忆)所有,未经许可不得转载。
本文链接: 【Data Lakehouse (湖仓一体) 到底是什么】(https://www.iteblog.com/archives/9905.html)
喜欢 (7)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!