详解数据仓库数据湖及湖仓一体

详解数据仓库数据湖及湖仓一体

随着近几年数据湖概念的兴起，业界对于数据仓库和数据湖的对比甚至

争论就一直不断。有人说数据湖是下一代大数据平台，各大云厂商也在

纷纷的提出自己的数据湖解决方案，一些云数仓产品也增加了和数据湖

联动的特性。

但是数据仓库和数据湖的区别到底是什么，是技术路线之争？是数据管

理方式之争？二者是水火不容还是其实可以和谐共存，甚至互为补充？

本文作者来自阿里巴巴计算平台部门，深度参与阿里巴巴大数据/数据中

台领域建设，将从历史的角度对数据湖和数据仓库的来龙去脉进行深入

剖析，来阐述两者融合演进的新方向一一湖仓一体，并就基于阿里云

MaxCompute/EMRDataLake的湖仓一体方案做一介绍。

01大数据领域发展20年的变与不变

1.1概述

大数据领域从本世纪初发展到现在，已经历20年。从宏观层面观察其中

的发展规律，可以高度概括成如下五个方面：

1.数据保持高速增长-从5V核心要素看，大数据领域保持高速增长。

阿里巴巴经济体，作为一个重度使用并着力发展大数据领域的公司，过

去5年数据规模保持高速增长（年化60%-80%）,增速在可见的未来

继续保持。对于新兴企业，大数据领域增长超过年200%。

2.大数据作为新的生产要素，得到广泛认可-大数据领域价值定位的迁

移，从"探索"到"普惠"，成为各个企业/政府的核心部门，并承担关键任

务。还是以阿里巴巴为例，30%的员工直接提交大数据作业。随大数据

普惠进入生产环境，可靠性、安全性、管控能力、易用性等企业级产品

力增强。

3.数据管理能力成为新的关注点-数仓（中台）能力流行起来，如何用

好数据成为企业的核心竞争力。

4.引擎技术进入收敛期-随着Spark（通用计算）、Flink（流计

算）、Hbase（KV）、Presto（交互分析）、ElasticSearch（搜

索）、Kafka（数据总线）自从2010-2015年逐步占领开源生态，最近

5年新引擎开源越来越少，但各引擎技术开始向纵深发展（更好的性

能、生产级别的稳定性等）O

5.平台技术演进出两个趋势，数据湖VS数据仓库-两者均关注数据存

储和管理（平台技术），但方向不同。

大数据作为新的生产要素，得到广泛认可，在可见的未来,规模保持高速增长

BigDatahasbeenwellreoognaedasnewessentialretourcoandthevolumeofB«gDatagrowsrapidly

Bigdataisdatasetsthataresovoluminousandcomplexthat

traditionaldate-processingapplicationsoftwareareinadequate

todealwiththem.

Volume-数据量

Variety-数据类型

Velocity-数据存储和计算的增长速度

Veracity-信吸比(soweneedtoMINEdata)

Value-价宿

超大规堰低成本直力.

以及数据上的快速迭代是双n成功的前提

图1.阿里巴巴双十一单日处理数据量增长

1.2从大数据技术发展看湖和仓

首先，数据仓库的概念出现的要比数据湖早的多，可以追溯到数据库为

王的上世纪90年代。因此，我们有必要从历史的脉络来梳理这些名词

出现的大概时间、来由以及更重要的背后原因。大体上，计算机科学领

域的数据处理技术的发展，主要分为四个阶段：

1.阶段一：数据库时代。数据库最早诞生于20世纪的60年代，今天

人们所熟知的关系型数据库则出现在20世纪70年代，并在后续的30

年左右时间里大放异彩，诞生了很多优秀的关系型数据库，如Oracle、

SQLServer.MySQL、PostgresSQL等，成为当时主流计算机系统不

可或缺的组成部分。到20世纪90年代，数据仓库的概念诞生。

此时的数据仓库概念更多表达的是如何管理企业中多个数据库实例的方

