数仓理论知识之杂谈

数仓痛点

数据仓库的三个阶段

• 第一阶段
  使用大量成熟的开源框架，主要以离线批处理为主，外围系统自研能力较弱，数据量和集群资源较少。
• 第二阶段
  使用开源+自研方式，有自己的方法论与建模体系，有比较完善的元数据管理，数据质量查控，可以满足离线实时需求。
• 第三阶段
  有自研的一站式大数据处理平台，有完善的数仓理论基础与外围工具，有完善的共享机制与权限管理。

痛点

• 临时取数需求占用数仓人员大部分时间
  • 解决方法：自助取数+OLAP引擎
• 数据规范与流程不一致，跨部门合作困难
  • 解决方法：建模规范和开发规范
• 指标口径不一致导致数据可信度下降
  • 解决方法：指标字段
• 烟囱式开发形成的数据孤岛与重复计算
  • 解决方法：指标字典，建模规范和开发规范
• 数据膨胀导致计算资源紧张，出数时间得不到保障
  • 解决方法：指标字段，数据产品和服务化
• 异常排查时间和修复时间长
  • 解决方法：元数据与数据质量监控
• 数据安全与数据共享矛盾不可调和
  • 解决方法：数据分级与权限管理
• 产出形式单一
  • 解决方法：数据产品和服务化
• 业务需求响应不及时
  • 解决方法：自助取数+OLAP系统，数据产品和服务化

数据模型

• 接入层
  底层，在企业中被称为ODS层，一般与业务源系统数据格式保持一致。
• 中间层
  过渡层，在企业中耗费精力最多的，也是最复杂的层，在中间层主要有临时表，维度层，明细层，汇总层与集市层组成。
• 应用层
  最终层，向外提供数据服务。

分层与功能对比：

分层	功能
APP数据应用层	个性化指标加工，基于应用的数据组装
DWM数据集市层	宽表集市、跨过业务场景、行为数据组装
DWS数据汇总层	单业务场景、行为数据组装、提升公共指标的复用
DWD数据明细层	标准化、维度补全、异常处理
DIM维度层	一致性维度建设
ODS数据接入层	数据同步，基本与源数据保持一致

数据流向

总原则：禁止逆向调用，避免同层调用，优先使用公共层，避免跨层调用。

实际上很难遵守总原则，所以近两年就炒起来了一个新的概念–数据治理。

数仓规范

表命名规范

以一张位于dwd层，属于dache（打车）业务，dianji（点击）主题，统计点击数量（click_detail），时间周期为天（day），存储策略为f。
dwd_daceh_dianji_click_detail_df

字段命名规范

• 属性字段：文本字段，使用通用单词即可

• 指标字段：修饰词+原子词+时间修饰

• 技术字段：计数主体_cnt

• 比例字段：计数主体_rate

• 分区字段：日、周、月、季度、年：ds。小时分区：nn。分钟分区：mm。业务分区：业务描述文本。

• 费用字段：计数主体_amt

• 标识字段：is_标识主体

• 时间字段：业务主体_time

• 日期字段：业务主体_date

需求对接规范

和业务，分析，技术沟通，确保延迟和取数准确可以接受。

数据开发规范

• 指定库和队列
  • 声明使用的库与本账号属于的队列
• 表创建
  • 建立外部表，文件存储格式，分隔符，存储位置指定
• 分区加载
  • 删除与创建，指定分区存储位置
• UDF/临时表创建
  • 删除与创建
• 数据写入
  • 是否通过覆盖写入数据
• 临时表删除
  • 定时清理临时表，自动清理临时表

外围系统建设

调度系统

为了保证数据处理结果的准确性，就必须要求这些任务按照上下游依赖关系有序、高效的执行。
一个较为基础的处理方式是，预估出每个任务处理所需时间，根据先后顺序，计算出每个任务的执行的起止时间，通过定时跑任务的方式，让整个系统保持稳定的运行。

• 开源
  • Azkaban
  • Oozie
  • DolphinScheduler
  • Airflow
• 自研

元数据管理系统

元数据管理系统是外部了解数仓的门户入口，一个好的元数据系统至少要有以下信息：

• 表信息：包括表英文名，中文注释，表状态
• 字段信息：包括字段类型，英文名，中文名，字段注释，保密级别，统计逻辑说明
• 负责人信息：业务/开发负责人名超链接、所在部门
• 分区信息：分区名、分区大小、分区记录条数、生成分区的时间
• 血缘信息：表上下游节点信息
• 代码信息：生成该表对应的代码地址超链接
• 存储说明：总表大小，波动情况
• 热度信息：表示被下游依赖的多寡
• 权限信息：申请访问超链接，权限审批到单人单字段粒度，不同保密级别字段对应不同审批流程

