数据湖的了解认识

数据湖概述

数据湖这一概念，最早是在2011年由CITO Research网站的CTO和作家Dan Woods首次提出。其比喻是：如果我们把数据比作大自然的水，那么各个江川河流的水未经加工，源源不断地汇聚到数据湖中。业界便对数据湖一直有着广泛而不同的理解和定义。

“数据湖是一个集中化存储海量的、多个来源，多种类型数据，并可以对数据进行快速加工，分析的平台，本质上是一套先进的企业数据架构。”

"数据湖"的核心价值在于为企业提供了数据平台化运营机制。随着DT时代的到来，企业急需变革，需要利用信息化、数字化、新技术的利器形成平台化系统，赋能公司的人员和业务，快速应对挑战。而这一切的数据基础，正是数据湖所能提供的。

维基上对它的解释：数据湖（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分析面临两个问题：

1. 只使用一部分属性，这些数据只能回答预先定义好（pre-determined）的问题。
2. 数据被聚合了，最低层级的细节丢失了，能回答的问题被限制了。

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

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

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

1. 数据湖应该是来源于单一的数据源；
2. 你可以有多个数据湖；
3. 如果存储来自多个系统的数据并对他们进行关联，那么这不是数据湖，而是由多个数据湖填充而成的水上花园（Water Garden）

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

ETL（Extract-Transform-Load）抽取、转换和加载。

经过这三步，数据仓库就建好了。这个“仓库”，主要是为了数据分析用途，比如用于BI、出报表、做经营分析等等。

简要总结下：数据库用于联机事务，通常为小数据量高频读写。

数据库等原始数据，经过ETL加工以后，就被装进了数据仓库。数据仓库主要用于联机分析业务，通常为大数据量读取。

虽然应用场景不一样，但他们都是结构化数据。

在相当长的一段时间内，他们联合起来，共同满足企业的实时“交易”型业务和联机“分析性”的业务。

随着时代的发展，数据的类型越来越多，人们对数据的需求也越来越复杂。

企业越来越看重这些“大数据”的价值，希望把他们存好、用好。

这些数据，五花八门，又多又杂，怎么存呢？

索性挖个大坑吧！

这就是数据湖的原型。说白了，数据湖就像一个“大水坑”，是一种把各类异构数据进行集中存储的架构。

为什么不是数据河Data River？

因为，数据要能存，而不是一江春水向东流。

为什么不是数据池Data Pool？

因为，要足够大，大数据太大，一池存不下。

为什么不是数据海Data Sea？

因为，企业的数据要有边界，可以流通和交换，但更注重隐私和安全，“海到无边天作岸”，那可不行。

so，数据湖，Data Lake，刚刚好。

可是，概念虽好，把这个“水坑”用好却不容易。

数据湖特点

数据湖本身，具备以下几个特点：

1.原始数据

海量原始数据集中存储，无需加工。数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据。数据湖可以包括来自关系数据库（行和列）的结构化数据，半结构化数据（CSV，日志， XML， JSON），非结构化数据（电子邮件，文档， PDF）和二进制数据（图像，音频，视频）。也就是数据湖将不同种类的数据汇聚到一起。

2.按需计算

使用者按需处理，不需要移动数据即可计算。数据库通常提供了多种数据计算引擎供用户来选择。常见的包括批量、实时查询、流式处理、机器学习等。

3.延迟绑定

数据湖提供灵活的，面向任务的数据编订，不需要提前定义数据模型。

数据湖优缺点

任何事物都有两面性，数据湖有优点也同样存在些缺点。

1.优点

1. 数据湖中的数据最接近原生的。这对于数据探索类需求，带来很大便利，可以直接得到原始数据。

2. 数据湖统一企业内部各个业务系统数据，解决信息孤岛问题。为横跨多个系统的数据应用，提供一种可能。

3. 数据湖提供了全局的、统一的企业级数据概览视图，这对于数据质量、数据安全..直到整体的数据治理，甚至提高到数据资产层面都大有裨益。