法论，但受限于单机数据库的处理能力以及多机数据库（分库分表）长

期以来的高昂价格，此时的数据仓库距离普通企业和用户都还很遥远。

人们甚至还在争论数据仓库（统一集中管理）和数据集市（按部门、领

域的集中管理）哪个更具可行性。

2.阶段二：大数据技术的「探索期」。时间进入到2000年附近，随着

互联网的爆发，动辄几十亿、上百亿的页面以及海量的用户点击行为，

开启了全球的数据量急剧增加的新时代。

传统的数据库方案再也无力以可接受的成本提供计算力，巨大的数据处

理需求开始寻找突破口，大数据时代开始萌芽。2003、2004、2006年

Google先后3篇经典论文（GFS、MapReduce.BigTable）奠基了

这个大数据时代的基本技术框架，即分布式存储、分布式调度以及分布

式计算模型。

随后，几乎是在同一时期，诞生了包括Google,微软Cosmos以及开

源Hadoop为代表的优秀分布式技术体系，当然，这其中也包括阿里巴

巴的飞天系统。此时人们兴奋于追求数据的处理规模，即『大』数据，

没有闲暇争论是数据仓库还是数据湖。

3.阶段三：大数据技术的I■发展期」。来到21世纪的第二个10年，

随着越来越多的资源投入到大数据计算领域，大数据技术进入一个蓬勃

发展的阶段，整体开始从能用转向好用。

代替昂贵的手写MapReduce作业的，则是如雨后春笋般出现的各种以

SQL为表达的计算引擎。这些计算引擎针对不同的场景进行针对性优

化，但都采用门槛极低的SQL语言，极大降低了大数据技术的使用成

本，数据库时代人们梦想的大一统的数据仓库终于成为现实，各种数据

库时代的方法论开始抬头。这个时期技术路线开始出现细分。

云厂商主推的如AWSRedshift、GoogleBigQuery、

Snowflake,包括MaxCompute这样的集成系统称为大数据时代的

数据仓库。而以开源Hadoop体系为代表的的开放式HDFS存储、开

放的文件格式、开放的元数据服务以及多种引擎（Hive、Presto.

Spark、Flink等）协同工作的模式，则形成了数据湖的雏形。

4.阶段四：大数据技术「普及期」。当前，大数据技术早已不是什么火

箭科技，而已经渗透到各行各业，大数据的普及期已经到来。市场对大

数据产品的要求，除了规模、性能、简单易用，提出了成本、安全、稳

定性等更加全面的企业级生产的要求。

•开源Hadoop线，引擎、元数据、存储等基础部件的迭代更替进

入相对稳态，大众对开源大数据技术的认知达到空前的水平。一方

面，开放架构的便利带来了不错的市场份额，另一方面开放架构的

松散则使开源方案在企业级能力构建上遇到瓶颈，尤其是数据安

全、身份权限强管控、数据治理等方面，协同效率较差（如

Ranger作为权限管控组件、Atlas作为数据治理组件，跟今天的

主流引擎竟然还无法做到全覆盖）。同时引擎自身的发展也对已有

的开放架构提出了更多挑战，DeltaLake、Hudi这样自闭环设计

的出现使得一套存储、一套元数据、多种引擎协作的基础出现了某

种程度的裂痕。

•真正将数据湖概念推而广之的是构筑了一套以为

AWSOAWSS3

中心化存储、Glue为元数据服务，E-M叩Reduce、Athena为引

擎的开放协作式的产品解决方案。它的开放性和和开源体系类似，

并在2019年推出LakeFormation解决产品间的安全授信问题。

虽然这套架构在企业级能力上和相对成熟的云数据仓库产品相去甚

远，但对于开源技术体系的用户来说，架构相近理解容易，还是很

有吸引力。AWS之后,各个云厂商也纷纷跟进数据湖的概念，并

在自己的云服务上提供类似的产品解决方案。

