数据湖与数据仓库的差别很明显。 然而，在企业中两者的作用是互补的，不应认为数据湖的出现是为了取代数据仓库，毕竟两者的作用是截然不同的
数据价值性：数仓中保存的都是结构化处理后的数据，而数据湖中可以保存原始数据也可以保存结构化处理后的数据，保证用户能获取到各个阶段的数据。因为数据的价值跟不同的业务和用户强相关，有可能对于A用户没有意义的数据，但是对于B用户来说意义巨大，所以都需要保存在数据湖中。
数据实时性：数据湖支持对实时和高速数据流执行 ETL 功能，这有助于将来自 IoT 设备的传感器数据与其他数据源一起融合到数据湖中。形象的来看，数据湖架构保证了多个数据源的集成，并且不限制schema，保证了数据的精确度。数据湖可以满足实时分析的需要，同时也可以作为数据仓库满足批处理数据挖掘的需要。数据湖还为数据科学家从数据中发现更多的灵感提供了可能。
数据保真性：数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。
数据灵活性：数据湖提供灵活的，面向任务的数据绑定，不需要提前定义数据模型，"写入型schema" 和"读取型schema"，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。对于任何数据应用来说，其实schema的设计都是必不可少的，即使是MongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽量采用相同/相似的结构。
数据仓库强调的"写入型schema"背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。
数据湖强调的"读取型schema"背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。因此，个人认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。
总结离线架构大行其道数十年，互联网数十年技术积淀和业务发展对数据又提出新要求，实时计算技术的发展满足了人们对数据实时性的要求，但未能满足互联网人对低成本高性能的执着追逐，技术的浪潮一波接一波，如果你错过了朝阳和高山，请不要错过了星辰和大海
当然，对于数据湖架构的批评也是不绝于耳。有人批评说，汇集各种杂乱的数据，应该就是数据沼泽。Martin Fowler也对数据湖中数据的安全性和私密性提出了质疑，历史见证了每一次新技术的诞生总是遇到万般挫折与质疑，但是它何曾让你失望过。