4. 数据湖改变了原有工作模式，鼓励人人了解、分析数据；而不是依赖于专门的数据团队的”供给”方式，可以提升数据运营效率、改善客户互动、鼓励数据创新。

缺点

1. 对数据的归集处理程度明显缺失，对于试图直接使用数据的用户来说显得有些过于“原材料”化，且数据太过冗余。应对这一问题，可通过”数据接入+数据加工+数据建模”的方式来解决。

2. 对数据湖基础层的性能有较高要求，必须依托高性能的服务器进行数据处理过程。这主要是来自于海量数据、异构多样化数据、延迟绑定模式等带来的问题。.

3. 数据处理技能要求高。这也主要是因为数据过于原始带来的问题。

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

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

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

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

数据湖与关联概念

1.数据湖与数据仓库

数据湖建设思路从本质上颠覆了传统数据仓库建设方法论。传统的企业数据仓库则强调的是整合、面向主题、分层次等思路。其两者并不是对等的概念，更多是包含；即数据仓库作为数据湖的一类“数据应用”存在。

两者可从以下维度进行对比：

1）存储数据类型

数据仓库是存储清洗加工过的，可信任的、结构良好的数据；数据湖则是存储大量原始数据，包括结构化的、半结构化的和非结构化的数据。在我们世界中，主要是由原始的、混乱的、非结构化的数据组成。

随着“混乱数据”的不断升级，人们对它的兴趣也不断增长，想要更好的理解它、从其中获取价值、并根据它做出决策。这就得需要一个灵活、敏捷、经济且相对轻松的解决方案，然而这些都不是数据仓库的强项。而且当有新的需求提出时，传统数据仓库又难以快速随之变化。

2）处理数据方式

如果需要加载到数据仓库中的数据，我们首先需要定义好它，这叫做写时模式（Schema-On-Write）。而对于数据湖，您只需加载原始数据，然后，当您准备使用数据时，就给它一个定义，这叫做读时模式（Schema-On-Read）。

这是两种截然不同的数据处理方法。因为数据湖是在数据到使用时再定义模型结构，因此提高了数据模型定义的灵活性，可满足更多不同上层业务的高效率分析诉求。

3）工作合作方式

传统的数据仓库的工作方式是集中式的，业务人员给需求到数据团队，数据团队根据要求加工、开发成维度表，供业务团队通过BI报表工具查询。

数据湖更多是开放、自助式的（self-service），开放数据给所有人使用，数据团队更多是提供工具、环境供各业务团队使用（不过集中式的维度表建设还是需要的），业务团队进行开发、分析。

2.数据湖 vs 大数据

数据湖的技术实现，与大数据技术紧密结合。

·通过Hadoop存储成本低的特点，将海量的原始数据、本地数据、转换数据等保存在Hadoop中。这样所有数据都在一个地方存储，能给后续的管理、再处理、分析提供基础。

·通过Hive、Spark等低成本处理能力(相较于RDBMS)，将数据交给大数据库平台剂型处理。此外，还可通过Storm、Flink等支持流式处理等特殊计算方式。

·由于Hadoop的可扩展性，可以很方便地实现全量数据存储。结合数据生命周期管理，可做到全时间跨度的数据管控

3.数据湖 vs 云计算

云计算采用虚拟化、多租户等技术满足业务对服务器、网络、存储等基础资源的最大化利用，降低企业对IT基础设施的成本，为企业带来了巨大的经济性；同时云计算技术实现了主机、存储等资源快速申请、使用，则同样为企业带来了更多的管理便捷性。在构建数据湖的基础设施时，云计算技术可以发挥很大作用。此外，像AWS、MicroSoft、EMC等均提供了云端的数据湖服务。

4.数据湖 vs 人工智能

近些年，人工智能技术再一次飞速发展，训练和推理等需要同时处理超大的，甚至是多个数据集，这些数据集通常是视频、图片、文本等非结构化数据，来源于多个行业、组织、项目，对这些数据的采集、存储、清洗、转换、特征提取等工作是一个系列复杂、漫长的工程。数据湖需要为人工智能程序提供数据快速收集、治理、分析的平台，同时提供极高的带宽、海量小文件存取、多协议互通、数据共享的能力，可以极大加速数据挖掘、深度学习等过程。

