Data Lake_理解数据湖

Pentaho首席技术官James Dixon创造了“数据湖”一词。它把数据集市描述成一瓶水（清洗过的，包装过的和结构化易于使用的）。而数据湖更像是在自然状态下的水，数据流从源系统流向这个湖。用户可以在数据湖里校验，取样或完全的使用数据。

这个也是一个不精确的定义。数据湖还有以下特点：

• 从源系统导入所有的数据，没有数据流失。
• 数据存储时没有经过转换或只是简单的处理。
• 数据转换和定义schema 用于满足分析需求。
• 

数据湖为什么叫数据湖而不叫数据河或者数据海？一个有意思的回答是：

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

1、数据湖的定义

---

1.1 维基百科对数据湖的定义

• 

数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖是以其自然格式存储数据的系统或存储库，通常是对象blob或文件。

数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据。

数据湖从企业的多个数据源获取原始数据，并且针对不同的目的，同一份原始数据还可能有多种满足特定内部模型格式的数据副本。因此，数据湖中被处理的数据可能是任意类型的信息，从结构化数据到完全非结构化数据。数据湖可以包括:

• 来自关系数据库（行和列）的结构化数据
• 半结构化数据（CSV，日志，XML，JSON）
• 非结构化数据（电子邮件，文档，PDF）和二进制数据（图像，音频，视频）

目前，HDFS是最常用的部署数据湖的技术，所以很多人会觉得数据湖就是HDFS集群。数据湖是一个概念，而HDFS是用于实现这个概念的技术。

1.2  AWS对数据湖的定义

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

1.3 微软对数据湖的定义

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

Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。

数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。

数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。

Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。

Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。

1.4 数据湖定义小结

• 数据湖需要提供足够用的数据存储能力， 这个存储保存了一个企业/组织中的所有数据
• 数据湖可以存储海量的任意类型的数据 ，包括结构化、半结构化和非结构化数据
• 数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
• 数据湖需要具备完善的数据管理能力（完善的元数据）, 可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等
• 数据湖需要具备多样化的分析能力 包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
• 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
• 

• 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。

• 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。

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

2.数据湖的处理架构

---

2.1 概述

• 

数据湖引擎介于管理数据系统、分析可视化和数据处理工具之间。数据湖引擎不是将数据从数据源移动到单个存储库，而是部署在现有数据源和数据使用者的工具(如BI工具和数据科学平台)之上。

• 

BI分析工具，如Tableau、Power BI、R、Python和机器学习模型，是为数据生活在一个单一的、高性能的关系数据库中的环境而设计的。然而，多数组织使用不同的数据格式和不同的技术在多种解决方案中管理他们的数据。

多数组织现在使用一个或多个非关系型数据存储，如云存储(如S3、ADLS)、Hadoop和NoSQL数据库(如Elasticsearch、Cassandra)

当数据存储在一个独立的高性能关系数据库中时，BI工具、数据科学系统和机器学习模型可以很好运用这部分数据。然而，就像我们上面所说的一样，数据这并不是存在一个地方。

因此，我们通常应用自定义ETL开发来集成来自不同系统的数据，以便于我们后续分析。通常分析技术栈分为以下几类：

• ODS(Operational Data Store)：数据从不同的数据库转移到单一的存储区域，如云存储服务(如Amazon S3、ADLS)、HDFS
• 数据仓库：虽然可以在Hadoop和云存储上直接执行SQL查询，但是这些系统的设计目的并不是提供交互性能。因此，数据的子集通常被加载到关系数据仓库或MPP数据库中，也就是构建数据仓库。
• 数据集市：为了在大型数据集上提供交互性能，必须通过在OLAP系统中构建多维数据集或在数据仓库中构建物化聚合表对数据进行预聚合。种多层体系架构带来了许多挑战。例如：
  • 灵活性：比如数据源的变化或新的数据需求，必须重新访问数据仓库每一层，以确保后续应用人员来使用，可能会花费较长的实施周期
  • 复杂性：数据分析人员必须了解所有存储数据的查询语法，增加了不必要的复杂性
  • 技术成本：该架构需要广泛的定制ETL开发、DBA专业知识和数据工程来满足业务中不断发展的数据需求
  • 基础设施成本：该架构需要大量的专有技术，并且通常会导致存储在不同系统中的数据产生许多副本
  • 数据治理：该架构如果血缘关系搞的不好，便使得跟踪、维护变得非常困难
  • 数据及时性：在ETL的过程中需要时间，所以一般数据是T-1的统计汇总

