一、数据湖概念

步骤

• 了解企业数据使用方面的需求
• 了解需求催生数据湖架构
• 数据湖和传统的数仓的简单对比

1.1 企业的数据困扰

我们学习到这里，已经接触到了如：数据库、数据仓库、oSQL数据库、消息队列、流式计算、缓存等等一系列的数据管理形式。

我们来回顾一下，这些数据管理形式都分别提供了什么功能：

• 数据库提供数据的存储和查询
• 数据仓库提供数据的集中存储的分析
• NoSOL数据库也同样提供数据的存储的查询
• 消息队列提供数据的转移通道
• 流式计算提供高效的数据的加工和分析
• 缓存系统提供数据的快速加载

可以看到，以上我们接触到的数据管理形式，提供了多种多样的功能，正常来说，应该已经足以满足企业在数据管理和利用方面的各种需求。

但是，我们仍会说，企业有数据管理和利用方面的闲扰

困扰一: 互联网的兴起和数据孤岛

随着互联网的兴起，企业内客户数据大量涌现。为了存储这些数据，单个数据库已不再足够，公司通常会建立多个按业务部门组织的数据库来保存数据。随着数据量的增长，公司通常可能会构建数十个独立运行的业务数据库，这些数据库具有不同的业务和用途

一方面，这是一种福气：有了更多，更好的数据，公司能够比以往更精确地定位客户并管理其运营。

另一方面，这导致了数据孤岛：整个组织中数据分散到各个地方

由于无法集中存储和利用这些数据，公司对于数据的利用效率并不高。

这样的痛苦让公司逐步走向数仓的利用模式。

困扰二: 非结构化数据

随着数据仓库的兴起，人们发现，数据孤岛的问题貌似被数仓解决了。我们通过正TL、数据管道等程序，从各个数据孤岛中抽取数据注入数仓中等待进行维度分析。看起来有一种数据集中存储的样子。但是随着互联网的加速发展，数据也产生了爆发性的增长，数仓就表现出来了一点力不从心：

1.数据增长的太快，而由于数据建模的严格性，每开发一次数仓的新应用，流程就很长。无法适应新时代对于数据快速分析、快速处理的要求

2.随着数据行业和大数据处理技术的发展，原本被遗忘在角落中的一些价值密度低的非结构化数据便慢慢了有了其价值所在，对于这些大量的非结构化数据（月志、记录、报告等)的分析也逐步提上日程

但是，数仓并不适合去分析非结构化的数据，因为数仓的严谨性，其只适合处理结构化的数据。那么，对于非结构化数据的处理数仓就不太适合。

困扰三：保留原始数据

在以前，由于大规模存储的成本和复杂性以及大数据技术尚未开始蓬勃发展等客观原因，造成企业对于数据的存储是精简的。
也就是，能够存入到企业系统中的数据都是经过处理提炼的，这些数据除了价值密度低的信息，只保留了和业务高度相关的核心内容。

这样可以有效的减少企业的数据容量，也就减少了存储的成本、以及管理维护的复杂度。

但这样做是有一定的缺点的，那就是企业并不保留原始数据（或者说保留部分），一旦出现数据错误或者其它问题，想要从原始的数据中进行溯源就难以完成了。并且，业务并不是一成不变的，当初因为业务被精简掉的内容，可能对未来的业务有所帮助。

所以无法太量的长期保存原始数据也是企业的困扰之一

• 数据孤岛
• 非结构化数据分析
• 想要海量的保存原始数据

基于这3个最主要的困扰，企业迫切希望能够做到：

• 数据的集中存储（解决数据孤岛），并且成本可控，使用维护简单
• 可以存储任意格式的数据（结构化的、非结构化的、半结构化的）
• 能够支特大多数分析框架

那么，数据湖的概念也就因这三种需求被逐步的提出并走向人们的视野中。集中存储，成本可控，使用简单，能够支持任意格式输入并拥有分析处理能力

1.2数据湖的提出

在2011年左右，开源大数据技术(Hadoop)逐步进入企业的视野也开始了蓬勃发展。

