4个简单的数据管理技巧

资讯频道 → 数据库

2顶
0踩

2016-06-03 15:57 by 副主编 mengyidan1988 评论(2) 有6756人浏览

数据库

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用

原文：4 Tips for Easier Data Management
作者： Diana Shealy
译者：孙思
责编：孙思，关注数据库领域，寻求报道或者投稿请发邮件sunsi@csdn.net，另有「CSDN 高级数据库技术群」，内有诸多知名互联网公司的大牛，欢迎加微信sunlovesi申请入群，备注姓名+公司+职位。

它发生在我们所有人身上，你会收到新的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

你决定如何与快照表工作一致是很关键的。根据上下文和目标，两种处理的方法是有效的。

寻找模式

当调查数据验证问题时，我发现它很有用，试图找到模式中的一些错误。比如，像这样的一些问题：

所有的数据都受到影响吗？
受影响的数据都来自同一组吗？
这些差异是成正比的，还是随机的？
有没有日期的模式？

帮助你缩小一个潜在的原因。如果所有的数据都受到影响，罪魁祸首通常是在脚本或查询中，而不是在数据本身。然而，如果我注意到某个月或某天有明显偏低，我将去调查基础数据。这可能意味着数据收集的问题发生在那个时间段。

如果数据验证往往按比例与原始数据相比，它可能意味着一些数据一直没有被捕获在你的聚合中。基本逻辑错误往往呈现出“随机”，意思似乎没有可识别的模式。然而，这种情况是由于不正确处理或简单，故障逻辑的边缘情况下发生的。

从头开始搜查

你已经尝试了一切，你仍然无法搞明白。现在，是时候开始挖掘了。虽然这很容易从错误的答案开始并且逆向工作，或从这个地方开始你认为这都是错的，但你必须从头开始。

数据中的错误刚开始可能为良性的，但随着你的工作分析，带来的问题是指数变的更差。就像一个数学题：从一开始，找到错的位置。这部分可能繁琐和耗时，但在用完了所有技术后，回到最初状态，观察你的数据是如何一步步的变化的，这有助于查询断点以及断点位置。

分享到：