精华内容
下载资源
问答
  • Iceberg构建湖仓一体架构的必备,与Delta Lake、hudi齐名,数据湖技术三驾马车。
  • 本文作者来自阿里巴巴计算平台部门,在深度参与阿里巴巴大数据 / 数据中台领域建设之后,将对数据湖和数据仓库的来龙去脉进行深入剖析,阐述两者融合演进的新方向——湖仓一体。 大数据 20 年发展的变与不变 概述 ...

    近几年,随着数据湖概念的兴起,业界对于数据仓库和数据湖的对比甚至争论始终不断。数据仓库和数据湖的区别到底是什么?本文作者来自阿里巴巴计算平台部门,在深度参与阿里巴巴大数据 / 数据中台领域建设之后,将对数据湖和数据仓库的来龙去脉进行深入剖析,阐述两者融合演进的新方向——湖仓一体。  

    大数据 20 年发展的变与不变 

    概述

    大数据从本世纪初发展到现在,已经历 20 年。从宏观层面观察其中的发展规律,可以高度概括成如下五个方面:

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

    • 数据保持高速增长

    • 大数据作为新的生产要素,得到广泛认可

    • 数据管理能力成为新的关注点

    • 引擎技术进入收敛期

    • 平台技术演进出两个趋势,数据湖 VS 数据仓库。两者均关注数据存储和管理(平台技术),但方向不同。

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

    纵观大数据的发展历史,可以看出数据仓库和数据湖有着截然不同的发展脉络。大体上,计算机科学领域的数据处理技术的发展,主要分为四个阶段:

    阶段一:数据库时代。数据库最早诞生于 20 世纪的 60 年代,今天人们所熟知的关系型数据库则出现在 20 世纪 70 年代,并在后续的 30 年左右时间里大放异彩,诞生了很多优秀的关系型数据库,如 Oracle、SQL Server、MySQL、PostgresSQL 等,成为当时主流计算机系统不可或缺的组成部分。到 20 世纪 90 年代,数据仓库的概念诞生。此时的数据仓库概念更多表达的是如何管理企业中多个数据库实例的方法论,但受限于单机数据库的处理能力以及多机数据库(分库分表)长期以来的高昂价格,此时的数据仓库距离普通企业和用户都还很遥远。人们甚至还在争论数据仓库(统一集中管理)和数据集市(按部门、领域的集中管理)哪个更具可行性。

    阶段二:大数据技术的「探索期」。2000 年左右,随着互联网的爆发,动辄几十亿、上百亿的页面以及海量的用户点击行为,开启了全球的数据量急剧增加的新时代。传统的数据库方案再也无力以可接受的成本提供计算力,巨大的数据处理需求开始寻找突破口,大数据时代开始萌芽。Google 先后发表 3 篇经典论文(GFS、MapReduce、BigTable),奠基了这个大数据时代的基本技术框架,即分布式存储、分布式调度以及分布式计算模型。随后,几乎是在同一时期,诞生了包括 Google,微软 Cosmos 以及开源 Hadoop 为代表的优秀分布式技术体系,当然,这其中也包括阿里巴巴的飞天系统。此时人们兴奋于追求数据的处理规模,即『大』数据,没有闲暇争论是数据仓库还是数据湖。

    阶段三:大数据技术的「发展期」。21 世纪第二个 10 年,随着越来越多的资源投入到大数据计算领域,大数据技术进入一个蓬勃发展的阶段,整体开始从能用转向好用。代替手写 MapReduce 作业,是如雨后春笋般出现的各种以 SQL 为表达的计算引擎,极大降低了大数据技术的使用成本,数据库时代人们梦想的大一统的数据仓库终于成为现实,各种数据库时代的方法论开始抬头。这个时期技术路线开始出现细分。云厂商主推的如 AWS Redshift、Google BigQuery,包括 MaxCompute 这样的集成系统称为大数据时代的数据仓库。而以开源 Hadoop 体系为代表的的开放式 HDFS 存储、开放的文件格式、开放的元数据服务以及多种引擎(Hive、Presto、Spark、Flink 等)协同工作的模式,则形成了数据湖的雏形。

    阶段四:大数据技术「普及期」。当前,大数据技术早已不是什么火箭科技,而已经渗透到各行各业,大数据的普及期已经到来。市场对大数据产品的要求,除了规模、性能、简单易用,提出了成本、安全、稳定性等更加全面的企业级生产的要求。

    开源 Hadoop 线,引擎、元数据、存储等基础部件的迭代更替进入相对稳态,大众对开源大数据技术的认知达到空前的水平。一方面,开放架构的便利带来了不错的市场份额,另一方面开放架构的松散则使开源方案在企业级能力构建上遇到瓶颈,尤其是数据安全、身份权限强管控、数据治理等方面,协同效率较差。同时引擎自身的发展也对已有的开放架构提出了更多挑战,Delta Lake、Hudi 这样自闭环设计的出现使得一套存储、一套元数据、多种引擎协作的基础出现了某种程度的裂痕。

    真正将数据湖概念推而广之的是 AWS。AWS 构筑了一套以 S3 为中心化存储、Glue 为元数据服务,E-MapReduce、Athena 为引擎的开放协作式的产品解决方案。它的开放性和开源体系类似,并在 2019 年推出 Lake Formation 解决产品间的安全授信问题。这套架构对于开源技术体系的用户来说,架构相近理解容易,仍然相当有吸引力。AWS 之后,各个云厂商也纷纷跟进数据湖的概念,并在自己的云服务上提供类似的产品解决方案。

    云厂商主推的数据仓库类产品则发展良好,数仓核心能力方面持续增强。性能、成本方面极大提升(如 MaxCompute 连续三年刷新 TPCx-BigBench 世界记录),数据管理能力空前增强(发展出数据中台建模理论和智能数仓),企业级安全能力大为繁荣(如细粒度数据安全控制、服务可用性 SLA 等),在联邦计算方面也普遍做了增强,一定程度上开始将非数仓自身存储的数据纳入管理,和数据湖的边界日益模糊。

    综上所述,数据仓库和数据湖是伴随着大数据技术发展,进化而来的两种不同的大数据平台技术,有着各自的特点和应用场景,在企业数字化建设中均扮演着重要的角色。

    图 2. 20 年大数据发展之路

    数据湖的本质和技术架构演进

    近几年数据湖的概念非常火热,各家对数据湖的定义不尽相同,但不论如何,数据湖的本质其实都包含如下四部分:

    1. 统一的存储系统

    2. 存储原始数据

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

    4. 数据湖与上云无关

    从上述四个标准判断,开源大数据的 Hadoop HDFS 存储系统就是一个标准的数据湖架构,具备统一的原始数据存储架构。而近期被广泛谈到的数据湖,其实是一个狭义的概念,特指“基于云上托管存储系统的数据湖系统,架构上采用存储计算分离的体系”。例如基于 AWS S3 系统或者阿里云 OSS 系统构建的数据湖。

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

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

    阶段一:自建开源 Hadoop 数据湖架构,原始数据统一存放在 HDFS 系统上,引擎以 Hadoop 和 Spark 开源生态为主,存储和计算一体。缺点是需要企业自己运维和管理整套集群,成本高且集群稳定性差。

    阶段二:云上托管 Hadoop 数据湖架构(即 EMR 开源数据湖),底层物理服务器和开源软件版本由云厂商提供和管理,数据仍统一存放在 HDFS 系统上,引擎以 Hadoop 和 Spark 开源生态为主。这个架构通过云上 IaaS 层提升了机器层面的弹性和稳定性,使企业的整体运维成本有所下降,但企业仍然需要对 HDFS 系统以及服务运行状态进行管理和治理,即应用层的运维工作。同时因为存储和计算耦合在一起,两种资源无法独立扩展。

    阶段三:云上数据湖架构,即云上纯托管的存储系统逐步取代 HDFS,成为数据湖的存储基础设施,并且引擎丰富度也不断扩展。除了 Hadoop 和 Spark 的生态引擎之外,各云厂商还发展出面向数据湖探查分析产品。这个架构仍然保持了一个存储和多个引擎的特性,相对于原生 HDFS 的数据湖架构的优势在于:

    帮助用户摆脱原生 HDFS 系统运维困难的问题。分离后的存储系统可以独立扩展,不再需要与计算耦合,可降低整体成本当用户采用数据湖架构之后,客观上也帮助客户完成了存储统一化(解决多个 HDFS 数据孤岛的问题)。

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

    数据仓库的诞生及与数据中台的关系

    数据仓库的概念最早来源于数据库领域,主要处理面向数据的复杂查询和分析场景。随着大数据技术发展,大量借鉴数据库的技术,例如 SQL 语言、查询优化器等,形成了大数据的数据仓库,因其强大的分析能力,成为主流。近几年,数据仓库和云原生技术相结合,又演生出了云数据仓库,解决了企业部署数据仓库的资源供给问题。云数据仓库作为大数据的高阶(企业级)平台能力,因其开箱即用、无限扩展、简易运维等能力,越来越受到人们的瞩目。

    笔者认为,数据仓库的本质包含如下三部分:

    1. 内置的存储系统,数据通过抽象的方式提供(例如采用 Table 或者 View),不暴露文件系统;

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

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

    从上述的标准判断,无论传统数据仓库还是新兴的云数据仓库系统(AWS Redshift、Google BigQuery、阿里云 MaxCompute)均体现了数仓的设计本质,它们均没有对外暴露文件系统,而是提供了数据进出的服务接口。这个设计可以带来多个优势:

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

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

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

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

    正因为如此,阿里巴巴飞天大数据平台建设之初,在选型的时候就采用了数据仓库的架构,即 MaxCompute 大数据平台。MaxCompute(原 ODPS) 既是阿里巴巴经济体的大数据平台,又是阿里云上的在线大数据计算服务(百度搜索阿里云官网 - 左侧大数据与人工智能选择 MaxCompute)。

    图 5. MaxCompute 云数仓产品架构

    得益于 MaxCompute 数据仓库的架构,阿里巴巴上层逐步构建了“数据安全体系”、“数据质量”、“数据治理”、“数据标签”等管理能力,并最终形成了阿里巴巴的大数据中台。可以说,作为最早数据中台概念的提出者,阿里巴巴的数据中台得益于数据仓库的架构。

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

    数据湖 VS 数据仓库

    综上,数据仓库和数据湖,是大数据架构的两种设计取向。两者在设计的根本分歧点是对包括存储系统访问、权限管理、建模要求等方面的把控。

    数据湖优先的设计,通过开放底层文件存储,给数据入湖带来了最大的灵活性。进入数据湖的数据可以是结构化的,也可以是半结构化的,甚至可以是完全非结构化的原始日志。另外,开放存储给上层的引擎也带来了更多的灵活度,各种引擎可以根据自己针对的场景随意读写数据湖中存储的数据,而只需要遵循相当宽松的兼容性约定(这样的松散约定当然会有隐患,后文会提到)。但同时,文件系统直接访问使得很多更高阶的功能很难实现,例如,细粒度(小于文件粒度)的权限管理、统一化的文件管理和读写接口升级也十分困难(需要完成每一个访问文件的引擎升级,才算升级完毕)。

    而数据仓库优先的设计,更加关注的是数据使用效率、大规模下的数据管理、安全 / 合规这样的企业级成长性需求。数据经过统一但开放的服务接口进入数据仓库,数据通常预先定义 schema,用户通过数据服务接口或者计算引擎访问分布式存储系统中的文件。数据仓库优先的设计通过抽象数据访问接口 / 权限管理 / 数据本身,来换取更高的性能(无论是存储还是计算)、闭环的安全体系、数据治理的能力等,这些能力对于企业长远的大数据使用都至关重要,我们称之为成长性。

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

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

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

    当企业处于初创阶段,数据从产生到消费的生命周期还需要一个创新探索的阶段才能逐渐沉淀下来,那么用于支撑这类业务的大数据系统,灵活性就更加重要,数据湖的架构更适用。

    当企业逐渐成熟起来,已经沉淀为一系列数据处理流程,问题开始转化为数据规模不断增长,处理数据的成本不断增加,参与数据流程的人员、部门不断增多,那么用于支撑这类业务的大数据系统,成长性的好坏就决定了业务能够发展多远。数据仓库的架构更适用。

    很多企业(尤其是新兴的互联网行业)正在经历这样一个从探索创新到成熟建模的过程。在这个过程中,因为数据湖架构太过灵活而缺少对数据监管、控制和必要的治理手段,导致运维成本不断增加、数据治理效率降低,企业落入了“数据沼泽”的境地,即数据湖中汇聚了太多的数据,反而很难高效率地提炼真正有价值的那部分。最后只有迁移到数据仓库优先设计的大数据平台,才解决了业务成长到一定规模后所出现的运维、成本、数据治理等问题。

    阿里巴巴的数据中台战略,正是在 2015 年前后阿里巴巴全集团完成 MaxCompute(数据仓库) 对多个 Hadoop( 数据湖)的完全替换(登月项目)才逐步形成的。

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

    下一代演进方向:湖仓一体

    经过对数据湖和数据仓库的深入阐述和比较,本文认为数据湖和数据仓库作为大数据系统的两条不同演进路线,有各自特有的优势和局限性。数据湖和数据仓库一个面向初创用户友好,一个成长性更佳。对企业来说,数据湖和数据仓库是否必须是一个二选一的选择题?是否能有一种方案同时兼顾数据湖的灵活性和云数据仓库的成长性,将二者有效结合起来为用户实现更低的总体拥有成本?

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

    数仓支持数据湖访问

    • 2017 年 Redshift 推出 Redshift Spectrum,支持 Redsift 数仓用户访问 S3 数据湖的数据。

    • 2018 年阿里云 MaxCompute 推出外包能力,支持访问包括 OSS/OTS/RDS 数据库在内的多种外部存储。

    但是无论是 Redshift Spectrum 还是 MaxCompute 的外部表,仍旧需要用户在数仓中通过创建外部表来将数据湖的开放存储路径纳入数仓的概念体系——由于一个单纯的开放式存储并不能自发描述其数据本身的变化,因此为这些数据创建外部表、添加分区(本质上是为数据湖中的数据建立 schema)无法完全自动化(需要人工或者定期触发 Alter table add partition 或 msck)。这对于低频临时查询尚能接受,对于生产使用来说,未免有些复杂。

    数据湖支持数仓能力

    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 三种查询类型,并给出了一个支持矩阵(如图 9),极大提升了使用的复杂度。   

    图 9. Hudi Support Matrix(来自网络)

    而 DeltaLake 则选择了保证以 Spark 为主要支持引擎的体验,相对牺牲对其他主流引擎的兼容性。这对其他引擎访问数据湖中的 Delta 数据造成了诸多的限制和使用不便。例如 Presto 要使用 DeltaLake 表,需要先用 Spark 创建 manifest 文件,再根据 manifest 创建外部表,同时还要注意 manifest 文件的更新问题;而 Hive 要使用 DeltaLake 表限制更多,不仅会造成元数据层面的混乱,甚至不能写表。

    上述在数据湖架构上建立数仓的若干尝试并不成功,这表明数仓和数据湖有本质的区别,在数据湖体系上很难建成完善的数仓。数据湖与数据仓库两者很难直接合并成一套系统,因此作者团队,开始基于融合两者的思路进行探索。提出下一代的大数据技术演进方向:湖仓一体,即打通数据仓库和数据湖两套体系,让数据和计算在湖和仓之间自由流动,从而构建一个完整的有机的大数据技术生态体系。

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

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

    2. 湖和仓有统一的开发体验,存储在不同系统的数据,可以通过一个统一的开发 / 管理平台操作;

    3. 数据湖与数据仓库的数据,系统负责自动 caching/moving,系统可以根据自动的规则决定哪些数据放在数仓,哪些保留在数据湖,进而形成一体化;我们将在下一章详细介绍阿里云湖仓一体方案如何解决这三个问题。

    阿里云湖仓一体方案

    整体架构

    阿里云 MaxCompute 在原有的数据仓库架构上,融合了开源数据湖和云上数据湖,最终实现了湖仓一体化的整体架构(图 10)。在该架构中,尽管底层多套存储系统并存,但通过统一的存储访问层和统一的元数据管理,向上层引擎提供一体的封装接口,用户可以同时查询数据仓库和数据湖中的表。

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

    针对上文提到的湖仓一体的三个关键问题,MaxCompute 实现了以下 4 个关键技术点。

    快速接入

    MaxCompute 全新自创 PrivateAccess 网络连通技术,在遵循云虚拟网络安全标准的前提下,实现多租户模式下特定用户作业定向与 IDC/ECS/EMR Hadoop 集群网络整体打通能力,具有低延迟、高独享带宽的特点。

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

    统一数据 / 元数据管理

    MaxCompute 实现湖仓一体化的元数据管理,通过 DB 元数据一键映射技术,实现数据湖和 MaxCompute 数仓的元数据无缝打通,无须联邦查询方式里的人工操作。MaxCompute 通过向用户开放创建 external project 的形式,将数据湖 HiveMetaStore 中的整个 database 直接映射为 MaxCompute 的 project,对 Hive Database 的改动会实时反应在这个 project 中。与此同时,阿里云 EMR 数据湖解决方案在今年云栖大会也推出了 Data Lake Formation,湖仓一体方案也会支持对该数据湖中的统一元数据服务的一键映射能力。

    MaxCompute 实现湖仓一体化的存储访问层,不仅支持内置优化的存储系统,也无缝的支持外部存储系统。既支持 HDFS 数据湖,也支持 OSS 云存储数据湖,可读写各种开源文件格式。

    统一开发体验

    数据湖里的 Hive DataBase 映射为 MaxCompute external project,和普通 project 别无二致,同样享受 MaxCompute 数仓里的数据开发、追踪和管理功能。基于 DataWorks 强大的数据开发 / 管理 / 治理能力,提供统一的湖仓开发体验,降低两套系统的管理成本。

    MaxCompute 高度兼容 Hive/Spark,支持一套任务可以在湖仓两套体系中灵活无缝的运行。

    同时,MaxCompute 也提供高效的数据通道接口,可以让数据湖中的 Hadoop 生态引擎直接访问,提升了数仓的开放性。

    自动数仓

    湖仓一体需要用户根据自身资产使用情况将数据在湖和仓之间进行合理的分层和存储,以最大化湖和仓的优势。MaxCompute 开发了一套智能 cache 技术,根据对历史任务的分析来识别数据冷热度,从而自动利用闲时带宽将数据湖中的热数据以高效文件格式 cache 在数据仓库中,进一步加速数据仓库的后续数据加工流程。不仅解决了湖仓之间的带宽瓶颈问题,也达到了无须用户参与即可实现数据分层管理 / 治理以及性能加速的目的。

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

    基于 MaxCompute 湖仓一体技术,DataWorks 进一步对湖仓两套系统进行封装,屏蔽湖和仓异构集群信息,构建一体化的大数据中台,实现一套数据、一套任务在湖和仓之上无缝调度和管理。

    企业可以使用湖仓一体化的数据中台能力,优化数据管理架构,充分融合数据湖和数据仓库各自优势。使用数据湖做集中式的原始数据存储,发挥数据湖的灵活和开放优势。又通过湖仓一体技术将面向生产的高频数据和任务,无缝调度到数据仓库中,以得到更好的性能和成本,以及后续一系列面向生产的数据治理和优化,最终让企业在成本和效率之间找到最佳平衡。既适用于全新构建大数据平台的企业,也适合已有大数据平台的企业进行架构升级,可以保护现有投资和实现资产利旧。

    图 11. DataWorks 湖仓一体化数据中台

    新浪微博的”湖仓一体“应用

    微博机器学习平台团队,主要做社交媒体领域里的推荐主要做社交媒体领域里的推荐 / 排序、文本 / 图像分类、反垃圾 / 反作弊等技术。技术架构上主要围绕开源 Hadoop 数据湖解决方案,一份 HDFS 存储 + 多种计算引擎(hive、spark、flink),以满足以 AI 为主的多计算场景需求。

    但微博作为国内 Top 的社交媒体应用,当前的业务体量和复杂性已然进入到开源“无人区”,开源数据湖方案在性能和成本方面都无法满足微博的要求。微博借助阿里巴巴飞天大数据和 AI 平台能力(MaxCompute+PAI+DataWorks ),解决了超大规模下的特征工程、模型训练以及矩阵计算的性能瓶颈问题,进而形成了阿里巴巴 MaxCompute 平台(数仓)+ 开源平台(数据湖)共存的格局。

    微博希望借助这两套异构的大数据平台,既保持面向 AI 的各类数据和计算的灵活性,又解决超大规模下的计算和算法的性能 / 成本问题。但因为这两套大数据平台在集群层面完全是割裂的,数据和计算无法在两个平台里自由流动,无形之中增加了大量的数据移动和计算开发等成本,进而制约了业务的发展。

    主要的痛点是:

    • 安排专人专项负责训练数据同步,工作量巨大;

    • 训练数据体量大,导致耗时多,无法满足实时训练的要求;

    •  新写 SQL 数据处理 query,无法复用 Hive SQL 原有 query。

    图 12. 新浪微博业务痛点示意图

    为了解决上述的痛点问题,阿里云产品团队和微博机器学习平台团队联合共建湖仓一体新技术,打通了阿里巴巴 MaxCompute 云数仓和 EMR Hadoop 数据湖,构建了一个跨湖和仓的 AI 计算中台。MaxCompute 产品全面升级网络基础设施,打通用户 VPC 私域,且依托 Hive 数据库一键映射和强大完善的 SQL/PAI 引擎能力,将 MaxCompute 云数仓和 EMR Hadoop 数据湖技术体系无缝对接,实现湖和仓的统一且智能化管理和调度。

    图 13. 微博湖仓一体架构图

    这套体系不仅融合了数据湖和数据仓库的优势,在灵活性和效率上找到最佳平衡,还快速构建了一套统一的 AI 计算中台,极大提升该机器学习平台团队的业务支撑能力。无须进行数据搬迁和作业迁移,即可将一套作业无缝灵活调度在 MaxCompute 集群和 EMR 集群中。

    SQL 数据处理任务被广泛运行到 MaxCompute 集群,性能有明显提升。基于阿里巴巴 PAI 丰富且强大的算法能力,封装出多种贴近业务场景的算法服务,满足更多的业务需求。

    MaxCompute 云原生的弹性资源和 EMR 集群资源形成互补,两套体系之间进行资源的削峰填谷,不仅减少作业排队,还能降低整体成本。

    总   结

    数据湖和数据仓库,是在今天大数据技术条件下构建分布式系统的两种数据架构设计取向,要看平衡的方向是更偏向灵活性还是成本、性能、安全、治理等企业级特性。但是数据湖和数据仓库的边界正在慢慢模糊,数据湖自身的治理能力、数据仓库延伸到外部存储的能力都在加强。

    在这样的背景之下,MaxCompute 率先提出湖仓一体,为业界和用户展现了一种数据湖和数据仓湖互相补充,协同工作的架构。这样的架构同时为用户提供了数据湖的灵活性和数据仓库的诸多企业级特性,将用户使用大数据的总体拥有成本进一步降低,我们认为是下一代大数据平台的演进方向。

    展开全文
  • 湖仓一体参考架构 湖仓一体架构除了满足以上提到的关键特性,在实现中还需要解决以下几个关键问题: 1. 支持丰富、便捷、可靠的数据入湖接入,比如支持ACID事务控制,缩短数据入湖链路 2. 支持统一的元数据,打通...

    *本文为「码上观世界」原创内容 

    今日奇想:火星的现状被认为是未来地球的模样,目前世界主要国家相继探测火星生命存在的可能性,但是仍没有重要进展。假如火星在漫长的历史变迁的某一段时期存在高等生物,并相继发展到了一定高度的文明,那么在火星变得温度极端不适合星球表面生存的时候,一定会尝试往底层深处挖掘洞穴的方式延缓灭亡,类似地球早期原始人洞穴生活那样。此外,文明生活也会留下历史古迹,这些都是考古学家和民间盗墓人士的绝活,因此有必要在人类到达火星前,加快培训这类高手上岗。

    数仓与数据湖

    数据仓库之父Bill Inmon指出:“数据仓库是一个面向主题的、集成的、反映历史变化的、非易变的数据集合,用于支持管理决策过程。”而数据湖,AWS给出的定义是“一个集中式存储库,允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据(无需先对数据进行结构化处理),并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习,以指导做出更好的决策。”

    AWS列出了数仓和数据湖两者各自的特性:

    有微软的分析师对比数据湖和数据仓库各自的优缺点,并列举如下:

    湖仓一体具有以下五个关键特性:

    • 支持分析结构化和非结构化数据;

    • 适用于分析师和数据科学家,不仅支持报表,而且支持机器学习和人工智能相关用例;

    • 数据可治理,避免产生沼泽;

    • 架构鲁棒安全,确保利益相关者能正确访问以数据为中心的安全架构;

    • 以合理代价实现有效扩展

    数仓平台架构演进

    第一代数仓平台计算与存储耦合,扩容和运维成本过高,且不支持非结构化数据。

    第二代数仓平台基于数据湖+数仓的双层架构虽然解决了计算和存储耦合的问题,但是相比一代数仓平台,又多了从运营系统到数据湖的ETL以及从数仓到湖的ETL过程,增加了系统的复杂度和脆弱性,数据的重复存储和计算引入了额外的成本。同时基于数据湖的数据应用失去了数据仓库的丰富管理功能,以及缺乏必要的事务管理功能和跟数据仓库相适应的性能优化能力。

    第三代数仓平台结合数据仓库和数据湖各自的优点,将数据仓库的丰富管理功能和跟数据仓库相适应的性能优化能力与支持多种数据格式的低成本存储的数据湖的灵活性结合起来,并引入统一元数据层,不仅统一了基于表的数据访问和基于文件的数据访问方式,还实现了事务管理功能和其他诸如访问控制、版本控制等管理功能,形成lakehouse架构。

    Lakehouse 是一种结合了数据湖和数据仓库优势的新范式,解决了数据湖的局限性。Lakehouse 使用新的系统设计:直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据架构和数据管理功能。Lakehouse首先基于标准文件格式(如Apache Parquet、ORC等)将数据存储在独立部署的低成本对象存储(例如Amazon S3、Aliyun OSS)中,并允许客户端使用标准文件格式直接从该存储中读取对象,这样许多ML库(例如TensorFlow和Spark MLlib)就可以读取数据湖文件格式(如Parquet)。其次,为了做到事务管理和版本控制,Lakehouse提供了公共元数据层,数据访问通过逻辑表的形式对外暴露,比如lakehouse框架实现之一的Apache Iceberg的表由一系列快照文件组成,每个快照文件(snapshot)存储一个清单列表文件(manifest list),清单列表文件记录1至多个清单文件(manifest file)的路径和相关文件的统计数量信息等,而清单文件记录了组成某个快照的数据文件(data file)列表。每行都是每个数据文件的详细描述,包括数据文件的状态、文件路径、分区信息、列级别的统计信息(比如每列的最大最小值、空值数等)、文件的大小以及文件里面数据的行数等信息。数据文件是 Apache Iceberg 表真实存储数据的文件,可以采用parquet、avro等格式。它们之间的关系如下图所示:

    有了公共元数据层,高级数据处理库(ML等)就可以查询表所属的文件列表,然后直接读取并处理文件。另外,为了解决在实时数据同步和离线数据同步场景中一份数据被两次ETL(一次增量传给实时处理,一份全量传给批量处理)带来的数据处理链路复杂和数据重复存储带来的问题,lakehouse引入了增量更新、事务管理功能和版本控制等高级特性,不仅将ETL过程大大缩短而且将原本的离线日T+1时间缩短到分钟级别。

    最后,lakehouse面临的最大技术问题是在受限于网络带宽且独立存储的外部开放数据格式的情境下,如何优化SQL性能,相比之下经典数仓对SQL进行更彻底的优化(包括使用专有存储格式)。Lakehouse除了需要探讨是否存在不同于现有的标准格式(例如Parquet和ORC)的存储文件格式,还需要探讨在与格式无关的优化技巧。目前lakehouse常用的优化方式包括使用高性能的存储设备(如SSD、RAM缓存等),使用Parquet/ORC数据格式中的辅助数据结构(如BloomFilter、统计信息等)以及在这些现有格式内优化数据布局(如数据聚集和排序等)。

    经过优化改进后的lakehouse架构如下所示:

    实际上,Lakehouse代表了湖仓融合的一种方向:基于Hadoop体系的数据湖向数据仓库能力扩展,湖中建仓,从DataLake进化到LakeHouse。LakeHouse结合了数据湖和数据仓库特点,直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。目前业界已经涌现了一些LakeHouse产品,如Netflix开源Iceberg、Uber开源Hudi、Databricks的 DeltaLake。

    阿里云基于Hudi构建的OLAP数据湖产品便是这种融合方向的一个案例,它强化数据贴源层端的数据入湖功能,并在此基础上通过统一元数据和统一调度实现一定程度的数据聚合和应用。

    另一个融合方向是数据湖和数据仓库协同起来向湖仓一体的融合分析架构发展,随着企业数据量快速增长,不仅是结构化数据,也有非结构化数据,同时提出了对搜索/机器学习更多的能力要求,使得原来数仓技术不能够有效的处理复杂场景,为此需扩展原有系统,引入Hadoop大数据平台实现新类型数据、新业务场景的支持。在这个背景下由Gartner在2011年提出逻辑数据仓库的概念,预测企业数据分析倾向于转向一种更加逻辑化的架构,利用分布式处理、数据虚拟化以及元数据管理等技术,实现逻辑统一物理分开的协同体系。

    如下图的逻辑数仓采用与经典数仓类似的分层数据架构,区别在于在数据贴源层引入数据虚拟化技术,通过表视图的方式建立数据虚拟层,直接使用源库的数据进行过滤,清洗等功能,然后基于虚拟层再构建上层数据架构。数据虚拟层的引入避免了数据在不同系统之间集成的复杂度,有助于降低数据重复和提升数据质量。

    基于逻辑数仓的设计理念来构建数据湖,首要问题是实现统一的元数据,打通不同数据系统,使其具备数据共享和跨库分析能力,支持互联互通、计算下推、协同计算,实现数据多平台之间透明流动。采用这种架构的首次尝试产品是AWS的RedShift,为了支持访问S3的数据,RedShift通过Spectrum创建外表的形式将外部数据映射到RedShift:

    create external schema s3_external_schema 
    from data catalog 
    database 'spectrumdb' iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'create external database if not exists;
    
    
    CREATE  external table s3_external_schema.LINEITEM_CSV ( 
     L_ORDERKEY BIGINT,
     L_PARTKEY INT,
     L_SUPPKEY INT,
     L_LINENUMBER INT,
     L_QUANTITY DECIMAL(12,2),
     L_EXTENDEDPRICE DECIMAL(12,2),
     L_COMMENT VARCHAR(128))row format delimitedfields terminated by '|'stored as textfile
    location 's3://<your-bucket>/<xyz>/lineitem_csv/';
    

    创建的外部表跟内部表一样,注册到全局的元数据系统Glue Data Catalog 中,有了公共元数据,其他产品如RDS、Athena、EMR都可以基于元数据访问同样的一份数据(shared data)。值得一提的是Glue不仅负责管理元数据,还负责数据的爬网ETL任务运行和调度等。

    对Redshift Spectrum来说,访问外部数据需要人工创建外部表并导入外部数据,相对全自动导入外部元数据来讲,还不够彻底。阿里云的MaxCompute作为同样的云数仓产品,在解决无法访问EMR Hadoop集群的元数据问题时,使用数据自动映射的方式,全部导入元数据,在一个平台访问两个系统的数据。下图是阿里云为微博大数据平台提供的解决方案:将EMR Hadoop元数据映射到MaxCompute,然后基于统一的数据开发平台DataWorks进行数据开发和查询:

    为了避免热数据访问性能问题,MaxCompute通过智能调度技术,将面向生产的高频数据和任务,无缝调度到数据仓库中,以得到更好的性能和成本。相比Redshift,这一做法相对彻底,但是相对于AWS的整个数据产品体系来讲,该做法更显得是一种事后补救措施,并没有将其他存储产品的元数据打通。

    通过上述案例可知,两种融合方向并不是完全排斥的,比如Redshift Spectrum通过外表访问S3数据,可以看做第二种逻辑数仓的融合方案,但Redshift Spectrum本身又可看做构建于数据湖之上的数仓产品,这属于第一种融合方向。当然Redshift也可看做独立的数仓产品。

    湖仓一体参考架构

    湖仓一体架构除了满足以上提到的关键特性,在实现中还需要解决以下几个关键问题:

    1. 支持丰富、便捷、可靠的数据入湖接入,比如支持ACID事务控制,缩短数据入湖链路

    2. 支持统一的元数据,打通不同数据系统,使其具备数据共享和跨库分析能力,支持互联互通、计算下推、协同计算

    3. 支持统一数据开发,在一个平台访问多种数据源,支持低门槛的SQL开发方式

    4. 支持统一任务智能调度和运维监控

    5. 支持统一查询,通过联邦查询访问不同数据源

    上述架构的主链路是数据源入湖并进行Data lake Catalog元数据注册,然后基于统一元数据进行数据湖上的计算分析和数仓建模。该链路建立在存储和计算分离和共享元数据前提下,存储和计算分离保证了各自独立部署和扩容,共享元数据保证了计算引擎的独立和数据的共享。

    在数据接入层,支持Hive、S3、RDS、Kafka等不同数据源的接入,数据源接入既可以直接入湖再分析,也可以先分析再入湖,避免数据的重复存储和复杂集成问题。

    在元数据层,统一元数据既支持通过lakehouse架构统一管理的元数据,也支持通过映射外部数据源系统的元数据。

    数据集成与开发、数据治理与服务和运维监控、权限管理作为架构补充,提供了用户易于操作的管理界面和运维界面。

    在上层计算和查询层,基于统一元数据层,同时支持数据仓库建模和高级数据处理应用。多种独立的EMR计算引擎基于多版本的lakehouse架构既支持实时数据处理也支持历史全量数据处理。联邦查询基于元数据打通不同数据源的互联互通。

    建立真实有效湖仓一体架构,应遵循如下五个关键原则:

    • 计算和存储的解耦:首要原则是加入解耦和存储。存储便宜且持久,计算昂贵且短暂。计算和存储的解耦,可使系统灵活地按需升级并扩展计算服务。

    • 目标驱动的存储层:数据以多种形态和形式呈现,因此数据的存储方式应具灵活性,以适应数据的不同形态和用途。灵活性包括根据数据的种类及提供方式不同,提供关系层、图数据层、文档层以及 Blob 等多模态存储层。

    • 模块化的体系架构:该原则源自于 SOA,确保数据处于核心地位,以围绕数据开展所需服务为关键。基于数据开展数据抽取、处理、编目和分析等不同类型的服务,而不是借助流水线将数据提供给服务。

    • 聚焦于功能,而非技术:该原则体现了灵活性。功能的变化缓慢,但技术的变革日新月异。因此一定要聚焦于组件所完成的功能,进而可轻易追随技术的发展而替换旧技术。

    • 活动编目(Active cataloging):该项基本原则是避免数据湖沦为数据沼泽的关键。编目上需具有明确的治理原则,有助于确保数据充分记录到数据湖中。

    特别是数据编目尤其值得重视,AWS指出,“数据湖架构的主要挑战是存储原始数据而不监督内容。对于使数据可用的数据湖,它需要有定义的机制来编目和保护数据。没有这些元素,就无法找到或信任数据,从而导致“数据沼泽”的出现。满足更广泛受众的需求需要数据湖具有管理、语义一致性和访问控制。”

    参考链接:

    1. http://docs.media.bitpipe.com/io_12x/io_128955/item_1271002/r20-logical-data-warehouse-analyst-paper.pdf

    2. http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

    3. https://www.eckerson.com/articles/an-architect-s-view-of-the-data-lakehouse-perplexity-and-perspective

    4. https://aws.amazon.com/cn/big-data/datalakes-and-analytics/what-is-a-data-lake/

    5. https://mp.weixin.qq.com/s/XNcyPHPsqAhEFWEuxtafCg

    6. https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html

    7. https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html


    展开全文
  • 湖仓一体解决方案

    2021-04-30 18:32:37
    数据产生的背景 由于云技术的推动,企业对于跨公司、跨行业、跨领域的综合型数据的需求日趋明显,不同类型、格式数据之间的关联性碰撞越来越激烈,刺激着数据技术的创新发展,逐渐形成了大数据生态结构。当前面临...
    • 数据湖产生的背景

    由于云技术的推动,企业对于跨公司、跨行业、跨领域的综合型数据的需求日趋明显,不同类型、格式数据之间的关联性碰撞越来越激烈,刺激着数据技术的创新发展,逐渐形成了大数据生态结构。当前面临的问题的复杂性、综合性、交叉性,导致数据的使用成本越来越高,企业迫切需求能够有效打破数据孤岛、解决数据主权、统一数据汇聚和共享的混合式数据平台,数据湖应运而生。

    • 数据湖的概念

    早在2011年,福布斯的一篇文章中介绍了数据湖(Data Lake)的概念,针对数据仓库中的开发周期长、维护、开发成本高、丢失细节数据等不足进行的补充。数据湖是一种大型数据存储库和处理引擎。它能够大量存储各种类型的数据,拥有强大的信息处理能力和处理几乎无限的并发任务或工作的能力。维基百科对 Datalake 的解释:数据湖是一种在系统或存储库中以自然格式存储数据的方法,它有助于以各种模式和结构形式配置数据,通常是对象块或文件。形象的描述数据湖是指用湖来形容存储数据的平台,流入湖中的水表示未经处理的原始数据,这些数据包括表格、文本、声音、图像等等。湖中的水就代表存储的各种数据,在湖中可以进行数据的处理、分析、建模、加工,处理后的数据仍然可以留在湖中。而流出的水代表经过分析后,下流所需要的数据,再到达用户端,提供信息得出结论。

    数据湖的主要思想将是不用类型、不同领域的原始数据进行统一的存储,包括结构化数据、半结构化数据和二进制数据,形成一个容纳所有形式的数据的集中式数据存储集。这个数据存储集具备庞大的数据存储规模,T级别的计算能力,满足多元化的数据信息交叉分析以及大同容量、高速度的数据管道。

    • 数据湖的优势
    1. 轻松地收集数据:数据湖与数据仓库的一大区别就是,Schema On Read,即在使用数据时才需要Schema信息;而数据仓库是Schema On Write,即在存储数据时就需要设计好Schema。这样,由于对数据写入没有限制,数据湖可以更容易的收集数据。
    2. 从数据中发掘更多价值:数据仓库和数据市场由于只使用数据中的部分属性,所以只能回答一些事先定义好的问题;而数据湖存储所有最原始、最细节的数据,所以可以回答更多的问题。并且数据湖允许组织中的各种角色通过自助分析工具,对数据进行分析,以及利用AI、机器学习的技术,从数据中发掘更多的价值。
    3. 消除数据孤岛:数据湖中汇集了来自各个系统中的数据,这就消除了数据孤岛问题。
    4. 具有更好的扩展性和敏捷性:数据湖可以利用分布式文件系统来存储数据,因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格,因此天生具有更高的灵活性,从而提高了敏捷性。
    • 数据湖与数据仓库的区别

    数据仓库是一个优化的数据库,用于分析来自事务系统和业务线应用程序的关系数据。事先定义数据结构和 Schema 以优化快速 SQL 查询,其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换,因此可以充当用户可信任的“单一信息源”。

    数据湖概念是2011年提出来的,最初数据湖是数据仓库的补充,是为了解决数据仓库漫长的开发周期,高昂的开发、维护成本,细节数据丢失等问题出现的。数据湖与数据仓库很类似,都是数据存储,两者之间主要区别如下图所示。

     

    数据仓库是优化后的数据库,在存储数据之前要先定义好数据结构。而数据湖是一个数据存储的平台,不需要定义数据,能够自由存储不同类型的数据。在加载数据时,数据仓库需要预先定义,即写时模式;数据湖则是在准备使用数据的时候定义数据,即读时模式。因此,数据湖提高了数据模型的定义灵活性,更能满足不同业务的需求。

    随着使用数据仓库的组织看到数据湖的优势,他们正在改进其仓库以包括数据湖,并启用各种查询功能、数据科学使用案例和用于发现新信息模型的高级功能。

    • 偶数科技湖仓一体解决方案

    随着数据分析需求的扩大,数据湖+数据仓库的湖仓一体分析能力成为下一代数据分析系统的核心能力。相对于数据仓库,数据湖在成本、灵活性、多源数据分析等多方面,都有着非常明显的优势。

     

    偶数科技湖仓一体数据平台是新一代的数据基础设施,它能够依托云原生特性、计算存储分离架构、强ACID特性、强SQL标准支持、Hadoop原生支持、高性能并行执行能力等一系列底层技术的变革,实现高弹性、强扩展性、强共享性、强兼容性、强复杂查询能力、自动化机器学习支持等上层技术能力的变革,最终帮助企业有效应对大规模、强敏态、高时效、智能化等愈发明显的数字化趋势。

    湖仓一体架构特点:

    可管理性:湖仓一体提供完善的数据管理能力。数据湖中会存在两类数据:原始数据和处理后的数据。数据湖中的数据会不断的积累、演化,因此包含以下数据管理能力:数据源、数据连接、数据格式、数据schema(库/表/列/行)。同时,数据湖是单个企业/组织中统一的数据存放场所,因此,还具有一定的权限管理能力。

    可追溯性:数据湖是一个组织/企业中全量数据的存储场所,需要对数据的全生命周期进行管理,包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现,需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的,能够清楚的重现数据完整的产生过程和流动过程。

    丰富的计算引擎:提供从批处理、流式计算、交互式分析到机器学习等各类计算引擎。一般情况下,数据的加载、转换、处理会使用批处理计算引擎;需要实时计算的部分,会使用流式计算引擎;对于一些探索式的分析场景,可能又需要引入交互式分析引擎。随着大数据技术与人工智能技术的结合越来越紧密,各类机器学习/深度学习算法也被不断引入,平台已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此,该湖仓一体解决方案提供计算引擎的可扩展/可插拔。

    多模态的存储引擎:湖仓一体本身内置多模态的存储引擎,以满足不同的应用对于数据访问需求(综合考虑响应时间/并发/访问频次/成本等因素)。但是,在实际的使用过程中,为了达到可接受的性价比,该湖仓一体解决方案提供可插拔式存储框架,支持的类型有HDFS/S3/OSS,并且在必要时还可以与外置存储引擎协同工作,满足多样化的应用需求。

    偶数科技产品与解决方案特性优势:

    1. 云原生特性、计算存储分离架构,及其带来的高弹性:利用云服务器、分布式存储等云原生技术,对数据基础设施的扩展性能进行深度优化,充分适应云上应用对高度弹性、无限扩容能力的要求,并采取计算存储分离架构,进一步提升数据基础设施的扩展灵活性;
    2. 计算存储分离架构,及其带来的强扩展性、强共享性:采取计算、存储分离的技术架构,充分适应数字化应用对计算、存储分别独立扩展的要求,增强了弹性能力,并能够支持数千节点的集群规模,尽可能避免多集群部署,并可低成本地支持跨集群的数据共享;
    3. 强ACID特性、SQL标准支持、Hadoop原生兼容,及其带来的强兼容性:具备完善的SQL标准、ACID特性的支持能力,兼容过去采用Oracle、DB2等传统交易型数据库、MPP数据库的数字化应用,并支持对接访问Hive、HDFS等Hadoop原生组件,从而兼容过去采用SQL-on-Hadoop数据库的数字化应用,实现数字化应用在数据基础设施间的平滑迁移;
    4. 高性能并行执行能力,及其带来的强复杂查询性能:面向PB级大数据,具备比MPP、SQL-on-Hadoop数据仓库更快的复杂查询性能,从而明显降低批处理、即席查询所需的时间,保证数据处理能力的高时效;
    5. 自动化机器学习支持:具备对自动化机器学习技术的支持能力,基于AutoML等技术,为业务人员提供自动化AI建模能力,实现AI模型全生命周期管理,降低AI研发与管理成本。
    6. 数据资产管理能力:具备数据标准管理、数据质量管理、元数据管理、数据资产目录(敏感数据/业务术语表关联/数据标签/血缘分析)等数据资产化管理能力,从而更好地赋予数据以价值,实现数据的资产化管理与运营。
    7. 数据服务管理能力:通过数据API管理模块提供的低门槛、可视化的操作方式,以及分组、权限管理、服务上下线、计量与计费等管理功能,帮助数据分析人员将各类数据查询语句封装为API服务,供各业务部门和业务系统调用,从而实现数据的价值变现。
    展开全文
  • ▼ 关注「Flink 中文社区」,获取更多技术干货▼摘要:本文详细介绍了 Flink + Hudi 湖仓一体化方案的原型构建。主要内容为:Hudi新架构与湖仓一体最佳实践Flink on...

    ▼ 关注「Flink 中文社区」,获取更多技术干货 ▼

    摘要:本文详细介绍了 Flink + Hudi 湖仓一体化方案的原型构建。主要内容为:

    1. Hudi

    2. 新架构与湖仓一体

    3. 最佳实践

    4. Flink on Hudi

    5. Flink CDC 2.0 on Hudi

    Tips:FFA 2021 重磅开启,点击「阅读原文」即可报名~

    c7a843fa3e5dac4fb19919665984838f.png GitHub 地址 cb5654038773809ed809b93fe4178d8a.png

    欢迎大家给 Flink 点赞送 star~

    f27d52b62419bb28cf1dfe46b940f114.png

    一、Hudi


    1. 简介

    Apache Hudi (发音为 “Hoodie”)在 DFS 的数据集上提供以下流原语:

    • 插入更新 (如何改变数据集?)

    • 增量拉取 (如何获取变更的数据?)

    Hudi 维护在数据集上执行的所有操作的时间轴 (timeline),以提供数据集的即时视图。Hudi 将数据集组织到与 Hive 表非常相似的基本路径下的目录结构中。数据集分为多个分区,文件夹包含该分区的文件。每个分区均由相对于基本路径的分区路径唯一标识。

    分区记录会被分配到多个文件。每个文件都有一个唯一的文件 ID 和生成该文件的提交 (commit)。如果有更新,则多个文件共享相同的文件 ID,但写入时的提交 (commit) 不同。

    存储类型 – 处理数据的存储方式

    • 写时复制

    • 纯列式

    • 创建新版本的文件

    • 读时合并

    • 近实时

    视图 – 处理数据的读取方式

    读取优化视图 - 输入格式仅选择压缩的列式文件

    • parquet 文件查询性能

    • 500GB 的延迟时间约为 30 分钟

    • 导入现有的 Hive 表

    近实时视图

    • 混合、格式化数据

    • 约 1-5 分钟的延迟

    • 提供近实时表

    增量视图

    • 数据集的变更

    • 启用增量拉取

    Hudi 存储层由三个不同的部分组成:

    • 元数据 – 它以时间轴的形式维护了在数据集上执行的所有操作的元数据,该时间轴允许将数据集的即时视图存储在基本路径的元数据目录下。时间轴上的操作类型包括:

      • 提交 (commit),一次提交表示将一批记录原子写入数据集中的过程。单调递增的时间戳,提交表示写操作的开始。

      • 清理 (clean),清理数据集中不再被查询中使用的文件的较旧版本。

      • 压缩 (compaction),将行式文件转化为列式文件的动作。

    • 索引 - 将传入的记录键快速映射到文件 (如果已存在记录键)。索引实现是可插拔的,Bloom 过滤器 - 由于不依赖任何外部系统,因此它是默认配置,索引和数据始终保持一致。Apache HBase - 对少量 key 更高效。在索引标记过程中可能会节省几秒钟。

    • 数据 - Hudi 以两种不同的存储格式存储数据。实际使用的格式是可插入的,但要求具有以下特征 – 读优化的列存储格式 (ROFormat),默认值为 Apache Parquet;写优化的基于行的存储格式 (WOFormat),默认值为 Apache Avro。

    7a09ab899f6392d6179e74bf796d8e8b.png

    2. 为什么 Hudi 对于大规模和近实时应用很重要?

    Hudi 解决了以下限制:

    • HDFS 的可伸缩性限制;

    • 需要在 Hadoop 中更快地呈现数据;

    • 没有直接支持对现有数据的更新和删除;

    • 快速的 ETL 和建模;

    • 要检索所有更新的记录,无论这些更新是添加到最近日期分区的新记录还是对旧数据的更新,Hudi 都允许用户使用最后一个检查点时间戳。此过程不用执行扫描整个源表的查询。

    3. Hudi的优势

    • HDFS 中的可伸缩性限制;

    • Hadoop 中数据的快速呈现;

    • 支持对于现有数据的更新和删除;

    • 快速的 ETL 和建模。

    以上内容主要引用于:《Apache Hudi 详解》

    二、新架构与湖仓一体

    通过湖仓一体、流批一体,准实时场景下做到了:数据同源、同计算引擎、同存储、同计算口径。数据的时效性可以到分钟级,能很好的满足业务准实时数仓的需求。下面是架构图:

    6b8a6fb8bd2ba66519aec486c1ad7181.png

    MySQL 数据通过 Flink CDC 进入到 Kafka。之所以数据先入 Kafka 而不是直接入 Hudi,是为了实现多个实时任务复用 MySQL 过来的数据,避免多个任务通过 Flink CDC 接 MySQL 表以及 Binlog,对 MySQL 库的性能造成影响。

    通过 CDC 进入到 Kafka 的数据除了落一份到离线数据仓库的 ODS 层之外,会同时按照实时数据仓库的链路,从 ODS->DWD->DWS->OLAP 数据库,最后供报表等数据服务使用。实时数仓的每一层结果数据会准实时的落一份到离线数仓,通过这种方式做到程序一次开发、指标口径统一,数据统一。

    从架构图上,可以看到有一步数据修正 (重跑历史数据) 的动作,之所以有这一步是考虑到:有可能存在由于口径调整或者前一天的实时任务计算结果错误,导致重跑历史数据的情况。

    而存储在 Kafka 的数据有失效时间,不会存太久的历史数据,重跑很久的历史数据无法从 Kafka 中获取历史源数据。再者,如果把大量的历史数据再一次推到 Kafka,走实时计算的链路来修正历史数据,可能会影响当天的实时作业。所以针对重跑历史数据,会通过数据修正这一步来处理。

    总体上说,这个架构属于 Lambda 和 Kappa 混搭的架构。流批一体数据仓库的各个数据链路有数据质量校验的流程。第二天对前一天的数据进行对账,如果前一天实时计算的数据无异常,则不需要修正数据,Kappa 架构已经足够。

    本节内容引用自:37 手游基于 Flink CDC + Hudi 湖仓一体方案实践


    三、最佳实践


    1. 版本搭配

    版本选择,这个问题可能会成为困扰大家的第一个绊脚石,下面是hudi中文社区推荐的版本适配:

    FlinkHudi
    1.12.20.9.0
    1.13.10.10.0

    建议用 Hudi master + Flink 1.13 这样可以和 CDC connector 更好地适配。

    2. 下载Hudi

    https://mvnrepository.com/artifact/org.apache.Hudi/Hudi-Flink-bundle

    目前 maven 中央仓库,最新版本是 0.9.0 ,如果需要下载 0.10.0 版本 , 可以加入社区群,在共享文件中下载,也可以下载源码自行编译。

    3. 执行

    如果将 Hudi-Flink-bundle_2.11-0.10.0.jar 放到了 Flink/lib 下,则只需要如下执行即可,否则会出现各种找不到类的异常

    bin/SQL-client.sh embedded

    四、Flink on Hudi

    新建 maven 工程,修改 pom 如下:

    
     
    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
    
    
        <groupId>org.example</groupId>
        <artifactId>Flink_Hudi_test</artifactId>
        <version>1.0-SNAPSHOT</version>
    
    
        <properties>
            <maven.compiler.source>8</maven.compiler.source>
            <maven.compiler.target>8</maven.compiler.target>
            <Flink.version>1.13.1</Flink.version>
            <Hudi.version>0.10.0</Hudi.version>
            <hadoop.version>2.10.1</hadoop.version>
        </properties>
    
    
        <dependencies>
    
    
    
    
            <dependency>
                <groupId>org.apache.hadoop</groupId>
                <artifactId>hadoop-client</artifactId>
                <version>${hadoop.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.hadoop</groupId>
                <artifactId>hadoop-hdfs</artifactId>
                <version>${hadoop.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.hadoop</groupId>
                <artifactId>hadoop-common</artifactId>
                <version>${hadoop.version}</version>
            </dependency>
    
    
    
    
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-core</artifactId>
                <version>${Flink.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-streaming-java_2.11</artifactId>
                <version>${Flink.version}</version>
            </dependency>
    
    
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-connector-jdbc_2.11</artifactId>
                <version>${Flink.version}</version>
            </dependency>
    
    
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-java</artifactId>
                <version>${Flink.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-clients_2.11</artifactId>
                <version>${Flink.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-table-api-java-bridge_2.11</artifactId>
                <version>${Flink.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-table-common</artifactId>
                <version>${Flink.version}</version>
            </dependency>
    
    
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-table-planner_2.11</artifactId>
                <version>${Flink.version}</version>
            </dependency>
    
    
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-table-planner-blink_2.11</artifactId>
                <version>${Flink.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.Flink</groupId>
                <artifactId>Flink-table-planner-blink_2.11</artifactId>
                <version>${Flink.version}</version>
                <type>test-jar</type>
            </dependency>
    
    
            <dependency>
                <groupId>com.ververica</groupId>
                <artifactId>Flink-connector-mySQL-CDC</artifactId>
                <version>2.0.0</version>
            </dependency>
    
    
            <dependency>
                <groupId>org.apache.Hudi</groupId>
                <artifactId>Hudi-Flink-bundle_2.11</artifactId>
                <version>${Hudi.version}</version>
                <scope>system</scope>
                <systemPath>${project.basedir}/libs/Hudi-Flink-bundle_2.11-0.10.0-SNAPSHOT.jar</systemPath>
            </dependency>
    
    
            <dependency>
                <groupId>mySQL</groupId>
                <artifactId>mySQL-connector-java</artifactId>
                <version>5.1.49</version>
            </dependency>
    
    
    
    
        </dependencies>
    </project>

    我们通过构建查询insert into t2 select replace(uuid(),'-',''),id,name,description,now() from mySQL_binlog 将创建的 MySQL 表,插入到 Hudi 里。

    package name.lijiaqi;
    
    
    import org.apache.Flink.streaming.api.environment.StreamExecutionEnvironment;
    import org.apache.Flink.table.api.EnvironmentSettings;
    import org.apache.Flink.table.api.SQLDialect;
    import org.apache.Flink.table.api.TableResult;
    import org.apache.Flink.table.api.bridge.java.StreamTableEnvironment;
    
    
    public class MySQLToHudiExample {
        public static void main(String[] args) throws Exception {
            EnvironmentSettings fsSettings = EnvironmentSettings.newInstance()
                    .useBlinkPlanner()
                    .inStreamingMode()
                    .build();
            StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
            env.setParallelism(1);
            StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env, fsSettings);
    
    
            tableEnv.getConfig().setSQLDialect(SQLDialect.DEFAULT);
    
    
            // 数据源表
            String sourceDDL =
                    "CREATE TABLE mySQL_binlog (\n" +
                            " id INT NOT NULL,\n" +
                            " name STRING,\n" +
                            " description STRING\n" +
                            ") WITH (\n" +
                            " 'connector' = 'jdbc',\n" +
                            " 'url' = 'jdbc:mySQL://127.0.0.1:3306/test', \n"+
                            " 'driver' = 'com.mySQL.jdbc.Driver', \n"+
                            " 'username' = 'root',\n" +
                            " 'password' = 'dafei1288', \n" +
                            " 'table-name' = 'test_CDC'\n" +
                            ")";
    
    
            // 输出目标表
            String sinkDDL =
                    "CREATE TABLE t2(\n" +
                            "\tuuid VARCHAR(20),\n"+
                            "\tid INT NOT NULL,\n" +
                            "\tname VARCHAR(40),\n" +
                            "\tdescription VARCHAR(40),\n" +
                            "\tts TIMESTAMP(3)\n"+
    //                        "\t`partition` VARCHAR(20)\n" +
                            ")\n" +
    //                        "PARTITIONED BY (`partition`)\n" +
                            "WITH (\n" +
                            "\t'connector' = 'Hudi',\n" +
                            "\t'path' = 'hdfs://172.19.28.4:9000/Hudi_t4/',\n" +
                            "\t'table.type' = 'MERGE_ON_READ'\n" +
                            ")" ;
            // 简单的聚合处理
            String transformSQL =
                    "insert into t2 select replace(uuid(),'-',''),id,name,description,now()  from mySQL_binlog";
    
    
            tableEnv.executeSQL(sourceDDL);
            tableEnv.executeSQL(sinkDDL);
            TableResult result = tableEnv.executeSQL(transformSQL);
            result.print();
    
    
            env.execute("mySQL-to-Hudi");
        }
    }
    查询 Hudi
    package name.lijiaqi;
    
    
    import org.apache.Flink.streaming.api.environment.StreamExecutionEnvironment;
    import org.apache.Flink.table.api.EnvironmentSettings;
    import org.apache.Flink.table.api.SQLDialect;
    import org.apache.Flink.table.api.TableResult;
    import org.apache.Flink.table.api.bridge.java.StreamTableEnvironment;
    
    
    public class ReadHudi {
        public static void main(String[] args) throws Exception {
            EnvironmentSettings fsSettings = EnvironmentSettings.newInstance()
                    .useBlinkPlanner()
                    .inStreamingMode()
                    .build();
            StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
            env.setParallelism(1);
            StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env, fsSettings);
    
    
            tableEnv.getConfig().setSQLDialect(SQLDialect.DEFAULT);
    
    
            String sourceDDL =
                    "CREATE TABLE t2(\n" +
                            "\tuuid VARCHAR(20),\n"+
                            "\tid INT NOT NULL,\n" +
                            "\tname VARCHAR(40),\n" +
                            "\tdescription VARCHAR(40),\n" +
                            "\tts TIMESTAMP(3)\n"+
    //                        "\t`partition` VARCHAR(20)\n" +
                            ")\n" +
    //                        "PARTITIONED BY (`partition`)\n" +
                            "WITH (\n" +
                            "\t'connector' = 'Hudi',\n" +
                            "\t'path' = 'hdfs://172.19.28.4:9000/Hudi_t4/',\n" +
                            "\t'table.type' = 'MERGE_ON_READ'\n" +
                            ")" ;
            tableEnv.executeSQL(sourceDDL);
            TableResult result2 = tableEnv.executeSQL("select * from t2");
            result2.print();
    
    
            env.execute("read_Hudi");
        }
    }

    展示结果

    c68fc21695bf433ea2475d242f053776.png

    五、Flink CDC 2.0 on Hudi

    上一章节,我们使用代码形式构建实验,在本章节里,我们直接使用官网下载的 Flink 包来构建实验环境。

    1. 添加依赖

    添加如下依赖到 $Flink_HOME/lib 下:

    • Hudi-Flink-bundle_2.11-0.10.0-SNAPSHOT.jar (修改 Master 分支的 Hudi Flink 版本为 1.13.2 然后构建)

    • hadoop-mapreduce-client-core-2.7.3.jar (解决 Hudi ClassNotFoundException)

    • Flink-SQL-connector-mySQL-CDC-2.0.0.jar

    • Flink-format-changelog-json-2.0.0.jar

    • Flink-SQL-connector-Kafka_2.11-1.13.2.jar

    注意,在寻找 jar 的时候,CDC 2.0 更新过 group id ,不再试com.alibaba.ververica 而是改成了 com.ververica

    dae990cebaac68308fb96428f3ebe7f3.png

    2. Flink SQL CDC on Hudi

    创建 MySQL CDC 表

    
     
    CREATE  TABLE mySQL_users (
     id BIGINT PRIMARY KEY NOT ENFORCED ,
     name STRING,
     birthday TIMESTAMP(3),
     ts TIMESTAMP(3)
    ) WITH (
     'connector' = 'mySQL-CDC',
     'hostname' = 'localhost',
     'port' = '3306',
     'username' = 'root',
     'password' = 'dafei1288',
     'server-time-zone' = 'Asia/Shanghai',
     'database-name' = 'test',
     'table-name' = 'users'   
    );

    创建 Hudi 表

    
     
    CREATE TABLE Hudi_users5(
     id BIGINT PRIMARY KEY NOT ENFORCED,
        name STRING,
        birthday TIMESTAMP(3),
        ts TIMESTAMP(3),
        `partition` VARCHAR(20)
    ) PARTITIONED BY (`partition`) WITH (
        'connector' = 'Hudi',
        'table.type' = 'MERGE_ON_READ',
        'path' = 'hdfs://localhost:9009/Hudi/Hudi_users5'
    );

    修改配置,让查询模式输出为表,设置 checkpoint

    set execution.result-mode=tableau;
    set execution.checkpointing.interval=10sec;

    进行输入导入

    INSERT INTO Hudi_users5(id,name,birthday,ts, `partition`) SELECT id,name,birthday,ts,DATE_FORMAT(birthday, 'yyyyMMdd') FROM mySQL_users;

    查询数据

    select * from Hudi_users5;

    执行结果

    b52b61b695516f2ecb33b59762c45f81.png

    3. 卡执行计划

    9a5f569c335bdbf2452a69c7b687246a.png

    这个问题研究了很久,表面上很正常,日志也没有任何报错,也可以看出来 CDC 起作用了,有数据写入,但是就是卡在 hoodie_stream_write 上一动不动,没有数据下发。感谢社区大佬 Danny Chan 的提点,可能是 checkpoint的问题,于是做了设置:

    set execution.checkpointing.interval=10sec;

    终于正常:

    56c843cdb38064fcef35f61cd53640fe.png

    至此,Flink + Hudi 湖仓一体化方案的原型构建完成。

    参考链接

    [1] https://blog.csdn.net/qq_37095882/article/details/103714548

    [2] https://blog.csdn.net/weixin_49218925/article/details/115511022


    44ba1ca59b738fffbb94cd2bef5208d8.png  Flink Forward Asia 2021  da64daeb41fbf35b57057fbc314e1f52.png

    报名现已开放

    Flink Forward Asia 2021 重磅启动!FFA 2021 将于 12 月 4-5 日在北京·国家会议中心举办,预计将有 3000+ 开发者参与,探讨交流 Flink 最新动态。报名通道已开启,扫描下图二维码,或点击文末「阅读原文」即可报名 FFA 2021~

    b8bd7b8a6f661976f8867e824139a67b.png


    更多 Flink 相关技术问题,可扫码加入社区钉钉交流群~

    2761d22dd435679d88306ec215b4d96d.png

     08164acffa3d81d16d9bfda9b4a23ab5.gif  戳我,报名 FFA 2021 大会!

    展开全文
  • 摘要:华为云发布新一代智能数据湖华为云FusionInsight时再次提到了湖仓一体理念,那我们就来看看湖仓一体的来世今生。 伴随5G、大数据、AI、IoT的飞速发展,数据呈现大规模、多样性的极速增长,为了应对多变的业务...
  • 1背景介绍数据分析从上世纪 80 年代兴起以来,大体经历了企业数仓(EDW)、数据湖(Data Lake)、以及现在的云原生数仓、湖仓一体等过程。企业数仓是数据仓库最原始的版本,主要用于企...
  • 点击上方蓝色字体,选择“设为星标”回复”资源“获取更多资源大数据技术与架构点击右侧关注,大数据开发领域最强公众号!大数据真好玩点击右侧关注,大数据真好玩!导读:随着近几年数据概念的兴起...
  • 最近被大数据相关的小词儿,整的有点懵。索性我们就来个专题,聊透数据库、数据仓库、数据湖以及风头正劲的“Lake house”——湖仓一体化。数据仓库是个啥?和数据库有什么不同?数据库的基本...
  • 简介: MaxCompute 是面向分析的企业级 SaaS 模式云...本文为2021年阿里云峰会,阿里云开发者大会大数据与AI一体化开发平台分论坛,如何基于MaxCompute快速打通数据仓库和数据湖的湖仓一体实践演讲翻译稿。 点击.
  • 新一代“湖仓一体”数据库厂商,在面向全新海量联机业务的场景中快速崛起。 当前,各行各业的数字化转型进入了快车道。数字化转型的核心要义是挖掘数据的价值,随着企业数字化转型的深化,跨多业务、多数据类型的...
  • 简介:随着云计算的普及和数据分析需求的扩大,数据湖+数据仓库的湖仓一体分析能力成为下一代数据分析系统的核心能力。相对于数据仓库,数据湖在成本、灵活性、多源数据分析等多方面,都有着非常明显的优势。IDC发布...
  • 简介:本文由 T3 出行大数据平台负责人杨华和资深大数据平台开发工程师王祥虎介绍 Flink、Kylin 和 Hudi 湖仓一体的大数据生态体系以及在 T3 的相关应用场景。 本文由 T3 出行大数据平台负责人杨华和资深大数据...
  • 译者韩宗泽(棕泽),阿里云计算平台事业部技术专家,负责开源大数据生态企业团队的研发工作前言本文翻译自大数据技术公司 Databricks 针对数据 Delta Lake 系列技术文章。众...
  • 摘要:由汽车之家实时计算平台负责人邸星星在 4 月 17 日上海站 Meetup 分享的,基于 Flink + Iceberg 的湖仓一体架构实践,内容包括:数据仓库架构升级的背景基于 I...
  • 艾瑞咨询发布《2021年中国数据库行业研究报告》,可同时实现海量大数据联机交易和联机分析的「湖仓一体」创新架构成为数据库未来发展新趋势。
  • 国际研究机构MarketsandMarkets的最新研究报告显示,到2024年,全球数据市场将突破200亿美元,增至201亿美元,复合年增长率将高达20.6%。可以说,随着数据治理与应用...
  • 本文介绍什么是数据仓库,数据湖,湖仓一体,并 1. 数据仓库 数据仓库的英文名为Data Warehouse,简写为DW。它由数据仓库之父比尔·恩门 (Bill Inmon)于1990年提出。数据仓库是一个面向主题的、集成的、相对稳定...
  • 整个最佳实践是基于MaxCompute的湖仓一体架构,模拟公司使用场景。比如公司 A 使用云上关系型数据库 RDS 作为自己的业务库,同时使用阿里云 EMR 系统做日志数据采集。将数据汇集到云上对象存储 OSS 上,引入了数据湖...
  • 湖仓一体

    2021-07-15 22:12:12
    待完善
  • Data Lakehouse (湖仓一体) 到底是什么

    千次阅读 2020-11-28 20:56:17
    背景数据湖(Data Lake),湖仓一体(Data Lakehouse)俨然已经成为了大数据领域最为火热的流行词,在接受这些流行词洗礼的时候,身为技术人员我们往往会发出这样的疑问,这是...
  • MaxCompute 在湖仓一体架构中,通过支持 Delta Lake 和 Hudi 在数据湖中提供数据仓库性能。 本文作者 孟硕 阿里云智能 产品专家 直播视频请点击 直播观看 一、最佳实践背景 整个最佳实践是基于MaxCompute的湖仓...
  • 看到一篇讲述数据的文章,深有感受,故摘录其中一些内容如下: 原文链接:https://www.modb.pro/db/67146 摘文如下: 1970年,在IBM工作的计算机科学家Edgar F. Codd发表了一篇名为“A Relational Model of Data ...
  • 与竞争对手常用的“湖仓一体”表述有所不同,亚马逊云科技使用了另一个词——智能湖仓。顾凡对此表示,“这种表述背后的含义是‘打通湖仓‘,并非‘一体‘的概念,我们仍然是分开的湖与仓,并不是大一统的产品,...
  • 如Athena、Redshift,可以看到Hudi作为数据湖格式层衔接了云原生数据湖与数据仓库,可用于打造湖仓一体底层通用格式,Hudi生态也越来越完善,也欢迎广大开发者参与Apache Hudi社区,一起建设更好的数据湖,Github...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 720
精华内容 288
关键字:

湖仓一体