人在数海漂，挨了“数据粒度”这一刀

粒度取决于维度的组合，即我们想通过什么角度去看事物。不同的业务场景，对数据粒度有不同的要求。粒度越细可以表达的东西越多、粒度越粗可以表达的东西就越少了。

例如：看一天所有的交易额，粒度是：天 ，比如：20210616 有100万交易额。看一天某一个卖家的交易额，数据粒度是：天+买家ID ，比如：20210616+买家ID14有100万交易额。

好戏来了

熬在数据之海，摸爬滚打，却挨了“数据粒度这一刀”，草率了。

某年某月某天，“指象”大哥，拿到业务数据需求，自命“数据驱动业务”而不凡，操起自己的SQL大刀，打完收工，数据已OK，请业务大佬咪西。

几天后，业务酒足饭饱之时，突然，一条消息炸群了，同一个卖家为啥在一天有两天聚合的数据呢？看到业务大佬的@我，我去，我是不是要火了。

我告诉自己不要慌，“百应必有果，这个报应不一定是我”。我回复到：“收到，我check一下”（显得沉着冷静，实则慌的一B）。

经过10多分钟的顺藤摸瓜，终于，我提供的数据确实有同一个买家ID有在同一天有两条数据，我突然想起来业务前两天“修改过买家名称”。也就是说“在数据历史的长河中，同一个买家ID，是存在两个名称的”。

捶胸顿足：“卧槽，疏忽了”（系统没有卖家修改名称的入口，本次名称变更是业务运营批量更新）。

我将（日期，卖家ID，卖家名称）作为维度组合，来计算指标，同日出现两个数据。我心想这是数据粒度更细了，数据不是重复，我应该没有责任（其实我责无旁贷）。

经过和业务的撕逼（百依百顺），一起合作共赢，修正数据，及时消除数据带来的业务影响。

一，“指象大哥”为啥错了？

面壁思过，痛定思痛：

其一，事前：没有明确数据粒度及业务使用场景；

其二，事中：错把维度简单的等价于粒度，直接去事实表中的维度属性做粒度组合；

其三，事后：没有缜密的数据监控，未能及时发现。

事后诸葛亮，三个理由着实让人幸福（各位贻笑大方，呵呵哒）。

二，“指象大哥”有话BB

虽然大哥摔倒，你们不扶大哥一把，大哥不怪你们，大哥要“杀人诛心，以德报怨”。传授你毕生功力，接好了....

在维度建模中，通常将指标的度量称之为“事实”，将产生度量的环境称之为“维度”。

那么上文中的“日期、卖家ID、卖家名称”是维度；“交易额、订单量、客户数”就是指标，是基于事实加工计算而来。维度是看事物的角度，指标是我们基于“维度”视角看的度量多少，大小等。 在数据仓中数据表大致分为两类：一是维度表，二是事实表。

维度表一般由【代理键、自然键、维度属性】三部分构成。

• 代理键：不具有任何业务含义，仅做维度表数据唯一性区分的属性，通常以主键形式出现，比如自增的ID。
• 自然键：具有业务含义，是业务实体一个实例的唯一性区分，比如卖家ID、商品ID，在维度表中不一定做表的主键。
• 维度属性：描述同一业务实体各种特征的维度列，比如卖家名称、商品名称等

从维表的组成部分，我们很容易的看到维表的关键粒度，是自然主键，维度的主键ID一定是唯一（属性名称通常取最新的），维表中的维度属性在不同天是更新变化的。

谈到这里，聪慧可人的同学肯定会说：“指象大哥，天粒度聚合时可以用事实表关联维度表，维度属性（e.g 卖家名称）即使参与维度组合，也不会造成同一个天有多个卖家名称的现象出现。"

你说的对，哥也看了上游数据也是按天取维表聚合而成的数据表B（存在不同天之间卖家名称同的数据）。哥基于数据B表直接聚合，造成了B2数据表粒度不唯一了，大意了。

三，指象大哥的独家秘方

1，要事前弄清维度的一致性原则：

维度表的一致性是关系到数据模型能否进行跨业务横向钻取做多业务流程分析的关键。

一致性原则主要体现在三个方面：结构一致性、语意一致性、内容一致性。

• 结构一致性：同一实体的同一维度属性在不同维度表/事实表中，需有相同的维度属性列名、相同的数据类型定义，以保证内容的同一性。
• 语意一致性：不同维度表/事实表中，相同维度属性所表达的业务含义需要是一致的，否则在使用过程中会出现相同指标、不同结果的数据指标不一致性。
• 内容一致性：是需要在同一实体同一维度属性在不同维度表中需要有相同的数据内容表示（如，下单日期维度和支付日志维度中month属性一个是‘202002’表示，一个‘2020-03’表示）。

2，事中如何保证维度一致性：

保证一致性的两个方法：共享维度表结构、共享维度表内容。

共享维度表结构：同一实体的不同角色维度表共享一张维度表，通过在核心维度表上创建视图或进行数据导出实现维度表结构的共享（如：下单日期维度、支付日志维度）。

共享维度表内容：其他表加工过程中使用到维度属性内容，直接从维度表中获取，该实体的所有属性，均以维度表中属性为准，仅在维度表中进行维护，其他事实表/维度表中使用到维度表的指定属性，仅做内容共享。

3，事后要对数据产出的粒度做监控

在ETL任务产出数据之后，通过自动化程序查询验证数据表中的主键唯一，来监控数据粒度是否重复，发现重复则推送报警给负责人，并阻塞一段时间的下游生产任务。负责人处理完成重复粒度，恢复下游生产。

当然保证数据质量我们可以做的很多，比如，需要保证数据的 最晚就绪时间、重复记录、空值、NULL值、数据量、数据量7日均值、就绪时间延迟、执行时长、数据量环比、指标监控、指标一致性、值域监控、表间数据量对比等等，任重道远。