数据湖引擎采用了一种不同的方法来支持数据分析。数据湖引擎不是将数据移动到单个存储库中，而是在数据原本存储的地方访问数据，并动态地执行任何必要的数据转换和汇总。

此外，数据湖引擎还提供了一个自助服务模型，使数据使用者能够使用他们喜欢的工具(如Power BI、Tableau、Python和R)探索、分析数据，而不用关心数据在哪存、结构如何。

有些数据源可能不适合分析处理，也无法提供对数据的有效访问。数据湖引擎提供了优化数据物理访问的能力。有了这种能力，可以在不改变数据使用者访问数据的方式和他们使用的工具的情况下优化各个数据集。

与传统的解决方案相比，数据湖引擎使用多种技术使数据消费者能够访问数据，并集成这些技术功能到一个自助服务的解决方案中。

数据湖可以认为是新一代的大数据基础设施。为了更好的理解数据湖的基本架构，我们先来看看大数据基础设施架构的演进过程。

2.2 第一阶段：以Hadoop为代表的离线数据处理基础设施

如下图所示，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施。

• 
• 围绕HDFS和MR，产生了一系列的组件，不断完善整个大数据平台的数据处理能力，例如面向在线KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。
• 同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了Tez、Spark、Presto、Flink等计算引擎，MR模型也逐渐进化成DAG模型。
• DAG模型一方面增加计算模型的抽象并发能力：对每一个计算过程进行分解，根据计算过程中的聚合操作点对任务进行逻辑切分，任务被切分成一个个的stage，每个stage都可以有一个或者多个Task组成，Task是可以并发执行的，从而提升整个计算过程的并行能力；
• 另一方面，为减少数据处理过程中的中间结果写文件操作，Spark、Presto等计算引擎尽量使用计算节点的内存对数据进行缓存，从而提高整个数据过程的效率和系统吞吐能力。

2.3 第二阶段：lambda架构

参考以前的文章： 一：大数据架构回顾-Lambda架构

随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。

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

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

2.4 第三阶段：Kappa架构

参见以前的文章：二：大数据架构回顾-Kappa架构

Lambda架构虽然解决了应用读取数据的统一性问题，但是“流批分离”的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。

目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。

2.5 大数据基础设施架构小结

综上，从传统的hadoop架构往lambda架构，从lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。

当前的企业实践中，除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳入大数据平台来进行统一的处理。

然而，目前的大数据平台基础架构，都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理，这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。

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

• 进行长期的原样存储，以便可回溯重放原始数据
• 进行有效管理与集中治理
• 提供多模式的计算能力满足处理需求
• 面向业务，提供统一的数据视图、数据模型与数据处理结果

数据湖就是在这个大背景下产生的，除了有大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。

落到具体的实现上，数据湖需要包括一系列的数据管理组件，包括：

• 数据接入；
• 数据搬迁；
• 数据治理；
• 数据质量管理；
• 资产目录；
• 访问控制；
• 任务管理；
• 任务编排；
• 元数据管理等

如下图所示，给出了一个数据湖系统的参考架构

• 

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

• 更强大的数据接入能力：数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
• 更强大的数据管理能力：管理能力具体又可分为基本管理能力和扩展管理能力：可共享的元数据：数据湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据。
  • 基本管理能力：包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的。
  • 扩展管理能力：包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下，数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据，来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题，一般情况下，数据湖系统不会直接提供相关功能，但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。

好的数据湖系统，计算引擎在处理数据时，能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理，而无需进行人工/编程干预。

更进一步，好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别。

还有一点应该指出的是，前面数据湖系统的参考架构图的集中式存储更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。

事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。