大数据技术带来了：

• 海量数据分析的可能性
• 低成本、易维护管理的分布式存储

与此同时，基于大数据技术带来的优势以及企业对数据的困扰所产生的需求，在2011年，数据湖的概念也被提出在概念中提到，数据湖应该做到：

• 集中存储
• 保留原始数据格式
• 支持任意格式
• 支持海量数据分析

以上的诉求，大数据技术体系均可以满足。此时，企业开始走向构建数据湖的时代。

数据湖的提出，是基于大数据技术的发展，如果没有大数据技术，数据湖的概念很难被落实。

1.3所以，数据湖是什么？

根据前面的内容，我们可以得出，数据湖就是：

一种支持任意数据格式、并保留原始数据内容的大规模存储系统架构，并且其支持海量数据的分析处理。

• 大规模存储系统架构
  • 支持任意数据格式的输入，并做到集中存储
  • 能够保留海量的原始数据
• 支持海量数据分析处理

1.4为什么叫做数据的湖？

我们知道，IT技术的命名有时候是和其本身关系不大的，比如adoop、Pig、Spark等。有时候看名字我们就知道其是做什么的，比如Flume、Zookeeper等。

数据湖的命名(Data Lake)就是第二种，名字贴合其实际意义的。
为什么是湖泊呢？

我们前面说过，数据湖应该做到：

• 集中存储
• 支持任意数据格式输入
• 等

那么，这样的要求，是不是很像：无论大小河流（任意格式）均可将水汇入湖泊中（集中存储）。

所以，从名字中我们可以解析到，数据湖就是一个巨大的数据集合，汇聚了来自各个系统的任意格式的原始数据，并且能够对湖泊进行利用分析，进行水的流出（分析、利用的结果)

1.5数据仓库数据集市-数据湖区别

我们应该听说过以下3个概念：

• 数据仓库
• 数据集市
• 数据湖

那么这三者到底有什么区别呢？

数据湖：

是整个公司内的一个开放的数据中心，接收任意类型的数据输入，对数据进行集中存储，并能对这些数据提供分析服务。

数据仓库：

是整个公司的业务数据集合，主要针对结构化的业务数据，并能提供查询分析服务。

数据集市：

是一个小型的部门级别或者工作组级别的数仓。其内部数据主要针对指定业务范围，或者为指定人员提供服务。

2.1写时模式VS读时模式

为了更好的理解数据湖，我们先了解一下：

• 写时榄式
• 读时模式

写时模式

数据在写入之前，就需要定义好数据的schema，数据按照schema的定义写入

读时模式

数据在写入的时候，不需要定义Schema，在需要使用的时候在使用Schema定义它

写时模式和读时模式是两种截然不同的数据处理方法。

我们前面学习的如：数据库、数据仓库、数据集市或者具体的一些框架如：Mysq1，Redis, HBase等均是写时模式，即数据在写入之前就需要预先有Schema定义好才可以。

而数据湖就是一种读时模式思想的具体体现

相比较写时模式而言，读时模式因为是数据在使用到的时候再定义模型结构(Scma)，因此能够提高数据模型定义的灵活性，可以满足不同上层业务的高效率分析需求。

因为，对于写时模式而言，如果想要事后更改Schema是有很高的成本的.

而读时模式可以在用的时候再定义Schema就很灵活了，同一套数据可以用不同的Schema来定义，来获取不同的效果。

2.2 数据湖构建的几种常规方式

想必同学们学习到这里，应该会有一定的疑惑，就是：

数据湖是一种新型的数据库吗？还是一种新推出的技术框架吗？

答案是：NO

我们前直给数据湖一个定义，就是：

数据湖是一种支持任意数据格式、并保留原始数据内容的大规模存储系统架构，并且其支持海量数据的分析处理。

那么根据定义可以看出，数据湖是一种系统的架构方案，它并不是一种特殊的数据库，也不是某一种技术框架。数据湖是一种概念，一种解决问题的思路，一种数据治理的方案、一种企业大规模数据集中存储并利用的架构思想

那么，数据湖架构是怎么实现的呢？

