===== 摘要 =====
相信大家之前在使用 SalesBI 的 Cube 时已经对其有了概念，我们这里先复习一下一些基本术语，以便后续统一用词。
===== 什么是 Cube =====
所谓的 Cube，更多是一个技术性的术语。是为了满足人们从多角度多层次进行数据查询和分析的需要而建立起来的基于事实和维的数据库模型。日常工作中，我们往往会把业务交易的数据和基础信息的数据分门别类组织起来，而不是用一张很宽很宽地表去承载所有地信息。当需要使用到一些额外信息时，可以通过诸如 Excel 的 vlookup 等函数对额外的信息做查找：
{{:bi:3.自助分析:what_is_cube_002.png|}}
如上图，业务交易数据也许只有地区编号，而我们做统计分析时往往会需要找到该编号所属的大区、办事处等信息。后台数据库在整理数据的时候，就会把基础信息和业务明细流水通过关键字段关联起来。数据关联起来后，用一个形象的表述，就是 Cube：
{{:bi:3.自助分析:what_is_cube_001.png?300|}}
上面这个形象化表述的数据立方体就是一个 Cube，它的每一个坐标轴都代表一个业务角度（时间、地区、产品），坐标轴上的坐标值则表示了某个业务角度的一个确定的值（如：江苏、1月3日、青柠600），不同坐标轴坐标值的交叉点则表示一个具体的销售额。
上图只是演示了三个对数据观察的角度，更多的维度无法用图形绘制，只能凭空想象了。人类虽然无法形象的理解更高维度的图形了，但在数学上当然没有问题，所以类比过来，这种多个维度的统计量，这种数据组织形式，我们就把它叫 CUBE 立方体，通过一些工具，我们可以在这个CUBE上进行切片、钻取等操作。
=== 维度 ===
维度是人们观察数据的**角度**。比如“哪种产品销量最好？”主要关注的是产品维度，“哪些地区连续六个月销售额环比增长？”则同时关注了地区和日期两个维度。
数据立方体中，维度可以被抽象理解成一个坐标轴。比如在上面的 Cube 中有三个维度：地区、时间、产品，分别对应三维空间的一个坐标轴。维度**成员**就可以被抽象理解成坐标轴上的坐标值，比如“1 月”、“2 月”这两个维度成员同属于时间维度，它们各自表示了时间维度下一个具体的时间段。
维度存在不同的**级别**，或者称之为**层级**，也就是维度成员所描述业务角度的**细节程度**，可以理解为通过维度成员观察数据的**粒度**。
例如日期维度中 2019年、1月这两个成员，分别属于年份、月份两个不同的级别，显而易见，年份级别的维度成员描述数据的粒度较为宽泛，月份级别则较为细致。换而言之，粒度就相当于坐标轴上的**刻度**：
{{:bi:3.自助分析:what_is_cube_004.png|}}
通常情况下，我们在讨论一个维度的粒度时，往往会值这个数据维的最小层级所能达到的细节程度。例如上面关系图中的地区表，我们可以这样看：
* 维度：地区/区域
* 粒度：数据粒度可以到办事处
* 层级：该维度分为大区、办事处两个层级
* 成员：大区的成员有华东、华北……；办事处的成员有上海、浙江……
=== 指标 ===
指标，或者说度量，是决策者所关心的具有实际意义的数值，比如销售额、完成率等。指标w往往需要经过加和、平均等汇总计算方式得到，并且是需要在一定的前提条件进行汇总计算，如时间、地点、范围，也就是我们常说的**统计口径**与范围。
在一个数据立方体中，从每个维度上都选取一个确定的维度成员，这些维度成员组合所确定的一个点就是一个指标值。
{{:bi:3.自助分析:what_is_cube_005.png?300|}}
比如，在这个 Cube 中，日期维度：1月2日；地区维度：浙江；产品维度：桃子600就确定了一个最细粒度的数据方块，这个小数据方块就是销售额 6000 这个测度值，它表示“浙江1月2日桃子600销量是6000”。
===== 销售执行Cube简介 =====
对于DWC而言，销售日常执行包括了下单、拜访、陈列等多种业务动作，而这些业务动作又因考核等政策规则的变化衍生出各种KPI指标。不同的业务动作产生的指标，其数据粒度和维度都是不一样的。例如，订单的维度可以是天、客户、SKU，而拜访就不会存在 SKU 这个维度；即便同样维度，不同的指标粒度也不一样。又如，库存往往是按月、周去盘点的，因此其粒度最细只能到周，但订单却可以每天都发生，其粒度更细；
可见，如果我们天马行空地对数据做切片、汇总时，往往很有可能因为数据维度、粒度不同，得到一个奇怪的数字。这就需要对 Cube 里面各个指标所能覆盖的维度和粒度做一定的了解，才能拉出正确的数字。
===== Cube 的应用 =====
==== 写在前面 ====
在打开Cube的时候，您会发现这其实和数据集没有多大的区别。从技术角度上看确实如此！Cube 的出现是为了让我们能**更方便地把一些基础数据通过共同的维度汇总在一起**，与之前介绍的 Dataset 相比，他们有以下的区别：
* Dataset 倾向于某个主题的数据应用；而 Cube 则是综合性的分析
* Dataset 多为处理好的指标；而 Cube 更多倾向于原始事实数据
* Dataset 更多聚焦在当时发生了什么；而 Cube 更倾向于以现在的角度回望过去
* Dataset 数据量较小，更快，适合日常业务跟进使用；而 Cube 数据量庞大，占用大量资源，适合业务分析使用
举例来说，可以从以下角度考虑使用哪个数据源：
* 每日的订单跟进最终 -- 推荐使用 Dataset
* 考核数据的核对、追溯 -- 推荐使用 Dataset
* Bluesky 的执行情况 -- 推荐使用 Dataset
* 组织、线路变更后生意分析 -- 推荐使用 Cube
* 年度回顾、生意趋势 -- 推荐使用 Cube
需要说明的是，Cube 的运行将大量占用后台的计算资源，而这个资源是全国共享的。因此在打开 Cube 的时候，不要一下子拉出所有的明细数据，这么做的结果是把资源全部占用，其他同事无法使用；并且过于明细的数据(大于100万行)其实并非您最终的需求，最后还是要进一步加工。因此，我们希望在能使用 Dataset 的情况下，应尽量优先使用 Dataset，以分担数据的压力。而在必须使用到 Cube 时，亦请遵循以下原则以减少数据库的压力：
=== 最佳实践一 ===
**最佳实践之一：避免一下子进入细节**
我们的生意是由每个月几十万家门店的订单、拜访、陈列等构成的。每个门店如果下两个 SKU，或者说每个门店每月平均两次拜访，那业务数据则轻松过百万行。而100万是 Excel 能承载的最大数据行数。这个数据量放在 Excel 是无法承载的。并且，几十几百万行的数据，实质上并不是最终数据分析想要的结果，只是一个中间过程的表。因此，在获取数据时，应遵循从大到小，从宏观到细节的层层递进原则，而不是一下子跳进最明细的数据。
举例来说，对于 Compass 订单我们已经把数据按区域、办事处、地区、辖区、片区等层级归类，并且提供了最新维度以及历史维度两套组织架构信息供用户选择。如果我们是需要分析某些地区、某些业代的订单完成情况，我们只需要选择区域、人员的信息即可，在发现有差异或者机会点后，经过筛选，下钻至更细粒度的数据；而**不是先把所有门店的数据拉出来，看看数据长什么样后，再去掉无关的信息**！-- 要知道，当我们把所有门店的明细拉出来时，您就正在占用着大量的计算资源和网络带宽(可以把数据下载下来，会有几百兆)，这势必会对其他同事的使用造成影响。
{{:bi:3.自助分析:what_is_cube_007.png|}}
//(像取自助餐一样，按需获取所需字段，是保持数据库稳定且快速的最佳实践之一！)//
=== 最佳实践二 ===
**最佳实践之二：先筛选、再取数**
与前面的最佳实践类似，如果我们一定需要查看很明细的数据时，无法避免地需要拉出比如到门店、到SKU、到日等非常明细的业务信息时，可以采用“**由小到大**”的思路 -- 即先通过筛选器，把数据限制在一个足够小的范围：例如先选取一个月、一个片区的信息，观察数据的情况后，再逐步放宽限制。这样可以避免一下子引入过大的数据量导致过度占用资源，也可以让您能更快地对数据集进行拖拉、改变可视化效果等操作。
{{:bi:3.自助分析:what_is_cube_008.png|}}
//(先通过筛选器，把数据限制在一个小范围，观察数据后再逐步释放条件！)//
==== 应用举例 ====
我们经常接到区域对数据的诉求，下面举例几个常用的情况来看看如何通过上面的最佳实践获取想要的数据
=== Case 1 ===
//我最近要做我们区域下一年的生意规划，能否给我2020年开始我们办事处/大区所有的门店所有SKU每一天的订单数据？//
这是一个最常见的需求，在开始取数前，我们算一下，以广州办为例，这几年的门店数大概是8万家：
* 平均一个办事处月活跃门店50%，那就有4万家门店
* 一家门店一个月平均5个SKU，则是 5 × 4 = 20万行数据
* 两年则是：24 × 20 = 480万行数据
这个数据量在 Excel 是完全无法承载的。这时，我们可以以终为始，看看我们是否需要这么大的数据量？如果我们的目的是“分析现在办事处内各个业代在过去两年的订单完成情况”，那尽管数据确实是从每一个SKU、每一个订单来的，但可以通过用更粗粒度的数据来达到目的。在 Cube 里面可以通过类似透视表的方式，以业代为最细粒度，通过**矩阵**这个可视化组件，获取两年的订单数据。在选中矩阵组件后
* 在**行**里拖入最新的**办事处**、**地区经理**、**主管**、**业代**等字段
* 在**列**里把整个**日期**放入，会自动展示年、季、月、日这四个层级的字段信息，但报表数据会默认汇总到年(我们可以通过下钻的方式往下查看)
* 把**完成箱数**放到**值**里，从而形成一个二维透视表
* {{:bi:3.自助分析:what_is_cube_009.png?600|}}
注：Cube 里拉出来的数据，要与业务人员考核表得到的考核订单数一致，需要根据业务规则多个条件组合而成，若需使用考核数据，请使用考核表的 Dataset。
Cube 里保留了所有 Compass 订单的情况，但实际运作中，我们有很多情况都会录入 Compass，但不一定都计入考核。例如
* 根据目前的分销规则，分销体系里的 Compass 数据不计入考核。即渠道为经销商、配送商等需要排除在外：
* {{:bi:3.自助分析:what_is_cube_010.png?400|}}
* 计算考核时只会选取业代下的订单，即在筛选组织架构层级时，要选择其 Level = 7：
* {{:bi:3.自助分析:pasted:20211207-181844.png?400}}
* 有的大区MT渠道会录入订单，有的大区则不录入；这请根据实际情况选取所需数据：
* {{:bi:3.自助分析:what_is_cube_013.png?400|}}
* 因管理要求，办事处下会有一些虚拟的组织节点，亦请根据实际情况选取所需数据：
* {{:bi:3.自助分析:what_is_cube_012.png|}}
* 因管理要求，办事处下会有一些不再启用的组织节点，亦请根据实际情况选取所需数据：
* {{:bi:3.自助分析:pasted:20211208-115715.png?400}}
* 因管理要求，人员下会有一些历史不再有效的人员，亦请根据实际情况选取所需数据：
* {{:bi:3.自助分析:pasted:20211208-115929.png?400}}
正因考核时需要考虑多种因素，因此在需要计算业代考核的数据时，请务必采用考核报表的数据为准。
=== Case 2 ===
//我想了解一下我们区域内每个门店 IR 拍照回来的SKU上架的情况，能否给我今年每家门店的 IR 拍照数据？//
Again，对于此数据需求，我们还是要明确目的，以终为始获取数据。如果直接把门店字段拉出来，Cube 将会变得很慢很慢，同时也挤占了其他同事使用 Cube 的资源。因此，应该采用**先筛选、再取数**的原则，由小到大，通过一个片区、一个月份查看数据样式后，再逐步放开条件。(注: PowerBI 只允许下载不超过15万行数据，请注意最终下载的数据量)
根据上面**先筛选、再取数**的原则，我们可以先把一些限制条件拉到筛选器内：
- 先在筛选器内选择一个办事处、甚至一位地区经理、一位主管
- 限制数据在某一月份
- 把所需字段拉出来检查
- 之后再逐步放开筛选器条件
* {{:bi:3.自助分析:what_is_cube_014.png?600|}}
=== 小练习 ===
//对比一下本办事处两年以来每个主管的活跃客户数情况//！在这个练习中，我们需要
* 通过筛选器筛选自己所属区域的范围
* 拖取一个粗放的数据粒度(到主管)而不是从最细粒度(门店)开始
* 找到相关的数据指标
* 应用合适的可视化组件
==== 最新与历史 ====
在拖拉 Cube 的字段时，可以看到维度字段分为两大类：最新维度 vs. 月结维度。这样的设计跟我们的业务规则有关：因我们的组织架构每年都有大的调整，另外各个区域的线路每个月亦有各种调整，因此每个月会对门店的状态、挂靠归属的人员、组织架构等信息做结存，以保留当时的状态。因此在做 Cube 设计时，我们分别对这两种情况做了区分：
* {{:bi:3.自助分析:what_is_cube_016.png?600|}}
因此，在使用 Cube 时，我们可以看到维度信息分成几大类：
* {{:bi:3.自助分析:what_is_cube_017.png|}}
其中
* **最新维度**：用当前的维度信息去查看数据；如在做生意分析、线路规划时使用
* **月结维度**：用每个月月底时门店的渠道、组织挂靠等信息去查看数据；如在使用 Top 签约这个信息时则需要使用月结维度中的字段
因此，在使用各项维度信息之前，请想一下我们数据要分析的场景，再去拉取正确的维度和指标；否则，维度和指标的时效范围不一致时，会出现拉出空值或者出错的情况。
===== 总结 =====
* 获取数据时，需要根据业务实际情况获取相关数据；如，加上订单排除分销体系、组织架构层级选择 7 等条件。
* 为提高取数效率，请遵循先筛选、再取数原则
* 根据实际需要，选取最新维度还是历史维度
----
[[bi:3.自助分析|<<回到自助分析首页]] \\
[[bi:1.平台概览|<<回到目录]]