组织应采用数据湖的7个原因随着当今数据的数量、速度和种类不断变化，很明显没有一个数据库可以满足组织的所有数据需求。相反，许多组织已转向为特定用例或项目选择正确的数据存储技术。数据分散存储在不同的数据存储空间中，对组织整合数据进行分析提出了挑战。从历史上看，唯一可行的解??决方案是构建一个数据仓库，它从所有不同的来源获取数据，在清洗和合并之后，最后将这些数据以定义良好的结构加载到仓库中的精炼数据中。虽然这种方法没有任何问题，但数据湖和数据仓库的结合才是组织真正需要的解决方案。以下是组织应采用数据湖的7个原因：为什么应创建数据湖1.为数据仓库构建暂存区数据湖不必成为数据的最终存储目的地。由于数据不断流动并不断改变其形式，现代数据平台应促进数据的摄取和发现，同时为分析需求提供完整而严格的结构。一个常见的模式是数据湖充当数据摄取的不可变层。不会从中删除任何内容（可能只是被新版本覆盖，或出于合规原因删除）。所有引入数据平台的原始数据都可以在数据湖中找到。这意味着组织在严格遵循Kimbol、Inmon或DataVault方法论的同时，仍然可以使用ELT/ETL作业来转换和清理数据，然后再将其摄取到数据仓库中。组织不必在数据湖或数据仓库之间做出选择，而是可以同时使用数据湖和不可变的暂存区，以及用于商业智能分析报告的数据仓库。人工智能供应商Databricks创造了术语“DataLakehouse”，它将数据湖和数据仓库的优点结合在一个解决方案中。同样，组织采用像Snowflake这样的平台来使用像S3这样的云存储桶作为外部存储，有效地利用数据湖作为暂存区。最终，组织需要决定是为其用例选择一体式湖仓库还是数据湖和数据仓库的组合。研究发现，越来越多的数据团队正在超越数据仓库或数据湖，转而采用数据湖和数据仓库，这是有充分理由的。随着更多用例的出现和更多利益相关者的参与，单个解决方案很难满足所有需求。2.由于暂存区是不可变的，因此可以审计被引入组织数据生态系统的所有数据的日志。审计跟踪对于满足合规性要求通常很重要。数据湖使收集有关用户何时何地摄取数据的元数据变得更加容易。这不仅有助于合规性，还有助于跟踪数据所有权。3.缩短洞察价值和数据价值的时间通过提供不可变的所有数据层，组织可以在获取数据后立即向消费者提供数据。通过提供原始数据，组织将能够进行探索性分析，当不同的数据团队以不同的方式使用相同的数据集时，这可能很难完成。通常，不同的数据消费者可能需要基于相同原始数据的不同转换。数据湖允许组织深入研究各种类型和形式的数据，并决定哪些数据可以为组织产生洞察力。4.用于实时和批量分析的单一数据平台将实时数据导入数据仓库仍然是一个具有挑战性的问题。尽管市场上有试图解决此问题的工具，但如果将数据湖用作从中提取所有数据的不可变层，则可以轻松解决此问题。例如，许多解决方案（例如KinesisDataStreams或ApacheKafka）允许组织使用S3存储桶作为数据接收器。5.成本随着社交媒体、传感器、日志和网络分析数据量的持续增长，将所有数据存储在数据仓库中可能会变得更加昂贵。许多传统数据仓库将存储和处理紧密耦合，使得数据仓库扩展更加困难。数据湖相互独立地扩展存储和处理（查询和检索数据的API请求），一些云计算数据仓库也支持这种范式。6.便利通常，采用数据仓库解决方案需要组织管理底层计算集群。云计算提供商开始意识到这样做的困难，并建立了完全托管或完全无服务器的数据存储。例如，在将S3存储桶与AWSGlue和Athena结合使用时，组织的平台仍然不需要服务器，并且只需为使用的资源付费。组织可以利用这个单一数据平台来：检索关系和非关系数据查询历史和实时数据检查组织机器学习培训工作并提供机器学习模型在应用转换之前直接摄取数据后查询数据通过外部表从数据湖合并和DWH表数据（几乎所有DWH解决方案都可用）与其他服务和分布式计算框架（如Dask或Spark）集成在数据集成方面，在AWS云平台上，组织可以利用：数据湖形成的通道管理awswrangler（AWS上可用的Python库称为Pandas）Quicksight（AWSBI工具）Deltalake（由Databricks创建的开源平台）lakeFS（数据版本控制）Upsolver（使用Kappa架构，例如数据流和批量数据摄取）AWS数据库迁移服务使组织能够从RDS数据库表（甚至整个模式）增量导出数据到可以使用AWSGlue使用Athena查询的S3存储桶文件中。7.面向未来根据调查和统计，通常存储在数据仓库中的数据中至少有三分之一几乎从未被使用过。组织需要摄取、清理和维护此类数据源，以备日后需要时使用。这意味着数据工程师将花费大量时间和精力来构建和维护可能还没有明确业务需求的数据。ELT范式使组织能够通过仅为实际需要的用例构建数据管道来节省时间，同时将所有数据存储在数据湖中以供将来可能的用例使用。如果将来出现特定的业务问题，可能会找到答案，因为数据已经存在。但组织不必花时间清理和维护数据管道来解决尚无明确业务用例的问题。数据湖和云计算数据平台面向未来的另一个原因是，如果一个组织的业务快速增长，其平台将具有快速扩展的能力。组织无需借助成本高昂的迁移方案来随着数据库的增长或缩小而切换到更大或更小的数据库。无论组织选择哪种方法，其云数据平台都应允许其无限制地增长其数据资产。用例演示：无服务器事件驱动的ETL与AWS上的数据湖为了构建事件驱动的ETL演示，使用了一个数据集，并遵循了Databricks的“金、银、铜”原则。简而言之，这意味着组织对原始数据使用“青铜”层，对预处理和清洁数据使用“银”层，最后对已清理数据的最后阶段使用“金”层。为实现这一目标而创建：用于原始数据的S3存储桶：s3//data-lake-bronze用于清洁和转换数据的S3存储桶：s3//data-lake-silver一旦新文件到达“青铜”在S3存储桶中，触发AWSLambda函数。它将转换新对象并将数据加载到“银”阶段。wr.s3.to_parquet()指令不仅将数据加载到新的数据湖位置，而且：使用snappy和parquet格式压缩数据根据Pandas数据框的数据类型和列名对模式进行分类存储AWSGlue中的架构在目录中创建一个新的Athena表，以便您可以在管理控制台中查看S3、AWSGlue和Athena如何协同工作。Lambda的无服务器ETL如何扩展？想象一下组织对更多数据集执行类似的操作。管理所有这些lambda函数可能具有挑战性。即使AWSLambda的计算能力可以无限扩展，但仍然很难管理数据转换的状态，尤其是在实时和事件驱动的场景中。如果您使用像Dashbird这样的可观察性平台，您可以轻松检查哪些事件驱动的ETL工作负载正在成功，哪些没有。当组织测试功能时，他们可能会犯一些错误。而Dashbird平台的可观察性非常有助于查看事件驱动ETL的状态，包括任何错误消息。它可以更深入地挖掘日志并检查任何失败的执行。想象一下，如果您必须为数百个ETL作业执行此操作，那将是多么困难。配置故障警报就像将电子邮件地址或Slack通道添加到警报策略一样简单。组织还可以根据其他选定条件通知用户，例如冷启动、持续时间超过特定阈值（可能是僵尸任务）或特定时间段内异常大量的函数调用。结论数据湖和具有数据湖功能的数据仓库构成了面向未来的数据平台的重要组成部分。预先为所有数据构建关系模式可能效率低下，并且可能与当今的数据需求不兼容。拥有一个不可变的数据摄取层来存储所有曾经摄取的数据，有助于审计、数据发现、复制和修复数据管道中的错误。原标题：7ReasonsWhyYouShouldConsideraDataLake，作者：AnnaAnisienia