方案一：基于Hadoop生态体系的数据湖实施方案

实际上，多数企业对于Hadoop生态的使用，本质上是一种数据湖思想的体现。如，企业中会使用：

• HDFS来作为存储层，存储各类各样的原始数据，不管是结构的、半结构的、还是非结构的，均在HDFS存储。
• 使用Spark、SparkSQL、MR等计算框架作为分析引擎，对原始数据进行分析、抽取、计算、利用。
• 使用Flume、Kafka等持续不断的为HDFS落地新数据
• 使用Fink、Storm等实时分析HDFS的数据以及落地结果至HDFS之上。

实际上，以上的解决方案或者说数据架构，就是数据湖的思想。

我们在来回想一下

以上的技术利用，是不是满足了：

• 无论何种数据均可落地存储(HDFS)
• 无论何种数据均可分析(Spark、MR)

所以说，我们的结论就是：

数据湖，本质上就是要为企业构建一个数据治理方案，方案可以满足：无论何种数据（结构、半结构、非结构），均可集中存储，并能够提供分析服务，并且能够支撑海量的数据。

另外，集中存储也是一个很重要的概念。数据湖的思想是，数据（原始数据）均集中存储起来，在需要的时候可以快速抽取进行计算，避免这里存一份，那里存一份。集中存储，集中利用。

HDFS作为底层存储层，在企业业务系统中一般是均可访问到的（视权限管控的具体情况），那么对于企业来说，HDFS无处不在，在任何需要数据的时候，均随时从HDS中抽取即可。

• 可以直接让Spark、.SparkSQL(读时模式，后定义Schema)去分析
• 可以直接将数据扔给A集群去做训练
• 可以直接走ETL过程将数据扔入数仓

那么，以这种结论来看，多数企业均在使用数据湖这样的思想去治理数据。

方案二：基于云平台的数据湖实施方案

通过方案一的讲解，我们应该明白：数据湖不是技术框架，而是数据治理的方案这句话的意思了。
那么，在云平台上，基于云平台提供的技术架构和具体组件来协助构建企业的数据湖实施方案也是一种可行并高效的方式。
我们以AWS为例：

• 以S3对象存储服务为核心，提供数据湖的存储层，做到集中存储，随处访问（视权限管控结果）
• 以DynamoDB,Amazon ES等服务提供元数据存储和查询(Schema存储)
• 以Firehose、Snowball等服务提供数据导入功能
  ·以Athena、EMR、Redshift等服务提供数据的处理和分析功能
  ·以STS、Cloudwatch、IAN、API Gatewa等服务提供数据中心的安全、认证、访问、用户接口等功能

可以看出，其实和Hadoop生态体系的数据湖差不多，也是由一个核心的存储层提供集中存储(HDFS、S3)，然后由一系列计算引擎提供分析计算(Spark、EMR)，并由一系列其它辅助工具提供额外功能，如：数据导入、权限管控、元数据存储等。

方案三：基于商业公司提供的商业数据湖产品

部分公司选择使用相关商业产品（收费）来构建企业的数据湖生态。如：Zaloni等。

商业公司的商业产品，一般均为闭源实现，且价格不菲，多数为大型企业以及相关传统企业选用。

主要是花钱买服务，一般许多传统行业（非互联网等科技企业）的大型公司愿意选用，因为本身并没太多的技术人员，但又有相关需求，比较倾向花钱一套解决。

商业产品这里不多做介绍，我们主要关注于Hadoop生态和云平台相关。

2.3企业为何需要数据湖？对企业有何用处？

我们先来看一下，企业中数据仓库的开发流程。

一般，我们如果想要开发一个新的数仓应用
其开发流程是：

• 提出数仓应用的需求（需要某某某报表，指标分析）
• 根据需求，设计数仓的模型和表结构
• 设计完成后，编码应用ETL等工具完成数据的输入

可以发现，数仓的开发是倒序进行的，是以需求为导向的。

这是写时模式的一种体现，并且在前期进行需求分析、模型设计、项目编码等一系列操作是传统的应用开发模式，比较耗时并繁琐。