5.数据湖 vs 数据治理

传统方式下，数据治理工作往往是在数据仓库中。那么在构建企业级数据湖后，对数据治理的需求实际更强了。因为与”预建模”方式的数仓不同，湖中的数据更加分散、无序、不规格化等，需要通过治理工作达到数据”可用”状态，否则数据湖很可能会”腐化”成数据沼泽，浪费大量的IT资源。平台化的数据湖架构能否驱动企业业务发展，数据治理至关重要。这也是对数据湖建设的最大挑战之一。

6.数据湖 vs 数据安全

数据湖中存放有大量原始及加工过的数据，这些数据在不受监管的情况下被访问是非常危险的。这里是需要考虑必要的数据安全及隐私保护问题，这些是需要数据湖提供的能力。但换种角度来看，将数据集中在数据湖中，其实是有利于数据安全工作的。这要比数据分散在企业各处要好的多。

数据湖的架构体系

数据湖是一种存储架构，本质上讲是存储，企业基于云服务，可以快速挖出一个适合自己的“湖”，完成数据的采集、存储、处理、治理，提供数据集成共享服务、高性能计算能力和大数据分析算法模型，支撑经营管理数据分析应用的全面开展。为规模化数据应用赋能。

数据湖技术架构涉及了数据接入（转移）、数据存储、数据计算、数据应用、数据治理、元数据、数据质量、数据资源目录、数据安全及数据审计等10个方面领域：

1.数据接入（移动）

数据提取允许连接器从不同的数据源获取数据并加载到数据湖中。数据提取支持：所有类型的结构化，半结构化和非结构化数据。批量，实时，一次性负载等多次摄取；在数据接入方面，需提供适配的多源异构数据资源接入方式，为企业数据湖的数据抽取汇聚提供通道。

2.数据存储

数据存储应是可扩展的，提供经济高效的存储并允许快速访问数据探索。它应该支持各种数据格式。

3.数据计算

数据湖需要提供多种数据分析引擎，来满足数据计算需求。需要满足批量、实时、流式等特定计算场景。此外，向下还需要提供海量数据的访问能力，可满足高并发读取需求，提高实时分析效率。并需要兼容各种开源的数据格式，直接访问以这些格式存储的数据。

4.数据治理

数据治理是管理数据湖中使用的数据的可用性，安全性和完整性的过程。数据治理是一项持续的工作，通过阐明战略、建立框架、制定方 针以及实现数据共享，为所有其他数据管理职能提供指导和监督。

5.元数据

元数据管理是数据湖整个数据生命周期中需要做的基础性工作，企业需要对元数据的生命周期进行管理。元数据管理本身并不是目的，它是组织从其数据中获得更多价值的一种手段，要达到数据驱动，组织必须先是由元数据驱动的。

6.数据资源目录

数据资源目录的初始构建，通常会扫描大量数据以收集元数据。目录的数据范围可能包括全部数据湖中被确定为有价值和可共享的数据资产。数据资源目录使用算法和机器学习自动完成查找和扫描数据集、提取元数据以支持数据集发现、暴露数据冲突、推断语义和业务术语、给数据打标签以支持搜索、以及标识隐私、安全性和敏感数据的合规性。

7.隐私与安全

数据安全是安全政策和安全程序的规划、开发和执行、以提供对数据和信息资产的身份验证、授权、访问和审核。需要在数据湖的每个层中实现安全性。它始于存储，发掘和消耗，基本需求是停止未授权用户的访问。身份验证、审计、授权和数据保护是数据湖安全的一些重要特性。

8.数据质量

数据质量是数据湖架构的重要组成部分。数据用于确定商业价值，从劣质数据中提取洞察力将导致质量差的洞察力。数据质量重点关注需求、检查、分析和提升的实现能力，对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的各类数据质量问题进行识别、度量、监控、预警等一系列活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高。

9.数据审计

