数据湖是近两年中比较新的技术在大数据领域中，对于一个真正的数据湖应该是什么样子，现在对数据湖认知还是处在探索的阶段，像现在代表的开源产品有iceberg、hudi、Delta Lake。

那对于数据湖应该是什么样子，先来看数据湖的作者AWS来说明数据湖是什么东西，比如下图：

数据存储、模型设计、加工工具、开发人员和消费人员

从图中可以看出来数据湖并不比数据仓库在处理流程上多出了什么内容，更多的在于结构性的变化，下面就从五个方面来进行比较。

(1)数据存储

数据仓库采集、处理过程中存储下来的数据一般是以结构化的形式存在的，即使原始数据是非结构化的，但这些非结构化数据也只是在源头暂存一下，它通过结构化数据的形式进入数据仓库，成了数据仓库的基本存储格式，这个跟数据仓库的模型(维度或关系建模)都是建立在关系型数据基础上的特点有关。

事实上，是传统的数据建模负担让数据仓库只处理结构化数据，其实谁都没规定过数据仓库只处理和存储结构化数据。

数据湖包罗万象，轻装上阵，结构化与非结构化数据都成为了数据湖本身的一部分，这体现了数据湖中“湖”这个概念。因为没有数据仓库建模的限制，当然什么东西都可以往里面扔，但这为其变成数据沼泽埋下了伏笔。

(2)模型设计

数据仓库中所有的Schema(比如表结构)都是预先设计并生成好的，数据仓库建设最重要的工作就是建模，其通过封装好的、稳定的模型对外提供有限的、标准化的数据服务，模型能否设计的高内聚、松耦合成了评估数据仓库好坏的一个标准，就好比数据中台非常强调数据服务的复用性一样。

你会发现，数据仓库很像数据领域的计划经济，所有的产品(模型)都是预先生成好的，模型可以变更，但相当缓慢。

数据湖的模型不是预先生成的，而是随着每个应用的需要即时设计生成的，其更像是市场经济的产物，牺牲了复用性却带来了灵活性，这也是为什么数据湖的应用更多强调探索分析的原因。

(3)加工工具

数据仓库的采集、处理工具一般是比较封闭的，很多采取代码的方式暴力实现，大多只向集中的专业开发人员开放，主要的目的是实现数据的统一采集和建模，它不为消费者(应用方)服务，也没这个必要。

数据湖的采集和处理工具是完全开放的，因为第(2)点提到过：数据湖的模型是由应用即席设计生成的，意味着应用必须具备针对数据湖数据的直接ETL能力和加工能力才能完成定制化模型的建设，否则就没有落地的可能，更无灵活性可言。

工具能否开放、体验是否足够好是数据湖能够成功的一个前提，显然传统数据仓库的一些采集和开发工具是不行的，它们往往不可能向普通大众开放。

(4)开发人员

数据仓库集中开发人员处理数据涵盖了数据采集、存储、加工等各个阶段，其不仅要管理数据流，也要打造工具流。

由于数据流最终要为应用服务，因此其特别关注数据模型的质量，而工具流只要具备基本的功能、满足性能要求就可以了，反正是数据仓库团队人员自己用，导致的后果是害苦了运营人员。

数据湖完全不一样，集中开发人员在数据流阶段只负责把原始数据扔到数据湖，更多的精力花在对工具流的改造上，因为这些工具是直接面向最终使用者的，假如不好用，数据湖就不能用了。

(5)应用人员

数据仓库对于应用人员暴露的所有东西就是建好的数据模型，应用方的所有角色只能在数据仓库限定好的数据模型范围内倒腾，这在一定程度上限制了应用方的创新能力。比如原始数据有个字段很有价值，但数据仓库集中开发人员却把它过滤了。

这种问题在数据仓库中很常见，很多取数人员只会取宽表，对于源端数据完全不清楚，所谓成也数据仓库，败也数据仓库。

数据湖的应用方则可以利用数据湖提供的工具流接触到最生鲜的原始数据，涵盖了从数据采集、抽取、存储、加工的各个阶段，其可以基于对业务的理解，压榨出原始数据的最大价值。

可以看到，数据仓库和数据湖，代表着两种数据处理模式和服务模式，是数据技术领域的一次轮回。

早在ORACLE的DBLINK时代，我们就有了第一代的数据湖，因为那个时候ORACLE一统天下，ORALCE的DBLINK让直接探索原始数据有了可能。

随着数据量的增长和数据类型的不断丰富，我们不得不搞出一种新的“数据库”来集成各种数据。

但那个时候搞出的为什么是数据仓库而不是数据湖呢?

主要还是应用驱动力的问题。

因为那个时候大家关注的是报表，而报表最核心的要求就是准确性和一致性，标准化、规范化的维度和关系建模正好适应了这一点，集中化的数据仓库支撑模式就是一种变相的计划经济。

随着大数据时代到来和数字化的发展，很多企业发现，原始数据的非结构化比例越来越高，前端应用响应的要求越来越高，海量数据挖掘的要求越来越对，报表取数已经满足不了数据驱动业务的要求了。

<img align="" alt="" border="0" data-cke-saved-src="https://www.enicn.com/uploadfile/2023/0510/20230510102954500.png" src="https://www.enicn.com/uploadfile/2023/0510/20230510102954500.png" 560"="">

何谓湖仓一体?

湖仓一体是一种新的数据管理模式，将数据仓库和数据湖两者之间的差异进行融合，并将数据仓库构建在数据湖上，从而有效简化了企业数据的基础架构，提升数据存储弹性和质量的同时还能降低成本，减小数据冗余。

湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖(成为原始数据一部分)，湖的结构化应用知识沉淀到数据仓库。

湖仓一体架构主要的一点是实现“湖里”和“仓里”的数据能够无缝打通，对数据仓库的弹性和数据湖的灵活性进行有效集成，在该架构中，主要将数据湖作为中央存储库，将机器学习、数据仓库、日志分析、大数据等技术进行整合，形成一套数据服务环，更好地分析、整合数据，让数据仓库和数据湖中的数据可以自由流动，用户可以更便捷地调取其中的数据，让数据“入湖”、“出湖”更为便捷。

湖仓一体化，是将数据仓库和数据湖的价值进行叠加，克服数据重力，让数据在服务之间流动起来，减少重复建设，让湖中的数据可以”流到“数据仓中，并能直接进行数据调用;而数据仓中的数据也可以保存于数据湖中，供未来数据挖掘使用。借助湖仓一体化，可快速处理数仓内的热数据与数据湖中的历史数据，并生成丰富的数据集，但无需在执行中做任何数据移动操作。

那数据湖究竟应该是什么样子，需要在接下来的发展中获取到答案，但是以目前来看，典型的组织都需要数据仓库和数据湖，因为它们可满足不同的需求和使用诉求。所以数据湖和数据仓库的存在并不冲突，也并不是取代的关系，而是相互的融合关系。

图片来源：数据学堂