在传统的过去，这种开发形式没有太多问题，但是在数据大规模增长的今天，如果企业100%依赖数仓这种模式来进行数据的价值提炼，那么企业就很可能跟不上时代发展的步伐。

所以，数据湖的价值就体现了出来，除了为企业解决我们先前提到的三个困扰以外，还有一点对企业很有价值的就是：

基于数据湖的开发模式是一种读时模式，是一种灵活的、快速的数据处理思路，可以快速的对以后数据进行数据分析，并让其立刻产生价值。并且重要的是，它能在数字化的新浪潮下，真正的帮助企业完成技术转型、完成数据积累、完成高效的数据治理，应对快速发展的商业环境下层出不穷的新问题。

2.4数据湖概念总结

寥寥草草的说了这么多，我们来总结一下数据湖的一些特点

2.4.1 特点

• 不限格式，来之不拒，均可流入
  当前的时候，数据增长巨大、数据来源也是各种各样，不管是结构的、半结构的、还是非结构的，都可以流入数据湖做集中存储，方便利用的时候进行分析

• 集中存储、到处可访问
  数据集中存储起来(Hadoop:生态使用HDFS、云平台使用S3、OSs等)，在需要的时候随时进行访问，避免了在一些模式下，许多业务的数据均分散存储，这里一部分那里一部分，需要做许多前置工作才能将数据汇总聚合。

• 高性能分析能力
  借助于Spark、.MR、SparkSQL等高性能分析计算引擎，可以对海量的数据进行分析

• 原始数据存储
  大量的保留原始数据，让每一个字段每一段信息都发挥其价值，并更好的为企业提供数据溯源、数据修复等一系列功能。

2.4.2 对比数仓

前面我们简单的对比了一下：数据湖、数仓、数据集市

随着我们对数据湖概念了解的加深，我们再次对比一下数仓：

模式上：

• 数仓：写时模式，数据写入前已经定义好Schema,更改Schema成本较高
• 数据湖：读时模式，数据在利用的时候再定义Schema,灵活方便，典型例子：SparkSQL

基于SparkSQL的后定义Schema(读时模式)，目前，多数数据湖的实现方案里面，SparkSOL占了很大的份额。

使用思维上：

• 数仓：先有报表需求，根据需求确定数仓Schema,然后通过ETL过程将数据导入。也就是，先有需求、后准备数据
• 数据湖：并不需要根据需求来开发数据业务。数据集中存储，需要的时候再利用。也就是，先有数据，再根据已有数据开发业务。
  这样的方式对比数仓好在：
  • 可以完整的保留数据的结构，不会因为ETL过程损失数据信息
  • 可以加快数据开发的进度，适应企业不断增长的业务需求

处理数据上

• 数仓：只针对结构化数据、或部分有严格格式的半结构化数据
• 数据湖：接受任何数据输入

2.4.3数据湖的优势

• 轻松的收集数据（读时模式）：数据湖与数据仓库的一大区别就是，Schema On Read,即在使用数据时才需要Schema信息；而数据仓库是Schema On Write,即在存储数据时就需要设计好Schema.。这样，由于对数据写入没有限制，数据湖可以更容易的收集数据
• 不需要关心数据结构：存储数据无限制，任意格式数据均可存储，只要你能分析就能存。
• 全部数据都是共享的（集中存储），多个业务单元或者研究人员可以使用全部的数据，以前由于一些数据分布于不同的系统上，聚合汇总数据是很麻烦的。
• 从数据中发掘更多价值（分析能力）：数据仓库和数据市场由于只使用数据中的部分属性，所以只能回答一些事先定义好的问题；而数据湖存储所有最原始、最细节的数据，所以可以回答更多的问题。并且数据湖允许组织中的各种角色通过自助分析工具(MR、Spark、.SparkSQL等)，对数据进行分析，以及利用l、机器学习的技术，从数据中发掘更多的价值。
• 具有更好的扩展性和敏捷性：数据湖可以利用分布式文件系统来存储数据，因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格，因此天生具有更高的灵活性，从而提高了敏捷性。