两个主要的数据审计任务是跟踪对关键数据集的更改：跟踪重要数据集元素的更改；捕获如何/何时/以及更改这些元素的人员。数据审计有助于评估风险和合规性。

10.数据应用

数据应用是指通过对数据湖的数据进行统一的管理、加工和应用，对内支持业务运营、流程优化、营销推广、风险管理、渠道整合等活动，对外支持数据开放共享、数据服务等活动，从而提升数据在组织运营管理过程中的支撑辅助作用，同时实现数据价值的变现。在基本的计算能力之上，数据湖需提供批量报表、即席查询、交互式分析、数据仓库、机器学习等上层应用，还需要提供自助式数据探索能力。

如何通过数据治理实现数据湖商业价值

数据湖对一个企业的数字化转型和可持续发展起着至关重要的作用。构建开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。

1. 利用数据湖智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足企业各级数据分析应用需求。

2. 深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。

数据湖遇到挑战

数据湖本身是一个中心化的存储，能够存储任意规模的结构化与非结构化数据。数据湖的优势就是数据可以先作为资产存放起来，问题就在于如何把这些数据在业务中利用起来。当部署了数据湖之后，数据治理问题将会接踵而至，比如从数据湖到数据湖，如何将数据进行分流、湖的数据如何进行整理等。

数据仓库里的数据是经过过整理、清晰易懂的。而数据湖的概念是不经处理直接进行堆砌，那么数据湖就有可能会变成“数据沼泽”，筛选难度会变大。由于定义不正确、信息不完整、数据陈旧或无法找到所需信息，它需要更多的元数据来理解存储在数据湖中的数据资产，包括数据内容、数据资产图谱、数据敏感性、用户喜好、数据质量、上下文（缺乏上下文将无法用于分析）和数据价值等业务层面的理解。另外这些系统和应用是技术人员开发的，由于技术人员和业务人员的思维和“语言”存在差异，这使得业务用户获取数据变得更加复杂和困难。

1.避免数据沼泽

如何让数据湖的水保持清亮不会成为数据沼泽？“数据湖的数据不被有效使用就会成为大垃圾场。”中国有句谚语：“流水不腐，户枢不蠹”。数据只有流动起来，才可以不成为数据沼泽，湖泊只是暂存数据河流的基地。数据流动就意味着所有的数据产生，最终要有它的耕种者和使用者。要让数据有效流动起来，就要建立有效的“数据河”（Data River）。业界在数据湖的尝试上一般都会忽视数据治理的重要性，这是很危险的，由它导致的数据沼泽也是企业对数据湖持续观望的原因之一。

2.数据智能化治理是数据湖实现价值必有之路

对数据治理的需求实际更强了。因为与“预建模”方式的数仓不同，湖中的数据更加分散、无序、不规则化等，需要通过治理工作达到数据“可用”状态，否则数据湖很可能会“腐化”成数据沼泽，浪费大量的IT资源。平台化的数据湖架构能否驱动企业业务发展，数据治理至关重要，没有数据湖治理，企业可能失去有意义的商业智能。这也是对数据湖建设的最大挑战之一。

考虑全面的数据湖治理，包括是谁引入的数据、谁负责数据，以及数据的定义，以确保数据的妥善标记和使用，实现对企业数据资源内容层面的优化改造和有效管控。

数据湖的未来展望

现阶段数据湖更多是作为数据仓库的补充，数据湖概念和技术还在不断演化，不同的解决方案供应商也在添加新的特性和功能，包括架构标准化和互操作性、数据治理要求、数据安全性等。

数据湖作为一种云服务随时按需满足对不同数据的分析、处理和存储需求，数据湖的扩展性，可以为用户提供更多的实时分析，基于企业大数据的数据湖正在向支持更多类型的实时智能化服务发展，将会为企业现有的数据驱动型决策制定模式带来极大改变。

数据湖发展到现在，已经成为企业数据体系的基础：数据库、数仓、大数据处理、机器学习等各种数据服务，都可以“一湖尽收”。在这个“上云用数赋智”时代，很多企业已经完成上云第一步，接下来，就是如何“用数”和“赋智”。