【数据湖仓架构】数据湖和仓库:范式简介

简介: 【数据湖仓架构】数据湖和仓库:范式简介

是时候将数据分析迁移到云端了——您选择数据仓库还是数据湖解决方案?了解这两种方法的优缺点。


数据分析平台正在转向云环境,例如亚马逊网络服务、微软 Azure 和谷歌云。

云环境提供了多种好处,例如可扩展性、可用性和可靠性。此外,云提供商有大量的原生组件可供构建。还有多种第三方工具可供选择,其中一些是专门为云设计的,可通过云市场获得。

工具自然倾向于强调自己在分析集成中的作用。当您尝试选择最佳工具集时,这通常会令人困惑。在这篇文章中,我们将详细介绍许多工具的优缺点。

这是一个由三部分组成的系列文章的第一篇,我们评估了基于数据仓库和数据湖的解决方案的基本方法或范式的差异。

博客系列

 

  • 数据湖和仓库第 1 部分:范式简介
  • 数据湖和仓库第 2 部分:Databricks 和雪花
  • 数据湖和仓库第 3 部分:Azure Synapse 观点

两种范式:数据湖与数据仓库

基于一些主要组件的选择,云分析解决方案可以分为两类:数据湖和数据仓库。简而言之,数据仓库解决方案传统上是集中式的,而数据湖解决方案则分散到核心。这两种方法都有其优势,并且通常用于略有不同的目的。如今,产品具有这两个类别的典型特征是很常见的。即便如此,产品仍然展示其原始类别及其观点。

让我们将这种基本类别方法称为范式。理解范式的基本哲学有助于理解全局。

在这篇文章中,我们深入挖掘了范式的特征和差异。我们首先将分析平台划分为典型的组件阶段。在此之后,我们讨论从两种范式的角度选择组件的方法。

在本系列的下一篇文章中,我们将讨论如何在一些流行的产品中看到范式。

数据分析平台通常根据它们所涵盖的过程部分分为多个阶段。典型的批量数据流水线平台如上图所示。但是,文章分析也适用于实时平台。这些工具可以从处理(绿色)或存储(蓝色)的角度进行分类。下面的工具行对应于它们在平台不同阶段的可用性。

例如,典型的数据湖解决方案由单独的处理和存储工具组成。在数据仓库的情况下,一个单一的解决方案通常同时兼顾处理和存储功能。让我们更清楚一点。

从处理(绿色)的角度来看,数据平台阶段是:

  • 摄取 (Ingest )- 使用 API 接口或 ELT/ETL 工具从源系统读取数据
  • 准备(Prepare)——数据将进行初步清理和检查
  • 转换和丰富(Transform & Enrich)——根据用例丰富和修改数据
  • 服务 (Serve)- 准备好的数据提供给选择的工具以供实际使用
  • 可视化和报告(Visualize & Report )——信息以可视化或报告的形式提供给最终用户

此外,大数据世界的当前趋势是根据应用的处理级别将数据存储在多个层中。数据存储层(蓝色)通常至少包括:

  • 原始(也称为青铜)——未处理的源数据,按原样存储
  • 精炼(银)——经过初步清理和标准化的质量验证数据。数据通常尚未修剪。
  • 已发布(金)——经过处理、组合和丰富的数据。通常,数据也已针对特定用例进行聚合和修剪。

数据存储层的确切覆盖范围因源而异,但此处的细节无关紧要。但是,重要的是要注意,尤其是在银层和金层中,数据可以存储不止一次。例如,黄金层通常为不同的使用场景提供多个版本的数据。

比较数据分析平台

传统上,数据分析平台是用于公司报告目的的解决方案。对于这个用例,基于关系数据库的数据仓库是事实上的标准。但是,数据仓库不太适合处理新类型的数据,通常称为大数据。问题是由于数据量、实时要求和类型多样性造成的,其中包括非结构化和半结构化数据。为了补充工具集,在过去十年左右开发了数据湖类型的解决方案。

根据 Wikipedia 中的一个非常广泛的定义,数据湖是一种可以以原始形式存储数据的解决方案。一般来说,这意味着任何文件格式的潜在存储容量都是无限的。在实践中,该术语还涵盖处理存储数据的工具。


市场上倾向于将产品展示为“整体数据湖解决方案”。通常他们是对的:理论上,即使是具有大硬盘驱动器的虚拟机也能让有能力的编码人员创建数据湖解决方案。自然,这种极简主义的定义不是很有用。

相反,考虑范式的差异更有意义:数据仓库的基本原则和基于数据湖的解决方案。

数据仓库:以有组织的结构提供的已清理数据

对于数据仓库范式,基本方法是提供一个集中式产品,使数据能够存储在有组织的层次结构中,通常以数据库表的形式。该解决方案包括表之间的外键引用细粒度数据加密详细的用户访问管理等内容。对数据的访问主要通过特定的数据仓库产品处理,通常使用 SQL 语言。

数据仓库范式的优点是能够定义向用户提供的数据和格式。通常,数据以经过处理和干净的格式提供。例如,这样我们就可以保证数据的有效性。此外,源系统和数据的变化至少在某种程度上对用户是隐藏的。

另一方面,作为限制,我们依赖单一的产品供应商。例如,只能以产品支持的方式从数据仓库解决方案中检索数据。此外,我们需要以一种或另一种方式为数据的检索付费。数据仓库解决方案也可能成为数据处理的资源瓶颈。最近,在解决后一个限制方面取得了重大进展。

数据湖:去中心化带来的自由

数据湖范式的核心原则是责任分散。借助大量工具,任何人都可以在访问管理的范围内使用任何数据层中的数据:青铜、白银和黄金。组织数据和表的关系是可以的,但是通常不强制使用,我们可以很容易地绕过它们。