我们可以再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式，数据在数据湖中的整个生命周期如下图所示。

  理论上，一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化，以满足业务的需要。

• 

3.数据湖能给企业带来多种能力

---

数据湖能给企业带来多种能力，例如，能实现数据的集中式管理，在此之上，企业能挖掘出很多之前所不具备的能力。

另外，数据湖结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。数据湖能从以下方面帮助到企业：

• 实现数据治理（data governance）
• 通过应用机器学习与人工智能技术实现商业智能；
• 预测分析，如领域特定的推荐引擎；
• 信息追踪与一致性保障；
• 根据对历史的分析生成新的数据维度；
• 有一个集中式的能存储所有企业数据的数据中心，有利于实现一个针对数据传输优化的数据服务；
• 帮助组织或企业做出更多灵活的关于企业增长的决策。

4、数据湖与数据仓库区别

---

• 

4.1 概述

对于数据仓库与数据湖的不同之处，你可以想象一下仓库和湖泊的区别：仓库存储着来自特定来源的货物，而湖泊的水来自河流、溪流和其他来源，并且是原始数据。

数据仓库供应商包括AWS、Cloudera、IBM、谷歌、微软、甲骨文、Teradata、SAP、SnapLogic和Snowflake等。数据湖提供商包括AWS、谷歌、Informatica、微软、Teradata等

4.2 数据湖保留全部的数据

存储范围

• 数据仓库开发期间，大量的时间花费在分析数据源，理解商业处理和描述数据。结果就是为报表设计高结构化的数据模型。
• 这一过程大部分的工作就是来决定数据应不应该导入数据仓库。通常情况下，如果数据不能满足指定的问题，就不会导入到数据仓库。这么做是为了简化数据模型和节省数据存储空间。
• 相反，数据湖保留所有的数据。不仅仅是当前正在使用的数据，甚至不被用到的数据也会导进来。数据会一直被保存所有我们可以回到任何时间点来做分析。
• 因为数据湖使用的硬件与数据仓库的使用的不同，使这种方法成为了可能。现成的服务器与便宜的存储相结合，使数据湖扩展到TB级和PB级非常经济。

存储来源

• 数据仓库主要存储来自运营系统的大量数据
• 而数据湖则存储来自更多来源的数据，包括来自企业的运营系统和其他来源的各种原始数据资产集。

 4.3 数据湖支持所有数据类型

• 在储存方面上，数据湖中数据为非结构化的，所有数据都保持原始形式，并且仅在分析时再进行转换。
• 数据仓库一般由从事务系统中提取的数据组成，并由定量度量和描述它们的属性组成。诸如Web服务器日志，传感器数据，社交网络活动，文本和图像等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现，但是消费和存储它们可能是昂贵和困难的。
• 数据湖方法包含这些非传统数据类型。在数据湖中，我们保留所有数据，而不考虑源和结构。我们保持它的原始形式，并且只有在我们准备好使用它时才会对其进行转换。这种方法被称为“读时模式”。
• 数据仓库则是捕获结构化数据并将其按模式组织。

 4.4 适用人群

• 由于数据湖中的数据可能不准确，并且可能来自企业运营系统之外的来源，因此不是很适合普通的业务分析用户;
• 数据湖更适合数据科学家和其他数据分析专家，使用他们需要的非常庞大和多样化的数据集。
• 其他用户则可以使用更为结构化的数据视图如数据仓库来提供他们使用的数据，数据仓库非常适用于月度报告等操作用途，因为它具有高度结构化。

4.5 数据湖很容易适应变化

