数据仓库的分层架构与演进

标签: 数据仓库 架构 | 发表时间:2022-05-11 05:38 | 作者:阿里云云栖号
出处:https://juejin.cn/tag/%E6%9E%B6%E6%9E%84

​**简介:**分层架构很容易在各种书籍和文档中去理解,但是把建模方法和分层架构放在一起就会出现很多困惑了。接下来,我会从数据研发与建模的角度,演进一下分层架构的设计原因与层次的意义。

分层架构很容易在各种书籍和文档中去理解,但是把建模方法和分层架构放在一起就会出现很多困惑了。

一、分层的演进

之所以会有分层架构,最主要的原因还是要把复杂冗长的数据吹流程分拆成一些有明确目的意义的层次,这样复杂就被拆解为一些相对简单小的模块。那么分层架构中各层都是怎么产生的呢,我们可以简化看一下。

第一个数据加工任务

​我要进行第一个数据加工任务,一切平台层次都没有,我只有一个MaxCompute。我该怎么做呢?

第一步,我需要自己做一下数据集成,把源系统的数据集成到MaxCompute。

第二步,我需要把增量合并全量生成ODS层,这样我就得到了与业务系统一样的表结构和全量的数据。

第三步,因为我对业务系统的数据表关联关系有了解,所以,我可以根据业务需求使用ODS的全量表做表关联,加工出我想要的数据结果。

第一个数据应用

​如果我不只是做一个业务需求,我是有很多业务需求,这样我就形成了我的第一个数据应用。所以,我会集成更多的数据,做更多的数据合并全量的工作,并且我的全量ODS的表可以在多个业务场景复用。

但是试想一下,如果不是一个人在开发,那么团队内部是不是要协调一下,对工作进行一下分工。做集成的和做合并的是不是可以分给一部分人,然后把后面业务需求开发再分给另外一部分人。这样就避免了重复工作,和便于工作的专业性。

于是就可以拆分出来上图中的第一个方块“集成”(STG)和第二个方块 “全量”(ODS),这部分是纯技术性的工作,还没有涉及到业务需求。对于实际业务需求计算部分,就是我们的应用层集市层(ADM)。

第二个数据应用

​随着第二个数据应用的出现,各自做集成合并已经是非常不适合的做法了,于是就有个独立的STG和ODS层。

​很多时候,做完ODS就可以做业务数据加工了。并且这种情况从数据处理技术发展之初,数据仓库概念提出之前就存在了,现在依然很普遍。集市各自依赖ODS会遇到的多源加工指标不一致的问题逐渐遭人诟病,而造成指标不一致的主要原因重复加工。不同的人对同一业务的理解都很难保障一致性,更何况不同的部门的应用。对于这个问题,可以在各个大型企业早期的数据场景都会遇到,所以,在阿里对外宣传大数据平台的时候也会提到这个早期各个业务部门数据口径不一致的问题。这个问题在ODS的层面无法解决,必须要独立出一个团队来做公共的这部分数据,让各个应用集市去做各自独立的部分,这也是公共层(CDM)的由来。

二、分层与建模

通过上面的内容,我们终于知道了数据加工过程为什么要分层。那么数据建模应该如何来做呢?因为在数据仓库领域,在数据建模一直有两种争锋相对的观点,就是范式建模还是维度建模。我们在目前大数据这个场景,一般就只提一种方法了,就是维度建模。

维度建模的经典方法与教程中没有中间层的概念,也没有主题域划分的概念。维度建模一般用在数据集市场景,也就是ODS+ADM场景,各个业务通过一致性维度实现企业级的数据一致性。在传统的被IOE统治的时代,Teradata、IBM、Oracle都有基于关系型数据库(包括MPP数据库),在某些重要的行业,例如金融这些企业都会构建大型的企业级的维度模型来给集市提供公共数据服务,这就是公共层。因为范式模型导致实体都比较窄,跟实际的分析型业务需求(维度模型)差异太大,所以需要做一层中间层(相对范式模型更宽的表,这也是宽表说法的由来)来做为应用集市层共性加工工作的层次,这就是现在我们在架构中提到的ODS+CDM+ADM的架构。

