通过真实世界中的实例，我们将共同通过种种错误的数据分析方式总结出正确的技巧与诀窍。
相信每位朋友都遇到过这样的情况：将来自各类渠道的数据收集起来，通过A/B测试进行验证，希望借此得出分析结论。但在检查结果时，我们发现这些数字似乎并不怎么合理。事实上，数据验证也是我们日常工作中的重要环节，而且与编码一样需要大量追踪与调试。在今天的文章中，我们将共同通过真实世界中的实例，在对种种错误的数据分析方式的总结中找出正确的技巧与诀窍。
别急着做出假设
感觉上是对的，并不代表就真是对的。我们的大脑常常具有误导性。我发现很多分析师都因这种失误而身陷分析迷宫。
下面来看一种常见的问题：变更聚合查询。
先看以下两行查询：
- SELECT
- Month,
- Group1,
- Group2,
- Group3,
- CONCAT(Group1, “-”, Group2) as NewGroup,
- SUM(Usage) as total_usage
- FROM usage
- GROUP BY 1, 2, 3, 4, 5
- SELECT
- Month,
- CONCAT(Group1, “-”, Group2) as NewGroup,
- SUM(Usage) as total_usage
- FROM usage
- GROUP BY 1, 2
乍看起来，很多人会认为这两条查询的含义是完全一致的。左侧的查询只是包含了额外的几列，对吧?但事实并非如此。左侧查询中包含5个聚合层级，而右侧的只有2个。左侧的查询返回的总和数字更小，因为其定义更为明确。如果将其作为分析流程中的组成部分，那么不同的结果会给后续分析造成严重影响。
聚合错误是一类非常常见的问题，因此即使对自己的思路很有信心，大家也请务必再检查一遍。
Snapshot(快照)问题
过去四年当中，身为分析师与教师的从业经历让我意识到一大常见数据错误的起源：snapshot表。这类数据表面向特定时间段(每月、每周、每日)，旨在保存对应时间点的数字化快照。
无论原因为何，这类表确实难倒了很多人。首先，这类表往往很难理解，这意味着刚刚接触此类表的用户无法立即意识到其属于snapshot表，直接导致用户对数据进行错误运用。最简单的预防办法就是为其设置明确的名称，告知用户其属于snapshot类型。
我们该如何识别出snapshot表并找出其使用方法?最明确的标志就是，snapshot表中的全部指标往往都较平均值有所夸大。大家可能曾经把周快照当成日快照处理，并发现其结果比预期值大5到7倍——幸运的是，这种错误还是很容易发现的。大家可以将其拆分成一天，例如时段中的***一天，或者干脆取其中的***值。具体参考以下示例：
选定一天：
- SELECT
- TD_TIME_FORMAT(time, ‘yyyy-MM’) as MONTH,
- category,
- usage
- FROM usage_snapshot
- WHERE TD_TIME_RANGE(time, ‘2016-04-01’)
找到***值：
- SELECT
- TD_TIME_FORMAT(time, ‘yyyy-MM’) as MONTH,
- category,
- MAX(usage) as total_max_usase
- FROM usage_snapshot
关键在于坚持以同一种方法使用snapshot表。根据实际背景与目标，我们可以选择最为有效的具体处理办法。
总结模式
在验证数据有效性时，我发现总结其中的模式能够有效识别错误。具体问题包括：
- 是否全部数据皆受到影响?
- 受影响数据是否全部来自同样的群组?
- 区别间呈正相关状态，抑或各自随机?
- 数据之中是否存在某些模式?
这些问题有助于缩小思考范围。如果全部数据皆受到影响，则问题往往源自脚本或查询，而非数据本身。但如果某月或某日的值明显较低，则需要调查基础数据，这意味着该时段内的数据收集机制可能存在错误。
如果所验证的数据往往以等比例方式低于原始数据，可能意味着部分数据没能被聚合查询所正常收集。而基本逻辑错误则往往令分析结果呈现“随机性”，意味着其中没有明显的模式。
从头开始进行梳理
如果尝试了一切办法但仍然无法确定问题，那么只能进行深入挖掘了。虽然从直观上讲，我们都希望能够从出错的位置开始推进，但现在大家需要安下心来从头开始梳理。
数据中的错误往往最初尚属于良性范畴，但随着分析流程推进而变得愈发糟糕。这就像是在解数学题，我们要从头开始再推导一遍。这项工作可能费时费力，但却能够以清晰的思路帮助大家了解数据是如何一步步走偏并最终带来完全不可理解的结论。
相信大家一定也在处理数据验证工作中有着自己的技巧与诀窍，请在评论中不吝分享!
原文链接：4 Tips for Easier Data Management
