数仓总结
数据开发的本质是理解业务,设计合适的数仓结构,数据模型
问题往往是一环扣一环的,需要有足够的技术深度,将知识由点连接成面,而不是停留在相互孤立的知识点上。
系统化学习,构建 基础知识思维导图 与 系统设计与优化最佳实践。 点的基础 线的扩展 面的概览 全局的思考指南
3NF
- 完全函数依赖
通过 AB 能推出 C,但是 AB 单独得不到 C,那么可以说:C 完全依赖于 AB
(学号,课名)推出 分数,但是 单独用学号 推不出 分数,那么可以说:分数 完全依赖于(学号,课名)
- 部分函数依赖
通过 AB 能推出 C,通过 单独的A 或者 单独的B 也能推出 C,那么可以说:C 部分依赖于 AB
(学号,课名)推出 姓名,而还可以通过 学号 直接推出 姓名,那么可以说:姓名 部分依赖于(学号,课名)
表主键(学号,课名),分数完全依赖于(学号和课名),但是姓名并不完全依赖于(学号和课名)
- 传递函数依赖
通过 A 得到 B,通过 B 得到 C,但是通过 C 不能得到 A,那么可以说:C 传递依赖于 A
通过 学号 推出 系名,系名 推出 系主任,但是 系主任 不能推出 学号,那么可以说:系主任 专递依赖于 学号
https://blog.csdn.net/ytp552200ytp/article/details/108146345
- 1NF
表中每一列必须是不可拆分的最小单元,每一列原子性
- 2NF
在满足1NF后, 不存在非主属性对 key 的部分依赖,即要求表中所有列,必须依赖与主键,不能有任何一列与主键没有关联,也就是每一个表只描述一件事
- 3NF
在满足2NF后,不存在非主属性对 key 的传递依赖 。 要求表中每一列与主键直接相关而不是间接相关
0、纬度建模与星型、雪花模型 与数仓分层意义
范式建模 | 纬度建模 | |
---|---|---|
角度 | 从全企业的高度设计3NF | 从分析决策为出发点构建模型 |
描述 | 用实体加关系描述企业业务架构 | 事实表 纬度表 星星模型 雪花模型 |
范式理论 | 3NF 不允许冗余 | 逆3NF 允许冗余 |
面向 | 面向数据整理和一致性治理 | 面向业务,分析 |
复合式的数据仓库架构中,操作型或事务型系统的数据源,通过ETL抽取转换和加载到数据仓库的ODS层,然后通过ODS的数据,利用范式建模方法,建设原子数据的数据仓库EDW,然后基于EDW,利用维度建模方法建设数据集市。
1、纬度建模理论
在可理解性和性能最为最高目标驱动下,产生了纬度模型的构造思想
维度建模是一种将数据结构化的逻辑设计方法,它将客观世界划分为度量(事实)和上下文(维度)。度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称之为维度。它与实体-关系建模有很大的区别,实体-关系建模是面向应用,遵循第三范式,以消除数据冗余为目标的设计技术。维度建模是面向分析,为了提高查询性能可以增加数据冗余,反规范化的设计技术
- 便于理解、管理
- 提高查询性能
- 对称性
- 可扩展性
1.1、基本构成要素
事实表, 纬度表, 维度表和事实表的融合(星型结构)
1.1.1、事实表
- 事务事实表(Additive Fact)
保存的是最原子的数据,也称“原子事实表”
- 周期快照事实表(Semi-Additive Fact)
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,时间间隔如每天、每月、每年等等
它统计的是间隔周期内的度量统计, 周期快照事实表记录的是重复的可预测到的时间间隔的事实
周期快照事实表的粒度是每个时间段一条记录,通常比事务事实表的粒度要粗,是在事务事实表之上建立的聚集表
周期快照事实表的日期维度通常是记录时间段的终止日,记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改,其更新方式为增量更新。
- 累计快照事实表(Non-Additive Fact)
https://www.jianshu.com/p/453afb5382ea
周期快照事实表记录的确定的周期的数据,而累积快照事实表记录的不确定的周期的数据。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度,它通常具有多个日期字段,用来记录整个生命周期中的关键时间点。 累计快照适用于较短周期,有着明确的开始和结束状态的过程
事务事实表中一条交易记录会每天有一条数据来记录整个交易过程;而累积快照事实表只会有一条记录,数据会一致更新直到过程结束。
对于不同过程,要设计统一的结束标志,没有的业务时间置空
[图片上传失败...(image-34f832-1612103610614)]
[图片上传失败...(image-9209bf-1612103610614)]
- 非事实事实表(Factless Fact Table)
1.1.2、纬度表
维度表可以看作是用户来分析数据的窗口,
维度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,
维度表包含帮助汇总数据的特性的层次结构。
} 缓慢变化维(Slowly Changing Dimension) } 快速变化维(Rapidly Changing Dimension) } 大维(Huge Dimension)和迷你维(Mini-Dimension) } 退化维(Degenerate Dimension)
代理键用于维度表和事实表的连接
===> 代理键的优点
- 屏蔽业务或数据的影响, 性能优势, 建立不存在的纬度记录
- Kimball的缓慢变化维处理策略的核心就是使用代理关键字
1.2、四步走设计纬度模型
选取业务过程,确定粒度,选定纬度,定义事实
1.3、架构化、增量式建设数仓方法论
http://www.likecs.com/show-12868.html
数据仓库总线架构,(分解企业数据仓库规划任务,统一解释的标准化维度与事实。) 总线矩阵
一致性纬度,
一致性事实
数据仓库建模的争议点:从建立一个集中式的、规划好的架构角度为整个企业建立数据仓库,还是为每个具体的部门建立小型的独立解决方案。当然这两种都不是很有效。前者需要在设计之前将所有数据、所有业务完全掌握清楚,并对数据清洗等了解清楚,这个很难办到,后者由于是单独的创建集市,导致各集市互不兼容,无法形成企业级的全局的数据仓库。
如何解决这一难题,首先需要定义整个企业数仓系统的数据架构,收集业务需求生成企业数据仓库总线矩阵,矩阵每行对应一个业务过程,每列都是一个业务维度。逐个收集业务过程,并使用一致性维度确保系统的综合集成。这样每个业务过程的实现都对整个架构进行了增量扩展,迭代地建立成一个集成的数据仓库。
基于一致性维度的架构将一组业务过程紧密的联系到一起形成了企业数据仓库。企业数据仓库的总线其实就是共享的一致性维度。
另外:一致性维度需要得到高层的支持,因为要做到统一其实是牵扯很多业务系统的事情,有很多是非技术问题。
总线架构的意义
数仓规划是数仓建设的蓝图,涵盖从需求分析开始到最终的数仓评估验收整个环境;数仓规划之所以重要,是因为它是描述了数据流动的概念性框架,为元数据管理奠定了基础,对数据加工过程的理解、数仓建设的交流分享、数据的使用和问题排查、数仓健康度的评估都提供了极大的帮助。
2、星型、雪花模型
星型模型: 星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余
雪花模型: 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
类型 | 星型模型 | 雪花模型 |
---|---|---|
本质 | 纬度表直接链接事实表 | 存在纬度表没有直连事实表,而是链接其他纬度表 |
缺点 | 数据存在冗余,链接查询性能高,etl可以高度并行 | 数据冗余少,链接查询性能低,etl不能并行化 |
适合 | 指标分析 | 纬度分析 |
支架表
https://www.jianshu.com/p/a2fe0c3095a0
当一个属性集合(例如日期、地点)在某个维度或多个维度表中反复出现时,就可以考虑使用支架表。
虽然我们不推崇雪花模型,但如果一组属性在维度表中出现不止一次时,我们也可以采用受限的雪花模型——也就是支架表。
日期支架表是最常用的支架表 时间支架表 地区支架表
或者更准确的说,是维度建模与范式建模。纯粹的范式建模不适用与OLAP系统,纯粹的星型模型也会遇到无数的苦难。根据实际业务情况(而非底层系统)进行适当的妥协——例如微型维度和支架表——才能使你的模型真正靠谱。
微型纬度
当变化频率加快时候,并且维度表包含几百万行的维度表。如果对变化的跟踪采用可靠的SCD2技术对浏览和查询性能具有负面影响。采用不同的维度消除频繁分析或者频繁变化的属性,这一维度技术叫做微型维度。 例如:人口统计,不断变化的属性:收入,被转换为带状范围值。微型维度中的属性值通常呈现为相对小范围的离散值,尽管此类限制使用了预定义宽度范围的集合,但是它能够极大的减少微型维度中合并值的数量。
3、数仓的意义 与 分层的好处
数据仓库是支持管理决策过程. 面向主题的、集成的、相对稳定的、反映历史变化(不同时间)的持久的数据集合,用以支持经营管理中的决策制定过程、数据仓库中的数据面向主题,与传统数据库面向应用相对应。
数据仓库的四个基本特征是 面向主题
、集成的
、相对稳定的
、记录历史的
。 数据仓库的价值正是基于这四个特征体现的
- 高效的数据组织与管理
面向主题的数据组织方式,清晰的数据分类与分层机制形成高效、完整的数据体系。 增加数据分析获取统计的效率
- 集成价值
数仓收纳所有类型数据,实现各种不同数据的关联并进行多维分析,为多角度多层次的数据分析与决策提供支持
- 时间价值
数据任务按照时间调度收集入仓,分类分层。从应用角度有利于实现复杂的统计查询,体检数据统计效率
- 历史积累价值
记录历史,方便回朔历史,分析历史,跟踪历史行为,总结历史,预测未来
数仓分层的好处-------- 对数据进行分层的一个主要原因就是希望在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因。 |
---|
清晰的数据结构 |
数据血缘追踪 |
空间换时间 |
减少重复开发 |
统一数据口径 |
屏蔽业务的影响,快速适应业务的变化 |
复杂的问题简单化 |
4、数据仓库质量
如果保证数据质量?
数据质量管理是通过计划、实施和控制活动,运用质量管理技术度量、评估、改进和保证数据的恰当使用。
被动问题治理阶段
主动问题治理阶段
预防问题治理阶段
数据工作流质量管理
数据质量管理
数据生命周期管理
1、数仓纬度建模四部曲
-- 1. 通过对业务需求 以及 可用数据源综合考虑,决定对那种业务过程开展建模工作。
-- 2. 业务过程确定后,需要确定在纬度模型中包含那个级别的细节数据。(原子粒度 -> 汇总粒度)
-- 3. 以上两点确认后,纬度选择就比较直接了。在主纬度框架内(粒度),考虑其他纬度是否可以被属性化为业务度量
-- 4. 确认那些事实放到事实表中。 事实必须与粒度吻合。
数仓管理和发展一些分享 http://blog.itpub.net/29989552/viewspace-2151382/
1、数据建模的六大基本原则
建模的基本原则
简单讲建模的一些原则,在建模的考虑中需要加以考虑,避免后续遇到大坑措手不及,而不要简单的为了建模而建模。
1.高内聚&&低耦合
主要从数据业务特性和访问特性两个角度来考虑:
将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型;
将高概率同时访问的数据放一起 ,将低概率同时访问的数据分开存储。
2.核心模型与扩展模型分离
核心模型包括的宇段支持常用的核心业务,扩展模型包括的字段支持个性化或少量应用的需要,不要让扩展模型包括的字段过多的入侵核心模型,破坏核心模型的性能及简洁等
3.存储成本与计算性能均衡
在很多时候,设计可能清晰,但存储成本很高,或存储成本很小但计算逻辑复杂,性能差,都需要做一个比较,做到均衡,而非执意孤行。
4.公共逻辑下沉及统一
避免重复计算,需将公共逻辑在底层实现并统一口径
5.幂等性
处理逻辑不变,多次执行结果需保持一致。
6.规范性
相同含义字段需在多表中命名一致,表命名需清晰规范,便于查询及使用
1、 数据仓库从搭建到应用的一整套方法论
https://bbs.dtwave.com/topics/show/174
[图片上传失败...(image-9da691-1612103610613)]
前期调研
数据建模
标签类目
- 基础标签:直接对应的业务表字段,如性别、城市等
- 统计标签:标签定义含有常规的统计逻辑,开发时需要通过简易规则进行加工,如年增长率、月平均收益率等
- 算法标签:标签定义含有复杂的统计逻辑,开发时需要通过算法模型进行加工,如企业信用分、预测年销量等
开发实施
治理维护
贯穿数据采集、应用和价值实现等整个生命周期全过程。
数据管理就是通过对数据的生命周期的管理,提高数据资产质量,促进数据在“内增值,外增效”两方面的价值表现。
- 数据标准管理
- 数据模型管理
- 元数据管理
- 主数据管理
- 数据质量管理
- 数据安全管理
- 数据应用
1、数据治理方法论
https://bbs.dtwave.com/topics/show/167
狭义上讲,数据治理是指对数据质量的管理、专注在数据本身。广义上讲,数据治理是对数据的全生命周期进行管理,包含数据采集、清洗、转换等传统数据集成和存储环节的工作、同时还包含数据资产目录、数据标准、质量、安全、数据开发、数据价值、数据服务与应用等,整个数据生命期而开展开的业务、技术和管理活动都属于数据治理范畴。有的专家干脆把广义的数据治理称为数据资产管理。
数据治理专注于将数据作为企业数据资产进行应用和管理的一套管理机制,能够消除数据的不一致性,建立规范的数据应用标准,提高数据质量,实现数据内外部共享,并能够将数据作为组织的宝贵资产应用于业务、管理、战略决策中,发挥数据资产价值
数据治理平台主要采用数据中台技术和微服务架构初步替代传统架构、面向大数据架构下,为数据资源中心与外部数据系统提供数据服务。对内和对外系统提供云服务。
数据治理管理工具用于落实数据管理体系,实现数据管理自动化,提高数据管理效率,确保数据质量、实现安全数据共享。主要包括数据门户地图
、主数据管理
、数据指标
、元数据管理
、数据模型工具
、数据交换与服务工具
、数据资产管理
、数据开发
、数据质量管理
、数据安全
[图片上传失败...(image-d5a5a4-1612103610613)]
https://zhuanlan.zhihu.com/p/43446819
目前总结的数据治理领域包括但不限于一下内容:数据标准、元数据、数据模型、数据分布、数据存储、数据交换、数据生命周期管理、数据质量、数据安全以及数据共享服务。
同时各领域之间需要有机结合,
如数据标准、元数据、数据质量等几个领域相互协同和依赖。通过数据标准的管理,可以提升数据合法性、合规性,进一步提升数据质量,减少数据生产问题;
在元数据管理的基础上,可进行数据生命周期管理,有效控制在线数据规模,提高生产数据访问效率,减少系统资源浪费;
通过元数据和数据模型管理,将表、文件等数据资源按主题进行分类,可明确当事人、产品、协议等相关数据的主数据源归属、数据分布情况,有效实施数据分布的规划和治理。
[图片上传失败...(image-f0b368-1612103610613)]
2、灵魂30问
0、你们的离线/实时数仓是什么样的? 怎么分层的?
---!!!离线数仓架构
[图片上传失败...(image-77a680-1612103610613)]
--- !!!实时数仓架构
[图片上传失败...(image-862da2-1612103610613)]
- 第一层 DWD 公共实时明细层
实时计算订阅业务数据消息队列,然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合,将一些相同粒度的业务系统、维表中的维度属性全部关联到一起,增加数据易用性和复用性,得到最终的实时明细数据。这部分数据有两个分支,一部分直接落地到 ADS,供实时明细查询使用,一部分再发送到消息队列中,供下层计算使用;
- 第二层 DWS 公共实时汇总层
以数据域+业务域的理念建设公共汇总层,与离线数仓不同的是,这里汇总层分为轻度汇总层和高度汇总层,并同时产出,轻度汇总层写入 ADS,用于前端产品复杂的 olap 查询场景,满足自助分析和产出报表的需求;高度汇总层写入 Hbase,用于前端比较简单的 kv 查询场景,提升查询性能,比如实时大屏等;
===== 架构模式
APP: 高度汇总,应用数据,可以导入应用服务
DWM: 识别分析对象,圈定分析边界,丰富对象属性。
DWD: 识别实体关系,挂靠业务主题,屏蔽业务变化,统一数据标准
ODS : 落地缓冲区,与数据来源保持一致,还原业务
1、什么是数据仓库?如何构建数据仓库?
-什么是数据仓库?
数据仓库, 拿数据库做对比来解释吧
在数据库已经大量存在的情况下,为了进一步挖掘数据资源、为了决策需要而产生的 。
数据库是为捕获数据而设计,数据仓库是为分析数据而设计 数据库是面向事务的设计,数据仓库是面向主题设计的 数据库一般存储在线交易数据,数据仓库存储的一般是历史数据。
---> 以银行业务为例。数据库是事务系统的数据平台,客户在银行做的每笔交易都会写入数据库,被记录下来,这里,可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台,它从事务系统获取数据,并做汇总、加工,为决策者提供决策的依据。比如,某银行某分行一个月发生多少交易,该分行当前存款余额是多少。如果存款又多,消费交易又多,那么该地区就有必要设立ATM了。
数据仓库概念创始人W.H.Inmon在《建立数据仓库》一书中对数据仓库的定义是:数据仓库是支持管理决策过程. 面向主题的、集成的、相对稳定的、反映历史变化(不同时间)的持久的数据集合,用以支持经营管理中的决策制定过程、数据仓库中的数据面向主题,与传统数据库面向应用相对应。
-如何构建数据仓库?
从0-1构建的话,推荐以下步骤
通过业务、需求、数据调研,构建CDM业务流程图
根据流程图,划分主题域,确定主题
构建总线架构与总线矩阵,进行纬度建模(四步走),构建星型模型
设计数仓分层架构,定义数仓规范(命名、模型、开发、流程)
数据治理,保证数据质量,数据安全,数据审计
评估与验收。 开发与迭代开发
从概念模型(cdm)->逻辑模型(ldm)->物理模型(pdm)建模套路,是一个从抽象到具体的一个不断细化完善的分析,设计和开发的过程
[图片上传失败...(image-a51324-1612103610613)]
-数据仓库与数据中台的区别?
需要明白数据仓库和数据平台是两个不同的概念,不要把搭建一套 Hadoop + Hive 的平台叫数据仓库,这是数据平台的范畴
数据仓库不仅仅是指数据接入、数据存储和数据计算,它也要包括数据治理、数据建模和数据挖掘。比如元数据管理、维度建模和 OLAP 分析
数据质量管理
2、如何建设数据中台?简单说下对中台理解与思路
华为数据中台有句话叫做——炮火支援单兵作战
https://mp.weixin.qq.com/s?__biz=Mzg3NjIyNjQwMg==&mid=2247484084&idx=1&sn=976f87c5861bb670f502aada5566e6c2&chksm=cf3430b9f843b9af7dc79ea780b0e6708843939fca05b72c7f14a0e3bef082035029285af4f0&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=Mzg3NjIyNjQwMg==&mid=2247484399&idx=2&sn=a7cf983c93b25a217fe2674d9552eba8&chksm=cf3431e2f843b8f43d720f10968f2ca92aeb42768e699512ea2b69a04dbb788f82446e8d7325&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=Mzg3NjIyNjQwMg==&mid=2247484172&idx=2&sn=0df4ec70c9118f6a83c26f9a1b4eb65e&chksm=cf343101f843b81767df3d6d0573349db1943bdf4f1dc098086599d4b3170f97602b43a83c53&scene=21#wechat_redirect
企业的发展,往往伴随着业务更多元化,也必然会促进更多的业务数据产生,也为企业实现业务数据化和数据业务化带来了更多的可能性,但现实是很多企业依然采用传统理念去建设大数据平台,导致不单单业务系统是一个个烟囱,大数据平台也是一个个垂直的数据中心,所以如何打通这些数据并将其按照一个统一的标准进行建设,以达到技术降本、应用提效、业务赋能的目标,是众多企业面临的问题。数据中台就是为解决这些问题而生。
数据中台的内核包括两方面:一个是应用数据的技术能力,另一个是数据资产的管理。
就是如何构建企业数据中心, 然后把数据资产建好,管好,用好。 这不仅仅需要方法论和管理制度,更需要的一个可视化的数据管理工具,实现复杂的数据资产运维简单化
3、数据仓库、数据中台、数据湖的理解
数据仓库,分而治之,用于BI计算报表
数据湖 ,数据格式内容众多,可以进行更多的数据挖掘分析,多用于AI
数据中台 一统天下 对象DataAPI(组织架构)
4、传统数仓的程度(建模工具、ETL工具、BI报表工具、调度系统)
建模工具:powerDesiger、Erwin、Visio
ETL工具: kettle/informatic(主流的两款) 等等
BI报表工具:superset、cboard、redash、帆软BI/QuickBI/PowerBI 等等
调度系统:airflow、azkaban、ooize、xxl-job、dolphinscheduler、Zeus、hera、
5、传统数仓和大数据数仓的异同?有哪些大的变化?
数仓技术选型侧重点,要求不一致
数据来源不一样
数仓建模、分层不一样
数据查看分析不一样
6、数仓最重要的是什么?
-- 数据的真正价值在于数据驱动决策
-- 确保数据的准确性
-- 如何保证数据的准确性?
元数据的建设与管理是其中重要的一个环节
元数据建设的目标是打通数据接入到加工 ,再到数据消费整个链路,规范元数据体系与模型,提供统一的元数据服务出口,保障元数据产出的稳定性和质量。
首先梳理清楚元仓底层数据,对元数据做分类,如计算元数据、存储元数据、质量元数据等,减少数据重复建设,保障数据的唯一性。
另外, 要丰富表和字段使用说明,方便使用和理解。根据元仓底层数据构建元仓中间层,建设元数据基础宽表,也就是元数据中间层,打通从数据产生到消费整个链路。
https://mp.weixin.qq.com/s?__biz=Mzg3NjIyNjQwMg==&mid=2247484645&idx=1&sn=e1e0052e561fa8aa65064ec667264358&chksm=cf3436e8f843bffeca6b198d94c171d52a69d238b7b60d8399b2d9bc727de96409b027fd50f1&scene=21
7、实时数仓?采用什么架构?lambda有哪些优缺点?
实时数仓分为 利用框架实时计算数据型 与 利用高性能OLAP引擎实时导入型
如果你也想做实时数仓…
基于Lambda架构,MES实时计算平台演进之路
8、如何看待kappa架构?iota架构呢?
Lambda架构已死,去ETL化的IOTA才是未来
9、用户画像(静态、动态标签,统计、预测标签,衰退系数、权重
用户画像
58用户画像实践
静态数据-评估价值:用户相对稳定的信息,例如,主要包括人口属性、商业属性等方面数据;这类信息,自成标签,如果企业有真实信息则无需过多建模预测,更多的是数据清洗工作,如果某些静态信息不准或缺失则需要建模预测。
动态数据-循迹: 用户不断变化的行为信息,例如:浏览凡客首页、浏览休闲鞋单品页、搜索帆布鞋、发表关于鞋品质的微博、赞“双十一大促”的微博消息。等等均可看作互联网用户行为。
形态: 标签与权重: 用户画像的最终形态是通过分析用户行为,最终为每个用户打上标签,以及该标签的权重
标签:表征了内容,用户对该内容有兴趣、偏好、需求等等
权重:表征了指数,用户的兴趣、偏好指数,也可能表征用户的需求度,可以简单的理解为可信度,概率
数据建模方法: 标签=用户标识 + 时间 + 行为类型 + 接触点(网址+内容)的聚合,某用户因为在什么时间、地点、做了什么事,所以会打上**标签
10、推荐系统(协同过滤,基于用户、商品,各种距离算法等)
AI上略搞过
欧氏距离 其源自于欧式空间中计算两点间的距离公式
曼哈顿距离,城市街区距离、棋盘距离
11、数仓基础理念
主题域 血缘关系 拉链表 代理键 维度退化 缓慢变化维SCD 事实表类型 增量dwd处理 星型/雪花/星座模型 事实 维度 粒度 原子/派生指标 OLAP
12、数仓如何确定主题域?CDM?
主题(Subject)是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象。
例如“销售分析”就是一个分析领域,因此这个数据仓库应用的主题就是“销售分析”。 面向主题的数据组织方式,就是在较高层次上对分析对象数据的一个完整并且一致的描述,能刻画各个分析对象所涉及的企业各项数据,以及数据之间的联系。
所谓较高层次是相对面向应用的数据组织方式而言的,是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应,数据仓库中的数据是面向主题进行组织的。
主题可以说是 区别传统数据库面向应用进行数据组织, 数据仓库是面向主题,较高层次上对企业数据进行综合,归类,分析的一种方式。便于企业数据分析,避免数据孤岛
主题域是对某个主题进行分析后确定的主题的边界。分析主题域,确定要装载到数据仓库的主题是信息打包技术的第一步。 主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点,将这些数据主题划分到不同的主题域。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。
主题域是进一步抽象。 规整一类主题, 划分一类业务过程
主题域的确定必须由最终用户和数据仓库的设计人员共同完成的, 而在划分主题域时,大家的切入点不同可能会造成一些争论、重构等的现象,考虑的点可能会是下方的某些方面:
-- 1、按照业务或业务过程划分:
比如一个靠销售广告位置的门户网站主题域可能会有广告域,客户域等,而广告域可能就会有广告的库存,销售分析、内部投放分析等主题;
-- 2、根据需求方划分:
比如需求方为财务部,就可以设定对应的财务主题域,而财务主题域里面可能就会有员工工资分析,投资回报比分析等主题;
-- 3、按照功能或应用划分:
比如微信中的朋友圈数据域、群聊数据域等,而朋友圈数据域可能就会有用户动态信息主题、广告主题等;
-- 4、按照部门划分:
比如可能会有运营域、技术域等,运营域中可能会有工资支出分析、活动宣传效果分析等主题;
-- 总而言之,切入的出发点逻辑不一样,就可以存在不同的划分逻辑。在建设过程中可采用迭代方式,不纠结于一次完成所有主题的抽象,可先从明确定义的主题开始,后续逐步归纳总结成自身行业的标准模型。
13、 数仓如何分层的?及每一层的作用?为什么要这么分层?
系列 | 漫谈数仓第一篇NO.1 『数仓架构』
数仓蓝图:如何优雅地规划数仓体系
为什么要分层
空间换时间。通过建设多层次的数据模型供用户使用,避免用户直接使用操作型数据,可以更高效的访问数据。 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。 便于处理业务的变化。随着业务的变化,只需要调整底层的数据,对应用层对业务的调整零感知.
易维护
高性能
简单化
历史性
14、SCD的常用处理方式?优劣?
覆盖
添加新行 -- 拉链表
添加新列
微型纬度表---范围值
历史拉链表,既能满足对历史数据的需求,又能很大程度的节省存储资源;
- dw_begin_date表示该条记录的生命周期开始时间,dw_end_date表示该条记录的生命周期结束时间;
- dw_end_date = '9999-12-31'表示该条记录目前处于有效状态;
- 如果查询当前所有有效的记录,则
select * from order_his where dw_end_date = '9999-12-31'
- 如果查询2012-06-21的历史快照,则
select * from order_his where dw_begin_date <= '2012-06-21' and end_date >= '2012-06-21'。
-- 拉链表实现
SELECT * FROM
(
-- 失效值
SELECT A.user_num,
A.mobile,
A.reg_date,
A.t_start_time,
CASE
WHEN A.t_end_time = '9999-12-31' AND B.user_num IS NOT NULL THEN '昨天'
ELSE A.t_end_time
END AS t_end_time
FROM dws.user_his AS A
LEFT JOIN ods.user_update AS B
ON A.user_num = B.user_num
UNION ALL
-- 有效值
SELECT C.user_num,
C.mobile,
C.reg_date,
'昨天' AS t_start_time,
'9999-12-31' AS t_end_time
FROM ods.user_update AS C
) AS T
拉链表性能优化
使用拉链表的时候可以不加t_end_date,即失效日期,但是加上之后,能优化很多查询
在一些查询引擎中,我们对start_date和end_date做索引,这样能提高不少性能。
保留部分历史数据,比如说我们一张表里面存放全量的拉链表数据,然后再对外暴露一张只提供近3个月数据的拉链表。
可以加上当前行状态标识,能快速定位到当前状态。
在拉链表的设计中可以加一些内容,因为我们每天保存一个状态,如果我们在这个状态里面加一个字段,比如如当天修改次数,那么拉链表的作用就会更大
拉链表回滚
https://www.cnblogs.com/zuifangxiu/articles/6475179.html
假设恢复到t天之前的数据,即未融合t天数据之前的拉链表,假设标记的开始日期和结束日期分别为s、t,具体分析如下:
1 当t-1>e时,s数据、e数据在t天之前产生,保留即可
2 当t-1=e时,e数据在t天产生,需修改
3 当s 4 当s>=t时,s数据、e数据在t+n天产生,删除即可
比如在插入2015-08-23的数据后,回滚2015-08-22的数据,使拉链表与2015-08-21的一致,
1,
深入解析数据仓库中的缓慢变化维
https://www.jianshu.com/p/d3b8d80d27b3
15、元数据的理解,元数据管理系统
16、如何控制数据质量
如何提升数据质量??? http://www.woshipm.com/data-analysis/3945408.html/comment-page-1 http://www.woshipm.com/pmd/3952936.html 1 。 数据基础建设 数仓设计上,清洗完善,层级分明。ETL与数据血缘清晰。 不同主题域 , 不同层级的数据分别进行监控
- 数据处理监控 监控报警, 稽查任务质量
3.业务系统调整响应。管理与制度层面 规范化,降低沟通, 提升数据输出质量 与 数据响应速度
17、!! 如何做数据治理,数据资产管理
总体思路、模型设计、数加架构、数据治理四个方面 构建更贴合大数据应用的数据仓库。
目前总结的数据治理领域包括但不限于一下内容:
数据标准、元数据、数据模型、
数据分布、数据存储、数据交换、
数据生命周期管理、
数据质量、
数据安全以及数据共享服务。
18、Hive优化
[图片上传失败...(image-1a7eac-1612103610612)]
19、实时数仓
[图片上传失败...(image-e67fbf-1612103610612)]
-- DWD 公共实时明细层
这部分数据有两个分支,一部分直接落地到 ADS(olap引擎),供实时明细查询使用,一部分再发送到消息队列中,供下层计算使用;
-- DWS 公共实时汇总层
以数据域+业务域的理念建设公共汇总层,与离线数仓不同的是,这里汇总层分为轻度汇总层和高度汇总层,并同时产出,轻度汇总层写入 ADS,用于前端产品复杂的 olap 查询场景,满足自助分析和产出报表的需求;高度汇总层写入 Hbase,用于前端比较简单的 kv 查询场景,提升查询性能,比如实时大屏等;
实时数仓的应用场景:
实时olap分析
实时数据看板
实时用户特征 实时计算实体特征,用于精准运营
实时业务监控、预警
20、Kylin cube 与 减枝优化
https://blog.bcmeng.com/post/kylin-dimension.html
衍生纬度
聚合组 强制纬度、层级纬度、关联纬度
优化 Extended Column 与 并行度 rowkey 顺序