4个简单的数据管理技巧
它发生在我们所有人身上，你会收到新的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起初，许多人看到这2个查询后会认为它们实际上是相同的效果。左边的查询仅包含了一些额外的列，对吗？但这并不算什么，在左边查询中有五个级别的聚合，右边仅有两个。由于该组织更加精细化，左边查询将返回更小的总数。这取决于你所做的进一步分析，如窗口函数或甚至过滤，这些额外的组可能会造成严重的破坏。如果你只是把他们放在管道做未来的查询，那么你就不再有不同的分组。
聚合错误是最常见导致数据错误的原因。即使一开始看起来正确，多两遍你就会恍然大悟。
这是一个快速的
由此，我指出另一个常见的数据错误，在过去四年里，我遇到可把快照表作为一位分析师和一位老师。这些都是数据表在给定时间段内 （每月、 每周、 每天），及时采取数码快照。
无论出于何种原因，这些类型的表格牵绊着许多人。首先，他们往往确定性很差。我这里的意思是，对于该表中一个新的消费者，作为快照表不会被立即识别，这样会造成用户误操作数据。一个简单的解决方案是预防诸如命名表来反映其内部结构。
如果你怀疑一个快照表及如何与其一起工作，那么，你可以使用快照表中的最大标识符，所有指标过于夸大。你采取一周后得到的结果数据，看起来是否是大了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你决定如何与快照表工作一致是很关键的。根据上下文和目标，两种处理的方法是有效的。
寻找模式
当调查数据验证问题时，我发现它很有用，试图找到模式中的一些错误。比如，像这样的一些问题：
- 所有的数据都受到影响吗？
- 受影响的数据都来自同一组吗？
- 这些差异是成正比的，还是随机的？
- 有没有日期的模式？
帮助你缩小一个潜在的原因。如果所有的数据都受到影响，罪魁祸首通常是在脚本或查询中，而不是在数据本身。然而，如果我注意到某个月或某天有明显偏低，我将去调查基础数据。这可能意味着数据收集的问题发生在那个时间段。
如果数据验证往往按比例与原始数据相比，它可能意味着一些数据一直没有被捕获在你的聚合中。基本逻辑错误往往呈现出“随机”，意思似乎没有可识别的模式。然而，这种情况是由于不正确处理或简单，故障逻辑的边缘情况下发生的。
从头开始搜查
你已经尝试了一切，你仍然无法搞明白。现在，是时候开始挖掘了。虽然这很容易从错误的答案开始并且逆向工作，或从这个地方开始你认为这都是错的，但你必须从头开始。
数据中的错误刚开始可能为良性的，但随着你的工作分析，带来的问题是指数变的更差。就像一个数学题：从一开始，找到错的位置。这部分可能繁琐和耗时，但在用完了所有技术后，回到最初状态，观察你的数据是如何一步步的变化的，这有助于查询断点以及断点位置。