关于 Data Lake 的概念、架构与应用场景介绍

简介: 本文详细介绍了 Data Lake 的概念、架构与应用场景介绍。

数据湖(Data Lake)概念介绍
什么是数据湖(Data Lake)?
数据湖的起源,应该追溯到2010年10月,由 Pentaho 的创始人兼 CTO, James Dixon 所提出,他提出的目的就当时历史背景来看,其实是为了推广自家产品 Pentaho。当时核心要解决的问题是传统数据仓库报表分析面临的两个问题:
• 只使用一部分属性,这些数据只能回答预先定义好(pre-determined)的问题。
• 数据被聚合了,最低层级的细节丢失了,能回答的问题被限制了。
技术概念的提出,本质都是为了业务场景服务的,是为解决某类特定场景的问题。
而我们当前所讨论的数据湖,已经远远超过了当初 James Dixon 所定义的数据湖,各厂商之间也对数据湖有了更多的不同定义。
• Wikipedia
• A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files. A data lake is usually a single store of data including raw copies of source system data, sensor data, social data etc., and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning.
• A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video).
• A data lake can be established "on premises" (within an organization's data centers) or "in the cloud" (using cloud services from vendors such as Amazon, Microsoft, or Google).
“数据湖是一类存储数据自然/原始格式的系统或存储,通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据,各类任务包括报表、可视化、高级分析和机器学习。
数据湖中包括来自于关系型数据库中的结构化数据(行和列)、半结构化数据(如CSV、日志、XML、JSON)、非结构化数据(如 email、文档、PDF 等)和 二进制数据(如图像、音频、视频)。
数据湖可以构建在企业本地数据中心,也可以构建在云上。”
• AWS
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
“数据湖是一个集中式存储库,允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据(无需先对数据进行结构化处理),并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习,以指导做出更好的决策。”
• 微软
Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics.
“Azure 的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力,这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据,并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时,消除了数据采集和存储的复杂性,同时也能支持批处理、流式计算、交互式分析等。”
• 阿里云
“数据湖是统一存储池,可对接多种数据输入方式,您可以存储任意规模的结构化、半结构化、非结构化数据。数据湖可无缝对接多种计算分析平台,根据业务场景不同,可以选择相应的计算引擎对数据湖中存储的数据进行数据处理与分析,从而打破孤岛,挖掘业务价值。”
综上所述,不同厂商对数据湖都有不同的一些描述和理解,但从上面我们可以看到,大家也有一些共通点:
• 统一的数据存储,存放原始的数据。
• 支持任意结构的数据存储,包括结构化、半结构化、非结构化。
• 支持多种计算分析,适用多种应用场景。
• 支持任意规模的数据存储与计算能力。
• 目标都是为了更好,更快的发现数据价值。
关于 Data Lake 每个人都有自己不同的理解,它是一套解决问题的理念,从根本上解决了业务场景所遇到的一些问题,在解决问题的过程中,技术实现上会有一定的差异与不同。
数据湖应该具备哪些能力
数据湖本身其实是一套解决方案,它是为企业的业务诉求服务的,是为发现数据价值提供的一套数据解决方案,那么在这套解决方案里它应该具备怎么样的一些能力,才能满足业务需求呢?
数据存储
• 统一存储系统
数据需要集中存储在一个存储系统中
• 支持海量数据
存储系统需要支持海量数据的存储,并且需要具备可扩展的特性,以支持海量数据的存储及性能要求。如 HDFS、AWS S3、Aliyun OSS 等。
• 任意类型数据
可以支持任意数据类型的存储,包括结构化、半结构化、非结构化的数据。
• 原始数据不变
数据应该在整个数据湖中保持最原始的一份数据,它与原始数据完全一模一样。
数据分析
• 支持多种分析引擎
可以通过多种引擎对湖上数据进行分析计算,例如离线分析、实时分析、交互式分析、机器学习等多种数据分析场景。
• 计算可扩展性
计算引擎需要具备可扩展的能力,具备随数据量不断变大、业务不断增长的弹性数据分析的能力。
• 存储与计算分离(云上)
在云上,大家现在都实现了存算分离的数据湖架构,它让存储和计算分别插上了翅膀,可以灵活的进行资源伸缩,大大节省了成本。但在云下 HDFS 架构下,它并不是一个必备能力,因为硬件成本是相对固定的。
数据湖管理
上述的数据存储和数据分析是数据湖必须具备的基本能力,但是就一个解决方案来说,如果要实际解决业务问题,仅仅是基础能力,并不足以将其应用落地,甚至会变为可怕的数据沼泽。所以在数据湖解决方案中,还需要结合一系列的数据湖上的管理能力,帮助大家管理和识别数据湖中的数据。这些能力包括:
• 多样化的数据入湖
需要具备把各种数据源接入集成到数据湖中的能力,作为数据湖构建的第一步,其意义不言而喻。
• 元数据管理
提供统一的元数据能力,可以快速发现数据湖上的元数据,并可对元数据进行管理和优化,避免数据湖成为数据沼泽。
• 数据安全
对数据可以进行细粒度的权限管控,为企业的数据湖加上安全的锁。更丰富的能力还应该支持敏感数据脱敏,数据加密,标签权限,操作审计等能力。
• 数据质量
数据质量是对湖内数据正确性、合理性监控的一种能力,及时发现数据湖中数据质量的问题。为有效的数据探索提供保障。
• 数据探索
可提供在线的数据探索能力,可以满足日常对湖内数据进行快速探索和简单查看的能力,便于更好的管理湖内的数据。
数据湖能解决哪类问题
• 数据分散,存储散乱,形成数据孤岛,无法联合数据发现更多价值
这方面来讲,其实数据湖要解决的与数据仓库是类似的问题,但又有所不同,因为它的定义里支持对半结构化、非结构化数据的管理。而传统数据仓库仅能解决结构化数据的统一管理。
在这个万物互联的时代,数据的来源多种多样,随着不同应用场景,产出的数据格式也是越来越丰富,不能再仅仅局限于结构化数据。如何统一存储这些数据,就是迫切需要解决的问题。
• 存储成本问题
数据库或数据仓库的存储受限于实现原理及硬件条件,导致存储海量数据时成本过高,而为了解决这类问题就有了HDFS/对象存储这类技术方案。数据湖场景下如果使用这类存储成本较低的技术架构,将会为企业大大节省成本。结合生命周期管理的能力,可以更好的为湖内数据分层,不用纠结在是保留数据还是删除数据节省成本的问题。
• SQL 无法满足的分析需求
越来越多种类的数据,意味着越来越多的分析方式,传统的 SQL 方式已经无法满足分析的需求,如何通过各种语言自定义贴近自己业务的代码,如何通过机器学习挖掘更多的数据价值。
• 存储/计算扩展性不足
传统数据库等在海量数据下,如规模到 PB 级别,因为技术架构的原因,已经无法满足扩展的要求或者扩展成本极高,而这种情况下通过数据湖架构下的扩展技术能力,实现成本为0,硬件成本也可控。
• 业务模型不定,无法预先建模
传统数据库和数据仓库,都是 Schema-on-Write 的模式,需要提前定义 Schema 信息。而在数据湖场景下,可以先保存数据,后续待分析时,再发现 Schema,也就是 Schema-on-Read。
LakeHouse 与数据湖
Lakehouse 概念由 Databricks 公司提出,更多内容大家可以阅读:https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html
Lakehouse 是一种新的数据技术架构,它在数据湖的基础之上,吸收了数据仓库,数据库的一些特性。这些特性最核心的一个特性是对 ACID 的支持。
Lakehouse 方案简化了整个数据链路,并提高了数据链路的实时性。它从原来的 Lambda 架构,升级到了 Kappa 架构:

相关文章
|
1月前
|
消息中间件 存储 缓存
Kafka【基础知识 01】消息队列介绍+Kafka架构及核心概念(图片来源于网络)
【2月更文挑战第20天】Kafka【基础知识 01】消息队列介绍+Kafka架构及核心概念(图片来源于网络)
94 2
|
2月前
|
SQL 分布式计算 Hadoop
Azkaban【基础 01】核心概念+特点+Web界面+架构+Job类型(一篇即可入门Azkaban工作流调度系统)
【2月更文挑战第6天】Azkaban【基础 01】核心概念+特点+Web界面+架构+Job类型(一篇即可入门Azkaban工作流调度系统)
100 0
|
1月前
|
消息中间件 存储 SQL
Flume【基础知识 01】简介 + 基本架构及核心概念 + 架构模式 + Agent内部原理 + 配置格式(一篇即可入门Flume)
【2月更文挑战第18天】Flume【基础知识 01】简介 + 基本架构及核心概念 + 架构模式 + Agent内部原理 + 配置格式(一篇即可入门Flume)
474 0
|
1月前
|
存储 数据采集 大数据
Data Lake架构揭秘
Data Lake架构揭秘
33 0
|
1月前
|
分布式计算 API 数据处理
Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
【2月更文挑战第15天】Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
60 1
|
3月前
|
消息中间件 负载均衡 监控
微服务架构:从概念到实践
微服务架构是一种面向服务的架构风格,旨在将复杂的应用程序拆分成更小、更可管理的部分。本文将介绍微服务架构的概念和原则,并提供一些实践经验和最佳实践。
|
3月前
|
负载均衡 持续交付 微服务
微服务架构的概念与实践
随着互联网应用的快速发展,传统的单体式架构已经无法满足业务需求。微服务架构作为一种全新的解决方案,正在逐渐流行起来。本文将介绍微服务架构的基本概念、特点以及实践技巧,帮助读者更好地理解和应用这一架构模式。
|
6天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
18天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
23 0
|
6天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。