•云厂商主推的数据仓库类产品则发展良好，数仓核心能力方面持续

增强。性能、成本方面极大提升（MaxCompute完成了核心引擎

的全面升级和性能跳跃式发展，连续三年刷新TPCx-BigBench世

界记录），数据管理能力空前增强（数据中台建模理论、智能数

仓），企业级安全能力大为繁荣（同时支持基于ACL和基于规则

等多种授权模型，列级别细粒度授权，可信计算，存储加密，数据

脱敏等），在联邦计算方面也普遍做了增强，一定程度上开始将非

数仓自身存储的数据纳入管理，和数据湖的边界日益模糊。

综上所述，数据仓库是个诞生于数据库时代的概念，在大数据时代随云

厂商的各种数仓服务落地开花，目前通常指代云厂商提供的基于大数据

技术的一体化服务。而数据湖则脱胎于大数据时代开源技术体系的开放

设计，经过AWS整合宣传，通常是由一系列云产品或开源组件共同构

成大数据解决方案。

【敷据阵时代】大数据技术【探索期】大败据技术【发展期】大数据技术【皆■期】

«且取网的澧亲以公布式澈t的a为*心的,打利庚在开武也重，分布式计.・Bttt开■也1检入企业生产04曲■力工Mt.安生.»

行.能做内的素嫉imRgt本大"r«向■.。布mtnarasMapRrd火。用例HS分箱体向giant9.««MSttV.dlIMRfl4>f9«tt

02什么是数据湖

近几年数据湖的概念非常火热，但是数据湖的定义并不统一，我们先看

下数据湖的相关定义。

Wikipedia对数据湖的定义：

数据湖是指使用大型二进制对象或文件这样的自然格式储存数据的系

统。它通常把所有的企业数据统一存储，既包括源系统中的原始副本，

也包括转换后的数据，比如那些用于报表，可视化，数据分析和机器学习

的数据。数据湖可以包括关系数据库的结构化数据（行与列）、半结构化的

数据（CSV,日志，XML,JSON）,非结构化数据（电子邮件、文件、

PDF）和二进制数据（图像、音频、视频）。储存数据湖的方式包括

ApacheHadoop分布式文件系统,Azure数据湖或亚马逊云Lake

Formation云存储服务，以及诸如Alluxio虚拟数据湖之类的解决方

案。数据沼泽是一个劣化的数据湖，用户无法访问，或是没什么价值。

AWS的定义相对简洁:

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结

构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），

并运行不同类型的分析-从控制面板和可视化到大数据处理、实时分析

和机器学习，以指导做出更好的决策。

Azure等其他云厂商也有各自的定义,本文不再赘述。

但无论数据湖的定义如何不同，数据湖的本质其实都包含如下四部分：

1.统一的存储系统

2.存储原始数据

3.丰富的计算模型/范式

4.数据湖与上云无关

从上述四个标准判断，开源大数据的HadoopHDFS存储系统就是一个

标准的数据湖架构，具备统一的原始数据存储架构。而近期被广泛谈到

的数据湖，其实是一个狭义的概念，特指"基于云上托管存储系统的数据

湖系统，架构上采用存储计算分离的体系"。例如基于AWSS3系统或者

阿里云OSS系统构建的数据湖。

下图是数据湖技术架构的演进过程，整体上可分为三个阶段：

其他引擎

HiveSparkHiveSpark

HDFSHDFS

自建开源数据湖EMR开源败湖云上数据湖

（存储计算一体）（存储计算一体）（存储计算分离）

图3.数据湖技术架构演进

1.阶段一：自建开源Hadoop数据湖架构，原始数据统一存放在HDFS

系统上，引擎以Hadoop和Spark开源生态为主，存储和计算一体。

缺点是需要企业自己运维和管理整套集群，成本高且集群稳定性差。

2.阶段二：云上托管Hadoop数据湖架构（即EMR开源数据湖），底

层物理服务器和开源软件版本由云厂商提供和管理，数据仍统一存放在

