多维数据分析

weixin_39033363

于 2024-07-10 16:13:30 发布

阅读量1k

点赞数 9

文章标签：数据分析数据仓库数据挖掘

本文链接：https://blog.csdn.net/weixin_39033363/article/details/117128427

版权

一、前言

在需求不具体的情况下，面对一堆杂乱的数据，我们该如何进行BI工程的建设呢？宏观上看，整个工程无非就是理解需求 -> 分门别类收集原材料 -> 对照需求，设计建模 -> 对照模型，开始工程；思路似乎很清晰，但是实际工作却极其繁琐，而且数据处理返工也是家常便饭，其中苦楚，恐怕也只有事中人才能体会。本人整理了最近的工作与相关文献资料，在进行复盘后，分享以下心得，鉴于涉猎有限，文章或有纰漏之处，恳请指出。

本文主要介绍了建立数据多维关系模型的相关理论，并给出了部分具体实例，这部分内容为数据仓库的分析型环境提供了必要的、切实可行的实践基础。

二、概念介绍

数据仓库：数据仓库是近年来在信息管理和数据库领域得到迅速发展的一种面向主题、集成的、随时间变化的、非易失的、用于管理决策支持的数据的集合。

多维关系模型（Multi_Demention Relation Model）：模型是对现实事务的反映和抽象，它可以帮助人们更加清晰地了解现实世界，多维关系模型是数据驻留在数据仓库内的外观蓝图，其设计是在业务需求分析之后开始，是数据仓库构建的第一步。

数据处理：理解业务需求，获取需要的各类源数据，源数据可能会缺失，冗余，或者出错，各种情况都有可能出现，后期统计，极大可能发现错误，此时需要定位错误，返工重新清洗。这里只强调一点：源数据一定要原封不动的留存，不要想当然进行数据清洗，进行覆盖，因为当时你以为的正确，后期可能会被判定是错误的，做数据分析，绝对不能带主观色彩来评判数据的正确性。

数据处理的目标：为了建设多维关系模型，需要进行全面的业务梳理，形成全方位的数据视角，帮助消灭各部门之间存在的信息孤岛问题，重点是要保证数据的一致性，分离底层技术的实现和上层业务的展现。

多维关系模型的建设标准：一个好的数据模型不仅仅对业务进行了抽象的划分，对实现技术也可以提供逻辑支持，因此数据模型应该涵盖从业务到技术实现的各个部分。

ETL(Extract-Transform-Load)：用来描述数据从来源经过抽取(从源数据进行抽取)、转换(在传输时进行转换)、加载至目的端的过程，重点要确定数据源和目标数据。

OLAP(On-Line Transaction Processing): 在线事务处理，是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。通俗理解就是从多源关系模型中建立数据立方体，然后对数据立方体按照不同维度进行聚合，上卷和下钻等等操作，数据仓库与OLAP的关系是互补的。

BI(Business Intelligence)：IT界对于BI的定义是，对于存储在OLAP立方体中的数据进行分析和展示。业界对BI的定义为向企业提供快速分析数据的技术和方法，通过收集、管理和分析数据，将数据转化为有价值的信息，并分发到企业各处，让企业的决策有数可依，直观量化地驱动企业管理和运营。

DM(Data Mining 区别后文的DM层 )和OLAP的区别：这边多补充一个概念，数据挖掘和OLAP都是数据分析工具，但是它们处理的问题不同，数据分析的深度不同，DM是一种挖掘性质的数据分析，它能够自动地发现事物间潜在的关系和特征模式，并且可以利用这些特征模式进行有效的预测分析，而OLAP是一种验证性性质的数据分析，用户提出某种问题或者某种假设，OLAP负责多维度多层次地展现数据及问题相关的详细信息，供用户判断提出的假设是否合理。OLAP处于数据分析较为初步的阶段，DM属于比较深入的层次，DM和OLAP相辅相成，DM能够发现OLAP不能发现的更为复杂和细致的问题，而OLAP能够快速告诉我们的系统过去和现状，从而帮助我们更好理解数据，加快知识发现的过程，并且能够迅速验证DM发现的模式是否合理。很多初入门的数据分析师因为弄不清楚这些概念，从而无法肯定自己的工作，认为自己日常只是做简单统计，并无多大价值，这种想法说到底还是经验不够，无法意识到数据的价值。

事实表：保存度量值或现实结果的表，称为现实表，保存大量的行，如学生选课数据，就记录所有学生，课程和授课老师的对应关系。

维度表：记录描述性的信息，保存大量的列，如学生个人信息表保存学生的姓名，入学年份，生日，性别等属性信息。

