数据仓库设计_数据仓库设计实例 - CSDN
精华内容
参与话题
  • 1.为什么要设计数据分层? * 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务。 * 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得。 * 各种重复计算,严重...

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

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


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

    数据仓库数据流

     

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

     

    杂乱的数据流

     

    4.怎样分层

     

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


    1. ODS 全称是 Operational Data Store,操作数据存储

    “面向主题的”,数据运营层,也叫ODS层,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的 ETL 之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。
    但是,这一层面的数据却不等同于原始数据。在源数据装入这一层时,要进行诸如去噪(例如有一条数据中人的年龄是 300 岁,这种属于异常数据,就需要提前做一些处理)、去重(例如在个人资料表中,同一 ID 却有两条重复数据,在接入的时候需要做一步去重)、字段命名规范等一系列操作。

    2. 数据仓库层(DW),是数据仓库的主体

    在这里,从 ODS 层中获得的数据按照主题建立各种数据模型。这一层和维度建模会有比较深的联系。

    3. 数据产品层(APP),这一层是提供为数据产品使用的结果数据

    在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、Mysql 等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。
    比如我们经常说的报表数据,或者说那种大宽表,一般就放在这里。

     

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

    1. 数据来源层--> ODS层

    这里其实就是我们现在大数据技术发挥作用的一个主要战场。 我们的数据主要会有两个大的来源:
    a - 业务库,这里经常会使用 Sqoop 来抽取,比如我们每天定时抽取一次。在实时方面,可以考虑用 Canal 监听 Mysql 的 Binlog,实时接入即可。
    b - 埋点日志,线上系统会打入各种日志,这些日志一般以文件的形式保存,我们可以选择用 Flume 定时抽取,也可以用用 Spark Streaming 或者 Storm 来实时接入,
    当然,Kafka 也会是一个关键的角色。其它数据源会比较多样性,这和具体的业务相关,不再赘述。

     

     

    注意:在这层,理应不是简单的数据接入,而是要考虑一定的数据清洗,比如异常字段的处理、字段命名规范化、时间字段的统一等,

    一般这些很容易会被忽略,但是却至关重要。特别是后期我们做各种特征自动生成的时候,会十分有用。后续会有文章来分享。

    2. ODS、DW --> App层

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

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

     

    三、简单例子介绍:

    下面共5层:这里可以选择性的不加缓冲层、轻度汇总层

     

     

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


    ---- 明细层(ODS/DWD, Operational Data Store, DWD: data warehouse detail)
    -*- 概念:是数据仓库的细节数据层,是对STAGE层数据进行沉淀,减少了抽取的复杂性,同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式,将各个专业数据进行集中,明细层跟stage层的粒度一致,属于分析的公共资源
    -*- 数据生成方式:部分数据直接来自kafka,部分数据为接口层数据与历史数据合成。
    -*- 讨论方案: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/DW,data market或DWS, data warehouse service)
    -*- 概念:又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
    -*- 数据生成方式:由轻度汇总层和明细层数据计算生成。
    -*- 日志存储方式:使用impala内表,parquet文件格式。
    -*- 日志删除方式:长久存储。
    -*- 表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    -*- 库与表命名。库名:dm,表名:初步考虑格式为:dm_日期_业务表名,待定。
    -*- 旧数据更新方式:直接覆盖

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

     

    四、优化方案:

    前面提到的一种设计其实相对来讲已经很详细了,但是可能层次会有一点多,而且在区分一张表到底该存放在什么位置的时候可能还有不小的疑惑。
    我们在这一章里再设计一套数据仓库的分层,同时在前面的基础上加上维表和一些临时表的考虑,来让我们的方案更优雅一些。
    下图,做了一些小的改动,我们去掉了上一节的Buffer层,把数据集市层和轻度汇总层放在同一个层级上,同时独立出来了维表和临时表。

     

     

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

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

    展开全文
  • 数据仓库设计

    千次阅读 2019-03-28 14:11:41
    数据仓库简介:有些人不理解数据仓库,认为数据仓库就是获取数据,只要会使用hadoop、spark等大数据工具就懂数据仓库,这样的认识太片面。如果要从海量数据中总结出一个报表或者是多个报表,大数据工程师足以;如果...

    数据仓库简介:有些人不理解数据仓库,认为数据仓库就是获取数据,只要会使用hadoop、spark等大数据工具就懂数据仓库,这样的认识太片面。如果要从海量数据中总结出一个报表或者是多个报表,大数据工程师足以;如果在有限的资源动态的数据情况下,向前可历史追溯,向后对不断增加的报表实现兼容,这就需要一套科学的数据管理方法。数据仓库是一门数据管理的科学,数据仓库的核心就是计算、存储和维护之间的博弈。

    标准的数据仓库分层:sd(源数据层),ods(中间存储层),dw(多维数据层),dm(数据集市层),app(应用层)

    源数据层:源数据一般具有多来源、多类型特征,可能使用多种数据库,甚至是非结构化数据,是数据仓库中数据最复杂的一层,需要工程师对多种数据库多种数据类型都有一定了解。

    中间存储层:中间层数据和源数据基本保持一致,保存着最细粒度的数据。中间层可以说是数据仓库最重要的一层,是所有后期分析的数据基础。中间存储层一般存放所有的明细数据,具有数据量大,查询计算较慢的特点。

    多维数据层:多维数据层是经过清洗的,有价值的数据。多维数据层是在存储层的基础上清洗脏数据、删选有价值数据,并且对存储层的事实维度表进行事实维度分离。与中间存储层相比,多维数据层与存储层有着相同的数据粒度,但是具有更小的数据量、更快的查询速度。

    数据集市层:它是面向主题轻度汇总的数据,在某主题的最细粒度数据,能满足该主题所有需求。数据集市是按照某一主题汇总,既可以由多维数据层汇总,也可是其他集市表进一步汇总,通常是星状、雪花状数据和网状模型。数据集市层主题明确,极大减少使用方理解及使用成本

    应用层:这一层就是大家看到的各种报表,一般都是在数据集市基础上按照各种特定维度汇总的结果。应用层是面向用户的,数据具有极快的响应速度。

     数据仓库设计步骤
    1、确定主题

    主题与业务密切相关,所以设计数仓之前应当充分了解业务有哪些方面的需求,据此确定主题

    2、确定量度

    在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。量度是要统计的指标,必须事先选 
    择恰当,基于不同的量度将直接产生不同的决策结果。

    3、确定数据粒度

    考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。例如如果知道某些数据细分到天就好了,那么设置其粒度到天;但是如果不确定的话,就将粒度设置为最小,即毫秒级别的。

    4、确定维度

    设计各个维度的主键、层次、层级,尽量减少冗余。

    5、创建事实表

    事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。

    参考:https://blog.csdn.net/trigl/article/details/68944434

    https://blog.csdn.net/xiaolang85/article/details/52104839

    展开全文
  • (注意:本文介绍的是数据仓库设计的Kimball方法,即多维模型;关系模型,即Inmon方法参见(四)) 1. OLAP(联机分析处理)与OLTP(联机事务处理)主要区别 用户和系统的面向性:OLTP面向事务,日常操作;OLAP...

    注意:本文介绍的是数据仓库设计的Kimball方法,即多维模型;关系模型,即Inmon方法参见(四)

    1. OLAP(联机分析处理)与OLTP(联机事务处理)主要区别

    用户和系统的面向性:OLTP面向事务,日常操作;OLAP面向分析,用于决策支持。

    数据内容:OLTP当前数据;OLAP历史数据

    数据库设计:OLTP使用ER图、面向应用;OLAP使用星形模式或雪花,面向主题。

    视图:OLTP是详细的,一般的关系;OLTP汇总的,多维的。

    访问模式:OLTP读写操作都有,需要并行控制和恢复机制;OLAP多为读

    2. 多维数据模型

    数据仓库和OLAP基于多维数据模型。此模型用数据方表示数据。

    方体:数据汇总。方体是数据,方体的维度即各个维表,方体的值即事实表的度量;星型图则是事实表与维表的组织结构,与数据无关。数据仓库是面向主题的,主题用事实表表示

    方体的:根据不同的汇总级别或维的不同子集,构造方体的格。

    数据方:方体的格即为一个数据方。数据方由维和度量组成。

    原语:立方体定义 (事实表):

    define cube <cube_name> [<dimension_list>]:<measure_list>
    维定义 ( 维表):
    define dimension <dimension_name> as (<attribute_or_subdimension_list>)

    2.1 度量

    度量可以根据所用得聚集函数类型分为三类。

    分布的:一个聚集函数是分布的,如果它能用如下分布方式进行计算:设数据划分为n个集合,将函数用于每个划分,得到n个聚集值;再将函数用于前述n个聚集值得到的结果与将函数用于整个数据集(不划分)得到的结果一样,则该函数可以用分布方式计算。一个度量是分布的,如果它可以用分布聚集函数得到。如count(),sum(),min(),max()都是分布聚集函数。

    代数的:一个聚集函数是代数的,如果它能够用具有M个参数的代数函数计算(其中M是有界正整数),而每个参数都可以用一个分布聚集函数求得。一个度量是代数的,如果它可以用代数聚集函数得到。如avg(),min_N(),max_N(),standard_deviation()都是代数聚集函数。

    整体的:一个聚集函数是整体的,如果描述它的子聚集所需的存储没有常数界。即不存在一个有M个参数的代数函数进行这一计算(其中M是常数)。如median(),mode(),rank()都是。

    2.2 概念分层

    一般是对于维的概念分层。概念分层为数据库模式中属性的全序或偏序称作模式分层。概念分层可用于OLAP中上卷和下钻。OLAP上卷操作通过沿一个维的概念分层向上攀升或者通过维规约(即,一个或多个维从给定的立方体中删除),对数据立方体进行聚集。

    3. 多维数据库模式

    多维数据模型可以以星形模式、雪花模式、事实星座模式形式存在。

    星形模式:(1)一个大的、包含大批数据、不含冗余的中心表(事实表);(2)一组小的附属表(维表),每维一个。

    雪花模式:雪花模式是星型模式的变种,其中某些维表是规范化的,因而把数据进一步分解到附加的表中。雪花模式比星形模式的维表更规范,这样减少了冗余,但是可能需要更多的join操作,性能降低。数据仓库设计中,星形模式更多。

    事实星座模式(星系模式):多个事实表共享维表。

    4. 数据仓库设计

    须考虑的四种视图:
    -自顶向下视图:选择数据仓库所需的有关信息
    -数据源视图:揭示被操作数据库系统捕获、存储、和管理的信息
    -数据仓库视图:包括事实表和维表
    -商务查询视图:从最终用户的角度透视数据仓库中的数据

    典型的数据仓库设计过程
    -选取待建模的商务处理, 例如, 订单, 发票, 库存等.
    -选取商务处理的粒度, 例如,单个事务、一天的快照等 
    -选取用于每个事实表记录的, 如,时间、商品、顾客、供应商、仓库、事务类型和状态 等
    -选取将安放在事实表中的度量.  典型的度量是可加的数值量, 如dollars_sold和units_sold 

    5 数据仓库设计步骤[2]

    数据仓库系统的原始需求一般并不明确,且不断变化和增加,因此,采用原型法来进行数据仓库开发是比较合适的,原型法的思想是:从构建系统的简单的基本框架入手,不断丰富和完善整个系统。但是,数据仓库设计开发又不同于一般意义上的原型法,因为数据仓库的设计时数据驱动的。

    虽然数据仓库开发是一个迭代过程,如(三)中所述CLDS(SDLC,系统开发生命周期的相反方法),但是数据仓库的设计并不是没有步骤可言的,大体上分为:

    • 概念模型设计;
    • 技术准备工作;
    • 逻辑模型设计;
    • 物理模型设计;
    • 数据仓库生成;
    • 数据仓库运行与维护。

    5.1 概念模型设计

    概念模型最常用的是E-R法(实体-联系法,Inmon支持这种方法),使用E-R图作为描述工具。另一种方法是Kimball支持的多维模型。

    此步骤主要完成的工作是:(1)界定系统边界;(2)确定主要的主题域及其内容。

    例如,商场的边界可以界定为包含销售子系统、采购子系统、库存子系统在内的集合。在此基础上,确定三个基本主题:顾客、供应商、商品。

    5.2 技术准备工作

    本阶段工作:技术评估,技术环境准备。

    成果:技术评估报告,软硬件配置方案,系统(软硬件)总体设计方案。

    5.3 逻辑模型设计

    目前数据仓库一般建立在关系数据库基础之上,因此,在数据仓库的设计中采用的逻辑模型为关系模型。

    关系模型的基本概念:

    • 关系:一个二维表;
    • 元组:表中的一行称为一个元组;
    • 属性:表中的一列称为属性,列名即属性名;
    • 主码:表中的某个属性组,它们的值唯一的标识一个元组;
    • 域:属性的取值范围;
    • 分量:元组中的一个属性组;
    • 关系模式:对关系的描述,用关系名(属性名1,属性名2,……,属性名n)表示。

    数据仓库的逻辑模型描述了数据仓库的主题的逻辑实现,即每个主题所对应的关系表的关系模式的定义。

    本阶段主要工作:(1)粒度层次划分;(2)数据分割策略;(3)记录系统定义;(4)关系模式定义。

    5.4 物理模型设计

    主要工作:(1)确定存储结构;(2)确定索引结构;(3)确定存放位置;(4)确定存储分配。

    5.5 数据仓库生成

    主要工作:(1)设计接口;(2)数据装入。

    接口是指将操作性环境下的数据装载进入数据仓库环境,需要在两个不同环境的记录系统之间建立一个接口。

    5.6 数据仓库运行与维护

    包括:(1)建立DSS应用;(2)理解需求,改善和完善系统,维护数据仓库。

    DSS应用开发的步骤:确定所需的数据、编程抽取数据、合并数据、分析数据、回答问题、例行化。


    参考文献:

    [1]数据挖掘:概念与技术

    [2]《数据仓库技术与联机分析处理》

    展开全文
  • 数据仓库的四个层次设计

    千次阅读 2019-06-04 16:05:03
    数据仓库数据仓库全面接收源系统数据,ETL进程对数据进行规范化、验证、清洗,并最终装载进入数据集市,通过数据集市支持系统进行数据查询、分析,整个数据仓库包含四大层次。 1.数据仓库的四个操作    ...

            数据仓库:数据仓库全面接收源系统数据,ETL进程对数据进行规范化、验证、清洗,并最终装载进入数据集市,通过数据集市支持系统进行数据查询、分析,整个数据仓库包含四大层次。

    1.数据仓库的四个操作

           ETL(extractiontransformation loading)负责将分散的、异构数据源中的数据抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中。ETL 是实施数据仓库的核心和灵魂,ETL规则的设计和实施约占整个数据仓库搭建工作量的 60%~80%.
          1.数据抽取(extraction)包括初始化数据装载和数据刷新:初始化数据装载主要关注的是如何建立维表、事实表,并把相应的数据放到这些数据表中;而数据刷新关注的是当源数据发生变化时如何对数据仓库中的相应数据进行追加和更新等维护(比如可以创建定时任务,或者触发器的形式进行数据的定时刷新)。

          2. 数据清洗主要是针对源数据库中出现的二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行统一的处理。即清洗掉不符合业务或者没用的的数据。比如通过编写hive或者MR清洗字段中长度不符合要求的数据。

          3.数据转换(transformation)主要是为了将数据清洗后的数据转换成数据仓库所需要的数据:来源于不同源系统的同一数据字段的数据字典或者数据格式可能不一样(比如A表中叫id,B表中叫ids),在数据仓库中需要给它们提供统一的数据字典和格式,对数据内容进行归一化;另一方面,数据仓库所需要的某些字段的内容可能是源系统所不具备的,而是需要根据源系统中多个字段的内容共同确定。

        4. 数据加载(loading)是将最后上面处理完的数据导入到对应的存储空间里(mysql等)以方便给数据集市提供,进而可视化。

         一般大公司为了数据安全和操作方便,都是自己封装的数据平台和任务调度平台,底层封装了大数据集群比如hadoop集群,spark集群,sqoop,hive,zookeepr,hbase等只提供web界面,并且对于不同员工加以不同权限,然后对集群进行不同的操作和调用。以数据仓库为例,将数据仓库分为逻辑上的几个层次。这样对于不同层次的数据操作,创建不同层次的任务,可以放到不同层次的任务流中进行执行(大公司一个集群通常每天的定时任务有几千个等待执行,甚至上万个,所以划分不同层次的任务流,不同层次的任务放到对应的任务流中进行执行,会更加方便管理和维护)。

    2.数据仓库的四个逻辑架构层次

           数据仓库标准上可以分为四层。但是注意这种划分和命名不是唯一的,一般数仓都是四层,但是不同公司可能叫法不同。比如这里的临时层叫复制层SSA,京东则叫BDM。同样阿里巴巴却是五层数仓结构,更加详细,但是核心的理念都是从四层数据模型而来。如下分别展示京东和阿里巴巴数仓的架构层次和命名。

    1. 复制层(SSA,system-of-records-staging-area)

          SSA 直接复制源系统(比如从mysql中读取所有数据导入到hive中的同结构表中,不做处理)的数据,尽量保持业务数据的原貌;与源系统数据唯一不同的是,SSA 中的数据在源系统数据的基础上加入了时间戳的信息,形成了多个版本的历史数据信息。

    2. 原子层(SOR,system-of-record)

         SOR 是基于模型开发的一套符合 3NF 范式规则的表结构,它存储了数据仓库内最细层次的数据,并按照不同的主题域对数据分类存储;比如高校数据统计服务平台根据目前部分需求将全校数据在 SOR 层中按人事、学生、教学、科研四大主题存储;SOR 是整个数据仓库的核心和基础,在设计过程中应具有足够的灵活性,以能应对添加更多的数据源、支持更多的分析需求,同时能够支持进一步的升级和更新.

    3 .汇总层(SMA,summary-area)

        SMA 是 SOR和DM(集市层) 的中间过渡,由于 SOR 是高度规范化数据,此要完成一个查询需要大量的关联工作,同时DM 中的数据粒度往往要比 SOR 高很多,对要生DM 中的汇总数据需要进行大量的汇总工作,此,SMA 根据需求把 SOR 数据进行适度的反范(例如,设计宽表结构将人员信息、干部信息等多表的数据合并起来)和汇总(例如,一些常用的头汇总、机构汇总等);从而提高数据仓库查询性能。

    4.集市层/展现层(DM, data mart)

        DM 保存的数据供用户直接访问的:可以将 DM 理解成最终用户接最终想要看的数据;DM 主要是各类粒度的事数据,通过提供不同粒度的数据,适应不同的数访问需求;高校数据统计服务平台 DM 中的数据

        

     

    展开全文
  • 数据仓库主题设计及元数据设计

    万次阅读 2016-04-15 15:06:29
    数据仓库主题设计及元数据设计
  • 数据仓库设计流程图

    2020-01-11 16:22:46
  • 数据仓库架构设计的一点概念

    千次阅读 2018-05-28 09:31:33
    1、数据仓库所处环节 在一个成体系、结构化的数据应用场景下,数据和处理有四个层次: 操作层、数据仓库层、部门/数据集市层、个体层。 (1) 操作层是指为具体业务提供实时响应的各个业务系统,比如常见的订单...
  • 数据仓库架构及模型设计基础

    千次阅读 2019-06-26 21:58:18
    注:本文所有内容摘自《Hadoop构建数据仓库实践》 1.数仓架构 1.1数据集市架构 数据集市是按主题域组织的数据集合,用于支持部门级的决策。有两种类型的数据集市:独立数据集市和从属数据集市。 独立数据集市集中...
  • 数据仓库多维数据模型设计

    万次阅读 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...
  • 数据仓库设计思路

    千次阅读 2012-07-11 22:35:12
    数据仓库一些设计思路和总结 1、数据仓库模型设计分为概念模型、逻辑模型和物理模型;数据仓库建模方法:实体关系模型、维度建模。数据仓库逻辑模型设计:确定主题域->粒度层次划分->确定数据分割策略->关系模式...
  • 最近终于涉足数据挖掘领域,负责公司的数据挖掘任务,目前是一个人,意识不到这...如果你没有实施过数据仓库,那么从设定目标到给出设计,从创建数据结构到编写数据分析程序,再到面对挑剔的用户的评估,整个过程都会带
  • 数据仓库设计规范

    千次阅读 2018-12-19 11:41:34
    名词 名词简称 名词解释 Data Warehouse DW 数据仓库主体 Operational Data Store ODS 数据原始接入层,需要对数据频繁的... 数据源的细节层,有的也称为ODS层,是业务层与数据仓库的隔离层...
  • 数据仓库设计的七个步骤

    千次阅读 2007-05-21 21:43:00
    在处理一个数据仓库项目时需要注意的问题很多,但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维,不断尝试新的途径,对于找到一种可行的数据仓库实现方法来说也是必需的。 1. 配备一个全职的项目...
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
  • 干货:一文读懂数据仓库设计方案

    千次阅读 2019-11-14 12:10:00
    原文:https://www.cnblogs.com/skyell/p/11005666.html 作者:Skyell 转载原因:发现好多人对数据仓库理解的还不够透彻...
  • 数据仓库的架构与设计

    万次阅读 多人点赞 2017-04-01 17:52:19
    公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个简陋的数据仓库,这里记录一下数据仓库的一些知识。涉及的主要内容有: 什么是数据仓库数据仓库的架构 数据...
  • 数据仓库设计的21条原则

    千次阅读 2007-04-26 08:39:00
    使用Aosu易博通,一分钱不花,实现网文自动摘抄, 博客写作方便又快捷,和您现在看到的一样 !自主嵌入Google广告,还能赚取
  • 数据仓库设计的思考

    2011-06-15 17:25:00
    讲到数据仓库,很多人就会想到首先按照行业规范和客户需求调研、做源系统数据分析,然后设计主题,最后设计应用所需的事实表、维表;结构上基本分为三层:ODS-DW-DM。从理论的角度来看,数据仓库就是数据驱动的、...
  • Hive开发要知道数据仓库的四个层次设计

    万次阅读 多人点赞 2018-02-12 18:11:09
    数据仓库数据仓库全面接收源系统数据,ETL进程对数据进行规范化、验证、清洗,并最终装载进入数据集市,通过数据集市支持系统进行数据查询、分析,整个数据仓库包含四大层次。 1.数据仓库的四个操作  ETL...
  • 一、从数据流的逻辑上来讲,数据可以分为ODS层(原始日志数据),DW层(数据仓库),BN(统计结果数据) Spark/SparkStreaming任务加载原始日志(离线处理flume落地到hadoop集群的hdfs或实时消费kafka数据)提取...
1 2 3 4 5 ... 20
收藏数 123,757
精华内容 49,502
关键字:

数据仓库设计