精华内容
下载资源
问答
  • 维度建模理论

    2021-02-22 22:34:17
    维度建模和关系建模 实体-关系建模是面向应用,遵循第三范式,以消除数据冗余为目标的设计技术。 维度建模是面向分析,为了提高查询性能可以增加数据冗余,反规范化的设计技术。 关系模型 -在关系型数据库使用,...

    维度建模和关系建模

    实体-关系建模是面向应用,遵循第三范式,以消除数据冗余为目标的设计技术。

    维度建模是面向分析,为了提高查询性能可以增加数据冗余,反规范化的设计技术。

    关系模型 - 在关系型数据库使用,适用于OLTP,应用第三范式,减少不于主键直接关联的字段,减少数据冗余。

    维度模型 - 在大数据中使用,适用OLAP,在大规模数据中,跨表分析统计查询过程会造成多表关联,这会大大降低执行效率

     

    维度建模

    按照事实表,维度表来构建数据仓库,数据集市。

    事实表:表中的每行数据代表一个业务事件(如下单、支付、退款、收藏、评价等)

    维度表:一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。例如:用户、商品、日期、地区等。

     

     

    星型模型:维度表和事实表直接关联。

    雪花模型:对星型模型的扩展,维表可以有子维表(存在维表不与事实表直接关联)

    理论:https://blog.csdn.net/weixin_30470643/article/details/98408175

     

     

     

     

     

    展开全文
  • 维度建模理论与数仓分层思想 维度建模 ODS 层因为保留原始数据, 所以和业务数据库 (关系模型) 一样是关系模型. DWD 层即进行了维度建模, 将下面的模型 ↓ 转化为了下面的维度模型, 即以事实表为中心, 周围有一圈的...

    维度建模理论与数仓分层思想

    维度建模

    ODS 层因为保留原始数据, 所以和业务数据库 (关系模型) 一样是关系模型.

    DWD 层即进行了维度建模, 将下面的模型 ↓

    关系模型

    转化为了下面的维度模型, 即以事实表为中心, 周围有一圈的维度表 ↓

    维度建模示意图

    维度模型中的表数据 (数据特征) 可能有冗余, 但查询时一般只需要进行事实表和维度表进行 join, 不用 join 太多表, 查询性能更好.

    在维度建模的基础上又分为三种模型:星型模型、雪花模型、星座模型。

    星型模型和雪花模型

    但生产中事实表不可能只有一张, 所以多个事实表多个维度表结合形成了星座模型:

    星座模型

    维度模型的好处

    • Understandability: 表结构简单, 分析人员更好理解事实与维度数据的表结构;
    • Performance: 减少 join, 提高查询性能;
    • 方便进行 OLAP 多维分析: 后续数仓中单纯的聚合值意义不大, 一般需要计算某些维度下的聚合值才有意义, 比如 select 维度 agg(事实) from table group by 维度.

    维度模型的扩展

    维度模型对数据关系的变化也具有很高的适应性. 当发生以下变化时, 不需要改变现存的 BI 查询或应用, 就可以方便地适应, 且查询结果不会有任何改变:

    • 新增的事实与存在的事实表粒度一致时, 可以创建新列;
    • 如果新增的维度表与事实表的粒度一致, 可以通过在事实表中建立新的外键列, 可以将新的维度关联到已经存在的事实表上.
    • 如果某维度表新增的维度列, 直接在维度表上建立新列即可;
    • 可以使事实表的粒度更原子化, 方法是在维度表上增加属性, 然后以更细的粒度重置事实表, 小心保存事实表及维度表的别名.

    星型模型与 OLAP

    如果, DW 采用了星型模式建模, 或 OLAP 建模, 都可以说是利用了维度的概念, 他们对维度的认识是一样的, 只是物理实现上不一样. OLAP 一般用于即席查询, 通常会进行与计算, 索引策略和其他的优化方法; 同时有很多比 SQL 更好的分析函数, 使得OLAP的查询和分析性能更好, 不需要提出新的查询.

    但是, 一般在 OLAP 之前, 我们还是会将详细的, 原子的信息加载到星型模型中, 然后由此建立 OLAP 分析模型.

    星型模型主要包含事实表, 以及通过主键/外键关系与之关联的维度表, 联机分析处理 ( OLAP) 多维数据库是实现在多维数据库之上的多维结构, 它与星型模型内容等价, 或者说来源于星型模型.

    OLAP 多维数据库也是包含维度属性和事实表, 但它能够使用比 SQL 语言具有更强的分析能力的语言访问, 比如 XMLA 和 MDX 等.

    OLAP 多维数据库通常是部署 DW/BI 的最后步骤, 或者作为基于多个原子关系型模式的聚集结构.

    事实表

    事实表

    事实表中的每行数据代表一个业务事件或业务度量, 比如下单, 支付, 退款, 评价等.

    事实表一般包含两部分字段:

    • 维度字段. 即与维表相连接的外键, 通常具有两个和两个以上的外键, 外键之间表示维表之间多对多的关系.
    • 度量值. 即具有可加性的数值型的度量值, 像可统计次数, 个数, 金额等. 例如, 订单事件中的下单金额.

    事实表的特征:

    • 非常的大;
    • 内容相对的窄: 列数较少;
    • 经常发生变化, 每天会新增加很多.

    业务过程度量事件转换到事实表中

    事实度量

    最终计算通常在 DW 的上层或 OLAP 多维数据库层.

    可加

    最主要是数值类型和可加类型:

    • 数值类型: 销售额
    • 可加类型: 销售量

    这些都可以按照某些维度, 比如时间维度进行聚合, 这是最关键的.

    半可加

    半可加度量可以对某些维度进行汇总, 但不能对所有维度进行汇总.

    比如, 差额是常见的半可加事实, 除了时间维度外, 他们可以跨所有维度进行加法操作.

    不可加

    比率是最常见的不可加度量.

    一般对于这种, 非可加度量一般拆解为其全完可加分量.

    粒度 - 事实表分类

    事实表中每行数据是一个特定级别的细节数据, 称为粒度. 同一张事实表的粒度相同, 不会出现重复计算度量的问题.

    事务型粒度 (最常见)

    最常见, 最典型的事实表. 它和上面介绍的事实表的基本描述是一样的.

    每个事务或事件为单位,例如一个销售订单记录,一笔支付记录等,作为事实表里的一行数据。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新。

    特点:

    • 数据写入这样的事实表中就不会再进行修改了.
    • 最多.
    • 数据维护: 不变.
    • 采集中的同步策略: 增量 (数据不会变, 每天增量分区表).

    无事实事实表

    有些可能没有可以记录的数字化事实, 比如:

    • 某一天学生参加课程的时间, 包含时间, 学生, 教师, 地点, 课程等维度, 但没有数字度量.
    • 客户交际也是一种事件, 也没有相关的维度.

    比如日志数据, 一般也可以转换成无事实事实表.

    周期型快照粒度

    周期型快照事实表中不会保留所有数据 (这句话是跟事务型事实表进行对比的),只保留固定时间间隔的数据,例如每天或者每月的销售额,或每月的账户余额, 或者加购物车事实表。

    比如加购物车事实表:

    最原子性的事件是加购物车和取消购物车, 但我们并不关注加减的过程或加了几次, 减了几次, 我们关注的是购物车中剩下的商品, 这些商品可能就是用户想买却舍不得买的商品, 这样我们就可以对其进行一个促销, 让大量用户进行购买, 这是我们关注的.

    而购物车中的商品每天都可能会有变化, 所以我们一般周期性地记录购物车中的数据.

    数仓中的具体实践是在 Hive 中建立日期为分区的购物车事实表, 然后 MySql 中的购物车表每天固定时间导入到 Hive 的当天日期分区中, 也就是每天打一个快照.

    特点:

    • 相对较少.
    • 数据维护: 不变.
    • 采集中的同步策略: 全量 (每天全量分区表).

    累积型快照粒度

    累计快照事实表用于跟踪业务事实的变化。例如,数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据, 来跟踪订单生命周期进展情况

    当这个业务过程进行时,事实表的记录也要不断更新。也就是一行数据没办法一次写完, 需要分多个阶段累计写完的, 每个阶段都是一个里程碑.

    订单id 用户id 下单时间 打包时间 发货时间 签收时间 订单金额
    3-8 3-8 3-9 3-10

    特点:

    • 最少.
    • 数据维护: 不像事务型事实表和周期型快照事实表, 累积型快照事实表每行数据是会改变的. 但 Hive 一般不对数据进行修改, 而是采用先 select 查询出来, 查询过程中进行判断, 看需不需要修改数据, 需要改的话进行修改, 修改之后, insert overwrite 回原表.
    • 采集中的同步策略: 新增及变化 (一般按照第一个里程碑时间建立分区表).

    维度表

    维度表: 一般是对事实的描述信息. 每一张维表对应现实世界中的一个对象或者概念. 例如: 用户, 商品, 日期, 地区等.

    数仓的好坏取决于维度的设置, 分析能力取决于维度的质量和深度.

    属性应该包含真实使用的词汇, 而不是令人感到迷惑的缩写, 尽量少使用代码, 而是使用文本.

    操作码

    有的操作码有确定的业务含义, 比如前两位表示业务类别, 3~4位表示区域, 与其用户查询过滤操作码, 不如前期就将操作码差分, 然后以不同维度展现给用户, 这样用户就能方便地展开过滤, 分组和制作报表等工作. 其实就是一个 ETL 的过程.

    在分析操作码时, 如何确定某些元素是维度还是事实?

    • 包含多个值并后续参与计算, 往往是事实属性;
    • 对具体指的描述, 是一个常量, 某一约束和行标识, 往往是维度属性.
    • 连续值是事实, 离散型的不太大的列表一般是维度. 价格由于经常变化, 可以认为是一种事实度量.

    维表的特征

    • 维表的范围很宽 (具有多个属性, 列比较多, 一般都是宽表 50 ~ 100 个), 比如将日期或者商品相关的字段全部放入一个表里;
    • 通常以层次关系表示.
    • 跟事实表相比, 行数相对较小: 通常 < 10万条;
    • 内容相对固定 (跟事实表对比): 像事实表, 比如订单表, 每下单一次就增加一行, 每天增加很多. 但维度表比如商品表, 即每天的商品表, 改变并不大, 因为每天商品基本一样, 不可能说每天上架大量的商品. 还有些编码表, 地区表和时间表等都不会变.
    • 同步策略: 除了某些特殊不变的维度表只在第一次初始化的时候全量同步一次, 其他的维度表一般来说每日全量同步. 注意: 像用户维度表使用的是拉链表, 这个需要注意一下, 还有拉链表是否需要分区等等, 待探讨.

    维度表举例 - 时间维度表

    日期ID day of week day of year 季度 节假日
    2020-01-01 2 1 1 元旦
    2020-01-02 3 2 1
    2020-01-03 4 3 1
    2020-01-04 5 4 1
    2020-01-05 6 5 1

    数据仓库各层建模

    ODS

    • 保持数据原貌不做任何修改,起到备份数据的作用.
    • 数据采用压缩 lzo (数据是 load 来的),减少磁盘存储空间(例如:原始数据100G,可以压缩到10G左右. 如果采用列式存储 (同样类型数据压缩到一起), 压缩效率会更高).
    • 创建分区表,防止后续的全表扫描.

    DWD

    ETL + 维度建模.

    ETL

    日志数据在 DWD 层按照内容解析, 分为 5 类, 解析成 5 张表: 页面, 曝光, 事件操作, 启动, 错误.

    这里用到自定义解析 json 的函数.

    维度建模

    DWD层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。

    维度建模一般按照以下四个步骤

    选择业务过程→声明粒度→确认维度→确认事实

    1 选择业务过程

    在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。

    尽可能全地选择业务, 以应对后续业务需求的变更.

    2 声明粒度

    数据粒度指数据仓库的数据表中保存数据的细化程度或综合程度的级别

    一张事实表需要确定一个表的粒度, 即声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最细粒度,以此来应各种各样的需求。

    为什么选择最细粒度? 我们从 DWD 层进行聚合时是从最小粒度开始聚合的, 最小粒度可以聚合为更粗的粒度, 但反之只有粗粒度是无法得到细粒度的. 所以有了最小粒度就意味着可以聚合得到各种粒度.

    典型的粒度声明如下:

    • Order Detail 中,每行数据对应一个订单中的一个 sku,Order Info 中,每行数据对应一个订单, 所以订单事实表最细粒度为一个订单中的一个 sku. 但我们实建模过程中并不是完全遵照这样的, 就比如对下单来说应该是按照 Order Detail 中的 sku 来声明最细粒度, 但是对于下单, 我们其实建立了两个事实表, 一个 Order Info 事实表按照一个订单来声明粒度, 一个 Order Detail 事实表按照一个订单中的一个 sku 声明粒度. 这样做的好处? 因为有些需求我们是没必要去最细粒度去查询聚合的, 通过粗粒度事实表反而更容易获取, 比如, 想统计今天订单金额的总和, 按照 Order Detail 粒度就是每个商品价格和数量相乘再相加, 这样 数据量和计算量大, 反而不如在 Order Info 中直接对每一个订单金额求和即可来得方便.
    • 比如支付事实表, 我们只有一张 Payment Info 表, 那么支付事实表的最细粒度就是这张表的每一行数据指代的内容: 一条支付记录.
    • 一般情况下, 如果一个业务事实只有一张表的话, 粒度也就被确认了, 没有其他选择.
    3 确定维度

    维度的主要作用是描述业务事实,主要表示的是 “谁,何处,何时” 等信息。

    实际上就是确定事实表中有哪些外键.

    一般就是先把所有维度列出来, 然后看每个事实表和哪些维度 (group by 的字段) 有关.

    4 确定事实

    此处的 “事实” 一词,指的是业务中的度量值,例如

    订单金额、下单次数, 单价, 折扣, 净支付价格等。

    在 DWD 层,以 业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

    粒度 时间 用户 地区 商品 优惠券 活动 编码 快递商 仓库 度量值
    订单 一条订单 件数/金额
    订单详情 订单中一件商品 件数/金额
    支付 一条支付记录 金额
    加购物车 一个购物车记录 件数/金额
    收藏 用户一次收藏 个数
    评价 一次评价 个数
    退款 一次款款记录 件数/金额
    优惠券领用 一个用户领一个券的记录 个数

    这些关系是比较灵活的, 但前提是能关联上的, 能关联上的尽量关联上.

    什么是能关联上? 一般关系模型的一张事实表中的维度外键是直接关联上的, 但还有一些是可以间接关联上的. 比如支付表和位置, 直接关联不上, 但支付和订单相关, 订单和位置相关, 这样就关联起来了.

    至此,数仓的维度建模已经完毕,DWS、DWT 和 ADS 和维度建模已经没有关系了。

    DWS 和 DWT 都是建宽表,宽表都是按照主题去建。主题相当于观察问题的角度。对应着维度表。

    DWS & DWT

    这两层是款表层.

    DWS

    统计各个主题对象的当天行为,服务于 DWT 层的主题宽表。

    DWS 层宽表

    DWT

    以分析的主题对象为建模驱动,基于上层的应用和产品的指标需求,构建主题对象的全量宽表。

    DWT 层主题宽表

    DWS 和 DWT 的作用

    DWS 和 DWT 都一定程度进行了聚合, 没有 DWS 和 DWT 层可以吗? 可以, 但是:

    • 有些聚合操作是重复的, 需要重复计算;
    • DWD 是明细数据, 都从这一层去查询, 数据量比较大.

    所以 DWS 和 DWT 层存在的意义就是减少数据重复计算, 提高数据的复用性, 优化数仓性能.

    举例, 有以下需求:

    1 统计今天每个省份订单的个数是多少?

    select province, count(*) from orderInfo group by province where dt = 'xxxx-xx-xx'
    

    2 统计今天每个省份下单的总金额是多少?

    select province, sum(amount) from orderInfo group by procince where dt = 'xxxx-xx-xx'
    

    这两个需求其实是类似的, 但如果从 DWD 来查询, 重复计算了两遍, 降低了效率.

    DWS 和 DWT 设计

    从上面来看, 对于相同维度的聚合, 我们可以进行一次计算, 所以, DWS 和 DWT 层宽表应该以:

    • 维度为基准 (宽表有哪些);
    • 所有与此维度相关的事实表中的度量值的聚合值为字段 (宽表有哪些字段).
    • 时间尺度不同:
      • DWS 为每个维度对象的当天的统计值;
      • DWT 为每个维度对象的累积值 (订单金额, 次数等…), 比如最近 7 天, 最近 15 天, 最近一个月, 从开始至今的累积值等.

    DWD 和宽表层的关系

    DWD 层进行了维度建模, 款表层只是我们为了优化数仓建的两层, 和维度建模没有任何的关系.

    DWD 进行维度建模时不是以需求为驱动的, 主要以维度建模思路和步骤驱动的; 款表层是由需求指标为驱动的.

    ADS

    对电商系统各大主题指标分别进行分析。

    对接数据仓库后续的应用, 比如 BI 报表, 用户画像, 机器学习等. 这些应用都需要数仓中的数据, 它们需要什么数据, 我们就在 ADS 层提供对应的数据.

    比如, BI 报表需要展示结果, 比如一个聚合值, 那我们就把这个聚合值放到 ADS 层以供 BI 查询即可, 比如日活, 月活, 留存用户, 新增用户等.

    比如, 机器学习需要大量的样例数据, 也可以放入 ADS 层;

    比用户画像需要用户大量的各种信息, 也可以放在 ADS 层.

    也就是说, 不同的应用, 在 ADS 层准备的数据是不同的.

    维度建模举例

    零售

    选择业务过程

    建模的业务过程是 POS 零售交易, 该数据保证商业用户能够分析被销售的产品, 他们是在哪几天, 在哪个商店, 处于何种促销环境中被销售的.

    声明粒度

    最细粒度是 POS 交易的每个单品, 假设 POS 系统按照一个购物车中某种产品.

    确定维度

    日期, 产品, 门店, 促销, 收银员, 支付方式

    确定事实

    销售数量, 单价, 折扣, 净支付价格;

    扩展折扣额;

    扩展销售额 = 销量 ✖️ 单价;

    扩展成本;

    扩展毛利润;

    零售模式中的可度量事实

    维度表

    日期维度表

    日期维度表

    样例报表

    产品维度

    产品维度示例行

    产品维度表

    按照维度属性下钻

    引用

    确定事实

    销售数量, 单价, 折扣, 净支付价格;

    扩展折扣额;

    扩展销售额 = 销量 ✖️ 单价;

    扩展成本;

    扩展毛利润;

    [外链图片转存中…(img-PXM3uxaq-1606195310738)]

    维度表

    日期维度表

    [外链图片转存中…(img-199gR92j-1606195310738)]

    [外链图片转存中…(img-p8VNuXAQ-1606195310739)]

    产品维度

    [外链图片转存中…(img-fF1sRQXp-1606195310740)]

    [外链图片转存中…(img-HZIF5K6e-1606195310740)]

    [外链图片转存中…(img-wekvGH3U-1606195310741)]

    引用

    Kimball - 数据仓库工具箱

    展开全文
  • 维度建模经典理论 维度建模是数据仓库建设中的一种数据建模方法,将数据结构化的逻辑设计方法,它将客观世界划分为度量和上下文,Kimball最先提出这一概念。 其最简单的描述就是,按照事实表,维度表来构建数据...

    维度建模经典理论

    维度建模是数据仓库建设中的一种数据建模方法,将数据结构化的逻辑设计方法,它将客观世界划分为度量和上下文,Kimball最先提出这一概念。

    其最简单的描述就是,按照事实表,维度表来构建数据仓库,数据集市。这种方法的最被人广泛知晓的名字就是星型模式。实体关系模型(E-R)建模通常用于为单位的所有进程创建一个复杂的模型。这种方法已被证实在创建高效的联机事务处理 (OLTP) 系统方面很有效。相反,维度建模针对零散的业务进程创建个别的模型。例如,销售信息可以创建为一个模型,库存可以创建为另一个模型,而客户帐户也可以创建为另一个模型。每个模型捕获事实数据表中的事实,以及那些事实在链接到事实数据表的维度表中的特性。由这些排列产生的架构称为星型模式或雪花模式,已被证实在数据仓库设计中很有效。

     

     

     

     

    图1:典型星型模型架构

     

    维度建模实践升级--OneModel体系

    经典维度建模的方法论为我们OneModel体系的构建提供了启发和基础,同时我们在数据中台的过程中,我们带着批判和产品化的思维,对该方法论根据基于海量数据实战经验的演进和升级,创造出了符合企业数据中台构建的OneModel方法论和产品化体系。

    · 规范定义

    经典数据仓库有很多关于数据模型的做法,其中不乏优美的数据模型设计,但模型设计前无数据规范定义,模型设计后不能确保开发严格按照模型设计进行,为非闭环的单点模型设计。

    在业界中常用数据字典文档的方式维护标准规范定义,数据字典是在数据以及开发完成之后,为了业务能够读懂而增加的数据整理和标识的工作,以字典方式呈现。其意义更多在于帮助用户理解已有数据的含义和算法,但此时数据已经产生,无法规避二义性等形成的数据使用困扰,且后期维护的人力成本颇高,难以为续。

    OneModel方法论保障了数据唯一性的数据域、业务过程,以及在数据域、业务过程之下的指标、实体属性等的结构性封装、命名和定义。

    数据规范定义是在开发之前,以业务的视角进行数据的统一和标准定义,确保计算口径一致、算法一致、命名一致,后续的数据模型设计和ETL开发都是在此基础上进行的。

     

     

     

     

    图2:OneModel规范定义

     

    · 设计即开发

    将割裂的数据规范定义、数据模型设计、ETL开发连接在一期,实现“设计即开发”。将数据规范定义从工具层面的数据命名+结构化抽象定义合二为一,并与数据模型设计连接,进而直接支撑ETL开发。当数据规范定义完成之后,每一个指标都可以根据结构化命名规则和计算逻辑快速映射到对应的物理表中。

     

     

     

     

    图3:OneModel方法论解决设计与开发脱节的示意图

     

    · 所建即所得

    只要某个指标能够被规范定义,针对该指标的代码即可自动化生成,而一系列经过规范定义的指标则会根据相同计算粒度,聚集到若干物理表或逻辑表中,这样形成的物理表或逻辑表,其全部代码和自动化生成。对于中间生成过程不必关心,因为这是系统内部的智能黑盒要以智能化的方式来解决的。并且智能黑盒不仅实现代码自动化生成,还关心优化生成代码及其任务调度所对应的计算逻辑。

    下图为智能黑盒解决开发人员只需要基于业务逻辑建模,通过智能黑盒能自动生成、优化代码:

     

     

     

     

    图4:智能黑盒逻辑框架

    下图为数据的使用从逻辑表到物理表的全面升级,使得数据的设计和使用都完全基于业务进行逻辑建模,加快了建设和使用的效率:

     

     

     

     

    图5:逻辑表vs.物理表

     

    · 产品化实现

    OneModel体系不仅有方法论,还有规范、工具型数据产品等,具体包括:规范化数据建模,特别关注数据规范定义、数据模型设计和ETL开发等全流程;落地和承载规范化数据建模的规范化研发工具;规范化建模产生的所有分层数据模型;所有数据在面对应用时都会被监控和调度,且对上线、下线调优监控会反馈到规范化数据建模中。

    这四大部分形成有机闭环。OneModel体系关键指导意义和执行点是规范化数据建模,即数据规范定义、数据模型设计和ETL开发。在ETL开发之前严格要求规范定义和数据模型设计,虽有借鉴和部分继承经典维度建模的做法,但不同于一般意义上的事后“数据字典”和单点“模型设计”。

     

     

     

     

    图6:云上数据中台产品Dataphin整体功能架构

     

    阿里巴巴数据中台团队,致力于输出阿里云数据智能的最佳实践,助力每个企业建设自己的数据中台,进而共同实现新时代下的智能商业!

    阿里巴巴数据中台解决方案,核心产品:

    · Dataphin,以阿里巴巴大数据核心方法论OneData为内核驱动,提供一站式数据构建与管理能力;

    · Quick BI,集阿里巴巴数据分析经验沉淀,提供一站式数据分析与展现能力;

    · Quick Audience,集阿里巴巴消费者洞察及营销经验,提供一站式人群圈选、洞察及营销投放能力,连接阿里巴巴商业,实现用户增长。

    欢迎志同道合者一起成长!

    展开全文
  • 和行业经验和业务流程息息相关,在建模范围内,确定实体有哪些,梳理实体间的关系 具体方法可以参照5W1H: who、what、when、where、why、how 结果:实体关系图(不需要添加实体的属性) 数据仓库逻辑设计 ...

    拆书稿-数据仓库结构设计与实施

    在这里插入图片描述

    本篇文章内容目录

    第一部分:数据仓库总体结构(原书第二章)

    1 金字塔结构
    2 元数据与模型
    3 映像
    4 数据仓库三要素
    5 多维总计方阵
    6 方阵和数据集市的区别

    第二部分:数据仓库设计与应用开发(原书第五章)

    数据仓库层次结构
    数据仓库概念设计
    数据仓库逻辑设计
    数据仓库物理设计

    正文开始

    第一部分:数据仓库总体结构(原书第二章)

    1 金字塔结构

    金字塔从底层向上,体现出强大的收敛与聚合功能,层面越高越能高度地概括更丰富、更有意义的信息;层面越低,数据体量越大,细节程度越高,信息越具体。每个层面相互依托又互相关联。
    在这里插入图片描述
    数据仓库的金字塔结构和层次1
    在这里插入图片描述
    数据仓库的金字塔结构和层次2
    在这里插入图片描述

    数据仓库结构生态图

    在这里插入图片描述
    其中上图中有一个概念叫:过渡区,它为什么存在?并且有什么存在的价值?
    ① 为什么存在?

    • 提前可以做数据预处理
      来自数据源的数据在到达数据仓库之前,需要经过一些中间处理过程,而ETL常常是批量执行,是一些通用任务,无法完成定制化个性统计需求。而在数据源到数据仓库中间建立过渡区,可以针对特定数据进行预处理。例如:过滤空值、过滤多余字段、进行数据类型转换等等。

    ② 存在的价值?

    • 第一、数据源和数据仓库进行隔离
    • 第二、过渡区可作为数据接收切面,接纳不同数据源,数据仓库只需要从过度区获取数据。架构清晰
    • 第三、过度区可以在数据允许的条件下提供数据支持,减少数据源数据提取的压力。
    2 元数据与模型

    分类:元数据主要有两种类型的模型

    • 数据模型
    • 应用模型

    元数据定义: 说明数据的数据。像数据库中的数据字典,或者数据表与表之间的关系。
    作用:用于描述从操作型系统到分析型系统的映射,描述数据源、数据更新、总计数据的算法和数据提取的频率。
    模型的建立流程: 概念模型 、逻辑模型、物理模型

    3 映像

    映像是一系列结构化处理过程,能够引导数据从一个或者多个源系统到达目标系统。在这一过程当中存在一系列必要的转换处理。
    映像包括:

    • 源定义
    • 目标定义
    • 转换定义

    在转换过程中就可以添加数据预处理,过滤多余数据项,也可以完成数据转换映射。
    个人理解:在此过程中,通过此元数据管理,可以做一部分的规范化处理。例如: 源表和目标表的格式规范化(统一格式:数据库模式名_表名),完成转换后输出的数据集命名规范,转换过程中数据集的分隔符规范等等。

    数据映像从数据源到目标
    在这里插入图片描述

    4 数据仓库三要素

    在这里插入图片描述

    5 多维总计方阵

    是从数据仓库的事实表和有关维表中通过汇总、运算处理产生出来的综合数据,从结构和形式上更接近于最终用户对管理决策支持分析的要求,是为用户提供的具有多维数据查询和分析能力的视图。
    在这里插入图片描述
    创建方阵是将综合信息带给用户的必经之路,通过预先费时的计算和链接操作而生成的完好方阵系列,而不是在联机执行时间临时处理。方阵的存在大大减少了访问时间和复杂性,也降低了成本。

    方阵的类型

    • 多维联机分析处理方阵
    • 虚拟方阵
    • 奠基石式方阵–基础方阵
    • 嵌入式方阵
    • 稀疏方阵
    6 方阵和数据集市的区别

    数据集市

    1. 数据集市是按照需求定制化建立的,代表的数据价值只局限于需求的边界范围内。
    2. 针对性较强,可能在市场,营销,账务等业务线的数据集市都是不同的。不可重用,没有灵活性。并且容易产生数据孤岛,数据价值表现的很局限。
    3. 数据集市的种类统计粒度可能不同,不利于数据分析

    从上面定义可知,数据集市的统计边界更小一点,可能只是针对某个业务线,某个部门。而方阵是基于整个数据仓库,通过整个数据仓库的相关表来进行统计汇总。

    第二部分:数据仓库设计与应用开发(原书第五章)

    数据仓库层次结构

    在这里插入图片描述

    数据仓库概念设计

    概念模型是建立模型的初始阶段,主要描述与业务有关的重要实体以及相互之间的关系。
    该阶段主要是确定系统建模的边界和范围。和行业经验和业务流程息息相关,在建模范围内,确定实体有哪些,梳理实体间的关系
    具体方法可以参照5W1H: who、what、when、where、why、how
    结果:实体关系图(不需要添加实体的属性)

    数据仓库逻辑设计

    梳理业务规则,对概念模型做进一步细化
    确定实体的详细属性,实体间关系以及是否存在关系约束

    数据仓库物理设计

    从性能、访问、开发等多个方面考虑,做系统的实现。
    该阶段完成:

    1. 类型长度的定义
    2. 字段的其他详细定义: 飞空,默认值
    3. 约束的定义: 主键,外键
    展开全文
  • 维度建模基本理论

    2021-01-22 11:53:05
    Kimball维度建模基本理论
  • 文相关基本理论摘录自《数据仓库工具箱–维度建模的完全指南-第二版》和《数据仓库声明周期工具箱》 维度建模介绍 维度建模是一种将数据结构化的逻辑设计方法,将客观世界划分为度量和上下文。机构的每一个业务过程...
  • 文章目录1 数仓分层1.1 基本分层模型1.2 数据集市和数据仓库2 数仓理论2.1 范式理论2.2 关系建模和维度建模2.2.1 关系建模2.2.2 维度建模2.2.2.1 维度建模的三种模型2.3 维度表和事实表2.3.1 维度表2.3.2 事实表 ...
  • 1.事实表 2.维度表 3.模型 4.粒度 5.层次
  • 数仓理论之关系建模与维度建模

    千次阅读 2019-04-26 20:37:42
    维度模型主要应用于OLAP系统中,因为关系模型虽然冗余少,但是在大规模数据,跨表分析统计查询过程中,会造成多表关联,这会大大降低执行效率。 所以把相关各种表整理成两种:事实表和维度表两种。所有维度表围绕着...
  • 对数据分析越来越深入,越来越发现...1. 维度建模理论概要 1.1 维度设计的主要流程 1.1.1 选择业务过程 业务过程是组织完成的操作性活动,例如:获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。...
  • 目前实际应用中,Kimball的维度建模理论在实践中使用得最为广泛,尤其在互联网行业,互联网和移动互联网行业业务变化快 系统变化快,相应的数据变化也快,数据模型经常需要修改和重构,Kimball 的方法可以迅速响应...
  • 数仓维度建模

    2020-09-13 22:28:07
    20世纪80年代末期,数据...Kimball提出了数据仓库的建模技术--维度建模(dimensional modelling),该方法是在实践观察的基础上开发的。虽然它不基于任何理论,但是在实践中却非常成功。维度建模被视为设计数据仓库和数据
  • 1. 维度建模理论概要 1.1 维度设计的主要流程 1.1.1 选择业务过程 业务过程是组织完成的操作性活动,例如:获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件建立或获取性能度量,并...
  • 下面的内容,是笔者在学习和工作中的一些总结,其中概念性的内容大多来自书中,实践性的内容大多来自自己的...因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。
  • 对于 Inmon 和 Kimball 两种建模方式可以长篇大论叙述,但理论是很枯燥的,尤其是晦涩难懂的文字,大家读完估计也不会收获太多,所以我根据自己的理解用通俗的语言提炼出最核心的概念。 范式建模 范式建模是数仓之父...
  • 数据仓库之维度建模

    2020-08-23 16:59:49
    概述 数据仓库包含的内容很多,它可以包括架构、建模和方法论。...因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。 文章结构 本文将按照下面的顺序进行阐述:
  • 维度建模之维度表

    2019-02-20 14:30:00
    1.数据仓库分层理论 1.1 CIF 层次架构 CIF 层次架构(信息工厂)通过分层将不同的建模方案引入到不同的层次中,CIF 将数据仓库分为四层,如图所示: ODS(Operational Data Store):操作数据存储层,往往是业务...
  • 维度建模基础理论 事实表 事实表保存了大量业务度量数据(即事实)的表。最有用的事实是数字类型、可加类型。 事实表以粒度化分:事务粒度事实表(细)、周期快照粒度事实表、累积快照粒度事实表(粗)。 ...
  • 三、维度建模维度建模的基础上又分为3种模型:星型模型,雪花模型,星座模型。 (1)星型模型 网络示例图片 标准的星型模型维度只有一层,而雪花模型可能会涉及多级,维度层级 是雪花模型与星型模型的主要区别。...
  • 维度建模以分析决策的需求为出发点构建模型,一般有较好的大规模复杂查询的响应性能,更直接面向业务,典型的代表是我们比较熟知的星形模型,常用就是事实表关联很多维度表、退化维度形成宽表、根据某主题下的业务...
  • 报表自动化: 没有压力的维度建模​www.coologic.cn前面《报表自动化: 打开数据仓库的大门》提到了数仓分为了多个层次,其中 DW 层有多种建模方式,本文主要讲 维度建模 的方法,当然相关理论文章很多很多了,这篇...
  • 一、关系建模——三范式理论 三范式是基于关系建模的术语,主要应用于OLTP,避免数据冗余,让每个数据只出现一次 第一范式:属性不可切分,指一张表的所有属性不可再往下细分 非主属性对码,存在部分函数依赖 ...
  • 数仓维度建模系列-数仓规范篇

    万次阅读 2020-11-26 10:14:23
    上一篇介绍了维度建模体系的搭建,这次来分享下搭建数据仓库涉及的各种规范。 分享我工作中遇到的一个小案例: 小A:我发现XXX这个历史累计指标既可以从服务端出,又可以从日志出,这2份数据源貌似有差异 小B:是...
  • 维度建模出自Ralph Kimall的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling》(《数据仓库工具箱》)一书,是十分流行的数仓建模理论维度建模从根本上来讲是以结果为导向的,由数据消费...
  • 20世纪80年代末期,数据...Kimball提出了数据仓库的建模技术–维度建模(dimensional modelling),该方法是在实践观察的基础上开发的。虽然它不基于任何理论,但是在实践中却非常成功。维度建模被视为设计数据仓库和数据.
  • 前面《报表自动化: 打开数据仓库的大门》提到了数仓分为了多个层次,其中 DW 层有多种建模方式,本文主要讲 维度建模 的方法,当然相关理论文章很多很多了,这篇文章主要是为了串一下流程,并不会详细的展开每一步的...
  • 数仓建模首推书籍《数据仓库工具箱:维度建模权威指南》,本篇文章参考此书而作。 文章首发公众号:五分钟学大数据,公众号中发送“维度建模”即可获取此书籍第三版电子书 先来介绍下此书,此书是基于作者 60 多年...
  • 数据仓库、商业智能及维度建模初步 了解数据仓库的技术 实践课的三部分 商业的数据仓库 SQL server 微软的产品(使用) 开源的架构 hadoop上数据仓库的产品(hive) 云数据仓库 DW产品 作业等 大作业 查询语句的...

空空如也

空空如也

1 2 3 4 5 ... 12
收藏数 230
精华内容 92
关键字:

维度建模理论