现今几乎所有公司都掌握着一定量级的企业数据，数据在各个公司的运营或决策层面起到的作用是很重要的，有了数据才好制定下一步的计划，或者及时发现运营过程中的一些问题，若在决策上稍晚一些，或许机会就稍纵即逝，也许一个决策带来的结果和影响，短期内没有被从数据中挖掘得到，带来的后果是极其严重的，当然，这些是我的个人之谈。
有了一定的数据积累后大多数公司会选择把数据汇集起来建设一个企业级的数据仓库，本文对与数据仓库相关的名词“统计口径”做一定自己理解范畴内的解释。
统计口径的概念并非由数据仓库衍生而来，它应用于一切规范化的，离线或实时的，云端或本地的数据统计。
关于统计口径的定义：
想象一份数据是一块儿猪肉（最近猪肉较贵，正好拿来做类比），在数据之上运用统计口径对数据做加工，类比于屠夫听从顾客的指挥切割猪肉，只听顾客说道：要十斤精肉，切做臊子。不要见半点肥的在上头(咦，为什么要切做臊子？)屠夫自去肉案上拣了十斤精肉，细细切做臊子。只要精肉，切做臊子，这是顾客提出的条件，在一头整猪各个部位具备的情况下，最后顾客要得的也就这十斤臊子，所谓统计口径，就是统计条件的另一种说法。
一份数据，经过层层条件筛选，加工处理，最后被工程师（搬砖的）处理成需求方预期的样子。
数仓建设有了宽表之后就可以给产品运营或者boss们出一些数据了，这里的数据可以是明细数据也可以是汇总数据，可以做定时邮件发送也可以做成可视化报表，打开网站就能看到，一切以数据驱动为目的往前推进。
但是要想实现数据驱动，对数据的一致性和准确性要求就比较高了，比如同样的数据报表，统计某天的销售额，从业务数据库和数据仓库同时统计出一份该指标，大概率会出现对不上的情况，造成数据指标不一致可能得原因有如下几个：
1. 数据仓库在做数据同步时出了问题
2. 数据仓库通常相较业务数据库，在数据量和数据状态上有延迟，延迟通常是一天，而业务数据库通常是实时的
3. 统计人员代码逻辑写错了
4. 同一指标不同需求方给出的统计口径不一样
5. 同一需求方自己对同一指标的定义隔几天也会不同，但自己没做好记录，多次定义自己也乱了
其中，前三种属于技术问题，相对花费一天半天就可以修复，后两种，通常由公司各部门间的连接紧密程度和信息同步程度决定。
不同部门对同一个指标做不同的定义，形成不同的统计口径，双方各执一词都认为自己的是对的，数据不一致数仓的同事只好先按照123的步骤缓慢排错，最后错误在自己还好，如果在需求方，又是一番混乱争执，数据驱动效率低下，效果不良。
关于上述问题的解决办法，现在从技术方和业务需求方两个角度提出解决方案，
技术角度：
1、数据仓库在做数据同步时出了问题
解决方案：
数据同步并非简单的使用工具将不同数据源数据同步到数据仓库就好，业务数据同步之后往往需要数据完整性的校对，比如数据完整性的比对，这个过程可以做一个监控，最简单比如每日分区表的数据记录总量走势是否正常，正常情况业务数据应该逐日增多，若发现走势异常则可以及时排错，另外，全量同步相对出问题会较少，如果是增量同步，单纯用记录的插入时间和修改时间来拉取新增和改动数据，再和前天数据采取无则新增有则改之的思路做融合也有可能会出错，有的业务数据库在删除数据时会直接物理删除而不是给数据打上标记做逻辑删除，这种情况前面的增量同步逻辑无法捕捉到，造成某些数据在业务数据库已经不见了，却还在数据仓库正常生效，就造成数据不一致，增量同步要格外注意这种情况
2、数据仓库通常相较业务数据库，在数据量和数据状态上有延迟，延迟通常是一天，而业务数据库通常是实时的
解决方案：
某条订单在凌晨1点被同步到最新的数据仓库分区，此时假设它的状态是已付款待发货，到第二天下午4点该订单状态变成已发货，而此时数据仓库该订单状态还是 已付款待发货，此时若两边同时统计已发货订单，数仓就会比业务数据库少一条，若两边同时统计已付款待发货订单，数仓就会比业务数据库多一条，这种情况属于状态在一定时间区间内的波动，数仓本身具有一定延迟，故而这种情况尚且算作正常
3、统计人员逻辑写错了
解决方案：
统计人员可能由于自身技术经验或者业务理解能力的不足，或者是粗心大意，统计SQL写错继而造成指标不一致，直属上级应该对统计人员的技术能力有一定判断，若有需要可进行辅助指导或者成长培养，该情况属于新人尝犯错误不足为奇（给自己甩锅）当然，老司机也可能百密一疏
业务需求方角度：
4、同一指标不同需求方给出的统计口径不一样
解决方案：
很容易出现的问题是，一个企业内部各个部门，常见如产品和运营，在运作和沟通过程存在壁垒，这类问题本质是企业文化问题，是人的问题，两个部门可能是携手共进的小伙伴，也可能互相甩锅30年，更严重两边看谁都看不上眼，更更严重是三方谁看谁都看不上眼，越说越远……从技术角度角度能给的方案是：常见的数据指标定义的统计口径，应该在协作文档上做好记录，一方面防止过几天就忘了，一方面也好在多方校对数据时有个凭证，还能帮助技术方自纠自查，再者，数据方面的东西，多做记录会使人思路清晰。
5、同一需求方自己对同一指标的定义隔几天也会不同
解决方案：
首先不排除需求方的个人能力，产品运营这类职业不需要多高的门槛，程序员写了bug至少不修复是肯定不行的，需求方说错一两句话做错一两件事也就过去了，在公司业务的食物链里，程序员是最低的，也是最能背锅的， 这个问题的解决方案参照上个方案，需求方应避免口述或者在需求文档里对数据指标的统计口径做一次定义，常用的重要的统计指标，应该在企业协作文档上做好沉淀记录，方便大家查阅也方便后来的人理解，各数据指标的统计口径可能会随着业务的改动变更产生变化，变化是正常的，让每次变更留下记录，使变更路径有迹可循，技术方对专业的，逻辑严谨的需求方也不会有太多异议。
以上内容站在一个数据仓库工程师角度，算是对统计口径这个可名词可动词的"东西"做了一次自问自答，有不少带个人风格处的写作方式和用词，还希望读者能够见谅，该文章写作目的并非为了指导相关从业人员，而是从技术方面总结自己的工作经验，以便下次再有困惑之时查阅。