数据湖-1-数据湖的概念和基本特征

参考数据湖 | 一文读懂Data Lake的概念、特征、架构与案例

1 数据湖

1.1 数据湖的定义

如果需要给数据湖下一个定义，可以定义为这样：数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。

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

企业对数据湖寄予厚望，希望它能帮助用户快速获取有用信息，并能将这些信息用于数据分析和机器学习算法，以获得与企业运行相关的洞察力。

**数据湖(Data Lake)**概念最早是2011年由CITO Research网站的CTO和作家Dan Woods所提出，其比喻是：如果我们把数据比作大自然的水，那么各个江川河流的水未经加工，源源不断地汇聚到数据湖中。

数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。

数据湖概念的提出时间是仅次于大数据，可以说是一个很老的概念了。笔者认为数据湖本质上就是一个大数据平台，它随着大数据的技术不断完善，目前成熟的数据湖体系已具备了大数据存储、大数据处理、机器学习、大数据分析等等能力。

绝大部分企业的需求数据仓库基本都能满足了，只有少部分企业才能用到数据湖或大数据平台，好多企业都被忽悠上了大数据平台，光有个架子，却不知道能用来干嘛。对非结构化数据的处理，大多数企业本身除了数据存储之外，几乎不知道该怎么用。甚至大多数据企业连结构化数据都还处理不好，数据意识还停留在起步阶段。
（网名）所说的是事实，也是目前的普遍现象。但在笔者看来：一项新技术，一个新事物从诞生到发展到普及，是需要一个由“基础认知—知识学习—能力建设—探索应用—成熟应用”的过程。

在这个过程中，各企业的发展水平一定是参差不齐的，没有那两家企业的现状、需求、目标、数据是完全相同的，所以不同企业对数据的意识程度不相同、技术能力不一样、应用水平差异大也是正常的。

1.2 数据湖与企业的关系

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

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

企业数据中隐藏着多种能力，然而，在重要数据能够被具备商业数据洞察力的人使用之前，人们无法利用它们来改善企业的商业表现。

数据湖如何帮助企业
长期以来，企业一直试图找到一个统一的模型来表示企业中所有实体。
这个任务有极大的挑战性，原因有很多，下面列举了其中的一部分：
(1) 一个实体在企业中可能有多种表示形式，因此可能不存在某个完备的模型来统一表示实体。
(2)不同的企业应用程序可能会基于特定的商业目标来处理实体，这意味着处理实体时会采用或排斥某些企业流程。
(3)不同应用程序可能会对每个实体采用不同的访问模式及存储结构。

这些问题已困扰企业多年，并阻碍了业务处理、服务定义及术语命名等事务的标准化。

从数据湖的角度来看，我们正在以另外一种方式来看待这个问题。
使用数据湖，隐式实现了一个较好的统一数据模型，而不用担心对业务程序产生实质性影响。这些业务程序则是解决具体业务问题的“专家”。

数据湖基于从实体所有者相关的所有系统中捕获的全量数据来尽可能“丰满”地表示实体。

因为在实体表示方面更优且更完备，数据湖确实给企业数据处理与管理带来了巨大的帮助，使得企业具备更多关于企业增长方面的洞察力，帮助企业达成其商业目标。

1.3 数据湖的优点和缺点

企业会在其多个业务系统中产生海量数据，随着企业体量增大，企业也需要更智能地处理这些横跨多个系统的数据。

一种最基本的策略是采用一个单独的领域模型，它能精准地描述数据并能代表对总体业务最有价值的那部分数据。这些数据指的是前面提到的企业数据。

对企业数据进行了良好定义的企业当然也有一些管理数据的方法，因此企业数据定义的更改能保持一致性，企业内部也很清楚系统是如何共享这些信息的。

在这种案例中，系统被分为数据拥有者(data owner)及数据消费者(data consumer)。

对于企业数据来说，需要有对应的拥有者，拥有者定义了数据如何被其他消费系统获取，消费系统扮演着消费者的角色。

一旦企业有了对数据和系统的明晰定义，就可以通过该机制利用大量的企业信息。该机制的一种常见实现策略是通过构建企业级数据湖来提供统一的企业数据模型，在该机制中，数据湖负责捕获数据、处理数据、分析数据，以及为消费者系统提供数据服务。

数据湖能从以下方面帮助到企业：

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

1.4 数据湖是如何工作的

为了准确理解数据湖能给企业带来哪些好处，理解数据湖的工作机制以及构建功能齐全的数据湖需要哪些组件就显得尤为重要了。在一头扎进数据湖架构细节之前，不妨先来了解数据湖背景中的数据生命周期。

在一个较高的层面来看，数据湖中数据生命周期如图所示。

上述生命周期也可称为数据在数据湖中的多个不同阶段。
每个阶段所需的数据和分析方法也有所不同。

