数仓

刘超 2天前 ⋅ 4697 阅读   编辑

  数据仓库之父Bill Inmon

一、ETL

二、数仓概述

  1、数仓介绍

  2、数仓基本概念

  3、维度建模

  4、事实表

    a、基本概念
    b、常见事实表

  5、缓慢渐变维度

  4、数仓问题点
    离线数仓
    实时数仓

  5、实时数仓/离线数仓

    离线数仓hive

    a、hive拉链

    实时数仓

     a、flink + kudu

  6、数据湖
    a、Delta
    b、

  7、数据格式

    a、orc
    b、parquet

三、数仓场景

  1、历史数据变更
  2、数据晚到
  3、补录数据
    a、
业务要修改事实

 

四、辅助(外围)系统

  1、数据知产系统

  2、元数据系统

  3、数据质量系统(DQC)

  4、任务调度系统(airflow、oozie、azkaban)
    oozie最大问题就是容易产生死锁

  5、etl配置系统(数据清洗)

  6、数据补录系统

  7、数据生命周期系统

  8、安全管理系统

五、数仓开发规范

  1、表规范
    1.1、建议表按年、月、周、天分区,有如下原因
    a、一般我们会将表按day分区,但我们一般会有周报、月报、日报,如果表能按年、月、日分区能减少union操作。当然还可能有range区间跨度的任务,如果表是orc格式,当为表新增字段时,可能报错,需要特殊处理(类似Spark操作orc格式的带day的hive表问题这种问题)也可以通过hdfs、spark模糊匹配(glob语法)来实现range跨度的数据加载

  2、补录场景
    a、建议别选择orc作为数仓数据存储类型,因为我们使用的orc,在补数据时或者读取range(我们有day、week、month、range四种时间跨度的任务)数据时,经常碰到某天之前没有某字段,之后有某字段,然后导致任务失败(类似spark访问hive报cannot resolve '`advIndustry`' given input columns这种问题)

  3、  数据质量系统
    a、建议任务增加字段长度检测逻辑,避免字段长度超限导致报错,同时在数据质量系统增加字段长度检查规则,当字段长度超限,体现到看板中,让业务方看到异常数据,让他们去确认,如果数据是有效的,修改代码,重跑任务。同时完善元数据系统(能够获得不同存储介质中的数据的元数据(比如字段长度等),为表创建、数据质量提供依据)

六、数仓实战

  1、电信数仓需求及实现

    1) 目的需求和目标分析

    2) 系统结构和模型设计

    3) 系统装载、数据挖掘和界面设计

七、产品化与服务化

  1、数据产品化
  - 面向管理层的宏观经营分析系统
  - 面向运营人员的业务监控系统
  - 面向广告以及营销的一体化数据营销平台

  其中营销平台涉及用户圈存+用户触达+日志回流+效果分析(实验组+对照组)

  2、数据服务化
  - 数据以接口方式直接服务于线上业务
  - 数据以共享平台方式提供基础标签服务


注意:本文归作者所有,未经作者允许,不得转载

全部评论: 0

    我有话说: