详解大数据架构新概念

详解大数据架构新概念

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

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

出自己的数据湖解决方案，一些云数仓产品也增加了和数据湖联动的特性。

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

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

本文将从历史的角度对数据湖和数据仓库的来龙去脉进行深入剖析，来阐

述两者融合演进的新方向一一湖仓一体。

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

1.11.1概述

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

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

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

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

规模保持高速增长（年化60%—80%）,增速在可见的未来继续保持。对于新兴

企业，大数据领域增长超过年200%。

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

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

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

入生产环境，可靠性、安全性、管控能力、易用性等企业级产品力增强。

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

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

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

（KV）＞Presto（交互分析）、ElasticSearch（搜索）、Kafka（数据总线）自从2010

—2015年逐步占领开源生态，最近5年新引擎开源越来越少，但各引擎技术开

始向纵深发展（更好的性能、生产级别的稳定性等）。

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

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

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

B>gDat*hasboonwailraccgnaadMnawMWOUIivtaurcaandthovohxnoot819Datasmrarapidly

BigdataIsdatasolsthatarasovolunMnousandcomplexthat

traditionaldata-processingapplicationsoftwareareinadequate

todealwiththem.

Volume-数据量

Variety-数据类型

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

Veracity-信Qfttt(soweneedtoMINEdata)

Value-价值

♦大一幡畋棍.衽成木■力.

以及1溪上的捻速出比双11成W的前提

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

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

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

的20世纪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以及开源Ha

doop为代表的优秀分布式技术体系，当然，其中也包括阿里巴巴的飞天系统。

此时人们兴奋于追求数据的处理规模，即『大』数据，没有闲暇争论是数据仓

库还是数据湖。

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

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

整体开始从能用转向好用。

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

为表达的计算引擎。这些计算引擎针对不同的场景进行针对性优化，但都采用

门槛极低的SQL语言，极大降低了大数据技术的使用成本，数据库时代人们梦

想的大一统的数据仓库终于成为现实，各种数据库时代的方法论开始抬头。这

个时期技术路线开始出现细分。

云厂商主推的如AWSRedshift、GoogleBigQuery、Snowflake,包括MaxCo

mpute这样的集成系统称为大数据时代的数据仓库。而以开源Hadoop体系为

代表的开放式HDFS存储、开放的文件格式、开放的元数据服务以及多种引擎

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

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

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

要求，除了规模、性能、简单易用，提出了成本、安全、稳定性等更加全面的

企业级生产的要求。

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

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

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

源方案在企业级能力构建上遇到瓶颈，尤其是数据安全、身份权限强

管控、数据治理等方面，协同效率较差（如Ranger作为权限管控组

件、Atlas作为数据治理组件，跟今天的主流引擎竟然还无法做到全覆

盖）。同时引擎自身的发展也对已有的开放架构提出了更多挑战，Delta

Lake、Hudi这样自闭环设计的出现使得一套存储、一套元数据、多种

引擎协作的基础出现了某种程度的裂痕。

＞真正将数据湖概念推而广之的是AWS。AWS构筑了一套以S3为中心化

存储、Glue为元数据服务，E-MapReduce、Athena为引擎的开放协作

式的产品解决方案。它的开放性和和开源体系类似，并在2019年推出

LakeFormation解决产品间的安全授信问题。虽然这套架构在企业级能

力上和相对成熟的云数据仓库产品相去甚远，但对于开源技术体系的

用户来说，架构相近理解容易，还是很有吸引力。AWS之后，各个云

厂商也纷纷跟进数据湖的概念，并在自己的云服务上提供类似的产品

解决方案。

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

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

级和性能跳跃式发展，连续三年刷新TPCx-BigBench世界记录），数据

管理能力空前增强（数据中台建模理论、智能数仓），企业级安全能力

大为繁荣（同时支持基于ACL和基于规则等多种授权模型，列级别细

粒度授权，可信计算，存储加密，数据脱敏等），在联邦计算方面也普