分层：粗粒度适用于单张表的补充，细粒度适用于多张表的join，添加过滤参数。在DM层（Data Market 数据集市层），对应到BI软件中就是前端展示的Data Cube

三、多维关系模型建设

3.1 多维数据分析过程

在关系型数据库存储数据的基础上，建立决策分析所需要的多维关系模型，需要选择若干对决策活动有重要影响的因素，这些决策分析角度就构成了数据仓库逻辑结构中的多个维，数据的度量值就构成了事实数据的组成部分，从而形成了多维分析模型的两个基本的数据结构：事实表和维度表，两者结合能够给用户提供一个解决业务问题的、清晰自然的数据视图，以便于分析决策。

数据多维分析分为静态和动态两个方面。静态方面包括分析对象和变量的结合，分析的对象被定义为相应变量的函数，每个变量代表空间的一个维度。动态方面包括预测、比较、归类、上卷、下钻、数据集成、数据聚合等。维度数据从最低的细节级到较高的概要级别分为不同的层次，形成了一个家族结构，上一级与它的下一级之间是父与子的关系。在维度的不同结构层次中，主要的操作是对数据进行“上卷”和“下钻”。“上卷“是指用户在数据仓库的应用中从较低层次的数据开始逐步将数据按照层次进行概括处理，从详细数据聚集到概要数据的过程。而”下钻”则是指从数据仓库中的高层数据开始逐步向低层数据探索，了解概括性数据的具体细节。

为了实现以上的数据分析过程，我们必须要按照数据的业务需求流向，进行数据的层次划分。

3.2 数据分层原理

数据分层实现各个阶段业务的逻辑隔离，分层没有统一的标准，需要依据业务分析师对于整个BI项目数据的粒度把握（以下的数据分层是个人的实战经历，作为参考，不为标准，实际操作不可照本宣科，否则很容易陷入逻辑黑洞，在理论引导下，依据实际情况做适当变动是必要的）。

ODS：原始数据（Excel导入、链接数据库导入、其他平台源数据等），此层数据建议不做任何处理。

中间层数据建设

DWD：原始数据按照时间等维度整合的总数据，添加列，处理空值，噪声数据等

DWB：轻度的数据清洗、数据转义、维度转换、聚合（对DWD层数据进行ETL处理）

DWS：粗粒度的汇总聚合（依据业务需求在BI工具中对DWB数据进行ETL处理），形成维度表

DM：依据业务需求对DWS层数据进行汇总统计形成的宽表。（参数设置和过滤条件设置）

数据应用

从数据集市中建立数据立方体Data Cube，进行数据挖掘，数据可视化的应用

3.3 数据分层的好处

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解，由于数据分层的存在，我们可以条理清晰地快速进行Data Cube的上卷，下钻等OLAP操作。

减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算

统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

*常见的错误分层：复杂的维度交叉，看上去高大上，实际上缺乏重点、难以理解，根本用不上。不如直接定位到具体业务问题构建简单一些的分层方式。最后再强调一点，数据分层应当从业务中来，用到业务中去，各种方法只是工具不是目的。当前阶段到底要解决什么问题，这才是必须要想清楚的。

四、OLAP应用（理论会比较抽象，边实践边思考就会很容易理解）

4.1 数据立方体（Data Cube）

面向一个业务主题的数据集合

4.2 维度（Dimension）

维度是不同的业务分析角度。如对销售业务建模，我们可能会关心销售数据随着时间的变化情况，这里是从时间角度来看销售，所以时间就是一个维度（时间维度）。

维度层次体系（Hierarchy）

指维度的层次体系结构，因为维度还可以存在细节程度不同的多种描述，因此多种描述就成为维度的层次。如下展示了时间维度两种不同的层次体系

维度成员（Member）

维度的一个取值就称为该维度的一个维度成员，分为详细细维度成员和聚合维度成员，详细维度成员集合在一起就是聚合维度成员，如在月份这个维度中，一月、二月、三月就是详细维度成员，聚合在一起，就是一季度，这是一个聚合维度成员。用维度层次来理解就是如果一个维度是多层次的，那么该维度成员是用不同维度层次的取值组合，还是用时间维度来理解，我们从年份、月份和日期三个层次各取一个值，就得到了时间维度上的一个维度成员，即“某年某月某日”。

维度属性（Property）

属性的作用是用来标记维度成员，与别名不同，属性不是唯一的，可以重复标记多个维度成员。如“季度”就是一个属性，这个维度里面有一季度、二季度、三季度、四季度四个成员，每个成员的属性都是季度。

维度角色（DimensionRole）

指维度关联到数据立方体上所扮演的角色，如下图：表示人口迁移的数据模型，其中户籍迁入地和户籍迁出地都是地区维度，但是关联到数据模型上就会扮演不同的角色，任何多维数据模型，维度都是通过维度角色关联到Cube上的；

