一文读懂Data Lake的概念特征架构与案例.docx
- 文档编号:24668769
- 上传时间:2023-05-30
- 格式:DOCX
- 页数:34
- 大小:1.77MB
一文读懂Data Lake的概念特征架构与案例.docx
《一文读懂Data Lake的概念特征架构与案例.docx》由会员分享,可在线阅读,更多相关《一文读懂Data Lake的概念特征架构与案例.docx(34页珍藏版)》请在冰豆网上搜索。
一文读懂DataLake的概念特征架构与案例
一文读懂DataLake的概念、特征、架构与案例
本文包括七个小节:
1、什么是数据湖;2、数据湖的基本特征;3、数据湖基本架构;4、各厂商的数据湖解决方案;5、典型的数据湖应用场景;6、数据湖建设的基本过程;7、总结。
受限于个人水平,谬误在所难免,欢迎同学们一起探讨,批评指正,不吝赐教。
一、什么是数据湖
数据湖是目前比较热的一个概念,许多企业都在构建或者计划构建自己的数据湖。
但是在计划构建数据湖之前,搞清楚什么是数据湖,明确一个数据湖项目的基本组成,进而设计数据湖的基本架构,对于数据湖的构建至关重要。
关于什么是数据湖?
有不同的定义。
Wikipedia上说数据湖是一类存储数据自然/原始格式的系统或存储,通常是对象块或者文件,包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据,包括来自于关系型数据库中的结构化数据(行和列)、半结构化数据(如CSV、日志、XML、JSON)、非结构化数据(如email、文档、PDF等)和二进制数据(如图像、音频、视频)。
AWS定义数据湖是一个集中式存储库,允许您以任意规模存储所有结构化和非结构化数据。
微软的定义就更加模糊了,并没有明确给出什么是DataLake,而是取巧的将数据湖的功能作为定义,数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力,这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据,并且可以跨平台、跨语言的做所有类型的分析和处理。
关于数据湖的定义其实很多,但是基本上都围绕着以下几个特性展开。
1、数据湖需要提供足够用的数据存储能力,这个存储保存了一个企业/组织中的所有数据。
2、数据湖可以存储海量的任意类型的数据,包括结构化、半结构化和非结构化数据。
3、数据湖中的数据是原始数据,是业务数据的完整副本。
数据湖中的数据保持了他们在业务系统中原来的样子。
4、数据湖需要具备完善的数据管理能力(完善的元数据),可以管理各类数据相关的要素,包括数据源、数据格式、连接信息、数据schema、权限管理等。
5、数据湖需要具备多样化的分析能力,包括但不限于批处理、流式计算、交互式分析以及机器学习;同时,还需要提供一定的任务调度和管理能力。
6、数据湖需要具备完善的数据生命周期管理能力。
不光需要存储原始数据,还需要能够保存各类分析处理的中间结果,并完整的记录数据的分析处理过程,能帮助用户完整详细追溯任意一条数据的产生过程。
7、数据湖需要具备完善的数据获取和数据发布能力。
数据湖需要能支撑各种各样的数据源,并能从相关的数据源中获取全量/增量数据;然后规范存储。
数据湖能将数据分析处理的结果推送到合适的存储引擎中,满足不同的应用访问需求。
8、对于大数据的支持,包括超大规模存储以及可扩展的大规模数据处理能力。
综上,个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施;以数据为导向,实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理;并通过与各类外部异构数据源的交互集成,支持各类企业级应用。
图1.数据湖基本能力示意
这里需要再特别指出两点:
1)可扩展是指规模的可扩展和能力的可扩展,即数据湖不但要能够随着数据量的增大,提供“足够”的存储和计算能力;还需要根据需要不断提供新的数据处理模式,例如可能一开始业务只需要批处理能力,但随着业务的发展,可能需要交互式的即席分析能力;又随着业务的实效性要求不断提升,可能需要支持实时分析和机器学习等丰富的能力。
2)以数据为导向,是指数据湖对于用户来说要足够的简单、易用,帮助用户从复杂的IT基础设施运维工作中解脱出来,关注业务、关注模型、关注算法、关注数据。
数据湖面向的是数据科学家、分析师。
目前来看,云原生应该是构建数据湖的一种比较理想的构建方式,后面在“数据湖基本架构”一节会详细论述这一观点。
二、数据湖的基本特征
对数据湖的概念有了基本的认知之后,我们需要进一步明确数据湖需要具备哪些基本特征,特别是与大数据平台或者传统数据仓库相比,数据湖具有哪些特点。
在具体分析之前,我们先看一张来自AWS官网的对比表格
上表对比了数据湖与传统数仓的区别,个人觉得可以从数据和计算两个层面进一步分析数据湖应该具备哪些特征。
在数据方面:
1)“保真性”。
数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。
与数据仓库不同的地方在于,数据湖中必须要保存一份原始数据,无论是数据格式、数据模式、数据内容都不应该被修改。
在这方面,数据湖强调的是对于业务数据“原汁原味”的保存。
同时,数据湖应该能够存储任意类型/格式的数据。
2)“灵活性”:
上表一个点是“写入型schema”v.s.“读取型schema”,其实本质上来讲是数据schema的设计发生在哪个阶段的问题。
对于任何数据应用来说,其实schema的设计都是必不可少的,即使是mongoDB等一些强调“无模式”的数据库,其最佳实践里依然建议记录尽量采用相同/相似的结构。
“写入型schema”背后隐含的逻辑是数据在写入之前,就需要根据业务的访问方式确定数据的schema,然后按照既定schema,完成数据导入,带来的好处是数据与业务的良好适配;但是这也意味着数仓的前期拥有成本会比较高,特别是当业务模式不清晰、业务还处于探索阶段时,数仓的灵活性不够。
数据湖强调的“读取型schema”,背后的潜在逻辑则是认为业务的不确定性是常态:
我们无法预期业务的变化,那么我们就保持一定的灵活性,将设计去延后,让整个基础设施具备使数据“按需”贴合业务的能力。
因此,个人认为“保真性”和“灵活性”是一脉相承的:
既然没办法预估业务的变化,那么索性保持数据最为原始的状态,一旦需要时,可以根据需求对数据进行加工处理。
因此,数据湖更加适合创新型企业、业务高速变化发展的企业。
同时,数据湖的用户也相应的要求更高,数据科学家、业务分析师(配合一定的可视化工具)是数据湖的目标客户。
3)“可管理”:
数据湖应该提供完善的数据管理能力。
既然数据要求“保真性”和“灵活性”,那么至少数据湖中会存在两类数据:
原始数据和处理后的数据。
数据湖中的数据会不断的积累、演化。
因此,对于数据管理能力也会要求很高,至少应该包含以下数据管理能力:
数据源、数据连接、数据格式、数据schema(库/表/列/行)。
同时,数据湖是单个企业/组织中统一的数据存放场所,因此,还需要具有一定的权限管理能力。
4)“可追溯”:
数据湖是一个组织/企业中全量数据的存储场所,需要对数据的全生命周期进行管理,包括数据的定义、接入、存储、处理、分析、应用的全过程。
一个强大的数据湖实现,需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的,能够清楚的重现数据完整的产生过程和流动过程。
在计算方面,个人认为数据湖对于计算能力要求其实非常广泛,完全取决于业务对于计算的要求。
5)丰富的计算引擎。
从批处理、流式计算、交互式分析到机器学习,各类计算引擎都属于数据湖应该囊括的范畴。
一般情况下,数据的加载、转换、处理会使用批处理计算引擎;需要实时计算的部分,会使用流式计算引擎;对于一些探索式的分析场景,可能又需要引入交互式分析引擎。
随着大数据技术与人工智能技术的结合越来越紧密,各类机器学习/深度学习算法也被不断引入,例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。
因此,对于一个合格的数据湖项目而言,计算引擎的可扩展/可插拔,应该是一类基础能力。
6)多模态的存储引擎。
理论上,数据湖本身应该内置多模态的存储引擎,以满足不同的应用对于数据访问需求(综合考虑响应时间/并发/访问频次/成本等因素)。
但是,在实际的使用过程中,数据湖中的数据通常并不会被高频次的访问,而且相关的应用也多在进行探索式的数据应用,为了达到可接受的性价比,数据湖建设通常会选择相对便宜的存储引擎(如S3/OSS/HDFS/OBS),并且在需要时与外置存储引擎协同工作,满足多样化的应用需求。
三、数据湖基本架构
数据湖可以认为是新一代的大数据基础设施。
为了更好的理解数据湖的基本架构,我们先来看看大数据基础设施架构的演进过程。
1)第一阶段:
以Hadoop为代表的离线数据处理基础设施。
如下图所示,Hadoop是以HDFS为核心存储,以MapReduce(简称MR)为基本计算模型的批量数据处理基础设施。
围绕HDFS和MR,产生了一系列的组件,不断完善整个大数据平台的数据处理能力,例如面向在线KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。
同时,随着大家对于批处理的性能要求越来越高,新的计算模型不断被提出,产生了Tez、Spark、Presto等计算引擎,MR模型也逐渐进化成DAG模型。
DAG模型一方面,增加计算模型的抽象并发能力:
对每一个计算过程进行分解,根据计算过程中的聚合操作点对任务进行逻辑切分,任务被切分成一个个的stage,每个stage都可以有一个或者多个Task组成,Task是可以并发执行的,从而提升整个计算过程的并行能力;另一方面,为减少数据处理过程中的中间结果写文件操作,Spark、Presto等计算引擎尽量使用计算节点的内存对数据进行缓存,从而提高整个数据过程的效率和系统吞吐能力。
图2.Hadoop体系结构示意
2)第二阶段:
lambda架构。
随着数据处理能力和处理需求的不断变化,越来越多的用户发现,批处理模式无论如何提升性能,也无法满足一些实时性要求高的处理场景,流式计算引擎应运而生,例如Storm、SparkStreaming、Flink等。
然而,随着越来越多的应用上线,大家发现,其实批处理和流计算配合使用,才能满足大部分应用需求;而对于用户而言,其实他们并不关心底层的计算模型是什么,用户希望无论是批处理还是流计算,都能基于统一的数据模型来返回处理结果,于是Lambda架构被提出,如下图所示。
(为了省事,lambda架构和Kappa架构图均来自于网络)
图3.Lambda架构示意
Lambda架构的核心理念是“流批一体”,如上图所示,整个数据流向自左向右流入平台。
进入平台后一分为二,一部分走批处理模式,一部分走流式计算模式。
无论哪种计算模式,最终的处理结果都通过服务层对应用提供,确保访问的一致性。
3)第三阶段:
Kappa架构。
Lambda架构解决了应用读取数据的一致性问题,但是“流批分离”的处理链路增大了研发的复杂性。
因此,有人就提出能不能用一套系统来解决所有问题。
目前比较流行的做法就是基于流计算来做。
流计算天然的分布式特征,注定了他的扩展性更好。
通过加大流计算的并发性,加大流式数据的“时间窗口”,来统一批处理与流式处理两种计算模式。
图4.Kappa架构示意
综上,从传统的hadoop架构往lambda架构,从lambda架构往Kappa架构的演进,大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力,大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。
当前的企业实践中,除了关系型数据库依托于各个独立的业务系统;其余的数据,几乎都被考虑纳入大数据平台来进行统一的处理。
然而,目前的大数据平台基础架构,都将视角锁定在了存储和计算,而忽略了对于数据的资产化管理,这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。
大数据基础架构的演进,其实反应了一点:
在企业/组织内部,数据是一类重要资产已经成为了共识;为了更好的利用数据,企业/组织需要对数据资产1)进行长期的原样存储;2)进行有效管理与集中治理;3)提供多模式的计算能力满足处理需求;4)以及面向业务,提供统一的数据视图、数据模型与数据处理结果。
数据湖就是在这个大背景下产生的,除了大数据平台所拥有的各类基础能力之外,数据湖更强调对于数据的管理、治理和资产化能力。
落到具体的实现上,数据湖需要包括一系列的数据管理组件,包括:
1)数据接入;2)数据搬迁;3)数据治理;4)质量管理;5)资产目录;6)访问控制;7)任务管理;8)任务编排;9)元数据管理等。
如下图所示,给出了一个数据湖系统的参考架构。
对于一个典型的数据湖而言,它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力,能提供多模式的数据处理能力;增强点在于数据湖提供了更为完善的数据管理能力,具体体现在:
1)更强大的数据接入能力。
数据接入能力体现在对于各类外部异构数据源的定义管理能力,以及对于外部数据源相关数据的抽取迁移能力,抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
2)更强大的数据管理能力。
管理能力具体又可分为基本管理能力和扩展管理能力。
基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理,是一个数据湖系统所必须的,后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。
扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。
任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务,通常情况下,数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力,定制的系统/模块可以通过读取数据湖的相关元数据,来实现与数据湖系统的融合。
而数据质量和数据治理则是更为复杂的问题,一般情况下,数据湖系统不会直接提供相关功能,但是会开放各类接口或者元数据,供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
3)可共享的元数据。
数据湖中的各类计算引擎会与数据湖中的数据深度融合,而融合的基础就是数据湖的元数据。
好的数据湖系统,计算引擎在处理数据时,能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息,然后直接进行数据处理,而无需进行人工/编程干预。
更进一步,好的数据湖系统还可以对数据湖中的数据进行访问控制,控制的力度可以做到“库表列行”等不同级别。
图5.数据湖组件参考架构
还有一点应该指出的是,上图的“集中式存储”更多的是业务概念上的集中,本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。
事实上,数据湖的存储应该是一类可按需扩展的分布式文件系统,大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。
我们可以再切换到数据维度,从数据生命周期的视角来看待数据湖对于数据的处理方式,数据在数据湖中的整个生命周期如图6所示。
理论上,一个管理完善的数据湖中的数据会永久的保留原始数据,同时过程数据会不断的完善、演化,以满足业务的需要。
图6.数据湖中的数据生命周期示意
四、各厂商的数据湖解决方案
数据湖作为当前的一个风口,各大云厂商纷纷推出自己的数据湖解决方案及相关产品。
本节将分析各个主流厂商推出的数据湖解决方案,并将其映射到数据湖参考架构上,帮助大家理解各类方案的优缺点。
4.1AWS数据湖解决方案
图7.AWS数据湖解决方案
图7是AWS推荐的数据湖解决方案。
整个方案基于AWSLakeFormation构建,AWSLakeFormation本质上是一个管理性质的组件,它与其他AWS服务互相配合,来完成整个企业级数据湖构建功能。
上图自左向右,体现了数据流入、数据沉淀、数据计算、数据应用四个步骤。
我们进一步来看其关键点:
1)数据流入。
数据流入是整个数据湖构建的起始,包括元数据的流入和业务数据流入两个部分。
元数据流入包括数据源创建、元数据抓取两步,最终会形成数据资源目录,并生成对应的安全设置与访问控制策略。
解决方案提供专门的组件,获取外部数据源的相关元信息,该组件能连接外部数据源、检测数据格式和模式(schema),并在对应的数据资源目录中创建属于数据湖的元数据。
业务数据的流入是通过ETL来完成的。
在具体的产品形式上,元数据抓取、ETL和数据准备AWS将其单独抽象出来,形成了一个产品叫AWSGLUE。
AWSGLUE与AWSLakeFormation共享同一个数据资源目录,在AWSGLUE官网文档上明确指出:
“EachAWSaccounthasoneAWSGlueDataCatalogperAWSregion”。
对于异构数据源的支持。
AWS提供的数据湖解决方案,支持S3、AWS关系型数据库、AWSNoSQL数据库,AWS利用GLUE、EMR、Athena等组件支持数据的自由流动。
2)数据沉淀。
采用AmazonS3作为整个数据湖的集中存储,按需扩展/按使用量付费。
3)数据计算。
整个解决方案利用AWSGLUE来进行基本的数据处理。
GLUE基本的计算形式是各类批处理模式的ETL任务,任务的出发方式分为手动触发、定时触发、事件触发三种。
不得不说,AWS的各类服务在生态上实现的非常好,事件触发模式上,可以利用AWSLambda进行扩展开发,同时触发一个或多个任务,极大的提升了任务触发的定制开发能力;同时,各类ETL任务,可以通过CloudWatch进行很好的监控。
4)数据应用。
在提供基本的批处理计算模式之外,AWS通过各类外部计算引擎,来提供丰富的计算模式支持,例如通过Athena/Redshift来提供基于SQL的交互式批处理能力;通过EMR来提供各类基于Spark的计算能力,包括Spark能提供的流计算能力和机器学习能力。
5)权限管理。
AWS的数据湖解决方案通过LakeFormation来提供相对完善的权限管理,粒度包括“库-表-列”。
但是,有一点例外的是,GLUE访问LakeFormation时,粒度只有“库-表”两级;这也从另一个侧面说明,GLUE和LakeFormation的集成是更为紧密的,GLUE对于LakeFormation中的数据有更大的访问权限。
LakeFormation的权限进一步可以细分为数据资源目录访问权限和底层数据访问权限,分别对应元数据与实际存储的数据。
实际存储数据的访问权限又进一步分为数据存取权限和数据存储访问权限。
数据存取权限类似于数据库中对于库表的访问权限,数据存储权限则进一步细化了对于S3中具体目录的访问权限(分为显示和隐式两种)。
如图8所示,用户A在只有数据存取的权限下,无法创建位于S3指定bucket下的表。
个人认为这进一步体现了数据湖需要支持各种不同的存储引擎,未来的数据湖可能不只S3/OSS/OBS/HDFS一类核心存储,可能根据应用的访问需求,纳入更多类型的存储引擎,例如,S3存储原始数据,NoSQL存储处理过后适合以“键值”模式访问的数据,OLAP引擎存储需要实时出各类报表/adhoc查询的数据。
虽然当前各类材料都在强调数据湖与数据仓库的不同;但是,从本质上,数据湖更应该是一类融合的数据管理思想的具体实现,“湖仓一体化”也很可能是未来的一个发展趋势。
图8.AWS数据湖解决方案权限分离示意
综上,AWS数据湖方案成熟度高,特别是元数据管理、权限管理上考虑充分,打通了异构数据源与各类计算引擎的上下游关系,让数据能够自由“移动”起来。
在流计算和机器学习上,AWS的解决方案也比较完善。
流计算方面AWS推出了专门的流计算组件Kinesis,Kinesis中的KinesisdataFirehose服务可以创建一个完全被托管的数据分发服务,通过KinesisdataStream实时处理的数据,可以借助Firehose方便的写入S3中,并支持相应的格式转换,如将JSON转换成Parquet格式。
AWS整个方案最牛的地方还在与Kinesis可以访问GLUE中的元数据,这一点充分体现了AWS数据湖解决方案在生态上的完备性。
同样,在机器学习方面,AWS提供了SageMaker服务,SageMaker可以读取S3中的训练数据,并将训练好的模型回写至S3中。
但是,有一点需要指出的是,在AWS的数据湖解决方案中,流计算和机器学习并不是固定捆绑的,只是作为计算能力扩展,能方便的集成。
最后,让我们回到图6的数据湖组件参考架构,看看AWS的数据湖解决方案的组件覆盖情况,参见图9。
图9.AWS数据湖解决方案在参考架构中的映射
综上,AWS的数据湖解决方案覆盖了除质量管理和数据治理的所有功能。
其实质量管理和数据治理这个工作和企业的组织结构、业务类型强相关,需要做大量的定制开发工作,因此通用解决方案不囊括这块内容,也是可以理解的。
事实上,现在也有比较优秀的开源项目支持这个项目,比如ApacheGriffin,如果对质量管理和数据治理有强诉求,可以自行定制开发。
4.2华为数据湖解决方案
图10.华为数据湖解决方案
华为的数据湖解决方案相关信息来自华为官网。
目前官网可见的相关产品包括数据湖探索(DataLakeInsight,DLI)和智能数据湖运营平台(DAYU)。
其中DLI相当于是AWS的LakeFormation、GLUE、Athena、EMR(Flink&Spark)的集合。
官网上没找到关于DLI的整体架构图,我根据自己的理解,尝试画了一个,主要是和AWS的解决方案有一个对比,所以形式上尽量一致,如果有非常了解华为DLI的同学,也请不吝赐教。
华为的数据湖解决方案比较完整,DLI承担了所有的数据湖构建、数据处理、数据管理、数据应用的核心功能。
DLI最大的特色是在于分析引擎的完备性,包括基于SQL的交互式分析以及基于Spark+Flink的流批一体处理引擎。
在核心存储引擎上,DLI依然通过内置的OBS来提供,和AWSS3的能力基本对标。
华为数据湖解决方案在上下游生态上做的比AWS相对完善,对于外部数据源,几乎支持所有目前华为云上提供的数据源服务。
DLI可以与华为的CDM(云数据迁移服务)和DIS(数据接入服务)对接:
1)借助DIS,DLI可以定义各类数据点,这些点可以在Flink作业中被使用,做为source或者sink;2)借助CDM,DLI甚至能接入IDC、第三方云服务的数据。
为了更好的支持数据集成、数据开发、数据治理、质量管理等数据湖高级功能,华为云提供了DAYU平台。
DAYU平台是华为数据湖治理运营方法论的落地实现。
DAYU涵盖了整个数据湖治理的核心流程,并对其提供了相应的工具支持;甚至在华为的官方文档中,给出了数据治理组织的构建建议。
DAYU的数据治理方法论的落地实现如图11所示(来自华为云官网)。
图11DAYU数据治理方法论流程
可以看到,本质上DAYU数据治理的方法论其实是传统数据仓库治理方法论在数据湖基础设施上的延伸:
从数据模型来看,依然包括贴源层、多源整合层、明细数据层,这点与数据仓库完全一致。
根据数据模型和指标模型会生成质量规则和转换模型,DAYU会和DLI对接,直接调用DLI提供的相关数据处理服务,完成数据治理。
华为云整个的数据湖解决方案,完整覆盖了数据处理的生命周期,并且明确支持了数据治理,并提供了基于模型和指标的数据治理流程工具,在华为云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进。
4.3阿里云数据湖解决方案
阿里云上数据类产品众多,因为本人目前在数据BU,所以本节方案将关注在如何使用数据库BU的产品来构建数据湖,其他云上产品会略有涉及。
阿里云的基于数据库产品的数据湖解决方案更加聚焦,主打数据湖分析和联邦分析两个场景。
阿里云数据湖解决方案如图12所示。
图12.阿里云数据湖解决方案
整个方案依然采用OSS作为数据湖的集中存储。
在数据源的支持上,目前也支持所有的阿里云数据库,包括OLTP、OLAP和NoSQL等各类数据库。
核心关键点如下:
1)数据接入与搬迁。
在建湖过程中,DLA的Formation组件具备元数据发现和一键建湖的能力,在本文写作之时,目前“一键建湖”还只支持全量建湖,但是基于binlog的增量建湖已经在开发中了,预
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 一文读懂Data Lake的概念特征架构与案例 读懂 Data Lake 概念 特征 架构 案例