大数据数仓

数仓建模方案，数据模型，维度建模，数仓，全称就是数据仓库，是一个面向主题，集成的，相对稳定的，反映历史变化的数据集合，通常用于支持管理决策。

大数据数仓

• 基本概念
  • 数仓
    • 面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理决策。
    • 面向主题
      • 在较高层次上将企业信息系统的数据综合归并进行分析利用的抽象的概念。每个主题基本上对应一个相应的分析领域。
    • 集成的
      • 企业级数据，同时数据要保持一致性、完整性、有效性、精确性
    • 稳定的
      • 从某个时间段来看是保持不变的，没有更新操作、删除操作，以查询分析为主
    • 变化的
      • 反应历史变化
  • 类型
    • 面向业务的数据库常称作OLTP，面向分析的数据仓库亦称为OLAP
• 基本理论
  • 目标
    • 访问性能：能够快速查询所需的数据，减少数据l/O
    • 数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的存储成本和计算成本
    • 使用效率：改善用户应用体验，提高使用数据的效率
    • 数据质量：改善傲据统计口径的不一致性减少数据计算错误的可能性，提供高质量的、一致的数据访问平台
  • 关系模式范式
    • 关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性和数据的一致性，目前业界范式有：
    • 第一范式（1NF）
      • 域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项
    • 第二范式（2NF）
      • 在1NF的基础上，实体的属性完全依赖于主关键字，不能存在仅依赖主关键字一部分的属性
    • 第三范式（3NF）
      • 在2NF的基础上，任何非主属性不依赖于其它非主属性
    • 巴斯-科德范式（BCNF）
    • 第四范式（4NF）
    • 第五范式（5NF）
  • ER实体模型
    • 在信息系统中，将事物抽象为实体、属性、关系来表示数据关联和事物描述；
    • 实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非效据库的实体表
    • 属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等
    • 关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。
    • 实体之间建立关系
      • 1:1
      • 1：n
      • n：m
    • 应用场景
      • ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式
      • Bill lnom提出的数仓理论，推荐用ER关系模型进行建模
      • BI架构提出分层架构，数仓底层ODS、DWD也多采用ER关系模
  • 维度建模
    • Ralph Kimball推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。
    • 事实表
      • 在ER模型中抽象出了有实体、关系、属种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。
    • 维度表
      • 看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等较比比较手机性能
      • 维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度
      • 区域维度
      • 时间维度
    • 类型
      • 星型模型
        • 一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率
      • 雪花模型
        • 维度表的涉及更加规范，一般符合3NF
      • 模型对比
        • 冗余：雪花模型符合业务逻辑设计，采用3NF设，有效降低数据冗余；星型模型的维度表设不符合3NF反规范化，度表之间不会直接相关，牺牲部分存储空间
        • 性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高
        • ETL：雪花模型符合业务ER模型设计原则，在ETL过程中相对简单，但是由于附属模型的限制，ETL任务并行化较低；星型模型在设计维度表时反范式设计，所以在ETL过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理
    • 维度设计
      • 代理键
        • 自增的方式
      • 缓慢渐变维
    • 事实表设计
      • 明细事实表
      • 聚合事实表
  • dataVault模
    • 中心表Hub:唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合
    • 链接表Link:表示中心表之间的关系，通过链接表串联整个企业的业务关联关系
    • 卫星表Satellite:历史的描述性数据，数据仓库中数据的真正载体
  • CIF架构
    • ODS
    • DWD
      • 数据质量好
      • 公共DIM
    • DWS
    • DM
• 数据收集
  • 数据更新
    • 全量更新
      • 日快照
    • 增量更新
      • B_table:昨天更新+昨日新增 （生产）
        • 根据updata_time和created_time
      • A_table:T-2日全量数据（数仓）
      • 合并：1、A,B都有，取B；2、A没有B有,取B；3,A有，B没有,取A
      • 比对A_table自增id，无自增id会做每行的md5，进行校对
  • 技术栈
    • sqoop
    • dataX
    • csv等文件传输
• 大数据架构
  • 数仓作用
    • 时效性高
      • 支持实时应用
    • 业务灵活、多变
      • 支持业务快速变化
    • 数据源多样性
      • 关系型数据库
      • 非结构化数据
        • 日志
          • log
          • tomcat
        • NoSql
    • 数据质量参差不齐
      • 埋点数据质量因为链路会有丢失
    • 应用场景复杂
      • 精细化运营
  • 技术选型考虑点
    • 梳理业务和响应的应用场景
      • 有哪些业务场景
    • 需要处理的数据源的种类、类型、数据量
      • 有哪些数据源
      • 数据类型是什么
      • 数据量是多少
    • 对实效性要求
      • 离线
        • T+1
        • H级
      • 实时
    • 对灵活性要求
    • 对性能要求
    • 对成本要求
  • 调度平台
    • 基于状态
      • DAG
    • 基于文件
  • 四类团队角色
    • 大数据基础平台维护、基础运维、优化
      • hadoop、spark等平台的运维
    • 大数据生态开发、工程性开发、应用相关开发
      • 系统开发
    • 数据仓库、数据内容建设、开发
      • 大数据的建设者，关注业务
    • 数据使用者
  • hadoop
    • Hadoop自发布以来，架构经历了三次大的调整，分别是hadoop1>Hadoop2>Hadoop3当前主流为hadoop2版本，且Hadoop3截止目前无稳定版本发布
  • spark
  • hive
• 参考资料
  • https://mp.weixin.qq.com/s/j8tP9nTmA7m_MW85MXnExA