• 关于数据仓库的主要抱怨之一是需要多长时间来改变它们。在开发过程中花费大量时间来获得仓库的结构。一个好的仓库设计可以适应变化，但由于数据加载过程的复杂性以及为简化分析和报告所做的工作，这些更改必然会消耗一些开发人员资源并需要一些时间。
• 许多业务问题都迫不及待地让数据仓库团队适应他们的系统来回答问题。日益增长的对更快答案的需求促成了自助式商业智能的概念。
• 另一方面，在数据湖中，由于所有数据都以其原始形式存储，并且始终可供需要使用它的人访问，因此用户有权超越仓库结构以新颖方式探索数据并回答它们问题在他们的步伐。
• 如果一个探索的结果被证明是有用的并且有重复的愿望，那么可以应用更正式的模式，并且可以开发自动化和可重用性来帮助将结果扩展到更广泛的受众。如果确定结果无用，则可以丢弃该结果，并且不会对数据结构进行任何更改，也不会消耗开发资源。
• 所以，在架构方面：
  • 数据湖通常在存储数据之后定义架构，使用较少的初始工作并提供更大的灵活性。
  • 数据仓库在存储数据之前定义架构。

4.6 数据湖支持快速洞察数据

• 

• 最后的区别实际上是其他区别结果。由于数据湖包含所有数据和数据类型，因为它使用户能够在数据转换，清理和结构化之前访问数据，从而使用户能够比传统数据仓库方法更快地获得结果。

• 但是，这种对数据的早期访问是有代价的。通常由数据仓库开发团队完成的工作可能无法完成分析所需的部分或全部数据源。这让用户可以根据需要探索和使用数据，但上述第一层业务用户可能不希望这样做。他们仍然只想要他们的报告和KPI。
• 在数据湖中，这些操作报告的使用者将利用更加结构化的数据湖中数据的结构视图，这些视图与数据仓库中以前一直存在的数据相似。不同之处在于，这些视图主要存在于位于湖泊中的数据之上的元数据，而不是需要开发人员更改的物理刚性表格。

5、数据湖和数据仓库理解误区

---

 5.1、误解一：数据仓库和数据湖二者在架构上只能二选一

很多人认为数据仓库和数据湖在架构上只能二选一，其实这种理解是错误的。数据湖和数据仓库并不是对立关系，相反它们的并存可以互补给企业架构带来更多的好处：

• 数据仓库存储结构化的数据，适用于快速的BI和决策支撑，
• 而数据湖可以存储任何格式的数据，往往通过挖掘能够发挥出数据的更大作为。

所以在一些场景上二者的并存是可以给企业带来更多效益的。

5.2、误解二：相对于数据湖，数据仓库更有名更受欢迎

• 人工智能（AI）和机器学习项目的成功往往需要数据湖来做支撑。因为数据湖可让您存储几乎任何类型的数据而无需先准备或清理，所以可以保留尽可能多的潜在价值。而数据仓库存储的数据都是经过清洗，往往会丢失一些有价值的信息。
• 数据仓库虽然是这两种中比较知名的，但是随着数据挖掘需求的发展，数据湖的受欢迎程度可能会继续上升。数据仓库对于某些类型的工作负载和用例工作良好，而数据湖则是为其他类型的工作负载提供服务的另一种选择。

5.3、误解三：数据仓库易于使用，而数据湖却很复杂

• 确实，数据湖需要数据工程师和数据科学家的特定技能，才能对存储在其中的数据进行分类和利用。数据的非结构化性质使那些不完全了解数据湖如何工作的人更难以访问它。
• 但是，一旦数据科学家和数据工程师建立了数据模型或管道，业务用户就可以利用建立的数据模型以及流行的业务工具（定制或预先构建）的来访问和分析数据，而不在乎该数据存储在数据仓库中还是数据湖中。

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

---

个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施，完善数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性，例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等，无一不是为了更好的贴近业务，更好的方便客户使用。数据湖所强调的一些基本的技术特性，例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等，也是为了满足业务需求，并且给业务方提供最具性价比的TCO。

数据湖的建设过程应该与业务紧密结合；但是数据湖的建设过程与传统的数据仓库，甚至是大热的数据中台应该是有所区别的。区别在于，数据湖应该以一种更敏捷的方式去构建，“边建边用，边用边治理”。为了更好的理解数据湖建设的敏捷性，我们先来看一下传统数仓的构建过程。业界对于传统数仓的构建提出了“自下而上”和“自顶而下”两种模式，分别由Inmon和KimBall两位大牛提出。具体的过程就不详述了，不然可以再写出几百页，这里只简单阐述基本思想。

