泰安外贸网站建设公司,一级造价工程师专业,潍坊网站开发公司,网站 建设标准比别人更快接收好文章
随着近几年数据湖概念的兴起#xff0c;业界对于数据仓库和数据湖的对比甚至争论就一直不断。有人说数据湖是下一代大数据平台#xff0c;各大云厂商也在纷纷的提出自己的数据湖解决方案#xff0c;一些云数仓产品也增加了和数据湖联动的特性。
但是…
比别人更快接收好文章
随着近几年数据湖概念的兴起业界对于数据仓库和数据湖的对比甚至争论就一直不断。有人说数据湖是下一代大数据平台各大云厂商也在纷纷的提出自己的数据湖解决方案一些云数仓产品也增加了和数据湖联动的特性。
但是数据仓库和数据湖的区别到底是什么是技术路线之争是数据管理方式之争二者是水火不容还是其实可以和谐共存甚至互为补充
本文作者来自阿里巴巴计算平台部门深度参与阿里巴巴大数据/数据中台领域建设将从历史的角度对数据湖和数据仓库的来龙去脉进行深入剖析来阐述两者融合演进的新方向——湖仓一体并就基于阿里云MaxCompute/EMR DataLake的湖仓一体方案做一介绍。 01 大数据领域发展20年的变与不变
1.1 概述
大数据领域从本世纪初发展到现在已经历20年。从宏观层面观察其中的发展规律可以高度概括成如下五个方面
1. 数据保持高速增长- 从5V核心要素看大数据领域保持高速增长。阿里巴巴经济体作为一个重度使用并着力发展大数据领域的公司过去5年数据规模保持高速增长年化60%-80%增速在可见的未来继续保持。对于新兴企业大数据领域增长超过年200%。
2. 大数据作为新的生产要素得到广泛认可- 大数据领域价值定位的迁移从“探索”到“普惠”成为各个企业/政府的核心部门并承担关键任务。还是以阿里巴巴为例30%的员工直接提交大数据作业。随大数据普惠进入生产环境可靠性、安全性、管控能力、易用性等企业级产品力增强。
3. 数据管理能力成为新的关注点- 数仓中台能力流行起来如何用好数据成为企业的核心竞争力。
4. 引擎技术进入收敛期 - 随着Spark通用计算、Flink流计算、HbaseKV、Presto交互分析、ElasticSearch搜索、Kafka数据总线自从2010-2015年逐步占领开源生态最近5年新引擎开源越来越少但各引擎技术开始向纵深发展更好的性能、生产级别的稳定性等。
5. 平台技术演进出两个趋势数据湖 VS 数据仓库- 两者均关注数据存储和管理平台技术但方向不同。
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 整合宣传通常是由一系列云产品或开源组件共同构成大数据解决方案。
02 什么是数据湖
近几年数据湖的概念非常火热但是数据湖的定义并不统一我们先看下数据湖的相关定义。
Wikipedia对数据湖的定义
数据湖是指使用大型二进制对象或文件这样的自然格式储存数据的系统。它通常把所有的企业数据统一存储既包括源系统中的原始副本也包括转换后的数据比如那些用于报表, 可视化, 数据分析和机器学习的数据。数据湖可以包括关系数据库的结构化数据(行与列)、半结构化的数据(CSV日志XML, JSON)非结构化数据 (电子邮件、文件、PDF)和 二进制数据(图像、音频、视频)。储存数据湖的方式包括 Apache Hadoop分布式文件系统 Azure 数据湖或亚马逊云 Lake Formation云存储服务以及诸如 Alluxio 虚拟数据湖之类的解决方案。数据沼泽是一个劣化的数据湖用户无法访问或是没什么价值。
AWS的定义相对简洁
数据湖是一个集中式存储库允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据无需先对数据进行结构化处理并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习以指导做出更好的决策。
Azure等其他云厂商也有各自的定义本文不再赘述。
但无论数据湖的定义如何不同数据湖的本质其实都包含如下四部分
1. 统一的存储系统
2. 存储原始数据
3. 丰富的计算模型/范式
4. 数据湖与上云无关
从上述四个标准判断开源大数据的Hadoop HDFS存储系统就是一个标准的数据湖架构具备统一的原始数据存储架构。而近期被广泛谈到的数据湖其实是一个狭义的概念特指“基于云上托管存储系统的数据湖系统架构上采用存储计算分离的体系”。例如基于AWS S3系统或者阿里云OSS系统构建的数据湖。
下图是数据湖技术架构的演进过程整体上可分为三个阶段
1. 阶段一自建开源Hadoop数据湖架构原始数据统一存放在HDFS系统上引擎以Hadoop和Spark开源生态为主存储和计算一体。缺点是需要企业自己运维和管理整套集群成本高且集群稳定性差。
2. 阶段二云上托管Hadoop数据湖架构即EMR开源数据湖底层物理服务器和开源软件版本由云厂商提供和管理数据仍统一存放在HDFS系统上引擎以Hadoop和Spark开源生态为主。
这个架构通过云上 IaaS 层提升了机器层面的弹性和稳定性使企业的整体运维成本有所下降但企业仍然需要对HDFS系统以及服务运行状态进行管理和治理即应用层的运维工作。同时因为存储和计算耦合在一起稳定性不是最优两种资源无法独立扩展使用成本也不是最优。
3. 阶段三云上数据湖架构即云上纯托管的存储系统逐步取代HDFS成为数据湖的存储基础设施并且引擎丰富度也不断扩展。除了Hadoop和Spark的生态引擎之外各云厂商还发展出面向数据湖的引擎产品。
如分析类的数据湖引擎有AWS Athena和华为DLIAI类的有AWS Sagemaker。这个架构仍然保持了一个存储和多个引擎的特性所以统一元数据服务至关重要如AWS推出了Glue阿里云EMR近期也即将发布数据湖统一元数据服务。该架构相对于原生HDFS的数据湖架构的优势在于
帮助用户摆脱原生HDFS系统运维困难的问题。HDFS系统运维有两个困难1存储系统相比计算引擎更高的稳定性要求和更高的运维风险 2与计算混布在一起带来的扩展弹性问题。存储计算分离架构帮助用户解耦存储并交由云厂商统一运维管理解决了稳定性和运维问题。分离后的存储系统可以独立扩展不再需要与计算耦合可降低整体成本当用户采用数据湖架构之后客观上也帮助客户完成了存储统一化解决多个HDFS数据孤岛的问题
下图是阿里云EMR数据湖架构图它是基于开源生态的大数据平台既支持HDFS的开源数据湖也支持OSS的云上数据湖。 图4. 阿里云EMR数据湖架构
企业使用数据湖技术构建大数据平台主要包括数据接入、数据存储、计算和分析、数据管理、权限控制等下图是Gartner定义的一个参考架构。当前数据湖的技术因其架构的灵活性和开放性在性能效率、安全控制以及数据治理上并不十分成熟在面向企业级生产要求时还存在很大挑战在第四章会有详细的阐述。 03 数据仓库的诞生以及和数据中台的关系
数据仓库的概念最早来源于数据库领域主要处理面向数据的复杂查询和分析场景。随大数据技术发展大量借鉴数据库的技术例如SQL语言、查询优化器等形成了大数据的数据仓库因其强大的分析能力成为主流。
近几年数据仓库和云原生技术相结合又演生出了云数据仓库解决了企业部署数据仓库的资源供给问题。云数据仓库作为大数据的高阶企业级平台能力因其开箱即用、无限扩展、简易运维等能力越来越受到人们的瞩目。
Wikipedia对数据仓库的定义
在计算机领域数据仓库英语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数据仓库的架构阿里巴巴上层逐步构建了“数据安全体系”、“数据质量”、“数据治理”、“数据标签”等管理能力并最终形成了阿里巴巴的大数据中台。可以说作为最早数据中台概念的提出者阿里巴巴的数据中台得益于数据仓库的架构。 04 数据湖 VS 数据仓库
综上数据仓库和数据湖是大数据架构的两种设计取向。两者在设计的根本分歧点是对包括存储系统访问、权限管理、建模要求等方面的把控。
数据湖优先的设计通过开放底层文件存储给数据入湖带来了最大的灵活性。进入数据湖的数据可以是结构化的也可以是半结构化的甚至可以是完全非结构化的原始日志。另外开放存储给上层的引擎也带来了更多的灵活度各种引擎可以根据自己针对的场景随意读写数据湖中存储的数据而只需要遵循相当宽松的兼容性约定这样的松散约定当然会有隐患后文会提到。
但同时文件系统直接访问使得很多更高阶的功能很难实现例如细粒度小于文件粒度的权限管理、统一化的文件管理和读写接口升级也十分困难需要完成每一个访问文件的引擎升级才算升级完毕。
而数据仓库优先的设计更加关注的是数据使用效率、大规模下的数据管理、安全/合规这样的企业级成长性需求。数据经过统一但开放的服务接口进入数据仓库数据通常预先定义 schema用户通过数据服务接口或者计算引擎访问分布式存储系统中的文件。
数据仓库优先的设计通过抽象数据访问接口/权限管理/数据本身来换取更高的性能无论是存储还是计算、闭环的安全体系、数据治理的能力等这些能力对于企业长远的大数据使用都至关重要我们称之为成长性。
灵活性和成长性对于处于不同时期的企业来说重要性不同。
1. 当企业处于初创阶段数据从产生到消费还需要一个创新探索的阶段才能逐渐沉淀下来那么用于支撑这类业务的大数据系统灵活性就更加重要数据湖的架构更适用。
2. 当企业逐渐成熟起来已经沉淀为一系列数据处理流程问题开始转化为数据规模不断增长处理数据的成本不断增加参与数据流程的人员、部门不断增多那么用于支撑这类业务的大数据系统成长性的好坏就决定了业务能够发展多远。数据仓库的架构更适用。
本文有观察到相当一部分企业尤其是新兴的互联网行业从零开始架构的大数据技术栈正是伴随开源 Hadoop 体系的流行经历了这样一个从探索创新到成熟建模的过程。在这个过程中因为数据湖架构太过灵活而缺少对数据监管、控制和必要的治理手段导致运维成本不断增加、数据治理效率降低企业落入了『数据沼泽』的境地即数据湖中汇聚了太多的数据反而很难高效率的提炼真正有价值的那部分。
最后只有迁移到数据仓库优先设计的大数据平台才解决了业务成长到一定规模后所出现的运维、成本、数据治理等问题。还是举阿里巴巴的例子阿里巴巴成功的数据中台战略正是在 2015 年前后阿里巴巴全集团完成 MaxCompute数据仓库 对多个 Hadoop 数据湖的完全替换登月项目才逐步形成的。 05 下一代演进方向湖仓一体
经过对数据湖和数据仓库的深入阐述和比较本文认为数据湖和数据仓库作为大数据系统的两条不同演进路线有各自特有的优势和局限性。
数据湖和数据仓库一个面向初创用户友好一个成长性更佳。对企业来说数据湖和数据仓库是否必须是一个二选一的选择题是否能有一种方案同时兼顾数据湖的灵活性和云数据仓库的成长性将二者有效结合起来为用户实现更低的总体拥有成本
将数仓和数据湖融合在一起也是业界近年的趋势多个产品和项目都做过对应的尝试
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极大提升了使用的复杂度。 而DeltaLake则选择了保证以Spark为主要支持引擎的体验相对牺牲对其他主流引擎的兼容性。这对其他引擎访问数据湖中的Delta数据造成了诸多的限制和使用不便。例如Presto要使用DeltaLake表需要先用Spark创建manifest文件再根据manifest创建外部表同时还要注意manifest文件的更新问题而Hive要使用DeltaLake表限制更多不仅会造成元数据层面的混乱甚至不能写表。
上述在数据湖架构上建立数仓的若干尝试并不成功这表明数仓和数据湖有本质的区别在数据湖体系上很难建成完善的数仓。数据湖与数据仓库两者很难直接合并成一套系统因此作者团队开始基于融合两者的思路进行探索。
所以我们提出下一代的大数据技术演进方向湖仓一体即打通数据仓库和数据湖两套体系让数据和计算在湖和仓之间自由流动从而构建一个完整的有机的大数据技术生态体系。
我们认为构建湖仓一体需要解决三个关键问题
1. 湖和仓的数据/元数据无缝打通且不需要用户人工干预
2. 湖和仓有统一的开发体验存储在不同系统的数据可以通过一个统一的开发/管理平台操作
3. 数据湖与数据仓库的数据系统负责自动caching/moving系统可以根据自动的规则决定哪些数据放在数仓哪些保留在数据湖进而形成一体化
我们将在下一章详细介绍阿里云湖仓一体方案如何解决这三个问题。 06 阿里云湖仓一体方案
6.1 整体架构
阿里云MaxCompute在原有的数据仓库架构上融合了开源数据湖和云上数据湖最终实现了湖仓一体化的整体架构图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 FormationMaxCompute湖仓一体方案也会支持对该数据湖中的统一元数据服务的一键映射能力。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湖仓一体为企业提供了一种更灵活更高效更经济的数据平台解决方案既适用于全新构建大数据平台的企业也适合已有大数据平台的企业进行架构升级可以保护现有投资和实现资产利旧。
6.3 典型客户案例新浪微博应用「湖仓一体」构建混合云AI计算中台
案例背景
微博机器学习平台团队主要做社交媒体领域里的推荐主要做社交媒体领域里的推荐/排序、文本/图像分类、反垃圾/反作弊等技术。
技术架构上主要围绕开源Hadoop数据湖解决方案一份HDFS存储多种计算引擎hive、spark、flink以满足以AI为主的多计算场景需求。但微博作为国内Top的社交媒体应用当前的业务体量和复杂性已然进入到开源“无人区”开源数据湖方案在性能和成本方面都无法满足微博的要求。
微博借助阿里巴巴强大的飞天大数据和AI平台能力MaxCPAIDW 解决了超大规模下的特征工程、模型训练以及矩阵计算的性能瓶颈问题进而形成了阿里巴巴MaxCompute平台数仓 开源平台数据湖共存的格局。
核心痛点
微博希望借助这两套异构的大数据平台既保持面向AI的各类数据和计算的灵活性又解决超大规模下的计算和算法的性能/成本问题。但因为这两套大数据平台在集群层面完全是割裂的数据和计算无法在两个平台里自由流动无形之中增加了大量的数据移动和计算开发等成本进而制约了业务的发展。
主要的痛点是1安排专人专项负责训练数据同步工作量巨大 2 训练数据体量大导致耗时多无法满足实时训练的要求 3 新写SQL数据处理query无法复用Hive SQL原有query。 解决方案
为了解决上述的痛点问题阿里云产品团队和微博机器学习平台团队联合共建湖仓一体新技术打通了阿里巴巴MaxCompute云数仓和EMR Hadoop数据湖构建了一个跨湖和仓的AI计算中台。
MaxCompute产品全面升级网络基础设施打通用户VPC私域且依托Hive数据库一键映射和强大完善的SQL/PAI引擎能力将MaxCompute云数仓和EMR Hadoop数据湖技术体系无缝对接实现湖和的仓统一且智能化管理和调度。 案例价值
不仅融合了数据湖和数据仓库的优势在灵活性和效率上找到最佳平衡还快速构建了一套统一的AI计算中台极大提升该机器学习平台团队的业务支撑能力。无须进行数据搬迁和作业迁移即可将一套作业无缝灵活调度在MaxCompute集群和EMR集群中。SQL数据处理任务被广泛运行到MaxCompute集群性能有明显提升。基于阿里巴巴PAI丰富且强大的算法能力封装出多种贴近业务场景的算法服务满足更多的业务需求。MaxCompute云原生的弹性资源和EMR集群资源形成互补两套体系之间进行资源的削峰填谷不仅减少作业排队且降低整体成本。 07 总结
数据湖和数据仓库是在今天大数据技术条件下构建分布式系统的两种数据架构设计取向要看平衡的方向是更偏向灵活性还是成本、性能、安全、治理等企业级特性。
但是数据湖和数据仓库的边界正在慢慢模糊数据湖自身的治理能力、数据仓库延伸到外部存储的能力都在加强。在这样的背景之下MaxCompute 率先提出湖仓一体为业界和用户展现了一种数据湖和数据仓湖互相补充协同工作的架构。
这样的架构同时为用户提供了数据湖的灵活性和数据仓库的诸多企业级特性将用户使用大数据的总体拥有成本进一步降低我们认为是下一代大数据平台的演进方向。
