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