数据湖概念以及数据湖产生的背景和价值

一.数据湖的概念

数据湖是一个集中式存储库，允许以任意规模存储所有结构化和非结构化数据。是构建在低成本分布式存储之上，提供更好事务和性能支持的统一数据存储系统。

• 最底层为存储层：一般依赖HDFS或者公有云存储（比如S3）保存数据；数据格式为开放格式，比如Parquet或者ORC；
• 中间层为数据表抽象层：它的关键作用在于提供了表格式的抽象，比如能够支持ACID；
• 最上层为计算层：基于表抽象层，可以扩展出不同的计算引擎，满足不同的计算需求。

可以看出，由于采用了HDFS或公有云存储，所以数据湖在保存数据上，具有低成本大容量的优点，并且能够保存多种多样的数据，比如结构化、半结构化和非结构化数据；另外，由于表抽象层的存在，保证了ACID事务支持，同时提供了良好的扩展能力，可以面向不同的计算需求对接不同的计算引擎。

二.数据湖产生的背景

1.互联网早期

在互联网早期，各个公司的数据量不大，而且比较单一，因此整个数据架构比较简单，主要是基于关系型数据库搭建。

关系型数据库提供了数据的收集、存储和分析，数据质量比较高，但是能够支撑的数据量有限。

2.互联网爆发

随着互联网的爆发，数据量爆发式增长，原有的数据架构开始暴露出问题：单个关系型数据库无法支撑庞大的数据量。

于是公司会按照业务线等方式，把数据进行拆分，不同的数据库保存不同的数据，比如分别保存订单数据、用户数据等。虽然这种方式在一定程度上解决了问题，但它同时引入了另外一个问题：数据孤岛。如果业务想跨数据库进行数据分析，会非常困难，这严重影响了数据的可用价值。

在这个背景下，数据仓库（Data Warehouse）开始崛起。数据仓库可以集成多个数据库的数据，进行统一的处理分析，从而解决数据孤岛问题。而且相比关系型数据库，数据仓库的查询性能更高，响应更快。通过这种集中的数据分析（Single Source of Truth），也可以更方便地对数据进行审计、治理等。

但同时数据仓库也存在各种各样的问题，其中很关键一点是成本相对较高，特别是保存数据量很大的话，会给公司带来比较大的成本压力。而且采用商业版数据仓库的话，由于技术闭源，且依赖特定的企业级服务器，会让公司和商业数仓背后的公司产生强绑定的风险，这些都是大公司所忌惮的。

3.Hadoop的出现

这一切问题在Hadoop问世后都发生了重大转变，Hadoop脱胎于Google的“三驾马车”，借助Google的先进理念，再通过开源的方式提供给广大用户，可以说Hadoop由此成为了大数据分析的分水岭。企业从此有了一个很有吸引力的选型，从闭源昂贵的商业数仓，转向开源免费的Hadoop，而且Hadoop可以保存多种多样的数据，包括文本、图片、音视频等，这些都是数据仓库做不到的。

1.Hadoop的核心特点

• 低成本：部署在大量低成本服务器上
• 容错性：软硬件故障不会导致数据丢失，计算也可以重试
• 扩展性：可以存储海量数据
• 灵活性：可以保存丰富的数据类型

Hadoop的一大优势是低成本，很多时候更高的性能、更丰富的功能，远没有更低的成本对企业有吸引力。而且在低成本的优势之上，Hadoop提供了良好的容错性、扩展性，为不断涌现的数据提供了有力的存储和计算支撑。

2.Hadoop的局限性

Hadoop的火热也引来了不少非议，数据库领域的人站出来职责Hadoop在“开历史的倒车”。以数据库领域的多年经验，有几条准则是很重要的：

数据一定要有Schema；但是Hadoop体系一开始是没有Schema概念的，一份数据的格式是什么，一般隐藏在代码中，或者写这份数据的人的脑子里，给其他人使用数据造成了很大的障碍。当然这个问题在Hive出现后已经很大地改观了。
高级别的访问语言（主要指SQL）很重要；在他们看来，写MapReduce代码太反人类了，跟写汇编似的，很多人搞不定。
除此之外，Hadoop还有一些数据库领域很关键的特性缺失了：

不支持事务：写入数据的作业如果挂了，可能会写入脏数据，被下游读取到。
数据和Schema可能不匹配：如果写入了不符合Schema的数据，下游在处理的时候就会有各种异常。
不支持索引、不支持更新……

4.Hadoop + Data Warehouse

Hadoop以其大容量低成本的特性，保存最原始的数据，这部分数据比较全面，但是质量可能不是非常高。对于关键的数据，通过ETL处理后，导入到数据仓库中，提供更好的查询性能，提供更好的数据质量，支撑企业内部的BI和报表需求。

看起来很美好，但是可以看出又回到了早期存在的问题，数据孤岛问题。往往同一份数据在Hadoop和数据仓库中都有一份，除了造成数据冗余、成本浪费，还造成了数据产出口径不一致问题，应该以哪个系统的数据为准有时候说不清楚；另外，这种数据架构带来了运维上的困难，比如Schema的变更很容易导致ETL链路的各种问题，这些都严重影响了从数据到价值的转换效率。

三.数据湖引入的价值

用户需要有这样一种系统，它既具备Hadoop的低成本大容量的优势，又具备数据仓库ACID事务能力。

可以简单认为，数据湖就是这样一种融合了Hadoop和输出优势的技术。正如它的定义，它是构建在低成本分布式存储之上，提供更好的事务和性能支持的统一数据存储系统。

1.数据湖与数据仓库

2.基于Hive构建的传统数仓的局限性

• 数据运转效率低。数仓模型本身的研发与迭代成本比较高，生产速度赶不上需求速度，这就导致我们的创新想法落地、业务策略迭代等都会被按下暂停键。
• 端到端的数据变更困难。业务的快速迭代导致了基础数据 schema 频繁变更，而每次数据 schema 变更都需要变更数据仓库中的存量数据并且更新升级全链路，大大拖慢了业务的迭代效率
• 未提供较完善ACID语义支持。由于转储作业中断、INSERT OVERWRITE、Partition修改、Schema修改等相关变动，很难隔离对下游任务的影响；
• 近实时分析CDC数据困难。基于Hive构建的数仓对Update和Delete操作支持并不友好，往往需要额外的操作实现binlog数据的正确处理和分析；
• 机器学习流程更倾向于使用未加工的原始数据，通过特征提取和模型开发，用于模型在线推理；
• 难以提供近实时的报表。业务要求实现小时级或者分钟级的近实时报表。