HDFS系统上，引擎以Hadoop和Spark开源生态为主。

这个架构通过云上laaS层提升了机器层面的弹性和稳定性，使企业的整

体运维成本有所下降，但企业仍然需要对HDFS系统以及服务运行状态

进行管理和治理，即应用层的运维工作。同时因为存储和计算耦合在一

起，稳定性不是最优，两种资源无法独立扩展，使用成本也不是最优。

3.阶段三：云上数据湖架构，即云上纯托管的存储系统逐步取代

HDFS,成为数据湖的存储基础设施，并且引擎丰富度也不断扩展。除了

Hadoop和Spark的生态引擎之外，各云厂商还发展出面向数据湖的引

擎产品。

如分析类的数据湖引擎有AWSAthena和华为DLI,AI类的有AWS

Sagemaker。这个架构仍然保持了一个存储和多个引擎的特性，所以统

一元数据服务至关重要，如AWS推出了Glue，阿里云EMR近期也即

将发布数据湖统一元数据服务。该架构相对于原生HDFS的数据湖架构

的优势在于：

•帮助用户摆脱原生HDFS系统运维困难的问题。HDFS系统运维有

两个困难：1）存储系统相比计算引擎更高的稳定性要求和更高的

运维风险2）与计算混布在一起，带来的扩展弹性问题。存储计算

分离架构帮助用户解耦存储，并交由云厂商统一运维管理，解决了

稳定性和运维问题。

•分离后的存储系统可以独立扩展，不再需要与计算耦合，可降低整

体成本

•当用户采用数据湖架构之后，客观上也帮助客户完成了存储统一化

（解决多个HDFS数据孤岛的问题）

下图是阿里云EMR数据湖架构图，它是基于开源生态的大数据平台，既

支持HDFS的开源数据湖，也支持OSS的云上数据湖。

产品优势

基于开源生秀的大数据平台

支持hdfs和0S5两种存储体系

JindoFS+OSS架构具有更好的效率和更低的成本

易于启动和塔建

图4.阿里云EMR数据湖架构

企业使用数据湖技术构建大数据平台，主要包括数据接入、数据存储、

计算和分析、数据管理、权限控制等，下图是Gartner定义的一个参考

架构。当前数据湖的技术因其架构的灵活性和开放性，在性能效率、安

全控制以及数据治理上并不十分成熟，在面向企业级生产要求时还存在

很大挑战（在第四章会有详细的阐述）。

Datalakereferencearchitecture

Consumption

TnnsientRawData

RefinedZone

LadingZone

DataDataOMAMtg

OLTPoeOOS.民

Ori^rtalTrusted

Data

EnterpmeDau

WarehcxAe

Discovery厅0^***^*R9<I>

S^boxQBVMWW

®-Anetyvti

ESam

DauSCn6m

Log1

(aretMr

dm)■<!©0

MeiMateDrtatXaky

OoudServicesDataLake

图5.数据湖架构图（来自网络）

03数据仓库的诞生，以及和数据中台的关系

数据仓库的概念最早来源于数据库领域，主要处理面向数据的复杂查询

和分析场景。随大数据技术发展，大量借鉴数据库的技术，例如SQL语

言、查询优化器等，形成了大数据的数据仓库，因其强大的分析能力，

成为主流。

近几年，数据仓库和云原生技术相结合，又演生出了云数据仓库，解决

了企业部署数据仓库的资源供给问题。云数据仓库作为大数据的高阶

（企业级）平台能力，因其开箱即用、无限扩展、简易运维等能力，越

来越受到人们的瞩目。

Wikipedia对数据仓库的定义：

在计算机领域，数据仓库(英语：datawarehouse,也称为企业数据

仓库)是用于报告和数据分析的系统，被认为是商业智能的核心组件。

数据仓库是来自一个或多个不同源的集成数据的中央存储库。数据仓库

将当前和历史数据存储在一起，用于为整个企业的员工创建分析报告。