那么问题就在这里出来了,我们全部使用维度模型建模,如何使用范式模型的架构与概念。这也是我们在分层架构设计中目前最难以讲清楚的问题,也是我们实际在项目里面做的很别扭的原因:缺乏理论与实践支撑。

维度模型的构建是以实际业务需求为导向,模型是不断的需求累积出来的,适应快速的业务变化。而且维度模型不是一个建议一开始就进行企业级的思考设计的模型设计方法,是由局部业务逐渐扩张构建的。所以,我认为维度模型的架构不太适宜一开始做太重的太业务化公共层。反而应该强调在公共层构建共性加工的集合,去协调同步多个应用集市的计算,从而实现全局性的一致性维度和一致性事实。因为维度建模的建设也不是简单一蹴而就的,也是需要多次和多种数据处理以后才能最终变成符合业务需求的结果。多个不同的应用集市有大量的共性的加工需求,这些需求就是我们公共层的收集的建模需求。把这些共性需求在公共层使用维度建模的方法实现才是建设公共层的合理方法,而不是越俎代庖的去建设面向具体某个业务场景的指标标签(就是虽然实际是做了指标和标签的计算,但是我只是一个中间加工过程)。

接下来,我们继续利用上面讲解分层的方法来讲解公共层与集市层的关系。

第一个应用

​随着第一个应用出现,就可以基于部分的需求构建第一个公共层了。共性加工需求在一个中型的应用集市就很明显了。一、数据清洗。一个表的数据清洗后,会有多个数据加工任务都会使用这个清洗后的表,这就是最简单的共性加工的理解。二、多表关联。多张表的关联也是多个数据加工任务中可以提炼出来的,一次把需要关联使用的字段都关联合并到一张新表,后续的任务就可以直接用这个新表。三、共性汇总。对于数据从明细到汇总的group by,统一根据多个常用条件进行汇总,生成一张新表,后续的任务就可以直接用这个新表。一致性维度是维度建模中最关键的部分,直接影响到各个应用集市的数据标准与一致性问题,是公共层最重要的工作。

第二个应用

​随着应用的增加,需求也在不断的扩充,临时层和镜像层集成的表更多了。在公共层的明细和汇总也出现了多个应用集市都在共用的数据需求,会扩展补充到公共层。并且随着时间的变化,公共层的逻辑的正确性和公共性也需要在多个应用进入后整体考虑。

公共层与应用关系

通过上面两步演进,我们已经看到了公共层与应用层的关系了,是一体的。并不是各做各的,而是一件事情从专业化分工上做了切分。公共层与应用层只有一个共同目标,就是为满足业务需求而做数据加工。不同侧重的是应用层只需要关注自己部门的最终业务目标,公共层则需要从企业级的全局一致性、资源经济性上全盘考虑。

公共层与应用层的关系就是后勤部队与前方作战部队的关系,一个负责基础的材料准备工作,一个负责利用这些输出投入到真实战场。公共层是高效的数据复用和综合更低的资源代价,应用层则就是实际的业务需求。所以,最终的业务模型在应用层才有完整的针对性业务场景,在公共层是模型是多种场景业务需求的一个复合,代表了平台最基础和最通用的模型。

​从层次上来说,公共层向下是一块整体,负责跟上游多个交易型业务系统对接,对应用集市屏蔽了上游变化带来的影响,使得应用层能只关注于利用公共层的模型解决自己的业务需求。

原文链接

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

相关 [数据仓库 架构] 推荐:

数据仓库的架构与设计

- - CSDN博客推荐文章
公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个简陋的数据仓库,这里记录一下数据仓库的一些知识. 数据仓库多维数据模型的设计. 数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持. 这个定义的确官方,但是却指出了数据仓库的四个特点.

