数据湖已经成为许多大数据项目的基石,就因为它们在处理高速生成的大量数据(如 web、传感器或应用程序活动数据)时,提供了更容易、更灵活的选择。由于这类数据源越来越普遍,大家对数据湖的兴趣也在快速增长。然而,数据湖真的适合你吗?本文将带你一起来看四个指标,帮助你理解是该加入数据湖的潮流,还是应该坚持传统的数据仓库。
数据湖已经成为许多大数据项目的基石,就因为它们在处理高速生成的大量数据(如 web、传感器或应用程序活动数据)时,提供了更容易、更灵活的选择。由于这类数据源越来越普遍,大家对数据湖的兴趣也在快速增长。在本文中,我们将研究四个指标,它们应该有助于你理解是应该加入数据湖的潮流,还是应该坚持传统的数据仓库。但首先,让我们通过定义术语“数据湖”来设定讨论的范畴。
数据湖:基本定义
数据湖是一种通常被定义为大数据架构的方法,它侧重于将非结构化或半结构化数据以其原始格式存储在一个服务于多个分析用例或服务的存储库中。在此,存储和计算资源是解耦的,因此数据驻留在廉价的对象存储中,如Hadoop on-premise 或Amazon S3,而各种工具和服务(如 Apache Presto 、 Elasticsearch 和 Amazon Athena)可以用来查询这些数据。
这与传统的数据库或数据仓库架构不同,在传统的架构中,计算和存储是耦合的,为了实施一系列模式,数据是根据摄入进行结构化的。数据湖使采用“现在存储,以后分析”的方法变得更容易,因为几乎不需要付出什么努力即可将数据输入到这个湖中;然而,在分析数据时,可能会出现一些传统的数据准备挑战。
现在定义有了,接下来的问题是,你的组织需要数据湖吗?让我们从这 5 个关键指标开始。
01
数据的结构是怎样的?
数据湖非常适合存储大量的非结构化和半结构化数据。将这类数据存储在数据库中需要做大量的数据准备,因为数据库是围绕结构化表构建的,而不是 JSON / XML 格式的原始事件。
如果你的大部分数据是由结构化的表格组成的——例如,预先处理过的 CRM 记录或财务资产负债表——那么坚持使用数据库会更容易。但是,如果你正在处理大量基于事件的数据,比如服务器日志或点击流,那么以原始形式存储这些数据并根据你的用例构建特定的 ETL 流可能会更容易一些。
02
你的 ETL 过程有多复杂?
ETL (extract-transform-load,抽取 - 转换 - 加载)通常是实际使用数据的前提条件;但是,在处理大数据或流数据时,由于使用 Spark/Hadoop 等代码密集型框架编写 ETL 作业的复杂性,它会成为一个主要的障碍。
为了最小化花费在 ETL 上的资源数量,请尝试确定主要瓶颈发生在哪里。如果你在尝试将半结构化和非结构化数据“调整适应”到关系数据库方面遇到了很大的困难,那么现在是时候考虑转换到数据湖了。然而,创建从湖中向你将用于分析、机器学习的各种目标服务的 ETL 流仍然可能遇到很多挑战。在这种情况下,你可能想要使用一个数据湖 ETL 工具来自动化这些过程。
03
数据保持是问题吗?
由于数据库将存储与计算结合在一起,在数据库中存储非常大的数据量就变得非常昂贵。这就导致了很多数据保留方面的问题——为了控制成本,要么删除数据中的某些字段,要么限制保存历史数据的时间。
如果你的组织在不断努力寻找为了分析而保持数据和为了控制成本而删除数据之间的平衡点,数据湖解决方案可能是为了——数据湖架构建立在廉价的对象存储之上,允许你持有“嗅”到的 tb 甚至海量历史数据而不必花费多少成本。
04
你的用例是可预测的还是实验性的?
你应该问的最后一个问题是,你打算如何处理这些数据。如果你只是试图建立一个报告(或一组报告,或仪表板),基本上是针对定期更新的表运行一组预先确定的查询,那么数据仓库可能会是一个很好的解决方案,你可以使用 SQL 和可用的数据仓库和业务智能工具简单地实现此类解决方案。
然而,对于更多的实验性用例(比如机器学习和预测分析),提前知道你需要什么数据以及你想要如何查询它是比较困难的。在这些情况下,数据仓库的效率可能非常低,因为预定义的模式将限制你研究数据的能力。在这些情况下,数据湖可能是更好的选择。
结论:
数据湖适合你吗?
以“视情况而定”结尾的文章总是让人感觉像是在逃避,但事实是,大多数技术问题并没有一个唯一解。当你的数据达到一定的规模和复杂性时,数据湖无疑是最佳选择。你的组织在处于这些的情况吗?你可以用以上四个问题来回答这个问题。
文:Eran Levy
译:冬雨
领取专属 10元无门槛券
私享最新 技术干货