4.3 度量（Measure）

度量是从现实系统中抽象出来的，用于描述数据的实际含义，即描述数据“是什么”，一般情况下能精确化用数值表示的信息，如销售cube中商品的销售额、利润等；

度量维度（MeasureDimension）

表示度量值的维度，对于具有多个度量值的多维数据模型，可以将其度量信息单独提取并作为一个独立的维度，将数据模型进行升维；

转换为二维表结构（模型适合柱状图可视化） ->

转换为二维表结构(模型适合饼图可视化) ->

可以将度量与维度互换，互换后的模型与原形态具有完全相同的分析能力

还可以将普通维度变换为度量，可以将原Cube降维，降温后的Cube同样具有与原形态一样的分析能力

度量角色（MeasureRole）

度量维度关联到Cube上带有的角色信息

4.4 多维数据可视化

人类能够快速理解的维度一般不超过三个，因此对于多维数据，我们需要借助OLAP技术从多维数据模型中生成三维数据立方体，而这里多维数据指的是具有多个维度属性的数据变量，多维数据可视化是指将OLAP生成的数据立方体再次进行转化，变成低维的图表。

多维数据立方体

一个多维数据立方体可以表示为：（维度1、维度2、维度3......，度量变量）。如下图所示就是对某件商品按照地区，销售渠道和时间三个维度组织起来的三维立方体，加上度量“销售额”，就组成了一个多维数据立方体（地区、时间、销售渠道、销售额）。

事实（数据单元格）

当多维数据立方体的各个维度都选中一个维度成员，这些维度成员的组合就唯一确定了度量变量的一个值，这种确定的情况我们称之为“事实”。例如，下图中从年份，地区和销售渠道各取成员“2017年”、“江苏省”和“渠道A”，就唯一确定了度量“销售额”的值。

联动

当对一个Cube进行分析的时候，我们的分析方向有Cube上的点、线和面，面指的是维度间的组合，形象点理解可以看是三维立体的一个面，如下图：将地区和渠道进行组合，就是一个分析面；点指的是维度交叉的点，如下图：2017年在地区浙江通过渠道C的销量情况；线也比较好理解，这里不做说明了。

切片和切块

选取多维立方体的二维子集就是切片，选取一个三维子集就是切块。如选取地区和渠道维度就是切片，在此基础上再选取年份维度成员2016-2017，就是切块。

钻取（下钻）

维度的层次反应了数据的综合程度，维度层次越高，代表数据的综合度越高，数据量越少；维度层次越低，则代表的数据综合度越低，数据更加细粒度，可以查询到很多细节，数据量也就越大。钻取就是从维度的高层次下钻到低层次，从而可以观察更详细的数据。

聚合（上卷）

就是钻取的逆向操作。

旋转

维度方向的转换，也就是用户视角的多维立方体的方向发生变化。

可视化图表

运用图表有效表达数据分析师的分析观点，使分析结果一目了然。图表的设计是门大学问，如图形的选择、版式的设计、颜色的搭配等等，都需要掌握一定的设计原则。（*BI工具给出的图表基本满足需求，但是如果要追求绚丽的视觉效果，进行自定义设计，则需要懂得前端的开发技巧，这也许超出了数据分析师的职能需求，但是个人选择，毕竟技多不压身嘛）

五、总结

5.1 主流程

简单的来说，就是包括：数据源、ODS、DW（DM）、报告这几部分。

主要有这么几个流程：

数据源到ODS，需要考虑：
- 数据源的平台有哪些，比如SQLSever，Oracle，MySQL，文本文件，每个平台有哪些可用的同步工具
- 数据有哪些，数据字典有没有
- 哪些表全量同步
- 哪些表增量同步，如何取增量数据
- 同步周期，按小时，按天，按周，按月？
- 数据量评估：存量数据有多大，增量数据每天有多少？
- 历史保留多久
- 数据正确性校验
- 调度、监控、报警
ODS到DW(DM)，刚开始可以考虑建立数据集市(DM)，待对数据，对业务足够理解，人足够多的时候，考虑建立数据仓库(DW)，需要考虑：
- 熟悉数据字典，理解业务，理解数据
- 事实表要建哪些
- 维度表要建哪些
- 更新周期，按小时，按天，按周，按月？
- 数据量评估：存量数据有多大，增量数据每天有多少
- 历史保留多久
- 验数
- 调度、监控、报警
报告，这个是给业务、决策层看的，是体现价值的地方
- 统计口径的确定
- 验数：验证数据是否正确
- 如何展示：是表格、图形，还是大屏？