阿里云代理商-阿里云服务器-阿里云数据库-重庆典名科技

数据湖的基本特征、数据湖基本架构、数据湖的优势

发布时间: 2020-08-18 10:38:21文章作者: 网站编辑阅读量: 744
  数据湖的基本特征    数据湖的一部分价值是把不同种类的数据汇聚到一起,另一部分价值是不需要预定义的模型就能进行数据分析。现在的大数据架构是可扩展的,并且可以为用户提供越来越多的实时分析。在商业智能(BI)和数据仓库还没有被淘汰的今天,大数据分析和大数据湖正在向更多类型的实时智能服务发展,这些实时的智能服务可以支持实时的决策制定。
  
  对数据湖的概念有了基本的认知之后,我们需要进一步明确数据湖需要具备哪些基本特征,特别是与大数据平台或者传统数据仓库相比,数据湖具有哪些特点。在具体分析之前,我们先看一张来自对比表格。
 数据湖的基本特征 
  上表对比了数据湖与传统数仓的区别,个人觉得可以从数据和计算两个层面进一步分析数据湖应该具备哪些特征。在数据方面:
  
  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等计算引擎尽量使用计算节点的内存对数据进行缓存,从而提高整个数据过程的效率和系统吞吐能力。
  Hadoop体系结构示意
  
  2) 第二阶段:lambda架构。随着数据处理能力和处理需求的不断变化,越来越多的用户发现,批处理模式无论如何提升性能,也无法满足一些实时性要求高的处理场景,流式计算引擎应运而生,例如Storm、Spark Streaming、Flink等。然而,随着越来越多的应用上线,大家发现,其实批处理和流计算配合使用,才能满足大部分应用需求;而对于用户而言,其实他们并不关心底层的计算模型是什么,用户希望无论是批处理还是流计算,都能基于统一的数据模型来返回处理结果,于是Lambda架构被提出,如下图所示。(为了省事,lambda架构和Kappa架构图均来自于网络)
  Lambda架构示意
  
  Lambda架构的核心理念是“流批一体”,如上图所示,整个数据流向自左向右流入平台。进入平台后一分为二,一部分走批处理模式,一部分走流式计算模式。无论哪种计算模式,最终的处理结果都通过服务层对应用提供,确保访问的一致性。
  
  3) 第三阶段:Kappa架构。Lambda架构解决了应用读取数据的一致性问题,但是“流批分离”的处理链路增大了研发的复杂性。因此,有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征,注定了他的扩展性更好。通过加大流计算的并发性,加大流式数据的“时间窗口”,来统一批处理与流式处理两种计算模式。
  Kappa架构示意
  
  综上,从传统的hadoop架构往lambda架构,从lambda架构往Kappa架构的演进,大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力,大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中,除了关系型数据库依托于各个独立的业务系统;其余的数据,几乎都被考虑纳入大数据平台来进行统一的处理。然而,目前的大数据平台基础架构,都将视角锁定在了存储和计算,而忽略了对于数据的资产化管理,这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。
  
  大数据基础架构的演进,其实反应了一点:在企业/组织内部,数据是一类重要资产已经成为了共识;为了更好的利用数据,企业/组织需要对数据资产 1)进行长期的原样存储;2)进行有效管理与集中治理;3)提供多模式的计算能力满足处理需求;4)以及面向业务,提供统一的数据视图、数据模型与数据处理结果。数据湖就是在这个大背景下产生的,除了大数据平台所拥有的各类基础能力之外,数据湖更强调对于数据的管理、治理和资产化能力。落到具体的实现上,数据湖需要包括一系列的数据管理组件,包括:1)数据接入;2)数据搬迁;3)数据治理;4)质量管理;5)资产目录;6)访问控制;7)任务管理;8)任务编排;9)元数据管理等。如下图所示,给出了一个数据湖系统的参考架构。对于一个典型的数据湖而言,它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力,能提供多模式的数据处理能力;增强点在于数据湖提供了更为完善的数据管理能力,具体体现在:
  
  1) 更强大的数据接入能力。数据接入能力体现在对于各类外部异构数据源的定义管理能力,以及对于外部数据源相关数据的抽取迁移能力,抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
  
  2) 更强大的数据管理能力。管理能力具体又可分为基本管理能力和扩展管理能力。基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理,是一个数据湖系统所必须的,后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务,通常情况下,数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力,定制的系统/模块可以通过读取数据湖的相关元数据,来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题,一般情况下,数据湖系统不会直接提供相关功能,但是会开放各类接口或者元数据,供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
  
  3) 可共享的元数据。数据湖中的各类计算引擎会与数据湖中的数据深度融合,而融合的基础就是数据湖的元数据。好的数据湖系统,计算引擎在处理数据时,能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息,然后直接进行数据处理,而无需进行人工/编程干预。更进一步,好的数据湖系统还可以对数据湖中的数据进行访问控制,控制的力度可以做到“库表列行”等不同级别。
  数据湖组件参考架构
  
  还有一点应该指出的是,上图的“集中式存储”更多的是业务概念上的集中,本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上,数据湖的存储应该是一类可按需扩展的分布式文件系统,大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。
  
  我们可以再切换到数据维度,从数据生命周期的视角来看待数据湖对于数据的处理方式,数据在数据湖中的整个生命周期如图6所示。理论上,一个管理完善的数据湖中的数据会永久的保留原始数据,同时过程数据会不断的完善、演化,以满足业务的需要。
  数据湖中的数据生命周期示意
  数据湖与数据仓库的区别
  
  数据仓库是一种具有正式架构的成熟的、安全的技术。它们存储经过全面处理的结构化数据,以便完成数据治理流程。数据仓库将数据组合为一种聚合、摘要形式,以在企业范围内使用,并在执行数据写入操作时写入元数据和模式定义。数据仓库通常拥有固定的配置;它们是高度结构化的,因此不太灵活和敏捷。数据仓库成本与在存储前处理所有数据相关,而且大容量存储的费用相对较高。
  
  相较而言,数据湖是较新的技术,拥有不断演变的架构。数据湖存储任何形式(包括结构化和非结构化)和任何格式(包括文本、音频、视频和图像)的原始数据。根据定义,数据湖不会接受数据治理,但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比,数据湖缺乏结构性,而且更灵活;它们还提供了更高的敏捷性。在检索数据之前无需执行任何处理,而且数据湖特意使用了便宜的存储。
  
  1)数仓中保存的都是结构化处理后的数据,而数据湖中可以保存原始数据也可以保存结构化处理后的数据,保证用户能获取到各个阶段的数据。因为数据的价值跟不同的业务和用户强相关,有可能对于A用户没有意义的数据,但是对于B用户来说意义巨大,所以都需要保存在数据湖中。
  
  2)数据湖能够支持各种用户使用,包括数据科学家这类专业的数据人员。
  
  数据湖的优势
  
  轻松地收集和摄入数据:企业中的所有数据源都可以送入数据湖中。因此,数据湖成为了存储在企业内部服务器或云服务器中的结构化和非结构化数据的无缝访问点。通过数据分析工具可以轻松地获得整个无孤岛的数据集合。此外,数据湖可以用多种文件格式存储多种格式的数据,比如文本、音频、视频和图像。这种灵活性简化了旧有数据存储的集成。
  
  支持实时数据源:数据湖支持对实时和高速数据流执行 ETL 功能,这有助于将来自 IoT 设备的传感器数据与其他数据源一起融合到数据湖中。
  
  更快地准备数据:分析师和数据科学家不需要花时间直接访问多个来源,可以更轻松地搜索、查找和访问数据,这加速了数据准备和重用流程。数据湖还会跟踪和确认数据血统,这有助于确保数据值得信任,还会快速生成可用于数据驱动的决策的 BI。
  
  更好的可扩展性和敏捷性:数据湖可以利用分布式文件系统来存储数据,因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格,因此天生具有更高的灵活性,从而提高了敏捷性。数据科学家可以在数据湖内创建沙箱来开发和测试新的分析模型。
  
  具有人工智能的高级分析:访问原始数据,创建沙箱的能力,以及重新配置的灵活性,这些使得数据湖成为了一个快速开发和使用高级分析模型的强大平台。数据湖非常适合使用机器学习和深度学习来执行各种任务,比如数据挖掘和数据分析,以及提取非结构化数据。
联系客服免费领取更多阿里云产品新购、续费升级折扣,叠加官网活动折上折更优惠