比较学术的解释是，数据仓库由数据仓库之父W.H.Inmon于1990年

提出，主要功能乃是将组织透过信息系统之在线交易处理(OLTP)经年累

月所累积的大量数据，透过数据仓库理论所特有的数据存储架构，作一

有系统的分析整理,以利各种分析方法如在线分析处理(OLAP)、数据挖

掘(DataMining)之进行，并进而支持如决策支持系统(DSS)、主管信息

系统(EIS)之创建，帮助决策者能快速有效的自大量数据中，分析出有价

值的信息，以利决策拟定及快速回应外在环境变动，帮助建构商业智能

(BI)o

数据仓库的本质包含如下三部分：

1.内置的存储系统，数据通过抽象的方式提供(例如采用Table或者

View),不暴露文件系统。

2.数据需要清洗和转化，通常采用ETL/ELT方式

3.强调建模和数据管理，供商业智能决策

从上述的标准判断，无论传统数据仓库(如Teradata)还是新兴的云数

据仓库系统(AWSRedshift、GoogleBigQuery、阿里云

MaxCompute)均体现了数仓的设计本质，它们均没有对外暴露文件系

统，而是提供了数据进出的服务接口。

比如，Teradata提供了CLI数据导入工具，Redshift提供Copy命令

从S3或者EMR上导入数据，BigQuery提供DataTransfer服务，

MaxCompute提供Tunnel服务以及MMA搬站工具供数据上传和下

载。这个设计可以带来多个优势：

1.引擎深度理解数据，存储和计算可做深度优化

2.数据全生命周期管理，完善的血缘体系

3.细粒度的数据管理和治理

4.完善的元数据管理能力，易于构建企业级数据中台

正因为如此，阿里巴巴飞天大数据平台建设之初，在选型的时候就采用

了数据仓库的架构，即MaxCompute大数据平台。MaxCompute

（原ODPS）,既是阿里巴巴经济体的大数据平台，又是阿里云上的一种

安全可靠、高效能、低成本、从GB到EB级别按需弹性伸缩的在线大数

据计算服务（图6.是MaxCompute产品架构，具体详情请点击阿里云

MaxCompute官网地址）。

作为SaaS模式的企业级云数仓，MaxCompute广泛应用在阿里巴巴经

济体、以及阿里云上互联网、新金融、新零售、数字政府等数千家客

户。

介入访问(Web-UI/SDK/JDBC)

超过10万台服务器部署规模，广泛应用在阿

认证&访恒）控制管理监梓里巴巴经济体、以及阿里云上互联网、新金

数据仓库实例（Multi-Projects）融,新零售、数字政府等数千家客户

数据仓库1陶周&分享：散嵬仓库2分享：仓库3:数据仓库4

（ETL©目）：*-----*：（BI®目）*-----*（自助分析）:-----:（机犒学习）

产品优势

•云原生极致弹性,无服务那架构，开箱即用，支持秒级

弹性伸缩

•预置多种深度优化计算模型、存储和数据通道能力

•完善的企业皴平台能力，目支持开放生态

•强大的细粒度的安全隔离机制

•大镇模集群性能强、全偌博稳定性高，阿里巴巴双11场

景睑证

图6.MaxCompute云数仓产品架构

得益于MaxCompute数据仓库的架构，阿里巴巴上层逐步构建了“数

据安全体系"、"数据质量"、"数据治理"、"数据标签”等管理能力，并最

终形成了阿里巴巴的大数据中台。可以说，作为最早数据中台概念的提

出者，阿里巴巴的数据中台得益于数据仓库的架构。

鬻前臀瞽覆身需器用艮！湍鬻朝霆旌""红出一|金旦河

IIIIIIIIIIIIIIII砂*户

二山〜^也如哂曲《如我；•虹mn；qT±2

全/幽，S（政啾施■一场.按特大屏16控大解1688ttAE®CP®_技术•产居专一^行业解决方，

