数据仓库(Data Warehouse)简称DW或DWH,是数据库的一种概念上的升级,可以说是为满足新需求设计的一种新数据库,而这个数据库是需容纳更多的数据,更加庞大的数据集,从逻辑上讲数据仓库和数据库是没有什么区别的。
为企业所有级别的决策制定过程,提供所有类型数据支撑的战略集合,主要是用于数据挖掘和数据分析,以建立数据沙盘为基础,为消灭消息孤岛和支持决策为目的而创建的。
传统的数据库中,存放的数据都是一些定制性数据较多,表是二维的,一张表可以有很多字段,字段一字排开,对应的数据就一行一行写入表中,特点就是利用二维表表现多维关系。
但这种表现关系的上限和下限就定死了,比如QQ的用户信息,直接通过查询info表,对应的username、introduce等信息即可,而此时我想知道这个用户在哪个时间段购买了什么?修改信息的次数?诸如此类的指标时,就要重新设计数据库的表结构,因此无法满足我们的分析需求。
在产品脑图中可以很清晰的看到根据业务需求设计所需的字段,因此也导致数据库是根据业务需求进行设计。
那么有的会问,为什么一开始就不考虑好这个扩展性呢?为什么数据库一开始就不以数据仓库的形式设计?
首先数据仓库,从字面上理解就可以感受到这是一个很大的空间,而且存储的物品很杂,里面会存放酱油、沐浴露、洗发精等物品,而数据库是存放酱油、盐等厨房用品,洗浴又是一个数据库。
另外一个就是,国内互联网的发展,一开始大家都是做个软件出来,大家一起用,这个时候只要满足的了需求即可,现今不止是需求还有用户的体验等各种方面,需要根据这些分析指标做调整。
操作型数据库的数据组织面向事务处理任务,而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面,一个主题通常与多个操作型信息系统相关。
数据仓库的数据有来自于分散的操作型数据,将所需数据从原来的数据中抽取出来,进行加工与集成,统一与综合之后才能进入数据仓库;数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。
所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。数据仓库中的数据通常包含历史信息,系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。
数据仓库主要是为决策分析提供数据,所涉及的操作主要是数据的查询;
传统的关系数据库系统比较适合处理格式化的数据,能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存,且不随时间改变。
数据仓库中的数据不可更新是针对应用来说,从数据的进入到删除的整个生命周期中,数据仓库的数据是永远不变的。数据仓库的数据是随着时间变化而不断增加新的数据。数据仓库随着时间变化不断删去久的数据内容,数据仓库的数据也有时限的,数据库的数据时限一般是60 ~ 90天,而数据仓库的数据一般是5年~10年。
数据仓库中包含大量的综合性数据,这些数据很多是跟时间有关的,这些数据特征都包含时间项,以标明数据的历史时期。
数据库的操作:一般称为联机事务处理OLTP(On-Line Transaction Processing),是针对具体的业务在数据库中的联机操作,具有数据量较少的特点,通常对少量的数据记录进行查询、修改。
数据仓库的操作:一般称为联机分析处理OLAP(On-Line Analytical Processing),是针对某些主题(综合数据)的历史数据进行分析,支持管理决策。
想要进一步了解olap和oltp,可以参考链接:https://blog.csdn.net/MrZhangBaby/article/details/88748656
比较项 | 操作型(OLTP) | 分析性(OLAP) |
---|---|---|
关注 | 细节 | 综合或提炼 |
模型 | 实体 – 关系(E-R) | 星型或雪花 |
操作 | 可更新 | 只读,只追加 |
操作粒度 | 操作一个单元 | 操作一个集合 |
场景 | 面向事务 | 面向分析 |
数据量 | 小 | 大 |
需求 | 日常操作 | 决策需求 |
业务方向 | 客户信息、订单等查询 | 客户登录间隔时间,市场细分等 |
分层的主要原因是在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因:
每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
简单来说,我们最终给业务呈现的是一个能直接使用业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。
规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
将一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。
屏蔽业务的影响,不必改一次业务就需要重新接入数据。
每一个分层架构暂时没有写上维度层哈,不要上纲上线,维度层是毋容置疑的,公认必备的,在此没有做说明哈!!!
将数据分为ODS(操作数据)层、CDM(公共维度模型)层、ADS(应用数据)层。
将数据分为ODS(原始数据)层、中间数据层 (DWD/ DWS)、TDM(标签数据)层、ADM(应用数据集市)层。
业务流程数据,与业务系统基本保持一致,仅做简单整合、非结构化数据 结构化处理或者增加标识数据日期描述信息,不建议做深度清洗加工。
全历史业务过程数据,按照业务的易理解的视角重新组织,核心是标准、 统一,可以还原历史任何时刻的业务状态,建模的关键层。
面向对象,把跨业务板块、跨数据域的特定对象数据进行整合,形成对 象的全域标签体系,方便深度的分析、挖掘、应用,与数据集市建设方 法类似,特点是有大量算法标签。大数据魅力在这一层体现。
数据集市层,面向应用,根据应用的需要组织数据,一般是使用维度建 模方法,有时会因为业务的特殊诉求违反建模规范。
功能:ODS层是数据仓库准备区,为DWD层提供基础原始数据,可减少对业务系统的影响
建模方式及原则:从业务系统增量抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题逻辑划分
功能:为DW层提供来源明细数据,提供业务系统细节数据的长期沉淀,为未来分析类需求的扩展提供历史数据支撑
建模方式及原则:数据模型与ODS层一致,不做清晰转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理
功能:为DW、ST层提供细粒度数据,细化成DWB合DWS;
DWB是根据DWD明细数据经行清晰转换,如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等;
DWS是根据DWB层数据按各个维度ID进行粗粒度汇总聚合,如按交易来源,交易类型进行汇合
建模方式及原则:
功能:可以是一些宽表,是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储;
建模方式及原则:
尽量减少数据访问时计算,优化检索;
维度建模,星型模型;
事实拉宽,度量预先计算;
分表存储
功能:ST层面向用户应用和分析需求,包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析,面向最终结果用户;适合作OLAP、报表模型,如ROLAP,MOLAP;根据DW层经过聚合汇总统计后的粗粒度事实表
建模方式及原则:
保持数据量小;
维度建模,星形模型;
各位维度代理键+度量;
增加数据业务日期字段,支持数据重跑;
不分表存储
ODS-DWD-DWS-DWT-ADS
ODS
DWD
DWS
ADS
分层架构千变万化,适合自己的才是真。
个人建议根据业务情况复杂度进行合理的选择。
中小型3-4层足矣。大型多业态4-5层吧~
就先聊到这里吧~