让我帮你决定。长期以来，数据湖在业界引起了轰动，通常被视为解决所有数据问题的一站式解决方案。围绕数据湖的热议已误导组织设计那些对业务没有实际价值的数据湖。此外，多年来关于数据沼泽的恐怖故事只会助长怀疑。如果您正在争论是否需要数据湖来加强您的数据策略，本文将为您提供一些东西来开始您的呼吁。您是否厌倦了从没有逻辑集中存储区域的异构系统中提取数据？对于处理各种数据源的大多数组织来说，这是一个常见问题。缺乏用于分析工作负载的集中式数据存储迫使数据消费者创建本地化系统，通常仅限于少数用户进行报告和分析。一些非标准化流程最终会导致数据孤岛的产生，这可能成为数据访问、一致性和准确性方面的主要问题。数据湖架构可以通过分布式存储集中数据，从而提供可扩展、快速、安全和经济的解决方案。再加上强大的数据治理，它最终可以解决数据孤岛问题并使组织内的数据民主化。这些解决方案可以部署在本地、云端甚至混合基础架构中。您是否因为存储旧数据的成本高昂而简单地删除旧数据而感到内疚？随着数据的增长，DBMS需要更多的计算能力，这导致许多设计决策，例如分区和扩展，进一步增加了费用。当成本继续上升时，IT可以将数据压缩到备份数据库中以更便宜的存储或平面文件，或者在大多数情况下最终删除它们。存档数据或删除数据以降低费用可能会损害数据货币化的机会。可以设计数据湖架构来执行数据保留策略，从而减轻控制数据增长的压力。借助廉价的分层存储，您可以轻松规划周密的保留策略并存储大量数据，而不会超出预算并显着降低编排开销。您是否经常根据不断变化的数据结构调整您的数据库？如果您使用的是关系数据库并且源数据的架构不断变化，那么您要么忽略正在进行的更改并可能丢失有价值的信息，要么花费资源调整数据库以适用于源架构。无论哪种方式，你都赢不了。数据湖允许在不运行任何前期ETL流程的情况下存储原始数据（结构化/非结构化/半结构化）。您不会丢失正在进行的数据更改，并且可以节省调整数据库表结构、ETL管道等的费用。您（或消费者）可以在读取数据时定义数据的结构，而不是在存储数据时（检查读取模式），以允许授权消费者以他们喜欢的任何方式读取数据。双赢。您是否有不同的数据消费者集需要不同形式的同一数据集？并非您组织中的每个人都希望使用一种特定形状或切割方式的数据。一些消费者将需要符合其部门需求的关系形式的干净、结构化和必要的数据，一些消费者将需要原始数据来运行机器学习实验，而一些消费者将属于受限类别并使用屏蔽数据。在传统平台上满足这些要求变得麻烦（且昂贵）。一旦原始数据存储在数据湖中，就可以在数据中创建逻辑视图，以便用户可以以所需的形式使用数据。您甚至可以创建流程以将数据以结构化形式存储到数据仓库中，并应用匿名化规则将数据推送给外部消费者。你了解数据湖的概念吗？关于数据湖有很多误解，在做出决定之前了解一些事实很重要。数据湖是一个概念，而不是一个产品。DataLake不是AmazonS3或AzureDataLakeStorage或Hadoop，而是一种指导数据如何在对象存储（例如AmazonS3、ADLS、HDFS）或多个存储组件中存储和组织的架构。数据湖不能替代数据仓库。这是数据湖最大的困惑。以至于当你谷歌“数据湖”一词时，你会发现大多数人将数据湖比作数据仓库。数据湖允许数据以其原始格式驻留，而数据仓库是您存储处理过的、清理过的、结构化的和有趣的数据的地方。数据湖和数据仓库是相辅相成的思想，不能相互替代。数据湖需要治理。您可以将原始格式的数据不经任何处理提取到数据湖中，但是一旦数据存储到数据湖中，就需要对其进行适当的分类、管理和控制，以确保只有经过授权的消费者才能跟踪、识别和访问数据。数据湖不是一种放之四海而皆准的架构。数据湖设计因每个组织和用例而异。一个组织可以决定构建多个数据湖，或者一个数据湖可以为多个组织服务。在任何一种情况下，具体的设计决策都是根据业务战略、基础设施、技术选择和人员技能做出的。总之……数据湖确实具有巨大的优势，对于许多热衷于制定数据战略的组织来说可能是一个有吸引力的提议。你必须仔细检查它是否解决了你的业务问题，是否与你组织中的其他技术平台很好地集成，并真正为业务创造价值。做出良好的设计决策并确保在整个组织中建立数据治理纪律以使用数据湖至关重要。最重要的是，只有那些人才能成功实现这一目标，您将必须支持和发展正确的技能并鼓励数据驱动的文化。