1、Inmon提出自下而上（EDW-DM）的数据仓库建设模式，即操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层；

ODS层中的数据，根据预先设计好的EDW（企业级数据仓库）范式进行加工处理，然后进入到EDW。

EDW一般是企业/组织的通用数据模型，不方便上层应用直接做数据分析；因此，各个业务部门会再次根据自己的需要，从EDW中处理出数据集市层（DM）。

• 优势：易于维护，高度集成；
• 劣势：结构一旦确定，灵活性不足，且为了适应业务，部署周期较长。

此类方式构造的数仓，适合于比较成熟稳定的业务，例如金融。

2、KimBall提出自顶而下（DM-DW）的数据架构，通过将操作型或事务型系统的数据源，抽取或加载到ODS层；然后通过ODS的数据，利用维度建模方法建设多维主题数据集市（DM）。

各个DM，通过一致性的维度联系在一起，最终形成企业/组织通用的数据仓库。

• 优势：构建迅速，最快的看到投资回报率，敏捷灵活；
• 劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。

常应用于中小企业或互联网行业。

其实上述只是一个理论上的过程，其实无论是先构造EDW，还是先构造DM，都离不开对于数据的摸底，以及在数仓构建之前的数据模型的设计，包括当前大热的“数据中台”，都逃不出下图所示的基本建设过程。

• 

• 数据摸底：对于一个企业/组织而言，在构建数据湖初始工作就是对自己企业/组织内部的数据做一个全面的摸底和调研，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量等。在这个阶段一个隐含的重要工作是借助数据摸底工作，进一步梳理企业的组织结构，明确数据和组织结构之间关系。为后续明确数据湖的用户角色、权限设计、服务方式奠定基础

• 模型抽象：针对企业/组织的业务特点梳理归类各类数据，对数据进行领域划分，形成数据管理的元数据，同时基于元数据，构建通用的数据模型。
• 数据接入：根据第一步的摸排结果，确定要接入的数据源。根据数据源，确定所必须的数据接入技术能力，完成数据接入技术选型，接入的数据至少包括：数据源元数据、原始数据元数据、原始数据。各类数据按照第二步形成的结果，分类存放。
• 融合治理：简单来说就是利用数据湖提供的各类计算引擎对数据进行加工处理，形成各类中间数据/结果数据，并妥善管理保存。数据湖应该具备完善的数据开发、任务管理、任务调度的能力，详细记录数据的处理过程。在治理的过程中，会需要更多的数据模型和指标模型
• 业务支撑：在通用模型基础上，各个业务部门定制自己的细化数据模型、数据使用流程、数据访问服务

上述过程，对于一个快速成长的互联网企业来说，太重了，很多情况下是无法落地的，最现实的问题就是第二步模型抽象，很多情况下，业务是在试错、在探索，根本不清楚未来的方向在哪里，也就根本不可能提炼出通用的数据模型；没有数据模型，后面的一切操作也就无从谈起，这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。

数据湖应该是一种更为“敏捷”的构建方式，我们建议采用如下步骤来构建数据湖。

• 

对比，依然是五步，但是这五步是一个全面的简化和“可落地”的改进。

• 1)、数据摸底：依然需要摸清楚数据的基本情况，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量。但是，也就需要做这么多了。数据湖是对原始数据做全量保存，因此无需事先进行深层次的设计。
• 2)、技术选型：根据数据摸底的情况，确定数据湖建设的技术选型。事实上，这一步也非常的简单，因为关于数据湖的技术选型，业界有很多的通行的做法，基本原则个人建议有三个：
  • “计算与存储分离”、
  • “弹性”、
  • “独立扩展”。
• 3)、数据接入：确定要接入的数据源，完成数据的全量抽取与增量接入
  • 建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；
  • 计算引擎上建议重点考虑批处理需求和SQL处理能力，因为在实践中，这两类能力是数据处理的关键，关于流计算引擎后面会再讨论一下。无论是计算还是存储，建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了，再考虑构建专属集群。