(1)数据处理与分析既可按批量(batch)方式处理，也可以按近实时(near-real-time)方式处理。数据湖的实现需要同时支持这两种处理方式，因为不同的处理方式服务于不同的场景。处理方式(批处理或近实时处理)的选择也依赖数据处理或分析任务的计算量，因为很多复杂计算不可能在近实时处理模式中完成，而在一些案例中，则不能接受较长的处理周期。

(2)同样，存储系统的选择还依赖于数据访问的要求。例如，如果希望存储数据时便于通过SQL查询访问数据，则选择的存储系统必须支持SQL接口。

如果数据访问要求提供数据视图，则涉及将数据存储为对应的形式，即数据可以作为视图对外提供，并提供便捷的可管理性和可访问性。

(3)最近出现的一个日渐重要的趋势是通过服务(service)来提供数据，它涉及在轻量级服务层上对外公开数据。每个对外公开的服务必须准确地描述服务功能并对外提供数据。此模式还支持基于服务的数据集成，这样其他系统可以消费数据服务提供的数据。

当数据从采集点流入数据湖时，它的元数据被捕获，并根据其生命周期中的数据敏感度从数据可追溯性、数据世系和数据安全等方面进行管理。

数据世系被定义为数据的生命周期，包括数据的起源以及数据是如何随时间移动的。它描述了数据在各种处理过程中发生了哪些变化，有助于提供数据分析流水线的可见性，并简化了错误溯源。可追溯性是通过标识记录来验证数据项的历史、位置或应用的能力。

1.5 数据湖与数据仓库的区别

很多时候，数据湖被认为与数据仓库是等同的。
实际上数据湖与数据仓库代表着企业想达成的不同目标。
下表中显示了两者的关键区别。

从图表来看，数据湖与数据仓库的差别很明显。然而，在企业中两者的作用是互补的，不应认为数据湖的出现是为了取代数据仓库，毕竟两者的作用是截然不同的。

1.6 数据湖的构建方法

不同的组织有不同的偏好，因此它们构建数据湖的方式也不一样。构建方法与业务、处理流程及现存系统等因素有关。

简单的数据湖实现几乎等价于定义一个中心数据源，所有的系统都可以使用这个中心数据源来满足所有的数据需求。虽然这种方法可能很简单，也很划算，但它可能不是一个非常实用的方法，原因如下：
(1)只有当这些组织重新开始构建其信息系统时，这种方法才可行。
(2)这种方法解决不了与现存系统相关的问题。
(3)即使组织决定用这种方法构建数据湖，也缺乏明确的责任和关注点隔离(responsibility and separation of concerns)。
(4)这样的系统通常尝试一次性完成所有的工作，但是最终会随着数据事务、分析和处理需求的增加而分崩离析。

更好的构建数据湖的策略是将企业及其信息系统作为一个整体来看待，对数据拥有关系进行分类，定义统一的企业模型。

这种方法虽然可能存在流程相关的挑战，并且可能需要花费更多的精力来对系统元素进行定义，但是它仍然能够提供所需的灵活性、控制和清晰的数据定义以及企业中不同系统实体之间的关注点隔离。

这样的数据湖也可以有独立的机制来捕获、处理、分析数据，并为消费者应用程序提供数据服务。

2 什么是数据湖

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

Wikipedia上说数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件，包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。

AWS定义数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。

微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义，数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。

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

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

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

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

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

3 数据湖的基本特征

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

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

在数据方面：

3.1 保真性

数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。
与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。

3.2 灵活性

上表一个点是 “写入型schema” v.s.“读取型schema”，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。

对于任何数据应用来说，其实schema的设计都是必不可少的，即使是mongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽量采用相同/相似的结构。

“写入型schema”背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。

数据湖强调的“读取型schema”，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。

因此，个人认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。

3.3 可管理

数据湖应该提供完善的数据管理能力。
既然数据要求“保真性”和“灵活性”，那么至少数据湖中会存在两类数据：原始数据和处理后的数据。

数据湖中的数据会不断的积累、演化。因此，对于数据管理能力也会要求很高，至少应该包含以下数据管理能力：数据源、数据连接、数据格式、数据schema（库/表/列/行）。
同时，数据湖是单个企业/组织中统一的数据存放场所，因此，还需要具有一定的权限管理能力。

3.4 可追溯

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

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

3.5 丰富的计算引擎

从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。
一般情况下，数据的加载、转换、处理会使用批处理计算引擎；

需要实时计算的部分，会使用流式计算引擎；

对于一些探索式的分析场景，可能又需要引入交互式分析引擎。

随着大数据技术与人工智能技术的结合越来越紧密，各类机器学习/深度学习算法也被不断引入，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。

因此，对于一个合格的数据湖项目而言，计算引擎的可扩展/可插拔，应该是一类基础能力。

3.6 多模态的存储引擎

理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如S3/OSS/HDFS/OBS），并且在需要时与外置存储引擎协同工作，满足多样化的应用需求。