多组数据用什么对比（数据一致其实很简单）
多组数据用什么对比（数据一致其实很简单）版本3给出明确的分子&分母的定义之后，就可以正常计算单日的人均发文量了，但计算多天的人均发文量时又会遇到问题。表面上，该口径简明扼要地描述了发文成功率的计算逻辑，可是在实际使用中由于没有约定发文成功量和发文成功人数的定义，就会出现多个结果，比如：发文成功量是根据发文时间归属还是根据审核通过时间归属呢?。版本2口径：发文成功量 /发文成功人数；发文成功根据首次发文时间进行归属，发文成功人数按人头去重。
导语：数据工作者经常接触这样一个概念：口径，它是用于定义指标，但经常会发生“相同的”口径计算出的结果却大相径庭，debug时就会非常烦躁。怎样做才能简单有效地做到口径一致呢？
明确的定义指标计算逻辑
举个栗子：人均发文量作为指标
版本1
口径：发文成功量 /发文成功人数
表面上，该口径简明扼要地描述了发文成功率的计算逻辑，可是在实际使用中由于没有约定发文成功量和发文成功人数的定义，就会出现多个结果，比如：发文成功量是根据发文时间归属还是根据审核通过时间归属呢?。
版本2
口径：发文成功量 /发文成功人数；发文成功根据首次发文时间进行归属，发文成功人数按人头去重。
给出明确的分子&分母的定义之后，就可以正常计算单日的人均发文量了，但计算多天的人均发文量时又会遇到问题。
版本3
口径：发文成功量 /发文成功人数；发文成功根据首次发文时间进行归属，发文成功人数按人头去重；多日聚合时分子求和、分母去重后再相除。
到此，才是一份完整的口径定义。总结起来，口径定义应该至少包含以下3项：
- 计算方式：计算方式主要用于描述指标的现实含义；
- 原子指标计算条件：涉及到时间、地域等方面，应该明确根据哪个字段进行归属；
- 聚合方式：每个指标会面临聚合，对于原子指标需要去重的时候，尤其需要明确。
很多时候我们发现口径完全一致，但结果还是不一样，不要恼火，别执着地去想自己的SQL不会错，看看是不是发生了以下异常的情况：
情形1：同样的口径不一样的写法
假设要计算同学们的平均身高，在数学里下面的公式是永远成立的：
X为记录身高的向量，n为同学数量
那SQL可以有这两种写法：
-- 写法一
select
avg(height) as avg_height
from student_height_table
-- 写法二
select
sum(height) / count(student_id) as avg_height
from student_height_table
上面两种写法结果会一样吗？答案是否定的，只要height字段存在空值就会不一样。那有同学就会问“为什么会存在空值呢？”，其实在工作中会经常遇到这样的情况，虽然是小概率事件，但也无法避免，分析师需要根据现实情况判断如何处理并保持统一。
情形2：同样的限定条件不同的where条件
在业务中存在很多互为充要条件的情形，比方说：某一款手机，分别有128、256、512G内存三个常规版本，有1T内存的豪华版，常规版本有红、黄、黑三种颜色，豪华版仅有金色，那么只要手机是1T内存就一定是金色的。
那计算豪华版手机销量时的SQL可以这样写：
--写法一
select
count(order_id) as order_cnt
from sales_table
where color='gold'
--写法二
select
count(order_id) as order_cnt
from sales_table
where ram='1T'
理论上两者的计算结果是完全一致的，但现实情况中也不然，生产过程中，各字段有不同程度的缺失情况，需要多方约定一个限制方式然后推广执行。
注意join的影响多表join时以下操作可能会使得数据结果出现问题：
- 存在inner join，使得主表部分数据被不知不觉地删除；
- 存在一对多的left join，导致分母没变，分子却增加了几倍。
后续
导致数据结果不一致的情况有多个方面，后续将总结日常工作中用到的方法，大家一起关注呀！