• 4)、应用治理：这一步是数据湖的关键，我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看，数据应用和数据治理应该是相互融合、密不可分的。从数据应用入手，在应用中明确需求，在数据ETL的过程中，逐步形成业务可使用的数据；同时形成数据模型、指标体系和对应的质量标准。数据湖强调对原始数据的存储，强调对数据的探索式分析与应用，但这绝对不是说数据湖不需要数据模型；恰恰相反，对业务的理解与抽象，将极大的推动数据湖的发展与应用，数据湖技术使得数据的处理与建模，保留了极大的敏捷性，能快速适应业务的发展与变化

从技术视角来看，数据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用，需要具备相对完善的数据管理、类目管理、流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等能力。在计算能力上，目前主流的数据湖方案都支持SQL和可编程的批处理两种模式（对机器学习的支持，可以采用Spark或者Flink的内置能力）；在处理范式上，几乎都采用基于有向无环图的工作流的模式，并提供了对应的集成开发环境。对于流式计算的支持，目前各个数据湖解决方案采取了不同的方式。在讨论具体的方式之前，我们先对流计算做一个分类：

• 模式一：实时模式。这种流计算模式相当于对数据采用“来一条处理一条”/“微批”的方式进行处理；多见于在线业务，如风控、推荐、预警等。
• 模式二：类流式。这种模式需要获取指定时间点之后变化的数据/读取某一个版本的数据/读取当前的最新数据等，是一种类流式的模式；多见于数据探索类应用，如分析某一时间段内的日活、留存、转化等。

二者的本质不同在于，模式一处理数据时，数据往往还没有存储到数据湖中，仅仅是在网路/内存中流动；模式二处理数据时，数据已经存储到数据湖中了。综上，我个人建议采用如下图模式：

• 

如上图所示，在需要数据湖具备模式一的处理能力时，还是应该引入类Kafka中间件，作为数据转发的基础设施。完整的数据湖解决方案方案应该提供将原始数据导流至Kafka的能力。流式引擎具备从类Kafka组件中读取数据的能力。流式计算引擎在处理数据过后，根据需要，可以将结果写入OSS/RDBMS/NoSQL/DW，供应用访问。某种意义上，模式一的流计算引擎并非一定要作为数据湖不可分割的一部分存在，只需要在应用需要时，能够方便的引入即可。但是，这里需要指出的是：

• 流式引擎依然需要能够很方便的读取数据湖的元数据；
• 流式引擎任务也需要统一的纳入数据湖的任务管理；
• 流式处理任务依然需要纳入到统一的权限管理中。

对于模式二，本质上更接近于批处理。现在许多经典的大数据组件已经提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等经典的计算引擎。以HUDI为例，通过支持特殊类型的表（COW/MOR），提供访问快照数据（指定版本）、增量数据、准实时数据的能力。目前AWS、腾讯等已经将HUDI集成到了其EMR服务中，阿里云的DLA也正在计划推出DLA on HUDI的能力。

让我们再回到本文开头的第一章，我们说过，数据湖的主要用户是数据科学家和数据分析师，探索式分析和机器学习是这类人群的常见操作；流式计算（实时模式）多用于在线业务，严格来看，并非数据湖目标用户的刚需。但是，流式计算（实时模式）是目前大多数互联网公司在线业务的重要组成部分，而数据湖作为企业/组织内部的数据集中存放地，需要在架构上保持一定的扩展能力，可以很方便的进行扩展，整合流式计算能力。

• 5)、业务支撑：虽然大多数数据湖解决方案都对外提供标准的访问接口，如JDBC，市面上流行的各类BI报表工具、大屏工具也都可以直接访问数据湖中的数据。但是在实际的应用中，我们还是建议将数据湖处理好的数据推送到对应的各类支持在线业务的数据引擎中去，能够让应用有更好的体验。

7、主流厂商数据湖解决方案

---

7.1、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中具体目录的访问权限（分为显示和隐式两种）。如下图所示，用户A在只有数据存取的权限下，无法创建位于S3指定bucket下的表
  • 

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

综上，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的数据湖解决方案中，流计算和机器学习并不是固定捆绑的，只是作为计算能力扩展，能方便的集成。

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