面向应用提供量务及创新可他的主题式数据服务中间件（PneService）vtsmra*

B01国西▽—

消费蠡敬州体系企业朗B体系内再数抬体系商品物S体系位*效揖体系

数E引入

资产目录

j包©幽Q®q0>笠

好血数据建模

i电商文娱营销物流金融出行社交健康

蹴通用研发

―北一6林•北书汉楷♦一♦=丫相看依&O就黛力幅MMLL3tBit造融）

财皿

败据连授萃取

I痔宝和JWWAE幔媚优士UC1mLAZADA.....天③贵利_...

资产运营!■抿运维陈山

“级皿防.）.溃£“乌假二“侬就敌的1人

图7.阿里巴巴数据中台架构

04数据湖VS数据仓库

综上，数据仓库和数据湖，是大数据架构的两种设计取向。两者在设计

的根本分歧点是对包括存储系统访问、权限管理、建模要求等方面的把

控。

数据湖优先的设计，通过开放底层文件存储，给数据入湖带来了最大的

灵活性。进入数据湖的数据可以是结构化的，也可以是半结构化的，甚

至可以是完全非结构化的原始日志。另外，开放存储给上层的引擎也带

来了更多的灵活度，各种引擎可以根据自己针对的场景随意读写数据湖

中存储的数据，而只需要遵循相当宽松的兼容性约定（这样的松散约定

当然会有隐患，后文会提到）。

但同时，文件系统直接访问使得很多更高阶的功能很难实现，例如，细

粒度（小于文件粒度）的权限管理、统一化的文件管理和读写接口升级

也十分困难（需要完成每一个访问文件的引擎升级，才算升级完毕）。

而数据仓库优先的设计，更加关注的是数据使用效率、大规模下的数据

管理、安全/合规这样的企业级成长性需求。数据经过统一但开放的服务

接口进入数据仓库，数据通常预先定义schema,用户通过数据服务接

口或者计算引擎访问分布式存储系统中的文件。

数据仓库优先的设计通过抽象数据访问接口/权限管理/数据本身，来换

取更高的性能（无论是存储还是计算）、闭环的安全体系、数据治理的

能力等，这些能力对于企业长远的大数据使用都至关重要，我们称之为

成长性。

下图是针对大数据技术栈，分别比较数据湖和数据仓库各自的取舍。

数据湖I大数据技术栈I云数据仓库

ft-<G0U96VL*22JIWJUM作文曲或4篇m/)

■mdEt关式3Mt不品

卿“收也位网我

KUxCompute朋克MWWff、UM步耽

元■初版侬旗.普引•同曰》性透格忻元3眯3行K0也置到或MaxComput*晶,A*ACIDAup&tv/W*电］

•<»*««**（糜

计时少炉窿好.<MT在fgl.

•M.swns««

图8.数据湖和数据仓库在技术栈上的对比

灵活性和成长性，对于处于不同时期的企业来说，重要性不同。

1.当企业处于初创阶段，数据从产生到消费还需要一个创新探索的阶段

才能逐渐沉淀下来，那么用于支撑这类业务的大数据系统，灵活性就更

加重要，数据湖的架构更适用。

2.当企业逐渐成熟起来，已经沉淀为一系列数据处理流程，问题开始转

化为数据规模不断增长，处理数据的成本不断增加，参与数据流程的人

员、部门不断增多，那么用于支撑这类业务的大数据系统，成长性的好

坏就决定了业务能够发展多远。数据仓库的架构更适用。

本文有观察到，相当一部分企业（尤其是新兴的互联网行业）从零开始

架构的大数据技术栈，正是伴随开源Hadoop体系的流行，经历了这样

一个从探索创新到成熟建模的过程。在这个过程中，因为数据湖架构太

过灵活而缺少对数据监管、控制和必要的治理手段，导致运维成本不断

增加、数据治理效率降低，企业落入了『数据沼泽』的境地，即数据湖

