作者 | 关涛、李睿博、孙莉莉、张良模、贾扬清（from 阿里云智能计算平台）
黄波、金玉梅、于茜、刘子正（from 新浪微博机器学习研发部）
编者按
随着近几年数据湖概念的衰亡，业界对于数据仓库和数据湖的比照甚至争执就始终一直。有人说数据湖是下一代大数据平台，各大云厂商也在纷纷的提出本人的数据湖解决方案，一些云数仓产品也减少了和数据湖联动的个性。然而数据仓库和数据湖的区别到底是什么，是技术路线之争？是数据管理形式之争？二者是水火不容还是其实能够谐和共存，甚至互为补充？本文作者来自阿里巴巴计算平台部门，深度参加阿里巴巴大数据 / 数据中台畛域建设，将从历史的角度对数据湖和数据仓库的前因后果进行深刻分析，来论述两者交融演进的新方向——湖仓一体，并就基于阿里云 MaxCompute/EMR DataLake 的湖仓一体计划做一介绍。
大数据畛域倒退 20 年的变与不变
1.1 概述
大数据畛域从本世纪初倒退到当初，已经验 20 年。从宏观层面察看其中的倒退法则，能够高度概括成如下五个方面：
1、数据保持高速增长– 从 5V 外围因素看，大数据畛域保持高速增长。阿里巴巴经济体，作为一个重度应用并着力倒退大数据畛域的公司，过来 5 年数据规模保持高速增长（年化 60%-80%），增速在可见的将来持续放弃。对于新兴企业，大数据畛域增长超过年 200%。
2、大数据作为新的生产因素，失去宽泛认可– 大数据畛域价值定位的迁徙，从“摸索”到“普惠”，成为各个企业 / 政府的外围部门，并承当要害工作。还是以阿里巴巴为例，30% 的员工间接提交大数据作业。随大数据普惠进入生产环境，可靠性、安全性、管控能力、易用性等企业级产品力加强。
3、数据管理能力成为新的关注点– 数仓（中台）能力流行起来，如何用好数据成为企业的外围竞争力。
4、引擎技术进入收敛期 – 随着 Spark（通用计算）、Flink（流计算）、Hbase（KV）、Presto（交互剖析）、ElasticSearch（搜寻）、Kafka（数据总线）自从 2010-2015 年逐渐霸占开源生态，最近 5 年新引擎开源越来越少，但各引擎技术开始向纵深倒退（更好的性能、生产级别的稳定性等）。
5、平台技术演进出两个趋势，数据湖 VS 数据仓库– 两者均关注数据存储和治理（平台技术），但方向不同。
图 1. 阿里巴巴双十一单日解决数据量增长
1.2 从大数据技术倒退看湖和仓
首先，数据仓库的概念呈现的要比数据湖早的多，能够追溯到数据库为王的上世纪 90 年代。因而，咱们有必要从历史的脉络来梳理这些名词呈现的大略工夫、来由以及更重要的背地起因。大体上，计算机科学畛域的数据处理技术的倒退，次要分为四个阶段：
1、阶段一：数据库时代。数据库最早诞生于 20 世纪的 60 年代，明天人们所熟知的关系型数据库则呈现在 20 世纪 70 年代，并在后续的 30 年左右工夫里大放异彩，诞生了很多优良的关系型数据库，如 Oracle、SQL Server、MySQL、PostgresSQL 等，成为过后支流计算机系统不可或缺的组成部分。到 20 世纪 90 年代，数据仓库的概念诞生。此时的数据仓库概念更多表白的是如何治理企业中多个数据库实例的方法论，但受限于单机数据库的解决能力以及多机数据库（分库分表）长期以来的昂扬价格，此时的数据仓库间隔一般企业和用户都还很边远。人们甚至还在争执数据仓库（对立集中管理）和数据集市（按部门、畛域的集中管理）哪个更具可行性。
2、阶段二：大数据技术的「探索期」。工夫进入到 2000 年左近，随着互联网的暴发，动辄几十亿、上百亿的页面以及海量的用户点击行为，开启了寰球的数据量急剧减少的新时代。传统的数据库计划再也有力以可承受的老本提供计算力，微小的数据处理需要开始寻找突破口，大数据时代开始萌芽。2003、2004、2006 年 Google 先后 3 篇经典论文（GFS、MapReduce、BigTable）奠基了这个大数据时代的根本技术框架，即分布式存储、散布式调度以及分布式计算模型。随后，简直是在同一期间，诞生了包含 Google，微软 Cosmos 以及开源 Hadoop 为代表的优良分布式技术体系，当然，这其中也包含阿里巴巴的飞天零碎。此时人们兴奋于谋求数据的解决规模，即『大』数据，没有空闲争执是数据仓库还是数据湖。
3、阶段三：大数据技术的「发展期」。来到 21 世纪的第二个 10 年，随着越来越多的资源投入到大数据计算畛域，大数据技术进入一个蓬勃发展的阶段，整体开始从能用转向好用。代替低廉的手写 MapReduce 作业的，则是如雨后春笋般呈现的各种以 SQL 为表白的计算引擎。这些计算引擎针对不同的场景进行针对性优化，但都采纳门槛极低的 SQL 语言，极大升高了大数据技术的应用老本，数据库时代人们幻想的大一统的数据仓库终于成为事实，各种数据库时代的方法论开始低头。这个期间技术路线开始呈现细分。云厂商主推的如 AWS Redshift、Google BigQuery、Snowflake，包含 MaxCompute 这样的集成系统称为大数据时代的数据仓库。而以开源 Hadoop 体系为代表的的开放式 HDFS 存储、凋谢的文件格式、凋谢的元数据服务以及多种引擎（Hive、Presto、Spark、Flink 等）协同工作的模式，则造成了数据湖的雏形。
4、阶段四：大数据技术「遍及期」。以后，大数据技术早已不是什么火箭科技，而曾经渗透到各行各业，大数据的遍及期曾经到来。市场对大数据产品的要求，除了规模、性能、简略易用，提出了老本、平安、稳定性等更加全面的企业级生产的要求。
· 开源 Hadoop 线，引擎、元数据、存储等根底部件的迭代更替进入绝对稳态，公众对开源大数据技术的认知达到空前的程度。一方面，凋谢架构的便当带来了不错的市场份额，另一方面凋谢架构的涣散则使开源计划在企业级能力构建上遇到瓶颈，尤其是数据安全、身份权限强管控、数据治理等方面，协同效率较差（如 Ranger 作为权限管控组件、Atlas 作为数据治理组件，跟明天的支流引擎居然还无奈做到全笼罩）。同时引擎本身的倒退也对已有的凋谢架构提出了更多挑战，Delta Lake、Hudi 这样自闭环设计的呈现使得一套存储、一套元数据、多种引擎合作的根底呈现了某种程度的裂缝。
· 真正将数据湖概念推而广之的是 AWS。AWS 构筑了一套以 S3 为中心化存储、Glue 为元数据服务，E-MapReduce、Athena 为引擎的凋谢合作式的产品解决方案。它的开放性和和开源体系相似，并在 2019 年推出 Lake Formation 解决产品间的平安授信问题。尽管这套架构在企业级能力上和绝对成熟的云数据仓库产品相去甚远，但对于开源技术体系的用户来说，架构相近了解容易，还是很有吸引力。AWS 之后，各个云厂商也纷纷跟进数据湖的概念，并在本人的云服务上提供相似的产品解决方案。
· 云厂商主推的数据仓库类产品则倒退良好，数仓外围能力方面继续加强。性能、老本方面极大晋升（MaxCompute 实现了外围引擎的全面降级和性能跳跃式倒退，间断三年刷新 TPCx-BigBench 世界记录），数据管理能力空前加强（数据中台建模实践、智能数仓），企业级平安能力大为凋敝（同时反对基于 ACL 和基于规定等多种受权模型，列级别细粒度受权，可信计算，存储加密，数据脱敏等），在联邦计算方面也广泛做了加强，肯定水平上开始将非数仓本身存储的数据纳入治理，和数据湖的边界日益含糊。
综上所述，数据仓库是个诞生于数据库时代的概念，在大数据时代随云厂商的各种数仓服务落地开花，目前通常指代云厂商提供的基于大数据技术的一体化服务。而数据湖则脱胎于大数据时代开源技术体系的凋谢设计，通过 AWS 整合宣传，通常是由一系列云产品或开源组件独特形成大数据解决方案。
图 2. 20 年大数据倒退之路
什么是数据湖
近几年数据湖的概念十分炽热，然而数据湖的定义并不对立，咱们先看下数据湖的相干定义。
Wikipedia 对数据湖的定义：
A data lake is a system or repository of datastored in its natural/raw format,usually object blobsor files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analyticsand machine learning. A data lake can include structured datafrom relational databases(rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data(emails, documents, PDFs) and binary data(images, audio, video). A data lake can be established “on premises” (within an organization’s data centers) or “in the cloud” (using cloud services from vendors such as Amazon, Google and Microsoft).A data swamp is a deteriorated and unmanaged data lake that is either inaccessible to its intended users or is providing little value.
数据湖是指应用大型二进制对象或文件这样的天然格局贮存数据的零碎。它通常把所有的企业数据对立存储，既包含源零碎中的原始正本，也包含转换后的数据，比方那些用于报表, 可视化, 数据分析和机器学习的数据。数据湖能够包含关系数据库的结构化数据 (行与列)、半结构化的数据(CSV，日志，XML, JSON)，非结构化数据 (电子邮件、文件、PDF) 和 二进制数据(图像、音频、视频)。贮存数据湖的形式包含 Apache Hadoop 分布式文件系统，Azure 数据湖或亚马逊云 Lake Formation 云存储服务，以及诸如 Alluxio 虚构数据湖之类的解决方案。数据沼泽是一个劣化的数据湖，用户无法访问，或是没什么价值。
AWS 的定义绝对简洁：
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
数据湖是一个集中式存储库，容许您以任意规模存储所有结构化和非结构化数据。您能够按原样存储数据（无需先对数据进行结构化解决），并运行不同类型的剖析 – 从控制面板和可视化到大数据处理、实时剖析和机器学习，以领导做出更好的决策。
Azure 等其余云厂商也有各自的定义，本文不再赘述。
但无论数据湖的定义如何不同，数据湖的实质其实都蕴含如下四局部：
1、对立的存储系统
2、存储原始数据
3、丰盛的计算模型 / 范式
4、数据湖与上云无关
从上述四个规范判断，开源大数据的 Hadoop HDFS 存储系统就是一个规范的数据湖架构，具备对立的原始数据存储架构。而近期被宽泛谈到的数据湖，其实是一个广义的概念，特指“基于云上托管存储系统的数据湖零碎，架构上采纳存储计算拆散的体系”。例如基于 AWS S3 零碎或者阿里云 OSS 零碎构建的数据湖。
下图是数据湖技术架构的演进过程，整体上可分为三个阶段：
图 3. 数据湖技术架构演进
1、阶段一：自建开源 Hadoop 数据湖架构，原始数据对立寄存在 HDFS 零碎上，引擎以 Hadoop 和 Spark 开源生态为主，存储和计算一体。毛病是须要企业本人运维和治理整套集群，老本高且集群稳定性差。
2、阶段二：云上托管 Hadoop 数据湖架构（即 EMR 开源数据湖），底层物理服务器和开源软件版本由云厂商提供和治理，数据仍对立寄存在 HDFS 零碎上，引擎以 Hadoop 和 Spark 开源生态为主。这个架构通过云上 IaaS 层晋升了机器层面的弹性和稳定性，使企业的整体运维老本有所降落，但企业依然须要对 HDFS 零碎以及服务运行状态进行治理和治理，即应用层的运维工作。同时因为存储和计算耦合在一起，稳定性不是最优，两种资源无奈独立扩大，应用老本也不是最优。
3、阶段三：云上数据湖架构，即云上纯托管的存储系统逐渐取代 HDFS，成为数据湖的存储基础设施，并且引擎丰盛度也一直扩大。除了 Hadoop 和 Spark 的生态引擎之外，各云厂商还倒退出面向数据湖的引擎产品。如剖析类的数据湖引擎有 AWS Athena 和华为 DLI，AI 类的有 AWS Sagemaker。这个架构依然放弃了一个存储和多个引擎的个性，所以对立元数据服务至关重要，如 AWS 推出了 Glue，阿里云 EMR 近期也行将公布数据湖对立元数据服务。该架构绝对于原生 HDFS 的数据湖架构的劣势在于：
· 帮忙用户解脱原生 HDFS 零碎运维艰难的问题。HDFS 零碎运维有两个艰难：1）存储系统相比计算引擎更高的稳定性要求和更高的运维危险 2）与计算混布在一起，带来的扩大弹性问题。存储计算拆散架构帮忙用户解耦存储，并交由云厂商对立运维治理，解决了稳定性和运维问题。
· 拆散后的存储系统能够独立扩大，不再须要与计算耦合，可升高整体老本
· 当用户采纳数据湖架构之后，主观上也帮忙客户实现了存储统一化（解决多个 HDFS 数据孤岛的问题）
下图是阿里云 EMR 数据湖架构图，它是基于开源生态的大数据平台，既反对 HDFS 的开源数据湖，也反对 OSS 的云上数据湖。
图 4. 阿里云 EMR 数据湖架构
企业应用数据湖技术构建大数据平台，次要包含数据接入、数据存储、计算和剖析、数据管理、权限管制等，下图是 Gartner 定义的一个参考架构。以后数据湖的技术因其架构的灵活性和开放性，在性能效率、安全控制以及数据治理上并不非常成熟，在面向企业级生产要求时还存在很大挑战（在第四章会有具体的论述）。
图 5. 数据湖架构图（来自网络）
数据仓库的诞生，以及和数据中台的关系
数据仓库的概念最早来源于数据库畛域，次要解决面向数据的简单查问和剖析场景。随大数据技术倒退，大量借鉴数据库的技术，例如 SQL 语言、查问优化器等，造成了大数据的数据仓库，因其弱小的剖析能力，成为支流。近几年，数据仓库和云原生技术相结合，又演生出了云数据仓库，解决了企业部署数据仓库的资源供应问题。云数据仓库作为大数据的高阶（企业级）平台能力，因其开箱即用、有限扩大、繁难运维等能力，越来越受到人们的注目。
Wikipedia 对数据仓库的定义：
In computing, a data warehouse (DW or DWH), also known as an enterprise data warehouse (EDW), is a system used for reportingand data analysis, and is considered a core component of business intelligence.DWs are central repositories of integrated data from one or more disparate sources. Extract, transform, load(ETL) and extract, load, transform(E-LT) are the two main approaches used to build a data warehouse system.
在计算机领域，数据仓库（英语：data warehouse，也称为企业数据仓库）是用于报告和数据分析的零碎，被认为是商业智能的外围组件。数据仓库是来自一个或多个不同源的集成数据的地方存储库。数据仓库将以后和历史数据存储在一起，用于为整个企业的员工创立剖析报告。比拟学术的解释是，数据仓库由数据仓库之父 W.H.Inmon 于 1990 年提出，次要性能乃是将组织透过信息系统之在线交易解决 (OLTP) 经久不息所累积的大量数据，透过数据仓库实践所特有的数据存储架构，作一有零碎的剖析整顿 ，以利各种分析方法如在线剖析解决(OLAP)、数据挖掘(Data Mining) 之进行，并进而反对如决策支持系统 (DSS)、主管信息系统(EIS) 之创立，帮忙决策者能疾速无效的自大量数据中，剖析出有价值的信息，以利决策拟定及疾速回应外在环境变动，帮忙建构商业智能(BI)。
数据仓库的实质蕴含如下三局部：
1、内置的存储系统，数据通过形象的形式提供（例如采纳 Table 或者 View），不裸露文件系统。
2、数据须要荡涤和转化，通常采纳 ETL/ELT 形式
3、强调建模和数据管理，供商业智能决策
从上述的规范判断，无论传统数据仓库（如 Teradata）还是新兴的云数据仓库零碎（AWS Redshift、Google BigQuery、阿里云 MaxCompute）均体现了数仓的设计实质，它们均没有对外裸露文件系统，而是提供了数据进出的服务接口。比方，Teradata 提供了 CLI 数据导入工具，Redshift 提供 Copy 命令从 S3 或者 EMR 上导入数据，BigQuery 提供 Data Transfer 服务，MaxCompute 提供 Tunnel 服务以及 MMA 搬站工具供数据上传和下载。这个设计能够带来多个劣势：
1、引擎深度了解数据，存储和计算可做深度优化
2、数据全生命周期治理，欠缺的血统体系
3、细粒度的数据管理和治理
4、欠缺的元数据管理能力，易于构建企业级数据中台
正因为如此，阿里巴巴飞天大数据平台建设之初，在选型的时候就采纳了数据仓库的架构，即 MaxCompute 大数据平台。MaxCompute（原 ODPS)，既是阿里巴巴经济体的大数据平台，又是阿里云上的一种安全可靠、高效能、低成本、从 GB 到 EB 级别按需弹性伸缩的在线大数据计算服务（图 6. 是 MaxCompute 产品架构，具体详情请点击阿里云 MaxCompute 官网地址）。作为 SaaS 模式的企业级云数仓，MaxCompute 广泛应用在阿里巴巴经济体、以及阿里云上互联网、新金融、新批发、数字政府等数千家客户。
图 6. MaxCompute 云数仓产品架构
得益于 MaxCompute 数据仓库的架构，阿里巴巴下层逐渐构建了“数据安全体系”、“数据品质”、“数据治理”、“数据标签”等治理能力，并最终造成了阿里巴巴的大数据中台。能够说，作为最早数据中台概念的提出者，阿里巴巴的数据中台得益于数据仓库的架构。
图 7. 阿里巴巴数据中台架构
数据湖 VS 数据仓库
综上，数据仓库和数据湖，是大数据架构的两种设计取向。两者在设计的基本分歧点是对包含存储系统拜访、权限治理、建模要求等方面的把控。
数据湖优先的设计，通过凋谢底层文件存储，给数据入湖带来了最大的灵活性。进入数据湖的数据能够是结构化的，也能够是半结构化的，甚至能够是齐全非结构化的原始日志。另外，凋谢存储给下层的引擎也带来了更多的灵便度，各种引擎能够依据本人针对的场景随便读写数据湖中存储的数据，而只须要遵循相当宽松的兼容性约定（这样的涣散约定当然会有隐患，后文会提到）。但同时，文件系统间接拜访使得很多更高阶的性能很难实现，例如，细粒度（小于文件粒度）的权限治理、统一化的文件治理和读写接口降级也十分困难（须要实现每一个拜访文件的引擎降级，才算降级结束）。
而数据仓库优先的设计，更加关注的是数据应用效率、大规模下的数据管理、平安 / 合规这样的企业级成长性需要。数据通过对立但凋谢的服务接口进入数据仓库，数据通常事后定义 schema，用户通过数据服务接口或者计算引擎拜访分布式存储系统中的文件。数据仓库优先的设计通过形象数据拜访接口 / 权限治理 / 数据自身，来换取更高的性能（无论是存储还是计算）、闭环的平安体系、数据治理的能力等，这些能力对于企业久远的大数据应用都至关重要，咱们称之为成长性。
下图是针对大数据技术栈，别离比拟数据湖和数据仓库各自的取舍。
图 8. 数据湖和数据仓库在技术栈上的比照
灵活性和成长性，对于处于不同期间的企业来说，重要性不同。
1、当企业处于初创阶段，数据从产生到生产还须要一个翻新摸索的阶段能力逐步积淀下来，那么用于撑持这类业务的大数据系统，灵活性就更加重要，数据湖的架构更实用。
2、当企业逐步成熟起来，曾经积淀为一系列数据处理流程，问题开始转化为数据规模一直增长，解决数据的老本一直减少，参加数据流程的人员、部门一直增多，那么用于撑持这类业务的大数据系统，成长性的好坏就决定了业务可能倒退多远。数据仓库的架构更实用。
本文有察看到，相当一部分企业（尤其是新兴的互联网行业）从零开始架构的大数据技术栈，正是随同开源 Hadoop 体系的风行，经验了这样一个从摸索翻新到成熟建模的过程。在这个过程中，因为数据湖架构太过灵便而短少对数据监管、管制和必要的治理伎俩，导致运维老本一直减少、数据治理效率升高，企业落入了『数据沼泽』的地步，即数据湖中汇聚了太多的数据，反而很难高效率的提炼真正有价值的那局部。最初只有迁徙到数据仓库优先设计的大数据平台，才解决了业务成长到肯定规模后所呈现的运维、老本、数据治理等问题。还是举阿里巴巴的例子，阿里巴巴胜利的数据中台策略，正是在 2015 年前后阿里巴巴全团体实现 MaxCompute（数据仓库）对多个 Hadoop（数据湖）的齐全替换（登月我的项目）才逐步形成的。
图 9. 数据湖的灵活性 VS 数据仓库的成长性的示意图
下一代演进方向：湖仓一体
通过对数据湖和数据仓库的深刻论述和比拟，本文认为数据湖和数据仓库作为大数据系统的两条不同演进路线，有各自特有的劣势和局限性。数据湖和数据仓库一个面向初创用户敌对，一个成长性更佳。对企业来说，数据湖和数据仓库是否必须是一个二选一的选择题？是否能有一种计划同时兼顾数据湖的灵活性和云数据仓库的成长性，将二者无效联合起来为用户实现更低的总体领有老本？
将数仓和数据湖交融在一起也是业界近年的趋势，多个产品和我的项目都做过对应的尝试：
1、数仓反对数据湖拜访
· 2017 年 Redshift 推出 Redshift Spectrum，反对 Redsift 数仓用户拜访 S3 数据湖的数据。
· 2018 年阿里云 MaxCompute 推出表面能力，反对拜访包含 OSS/OTS/RDS 数据库在内的多种内部存储。
然而无论是 Redshift Spectrum 还是 MaxCompute 的内部表，仍旧须要用户在数仓中通过创立内部表来将数据湖的凋谢存储门路纳入数仓的概念体系——因为一个单纯的开放式存储并不能自描述其数据自身的变动，因而为这些数据创立内部表、增加分区（实质上是为数据湖中的数据建设 schema）无奈齐全自动化（须要人工或者定期触发 Alter table add partition 或 msck）。这对于低频长期查问尚能承受，对于生产应用来说，未免有些简单。
2、数据湖反对数仓能力
· 2011 年，Hadoop 开源体系公司 Hortonworks 开始了 Apache Atlas 和 Ranger 两个开源我的项目的开发，别离对应数据血统追踪和数据权限平安两个数仓外围能力。但两个我的项目倒退并不算顺利，直到 2017 年才实现孵化，时至今日，在社区和工业界的部署都还远远不够沉闷。外围起因数据湖与生俱来的灵活性。例如 Ranger 作为数据权限平安对立治理的组件，人造要求所有引擎均适配它能力保障没有安全漏洞，但对于数据湖中强调灵便的引擎，尤其是新引擎来说，会优先实现性能、场景，而不是把对接 Ranger 作为第一优先级的指标，使得 Ranger 在数据湖上的地位始终很难堪。
· 2018 年，Nexflix 开源了外部加强版本的元数据服务零碎 Iceberg，提供包含 MVCC（多版本并发管制）在内的加强数仓能力，但因为开源 HMS 曾经成为事实标准，开源版本的 Iceberg 作为插件形式兼容并配合 HMS，数仓治理能力大打折扣。
· 2018-2019 年，Uber 和 Databricks 相继推出了 Apache Hudi 和 DeltaLake，推出增量文件格式用以反对 Update/Insert、事务等数据仓库性能。新性能带来文件格式以及组织模式的扭转，突破了数据湖原有多套引擎之间对于共用存储的简略约定。为此，Hudi 为了维持兼容性，不得不创造了诸如 Copy-On-Write、Merge-On-Read 两种表，Snapshot Query、Incremental Query、Read Optimized Query 三种查问类型，并给出了一个反对矩阵（如图 10），极大晋升了应用的复杂度。
图 10. Hudi Support Matrix（来自网络）
而 DeltaLake 则抉择了保障以 Spark 为次要反对引擎的体验，绝对就义对其余支流引擎的兼容性。这对其余引擎拜访数据湖中的 Delta 数据造成了诸多的限度和应用不便。例如 Presto 要应用 DeltaLake 表，须要先用 Spark 创立 manifest 文件，再依据 manifest 创立内部表，同时还要留神 manifest 文件的更新问题；而 Hive 要应用 DeltaLake 表限度更多，不仅会造成元数据层面的凌乱，甚至不能写表。
上述在数据湖架构上建设数仓的若干尝试并不胜利，这表明数仓和数据湖有实质的区别，在数据湖体系上很难建成欠缺的数仓。数据湖与数据仓库两者很难间接合并成一套零碎，因而作者团队，开始基于交融两者的思路进行摸索。所以咱们提出下一代的大数据技术演进方向：湖仓一体，即买通数据仓库和数据湖两套体系，让数据和计算在湖和仓之间自在流动，从而构建一个残缺的有机的大数据技术生态体系。
咱们认为，构建湖仓一体须要解决三个关键问题：
1、湖和仓的数据 / 元数据无缝买通，且不须要用户人工干预
2、湖和仓有对立的开发体验，存储在不同零碎的数据，能够通过一个对立的开发 / 治理平台操作
3、数据湖与数据仓库的数据，零碎负责主动 caching/moving，零碎能够依据主动的规定决定哪些数据放在数仓，哪些保留在数据湖，进而造成一体化
咱们将在下一章具体介绍阿里云湖仓一体计划如何解决这三个问题。
阿里云湖仓一体计划
6.1 整体架构
阿里云 MaxCompute 在原有的数据仓库架构上，交融了开源数据湖和云上数据湖，最终实现了湖仓一体化的整体架构（图 11）。在该架构中，只管底层多套存储系统并存，但通过对立的存储拜访层和对立的元数据管理，向下层引擎提供一体的封装接口，用户能够联结查问数据仓库和数据湖中的表。整体架构还具备对立的数据安全、治理和治理等中台能力。
图 11. 阿里云湖仓一体整体架构
针对第五章提出的湖仓一体的三个关键问题，MaxCompute 实现了以下 4 个关键技术点。
1、疾速接入
· MaxCompute 全新借鉴 PrivateAccess 网络连通技术，在遵循云虚构网络安全规范的前提下，实现多租户模式下特定用户作业定向与 IDC/ECS/EMR Hadoop 集群网络整体买通能力，具备低提早、高独享带宽的特点。
· 通过疾速简略的开明、平安配置步骤即可将数据湖和购买的 MaxCompute 数仓相连通。
2、对立数据 / 元数据管理
· MaxCompute 实现湖仓一体化的元数据管理，通过 DB 元数据一键映射技术，实现数据湖和 MaxCompute 数仓的元数据无缝买通。MaxCompute 通过向用户凋谢创立 external project 的模式，将数据湖 HiveMetaStore 中的整个 database 间接映射为 MaxCompute 的 project，对 Hive Database 的改变会实时反馈在这个 project 中，并能够在 MaxCompute 侧随时通过这个 project 进行拜访、计算其中的数据。与此同时，阿里云 EMR 数据湖解决方案也将推出 Data Lake Formation，MaxCompute 湖仓一体计划也会反对对该数据湖中的对立元数据服务的一键映射能力。MaxCompute 侧对 external project 的各种操作，也会实时反馈在 Hive 侧，真正实现数据仓库和数据湖之间的无缝联动，齐全不须要相似联邦查问计划里的元数据人工干预步骤。
· MaxCompute 实现湖仓一体化的存储拜访层，不仅反对内置优化的存储系统，也无缝的反对内部存储系统。既反对 HDFS 数据湖，也反对 OSS 云存储数据湖，可读写各种开源文件格式。
3、对立开发体验
· 数据湖里的 Hive DataBase 映射为 MaxCompute external project，和一般 project 别无二致，同样享受 MaxCompute 数仓里的数据开发、追踪和治理性能。基于 DataWorks 弱小的数据开发 / 治理 / 治理能力，提供对立的湖仓开发体验，升高两套零碎的治理老本。
· MaxCompute 高度兼容 Hive/Spark，反对一套工作能够在湖仓两套体系中灵便无缝的运行。
· 同时，MaxCompute 也提供高效的数据通道接口，能够让数据湖中的 Hadoop 生态引擎间接拜访，晋升了数仓的开放性。
4、主动数仓
· 湖仓一体须要用户依据本身资产应用状况将数据在湖和仓之间进行正当的分层和存储，以最大化湖和仓的劣势。MaxCompute 开发了一套智能 cache 技术，依据对历史工作的剖析来辨认数据冷热度，从而主动利用闲时带宽将数据湖中的热数据以高效文件格式 cache 在数据仓库中，进一步减速数据仓库的后续数据加工流程。不仅解决了湖仓之间的带宽瓶颈问题，也达到了毋庸用户参加即可实现数据分层治理 / 治理以及性能减速的目标。
6.2 构建湖仓一体化的数据中台
基于 MaxCompute 湖仓一体技术，DataWorks 能够进一步对湖仓两套零碎进行封装，屏蔽湖和仓异构集群信息，构建一体化的大数据中台，实现一套数据、一套工作在湖和仓之上无缝调度和治理。企业能够应用湖仓一体化的数据中台能力，优化数据管理架构，充沛交融数据湖和数据仓库各自劣势。应用数据湖做集中式的原始数据存储，施展数据湖的灵便和凋谢劣势。又通过湖仓一体技术将面向生产的高频数据和工作，无缝调度到数据仓库中，以失去更好的性能和老本，以及后续一系列面向生产的数据治理和优化，最终让企业在老本和效率之间找到最佳均衡。
总体来说，MaxCompute 湖仓一体为企业提供了一种更灵便更高效更经济的数据平台解决方案，既实用于全新构建大数据平台的企业，也适宜已有大数据平台的企业进行架构降级，能够爱护现有投资和实现资产利旧。
图 12. DataWorks 湖仓一体化数据中台
6.3 典型客户案例：新浪微博利用「湖仓一体」构建混合云 AI 计算中台
· 案例背景
微博机器学习平台团队，次要做社交媒体畛域里的举荐次要做社交媒体畛域里的举荐 / 排序、文本 / 图像分类、反垃圾 / 反作弊等技术。技术架构上次要围绕开源 Hadoop 数据湖解决方案，一份 HDFS 存储 + 多种计算引擎（hive、spark、flink），以满足以 AI 为主的多计算场景需要。但微博作为国内 Top 的社交媒体利用，以后的业务体量和复杂性未然进入到开源“无人区”，开源数据湖计划在性能和老本方面都无奈满足微博的要求。微博借助阿里巴巴弱小的飞天大数据和 AI 平台能力（MaxC+PAI+DW），解决了超大规模下的特色工程、模型训练以及矩阵计算的性能瓶颈问题，进而造成了阿里巴巴 MaxCompute 平台（数仓）+ 开源平台（数据湖）共存的格局。
· 外围痛点
微博心愿借助这两套异构的大数据平台，既放弃面向 AI 的各类数据和计算的灵活性，又解决超大规模下的计算和算法的性能 / 老本问题。但因为这两套大数据平台在集群层面齐全是割裂的，数据和计算无奈在两个平台里自在流动，无形之中减少了大量的数据挪动和计算开发等老本，进而制约了业务的倒退。次要的痛点是：1）安顿专人专项负责训练数据同步，工作量微小 2）训练数据体量大，导致耗时多，无奈满足实时训练的要求 3）新写 SQL 数据处理 query，无奈复用 Hive SQL 原有 query。
图 13. 新浪微博业务痛点示意
· 解决方案
为了解决上述的痛点问题，阿里云产品团队和微博机器学习平台团队联结共建湖仓一体新技术，买通了阿里巴巴 MaxCompute 云数仓和 EMR Hadoop 数据湖，构建了一个跨湖和仓的 AI 计算中台。MaxCompute 产品全面降级网络基础设施，买通用户 VPC 私域，且依靠 Hive 数据库一键映射和弱小欠缺的 SQL/PAI 引擎能力，将 MaxCompute 云数仓和 EMR Hadoop 数据湖技术体系无缝对接，实现湖和的仓对立且智能化治理和调度。
图 14. 微博湖仓一体架构图
· 案例价值
1）不仅交融了数据湖和数据仓库的劣势，在灵活性和效率上找到最佳均衡，还疾速构建了一套对立的 AI 计算中台，极大晋升该机器学习平台团队的业务撑持能力。毋庸进行数据搬迁和作业迁徙，即可将一套作业无缝灵便调度在 MaxCompute 集群和 EMR 集群中。
2）SQL 数据处理工作被宽泛运行到 MaxCompute 集群，性能有显著晋升。基于阿里巴巴 PAI 丰盛且弱小的算法能力，封装出多种贴近业务场景的算法服务，满足更多的业务需要。
3）MaxCompute 云原生的弹性资源和 EMR 集群资源造成互补，两套体系之间进行资源的削峰填谷，不仅缩小作业排队，且升高整体老本。
总结
数据湖和数据仓库，是在明天大数据技术条件下构建分布式系统的两种数据架构设计取向，要看均衡的方向是更偏差灵活性还是老本、性能、平安、治理等企业级个性。然而数据湖和数据仓库的边界正在缓缓含糊，数据湖本身的治理能力、数据仓库延长到内部存储的能力都在增强。在这样的背景之下，MaxCompute 率先提出湖仓一体，为业界和用户展示了一种数据湖和数据仓湖相互补充，协同工作的架构。这样的架构同时为用户提供了数据湖的灵活性和数据仓库的诸多企业级个性，将用户应用大数据的总体领有老本进一步升高，咱们认为是下一代大数据平台的演进方向。
原文链接
本文为阿里云原创内容，未经容许不得转载。