近日因公司业务问题,突发兴致,想了解一下数仓及相关架构,恰逢阿里云有湖仓一体架构的直播,遂听之,但是直播内容讲的比较浅,于是深入了解之,并记录如下个人所得笔记,如有偏驳,后续改之.
概述
湖仓一体架构是针对数据存储的一种架构,主要还是针对企业级系统大数据存储及治理的一种机构.
发展
湖仓一体的架构是第三代演变的架构
- 第一代: 纯粹的数据仓库
- 第二代: 两层的湖仓一体,数据湖还是数据湖,数据仓还是数据仓,只是简单的融合在一起,运营系统的数据进入数据湖,数仓从湖中提取数据ETL后,再次存入数据湖,供给业务系统使用.
- 第三代: 湖仓一体,湖中建仓,在当前的架构中其实是将数仓的功能融合到了数据湖中,让数据湖拥有数仓的功能
理解
湖仓一体(LakeHouse)出现的原因
我们先来了解一下数据仓库和数据湖的概念
数据仓库
如果做过几年业务系统开发的开发童鞋一定深有体会,随着业务系统访问量和运行时间的增加,数据量级也随之增长,此时如果我们开发一个新的系统需要用到多个业务系统的数据,该如何操作?
如果多个业务系统分属不同数据库,甚至不同平台的数据库,比如Mysql/Oracle/MongoDB/PG,怎么才能关联到一起?
这时候就出现了第一代的数据仓库,概念也是很顺理成章,将各个数据库的数据抽取/转化/加载到一个大的数据库不就行了.
这里的一个大的数据库就是数据仓库(Data Warehouse),简称DW
数据抽取/转化/加载的过程就称为ETL
数据湖
数据仓库已经解决了大部分的数据问题,为什么还要数据湖?
数据仓库只能存储结构化的数据,可以理解为数据仓库就是一个大号的关系型数据库,那么数仓只能存储结构化数据.
而我们业务系统中其实还有很多非结构化的数据,比如日志,图片/语音/视频等文件等等,这种数据没办法按一个结构去存储,可是某些情况下我们还是需要对这些数据进行分析的,比如推荐算法需要通过对用户浏览/点击的日志分析对应用户的需求,进而给用户推送推荐商品,这个时候数仓就不能满足我们的需求了.
这也从侧面说明了一个问题: 在当前时代,数据是有价值的.
我们需要将业务系统的所有数据都存储到一个地方,这个地方既能存储结构化的数据,也能存储非结构的数据,这样我们就能随时从这个地方获取我们想要的数据进行一些操作.
这个地方就是数据湖(Data Lake)
个人理解: 数据湖就是我们不管是什么样的数据,不管当前对我们有用没用,先存储进去,万一后面有用呢.
数据湖的特点: 能存储任意数据,解决数据孤岛问题,容易出现数据沼泽问题.
ps:
- 数据孤岛: 各个业务系统数据并不相通,每个业务系统都自己搞自己的业务数据,即使他们的数据可能存在互通之处,不进行也无法进行交流沟通.
- 举例: 某公司有三个业务系统,每个业务系统都存储了一份自己的单位/员工信息,即使这份信息其实是一样,当某一个系统的单位/员工信息修改后,其他系统并不会随之修改,互不影响,就像孤岛一样
- 数据沼泽: 数据湖由于可以存储任意数据,因此所有业务系统都往里面扔数据,但不进行数据治理,导致数据湖的数据越来越多,越来越杂乱,最终形成一个杂乱不堪的数据集,无法从中获取有效数据.
数据湖使用的正确姿势:
可以联想一下我们现实生活中的湖泊,上游有水进入湖泊,湖泊有下游流出,并进入到各个河流
数据湖也是一样的,上游业务系统存储进入数据,数据在数据湖中经过治理处理后,进入到下游的各个业务系统中,然后各个业务系统再形成新的数据存储入数据湖,周而复始,形成良性循环,让数据产生更多的价值
原因
简单了解了数据湖和数仓的概念后,我们再来了解湖仓一体
湖仓一体出现的原因个人理解很简单: 数仓具有数据湖没有的功能,他俩需要形成互补,互补的结果就是湖仓一体.
数仓的存储成本较高,在一类业务上的数据分析处理更加优秀
数据湖的存储成本较低,主要针对异构的数据挖掘
这么一结合不就搞定了很多问题,举例: 湖仓一体支持数据在数仓和数据湖之间流动,可以将最近要分析的某类数据从数据湖中提取到数仓中进行更好的分析,也可以将数仓中暂时用不到的数据转入数据湖进行低成本存储,降低成本.
并且湖仓一体提供了统一的元数据,减少了第二代双层湖仓一体的ETL工作,也相当于减少系统的复杂度,将系统的稳定性下沉.
思考
湖仓一体架构应该是一种针对数据存储/分析/处理的一整套服务方案的集合,越做开发其实越能体会到数据量的增长,多个系统间数据的交互其实才是面临的最大问题,普通的增删改查其实没有任何难度可言,只有这种系统层面的问题才是真正难以解决的.
即使有了湖仓一体的思想和理念,但是如何实现也存在很多问题,目前暂时没有太多头绪,希望后续能在大厂的相关实践中找到答案!