中汇聚了太多的数据，反而很难高效率的提炼真正有价值的那部分。

最后只有迁移到数据仓库优先设计的大数据平台，才解决了业务成长到

一定规模后所出现的运维、成本、数据治理等问题。还是举阿里巴巴的

例子，阿里巴巴成功的数据中台战略，正是在2015年前后阿里巴巴全

集团完成MaxCompute（数据仓库）对多个Hadoop（数据湖）的

完全替换（登月项目）才逐步形成的。

§

1

)

售

孤

鬟

愚

特定规模前,数据湖灵活性占优,之后数仓成长性占优业务规模

图9.数据湖的灵活性VS数据仓库的成长性的示意图

05下一代演进方向：湖仓一体

经过对数据湖和数据仓库的深入阐述和比较，本文认为数据湖和数据仓

库作为大数据系统的两条不同演进路线，有各自特有的优势和局限性。

数据湖和数据仓库一个面向初创用户友好，一个成长性更佳。对企业来

说，数据湖和数据仓库是否必须是一个二选一的选择题？是否能有一种

方案同时兼顾数据湖的灵活性和云数据仓库的成长性，将二者有效结合

起来为用户实现更低的总体拥有成本？

将数仓和数据湖融合在一起也是业界近年的趋势，多个产品和项目都做

过对应的尝试：

1.数仓支持数据湖访问

•2017年Redshift推出RedshiftSpectrum,支持Redsift数仓

用户访问S3数据湖的数据。

•2018年阿里云MaxCompute推出外表能力，支持访问包括

OSS/OTS/RDS数据库在内的多种外部存储。

但是无论是RedshiftSpectrum还是MaxCompute的外部表，仍旧

需要用户在数仓中通过创建外部表来将数据湖的开放存储路径纳入数仓

的概念体系一一由于一个单纯的开放式存储并不能自描述其数据本身的

变化，因此为这些数据创建外部表、添加分区（本质上是为数据湖中的

数据建立schema）无法完全自动化（需要人工或者定期触发Alter

tableaddpartition或msck）e这对于低频临时查询尚能接受，对于

生产使用来说，未免有些复杂。

2.数据湖支持数仓能力

•2011年,Hadoop开源体系公司Hortonworks开始了Apache

Atlas和Ranger两个开源项目的开发，分别对应数据血缘追踪和

数据权限安全两个数仓核心能力。但两个项目发展并不算顺利，直

到2017年才完成孵化，时至今日，在社区和工业界的部署都还远

远不够活跃。核心原因数据湖与生俱来的灵活性。例如Ranger作

为数据权限安全统一管理的组件，天然要求所有引擎均适配它才能

保证没有安全漏洞，但对于数据湖中强调灵活的引擎，尤其是新引

擎来说，会优先实现功能、场景，而不是把对接Ranger作为第一

优先级的目标，使得Ranger在数据湖上的位置一直很尴尬。

•2018年，Nexflix开源了内部增强版本的元数据服务系统

Iceberg,提供包括MVCC（多版本并发控制）在内的增强数仓能

力，但因为开源HMS已经成为事实标准，开源版本的Iceberg作

为插件方式兼容并配合HMS,数仓管理能力大打折扣。

•2018-2019年,Uber和Databricks相继推出了ApacheHudi

和DeltaLake,推出增量文件格式用以支持Update/Insert.事务

等数据仓库功能。新功能带来文件格式以及组织形式的改变，打破

了数据湖原有多套引擎之间关于共用存储的简单约定。为此，Hudi

为了维持兼容性，不得不发明了诸如Copy-On-Write,Merge-

On-Read两种表,SnapshotQuery、IncrementalQuery、

ReadOptimizedQuery三种查询类型，并给出了一个支持矩阵

（如图10）,极大提升了使用的复杂度。

Copy-On-Writetables

QueryEngineSnapshotQueriesIncrementalQueries

HiveYY

SparkSOLYY

SparkDatasourceYY