• 

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

7.2  华为数据湖解决方案

• 

华为的数据湖解决方案相关信息来自华为官网。目前官网可见的相关产品包括数据湖探索（Data Lake Insight，DLI）和智能数据湖运营平台（DAYU）：

其中DLI相当于是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。官网上没找到关于DLI的整体架构图，我根据自己的理解，尝试画了一个，主要是和AWS的解决方案有一个对比，所以形式上尽量一致。

华为的数据湖解决方案比较完整，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的数据治理方法论的落地实现如下图所示（来自华为云官网）。

• 

可以看到，本质上DAYU数据治理的方法论其实是传统数据仓库治理方法论在数据湖基础设施上的延伸：从数据模型来看，依然包括贴源层、多源整合层、明细数据层，这点与数据仓库完全一致。

根据数据模型和指标模型会生成质量规则和转换模型，DAYU会和DLI对接，直接调用DLI提供的相关数据处理服务，完成数据治理。

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

7.3 阿里云数据湖解决方案

阿里云上数据类产品众多，阿里云的基于数据库产品的数据湖解决方案更加聚焦，主打数据湖分析和联邦分析两个场景。阿里云数据湖解决方案如下图所示

• 

整个方案依然采用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理念扩展到了数据湖，使得数据湖的运维、开发更加精细化。

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

• 

自左向右从数据的流向来看，数据生产者产生各类数据（云下/云上/其他云），利用各类工具，上传至各类通用/标准数据源，包括OSS/HDFS/DB等。

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

阿里云的DLA解决方案的另一个特色在于“基于云原生的湖仓一体化”。传统的企业级数据仓库在大数据时代的今天，在各类报表应用上依然是无法替代的；但是数仓无法满足大数据时代的数据分析处理的灵活性需求；因此，我们推荐数据仓库应该作为数据湖的上层应用存在：即数据湖是原始业务数据在一个企业/组织中唯一官方数据存储地；数据湖根据各类业务应用需求，将原始数据进行加工处理，形成可再次利用的中间结果；当中间结果的数据模式（Schema）相对固定后，DLA可以将中间结果推送至数据仓库，供企业/组织开展基于数仓的业务应用。

阿里云在提供DLA的同时，还提供了云原生数仓（原ADB），DLA和云原生数仓在以下两点上深度融合。

• 1） 使用同源的SQL解析引擎。DLA的SQL与ADB的SQL语法上完全兼容，这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。
• 2） 都内置了对于OSS的访问支持。OSS直接作为DLA的原生存储存在；对于ADB而言，可以通过外部表的能力，很方便的访问OSS上的结构化数据。借助外部表，数据可以自由的在DLA和ADB之间流转，做到真正的湖仓一体。

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

• 可以保存各类结构化、半结构化和非结构化数据；
• 可以对接各类异构数据源；
• 具备元数据发现、管理、同步等能力；
• 内置的SQL/Spark计算引擎具备更强的数据处理能力，满足多样化的数据处理需求；
• 具备全量数据的全生命周期管理能力。基于DLA+ADB的湖仓一体化方案，将同时覆盖“大数据平台+数据仓库”的处理能力。
• 

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

更重要的是，这种流动是受监管的，数据湖完整的记录了数据的流动情况。

7.4 Microsoft Azure数据湖解决方案

Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层，如下图所示（来自Azure官网）。

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

• 

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

开发工具的支持 与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进行扩展，满足定制开发需求。
• 多计算引擎的适配：SQL, Apache Hadoop和Apache Spark。这里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服务），Spark包括Azure Databricks。- 多种不同引擎任务之间的自动转换能力。

微软推荐U-SQL为数据湖的缺省开发工具，并提供各类转换工具，支持U-SQL脚本与Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之间的转化。

7.5 、小结

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

• 

出于篇幅关系，其实知名云厂商的数据湖解决方案还有谷歌和腾讯的。这两家从其官方网站上看，数据湖解决方案相对来讲比较简单，也仅仅是一些概念上的阐述，推荐的落地方案是“oss+hadoop（EMR）”。其实数据湖不应该从一个简单的技术平台视角来看，实现数据湖的方式也多种多样，评价一个数据湖解决方案是否成熟，关键应该看其提供的数据管理能力，具体包括但不限于元数据、数据资产目录、数据源、数据处理任务、数据生命周期、数据治理、权限管理等；以及与外围生态的对接打通能力。

