乐趣区

关于后端:关于-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/2…

Lakehouse 是一种新的数据技术架构,它在数据湖的根底之上,排汇了数据仓库,数据库的一些个性。这些个性最外围的一个个性是对 ACID 的反对。

Lakehouse 计划简化了整个数据链路,并进步了数据链路的实时性。它从原来的 Lambda 架构,降级到了 Kappa 架构:

1.png

2.png

从上述 gartner 报告来看,无论是开源社区还是云厂商之间,对于 Delta Lake 都曾经有了成熟的解决方案,但 Lakehouse,目前一些技术还是初步利用阶段,但从去年开始曾经很多公司将其逐渐利用到了各自的业务零碎中,并为业务带来了更多价值。从后续咱们的利用场景案例中大家也能够看到对于开源的湖格局 Delta Lake/Hudi/Iceberg 的一些具体利用。湖格局为大家带来了更多的可能,更多人违心尝试,相干技术解说可参考咱们后续的系列文章。

DataWarehouse & Data Lake & LakeHouse 不同维度比照
下图是从各个维度对三种架构的比照,不便咱们更好的了解他们的差别以及解决的问题。

3.png

基于阿里云体系的云原生数据湖架构
4.png

数据湖存储
基于阿里云 OSS 产品,能够为数据湖提供稳固的存储底座,它具备高牢靠、可扩大、已保护、高平安、低成本、高性能等特点。并提供了版本控制,生命周期等能力。

数据湖计算
阿里云的大数据分析引擎都反对 OSS 对象存储,如果您应用开源体系,能够应用 E-MapReduce 产品,它为您提供了开源 Spark/Hive/Trino/Flink 等计算能力。如果您喜爱全托管的服务,能够应用 MaxCompute/Databricks/Hologres/Flink 等计算产品。

JindoData 是阿里云开源大数据团队自研的数据湖存储减速套件,面向大数据和 AI 生态,为阿里云和业界次要数据湖存储系统提供全方位拜访减速解决方案。JindoData 套件基于对立架构和内核实现,次要包含 JindoFS 存储系统(原 JindoFS Block 模式),JindoFSx 存储减速零碎(原 JindoFS Cache 模式),JindoSDK 大数据万能 SDK 和全面兼容的生态工具(JindoFuse、JindoDistCp)、插件反对。

数据构建与治理
阿里云数据湖构建(Data Lake Formation,DLF)是一款全托管的疾速帮忙用户构建云上数据湖的服务,产品为云原生数据湖提供了对立的元数据管理、对立的权限与平安治理、便捷的数据入湖能力以及一键式数据摸索能力。用户能够通过疾速实现云原始数据湖计划的构建与治理,并可无缝对接多种计算引擎,突破数据孤岛,洞察业务价值。

联合访问控制与云监控两款产品,能够为数据湖提供用户治理、权限管制、监控审计等能力。

数据集成能够通过 Dataworks 的数据集成能力,DLF 的数据入湖,以及 Flink 产品的 CDC,实现数据的全链路入湖,反对多种数据源的数据入湖能力。

离线作业的数据开发、任务调度能够应用 Dataworks 产品实现,也能够应用开源系列计划如 airflow+zeppelin/jupyter 等实现。

实时作业的数据开发、任务调度治理能够通过 Flink 产品实现。

数据品质、数据治理等性能能够通过 Dataworks 产品实现。

数据湖的构建、治理与利用过程
5.png

数据湖的利用场景
传统大数据平台降级为数据湖架构
传统 IDC 机房的大数据平台存在以下的问题:
物理机自建集群,日常运维老本较高
业务倒退迅速, 流量压力, 计算压力一直减少,资源有余,补货周期长
数据扩散,不同我的项目之间规范凌乱
数据定义含糊,没有无效分层, 剖析应用艰难

解决方案
存量数据通过 Jindofs 迁徙到阿里云的 OSS
基于 EMR+DLF 构建整个数据平台的根底服务
应用 EMR 弹性伸缩满足计算量需要
应用 DLF 疾速构建数据湖所需服务
接入 Druid、Hologres、Impala 为下层数据利用提供无力的反对

业务价值
极大的缩小了运维老本, 运维人员缩小 30%
应用 EMR 弹性伸缩大大缩减了计算成本,缩小 10%-20%
通过 Jindofs+OSS 归档存储,缩小 10%-20% 存储老本
构建对立的数据规范, 对数据进行分层, 极大的晋升了业务方应用效率
6.png

新批发公司全托管数据湖
业务难点:
线下 Hadoop,组件多,平台运维艰难、老本高
数据开发、运维难度大,工作稳定性差
不足健全的平安体系

解决方案与业务价值:
对立存储:对象存储 OSS,可存储任意规模的数据,可对接业务利用、各类计算剖析平台
数据湖构建与治理:数据湖构建 DLF,解决数据入湖、对立元数据管理、对立权限管制等关键问题
数据湖格局:Deltalake,该格局反对数据的增量更新和生产,从而防止了应用 Lamda 架构的两条链路来反对离线和实时的数据计算
数据分析计算引擎:DDI 数据洞察 +EMR-Presto 交互式剖析,在保障软件产品性能和性能当先的根底上,提供了全托管免运维的服务,同时有极高的 SLA 保障
数据开发与调度:EMR Studio 是 E-MapReduce 用于开源大数据开发场景的集群类型,提供交互式开发、作业提交、作业调试和工作流一站式数据开发体验

数据流程:

7.png

整体架构图如下:

8.png

广告行业利用
业务难点
存算不拆散,无奈进行灵便指的组件降级,很多新的组件个性没法应用
存储在本地盘上,运维难度搞,有坏盘的经验。存储老本高,没法做冷热分层
元数据管理在繁多的集群上,快集群应用不便,集群稳定性间接影响元数据服务稳定性流批不拆散,互相烦扰,带来作业稳定性问题

解决方案与业务价值
存算拆散,简化了价格,随时能够降级最新版本,应用 Flink, Hudi 的最新个性
对存储在 OSS 上的数据进行冷热分层,节约老本
应用 DLF,进行元数据管理,同时治理数据权限。同时疾速反对 Flink, Hudi 等新个性
Hbase 应用 Jindo Block 模式,不便扩容
Flink 和 Hbase 等业务拆散,进步了业务的稳定性
应用 Hudi 的数据湖格局,实现了数据的疾速插入,反对了疾速的元数据变更,也能反对业务的准实时剖析场景
9.png

互联网金融公司湖与仓的交融,湖仓一体
业务难点
公司的第一代数据湖是基于 Hadoop + OSS 搭建的,同时引入的数据中台的执行引擎和存储是 Maxcompute,两套异构的执行引擎带来存储冗余、元数据不对立、权限不对立、湖仓计算不能自在流动

解决方案
如图架构 MaxCompute 和 EMR 不同引擎用于不同的业务场景,应用阿里云数据湖构建 DLF 对立做元数据管理和对立用户权限治理。通过 DataWorks 进行全链路数据治理,晋升数据品质与利用能力

业务价值
将 EMR 的元数据对立到 DLF,底层应用 OSS 作对立存储,并通过湖仓一体买通 EMR 数据湖和 MaxCompute 数仓两套体系,让数据和计算在湖和仓之间自在流动
实现湖仓数据分层存储。数据中台对数据湖数据进行维度建模的两头表存储在 MaxCompute 上,EMR 或其余引擎生产 ADS 层
10.png

更多对于数据湖计划及技术的解析,请参考咱们后续文章。

原文链接:http://click.aliyun.com/m/100…

本文为阿里云原创内容,未经容许不得转载。

退出移动版