数据湖解决方案的一个主要优势是计算和处理工具的去中心化数据科学家可以在自己的机器上使用青铜层数据进行 Python 图像分析,数据工程师可以使用 Apache Spark 修改银层数据,分析师可以通过报告工具利用黄金层数据。SQL 语言通常作为一种可能性提供。此外,计算是分散的,几乎没有瓶颈。


数据湖范式解决方案的一个主要弱点是缺乏数据组织,包括集中的元数据存储库。如果由于纠错或源系统修改而导致处理的数据更改,则可能非常难以跟踪。此外,不能始终保证数据的有效性或结构集中式数据湖元数据管理工具越来越多,但使用它们取决于开发过程。技术很少强制这样做。

结论:数据湖和数据仓库

在这篇文章中,我们讨论了数据仓库和基于数据湖的解决方案的基本方法或范式的差异。基于数据仓库的解决方案通常是集中式的,而数据湖解决方案则分散到核心。然而,这两个类别的工具都在发展,并且划分变得越来越不清晰。然而,理解范式方法有助于理解全局。

原则上,您可以纯粹在数据湖或基于数据仓库的解决方案上构建云数据分析平台

我见过大量基于数据湖工具的功能齐全的平台。在这些情况下,可以使用特定于用例的数据库数据集市来提供信息,而根本不需要数据仓库。

另一方面,也有成功的解决方案,其中整个平台都建立在数据仓库产品之上。数据直接读入数据仓库,在那里进行处理和服务。


但是,由于此处解释的差异,基于其中一种范例的解决方案不一定在所有情况下都是最佳的。他们的优势和基本理念是不同的。在处理青铜级和白银级数据时,在早期阶段利用基于数据湖的方法可能是有意义的。然后可以将数据存储在数据仓库中,以进一步组织成白银和黄金数据。通过这种方式,所有数据既可以用于快速实验的原始格式,也可以用于报告的结构格式。

这样,我们可以利用这两种方法的优势。


原文https://architect.pub/data-lakes-and-warehouses-intro-paradigms

相关实践学习
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
5月前
|
存储 机器学习/深度学习 数据采集
一文讲透数据仓库、数据湖、数据海的区别
企业常因数据架构不清导致报表延迟、数据矛盾、利用困难。核心解法是构建数据仓库(高效分析)、数据湖(灵活存储原始数据)和数据海(全局集成)。三者各有适用场景,需根据业务需求选择,常共存互补,助力数据驱动决策。
一文讲透数据仓库、数据湖、数据海的区别
|
5月前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
556 0
存储 数据采集 大数据
166 0
|
6月前
|
存储 人工智能 分布式计算
数据不用搬,AI直接炼!阿里云AnalyticDB AI数据湖仓一站式融合AI+BI
阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL版(以下简称ADB)诞生于高性能实时数仓时代,实现了PB级结构化数据的高效处理和分析。在前几年,为拥抱大数据的浪潮,ADB从传统数仓拓展到数据湖仓,支持Paimon/Iceberg/Delta Lake/Hudi湖格式,为开放的数据湖提供数据库级别的性能、可靠性和管理能力,从而更好地服务以SQL为核心的大规模数据处理和BI分析,奠定了坚实的湖仓一体基础。
|
7月前
|
SQL 存储 运维
别让运维数据“各过各的”:聊聊数据湖怎么搭,才能不成“沼泽”
别让运维数据“各过各的”:聊聊数据湖怎么搭,才能不成“沼泽”
260 0
|
7月前
|
存储 SQL 监控
数据中台架构解析:湖仓一体的实战设计
在数据量激增的数字化时代,企业面临数据分散、使用效率低等问题。数据中台作为统一管理与应用数据的核心平台,结合湖仓一体架构,打通数据壁垒,实现高效流转与分析。本文详解湖仓一体的设计与落地实践,助力企业构建统一、灵活的数据底座,驱动业务决策与创新。
|
10月前
|
SQL 分布式数据库 Apache
网易游戏 x Apache Doris:湖仓一体架构演进之路
网易游戏 Apache Doris 集群超 20 个 ,总节点数百个,已对接内部 200+ 项目,日均查询量超过 1500 万,总存储数据量 PB 级别。
935 3
网易游戏 x Apache Doris:湖仓一体架构演进之路
|
11月前
|
SQL 缓存 分布式计算
vivo 湖仓架构的性能提升之旅
聚焦 vivo 大数据多维分析面临的挑战、StarRocks 落地方案及应用收益。 在 **即席分析** 场景,StarRocks 使用占比达 70%,查询速度提升 3 倍,P50 耗时从 63.77 秒缩短至 22.30 秒,查询成功率接近 98%。 在 **敏捷 BI** 领域,StarRocks 已完成 25% 切换,月均查询成功数超 25 万,P90 查询时长缩短至 5 秒,相比 Presto 提升 75%。 在 **研发工具平台** 方面,StarRocks 支持准实时数据查询,数据可见性缩短至 3 分钟,查询加速使 P95 延迟降至 400 毫秒,开发效率提升 30%。
vivo 湖仓架构的性能提升之旅
|
11月前
|
存储 缓存 Apache
小红书湖仓架构的跃迁之路
小红书研发工程师李鹏霖(丁典)在StarRocks年度峰会上分享了如何通过结合StarRocks和Iceberg实现极速湖仓分析架构。新架构使P90查询性能提升了3倍,查询响应时间稳定在10秒以内,存储空间减少了一半。RedBI自助分析平台支持灵活、快速的即席查询,优化了排序键和Join操作,引入DataCache功能显著提升查询性能。未来将探索近实时湖仓分析架构,进一步优化处理能力。
|
11月前
|
SQL 消息中间件 Serverless
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
359 4