2.4.4数据湖的要求

想必大家应该对数据湖有了清晰的认知了，那么，为了满足我们需要的：

• 集中存储
• 任意格式输入
• 强大的分析能力

我们需要对数据湖的实现提出如下的要求：

1. 安全：数据集中存储，就对数据安全有了更高的要求，对权限的管控要求更加严格。
2. 可拓展的：随着业务扩张、数据增多，要求数据湖体系可以随需求扩展其能力：
3. 可靠的：作为一个集中存储的数据中心，可靠性也很重要，三天两头坏掉那是不可以的。
4. 吞吐量：数据湖作为海量数据的存储，对数据的吞吐量要求就必须很高。
5. 原有格式存储：数据湖我们定义为所有数据的原始数据集中存储库，那么存储进入数据湖的数据就是未经修饰的、原始的数据
6. 支持多种数据源的输入：不限制数据类型，任意数据可以写入
7. 多分析框架的支持：因为数据格式各种各样，并不全是结构化数据，所以，要求支持多种分析框架对数据湖中的数据进行提取、分析。包括但不限于：批处理的、实时的、流的、机器学习的、图形计算的等等。

2.5 数据湖架构的4个指导原则

数据湖在架构的时候，遵循如下4个设计指导原则：

原则1：分离数据和业务

在数据湖的架构设计中，不考虑业务，只考虑数据。

也就是我们只站在数据的层面去考虑敲如何去高效的写入、如何实现可用的集中存储

而不会在这个过程中，考虑业务，为业务对数据做适配。这些考虑是数仓应该做的。

原则2：存储和计算的分离（可选，比较适用云平台）

有这样一个问题，当计算容量的不够的时候，我们需要对计算进行扩容，但是一般的Hadoop使用中，计算和存储是在一起的。(datanode和计算节点复用，为了做数据本地计算)

对计算进行扩容就会导致存储也一样扩容，那么，存储的rebalance,就会造成存储的资源消耗。

也就是说白了，计算的扩容受到存储的制约，无法灵活的扩容缩容。

所以，最好的情况，就是做计算和存储的分离。
存储是存储，计算是计算。
但对于传统的Hdoo集群来说，做分离的话，就对网络环境要求极高，因为当数据无法在本地计算的时候，就需要走网络传输。
那么，交换机等内网性能就会是很大的挑战。
所以，对于多数受到成本制约的公司来说，存储和计算的分离是可选的原则因伪其成本较高。

但是，对于云平台来说就没有这方面的倾虑。
云平台基本上都是，天生的计算和存储分离的：
如AWS的S3作为存储，其计算是和S3没有任何关联的。
如Azure的Blob存储，其计算也和Blob无关
同样，如阿里云的0SS存储，也是和计算没有关系的。
所以，如果要在云平台上实现数据湖，那么一个天生的优势就是，计算和存储很容易就分离了。

原则3：Lambda架构VS Kappa架构VS IOTA架构

数据湖构建好后，数据总要被利用、被分析而一个好的数据利用的架构可以高效的去处理数据湖内的海量数据。
数据处理的架构，一般有Lambda架构、Kappa架构、IoTA架构等。
关于这些架构，请参阅后面的拓展章节内的介绍。

原则4：管理服务的重要性和选择合适的工具

数据湖不仅仅是一个存储那么简单，存储是为了利用，为了达到这一点，我们需要：

• 对数据进行安全管理
• 对访问进行权限管控
• 需要ETL等将数据汇入数据湖
• 需要使用合适批处理、流处理去分析去计算
• 用户前端工具，如BI展示、REST API等
• 等等，一些列周边围绕的服务

也就是，实现一个数据湖需要许多服务的协同配合，不仅仅是存储那么简单，所以这些管理服务以及相关的辅助工具对于数据湖来说是很重要的。

那么，适当的管理服务可以帮助我们更加简便的设计数据湖的架构。

如上，是数据湖架构的4个指导原则，一般来说，满足这4个指导原测，就能构建出成功的数据湖架构。