2万字，详解数据湖，概念特征架构方案场景以及建湖全过程（建议收藏）

Posted 浪尖聊大数据

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了2万字，详解数据湖，概念特征架构方案场景以及建湖全过程（建议收藏）相关的知识，希望对你有一定的参考价值。

导读：最近，数据湖的概念非常热，许多前线的同学都在讨论数据湖应该怎么建？有没有成熟的数据湖解决方案？各大厂商的数据湖解决方案到底有没有实际落地的案例？怎么理解数据湖？数据湖和大数据平台有什么不同？带着这些问题，我们尝试写了这样一篇文章，希望能抛砖引玉，引起大家一些思考和共鸣。



本文共有以下7个章节：

  1. 什么是数据湖

  2. 数据湖的基本特征

  3. 数据湖基本架构

  4. 各厂商的数据湖解决方案

  5. 典型的数据湖应用场景

  6. 数据湖建设的基本过程

  7. 总结



一、什么是数据湖


数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖，有如下定义。


Wikipedia是这样定义的：


数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，各类任务包括报表、可视化、高级分析和机器学习。数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。数据沼泽是一种退化的、缺乏管理的数据湖，数据沼泽对于用户来说要么是不可访问的要么就是无法提供足够的价值。


AWS的定义相对就简洁一点：


数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。


微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义：


Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。


关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开。

  1. 数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。
  2. 数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
  3.  数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
  4. 数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
  5. 数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
  6. 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
  7. 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
  8. 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。


综上，个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。


图1. 数据湖基本能力示意


这里需要再特别指出两点：

  1. 可扩展是指规模的可扩展和能力的可扩展，即数据湖不但要能够随着数据量的增大，提供“足够”的存储和计算能力；还需要根据需要不断提供新的数据处理模式，例如可能一开始业务只需要批处理能力，但随着业务的发展，可能需要交互式的即席分析能力；又随着业务的实效性要求不断提升，可能需要支持实时分析和机器学习等丰富的能力。

  2. 以数据为导向，是指数据湖对于用户来说要足够的简单、易用，帮助用户从复杂的IT基础设施运维工作中解脱出来，关注业务、关注模型、关注算法、关注数据。数据湖面向的是数据科学家、分析师。目前来看，云原生应该是构建数据湖的一种比较理想的构建方式，后面在“数据湖基本架构”一节会详细论述这一观点。


二、数据湖的基本特征


对数据湖的概念有了基本的认知之后，我们需要进一步明确数据湖需要具备哪些基本特征，特别是与大数据平台或者传统数据仓库相比，数据湖具有哪些特点。在具体分析之前，我们先看一张来自AWS官网的对比表格



