很多人可能和我一样，对数据湖很好奇，看了很多数据湖的文章，但不管别人怎么说，我觉得很难把握数据湖的本质。
有些人说文生义认为，数据湖是什么都可以过去丢弃的，特别是对非结构数据的处理非常方便。
是吗？
有案例才有鉴别。 有人找了数据湖的作者AWS解释了数据湖是什么样的。 例如下图：
不了解数据的人可能觉得数据湖很厉害，但了解数据的人可能觉得它只是一种数据仓库技术的堆砌包装。 看了上面的框架图，不知道哪个专业术语的数据家呢？ 什么数据湖被炒作成了新概念？
因为有了比较才能鉴别，很多文章都把数据湖和数据仓库进行了比较。 以下是网上流传的说法。
这个比较好像能发现一点区别，感觉隔靴搔痒，但是结构化和非结构化是数据仓库和数据湖的主要区别吗？ BI和机器学习成了主要的区别吗？
其实，这个比较有很大的逻辑漏洞。 也就是说，从结果中看到差异，用差异来说明差异，逆转因果，被很多专家鄙视。 例如，AWS数据湖可以处理非结构化数据，但数据仓库不能处理非结构化数据。 我认为这是数据湖和数据仓库的本质区别之一。
这次试着比较了一下。 让我来谈谈我所理解的数据湖的本质。 如果你对新事物不了解本质，你就很难控制它，更不用说实践了，下图尽了一切。
以下，用一篇文章具体说明数据湖和数据仓库的区别。 大多数情况下，会发出why。 我知道那是我懂事的一个原则。
数据仓库和数据湖的处理过程如下图所示，用红色圆圈表示五个目标进程节点。
正如您所看到的，数据湖并不比数据仓库在处理过程中出现更多的内容，结构变化更多。 从数据存储、模型设计、加工工具、开发者和消费者五个方面进行比较。
1)数据存储
在数据仓库收集、处理过程中存储的数据一般以结构化的形式存在，即使原始数据是非结构化的，这些非结构化数据也只是暂时存储在源中，以结构化数据的形式进入数据仓库，成为数据仓库的基本存储形式这与数据仓库模型维度或关系建模)基于关系型数据的特征有关。
事实上，由于传统的数据建模负担，数据仓库只处理结构化数据，实际上没有人规定数据仓库只处理和存储结构化数据。
数据湖包罗万象、轻巧，结构化数据和非结构化数据都成为数据湖本身的一部分，这体现了数据湖中“湖”的概念。 由于没有数据仓库建模的限制，当然什么都可以过去扔，但这为数据沼泽埋下了伏笔。
看到这个一定不能接受。 别着急，往下看。
)2)模型设计
数据仓库中的所有模式，例如表结构，都是预先设计和生成的。 数据仓库建设最重要的工作是建模，通过封装稳定的模型对外提供有限的标准化数据服务。 模型能否设计的高凝聚、松耦合已成为评价数据仓库好坏的一个标准，就像数据中心非常强调数据服务的复用性一样。
数据仓库与数据领域的计划经济非常相似，所有产品模型)都是预先生成的，模型可以更改，但可以看到相当慢。
数据湖模型不是预先生成的，而是根据每个APP的需要即时设计生成的，更像是市场经济的产物，以牺牲可重用性为代价带来了灵活性。 因此，数据湖的APP更加强调搜索分析。
)3)加工工具
数据仓库的收集、处理工具一般是封闭的，以多种代码方式暴力实现，多只对集中的专业开发人员开放，主要目的是实现数据的统一收集和建模，为消费者APP端)提供服务或
数据湖的收集和处理工具完全开放。 2)如第2点所述，数据湖模型由应用即席设计生成，应用意味着必须具备对数据湖数据的直接ETL能力和加工能力，才能完成定制化模型的建设，否则就没有落地的可能性，更没有灵活性
工具能否开放、体验是否充分是数据湖能够成功的一个前提，显然传统数据仓库的一些收集和开发工具不行，它们是非常丑陋的，不能向普通大众开放。
4 )开发者
一组数据仓库
中开发人员处理数据涵盖了数据采集、存储、加工等各个阶段，其不仅要管理数据流，也要打造工具流。
由于数据流最终要为应用服务，因此其特别关注数据模型的质量，而工具流只要具备基本的功能、满足性能要求就可以了，反正是数据仓库团队人员自己用，导致的后果是害苦了运营人员。
数据湖完全不一样，集中开发人员在数据流阶段只负责把原始数据扔到数据湖，更多的精力花在对工具流的改造上，因为这些工具是直接面向最终使用者的，假如不好用，数据湖就死了。
（5）应用人员
数据仓库对于应用人员暴露的所有东西就是建好的数据模型，应用方的所有角色只能在数据仓库限定好的数据模型范围内倒腾，这在一定程度上限制了应用方的创新能力。比如原始数据有个字段很有价值，但数据仓库集中开发人员却把它过滤了。
这种问题在数据仓库中很常见，很多取数人员只会取宽表，对于源端数据完全不清楚，成了井底之蛙，这是数据仓库集中开发人员造的“孽”，所谓成也数据仓库，败也数据仓库。
数据湖的应用方则可以利用数据湖提供的工具流接触到最生鲜的原始数据，涵盖了从数据采集、抽取、存储、加工的各个阶段，其可以基于对业务的理解，压榨出原始数据的最大价值。
可以看到，数据仓库和数据湖，代表着两种数据处理模式和服务模式，是数据技术领域的一次轮回。
早在ORACLE的DBLINK时代，我们就有了第一代的数据湖，因为那个时候ORACLE一统天下，ORALCE的DBLINK让直接探索原始数据有了可能。
随着数据量的增长和数据类型的不断丰富，我们不得不搞出一种新的“数据库”来集成各种数据。
但那个时候搞出的为什么是数据仓库而不是数据湖呢？
主要还是应用驱动力的问题。
因为那个时候大家关注的是报表，而报表最核心的要求就是准确性和一致性，标准化、规范化的维度和关系建模正好适应了这一点，集中化的数据仓库支撑模式就是一种变相的计划经济。
随着大数据时代到来和数字化的发展，很多企业发现，原始数据的非结构化比例越来越高，前端应用响应的要求越来越高，海量数据挖掘的要求越来越对，报表取数已经满足不了数据驱动业务的要求了。
一方面企业需要深挖各种数据，从展示数据为主（报表）逐步向挖掘数据（探索预测）转变，另一方面企业也需要从按部就班的支撑模式向快速灵活的方向转变，要求数据仓库能够开放更多的灵活性给应用方，这个时候数据仓库就有点撑不住了。
（此处已添加小程序，请到今日头条客户端查看）
数据湖就是在这种背景下诞生的。
其实早在数据湖出来之前，很多企业就在做类似数据湖的工作了，比如我们5年前重构hadoop大数据平台的时候，就已经要求源端能将各种格式的数据直接扔过来，然后用不同的引擎处理，非结构化的就自己做一个定制化的ETL工具，只是没有统一进行整合而已。
ETL之所以不开放，主要是驱动力不够，其实我们没有那么多类型的数据要定制化抽取，也许后续会需要吧。
而可视化开发平台使用比较广泛，只是因为市场觉得IT做的太慢了，需要一个可视化平台来直接操作。
很多企业不搞可视化开发平台也是容易理解的，报表就能活得很好，干嘛业务人员要自己开发和挖掘。现在数据湖叫的欢的，大多是互联网公司，比如亚马逊，这是很正常的。
数据湖和数据仓库，不能说谁更好谁更差，大家都有可取之处，阿里最近一篇文章提到的数湖一体是很好的概念，可以实现双方的优势互补，我这里画一张图，方便你的理解：
何谓湖仓一体？
（1）湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖（成为原始数据一部分），湖的结构化应用知识沉淀到数据仓库
（2）湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作
（3）数据湖与数据仓库的数据，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化
至于理解的对不对，你怎么看？