通用离线与实时计算平台

开源的有hadoop，spark，flink。

数据质量监控

数据质量监控系统主要基于规则判断达到数据监控的目的，系统建设一般分为三个阶段：

1. 表级别的监控：主要为表的总条数、总大小、分区数据、各分区条数、各分区大小，条数/大小同环比，日增长情况等。
2. 字段级别监控：枚举值异常判断、特殊值判断、范围判断等。
3. 全链路数据监控：主要依赖上下游血缘分析，自动判断跟踪故障点。

发展方向展望

• 趋势一
  产品化与服务化
• 趋势二
  单一技能变多项技能

目前企业招聘总结

• 建模理论基础扎实，且能熟练运用在工作中
• 熟悉大数据技术栈中的常用组件，并能熟练使用各类型语言进行离线计算或者实时流计算的开发
• 熟悉业内常规的开源组件，并能根据不同的场景制定不同的数据仓库实施方案
• 有很强的业务senese，是某一个或者特定领域的专家
• 有较好的项目管理能力，能推动项目发展
• 超大数据量下的代码优化能力，并对原理理解透彻
• 数据产品规划能力
• 数据治理能力
• 数据分析与挖掘能力

数仓模型好坏标准

• 节点耗费存储越小越好
• 节点耗费资源越小越好
• 节点深度越小越好

基础

数据仓库发展历史

• 萌芽阶段
  20世纪70年代MIT提出将业务处理系统和分析系统分开，针对各自不同特点设计不同的架构。
• 探索阶段
  20世纪80年代中后期DEC结合MIT理论，建立TA2规范定义分析系统的四个组成部分：数据获取、数据访问、目录和用户服务。
• 雏形阶段
  1988年IBM第一次提出信息仓库的概念并称之为VIATL规范。
• 确立阶段
  1991年Bill lnmon出版《Build the Data Warehouse》标志着数据仓库概念的确立。

什么是数据仓库

在《数据仓库工具箱》中，对数据仓库的描述是：
数据仓库是一个面向主题的，集成的，相对稳定的，反应历史变化的数据集合，用于支持管理决策。（官方定义）

在《数据仓库》中，对数据仓库的描述是：
数据仓库是一个将源系统数据抽取、清洗、规格化、提交到维度数据存储的系统，为决策的指定提供查询和分析功能的支撑和实现。

什么情况下去建设数据仓库

• 当你需要集中化管理你的数据时
• 当你希望以更高效的方式使用数据时
• 当你的数据量和复杂度到需要一个团队来维护时
• 当你希望可以数据驱动业务时
• 当你想要借助大数据的力量来提升产品竞争力时
• 当你想时刻知道业务发展情况时

模型设计的三个阶段

概念模型

概念模型主要是指通过分析和归纳，将业务划分为几个主题，并确定主题之间的关系。
比如电影行业的影院、影片、影人、用户、订单、渠道等等

逻辑模型

逻辑模型是指在概念模型的基础上，定义数据仓库各种实体、属性、关系，指导后续的数据存储、组织和数据应用的开发。目前比较流行的建模理论是Inmon提出的自下而上的范式建模理论和Kimball的自上而下的维度建模理论。

范式建模

三范式：

• 原子性：数据不可分割
• 唯一性：每行数据唯一
• 独立性：消除传递依赖

优点：

• 节约存储
• 结构清晰
• 易于理解
• 适合关系型数据库

缺点：

• 构建比较繁琐
• 查询复杂
• 不适合构建在大数据分布式环境下

维度建模

维度：

• 星型
  一个事实表对应多个维度表
• 雪花型
  一个维度表对应多个维度表

优点：

• 方便使用
• 适合大数据下的数据处理
• 适合进行OLAP操作

缺点：

• 维度补全造成的数据存储的浪费
• 维度变化造成的数据更新量大
• 典型的反三范式

物理模型

物理模型设计是指根据逻辑模型设计的结构为基础，设计数据对象的物理实现，比如表的命名规范、字段的命名规范、字段类型选择、分区设置、存储设置，更新方式等等。

什么是主题域

主题域是将业务过程或者维度进行抽象的集合

特点是：面向分析的（主题域的划分是从业务的分析角度来进行划分的），业务抽象的（在业务流程中将一些行为的点转换为事实度量），通用的（主题域划分后相对稳定），需要长期维护的。

主题域划分

一般在数据仓库中业务主题与数据主题两种（大概率前者包容后者），包容会体现在数据表命名中：
dwd(层)_xx(业务主题域)_yy(数据主题域)_zz(业务描述)_df (存储时间+存储策略)

进行数据主题与业务主题的联系一般都使用业务数据矩阵：
拿一个电商app举例