什么是数据湖

数据湖是一个集中式存储库，是一种以原生格式存储各种大型原始数据集的数据库，它允许以任意规模存储所有结构化和非结构化数据。数据湖的概念最初是由大数据厂商提出的，表面上看，数据都是承载在基于可向外扩展的HDFS廉价存储硬件之上的。

什么是数据湖

数据湖的一部分价值是把不同种类的数据汇聚到一起，另一部分价值是不需要预定义的模型就能进行数据分析。

在商业智能和数据仓库还没有被淘汰的今天，大数据分析和大数据湖正在向更多类型的实时智能服务发展，这些实时的智能服务可以支持实时的决策制定。

使用数据湖能够在更短的时间内从更多来源利用更多数据，并使用户能够以不同方式协同处理和分析数据，从而做出更好、更快的决策。

数据湖详解

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

数据湖最早是由Pentaho的创始人兼CTO， James Dixon，在2010年10月纽约Hadoop World大会上提出来的。当时Pentaho刚刚发布了Hadoop的第一个版本。在这样的一个大背景下，可以合理的猜测，当时James Dixon提出数据湖的概念，是为了推广自家的Pentaho产品以及Hadoop的。

Pentaho是个BI分析组件。当时的BI分析主要是基于数据市场（Data Mart）的。数据市场的建立需要事先识别出感兴趣的字段、属性，并对数据进行聚合处理。这样BI分析面临两个问题：

只使用一部分属性，这些数据只能回答预先定义好（pre-determined）的问题。

数据被聚合了，最低层级的细节丢失了，能回答的问题被限制了。

而基于Hadoop的BI分析，可以解决这个问题——把所有数据都原样存在Hadoop中，后面需要的时候再来取用。如果说数据集市、数据仓库里面是瓶装的水——它是清洁的、打包好的、摆放整齐方便取用的；那么数据湖里面就是原生态的水——它是未经处理的，原汁原味的。数据湖中的水从源头流入湖中，各种用户都可以来湖里获取、蒸馏提纯这些水（数据）。

由此，数据湖的概念被提出来了，并引起了大家的普遍关注。

后来，不知怎么，又有一个新的特性加进来了：就是数据湖可以解决数据孤岛问题。——这个想法似乎也挺符合数据湖的理念的。各种数据源都汇聚到一个湖里，自然就解决了数据孤岛问题。——但这应该并不是James的本意。从他后来的blog中可以看出，他所认为的数据湖是这样的：

数据湖应该是来源于单一的数据源；

你可以有多个数据湖；

如果存储来自多个系统的数据并对他们进行关联，那么这不是数据湖，而是由多个数据湖填充而成的水上花园（Water Garden）

不过，创始人怎么想已经不重要了……目前大家普遍认为，解决数据孤岛是数据湖的一大特点，毕竟这是一个看上去很美好的事。但是，把解决数据孤岛作为数据湖的使命，也确实引入了不少问题。

轻松地收集数据：数据湖与数据仓库的一大区别就是，Schema On Read，即在使用数据时才需要Schema信息；而数据仓库是Schema On Write，即在存储数据时就需要设计好Schema。这样，由于对数据写入没有限制，数据湖可以更容易的收集数据。

从数据中发掘更多价值：数据仓库和数据市场由于只使用数据中的部分属性，所以只能回答一些事先定义好的问题；而数据湖存储所有最原始、最细节的数据，所以可以回答更多的问题。并且数据湖允许组织中的各种角色通过自助分析工具，对数据进行分析，以及利用AI、机器学习的技术，从数据中发掘更多的价值。

消除数据孤岛：数据湖中汇集了来自各个系统中的数据，这就消除了数据孤岛问题。

具有更好的扩展性和敏捷性：数据湖可以利用分布式文件系统来存储数据，因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格，因此天生具有更高的灵活性，从而提高了敏捷性。

数据湖刚提出来时，只是一个朴素的理念。而从理念变成一个可以落地的系统，就面临着许多不得不考虑的现实问题：

首先，把所有原始数据都存储下来的想法，要基于一个前提，就是存储成本很低。而今数据产生的速度越来越快、产生的量越来越大的情况下，把所有原始数据，不分价值大小，都存储下来，这个成本在经济上能不能接受，可能需要打一个问号。

其次，数据湖中存放这各类最原始的明细数据，包括交易数据、用户数据等敏感数据，这些数据的安全怎么保证？用户访问的权限如何控制？

再次，湖中的数据怎么治理？谁对数据的质量、数据的定义、数据的变更负责？如何确保数据的定义、业务规则的一致性？

数据湖的理念很好，但是它现在还缺乏像数据仓库那样，有一整套方**为基础，有一系列具有可操作性的工具和生态为支撑。正因如此，目前把Hadoop用来对特定的、高价值的数据进行处理，构建数据仓库的模式，取得了较多的成功；而用来落实数据湖理念的模式，遭遇了一系列的失败。这里，总结一些典型的数据湖失败的原因：

