你真的需要数据湖吗？

数据湖已经成为许多大数据项目的基石，就因为它们在处理高速生成的大量数据（如web、传感器或应用程序活动数据）时，提供了更容易、更灵活的选择。由于这类数据源越来越普遍，大家对数据湖的兴趣也在快速增长。然而，数据湖真的适合你吗？本文将带你一起来看四个指标，帮助你理解是该加入数据湖的潮流，还是应该坚持传统的数据仓库。

数据湖已经成为许多大数据项目的基石，就因为它们在处理高速生成的大量数据（如web、传感器或应用程序活动数据）时，提供了更容易、更灵活的选择。由于这类数据源越来越普遍，大家对数据湖的兴趣也在快速增长。

然而，与任何新兴技术一样，不存在放之四海而皆准的解决方案：数据湖可能非常适合某些场景，但在其他情况下，坚持使用经实践检验过的数据库架构将是更好的解决方案。在本文中，我们将研究四个指标，它们应该有助于你理解是应该加入数据湖的潮流，还是应该坚持传统的数据仓库。但首先，让我们通过定义术语“数据湖”来设定讨论的范畴。

数据湖：基本定义

数据湖是一种通常被定义为大数据架构的方法，它侧重于将非结构化或半结构化数据以其原始格式存储在一个服务于多个分析用例或服务的存储库中。在此，存储和计算资源是解耦的，因此数据驻留在廉价的对象存储中，如Hadoop on-premise或Amazon S3，而各种工具和服务（如Apache Presto、Elasticsearch和Amazon Athena）可以用来查询这些数据。

这与传统的数据库或数据仓库架构不同，在传统的架构中，计算和存储是耦合的，为了实施一系列模式，数据是根据摄入进行结构化的。数据湖使采用“现在存储，以后分析”的方法变得更容易，因为几乎不需要付出什么努力即可将数据输入到这个湖中；然而，在分析数据时，可能会出现一些传统的数据准备挑战。

现在定义有了，接下来的问题是，你的组织需要数据湖吗？让我们从这5个关键指标开始。

1. 数据的结构是怎样的？

数据湖非常适合存储大量的非结构化和半结构化数据。将这类数据存储在数据库中需要做大量的数据准备，因为数据库是围绕结构化表构建的，而不是JSON / XML格式的原始事件。

如果你的大部分数据是由结构化的表格组成的——例如，预先处理过的CRM记录或财务资产负债表——那么坚持使用数据库会更容易。但是，如果你正在处理大量基于事件的数据，比如服务器日志或点击流，那么以原始形式存储这些数据并根据你的用例构建特定的ETL流可能会更容易一些。

2. 你的ETL过程有多复杂?

ETL （extract-transform-load，抽取-转换-加载）通常是实际使用数据的前提条件；但是，在处理大数据或流数据时，由于使用Spark/Hadoop等代码密集型框架编写ETL作业的复杂性，它会成为一个主要的障碍。

为了最小化花费在ETL上的资源数量，请尝试确定主要瓶颈发生在哪里。如果你在尝试将半结构化和非结构化数据“调整适应”到关系数据库方面遇到了很大的困难，那么现在是时候考虑转换到数据湖了。然而，创建从湖中向你将用于分析、机器学习的各种目标服务的ETL流仍然可能遇到很多挑战。在这种情况下，你可能想要使用一个数据湖ETL工具来自动化这些过程。

3.数据保持是问题吗?

由于数据库将存储与计算结合在一起，在数据库中存储非常大的数据量就变得非常昂贵。这就导致了很多数据保留方面的问题——为了控制成本，要么删除数据中的某些字段，要么限制保存历史数据的时间。

如果你的组织在不断努力寻找为了分析而保持数据和为了控制成本而删除数据之间的平衡点，数据湖解决方案可能是为了——数据湖架构建立在廉价的对象存储之上，允许你持有“嗅”到的tb甚至海量历史数据而不必花费多少成本。

4. 你的用例是可预测的还是实验性的?

你应该问的最后一个问题是，你打算如何处理这些数据。如果你只是试图建立一个报告（或一组报告，或仪表板），基本上是针对定期更新的表运行一组预先确定的查询，那么数据仓库可能会是一个很好的解决方案，你可以使用SQL和可用的数据仓库和业务智能工具简单地实现此类解决方案。

然而，对于更多的实验性用例（比如机器学习和预测分析），提前知道你需要什么数据以及你想要如何查询它是比较困难的。在这些情况下，数据仓库的效率可能非常低，因为预定义的模式将限制你研究数据的能力。在这些情况下，数据湖可能是更好的选择。

结论：数据湖适合你吗?

以“视情况而定”结尾的文章总是让人感觉像是在逃避，但事实是，大多数技术问题并没有一个唯一解。当你的数据达到一定的规模和复杂性时，数据湖无疑是最佳选择。你的组织在处于这些的情况吗？你可以用以上四个问题来回答这个问题。

作者介绍：

Eran Levy是Upsolver的市场总监。Upsolver是云原生平台，你可以使用一个简单的、可视化的UI和SQL来配置它。世界上大多数创新型的公司都使用Upsolver来自动化所有数据湖操作：摄取、存储管理、模式管理和ETL流（包括聚合和连接）。

原文链接：

Do You Actually Need a Data Lake?