上表对比了数据湖与传统数仓的区别，个人觉得可以从数据和计算两个层面进一步分析数据湖应该具备哪些特征。在数据方面：

  • 保真性：数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。
  • 灵活性：上表一个点是 “写入型schema” v.s.“读取型schema”，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。对于任何数据应用来说，其实schema的设计都是必不可少的，即使是mongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽量采用相同/相似的结构。“写入型schema”背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。数据湖强调的“读取型schema”，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。因此，个人认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。
  • 可管理：数据湖应该提供完善的数据管理能力。既然数据要求“保真性”和“灵活性”，那么至少数据湖中会存在两类数据：原始数据和处理后的数据。数据湖中的数据会不断的积累、演化。因此，对于数据管理能力也会要求很高，至少应该包含以下数据管理能力：数据源、数据连接、数据格式、数据schema（库/表/列/行）。同时，数据湖是单个企业/组织中统一的数据存放场所，因此，还需要具有一定的权限管理能力。
  • 可追溯：数据湖是一个组织/企业中全量数据的存储场所，需要对数据的全生命周期进行管理，包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现，需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的，能够清楚的重现数据完整的产生过程和流动过程。


    • 在计算方面，个人认为数据湖对于计算能力要求其实非常广泛，完全取决于业务对于计算的要求。


  • 丰富的计算引擎。从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。一般情况下，数据的加载、转换、处理会使用批处理计算引擎；需要实时计算的部分，会使用流式计算引擎；对于一些探索式的分析场景，可能又需要引入交互式分析引擎。随着大数据技术与人工智能技术的结合越来越紧密，各类机器学习/深度学习算法也被不断引入，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此，对于一个合格的数据湖项目而言，计算引擎的可扩展/可插拔，应该是一类基础能力。

  • 多模态的存储引擎。理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如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、Spark Streaming、Flink等。

    然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求；而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出，如下图所示。


    图3. Lambda架构示意


    Lambda架构的核心理念是“流批一体”，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。


    3） 第三阶段：Kappa架构。Lambda架构解决了应用读取数据的一致性问题，但是“流批分离”的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。


    图4. Kappa架构示意

    综上，从传统的hadoop架构往lambda架构，从lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中，除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳入大数据平台来进行统一的处理。然而，目前的大数据平台基础架构，都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理，这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。


    曾经看过一个很有意思的文章，提出过如下问题：数据湖为什么叫数据湖而不叫数据河或者数据海？一个有意思的回答是：

    1. “河”强调的是流动性，“海纳百川”，河终究是要流入大海的，而企业级数据是需要长期沉淀的，因此叫“湖”比叫“河”要贴切；同时，湖水天然是分层的，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的，“热”数据在上层，方便应用随时使用；温数据、冷数据位于数据中心不同的存储介质中，达到数据存储容量与成本的平衡。
    2. 不叫“海”的原因在于，海是无边无界的，而“湖”是有边界的，这个边界就是企业/组织的业务边界；因此数据湖需要更多的数据管理和权限管理能力。
    3. 叫“湖”的另一个重要原因是数据湖是需要精细治理的，一个缺乏管控、缺乏治理的数据湖最终会退化为“数据沼泽”，从而使应用无法有效访问数据，使存于其中的数据失去价值。


    大数据基础架构的演进，其实反应了一点：在企业/组织内部，数据是一类重要资产已经成为了共识；为了更好的利用数据，企业/组织需要对数据资产：

    1. 进行长期的原样存储
    2. 进行有效管理与集中治理
    3. 提供多模式的计算能力满足处理需求
    4. 以及面向业务，提供统一的数据视图、数据模型与数据处理结果


    数据湖就是在这个大背景下产生的，除了大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。落到具体的实现上，数据湖需要包括一系列的数据管理组件，包括：

    1. 数据接入

    2. 数据搬迁

    3. 数据治理

    4. 质量管理

    5. 资产目录

    6. 访问控制

    7. 任务管理

    8. 任务编排

    9. 元数据管理等


    如下图所示，给出了一个数据湖系统的参考架构。对于一个典型的数据湖而言，它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力，能提供多模式的数据处理能力；增强点在于数据湖提供了更为完善的数据管理能力，具体体现在：

    1. 更强大的数据接入能力。数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
    2. 更强大的数据管理能力。管理能力具体又可分为基本管理能力和扩展管理能力。基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的，后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下，数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据，来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题，一般情况下，数据湖系统不会直接提供相关功能，但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
    3. 可共享的元数据。数据湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据。好的数据湖系统，计算引擎在处理数据时，能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理，而无需进行人工/编程干预。更进一步，好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别。



    图5. 数据湖组件参考架构


    还有一点应该指出的是，上图的“集中式存储”更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。


    我们可以再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式，数据在数据湖中的整个生命周期如图6所示。理论上，一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化，以满足业务的需要。


    图6. 数据湖中的数据生命周期示意


    四、各厂商的数据湖解决方案



    数据湖作为当前的一个风口，各大云厂商纷纷推出自己的数据湖解决方案及相关产品。本节将分析各个主流厂商推出的数据湖解决方案，并将其映射到数据湖参考架构上，帮助大家理解各类方案的优缺点。


    4.1 AWS数据湖解决方案



    图7. AWS数据湖解决方案

    图7是AWS推荐的数据湖解决方案。整个方案基于AWS Lake Formation构建，AWS Lake Formation本质上是一个管理性质的组件，它与其他AWS服务互相配合，来完成整个企业级数据湖构建功能。上图自左向右，体现了数据流入、数据沉淀、数据计算、数据应用四个步骤。我们进一步来看其关键点：


    1） 数据流入。
    数据流入是整个数据湖构建的起始，包括元数据的流入和业务数据流入两个部分。元数据流入包括数据源创建、元数据抓取两步，最终会形成数据资源目录，并生成对应的安全设置与访问控制策略。解决方案提供专门的组件，获取外部数据源的相关元信息，该组件能连接外部数据源、检测数据格式和模式（schema），并在对应的数据资源目录中创建属于数据湖的元数据。业务数据的流入是通过ETL来完成的。


    在具体的产品形式上，元数据抓取、ETL和数据准备AWS将其单独抽象出来，形成了一个产品叫AWS GLUE。AWS GLUE与AWS Lake Formation共享同一个数据资源目录，在AWS GLUE官网文档上明确指出：“Each AWS account has one AWS Glue Data Catalog per AWS region”。


    对于异构数据源的支持。AWS提供的数据湖解决方案，支持S3、AWS关系型数据库、AWS NoSQL数据库，AWS利用GLUE、EMR、Athena等组件支持数据的自由流动。


    2） 数据沉淀。


    采用Amazon S3作为整个数据湖的集中存储，按需扩展/按使用量付费。


    3） 数据计算。


    整个解决方案利用AWS GLUE来进行基本的数据处理。GLUE基本的计算形式是各类批处理模式的ETL任务，任务的出发方式分为手动触发、定时触发、事件触发三种。不得不说，AWS的各类服务在生态上实现的非常好，事件触发模式上，可以利用AWS Lambda进行扩展开发，同时触发一个或多个任务，极大的提升了任务触发的定制开发能力；同时，各类ETL任务，可以通过CloudWatch进行很好的监控。


    4） 数据应用。


    在提供基本的批处理计算模式之外，AWS通过各类外部计算引擎，来提供丰富的计算模式支持，例如通过Athena/Redshift来提供基于SQL的交互式批处理能力；通过EMR来提供各类基于Spark的计算能力，包括Spark能提供的流计算能力和机器学习能力。


    5） 权限管理。


    AWS的数据湖解决方案通过Lake Formation来提供相对完善的权限管理，粒度包括“库-表-列”。但是，有一点例外的是，GLUE访问Lake Formation时，粒度只有“库-表”两级；这也从另一个侧面说明，GLUE和Lake Formation的集成是更为紧密的，GLUE对于Lake Formation中的数据有更大的访问权限。


    Lake Formation的权限进一步可以细分为数据资源目录访问权限和底层数据访问权限，分别对应元数据与实际存储的数据。实际存储数据的访问权限又进一步分为数据存取权限和数据存储访问权限。数据存取权限类似于数据库中对于库表的访问权限，数据存储权限则进一步细化了对于S3中具体目录的访问权限（分为显示和隐式两种）。如图8所示，用户A在只有数据存取的权限下，无法创建位于S3指定bucket下的表。


    个人认为这进一步体现了数据湖需要支持各种不同的存储引擎，未来的数据湖可能不只S3/OSS/OBS/HDFS一类核心存储，可能根据应用的访问需求，纳入更多类型的存储引擎，例如，S3存储原始数据，NoSQL存储处理过后适合以“键值”模式访问的数据，OLAP引擎存储需要实时出各类报表/adhoc查询的数据。虽然当前各类材料都在强调数据湖与数据仓库的不同；但是，从本质上，数据湖更应该是一类融合的数据管理思想的具体实现，“湖仓一体化”也很可能是未来的一个发展趋势。


    图8. AWS数据湖解决方案权限分离示意


    综上，AWS数据湖方案成熟度高，特别是元数据管理、权限管理上考虑充分，打通了异构数据源与各类计算引擎的上下游关系，让数据能够自由“移动”起来。在流计算和机器学习上，AWS的解决方案也比较完善。流计算方面AWS推出了专门的流计算组件Kinesis，Kinesis中的Kinesis data Firehose服务可以创建一个完全被托管的数据分发服务，通过Kinesis data Stream实时处理的数据，可以借助Firehose方便的写入S3中，并支持相应的格式转换，如将JSON转换成Parquet格式。

    AWS整个方案最牛的地方还在与Kinesis可以访问GLUE中的元数据，这一点充分体现了AWS数据湖解决方案在生态上的完备性。同样，在机器学习方面，AWS提供了SageMaker服务，SageMaker可以读取S3中的训练数据，并将训练好的模型回写至S3中。但是，有一点需要指出的是，在AWS的数据湖解决方案中，流计算和机器学习并不是固定捆绑的，只是作为计算能力扩展，能方便的集成。


    最后，让我们回到图6的数据湖组件参考架构，看看AWS的数据湖解决方案的组件覆盖情况，参见图9。



    图9. AWS 数据湖解决方案在参考架构中的映射


    综上，AWS的数据湖解决方案覆盖了除质量管理和数据治理的所有功能。其实质量管理和数据治理这个工作和企业的组织结构、业务类型强相关，需要做大量的定制开发工作，因此通用解决方案不囊括这块内容，也是可以理解的。事实上，现在也有比较优秀的开源项目支持这个项目，比如Apache Griffin，如果对质量管理和数据治理有强诉求，可以自行定制开发。


    4.2 华为数据湖解决方案



    图10.华为数据湖解决方案


    华为的数据湖解决方案相关信息来自华为官网。目前官网可见的相关产品包括数据湖探索（Data Lake Insight，DLI）和智能数据湖运营平台（DAYU）。其中DLI相当于是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。官网上没找到关于DLI的整体架构图，我根据自己的理解，尝试画了一个，主要是和AWS的解决方案有一个对比，所以形式上尽量一致，如果有非常了解华为DLI的同学，也请不吝赐教。


    华为的数据湖解决方案比较完整，DLI承担了所有的数据湖构建、数据处理、数据管理、数据应用的核心功能。DLI最大的特色是在于分析引擎的完备性，包括基于SQL的交互式分析以及基于Spark+Flink的流批一体处理引擎。在核心存储引擎上，DLI依然通过内置的OBS来提供，和AWS S3的能力基本对标。华为数据湖解决方案在上下游生态上做的比AWS相对完善，对于外部数据源，几乎支持所有目前华为云上提供的数据源服务。


    DLI可以与华为的CDM（云数据迁移服务）和DIS（数据接入服务）对接：


    1. 借助DIS，DLI可以定义各类数据点，这些点可以在Flink作业中被使用，做为source或者sink；

    2. 借助CDM，DLI甚至能接入IDC、第三方云服务的数据。


    为了更好的支持数据集成、数据开发、数据治理、质量管理等数据湖高级功能，华为云提供了DAYU平台。DAYU平台是华为数据湖治理运营方法论的落地实现。DAYU涵盖了整个数据湖治理的核心流程，并对其提供了相应的工具支持；甚至在华为的官方文档中，给出了数据治理组织的构建建议。DAYU的数据治理方法论的落地实现如图11所示（来自华为云官网）。


    图11 DAYU数据治理方法论流程


    可以看到，本质上DAYU数据治理的方法论其实是传统数据仓库治理方法论在数据湖基础设施上的延伸：从数据模型来看，依然包括贴源层、多源整合层、明细数据层，这点与数据仓库完全一致。根据数据模型和指标模型会生成质量规则和转换模型，DAYU会和DLI对接，直接调用DLI提供的相关数据处理服务，完成数据治理。

    华为云整个的数据湖解决方案，完整覆盖了数据处理的生命周期，并且明确支持了数据治理，并提供了基于模型和指标的数据治理流程工具，在华为云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进。


    4.3 阿里云数据湖解决方案


    阿里云上数据类产品众多，因为本人目前在数据BU，所以本节方案将关注在如何使用数据库BU的产品来构建数据湖，其他云上产品会略有涉及。阿里云的基于数据库产品的数据湖解决方案更加聚焦，主打数据湖分析和联邦分析两个场景。阿里云数据湖解决方案如图12所示。


    图12. 阿里云数据湖解决方案


    整个方案依然采用OSS作为数据湖的集中存储。在数据源的支持上，目前也支持所有的阿里云数据库，包括OLTP、OLAP和NoSQL等各类数据库。核心关键点如下：

    1. 数据接入与搬迁。在建湖过程中，DLA的Formation组件具备元数据发现和一键建湖的能力，在本文写作之时，目前“一键建湖”还只支持全量建湖，但是基于binlog的增量建湖已经在开发中了，预计近期上线。增量建湖能力会极大的增加数据湖中数据的实时性，并将对源端业务数据库的压力降到最下。这里需要注意的是，DLA Formation是一个内部组件，对外并没有暴露。
    2. 数据资源目录。DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理，无论数据是在“湖中”还是在“湖外”。Meta data catalog也是联邦分析的统一元数据入口。
    3. 在内置计算引擎上，DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎，都和Meta data catalog深度集成，能方便的获取元数据信息。基于Spark的能力，DLA解决方案支持批处理、流计算和机器学习等计算模式。
    4. 在外围生态上，除了支持各类异构数据源做数据接入与汇聚之外，在对外访问能力上，DLA与云原生数据仓库（原ADB）深度整合。一方面，DLA处理的结果可之际推送至ADB中，满足实时、交互式、ad hoc复杂查询；另一方面，ADB里的数据也可以借助外表功能，很方便的进行数据回流至OSS中。基于DLA，阿里云上各类异构数据源可以完全被打通，数据自由流动。
    5. 在数据集成和开发上，阿里云的数据湖解决方案提供两种选择：一种是采用dataworks完成；另一种是采用DMS来完成。无论是选择哪种，都能对外提供可视化的流程编排、任务调度、任务管理能力。在数据生命周期管理上，dataworks的数据地图能力相对更加成熟。
    6. 在数据管理和数据安全上，DMS提供了强大的能力。DMS的数据管理粒度分为“库-表-列-行”，完善的支持企业级的数据安全管控需求。除了权限管理之外，DMS更精细的地方是把原来基于数据库的devops理念扩展到了数据湖，使得数据湖的运维、开发更加精细化。


    进一步细化整个数据湖方案的数据应用架构，如下图所示。


    图13. 阿里云数据湖数据应用架构


    自左向右从数据的流向来看，数据生产者产生各类数据（云下/云上/其他云），利用各类工具，上传至各类通用/标准数据源，包括OSS/HDFS/DB等。针对各类数据源，DLA通过数据发现、数据接入、数据迁移等能力，完整建湖操作。

    对于“入湖”的数据，DLA提供基于SQL和Spark的数据处理能力，并可以基于Dataworks/DMS，对外提供可视化的数据集成和数据开发能力；在对外应用服务能力上，DLA提供标准化的JDBC接口，可以直接对接各类报表工具、大屏展示功能等。阿里云的DLA的特色在于背靠整个阿里云数据库生态，包括OLTP、OLAP、NoSQL等各类数据库，对外提供基于SQL的数据处理能力，对于传统企业基于数据库的开发技术栈而言，转型成本相对较低，学习曲线比较平缓。


    阿里云的DLA解决方案的另一个特色在于“基于云原生的湖仓一体化”。传统的企业级数据仓库在大数据时代的今天，在各类报表应用上依然是无法替代的，但是数仓无法满足大数据时代的数据分析处理的灵活性需求。

    因此，我们推荐数据仓库应该作为数据湖的上层应用存在：即数据湖是原始业务数据在一个企业/组织中唯一官方数据存储地；数据湖根据各类业务应用需求，将原始数据进行加工处理，形成可再次利用的中间结果；当中间结果的数据模式（Schema）相对固定后，DLA可以将中间结果推送至数据仓库，供企业/组织开展基于数仓的业务应用。阿里云在提供DLA的同时，还提供了云原生数仓（原ADB），DLA和云原生数仓在以下两点上深度融合。


  • 使用同源的SQL解析引擎。DLA的SQL与ADB的SQL语法上完全兼容，这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。

  • 都内置了对于OSS的访问支持。OSS直接作为DLA的原生存储存在；对于ADB而言，可以通过外部表的能力，很方便的访问OSS上的结构化数据。借助外部表，数据可以自由的在DLA和ADB之间流转，做到真正的湖仓一体。


    • DLA+ADB的组合真正做到了云原生的湖仓一体（关于什么是云原生，不在本文的讨论范畴）。本质上，DLA可以看成一个能力扩展的数据仓库贴源层。与传统数仓相比，该贴源层：


    1. 可以保存各类结构化、半结构化和非结构化数据；

    2. 可以对接各类异构数据源；

    3. 具备元数据发现、管理、同步等能力；

    4. 内置的SQL/Spark计算引擎具备更强的数据处理能力，满足多样化的数据处理需求；

    5. 具备全量数据的全生命周期管理能力。基于DLA+ADB的湖仓一体化方案，将同时覆盖“大数据平台+数据仓库”的处理能力。




    DLA还有一个重要能力是构建了一个“四通八达”的数据流动体系，并以数据库的体验对外提供能力，无论数据在云上还是云下，无论数据在组织内部还是外部；借助数据湖，各个系统之间的数据不再存在壁垒，可以自由的流进流出；更重要的是，这种流动是受监管的，数据湖完整的记录了数据的流动情况。


    4.4 Azure数据湖解决方案


    Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层，如图15所示（来自Azure官网）。存储层是基于Azure object Storage构建的，依然是对结构化、半结构化和非结构化数据提供支撑。

    接口层为WebHDFS，比较特别的是在Azure object Storage实现了HDFS的接口，Azure把这个能力称为“数据湖存储上的多协议存取”。在资源调度上，Azure基于YARN实现。计算引擎上，Azure提供了U-SQL、hadoop和Spark等多种处理引擎。


    图15. Azure Data lake analysis 架构


    Azure的特别之处是基于visual studio提供给了客户开发的支持。

    1. 开发工具的支持，与visual studio的深度集成；Azure推荐使用U-SQL作为数据湖分析应用的开发语言。Visual studio为U-SQL提供了完备的开发环境；同时，为了降低分布式数据湖系统开发的复杂性，visual studio基于项目进行封装，在进行U-SQL开发时，可以创建“U-SQL database project”，在此类项目中，利用visual studio，可以很方便的进行编码与调试，同时，也提供向导，将开发好的U-SQL脚本发布到生成环境。U-SQL支持Python、R进行扩展，满足定制开发需求。
    2. 多计算引擎的适配：SQL, Apache Hadoop和Apache Spark。这里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服务），Spark包括Azure Databricks。
    3. 多种不同引擎任务之间的自动转换能力。微软推荐U-SQL为数据湖的缺省开发工具，并提供各类转换工具，支持U-SQL脚本与Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之间的转化。


    4.5 小结


    本文所讨论的是数据湖的解决方案，不会涉及到任何云厂商的单个产品。我们从数据接入、数据存储、数据计算、数据管理、应用生态几个方面，简单做了一个类似下表的总结。



    出于篇幅关系，其实知名云厂商的数据湖解决方案还有谷歌和腾讯的。这两家从其官方网站上看，数据湖解决方案相对来讲比较简单，也仅仅是一些概念上的阐述，推荐的落地方案是“oss+hadoop（EMR）”。

    其实数据湖不应该从一个简单的技术平台视角来看，实现数据湖的方式也多种多样，评价一个数据湖解决方案是否成熟，关键应该看其提供的数据管理能力，具体包括但不限于元数据、数据资产目录、数据源、数据处理任务、数据生命周期、数据治理、权限管理等；以及与外围生态的对接打通能力。

    五、典型的数据湖应用案例


    5.1 广告数据分析


    近年来，流量获取的成本就越来越高，线上渠道获客成本的成倍增长让各行各业都面临着严峻的挑战。在互联网广告成本不断攀升的大背景下，以花钱买流量拉新为主要的经营策略必然行不通了。流量前端的优化已成强弩之末，利用数据工具提高流量到站后的目标转化，精细化运营广告投放的各个环节，才是改变现状更为直接有效的方式。说到底，要提高广告流量的转化率，必须依靠大数据分析。


    为了能够提供更多的决策支撑依据，需要采取更多的埋点数据的收集和分析，包括但不限于渠道、投放时间、投放人群，以点击率为数据指标进行数据分析，从而给出更好的、更迅速的方案和建议，实现高效率高产出。因此，面对广告投放领域多维度、多媒体、多广告位等结构化、半结构化和非结构化数据采集、存储、分析和决策建议等要求，数据湖分析产品解决方案在广告主或者发布商进行新一代技术选型中上受到了很热烈的青睐。

    DG是一家全球领先的企业国际化智能营销服务商，基于先进的广告技术、大数据和运营能力，为客户提供全球高质量用户获取及流量变现服务。DG从成立之初就决定以公有云为基础来构建其IT基础设施，最初DG选择了AWS云平台，主要将其广告数据在S3中以数据湖的形态进行存放，通过Athena进行交互式分析。然而随着互联网广告的飞速发展，广告行业带来了几大挑战，移动广告的发布与追踪系统必须解决几个关键问题：

    1. 并发性与峰值问题。在广告行业，流量高峰时常出现，瞬间的点击量可能达到数万，甚至数十万，这就要求系统具备非常好的可扩展性以快速响应和处理每一次点击
    2. 如何实现对海量数据的实时分析。为了监控广告投放效果，系统需要实时对用户的每一次点击和激活数据进行分析，同时把相关数据传输到下游的媒体；
    3. 平台的数据量在急剧增长，每天的业务日志数据在持续的产生和上传，曝光、点击、推送的数据在持续处理，每天新增的数据量已经在10-50TB左右，对整个数据处理系统提出了更高的要求。如何高效地完成对广告数据的离线/近实时统计，按照广告客户的维度要求进行聚合分析。


    针对上述三点业务挑战，同时DG这个客户日增量数据正在急剧变大（当前日数据扫描量达到100+TB），继续在AWS平台使用遇到Athena读取S3数据带宽瓶颈、数据分析滞后时间越来越长、为应对数据和分析需求增长而急剧攀升的投入成本等，经过认真、仔细的测试和分析，最终决定从AWS云平台全量搬站到阿里云平台，新架构图如下：


    图16. 改造后的广告数据湖方案架构


    从AWS搬站到阿里云后，我们为该客户设计了“利用Data Lake Analytics + OSS”极致分析能力来应对业务波峰波谷。一方面轻松应对来自品牌客户的临时分析。另一方面利用Data Lake Analytics的强大计算能力，分析按月、季度广告投放，精确计算出一个品牌下面会有多少个活动，每个活动分媒体，分市场，分频道，分DMP的投放效果，进一步增强了加和智能流量平台为品牌营销带来的销售转化率。

    并且在广告投放与分析的总拥有成本上，Data Lake Analytics提供的Serverless的弹性服务为按需收费，不需要购买固定的资源，完全契合业务潮汐带来的资源波动，满足弹性的分析需求，同时极大地降低了运维成本和使用成本。


    图17 数据湖部署示意图


    总体上，DG从AWS切换到阿里云后，极大地节省了硬件成本、人力成本和开发成本。由于采用DLA serverless云服务，DG无需先期投入大量的资金去购买服务器、存储等硬件设备，也无需一次性购买大量的云服务，其基础设施的规模完全是按需扩展：需求高的时候增加服务数量，需求减少的时候减少服务数量，提高了资金的利用率。

    使用阿里云平台带来的第二个显著好处是性能的提升。在DG业务的快速增长期以及后续多条业务线接入期，DG在移动广告系统的访问量经常呈爆发式增长，然而原先AWS方案和平台在Athena读取S3数据遇到数据读取带宽的极大瓶颈，数据分析的时间变得越来越长，阿里云DLA联合OSS团队等进行了极大的优化和改造，同时，DLA数据库分析在计算引擎上（与TPC-DS打榜世界第一的AnalyticDB共享计算引擎）比Presto原生计算引擎的能力提升数十倍性能，也极大的为DG提升了分析性能。


    5.2 游戏运营分析


    数据湖是一类TCO表现极其优秀的大数据基础设施。对于很多快速增长的游戏公司而言，一个爆款游戏，往往在短期内相关数据增长极快；同时，公司的研发人员的技术栈很难在短期内与数据的增量和增速进行匹配；此时，呈爆发增长的数据很难被有效利用。数据湖是一个解决此类问题的技术选择。


    YJ是一家高速成长的游戏公司，公司希望能依托相关用户行为数据进行深入分析，指导游戏的开发和运营。数据分析背后的核心逻辑在于随着游戏行业市场竞争局面的扩大，玩家对于品质的要求越来越高，游戏项目的生命周期越来越短，直接影响项目的投入产出比，通过数据运营则可以有效的延长项目的生命周期，对各个阶段的业务走向进行精准把控。

    而随着流量成本的日益上升，如何构建经济、高效的精细化数据运营体系，以更好的支撑业务发展，也变得愈发重要起来。数据运营体系就需要有其配套的基础支撑设施，如何选择这类基础支撑设施，是公司技术决策者需要思考的问题。思考的出发点包括：


    1. 要有足够的弹性。对于游戏而言，往往就是短时间爆发，数据量激增；因此，能否适应数据的爆发性增长，满足弹性需求是一个重点考量的点；无论是计算还是存储，都需要具备足够的弹性。

    2. 要有足够的性价比。对于用户行为数据，往往需要拉到一个很长的周期去分析去对比，比如留存率，不少情况下需要考虑90天甚至180天客户的留存率；因此，如何以最具性价比的方式长期存储海量数据是需要重点考虑的问题。
    3. 要有够用的分析能力，且具备可扩展性。许多情况下，用户行为体现在埋点数据中，埋点数据又需要与用户注册信息、登陆信息、账单等结构化数据关联分析；因此，在数据分析上，至少需要有大数据的ETL能力、异构数据源的接入能力和复杂分析的建模能力。
    4. 要与公司现有技术栈相匹配，且后续利于招聘。对于YJ，其在技术选型的时候一个重要点就是其技术人员的技术栈，YJ的技术团队大部分只熟悉传统的数据库开发，即mysql；并且人手紧张，做数据运营分析的技术人员只有1个，短时间内根本没有能力独立构建大数据分析的基础设施。从YJ的角度出发，最好绝大多数分析能够通过SQL完成；并且在招聘市场上，SQL开发人员的数量也远高于大数据开发工程师的数量。针对客户的情况，我们帮助客户对现有方案做了改造。



    图18. 改造前的方案


    改造前，客户所有的结构化数据都在一个高规格的MySQL里面；而玩家行为数据则是通过LogTail采集至日志服务（SLS）中，然后从日志服务中分别投递到OSS和ES里。这个架构的问题在于：

    1. 行为数据和结构化数据完全割裂，无法联动分析；
    2. 对于行为数据智能提供检索功能，无法做深层次的挖掘分析；
    3. OSS仅仅作为数据存储资源使用，并没有挖掘出足够的数据价值。


    事实上，我们分析客户现存架构其实已经具备了数据湖的雏形：全量数据已经在OSS中保存下来了，现在需要进一步补齐客户对于OSS中的数据的分析能力。而且数据湖基于SQL的数据处理模式也满足客户对于开发技术栈的需求。综上，我们对客户的架构做了如下调整，帮助客户构建了数据湖。


    图19. 改造后的数据湖解决方案


    总体上，我们没有改变客户的数据链路流转，只是在OSS的基础上，增加了DLA组件，对OSS的数据进行二次加工处理。DLA提供了标准SQL计算引擎，同时支持接入各类异构数据源。基于DLA对OSS的数据进行处理后，生成业务直接可用的数据。但是DLA的问题在于无法支撑低延迟需求的交互式分析场景，为了解决这个问题，我们引入了云原生数据仓库ADB来解决交互式分析的延迟性问题；同时，在最前端引入QuickBI作为客户的可视化分析工具。YJ方案是图14所示的湖仓一体化解决方案在游戏行业的一个经典落地案例。


    YM是一家数据智能服务提供商，面向各类中小商家提供一系列数据分析运营服务。具体实现的技术逻辑如下图所示。


    图20. YM智能数据服务SaaS模式示意


    平台方提供多端SDK供用户（商家提供网页、APP、小程序等多种接入形式）接入各类埋点数据，平台方以SaaS的形式提供统一的数据接入服务和数据分析服务。商家通过访问各类数据分析服务来进行更细粒度的埋点数据分析，完成行为统计、客户画像、客户圈选、广告投放监测等基本分析功能。然而，这种SaaS模式下，会存在一定的问题：

    1. 由于商家类型和需求的多样化，平台提供SaaS类分析功能很难覆盖所有类型的商家，无法满足商家的定制化需求；如有些商家关注销量，有些关注客户运营，有些关注成本优化，很难满足所有的需求。
    2. 对于一些高级分析功能，如依赖于自定义标签的客户圈选、客户自定义扩展等功能，统一的数据分析服务无法满足的；特别是一些自定义的标签依赖于商家自定义的算法，无法满足客户的高级分析需求。
    3. 数据的资产化管理需求。在大数据时代，数据是一个企业/组织的资产已经成为了大家的共识，如何能让属于商家的数据合理、长期的沉淀下来，也是SaaS服务需要考虑的事情。


    综上，我们在上图的基本模式上引入了数据湖模式，让数据湖作为商家沉淀数据、产出模型、分析运营的基础支撑设施。引入数据湖后的SaaS数据智能服务模式如下。


    图21. 基于数据湖的数据智能服务


    如图21所示，平台方为每个用户提供一键建湖服务，商家使用该功能构建自己的数据湖，“一键建湖”能力一方面帮助商家将所有埋点数据的数据模型（schema）同步至数据湖中；另一方面，将属于该商家的所有埋点数据全量同步至数据湖中，并基于“T+1”的模式，将每天的增量数据归档入湖。基于数据湖的服务模式在传统的数据分析服务的基础上，赋予了用户数据资产化、分析模型化和服务定制化三大能力：

    1. 数据资产化能力。利用数据湖，商家可以将属于自己的数据持续沉淀下来，保存多长时间的数据，耗费多少成本，完全由商家自主决定。数据湖还提供了数据资产管理能力，商家除了能管理原始数据外，还能将处理过的过程数据和结果数据分门别类保存，极大的提升了埋点数据的价值。
    2. 分析模型化能力。数据湖中不仅仅有原始数据，还有埋点数据的模型（schema）。埋点数据模型体现了全域数据智能服务平台对于业务逻辑的抽象，通过数据湖，除了将原始数据作为资产输出外，还将数据模型进行了输出，借助埋点数据模型，商家可以更深入的理解埋点数据背后所体现的用户行为逻辑，帮助商家更好的洞察客户行为，获取用户需求。
    3. 服务定制化能力。借助数据湖提供的数据集成和数据开发能力，基于对埋点数据模型的理解，商家可以定制数据处理过程，不断对原始数据进行迭代加工，从数据中提炼有价值的信息，最终获得超越原有数据分析服务的价值。



     六、数据湖建设的基本过程



    个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑

    万字详解数据仓库数据湖数据中台和湖仓一体

    本文目录：

    一、前言
    二、概念解析

    1. 数据仓库
    2. 数据湖
    3. 数据中台

    三、具体区别

    1. 数据仓库 VS 数据湖
    2. 数据仓库 VS 数据中台
    3. 总结

    四、湖仓一体

    1. 目前数据存储方案
    2. Data Lakehouse（湖仓一体）

    一、前言

    数字化转型浪潮卷起各种新老概念满天飞，数据湖、数据仓库、数据中台轮番在朋友圈刷屏，有人说“数据中台算个啥，数据湖才是趋势”，有人说“再见了数据湖、数据仓库，数据中台已成气候”……
    .

    50000字详解数仓建设保姆级教程，涵盖离线和实时
    .

    企业还没推开数字化大门，先被各种概念绊了一脚。那么它们 3 者究竟有啥区别？别急，先跟大家分享两个有趣的比喻。

    1、图书馆VS地摊

    如果把数据仓库比喻成“图书馆”，那么数据湖就是“地摊”。去图书馆借书（数据），书籍质量有保障，但你得等，等什么？等管理员先查到这本书属于哪个类目、在哪个架子上，你才能精准拿到自己想要的书；而地摊上没有人会给你把关，什么书都有，你自己翻找、随用随取，流程上比图书馆便捷多了，但大家找书的过程是没有经验可复用的，偶尔多拿少拿咱们可能也不知道。

    2、升级版银行

    假定数据仓库、数据湖、数据中台都是银行，可以提供现金、黄金等多种服务。过去大家进银行前都得先问门卫，里面每个门牌上的数字对应哪个服务呢？是现金还是黄金呢？然后推开对应的门把东西取出来。而有了“数据中台”这个银行，大家一进来就能看到标着“现金”、“黄金”汉字的窗口，一目了然，你只需要走到窗口前，就有专人帮你办理。

    以上两个例子不一定全面，但基本能解释三者的优劣势。数据仓库具备规范性，但取数用数流程长；数据湖取数用数更实时、存储量大，但数据质量难以保障；数据中台能精准快速地响应业务需求，离业务侧最近。

    为了更清晰地区别三者，接下来咱们再来看看它们各自的定义以及应用区别。

    二、概念解析

    1. 数据仓库

    数据仓库诞生于 1990 年，绝对算得上是“老前辈”了，它是一个相对具体的功能概念。目前对数据仓库的主流定义是位于多个数据库上的大容量存储库，它的作用在于存储大量的结构化数据，并能进行频繁和可重复的分析，帮助企业构建商业智能（BI）。

    具体定义：

    数据仓库(Data Warehouse)是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。其主要功能是将组织透过资讯系统之联机事务处理(OLTP)经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，分析出有价值的资讯。

    • 所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。

    • 所谓集成：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。

    • 所谓随时间变化：是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

    数据仓库的作用：

    数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。

    • 是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具；

    • 是主要用于历史性、综合性和深层次数据分析；

    • 数据来源是ERP（例:SAP）系统或其他业务系统；

    • 能够提供灵活、直观、简洁和易于操作的多维查询分析;

    • 不是日常交易操作系统，不能直接产生交易数据；

    实时数仓

    实时数仓和离线数仓非常的像，诞生的背景主要是近几年企业对于数据服务的实时性需求日益增多。里面的数据模型也会像中台一样分好几层：ODS 、CDM、ADS。但整体对于实时性要求极高，因此一般存储会考虑采用Kafka这种log base的MQ，而计算引擎会采用Flink这种流计算引擎。

    2. 数据湖

    数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施，它就像一个大型仓库存储企业多样化原始数据以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理。拥有强大的信息处理能力和处理几乎无限的并发任务或工作的能力。

    数据湖从企业的多个数据源获取原始数据，数据可能是任意类型的信息，从结构化数据到完全非结构化数据，并通过与各类外部异构数据源的交互集成，支持各类企业级应用。结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。

    进入互联网时代，有两个最重要的变化。

    一个是数据规模前所未有，一个成功的互联网产品日活可以过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据仓库难于扩展，根本无法承载如此规模的海量数据。

    另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

    所以，数据规模和数据类型的限制，导致传统数据仓库无法支撑互联网时代的商业智能。

    05年的时候，Hadoop诞生了。 Hadoop 相比传统数据仓库主要有两个优势：

    • 完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；

    • 弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据（包含了原始数据）在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。而数仓更加关注可以作为事实依据的数据。

    随着Hadoop与对象存储的成熟，数据湖的概念在10年被提出：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统（这意味着数据湖的底层不应该与任何存储耦合）。

    对应的来说，如果数据湖没有被治理好（缺乏元数据、定义数据源、制定数据访问策略和安全策略，并移动数据、编制数据目录），则会变成数据沼泽。

    而从产品形态上来说，数仓往往是独立标准化的产品。而数据湖更像是一种架构指导——需要配合一系列的周边工具，来实现业务需要的数据湖。

    3. 数据中台

    大规模数据的应用，也逐渐暴露出现一些问题。

    业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导致运营对数据的信任度下降。如果你是运营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标出现了两个值，你的感受如何? 你第一反应肯定是数据算错了，你不敢继续使用这个数据了。

    数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。

    • 如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？

    • 如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，活干不完。

    • 如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这也太贵了，能不能再省一点，要不吃不消了。

    这些问题的根源在于，数据无法共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜之间，我们就可以根据场景，孵化出很多数据应用，这些应用让数据产生价值。

    数据中台样板

    在建设中台的过程中，一般强调这样几个重点：

    • 效率、质量和成本是决定数据能否支撑好业务的关键，构建数据中台的目标就是要实现高效率、高质量、低成本。

    • 数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。

    • 如果你的企业拥有 3 个以上的数据应用场景，数据产品还在不断研发和更新，你必须要认真考虑建设数据中台。

    那么接下来就看一下阿里巴巴对于数据中台的实践。

    正如上述提到的数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。阿里数据中台提到了各种one思想，如：

    • OneData：公共数据只保存一份
    • OneService：通过一个服务接口进行暴露

    三、具体区别

    1. 数据仓库 VS 数据湖

    相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们一致认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比，数据湖缺乏结构性，而且更灵活，并且提供了更高的敏捷性。值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。

    2. 数据仓库 VS 数据中台

    数据仓库和传统的数据平台，其出发点为一个支撑性的技术系统，即一定要先考虑我具有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理；而数据中台的第一出发点不是数据而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。

    在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT结构转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。

    3. 总结

    根据以上数据仓库、数据湖和数据中台的概念论述和对比，我们进行如下总结：

    • 数据中台、数据仓库和数据湖没有直接的关系；

    • 数据中台、数据仓库和数据湖在某个维度上为业务产生价值的形式有不同的侧重；

    • 数据中台是企业级的逻辑概念，体现企业数据向业务价值转化的能力，为业务提供服务的主要方式是数据 API；

    • 数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表；

    • 数据中台距离业务更近，能够更快速的响应业务和应用开发需求，从而为业务提供速度更快的服务；

    • 数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；

    • 数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

    四、湖仓一体

    有人说“湖仓一体成为下一站灯塔，数仓、数据湖架构即将退出群聊”。

    2020年，大数据DataBricks公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，此概念一出各路云厂商纷纷跟进。

    Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。

    1. 目前数据存储的方案

    一直以来，我们都在使用两种数据存储方式来架构数据：

    • 数据仓库：主要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理，并导入到目标表中。在数仓中，数据存储的结构与其定义的schema是强匹配的。

    • 数据湖：存储任何类型的数据，包括像图片、文档这样的非结构化数据。数据湖通常更大，其存储成本也更为廉价。存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上。相反的是，数据的拥有者通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上。

    现在许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有一定的冗余。

    2. Data Lakehouse（湖仓一体）

    Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。

    下面详细解释下：

    湖仓一体（Data Lakehouse）：

    依据DataBricks公司对Lakehouse 的定义：一种结合了数据湖和数据仓库优势的新范式，解决了数据湖的局限性。Lakehouse 使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。

    解释拓展：

    湖仓一体，简单理解就是把面向企业的数据仓库技术与数据湖存储技术相结合，为企业提供一个统一的、可共享的数据底座。

    避免传统的数据湖、数据仓库之间的数据移动，将原始数据、加工清洗数据、模型化数据，共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。

    湖仓一体方案的出现，帮助企业构建起全新的、融合的数据平台。通过对机器学习和AI算法的支持，实现数据湖+数据仓库的闭环，提升业务的效率。数据湖和数据仓库的能力充分结合，形成互补，同时对接上层多样化的计算生态。

    Lakehouse有如下关键特性：

    • 事物支持：Lakehouse 在企业级应用中，许多数据管道通常会同时读取和写入数据。通常多方同时使用 SQL 读取或写入数据，Lakehouse 保证支持ACID事务的一致性。

    • 模式实施和治理：Lakehouse 应该有一种支持模式实施和演变的方法，支持 DW 模式规范，例如 star /snowflake-schemas。该系统应该能够推理数据完整性，并且应该具有健壮的治理和审核机制。

    • BI支持：Lakehouse 可以直接在源数据上使用BI工具。这样可以减少陈旧度和等待时间，提高新近度，并且降低必须在数据湖和仓库中操作两个数据副本的成本。

    • 存储与计算分离：事实上，这意味着存储和计算使用单独的群集，因此这些系统能够扩展到更多并发用户和更大数据量。一些现代数据仓库也具有这种属性。

    • 兼容性：Lakehouse 使用的存储格式是开放式和标准化的，例如 Parquet，并且它提供了多种 API，包括机器学习和 Python/R 库，因此各种工具和引擎都可以直接有效地访问数据。

    • 支持从非结构化数据到结构化数据的多种数据类型：Lakehouse 可用于存储，优化，分析和访问许多新数据应用程序所需的数据类型，包括图像，视频，音频，半结构化数据和文本。

    • 支持各种工作场景：包括数据科学，机器学习和 SQL 分析。这些可能依赖于多种工具来支持的工作场景，它们都依赖于相同的数据存储库。

    • 端到端流式任务：实时报告是许多企业的日常需要。对流处理的支持消除了对专门服务于实时数据应用程序的单独系统的需求。

    上面这张图是DataBricks给出的架构演化参考图。

    我们可以看到，传统的数仓目标非常明确，适用于将各业务数据源合并后，进行商务BI分析和报表。随着企业需要处理的数据类型越来越多，包括客户行为，IoT，图片，视频等， 数据规模也成指数增加。

    数据湖技术被引入，并用于承担通用数据存储和处理平台的作用，数据湖由于其分布式存储和计算能力的特点，也可以更好的支持机器学习计算， 在数据湖时代，我们通常可以看到DataLake和Data Warehouse还是会同时存在的。

    随着大数据时代的到来，是不是有可能让大数据技术可以取代传统数仓，形成一个统一的数据处理架构，湖仓一体的概念被提出，并由DataBricks和云厂商们在进行快速的推演和实践。

    参考

    1. 最强最全面的数仓建设规范指南
    2. 美团数据平台及数仓建设实践，超十万字总结
    3. 数仓建设保姆级教程

    以上是关于2万字，详解数据湖，概念特征架构方案场景以及建湖全过程（建议收藏）的主要内容，如果未能解决你的问题，请参考以下文章

    万字详解数据仓库数据湖数据中台和湖仓一体

    万字详解数据仓库数据湖数据中台和湖仓一体

    万字详解数据仓库数据湖数据中台和湖仓一体

    万字详解数据仓库数据湖数据中台和湖仓一体

    漫说数据湖——如何建湖？如何做数据ETL？为什么大数据需要数据湖？

    4万字全面掌握数据库, 数据仓库, 数据集市,数据湖,数据中台