PrestoYN

ImpalaYN

Merge-On-Readtables

QueryEngineSnapshotQueriesIncrementalQueriesReadOptimizedQueries

HiveYYY

SparkSQLYYY

SparkDatasourceNNY

PrestoNNY

ImpalaNNY

图10.HudiSupportMatrix（来自网络）

而DeltaLake则选择了保证以Spark为主要支持引擎的体验，相对牺牲

对其他主流引擎的兼容性。这对其他引擎访问数据湖中的Delta数据造

成了诸多的限制和使用不便。例如Presto要使用DeltaLake表，需要

先用Spark创建manifest文件，再根据manifest创建外部表，同时

还要注意manifest文件的更新问题；而Hive要使用DeltaLake表限

制更多，不仅会造成元数据层面的混乱，甚至不能写表。

上述在数据湖架构上建立数仓的若干尝试并不成功，这表明数仓和数据

湖有本质的区别，在数据湖体系上很难建成完善的数仓。数据湖与数据

仓库两者很难直接合并成一套系统，因此作者团队，开始基于融合两者

的思路进行探索。

所以我们提出下一代的大数据技术演进方向：湖仓一体，即打通数据仓

库和数据湖两套体系，让数据和计算在湖和仓之间自由流动，从而构建

一个完整的有机的大数据技术生态体系。

我们认为，构建湖仓一体需要解决三个关健问题：

1.湖和仓的数据/元数据无健打通，且不需要用户人工干预

2.湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统

一的开发/管理平台操作

3.数据湖与数据仓库的数据，系统负责自动caching/moving,系统可

以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形

成一体化

我们将在下一章详细介绍阿里云湖仓一体方案如何解决这三个问题。

06阿里云湖仓一体方案

6.1整体架构

阿里云MaxCompute在原有的数据仓库架构上，融合了开源数据湖和

云上数据湖，最终实现了湖仓一体化的整体架构（图11）。

在该架构中，尽管底层多套存储系统并存，但通过统一的存储访问层和

统一的元数据管理，向上层引擎提供一体的封装接口，用户可以联合查

询数据仓库和数据湖中的表。整体架构还具备统一的数据安全、管理和

治理等中台能力。

MaxCompute湖仓TW5i架构

存储计II分寓

计鼻计算…开发平台/B阔f理/介入访问(Web-UVSDK/JDBC)

开源云?嫦湖

«CloudDatalaka认证&访问控制号理安全开发就鬃

内,第计U模型(5QUMR/PAL)联合计II平台(SpirVFImk)

+酶例(Multi-Projects)

BOB仓客im2分.；eag仓康2j皿的享数景仓咋3皿分享;u图6漳A

(ETUBS)*---------:(BUS自\*-----*(白助分析);*-----*(机学习)

Hive|Spark...开源自建数据湖

开放行■(HDFS)OrvpermDatatake

+f化的元费照f化的湖仓存储访问层

InsideHadoopInsideOSSMaxComput毗化内

SaaS云数仓…\A

MaxCompute

・・・HDF带晶云呼信NoSQUMBS®仓凉

(OSS)(TableStore)(MaxCompute内＞)

图11.阿里云湖仓一体整体架构

针对第五章提出的湖仓一体的三个关键问题，MaxCompute实现了以

下4个关键技术点。

1.快速接入

•MaxCompute全新自创PrivateAccess网络连通技术，在遵循云

虚拟网络安全标准的前提下，实现多租户模式下特定用户作业定向

与IDC/ECS/EMRHadoop集群网络整体打通能力，具有低延

迟、高独享带宽的特点。

•经过快速简单的开通、安全配置步骤即可将数据湖和购买的

MaxCompute数仓相连通。

2.统一数据/元数据管理

•MaxCompute实现湖仓一体化的元数据管理，通过DB元数据一

键映射技术，实现数据湖和MaxCompute数仓的元数据无缝打

通。MaxCompute通过向用户开放