数据仓库的分层架构与演进

- - 掘金 架构
​**简介:**分层架构很容易在各种书籍和文档中去理解,但是把建模方法和分层架构放在一起就会出现很多困惑了. 接下来,我会从数据研发与建模的角度,演进一下分层架构的设计原因与层次的意义. 分层架构很容易在各种书籍和文档中去理解,但是把建模方法和分层架构放在一起就会出现很多困惑了. 之所以会有分层架构,最主要的原因还是要把复杂冗长的数据吹流程分拆成一些有明确目的意义的层次,这样复杂就被拆解为一些相对简单小的模块.

美团DB数据同步到数据仓库的架构与实践

- - 美团点评技术团队
在数据仓库建模中,未经任何加工处理的原始业务层数据,我们称之为ODS(Operational Data Store)数据. 在互联网企业中,常见的ODS数据有业务日志数据(Log)和业务DB数据(DB)两类. 对于业务DB数据来说,从MySQL等关系型数据库的业务数据进行采集,然后导入到Hive中,是进行数据仓库生产的重要环节.

数据仓库

- Ran - [email protected]
翻译:马少兵、曾怀东、朱翊然、林业. 尽管服务器存储、处理能力得到有效的提高,以及服务器价格的降低,让人们能够负担起大量的服务器,但是商业软件应用和监控工具快速的增加,还是使得人们被大量的数据所困扰. 在数据仓库领域中的许多系统管理员、应用开发者,以及初级数据库管理员发现,他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语,概念或工具.

数据仓库简介、发展、架构演进、实时数仓建设、与离线数仓对比

- - zhisheng的博客
数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务,数据仓库的建设也是“数据智能”中必不可少的一环. 本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容. 原地地址: https://ververica.cn/developers/how-to-do-real-time-counting/.

数据仓库概念

- - 互联网 - ITeye博客
数据仓库:是一个数据库环境,它提供用户用于决策支持的当前和历史数据,这些数据在传统的数据库中不方便得到. 特点:面向主题,集成的,相对稳定的,反应历史变化的. 组成:数据仓库的数据库,数据抽取工具,元数据,访问工具,数据集市,数据仓库管理,信息发布系统. 数据挖掘:就是从大量数据中获取有效的,新颖的,潜在有用的,最终可理解的模式的过程.

大数据仓库-kudu

- - 数据库 - ITeye博客
数据仓库里面存储引擎是非常重要的,存储引擎的好坏,基本决定了整个数仓的基础. cloudera公司最近发布了一个kudu存储引擎. 按照cloudera的想法,kudu的出现是为了解决,hbase,parquet不能兼顾分析和更新的需求,所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用.

数据仓库的设计与开发

- - 数据库 - ITeye博客
     数据仓库系统的设计与开发. 1)       收集和分析业务需求.   用户需求,管理人员需求. 2)       建立数据模型和数据仓库的物理设计.   概念模型,逻辑模型,物理模型. 3)       定义数据源. 数据源面向应用,不是面向主题,而且数据源之间存在多个不一致的情况,所以必须在已有的系统中定义记录系统(内容正确,在多个数据源间起决定作用的操作型数据源).

oracle数据仓库设计指南

- - 数据库 - ITeye博客
ODS(Operational Data Store)是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征,它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据.     一般在带有ODS的系统体系结构中,ODS都设计为如下几个作用:. 1 )    在业务系统和数据仓库之间形成一个隔离层.

[原]数据仓库元数据管理

- - oycn2010的专栏
元数据管理, 简单的做就是EXCEL结合版本管理等传统工具管理, 专业点就用专门的元数据管理工具;. 数据字典--> 数据知识库. 业务元数据,技术元数据,管理元数据. 参照:SAP元数据管理平台:按业务(角色)分类,按技术类型分类(特征,关键值,DSO,InfoCube),数据流程图. 按照传统的定义,元数据(Metadata)是关于数据的数据.