400-0380-010
申请试用
免费预约演示
让我们的咨询顾问用最短 20分钟 的讲解,来帮助您
更高效的评估大数据+RPA
数仓用的好好的,还要建数据湖么
发布时间:2021-12-03 浏览:1
数据湖的发展模式和我们熟知的技术发展模式一样,随着时间的推移,成功模式才变得清晰。这种清晰源自努力实践的经验教训,我们也更加清晰了数据湖与数据仓库之间的关系。那么数据湖和数据仓库该如何选择呢?



数据湖与数据仓库,只能二选一吗?



图片


在数据湖体系结构中,计算资源分离是一种核心的抽象,这是Redshift Spectrum、Presto和Athena解决方案存在的原因。以Amazon的Athena为例,Athena不是一个数据仓库软件,而是一个基于开源FaceBook Presto开发的按需查询引擎,它将按需提供“计算”资源查询数据作为一项服务来提供。Amazon的Redshift Spectrum和Athena一样可以查询数据湖中的数据,利用的是从一个Redshift集群中分离出来的计算资源。

根据设计,数据湖中的查询数据服务可以很好地抽象出这个引擎模型,而且无论你在Google云上是否有亚马逊数据湖(AWS数据湖)、Oracle数据湖、Azure数据湖或BigQuery数据湖,模型都是类似的。可以通过Athena这类的查询引擎或者像Redshift、 BigQuery、Snowflake等“仓库”来查询数据湖数据内容,这些服务提供计算资源,而不是提供一个数据湖。

所以,对于大多数企业来说,数据湖和数据仓库如何共存才是正确的讨论内容,而不是讨论如何二选一。


数据仓库可以当作数据湖使用么?




传统上,数仓旨在反映企业已经完成的事务,也反映企业完成一系列的一致事务,例如一个已经完成的事务可能提供有关收入、订单、“最佳客户”和其他领域的重要事务。

但是,在数仓“导入所有数据”模型中,数仓包含所有的数据内容,其中会包括暂时的和易失的原始数据。

将所有的原始数据重新打包到数仓中的操作更像是操作型数据库(Operational Data Store,ODS)或者数据集市的操作,而不像是数仓的操作。你能将所有的数据都扔进数仓吗?不能。不能仅仅因为你可以在技术上做一些事情,就可以使它成为正确的体系结构。

图片

将所有数据放进仓库的建议说,事务数据只是逻辑组织数据的一个功能。在企业内部定义和推广这个逻辑定义的人将无法得到理解,甚至更糟的是他将被忽视,原因是这种方式几乎就是一种发生在数仓中的“数据沼泽”,尽管教科书上定义数据沼泽发生在数据湖中。对于任何一个被迫善后处理的人来说,这都是一场数据处理的噩梦。


这个模型会将你限制在数仓技术及其模型中,同时还需要你将所有数据都导入数仓。如果你喜欢四处寻找供应商、设定各种人为限制、降低数据认知能力和背负各种技术债务,那么这种方法肯定很适合你。

正确的做法是,数据湖可以最小化技术债务,同时还可以加速企业团队对数据的消耗。考虑到数仓、查询引起和数据分析市场的变化在加快,你战略的核心应该是最小化风险和技术债务。

数据湖的优势



数据湖不仅仅可以存储数据,还可以兼容数仓、数据分析技术栈中的技术。事实上,大多数数据湖是动态的生态系统,而不是静态的封闭系统。当数仓负载适中时,数据湖是一个活跃数据源,源源不断为其输送数据,反之亦然,负载过重时,数据湖进行对数据进行适当地动态处理,以降低成本和提高效率。

数据湖和数仓的存在确实不冲突的,那么为什么有人说数据湖会变成数据沼泽,因为它们只是存储,缺乏治理、管理,没有数据生命周期/保留策略,也没有元数据。

图片


在极端情况下,这是真的。如果你把一个数据湖当作是你笔记本电脑上一个通用的“无标题文件夹”来处理文件,那么就可能会变成一个数据沼泽,所以,这会存在风险。然而,对于任何习惯以这种方式进行文件转储的人来说,他们对成功安排人员、流程和技术都有点不感兴趣。

那么,真正的数据沼泽是什么呢?真正的数据沼泽是设计不当创造出来的,而不是疏于管理促成的。

数据湖更大的威胁不是缺乏治理、管理、生命周期策略和元数据,而是缺乏防止这种情况发生的生态系统,这个生态系统包括工具、角色、职责和系统。数据湖之所以成为沼泽,不仅仅是因为“倾倒文件”,还因为数据湖的相关人员、流程和技术安排过于复杂。如果你认为你的企业级数仓过程缓慢,那么你的数据湖也会如此。

简单、敏捷和灵活是数据湖众多优点中的一部分,当湖中出现重要的业务逻辑和流程时,你将面临这样的风险:创建出来的解决方案缺乏简单性、无法响应变化、设计过于严格,而这就是你需要警惕的数据沼泽。数据沼泽是昂贵的、费时的,从而无法满足任何人的期望。这听起来是不是很熟悉?

对于那些正在计划或者已经部署了数据湖的人来说,要小心数据湖的定位和特性蔓延。经常会看到供应商将其在传统数仓和其它ETL产品中发现的特性和功能定义为数据湖的功能,尽管从技术上讲,可以在数据湖中进行复杂的数据处理。

但是,你可能在数据湖外已经有了执行这些处理操作的工作流、工具、人员和技术,并不是所有的数据处理都符合你的上下游流程,请仔细考虑数据湖嵌套处理数据导致复杂性激增的风险。

请警惕,当前或计划中的数据湖逐渐看起来更像是传统的ETL工具和数仓的合体,如果你已经经历过一个过于复杂的构建企业级数仓工作,会很容易发现这一点。

数据湖专注于业务价值,为你提供了一个在全面数据分析的背景下搭建工作框架的机会,这会提高你实现数据湖目标和衡量业务绩效的速度。