遍做了增强，一定程度上开始将非数仓自身存储的数据纳入管理，和

数据湖的边界日益模糊。

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

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

体化服务。而数据湖则脱胎于大数据时代开源技术体系的开放设计，经过AWS

整合宣传，通常是由一系列云产品或开源组件共同构成大数据解决方案。

图2.20年大数据发展之路

202什么是数据湖

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

数据湖的相关定义。

Wikipedia对数据湖的定义：

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

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

后的数据，比如那些用于报表，可视化，数据分析和机器学习的数据。数据湖

可以包括关系数据库的结构化数据（行与列）、半结构化的数据（CSV,日志，X

MLJSON）,非结构化数据（电子邮件、文件、PDF）和二进制数据（图像、音

频、视频）。储存数据湖的方式包括ApacheHadoop分布式文件系统，Azure数

据湖或亚马逊云LakeFormation云存储服务，以及诸如Alluxi。虚拟数据湖之类

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

值。

AWS的定义相对简洁：

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

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

类型的分析-从控制面板和可视化到大数据处理、实时分析和机器学习，以指

导做出更好的决策。

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

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

1.统一的存储系统

2.存储原始数据

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

4.数据湖与上云无关

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

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

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

采用存储计算分离的体系二例如基于AWSS3系统或者阿里云OSS系统构建的

数据湖。

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

HiveISparkHIHiveISparkHIHivcI3”

卜=

IIII']”1祭^—I

I自建集翦IIIEM旗群I[1

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

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

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

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

上，引擎以Hadoop和Spark开源生态为主，存储和计算一体。缺点是需要企业

自己运维和管理整套集群，成本高且集群稳定性差。

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

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

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

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

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

和治理，即应用层的运维工作。同时因为存储和计算耦合在一起，稳定性不是

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

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

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

的生态引擎之外，各云厂商还发展出面向数据湖的引擎产品。

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

kero这个架构仍然保持了一个存储和多个引擎的特性，所以统一元数据服务至

关重要，如AWS推出了Glue,阿里云EMR近期也即将发布数据湖统一元数据

服务。该架构相对于原生HDFS的数据湖架构的优势在于：

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

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

2）与计算混布在一起，带来的扩展弹性问题。存储计算分离架构帮助

用户解耦存储，并交由云厂商统一运维管理，解决了稳定性和运维问

题。

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

成本.

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

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

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

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

产品优势

•『于开源生袤的大数据平台

•支持hdf$»o$s两神学催体手

•JindoFS+OSS茶梅具有更好的效率阳更偃的成本

•♦于启动物格缘

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

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

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

前数据湖的技术因其架构的灵活性和开放性，在性能效率、安全控制以及数据

治理上并不十分成熟，在面向企业级生产要求时还存在很大挑战（在第四章会

有详细的阐述）。

Datalakereferencearchitecture

图5.数据湖架构图

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

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

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

优化器等，形成了大数据的数据仓库，因其强大的分析能力，成为主流。

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

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

平台能力，因其开箱即用、无限扩展、简易运维等能力，越来越受到人们的瞩

目r-i。

Wikipedia对数据仓库的定义：

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

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

是来自一个或多个不同源的集成数据的中央存储库。数据仓库将当前和历史数

据存储在一起，用于为整个企业的员工创建分析报告。

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

主要功能乃是将组织透过信息系统之在线交易处理（OLTP）经年累月所累积的

大量数据，透过数据仓库理论所特有的数据存储架构，作一有系统的分析整

理，以利各种分析方法如在线分析处理（OLAP）、数据挖掘（DataMining）之

进行，并进而支持如决策支持系统（DSS）、主管信息系统（日S）之创建，帮助

决策者能快速有效的自大量数据中，分析出有价值的信息，以利决策拟定及快

速回应外在环境变动，帮助建构商业智能（Bl）»

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

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

w）,不暴露文件系统。

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

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

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

仓库系统（AWSRedshift、GoogleBigQuery、阿里云MaxCompute）均体现了数

仓的设计本质，它们均没有对外暴露文件系统，而是提供了数据进出的服务接

口。

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

者EMR上导入数据，BigQuery提供DataTransfer服务，MaxCompute提供Tunn

el服务以及MMA搬站工具供数据上传和下载。这个设计可以带来多个优势：

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

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

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

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

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

数据仓库的架构，即MaxCompute大数据平台。MaxCompute（原。DPS）,既

是阿里巴巴经济体的大数据平台，又是阿里云上的一种安全可靠、高效能、低

成本、从GB到EB级别按需弹性伸缩的在线大数据计算服务（图6.是MaxCom

pute产品架构，具体详情请点击阿里云MaxCompute官网地址）。

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

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

超过10万台展务器8Ml规&,广泛应用在网

里巴巴经济体.以及阿里云上互联网,新金

M.新零售.败手政府密敷千家客户

产品优势

自适应A性贲源油

•云・堡I51SA性.无量方构.开总即用.支持眇簸

•疫・多阱优化计算模型.存8图通道Q

户的—

x⑸nt•完■的企业・平台■力.且支特开放生有

•SL大的地为度的安翁・,机制

•方！・*群性幡强.全Qfi性高.阿里巴巴双11场

■魅证

图6.MaxCompute云数仓产品架构

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

全体系”“数据质量”“数据治理”“数据标签”等管理能力，并最终形成了阿里

巴巴的大数据中台。可以说，作为最早数据中台概念的提出者，阿里巴巴的数

据中台得益于数据仓库的架构。

阿里巴巴数据中台架构____________

B"*SBBKa-««»«■aHH0Ei工…篮

3W«tFBBa单囹2ZZttMMM-ttMMU)0KHMt-«>•**■«»1*«；-DT±2