8、数据湖总结

---

 数据湖总结：数据湖作为新一代大数据分析处理的基础设施，需要超越传统的大数据平台。个人认为目前在以下方面，是数据湖解决方案未来可能的发展方向。

8.1 云原生架构

关于什么是云原生架构，众说纷纭，很难找到统一的定义。但是具体到数据湖这个场景，个人认为就是以下三点特征：

• 存储和计算分离，计算能力和存储能力均可独立扩展；
• 多模态计算引擎支持，SQL、批处理、流式计算、机器学习等；
• 提供serverless态服务，确保足够的弹性以及支持按需付费。

8.2 足够用的数据管理能力

• 数据湖需要提供更为强大的数据管理能力，包括但不限于数据源管理、数据类目管理、处理流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等。

8.3 大数据的能力，数据库的体验

• 目前绝大多数数据分析人员都只有数据库的使用经验，大数据平台的能力虽强，但是对于用户来说并不友好，数据科学家和数据数据分析师应该关注数据、算法、模型及其与业务场景的适配，而不是花大量的时间精力去学习大数据平台的开发。
• 数据湖要想快速发展，如何为用户提供良好的使用体验是关键。基于SQL的数据库应用开发已经深入人心，如何将数据湖的能力通过SQL的形式释放出来，是未来的一个主要方向。

8.4 完善的数据集成与数据开发能力

• 对各种异构数据源的管理与支持，对异构数据的全量/增量迁移支持，对各种数据格式的支持都是需要不断完善的方向。同时，需要具备一个完备的、可视化的、可扩展的集成开发环境。

8.5 与业务的深度融合与集成

• 典型数据湖架构的构成基本已经成为了业界共识：分布式对象存储 + 多模态计算引擎 + 数据管理。

决定数据湖方案是否胜出的关键恰恰在于数据管理，无论是原始数据的管理、数据类目的管理、数据模型的管理、数据权限的管理还是处理任务的管理，都离不开与业务的适配和集成；未来，会有越来越多的行业数据湖解决方案涌现出来，与数据科学家和数据分析师形成良性发展与互动。如何在数据湖解决方案中预置行业数据模型、ETL流程、分析模型和定制算法，可能是未来数据湖领域差异化竞争的一个关键点。

Flag:

---

• 数据湖是一个概念，基本的架构构成：分布式对象存储 + 多模态计算引擎 + 数据管理
• 存储的数据视角：
  • 多元异构的原始数据；
  • 用于报告、可视化、探索分析、机器学习的转换数据。
• 应该具备的能力：
  • 数据要转换，那就需要有支撑海量数据清洗转换的分布式计算能力；
  • 数据要产生价值，那就需要有技术门槛低的AI平台来做探索分析；
• 数据治理的视角：
• 不同的海量数据共存，那就需要精细化数据治理。
• 数据要流出：就需要有统一的服务管理、权限管理
• 大数据基础设置架构：
  • Hadoop离线计划
  • Lambda
  • Kappa
  • 数据湖：新一代大数据基础架构。除了大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力
• 适用人群：
  • 数据湖存有完整的原始数据，适合数据科学家和数据分析师
  • 其它人员更适合于数据视图和数据仓库
• 数据湖与数据仓库
  • 数据仓库应该作为数据湖的上层应用存在，数据湖根据各类业务应用需求，将原始数据进行加工处理，形成可再次利用的中间结果；当中间结果的数据模式（Schema）相对固定后，可以将中间结果推送至数据仓库 （即 DataHouse）

所以：从这些特性上小结：理解为一套企业级的大数据平台岂可？ 包含有大数据基础平台技术支撑，有数据集中管控，分层治理的特性。

参考资料

---

• https://mp.weixin.qq.com/s/JwZonfmJldZTzxKYKZC0QQ