摘要：今天分享的主要内容是基于百度的数据仓库方法论（精华版）
分享时间：2021年6月2号
分享内容：石老师
摘要整理：皮卡丘
主要内容：
1. 数据中台简介
2. 数据仓库方法论
3. 数据仓库项目实践
一、数据中台简介
1.1、数据中台：
数据中台是一套可持续 "让企业的数据用起来" 的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。
1.2、数据中台核心内容：
- 数据相关的工具、产品和技术：
- 批量数据采集：sqoop、datax...
- 离线数据处理：HIVE、Spark
- 实时数据处理：SparkStreaming、Flink
- 数据资产：
- 公司业务本身产生和沉淀的数据
- 公司运作产生的数据（如财务、行政）
- 第三方数据：购买、爬虫...
- 数据管理：
- 相关数据管理技术和概念，包括：数仓、数据建模、数据质量、数据规范、数据安全、元数据管理等
1.3、数据中台架构：
1.4、数据中台、数据仓库、数据平台之间的区别：
- 数据中台：
- 数据中台是企业级的逻辑概念，体现企业D2V(Data to Value) 的能力，为业务提供服务的主要方式是数据API
- 数据中台距离业务更近，为业务提供速度更快的服务
- 数据中台是建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层
- 数据仓库：
- 数据仓库是一个相对具体的概念，是存储和管理一个或者多个主题数据的集合，为业务提供服务的方式主要是分析报表
- 数据仓库是为了支持管理决策分析
- 数据平台：
- 数据平台是在大数据基础上出现的融合结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是提供数据集
二、数据仓库方法论
2.1、离线平台：数据化运营（想要什么）
- 当前和过去一个季度或者 一个月的销售趋势如何？
- 哪些商品热销？
- 哪些商品销售不好？
- 哪些客户购买能力比较强？
总结：获取能统计对应指标的数据
2.2、离线平台主要特点：
- 对分析需求最擅长，也是最成熟的，使用最广泛的
- 开源的解决方案和商业性的解决方案很多
- 是构建公司和企业数据平台的根本和基础
- 是目前数据平台的主战场
2.3、数据平台架构：
2.4、HIVE离线数据平台架构：
- 在大数据出现之前，离线数据平台就是数据仓库，数据部门也就是数据仓库部门
- hadoop出现之前，数据仓库的主要技术是商业化数据，比如SQL Server、Oracle、DB2等
- 随着数据量的爆炸性增长，Hadoop的MapReduce、Spark、Hive等大数据技术被应用到数据仓库中
- 离线数据平台另一关键技术是数据的建模：维度表、事实表
- 离线数据内容建设会对精心加工后的数据进行分层：
- ODS原始数据层
- DWD明细数据层
- DWS汇总层
- APP数据集市层
2.5、数据技术：OLTP&OLAP（扩展）
- OLTP：(online transaction Processing)：
- OLTP数据库，如商业性的Oracle、MS SQL Server和MySQL等关系数据库
- 主要是基本的、日常的事务处理，例如银行交易或者进行增删改查等
- OLTP核心需求：单条记录的高效快速处理，索引技术、分库分表
- OLAP：analysis
- OLAP数据库，专门的分析型数据库，侧重决策支持
- OLAP一般只需要处理数据查询请求，数据都是批量导入的，因此通过列存储、列压缩和位图索引等技术可以大大加快响应请求速度
2.6、数据仓库建模技术：
三种搭建数据仓库的方式：
- 传统OLTP数据库中搭建
- 商业性数据仓库产品中搭建（MPP架构）
- 基于Hadoop（HIVE）来搭建
- 不管哪种方式都会面临以下问题：
- 怎么组织数据仓库中的数据
- 怎么组织才能使得数据使用最为方便和便捷
- 怎么组织才能使得数据仓库具有良好的可扩展性和可维护性
2.7、OneData指导方针：
- 首先，进行充分的业务调研和需求分析，这是数仓建设的基石
- 其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵，抽象出业务过程和维度
- 再次，对报表需求抽象整理出相关指标体系，使用OneData工具完成指标规范定义和模型设计
- 最后，代码研发和运维
三、数据仓库项目实战
3.1、需求场景：
- 场景：用车日期2020-09-01到2020-10-01各个城市的应单率，接单率，支付单量
- 分析：各个城市的用车情况
- 落地运营：便于给运营或者产品提供数据分析资料
3.2、数据调研
3.2.1 整理现状
- 收集现有报表：在公司目前的平台中查询现有的报表，比如报表系统，邮件系统以及各个定时任务(crontab)中
- 确认报表有效性：
- 定位报表中使用的表数据是否近3个月有更新
- 可通过报表访问量，如三个月内无访问可认为不再有效
- 不确定的报表可暂时关闭，3个月后无人反馈则也可认为无效
3.2.2 维度指标拆解：
- 数据域划分：数据域指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程可 以概况为一个个不可拆分的的行为事件。当你面对一个全新的业务领域时，做数 据域的划分会帮助你认识全局，规划底层的整体建设。
功能/业务模块 | 业务动作 |
订单管理 | 取消，已完成 |
- 维度拆解：构建一致性维度的矩阵，所谓一致性维度即是抽象出来的一些通用的维度。比如商品的库存以及商品的大区，对应的供应商，以及分销渠道，那么大区一类的维度便可以统一归为地区维度，其他的则分别归为供应商/分销渠道/商品基础信息/时间等维度，统一放置在一致性维度表中。一致性维度由需求衍生，商品域需求方关注的一些通用维度如下：
数据域 | 一致性维度 | 表名 |
商品 | 区域 | dim_city_ymd |
商品基础信息 | dim_prd_info_ymd | |
分销渠道 | dim_prd_dis_ymd | |
供应商 | dim_supp_ymd | |
时间 | dim_date_ymd |
- 指标拆解：
数据域 | 衍生指标 |
已售库存 | |
剩余库存 | |
总库存 | |
...... |
3.2.3 数据源确认：
- 对接研发：通过系统开发确认数据源情况
- 熟悉系统：
- 研发确认
- 产品经理
- 原有报表系统
- 表源确认：
生产库 | 生产表 | 同步表 | 同步job | 描述 |
a_mysql | orders | ods_orders | 10012 | 订单详情 |
a_mysql | products | ods_products | 10013 | 商品详情 |
a_mysql | aisles | ods_aisles | 10014 | 货架详情 |
a_mysq | departments | ods_departments | 10015 | 部门详情 |
3.3、模型设计
3.3.1 选择业务过程：
- 数据模型必然来自于某一个业务流程，选取商品域中的库存维护 的过程，如上面所说，库存维护会引起产品库存数量的变动，业务需 要对这一业务过程产生的结果进行关注
3.3.2 声明粒度：
- 粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度
- 明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录
- 在设计事实表的过程中，粒度定义得越细越好， 建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求
- 比如：在商品域的库存表中，最细的粒度就是商品id。主键则为productid
3.3.3 确定维度：
- 注意事项：
- 尽可能生成丰富的维度属性
- 尽可能多地给出包括一些富有意义的文字性描述
- 尽量沉淀出通用的维度属性
- 维表设计的时候不要把所有的ods表字段都放进来，每个字段都应该明确含义
- 维表遵循原则：
- 现有报表已有的维度+和业务人员的沟通时他们关心的其他维度+部分明确含义未来有场景可能使用的维度
- 主键：维表应该使用主键标识其唯一性，唯一的主键，外键标注
- id与文字描述应该同时存在，id作为不同表关联，名称用于报表展示
- 通用维度应沉淀至维表，做好封装，避免下游各自建立逻辑导致不一致
- 规范统一
- 物理模型：
- 物理设计阶段意味着需要将具体的来源表以及来源字段确认下来，如果逻辑复杂，具体的逻辑也可以落下来
3.3.4 确定事实：
- 指标拆解：确定事实，即为确定指标。在调研的过程中收集到很多指标，且都已经完成了规范的命名
- 事实表设计：
- 详细步骤可以参照维表进行实施
3.4、模型开发
- 根据前面构建的逻辑模型以及mapping文档进行HQL脚本的编写
3.5、模型验证及调整、上线发布