BMUUAAAfHUM*X«AttXHVMM)«M«AQI0«WWA*«JMfiMGMB

(0Ms««VK・)

WMBma

06V

町KiNLH

黠企业同图体KWIBK体RJ

■«引入

rni'it"-r

UBCJatX

缁已®图Q⑥y•⑥

慨saut«

M”«aMIitifittsM

■RMJWI发

HmjUiAENN

UCMIAZADA一xn»«—.

BKiiHiMK

计算与芬•平台ntitaws皿计-亚在**力

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

404数据湖VS数据仓库

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

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

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

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

完全非结构化的原始日志。另外，开放存储给上层的引擎也带来了更多的灵活

度，各种引擎可以根据自己针对的场景随意读写数据湖中存储的数据，而只需

要遵循相当宽松的兼容性约定（这样的松散约定当然会有隐患，后文会提到）。

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

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

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

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

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

数据仓库，数据通常预先定义schema,用户通过数据服务接口或者计算引擎访

问分布式存储系统中的文件。

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

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

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

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

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

'『3^1溜溜版值留皿«.IMeWHKMAa作EU«IMtA

«KV.WWMKMBMkC*.0z«ff*_______

d-.—.»，—、MoCorvot*MN190MMSBiUHMMHOHWCtiMMIKHaVn.IHU>MB»

盟擢was蹲—s*«如~•客W骼*a，

3*『!W£S3STg^缪罐窃Rg黯督85a.wi«n

9««wnKBUMfiAnMI»«xt*aI»f>awfi4*

•»BXAMma.CKHVM««MVaxMVMmMVXM—g用cHMmiMI

0«cm>WMWamt

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

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

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

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

数据湖的架构更适用。

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

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

不断增多，那么用于支撑这类业务的大数据系统，成长性的好坏就决定了业务

能够发展多远。数据仓库的架构更适用。

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

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

索创新到成熟建模的过程。在这个过程中，因为数据湖架构太过灵活而缺少对

数据监管、控制和必要的治理手段，导致运维成本不断增加、数据治理效率降

低，企业落入了『数据沼泽』的境地，即数据湖中汇聚了太多的数据，反而很

