数据湖和数据仓库的技术融合催生湖仓一体Data LakeHouse_不同的数据仓库系统可以整合为一个数据湖吗

在过去大概两三年的时间里，数据湖与数据仓库开始出现非常强的相互融合的趋势，各自吸取对方的长处，进入到湖仓一体这样一个时代，已经变成目前的技术热点。

湖仓一体【LakeHouse】是一种新型开放式架构，将数据湖和数据仓库的优势充分结合，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能。

Data Lakehouse试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余

本文针对数据仓库 DataWarehouse、数据湖 DataLake进行对比，进而描述实现湖仓一体的两个流派。最后讲解湖仓一体的特性。

数据处理发展过程如下：

数据湖和数据仓库的对比

方法论等维度对比

按照 5 个维度对比了数据湖和数据仓库体系

• 方法论不同
  • 数据湖是一个文件存储系统，可以往里面放任何一种文件或者数据，典型特点是事后建模，方法论是用户先把数据放上来，然后再考虑如何使用，也叫做 SchemaOnRead。
  • 数据仓库事前建模的模式，在把数据推进数据仓库的时候，要求先 CreateTable/Schema
• 存储的形态不同
  • 数据湖存储的是文件，可以存储所有类型的数据
  • 数据仓库存储的是表（具体表如何存储对用户不可见），是面向结构化关系表达设计的，因此面向 AI 这种非结构化数据，存在很大挑战，它几乎不支持音视图类型的数据。
• 支持的计算引擎不同
  • 数据湖天然是一种更开放的架构，向所有引擎开放，但几乎很难做到非常好的端到端优化。
    如当客户把数据上传到数据湖上，是以行存的 Log 文件格式存储，上层的计算引擎几乎很难做到端到端优化（因为非列存、缺乏统计信息和索引的支持）。
  • 数据仓库是偏端到端的设计，只对特定计算引擎开放，更容易做到端到端的优化
• 启动和维护成本
  • 数据湖是一个存储系统，非常容易上手，启动成本低，但随着数据量的增长，运维管理会越来越困难，所以数据湖最终有可能变成数据沼泽，这是数据湖面临的一个大问题
  • 数据仓库在写入数据前需要事先建模，有整体数据模型的顶层设计，所以启动成本很高，但在日后扩展时的运维和管理成本变得更低
• 数据治理
  • 数据仓库是面向数据文件的，不需要事先建模，缺乏整体的数据模型，很难进行数据治理。
  • 数据仓库是面向结构化数据的，事先建模，有整体数据模型的顶层设计，更容易进行数据治理，产生数据地图和数据血缘关系
    

面向用户等对比

数据湖的痛点

数据湖主要以离线批量计算为主，因为不支持数据仓库的数据管理能力，难以提高数据质量；
数据入湖时效差不支持实时更新，数据无法强一致性；
主题建模不友好，无法直接历史拉链建模；
同时交互分析通常将数据搬迁到数据仓库平台，造成分析链路长，数据冗余存储；
批 &流等场景融合不够，无法满足企业的海量数据处理诉求。

数据仓库的痛点

数据仓库满足不了非结构化数据的分析需求，性价比不高；
同时仓 &湖间难以互联互通，数据协同效率较低，无法支持跨平台透明访问，形成了事实上的数据孤岛，找数困难；
缺乏全局数据视图，不同平台接口差异和不同开发管理工具，造成用户开发使用复杂，
数据分别管理维护代价高体验差。

湖仓一体的流派

现在很多厂商考虑怎么在数据湖上应用更多数据仓库技术，反过来数据仓库厂商也希望用数据湖的技术使自己更开放，这两个技术在互相学习和融合，最终催生了一个新的技术热点：湖仓一体。

所以实现湖仓一体有2个流派：

• 以数据仓库为基础，进化为湖仓一体：
  • 通常湖和仓是左右摆布的，左边是一个数据库，右边是一个数仓，然后数据湖和数仓之间有数据流动，像一个左右结构
  • 如 Databricks，是以数据湖为轴发展起来，更多谈的是从湖向仓怎么走，最终走向湖仓一体
• 以数据湖为基础，进行为湖仓一体：
  • 是在数据湖之上再做一个数仓，像是一个上下结构
  • 如Redshift 、MaxCompute，是以数仓为核心，所以是从数仓向湖上走。

湖仓一体

目标

• 实现“湖里”和“仓里”的数据/元数据能够无缝打通，并且“自由”流动
  • 湖里的“新鲜”数据可以流到仓里，甚至可以直接被数仓使用，
  • 仓里的“不新鲜”数据，流到湖里，低成本长久保存，供未来的数据挖掘使用。
  • 处理数仓内的热数据与数据湖中的历史数据，生成丰富的数据集，全程无需执行任何数据移动操作
  • 生成的新数据集可以插入到数仓中的表内，或者直接插入由数据湖托管的外部表中

关键特征

• 事务支持：在企业中，数据往往要为业务系统提供并发的读取和写入。对事务的ACID支持，可确保数据并发访问的一致性、正确性，尤其是在SQL的访问模式下。
• 数据的模型化和数据治理：Lakehouse 可以支持各类数据模型的实现和转变，支持DW模式架构，例如星型模型、雪花模型等。该系统应当保证数据完整性，并且具有健全的治理和审计机制。
• 报表以及分析应用的支持：报表和分析应用都可以使用这一存储架构。Lakehouse里面所保存的数据经过了清理和整合的过程，它可以用来加速分析。同时相比于数仓，它能够保存更多的数据，数据的时效性也会更高，能显著提升报表的质量
• 存算分离：存算分离的架构，使得系统能够扩展到更大规模的并发能力和数据容量。
• 开放性：采用开放、标准化的存储格式（例如Parquet、ORC等），提供丰富的API支持，因此各种工具和引擎（包括机器学习和Python / R库）可以高效地对数据进行直接访问。
• 支持多种数据类型（从结构化到非结构化）：Lakehouse可为许多应用程序提供数据的入库、转换、分析和访问。数据类型包括图像、视频、音频、半结构化数据和文本等。
• 支持各种工作负载：支持包括数据科学、机器学习、SQL查询、分析等多种负载类型。这些工作负载可能需要多种工具来支持，但它们都由同一个数据库来支撑。
• 端到端流：实时报表已经成为企业中的常态化需求，实现了对流的支持后，不再像以往一样，为实时数据服务构建专用的系统。

落地实例

阿里云湖仓一体的架构

将数据仓库MaxCompute和数据湖EMR

华为云的湖仓一体架构

参考

what-is-a-data-lakehouse