数据沼泽：当越来越多的数据接入到数据湖中，但是却没有有效的方法跟踪这些数据，数据沼泽就发生了。在这种失败中，人们把所有东西都放在HDFS中，期望以后可以发掘些什么，可没多久他们就忘那里有什么。

数据泥团：各种各样的新数据接入进数据湖中，它们的组织形式、质量都不一样。 由于缺乏用于检查，清理和重组数据的自助服务工具，使得这些数据很难创造价值。

缺乏自助分析工具：由于缺乏好用的自助分析工具，直接对数据湖中的数据分析很困难。一般都是数据工程师或开发人员创建一个整理后的小部分数据集，把这些数据集交付给更广泛的用户，以便他们使用熟悉的工具进行数据分析。这限制了更广泛的人参与到探索大数据中，降低了数据湖的价值。

缺乏建模的方**和工具：在数据湖中，似乎每一项工作都得从头开始，因为以前的项目产生的数据几乎没有办法重用。 其实，我们骂数据仓库很难变化以适应新需求，这其中有个原因就是它花很多时间来对数据进行建模，而正是有了这些建模，使得数据可以共享和重用。数据湖也需要为数据建模，不然每次分析师都得从头开始。

缺少数据安全管理：通常的想法是每个人都可以访问所有数据，但这是行不通的。企业对自己的数据是有保护本能的，最终一定是需要数据安全管理的。

一个数据湖搞定一切：大家都对能在一个库中存储所有数据的想法很兴奋。然而，数据湖之外总会有新的存储库，很难把他们全都消灭掉。 其实，大多数公司所需的，是可以对多种存储库联合访问功能。是不是在一个地方存储，并不是那么重要。

数据集成能力：

需要具备把各种数据源接入集成到数据湖中的能力。数据湖的存储也应该是多样的，比如HDFS、HIVE、HBASE等等。

数据治理能力：

治理能力的核心是维护好数据的元数据（metadata）。强制要求所有进入数据湖的数据必须提供相关元数据，应该作为最低限度的治理管控。没有元数据，数据湖就面临成为数据沼泽的风险。更丰富的功能还包括：

自动提取元元数据，并根据元数据对数据进行分类，形成数据目录。

自动对数据目录进行分析，可以基于AI和机器学习的方法，发现数据之间的关系。

自动建立数据之间血缘关系图。

跟踪数据的使用情况，以便将数据作为产品，形成数据资产。

数据搜索和发现能力：

如果把整个互联网想象成一个巨大的数据湖。那么，之所以人们可以这么有效的利用这个湖中的数据，就是因为有了Google这样的搜索引擎。人们可以通过搜索，方便地找到他们想要的数据，进而进行分析。搜索能力是数据湖的十分重要的能力。

数据安全管控能力：

对数据的使用权限进行管控，对敏感数据进行脱敏或加密处理，也是数据湖能商用所必须具备的能力。

数据质量检验能力：

数据质量是分析正确的关键。因此必须对进入数据湖中的数据的质量情况进行检验。及时发现数据湖中数据质量的问题。为有效的数据探索提供保障。

自助数据探索能力：

应该具备一系列好用的数据分析工具，以便各类用户可以对数据湖中的数据进行自助探索。包括：

支持对流、NoSQL、图等多种存储库的联合分析能力

支持交互式的大数据SQL分析

支持AI、机器学习分析

支持类似OLAP的BI分析

支持报表的生成

Delta Lake

Delta Lake是Databricks公司今年四月刚刚开源的一个项目。它基于自家的Spark，为数据湖提供支持ACID事务的数据存储层。主要功能包括：支持ACID事务、元数据处理、数据历史版本、Schema增强等。

Kylo

Kylo是Teradata开源的一个全功能的数据湖平台。它基于Hadoop和Spark。提供一套完整的数据湖解决方案，包括数据集成、数据处理、元数据管理等功能。功能比较齐全。

Dremio

Dremio是Dremio公司开源的一个DaaS平台。它主要基于Apache Arrow，提供基于Arrow的执行引擎，使得数据分析师可以对多种数据源的数据进行联合分析。

除此之外，还有一些商业的数据湖平台，比如zaloni。另外，各大云厂商也都提供了数据湖平台或数据湖分析服务，比如Azure、Amazon、阿里云等。

就数据湖这个概念来说，它有些模糊，并且太形象，所以很多人都可以发挥自己的想象扩展这个概念。以至于数据湖在概念层面还是有些混乱的。它缺少一系列标准化的、完善的定义。在实现层面，数据湖在架构上还不成熟。还缺乏一整套的方**、工具和生态圈。

但可以看到，数据湖仍在不断演化。在大数据时代，人们对数据湖能解决的一些问题，还是有需求的。

CIO之家-企业信息化知识平台 作者:歌湾汐云 来源:简书