难高效率的提炼真正有价值的那部分。

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

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

里巴巴成功的数据中台战略，正是在2015年前后阿里巴巴全集团完成MaxCom

pute（数据仓库）对多个Hadoop（数据湖）的完全替换（登月项目）才逐步形

成的。

(

0

工

)

皆

取

矍

客户如何才能同时享受数据湖的灵活

变

性和云1燔仓毒的成长性?

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

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

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

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

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

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

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

时兼顾数据湖的灵活性和云数据仓库的成长性，将二者有效结合起来为用户实

现更低的总体拥有成本？

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

对应的尝试：

1.数仓支持数据湖访问

>2017年Redshift推出RedshiftSpectrum,支持Redsift数仓用户访问S3

数据湖的数据。

>2018年阿里云MaxCompute推出外表能力，支持访问包括OSS/OTS/RD

S数据库在内的多种外部存储。

但是无论是RedshiftSpectrum还是MaxCompute的外部表，仍旧需要用户

在数仓中通过创建外部表来将数据湖的开放存储路径纳入数仓的概念体系一

由于一个单纯的开放式存储并不能自描述其数据本身的变化，因此为这些数据

创建外部表、添加分区（本质上是为数据湖中的数据建立schema）无法完全自

动化（需要人工或者定期触发Altertableaddpartition或msck）。这对于低频

临时查询尚能接受，对于生产使用来说，未免有些复杂。

2.数据湖支持数仓能力

>2011年，Hadoop开源体系公司Hortonworks开始了ApacheAtlas和Ra

nger两个开源项目的开发，分别对应数据血缘追踪和数据权限安全两

个数仓核心能力。但两个项目发展并不算顺利，直到2017年才完成孵

化，时至今日，在社区和工业界的部署都还远远不够活跃。核心原因

数据湖与生俱来的灵活性。例如Ranger作为数据权限安全统一管理的

组件，天然要求所有引擎均适配它才能保证没有安全漏洞，但对于数

据湖中强调灵活的引擎，尤其是新引擎来说，会优先实现功能、场

景，而不是把对接Ranger作为第一优先级的目标，使得Ranger在数据

湖上的位置一直很尴尬。

>2018年，Nexflix开源了内部增强版本的元数据服务系统Iceberg,提供

包括MVCC（多版本并发控制）在内的增强数仓能力，但因为开源HM

S已经成为事实标准，开源版本的Iceberg作为插件方式兼容并配合H

MS,数仓管理能力大打折扣。

>2018—2019年，Uber和Databricks相继推出了ApacheHudi和DeltaLa

ke,推出增量文件格式用以支持Update/lnsert、事务等数据仓库功

能。新功能带来文件格式以及组织形式的改变，打破了数据湖原有多

套引擎之间关于共用存储的简单约定。为此，Hudi为了维持兼容性，

不得不发明了诸如Copy-On-Write、Merge-On-Read两种表，Snapshot

Query、IncrementalQuery、ReadOptimizedQuery三种查询类型，并

给出了一个支持矩阵（如图10）,极大提升了使用的复杂度。

Copy-On-WritetabIes

QueryEngineSnapshotQueriesIncronentalQueries

HiveYY

SparkSQLYY

SparkDatasourceYY

PrestoYN

lapalaYN

Merge-On-Readtables

QueryEngin*SnapshotOuerie*Increment*1QueriesReadOptiatzedQueries

HiveYYY

SparkSQLYYY

SparkDatasourceNNY

PrestoNNY

ImpalaNNY

图10.HudiSupportMatrix

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

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

限制和使用不便。例如Presto要使用DeltaLake表，需要先用Spark创建manife

st文件，再根据manifest创建外部表，同时还要注意manifest文件的更新问

题；而Hive要使用DeltaLake表限制更多，不仅会造成元数据层面的混乱，甚

至不能写表。

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

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

很难直接合并成一套系统，因此作者团队，开始基于融合两者的思路进行探

