数据湖是近两年中比较新的技术在大数据领域中，对于一个真正的数据湖应该是什么样子，现在对数据湖认知还是处在探索的阶段，像现在代表的开源产品有iceberg、hudi、Delta Lake。
那对于数据湖应该是什么样子，先来看数据湖的作者AWS来说明数据湖是什么东西，比如下图：
不懂数据的人也许会觉得数据湖很厉害，而懂数据的人也许会觉得仅是一堆数据仓库技术的堆砌包装而已，你看上面那张框架图，哪个专业词汇数据人士会不懂？凭什么数据湖被炒作成了一个新概念？
而对于数据湖的定义则是：
数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。
那么数据湖和我们早先的数据仓库究竟有什么样的区别呢：
数据仓库是一个优化的数据库，用于分析来自事务系统和业务线应用程序的关系数据。事先定义数据结构和 Schema 以优化快速 SQL 查询，其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换，因此可以充当用户可信任的“单一信息源”。
数据湖有所不同，因为它存储来自业务线应用程序的关系数据，以及来自移动应用程序、IoT 设备和社交媒体的非关系数据。捕获数据时，未定义数据结构或 Schema。这意味着您可以存储所有数据，而不需要精心设计也无需知道将来您可能需要哪些问题的答案。您可以对数据使用不同类型的分析（如 SQL 查询、大数据分析、全文搜索、实时分析和机器学习）来获得见解。
从介绍来看好像数据仓库和数据湖的最主要的区别就是对结构化的数据和非结构化数据的存储，但是真的仅仅是这样吗？
事实上，这种比较有较大逻辑漏洞：即是从结果出发来看差异，然后又用这个差异来说明区别，颠倒了因果。比如AWS的数据湖能够处理非结构化数据，而数据仓库无法处理非结构化数据，就认为这是数据湖与数据仓库的本质区别之一。
下面的文章中将来探索数据湖和数据仓库究竟有什么样的区别，学习一个新的事物要一步步的发现这个事物的本质是什么。
数据仓库和数据湖的处理流程可以用下图来示意，其中用红圈标出了5个对标的流程节点。
从图中可以看出来数据湖并不比数据仓库在处理流程上多出了什么内容，更多的在于结构性的变化，下面就从数据存储、模型设计、加工工具、开发人员和消费人员五个方面来进行比较。
数据仓库采集、处理过程中存储下来的数据一般是以结构化的形式存在的，即使原始数据是非结构化的，但这些非结构化数据也只是在源头暂存一下，它通过结构化数据的形式进入数据仓库，成了数据仓库的基本存储格式，这个跟数据仓库的模型（维度或关系建模）都是建立在关系型数据基础上的特点有关。
事实上，是传统的数据建模负担让数据仓库只处理结构化数据，其实谁都没规定过数据仓库只处理和存储结构化数据。
数据湖包罗万象，轻装上阵，结构化与非结构化数据都成为了数据湖本身的一部分，这体现了数据湖中“湖”这个概念。因为没有数据仓库建模的限制，当然什么东西都可以往里面扔，但这为其变成数据沼泽埋下了伏笔。
数据仓库中所有的Schema(比如表结构)都是预先设计并生成好的，数据仓库建设最重要的工作就是建模，其通过封装好的、稳定的模型对外提供有限的、标准化的数据服务，模型能否设计的高内聚、松耦合成了评估数据仓库好坏的一个标准，就好比数据中台非常强调数据服务的复用性一样。
你会发现，数据仓库很像数据领域的计划经济，所有的产品（模型）都是预先生成好的，模型可以变更，但相当缓慢。
数据湖的模型不是预先生成的，而是随着每个应用的需要即时设计生成的，其更像是市场经济的产物，牺牲了复用性却带来了灵活性，这也是为什么数据湖的应用更多强调探索分析的原因。
数据仓库的采集、处理工具一般是比较封闭的，很多采取代码的方式暴力实现，大多只向集中的专业开发人员开放，主要的目的是实现数据的统一采集和建模，它不为消费者（应用方）服务，也没这个必要。
数据湖的采集和处理工具是完全开放的，因为第（2）点提到过：数据湖的模型是由应用即席设计生成的，意味着应用必须具备针对数据湖数据的直接ETL能力和加工能力才能完成定制化模型的建设，否则就没有落地的可能，更无灵活性可言。
工具能否开放、体验是否足够好是数据湖能够成功的一个前提，显然传统数据仓库的一些采集和开发工具是不行的，它们往往不可能向普通大众开放。
数据仓库集中开发人员处理数据涵盖了数据采集、存储、加工等各个阶段，其不仅要管理数据流，也要打造工具流。
由于数据流最终要为应用服务，因此其特别关注数据模型的质量，而工具流只要具备基本的功能、满足性能要求就可以了，反正是数据仓库团队人员自己用，导致的后果是害苦了运营人员。
数据湖完全不一样，集中开发人员在数据流阶段只负责把原始数据扔到数据湖，更多的精力花在对工具流的改造上，因为这些工具是直接面向最终使用者的，假如不好用，数据湖就不能用了。
数据仓库对于应用人员暴露的所有东西就是建好的数据模型，应用方的所有角色只能在数据仓库限定好的数据模型范围内倒腾，这在一定程度上限制了应用方的创新能力。比如原始数据有个字段很有价值，但数据仓库集中开发人员却把它过滤了。
这种问题在数据仓库中很常见，很多取数人员只会取宽表，对于源端数据完全不清楚，所谓成也数据仓库，败也数据仓库。
数据湖的应用方则可以利用数据湖提供的工具流接触到最生鲜的原始数据，涵盖了从数据采集、抽取、存储、加工的各个阶段，其可以基于对业务的理解，压榨出原始数据的最大价值。
可以看到，数据仓库和数据湖，代表着两种数据处理模式和服务模式，是数据技术领域的一次轮回。
早在ORACLE的DBLINK时代，我们就有了第一代的数据湖，因为那个时候ORACLE一统天下，ORALCE的DBLINK让直接探索原始数据有了可能。
随着数据量的增长和数据类型的不断丰富，我们不得不搞出一种新的“数据库”来集成各种数据。
但那个时候搞出的为什么是数据仓库而不是数据湖呢？
主要还是应用驱动力的问题。
因为那个时候大家关注的是报表，而报表最核心的要求就是准确性和一致性，标准化、规范化的维度和关系建模正好适应了这一点，集中化的数据仓库支撑模式就是一种变相的计划经济。
随着大数据时代到来和数字化的发展，很多企业发现，原始数据的非结构化比例越来越高，前端应用响应的要求越来越高，海量数据挖掘的要求越来越对，报表取数已经满足不了数据驱动业务的要求了。
一方面企业需要深挖各种数据，从展示数据为主（报表）逐步向挖掘数据（探索预测）转变，另一方面企业也需要从按部就班的支撑模式向快速灵活的方向转变，要求数据仓库能够开放更多的灵活性给应用方，这个时候数据仓库就有点撑不住了。
数据湖就是在这种背景下诞生的。
其实早在数据湖出来之前，很多企业就在做类似数据湖的工作了，但是只不过大家更多的集中在数据仓库结构化的数据处理中，对于非结构化的数据日志等更多的则是将其存储起来，对于需要的时候再通过应用程序进行处理获取到自己想要的结果，只不过是没有系统化的处理而已。
ETL之所以不开放，主要是驱动力不够，其实我们没有那么多类型的数据要定制化抽取。
很多企业不搞可视化开发平台也是容易理解的，报表就能活得很好，干嘛业务人员要自己开发和挖掘。现在数据湖叫的欢的，大多是互联网公司，比如亚马逊，这是很正常的。
而最近比较新的概念湖仓一体，阿里提出的概念，下面这张图来看一下：
湖仓一体是一种新的数据管理模式，将数据仓库和数据湖两者之间的差异进行融合，并将数据仓库构建在数据湖上，从而有效简化了企业数据的基础架构，提升数据存储弹性和质量的同时还能降低成本，减小数据冗余。
湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖（成为原始数据一部分），湖的结构化应用知识沉淀到数据仓库。
湖仓一体架构主要的一点是实现“湖里”和“仓里”的数据能够无缝打通，对数据仓库的弹性和数据湖的灵活性进行有效集成，在该架构中，主要将数据湖作为中央存储库，将机器学习、数据仓库、日志分析、大数据等技术进行整合，形成一套数据服务环，更好地分析、整合数据，让数据仓库和数据湖中的数据可以自由流动，用户可以更便捷地调取其中的数据，让数据“入湖”、“出湖”更为便捷。
湖仓一体化，是将数据仓库和数据湖的价值进行叠加，克服数据重力，让数据在服务之间流动起来，减少重复建设，让湖中的数据可以”流到“数据仓中，并能直接进行数据调用；而数据仓中的数据也可以保存于数据湖中，供未来数据挖掘使用。借助湖仓一体化，可快速处理数仓内的热数据与数据湖中的历史数据，并生成丰富的数据集，但无需在执行中做任何数据移动操作。
那数据湖究竟应该是什么样子，需要在接下来的发展中获取到答案，但是以目前来看，典型的组织都需要数据仓库和数据湖，因为它们可满足不同的需求和使用诉求。所以数据湖和数据仓库的存在并不冲突，也并不是取代的关系，而是相互的融合关系。
