在使用数据库和数据湖时存在几个关键的概念差异。在这篇文章中，让我们找出其中的一些差异，这些差异乍一看可能并不直观，尤其是对于具有深厚关系数据库背景的人来说。服务器是一次性的。数据在云端。解耦存储和计算。这是谈论数据湖时的典型问题。在传统数据库系统（以及最初基于Hadoop的数据湖）中，存储与计算服务器紧密耦合。服务器要么具有内置存储，要么直接连接到存储。在现代基于云的数据湖架构中，数据存储和计算是独立的。数据保存在云对象存储（例如：AWSS3、AzureStorage）中，通常采用像parquet这样的开放格式，而计算服务器是无状态的，它们可以在必要时启动/关闭。具有分离的存储和计算功能。降低计算成本。服务器在必要时运行。不使用时，可以将它们关闭，从而降低计算成本。可扩展性。您不必为高峰使用购买硬件。服务器/cpu/内存的数量可以根据当前使用情况动态增加/减少。沙盒。多个计算服务器/集群可以同时读取相同的数据。这允许您让多个团队在不同的集群上并行工作，读取相同的数据而不会相互影响。RAW数据为王！精选数据只是派生的。在数据库范式中，来自源系统的数据经过转换并加载到数据库表中后，就不再有用了。在数据湖范式中，RAW数据被保存为真实的来源，并最终永久保存，因为它是一种真正的资产。但是，RAW数据通常不适合企业用户使用，因此需要经过一个管理过程来提高其质量、提供结构和促进使用。整理后的数据最终会存储起来供数据科学团队、数据仓库、报告系统和业务用户使用。Datalakecuration（来源：作者图片）典型的数据湖消费者只能看到经过整理的数据，因此对经过整理的数据的重视程度远远超过产生它的RAW数据。然而，数据湖的真正资产是RAW数据（以及管理管道），因为管理数据就像可以随时刷新的物化视图。要点：可以随时从RAW重新创建。可以通过改进策展过程来重新创建来改进。我们可以有多个策展视图，每个视图专用于特定分析。今天做出的模式决策不会限制未来的需求信息经常需要更改，并且需要分析以前未从源/操作系统收集的一些信息。在典型情况下，如果未存储原始RAW数据，则历史数据将永远丢失。然而，在数据湖架构中，今天不将字段加载到策划模式中的决定可以在以后被覆盖，因为所有细节都安全地存储在数据湖的RAW区域中，并且可以检索历史策划数据重新创建其他字段。策划模式演变（图片由作者提供）关键要点：如果您现在不需要，请不要花很多时间创建通用的通用策划模式。迭代地创建一个策划模式，从添加你现在需要的字段开始......当需要额外的字段时，将它们添加到策划过程并重新处理它们。最后的想法数据湖不能替代数据库，每个工具都有其优势和致命弱点。将数据湖用于OLTP可能不是一个好主意，就像使用数据库存储千兆字节的非结构化数据一样。我希望本文有助于澄清两个系统之间的一些关键设计差异。