索。

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

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

的有机的大数据技术生态体系。

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

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

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

的开发/管理平台操作

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

自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化

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

606阿里云湖仓一体方案

6.16.1整体架构

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

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

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

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

库和数据湖中的表。整体架构还具备统一的数据安全、管理和治理等中台能

力。

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

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

个关键技术点。

1.快速接入

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

安全标准的前提下，实现多租户模式下特定用户作业定向与IDC/ECS/E

MRHadoop集群网络整体打通能力，具有低延迟、高独享带宽的特

点。

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

ute数仓相连通。

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

>MaxCompute实现湖仓一体化的元数据管理，通过DB元数据一键映射

技术，实现数据湖和MaxCompute数仓的元数据无缝打通。MaxCompu

te通过向用户开放创建externalproject的形式，将数据湖HiveMetaSto

re中的整个database直接映射为MaxCompute的project,对HiveData

base的改动会实时反应在这个project中，并可以在MaxCompute侧随

时通过这个project进行访问、计算其中的数据。与此同时，阿里云E

MR数据湖解决方案也将推出DataLakeFormation,MaxCompute湖仓

一体方案也会支持对该数据湖中的统一元数据服务的一键映射能力。M

axCompute侧对externalproject的各种操作，也会实时反应在Hive

侧，真正实现数据仓库和数据湖之间的无缝联动，完全不需要类似联

邦查询方案里的元数据人工干预步骤。

>MaxCompute实现湖仓一体化的存储访问层，不仅支持内置优化的存储

系统，也无缝的支持外部存储系统。既支持HDFS数据湖，也支持OSS

云存储数据湖，可读写各种开源文件格式。

3.统一开发体验

>数据湖里的HiveDataBase映射为MaxComputeexternalproject,和普

通project别无二致，同样享受MaxCompute数仓里的数据开发、追踪

和管理功能。基于DataWorks强大的数据开发/管理/治理能力，提供统

一的湖仓开发体验，降低两套系统的管理成本。

>MaxCompute高度兼容Hive/Spark,支持一套任务可以在湖仓两套体系

中灵活无缝的运行。

>同时，MaxCompute也提供高效的数据通道接口，可以让数据湖中的H

adoop生态引擎直接访问，提升了数仓的开放性。

4.自动数仓

>湖仓一体需要用户根据自身资产使用情况将数据在湖和仓之间进行合

理的分层和存储，以最大化湖和仓的优势。MaxCompute开发了一套智

能cache技术，根据对历史任务的分析来识别数据冷热度，从而自动利

用闲时带宽将数据湖中的热数据以高效文件格式cache在数据仓库中，

进一步加速数据仓库的后续数据加工流程。不仅解决了湖仓之间的带

宽瓶颈问题，也达到了无须用户参与即可实现数据分层管理/治理以及

性能加速的目的。

6.26.2构建湖仓一体化的数据中台

基于MaxCompute湖仓一体技术，DataWorks可以进一步对湖仓两套系统

进行封装，屏蔽湖和仓异构集群信息，构建一体化的大数据中台，实现一套数

据、一套任务在湖和仓之上无缝调度和管理。

企业可以使用湖仓一体化的数据中台能力，优化数据管理架构，充分融合

数据湖和数据仓库各自优势。使用数据湖做集中式的原始数据存储，发挥数据

湖的灵活和开放优势。

又通过湖仓一体技术将面向生产的高频数据和任务，无缝调度到数据仓库

中，以得到更好的性能和成本，以及后续一系列面向生产的数据治理和优化，

最终让企业在成本和效率之间找到最佳平衡。

总体来说，MaxCompute湖仓一体为企业提供了一种更灵活更高效更经济

的数据平台解决方案，既适用于全新构建大数据平台的企业，也适合已有大数

据平台的企业进行架构升级，可以保护现有投资和实现资产利旧。

DauWodu

中台层

计算思

元雌/计算打通

数据打通

片杓海醉