精华内容
下载资源
问答
  • 数据仓库层级划分

    千次阅读 2020-10-14 21:57:57
    • 清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。 • 数据血缘追踪:能够快速准确地定位到问题,并清楚它的危害范围。 • 减少重复开发:规范数据分层,开发一些...
    1.为什么要分层
    • 清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
    • 提升公共指标的复用性,减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
    • 降低数据口径不统一的风险。
    • 屏蔽原始数据和业务影响:不必改一次业务就需要重新接入数据。
    • 数据血缘追踪:能够快速准确地定位到问题,并清楚它的危害范围。
     
    2.Inmon与Kimball
        在Inmon提出的CIF(Corporate Information Factory,企业信息工厂)中,他将ODS(Operational Data Store,操作型存储)、EDW(Enterprise Data Warehouse,企业数据仓库)、DM(DataMart,数据集市)区别开来,共分三层。
        而Kimball的总线架构强调多个数据集市合成了数据仓库,只是他们基于统一的维度而已。因此,总线架构的分层中,从数据源接口就直接到了DM了。
        根据这两种思路,又可以衍生一些不同的方法。例如IBM就提出一种CDW的概念,叫做企业数据仓库层,这一层介于EDW和DM之间,起过渡作用(因为EDW和DM两层的建模理念是不同的)。
        下面我们参考Inmon与Kimball的思想,将数据仓分为如下几层进行简单介绍。
     
    3.CIF 层次架构
        CIF 层次架构(信息工厂)通过分层将不同的建模方案引入到不同的层次中,CIF 将数据仓库分为四层,如图所示:
    3.1 ODS(Operational Data Store)
        操作数据存储层: ODS 层中的数据全部来自于业务数据库,ODS 层的表格与业务数据库中的表格一一对应,就是将业务数据库中的表格在数据仓库的底层重新建立一次,数据与结构于业务系统完全保持一致。
        由于业务数据库(OLTP)基本按照 ER 实体模型建模,因此 ODS 层中的建模方式也是 ER 实体模型。
     
    3.2  DWD(Data Warehouse Detail)
        数据明细层:DWD 层要做的就是将数据进行 清洗、脱敏、转换、整合,在这层需要将 脏数据、状态定义不一致、命名不规范 等数据都会被处理。DWD 层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。
        在 DWD 可能会用到 ER 或者维度模型。在 DWD 层会抽取出公共维度,也就是说 DWD 层是一个非常规范的,高质量的,可信的数据明细层。
     
    3.3 DWS(Data Warehouse Service)
        服务数据层(公共汇总层): DWS 层为公共汇总层,会进行轻度汇总,粒度比明细数据稍粗,会针对度量值进行汇总,目的是避免重复计算。
        往往在 DWS 层建立宽表。例如订单总金额,可能在原始数据中没有这个数据,进入 DWS 层后可以统计出订单总金额,避免重复地拿订单明细数据去计算。
        DWS 层建议使用维度建模,因为数据仓库的主要应用是进行数据分析。 
     
    3.4 DM(Data Market)
        数据集市层: DM 层为数据集市层, 针对不同的主题进行统计报表的生成。 例如订单主题、物流主题等。在 DM 完成报表或者指标的统计,DM 层已经不包含明细数据,是粗粒度的汇总数据,因此 DM 层会被当 成 BI 或者 OLAP 的底层模型。
       
     
     
    展开全文
  • 数据仓库层次划分

    千次阅读 2019-09-15 23:01:41
    构建数据仓库时,至少应具备以下物理层:

    构建数据仓库时,至少应具备以下物理层:
    在这里插入图片描述

    展开全文
  • 数据仓库层级架构

    千次阅读 2020-08-17 18:39:54
    数据仓库层级架构 来理解一下两者在架构设计上的联系和区别。 teradata一般是对企业级数据仓库而言,在Teradata的数据仓库架构,一般是缓冲层,模型层,集市层。如下图所示: ods:贴源层,保存源系统细节数据...

                                             数据仓库的层级架构

     

     teradata一般是对企业级数据仓库而言,在Teradata的数据仓库架构,一般是缓冲层,模型层,集市层。如下图所示:

    ods:贴源层,保存源系统细节数据。

     源系统为oracle数据库,一般有多个。通过fastload或tpump或者mutilload等工具加载到数据仓库缓冲层中,设计缓冲层主要是从技术实现的角度考虑。

     基础层根据业务划分主题,通过三范式建模得来。集市层作者遇到的情况就是为作为报表的数据表。

     整个ETL过程,事实上可以描述为ELT,抽取,加载,转换。这个过程由teradata自己开发的ETL Automation控制工作流程。

     一般情况下,都是按天来加载数据,比如今天24:00以后加载今天的数据。也有业务要求数据要在数据仓库中实时查询,那可以通过消息队列的方式来实现。

    数据仓库的架构通常是这样的,stg,ods,dwd,app。

    •  stg:临时层,技术实现的考虑。
    •  ods:贴源层,保存源系统细节数据。
    •  dwd:模型层
    •  app:应用层,往往也是报表的数据表。

     如下图所示:

     互联网公司与传统企业公司的区别在于点击流日志作为分析的一个主要来源。

    模型设计上主要的区别在于ods这一层的设计。考虑设计它的原因主要有:

     1、技术上的实现考虑,数据源来自多个异源数据库,有了这层,可以减少转换的成本,只专注于抽取和加载。

    2、模型层往往根据设定的模型来得到数据,而需求是具有很大变化性的,甚至有的时候很紧急,模型层可能会无法支撑需求,所以需要一个稳定的数据细节来支撑。

    互联网公司中,我们用hive作为数据仓库实现的数据库。

    展开全文
  • 本文主要讲解数据仓库的一个重要环节:如何设计数据分层!其它关于数据仓库的内容可参考之前的文章。 本文对数据分层的讨论适合下面一些场景,超过该范围场景 or 数据仓库经验丰富的大神就不必浪费时间看了。 ...

    转载来自https://www.cnblogs.com/wang3680/p/11538451.html

     

    转载http://bigdata.51cto.com/art/201710/554810.htm

    一、文章主题

    本文主要讲解数据仓库的一个重要环节:如何设计数据分层!其它关于数据仓库的内容可参考之前的文章。

    【漫谈数据仓库】 如何优雅地设计数据分层

    本文对数据分层的讨论适合下面一些场景,超过该范围场景 or 数据仓库经验丰富的大神就不必浪费时间看了。

    • 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务。
    • 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得。
    • 各种重复计算,严重浪费了计算资源,需要优化性能。

    二、文章结构

    最初在做数据仓库的时候遇到了很多坑,由于自身资源有限,接触数据仓库的时候,感觉在互联网行业里面的数据仓库成功经验很少,网上很难找到实践性比较强的资料。而那几本经典书籍里面又过于理论,折腾起来真是生不如死。还好现在过去了那个坎,因此多花一些时间整理自己的思路,帮助其他的小伙伴少踩一些坑。文章的结构如下:

    • 为什么要分层?这个问题被好几个同学质疑过。因此分层的价值还是要说清楚的。
    • 分享一下经典的数据分层模型,以及每一层的数据的作用和如何加工得来。
    • 分享两个数据分层的设计,通过这两个实际的例子来说明每一层该怎么存数据。
    • 给出一些建议,不是最好的,但是可以做参考。

    0x01 为什么要分层

    我们对数据进行分层的一个主要原因就是希望在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因:

    • 清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
    • 数据血缘追踪:简单来讲可以这样理解,我们最终给业务诚信的是一能直接使用的张业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。
    • 减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
    • 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。
    • 屏蔽原始数据的异常。
    • 屏蔽业务的影响,不必改一次业务就需要重新接入数据。

    数据体系中的各个表的依赖就像是电线的流向一样,我们都希望它是规整、流向清晰、便于管理的,如下图:

    【漫谈数据仓库】 如何优雅地设计数据分层

    但是,最终的结果大多却是依赖复杂、层级混乱,想梳理清楚一张表的声称途径会比较困难,如下图:

    【漫谈数据仓库】 如何优雅地设计数据分层

    0x02 怎样分层

    一、理论

    我们从理论上来做一个抽象,可以把数据仓库分为下面三个层,即:数据运营层、数据仓库层和数据产品层。

    【漫谈数据仓库】 如何优雅地设计数据分层

    • ODS 全称是 Operational Data Store,操作数据存储.“面向主题的”,数据运营层,也叫ODS层,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的 ETL 之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。但是,这一层面的数据却不等同于原始数据。在源数据装入这一层时,要进行诸如去噪(例如有一条数据中人的年龄是 300 岁,这种属于异常数据,就需要提前做一些处理)、去重(例如在个人资料表中,同一 ID 却有两条重复数据,在接入的时候需要做一步去重)、字段命名规范等一系列操作。
    • 数据仓库层(DW),是数据仓库的主体.在这里,从 ODS 层中获得的数据按照主题建立各种数据模型。这一层和维度建模会有比较深的联系,可以多参考一下前面的几篇文章。
    • 数据产品层(APP),这一层是提供为数据产品使用的结果数据

    在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、Mysql 等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。

    如我们经常说的报表数据,或者说那种大宽表,一般就放在这里。

    二、技术实践

    这三层技术划分,相对来说比较粗粒度,后面我们会专门细分一下。在此之前,先聊一下每一层的数据一般都是怎么流向的。这里仅仅简单介绍几个常用的工具,侧重中开源界主流。

    1. 数据来源层→ ODS层

    这里其实就是我们现在大数据技术发挥作用的一个主要战场。 我们的数据主要会有两个大的来源:

    业务库,这里经常会使用 Sqoop 来抽取,比如我们每天定时抽取一次。在实时方面,可以考虑用 Canal 监听 Mysql 的 Binlog,实时接入即可。

    埋点日志,线上系统会打入各种日志,这些日志一般以文件的形式保存,我们可以选择用 Flume 定时抽取,也可以用用 Spark Streaming 或者 Storm 来实时接入,当然,Kafka 也会是一个关键的角色。

    其它数据源会比较多样性,这和具体的业务相关,不再赘述。

    【漫谈数据仓库】 如何优雅地设计数据分层

    注意: 在这层,理应不是简单的数据接入,而是要考虑一定的数据清洗,比如异常字段的处理、字段命名规范化、时间字段的统一等,一般这些很容易会被忽略,但是却至关重要。特别是后期我们做各种特征自动生成的时候,会十分有用。后续会有文章来分享。

    2. ODS、DW → App层

    这里面也主要分两种类型:

    1. 每日定时任务型:比如我们典型的日计算任务,每天凌晨算前一天的数据,早上起来看报表。 这种任务经常使用 Hive、Spark 或者生撸 MR 程序来计算,最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
    2. 实时数据:这部分主要是各种实时的系统使用,比如我们的实时推荐、实时用户画像,一般我们会用 Spark Streaming、Storm 或者 Flink 来计算,最后会落入 Es、Hbase 或者 Redis 中。

    0x03 举个例子

    网上的例子很多,就不列了,只举个笔者早期参与设计的数据分层例子。分析一下当初的想法,以及这种设计的缺陷。上原图和内容。

    当初的设计总共分了 6 层,其中去掉元数据后,还有5层。下面分析一下当初的一个设计思路。

    【漫谈数据仓库】 如何优雅地设计数据分层

    缓冲层(buffer)

    • 概念:又称为接口层(stage),用于存储每天的增量数据和变更数据,如Canal接收的业务变更日志。
    • 数据生成方式:直接从kafka接收源数据,需要业务表每天生成update,delete,inseret数据,只生成insert数据的业务表,数据直接入明细层
    • 讨论方案:只把canal日志直接入缓冲层,如果其它有拉链数据的业务,也入缓冲层。
    • 日志存储方式:使用impala外表,parquet文件格式,方便需要MR处理的数据读取。
    • 日志删除方式:长久存储,可只存储最近几天的数据。讨论方案:直接长久存储
    • 表schema:一般按天创建分区
    • 库与表命名。库名:buffer,表名:初步考虑格式为:buffer日期业务表名,待定。

    明细层(ODS, Operational Data Store,DWD: data warehouse detail)

    • 概念:是数据仓库的细节数据层,是对STAGE层数据进行沉淀,减少了抽取的复杂性,同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式,将各个专业数据进行集中,明细层跟stage层的粒度一致,属于分析的公共资源
    • 数据生成方式:部分数据直接来自kafka,部分数据为接口层数据与历史数据合成。

    canal日志合成数据的方式待研究。

    • 讨论方案:canal数据的合成方式为:每天把明细层的前天全量数据和昨天新数据合成一个新的数据表,覆盖旧表。同时使用历史镜像,按周/按月/按年 存储一个历史镜像到新表。
    • 日志存储方式:直接数据使用impala外表,parquet文件格式,canal合成数据为二次生成数据,建议使用内表,下面几层都是从impala生成的数据,建议都用内表+静态/动态分区。
    • 日志删除方式:长久存储。
    • 表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    • 库与表命名。库名:ods,表名:初步考虑格式为ods日期业务表名,待定。
    • 旧数据更新方式:直接覆盖

    轻度汇总层(MID或DWB, data warehouse basis)

    • 概念:轻度汇总层数据仓库中DWD层和DM层之间的一个过渡层次,是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗,处理包含,如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于二者的应用领域不同,DWD的数据来源于生产型系统,并未满意一些不可预见的需求而进行沉淀;轻度综合层则面向分析型应用进行细粒度的统计和沉淀
    • 数据生成方式:由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
    • 日志存储方式:内表,parquet文件格式。
    • 日志删除方式:长久存储。
    • 表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    • 库与表命名。库名:dwb,表名:初步考虑格式为:dwb日期业务表名,待定。
    • 旧数据更新方式:直接覆盖

    主题层(DM,data market或DWS, data warehouse service)

    • 概念:又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
    • 数据生成方式:由轻度汇总层和明细层数据计算生成。
    • 日志存储方式:使用impala内表,parquet文件格式。
    • 日志删除方式:长久存储。
    • 表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    • 库与表命名。库名:dm,表名:初步考虑格式为:dm日期业务表名,待定。
    • 旧数据更新方式:直接覆盖

    应用层(App)

    • 概念:应用层是根据业务需要,由前面三层数据统计而出的结果,可以直接提供查询展现,或导入至Mysql中使用。
    • 数据生成方式:由明细层、轻度汇总层,数据集市层生成,一般要求数据主要来源于集市层。
    • 日志存储方式:使用impala内表,parquet文件格式。
    • 日志删除方式:长久存储。
    • 表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    • 库与表命名。库名:暂定apl,另外根据业务不同,不限定一定要一个库。
    • 旧数据更新方式:直接覆盖。

    0x04 如何更优雅一些

    前面提到的一种设计其实相对来讲已经很详细了,但是可能层次会有一点多,而且在区分一张表到底该存放在什么位置的时候可能还有不小的疑惑。我们在这一章里再设计一套数据仓库的分层,同时在前面的基础上加上维表和一些临时表的考虑,来让我们的方案更优雅一些。

    下图,做了一些小的改动,我们去掉了上一节的Buffer层,把数据集市层和轻度汇总层放在同一个层级上,同时独立出来了维表和临时表。

    【漫谈数据仓库】 如何优雅地设计数据分层

    这里解释一下DWS、DWD、DIM和TMP的作用。

    • DWS:轻度汇总层,从ODS层中对用户的行为做一个初步的汇总,抽象出来一些通用的维度:时间、ip、id,并根据这些维度做一些统计值,比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效,在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算,而不是ODS。
    • DWD:这一层主要解决一些数据质量问题和数据的完整度问题。比如用户的资料信息来自于很多不同表,而且经常出现延迟丢数据等问题,为了方便各个使用方更好的使用数据,我们可以在这一层做一个屏蔽。
    • DIM:这一层比较单纯,举个例子就明白,比如国家代码和国家名、地理位置、中文名、国旗图片等信息就存在DIM层中。
    • TMP:每一层的计算都会有很多临时表,专设一个DWTMP层来存储我们数据仓库的临时表。

    0x05 问答

    有朋友问了一些问题,有一些之前的确没讲清楚,补到这里。

    问答一: dws 和 dwd 的关系

    问:dws 和dwd 是并行而不是先后顺序?

    答:并行的,dw 层

    问:那其实对于同一个数据,这两个过程是串行的?

    答:dws 会做汇总,dwd 和 ods 的粒度相同,这两层之间也没有依赖的关系

    问:对呀,那这样 dws 里面的汇总没有经过数据质量和完整度的处理,或者单独做了这种质量相关的处理,为什么不在 dwd 之上再做汇总呢?我的疑问其实就是,dws的轻度汇总数据结果,有没有做数据质量的处理?

    答:ods 直接到 dws 就好,没必要过 dwd,我举个例子,你的浏览商品行为,我做一层轻度汇总,就直接放在 dws 了。但是你的资料表,要从好多表凑成一份,我们从四五份个人资料表中凑出来了一份完整的资料表放在了 dwd 中。然后在 app 层,我们要出一张画像表,包含用户资料和用户近一年的行为,我们就直接从dwd中拿资料, 然后再在 dws 的基础上做一层统计,就成一个app表了。当然,这不是绝对,dws 和 dwd 有没有依赖关系主要看有没有这种需求。

    问答二: ods 和 dwd 的区别

    问:还是不太明白 ods 和 dwd 层的区别,有了 ods 层后感觉 dwd 没有什么用了。

    答:嗯,我是这样理解的,站在一个理想的角度来讲,如果 ods 层的数据就非常规整,基本能满足我们绝大部分的需求,这当然是好的,这时候 dwd 层其实也没太大必要。 但是现实中接触的情况是 ods 层的数据很难保证质量,毕竟数据的来源多种多样,推送方也会有自己的推送逻辑,在这种情况下,我们就需要通过额外的一层 dwd 来屏蔽一些底层的差异。

    问:我大概明白了,是不是说 dwd 主要是对 ods 层做一些数据清洗和规范化的操作,dws 主要是对 ods 层数据做一些轻度的汇总?

    答:对的,可以大致这样理解。

    问答三:app 层是干什么的?

    问:感觉数据集市层是不是没地方放了,各个业务的数据集市表是应该在 dwd 还是在 app?

    答:这个问题不太好回答,我感觉主要就是明确一下数据集市层是干什么的,如果你的数据集市层放的就是一些可以供业务方使用的宽表表,放在 app 层就行。如果你说的数据集市层是一个比较泛一点的概念,那么其实 dws、dwd、app 这些合起来都算是数据集市的内容。

    问:那存到 Redis、ES 中的数据算是 app层吗?

    答:算是的,我个人的理解,app 层主要存放一些相对成熟的表,能供业务侧使用的。这些表可以在 Hive 中,也可以是从 Hive 导入 Redis 或者 ES 这种查询性能比较好的系统中。

    0xFF 总结

    数据分层是数据仓库非常重要的一个环节,它决定的不仅仅是一个层次的问题,还直接影响到血缘分析、特征自动生成、元数据管理等一系列功能的建设。因此适于尽早考虑。

    另外,每一层的名字不必太过在意,自己按照喜好就好。

    本文分享了笔者自己对数据仓库的一些理解和想法,不一定准确也不一定通用,但是可以作为一个参考的思路。有什么问题欢迎多交流。

    作者:少帅

    出处:少帅的博客--http://www.cnblogs.com/wang3680

    您的支持是对博主最大的鼓励,感谢您的认真阅读。

    本文版权归作者所有,欢迎转载,但请保留该声明。

    展开全文
  • 1.数据仓库简介 1.1什么是数据仓库 本质上,数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。 1.1.1 数据仓库的定义 面向主题、集成(面向主题相关,多个数据源)、非易失(一般并不进行数据更新...
  • 一、数据仓库简介、 二、操作型数据与分析型数据对比、 三、数据仓库 特征 与 定义、 四、特征一 : 面向主题 数据组织方式、 五、面向应用 数据组织方式、 六、面向主题 组织数据、 七、数据 从 面向应用 转为 面向...
  • 数据仓库维度建模

    2020-01-08 15:47:15
    红色框框内为数据仓库基础层级划分 stg(缓冲层):将接入的不同类型的源数据清晰、转换等处理后存储于表中。 dim(维度层):从缓冲层中获取数据,整合分析数据需要的维度信息存储于表中。 ods(数据仓库层):将同...
  • 数据仓库

    2020-04-18 12:50:37
    数据仓库与数据库区别4、数据仓库分层架构5、数据仓库元数据管理 1. 数据仓库的基本概念 数据仓库, 英文名称为Data Warehouse,可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策...
  • 数据仓库建模方法及企业数据中台建设。
  • 逻辑架构、技术架构、分层设计、主题划分、方法论 命名规范 各层级命名、任务命名、表命名、字段命名、指标命名等 模型规范 建模方法、建模工具、血缘关系、维度退化、一致性维度、元数据管理 开发规范 脚本...
  • 数据仓库分层

    2020-09-03 19:03:44
    而我们这个项目中将数据仓库层进而划分了两个层数据明 细层(DWD 层)和数据服务层(DWS 层)。即该项目中一共划分为 4 层 ODS 层、 DWD 层、DWS 层、DM 层 我们采用维度建模,考虑到三范式同时为了方便逻辑计算,...
  • 数据仓库理论

    2020-09-13 14:15:26
    数据仓库:英文Data WareHouse,数据仓库是面向主题,为分析数据而设计的,是一个各种数据(包括历史数据和当前数据)的中心存储系统,主要服务于商业智能(也就是BI)和企业决策管理。 商业智能:指用现代数据...
  • 1.什么是数据仓库 1.1 基本概念 1.2 主要特征 1.2.1 面向主题 1.2.2 集成性 1.2.3 非易失性(不可更新性) 1.2.4 时变性 2.数据库和数据仓库的区别 3.数据仓库的分层架构 4.数据仓库的元数据管理 1.什么是...
  • 想要有一个高质量的数据仓库,那么首先从数据仓库的设计上,我们就得有一个主题域完善,层级分明(通常分为ODS【数据源表层】,DWD【数据明细层】,DWS【数据汇总层】,DWA【数据应用层】),且数据消费场景明确,...
  • 这应该是数据仓库同学在设计数据分层时首先要被挑战的问题,类似的问题可能会有很多,比如说“为什么要做数据仓库?”、“为什么要做元数据管理?”、“为什么要做数据质量管理?”。当然,这里我们只聊一下为什么要...
  • Hive开发要知道数据仓库的四个层次设计

    万次阅读 多人点赞 2018-02-12 18:11:09
    数据仓库数据仓库全面接收源系统数据,ETL进程对数据进行规范化、验证、清洗,并最终装载进入数据集市,通过数据集市支持系统进行数据查询、分析,整个数据仓库包含四大层次。 1.数据仓库的四个操作  ETL...
  • 数据仓库从全局来看会涉及到四大块:业务源系统、ETL系统、数据应用层、数据消费层。 业务源系统 数据仓库中数据的来源是各个业务源系统。严格说来业务源系统不属于数据仓库的范畴。但是如果业务系统模型设计...
  • 数据仓库分层模型

    万次阅读 2019-10-31 21:13:14
    DW(数据仓库层) DWD层 (数据明细层) 负责数据的最细粒度的数据 经过了ODS层清洗(去空),去重,去燥,去除大于或者小于一定阈值的明细数据。 DWM层 (数据中间层) 在DWD层基础上,进行轻度汇总,结合常用...
  • 数据仓库设计规范文档

    千次阅读 2020-08-31 19:43:43
    总体来说,数仓划分为操作数据层、数据仓库层和数据集市层三部分 数据层次的划分 ODS:Operational Data Store,操作数据层,在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区,同时又...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,870
精华内容 1,548
关键字:

数据仓库层级划分