大数据分析工程师入门 ◀ 排查数据问题思维

悠悠 2023-05-29 05:03 10阅读 0赞

> 前两篇文章都是在讲，面对一个业务问题，你该如何处理，有各种分析方法，也有系统性的解决方案。那么，分析出来的数据或者某个指标出现问题的时候，我们该怎么办呢？别急，本文作为分析思维的第三篇文章，就重点和大家聊聊，如何去排查数据问题。

## ##

**1.为什么要讲排查数据问题的思维？**

数据分析工作和其他功能开发工作很大的一个不同是，功能开发一旦完成并通过测试，一般就可以比较稳定地长期运行，因为它的输入是相对稳定的。但是数据分析师得出的数据指标和分析结论，却很难保持稳定，因为输入数据是每天都在源源不断产生，你很难保证数据没有大的波动，而输入的不稳定，就可能会引发数据问题。另外，由于指标数量众多，数据处理和分析的流程很长，中间环节出现纰漏也在所难免。当然，这里说的数据问题，不一定是真有问题，但是出现大的波动，你也总要排查一轮，心里才比较安心，才敢相信这是合理的波动。

举个例子，作为视频行业，暑期结束后，你的日活和播放量大跳水，降低幅度超过20%，你猜想很大概率是和学生开学有关。但是，你又不得不排查一轮，才能安心地相信就是这个原因，因为既然是数据分析师，当然要用数据说话喽。至于怎么查，我们正文中再细说。

所以，对于数据分析师而言，工作中很重要也出现频率很高的一部分内容，就是排查数据问题。

## ##

**2.本文的课程目标是什么？**

作为入门课程的一篇，本文不求可以穷尽所有的排查思路，只是将比较重要的思路和做法，讲解给大家听，希望可以对大家的工作能够有所帮助。你也可以在自己的工作中，结合自己公司的业务，不断实践和总结出自己的一套思路出来。

**3.本文的讲解思路是？**

第一部分，讲解我们常遇到的问题类型。

第二部分，常用排查思路的总结。

第三部分，我们该如何去总结自己的思路。

## 常见数据问题类型及排查思路 ##

有时候的数据问题不一定是真的存在问题，可能只是看起来像是有问题一样，实际上就是一种正常的抖动。数据问题排查到最后，一般有两种原因，一种是存在bug或者流程异常，导致数据结果不对，修复相应bug，恢复数据即可；还有一种是，业务出现了问题，通过数据表现了出来。以下罗列也只是常见的问题类型，不一定穷尽了所有情况，如果你有其他见解，也请在留言区告诉我。

## ##

**1、数据缺失**

数据缺失，通常是说缺少某个应该存在的数据。一般有以下三种情况，我们来逐个介绍其现象，并讲解下通常的排查思路。

一是一个每天都统计的指标，突然某天没数据了，例如，每日首页访问人数，突然有一天没数据了。这种情况下，最大的可能性就是统计程序出了问题，没能正确的计算出结果。不过，先不着急去检查程序，还要观察下其他每日指标是否有问题，如果多个每日指标出了问题，那么更大的可能是数据源出了问题，应该优先排查数据源。

二是，某个统计维度下，缺少了某个维度值的数据，例如，各节目类型播放人数，少了一个节目类型的播放数据。这种情况下，要优先检查统计逻辑是否存在bug，如果是新做的指标，检查代码逻辑就可以了，如果是之前做了很久的指标，最近出的问题，那么很大的可能性是谁改动了相关逻辑，影响到了这个统计程序，要从最近的代码改动入手去排查。当然，也有可能是数据仓库相关的代码逻辑改动，导致数据的异常，所以数仓的代码改动，也要考虑进来。

三是，多指标联合的场景，缺少某个纬度值的数据。例如，各渠道的新增用户数、日活、总用户数的数据，缺少某个渠道的数据。这种情况，可能性最大的就是你在把多指标联合时，也就是join时，没有考虑到某个渠道可能在某个指标上没有数据，例如，缺失的渠道没有新增用户数，采用内连接的方式，就会导致这个渠道在最终结果里看不到。

**2、数据偏高或偏低**

数据偏高或偏低，都是属于数据表现出离群性，看上去有点不合理，虽然造成它们的原因可能不同，但是排查思路是相似的，所以，后面我们就以数据偏高为例来进行说明。首先要说明一点，不论是偏高或者偏低，不一定是真的有问题，要结合自身的业务特点与实际场景，有可能就是某些突发事件，造成的业务抖动。例如，某天我们发现前一天播放量下降了20%左右，一番排查后，发现前一天是双11，淘宝做了比较大力度的促销活动，引发全民疯狂抢购，结果导致当天我们的播放量产生了比较大的抖动，第二天就恢复正常了。

数据偏高问题，首先要排除数据源层面的问题，可以和上周、上个月的相同时间点的总体数据量做比对，也可以查看24时段分布情况，同时也可以请数仓同学排查数据收集系统和ETL程序有没有异常日志。其次，可以采用对照比较的方法，将该数据和其他相近的数据做比较。例如，现在的问题是某个专题的播放量偏高，可以对比该专题的曝光、点击等行为的统计数据，另外还可以和相近位置的其他专题做比较。有了对照做参考，我们容易确认是否存在异常。另外，还有一种可能性是和版本升级有关，可以增加一个版本维度，对比各版本的数据是否存在某个版本明显不正常的情况。

**3、数据趋势存在异常**

这里我们所说的趋势异常，是指应该呈现规律性变化的数据，出现了不符合历史规律的情况。这种问题一般很难排查，首先你要区分，该数据是呈现强规律，还是弱规律。如果是弱规律，那么波动可能是正常的，只需要确认数据源和统计程序没有问题就行了。如果是强规律，则要分析数据是高了还是低了，头脑风暴下可能的原因是什么，然后再逐个排查。一般容易出问题的点是，数据源的问题或者特殊事件的影响，可以考虑优先排查数据源，然后通过多维分析的方法，对可能引发问题的原因进行排查。

**4、数据互相矛盾**

数据相互矛盾，是指多个数据之间存在矛盾。常见的一种情况是，从报表系统查出来多个有关联关系的指标，结果发现他们有矛盾。比如，查到订单量、平均客单价和订单总金额三个数据，发现订单量乘以平均客单价和订单总金额差异很大；或者是各个频道的人均播放时长的平均值，比总体的人均播放时长大很多。这种情况，最常见的一种原因是不同指标的统计口径有差异，需要重新理清各指标读取的数据源以及统计逻辑，找到矛盾点。

**5、数据违背常识**

数据违背常识，是指数据出现了常识性的错误。比如转化率大于100%、用户的播放时长大于使用应用的时长等。这类问题，通常都是统计逻辑的问题，应该重点排查程序的统计逻辑。当然，也有一种可能性，是数据源存在问题，需要对数据追踪溯源，排查是哪个环节导致了数据的丢失。

## 排查思路总结 ##

在进行问题排查时，我们要抱着大胆怀疑，小心求证的态度。不要假设某个地方不会出问题，如果这个假设前提是错误的，你将永远陷入困惑的漩涡，要敢于大胆怀疑一切，不放过任何线索，综合所有知识，寻找问题的答案。

## ##

**1、排查数据源**

在遇到数据问题时，最好要先保证数据源没有问题。但是，并不是每次都要去查一遍数据源，而是要有这方面的意识。所以，最好在数据收集和数据ETL过程中，多打一些日志，并对程序和关键节点做监控，如有异常，要及时告警出来。这样，每次排查问题前，可以先检查下，是否有错误日志，或者告警信息。

当然，有时即便没有错误日志或告警信息，也不代表数据源没有问题，可能是数据程序中的某个bug，导致数据不正常。这时，需要首先缩小范围，明确是数据源层面的问题后，再去排查相关的代码逻辑。

数据源层面的问题，也有可能是采集端版本更新引入的bug导致的，所以在排查时也要考虑到这个因素，请相关部门的同事协助排查。

**2、多维度分析**

有些数据问题，排查方向一开始会觉得比较模糊，这时可以使用多维度分析的方式，使其逐步清晰。例如，遇到日活下降的问题，数据偏低，可以对日活的时段、地域、版本、终端、渠道等维度进行分析，查看是否在某个纬度值上有明显的降低，以进一步的去排查。举个实际的案例，之前发现公司新上线的视频应用，在推广一段时间后，人均播放时长逐步下降。我们通过上述各维度的分析，最后发现新版本的人均播放时长明显降的更厉害，所以猜测可能是版本问题，最后经由前端同事协助排查发现是合作方的SDK存在一个bug，导致我们数据上报时存在漏报的情况。

**3、对照分析**

对照分析的要点是找到一个参照系，从而确定是否有问题，以及问题的大致范围。这种方法是要找一个相近的其他数据，来做一个对比。比如，时间上的相近（上周、上月），位置上的相近（临近的推荐位），类型上的相近（形态上相似），或者业务上的相近（相似的业务场景）等。有了参考之后，你才更容易判断数据的合理性。对照分析的核心要点是找到可以对比参考的内容，最好是可以找到多个可以对比的点，综合分析，得出结论。

**4、debug代码逻辑**

其实大部分的数据问题，最后查下来都是程序bug。但是，有时统计逻辑过于复杂，bug非常不好找。我的建议是，分段排查，可以考虑把中间结果存储下来，或者抽取部分数据打印出来，然后分段逐个比对，不断缩小范围，最后定位到问题。

**5、由近到远，由简单到复杂**

排查的过程，应该符合先考虑和异常数据关系最近的维度或指标，排查过后再考虑较远的指标。执行排查时，也要先排查简单的方案，再排查复杂的方案。这是因为，排查过程中，可能会发现新的疑点，帮你找到新的线索，所以要先做能尽快执行的方案。

## 不断总结，持续精进 ##

排查数据问题，是数据分析师工作中很重要的一部分。而且同样的数据问题，可能会反复出现。所以，比较好的做法是，每次排查后都做下总结，在一个公共页面上，记录下问题的现象、排查的过程、找到的原因、对应的解决方案。这样不断积累下来，后续排查问题的效率就会越来越高，并且可以让自己以后避免再犯类似的错误，持续精进自己。

那么，在进行总结时，我们要注意以下几点：

**1.问题描述要清晰，排查步骤要明确。**

这里说的描述清晰是指要把问题发生的背景和现象都要写清楚，这样其他人才容易看明白。另外排查步骤要进行总结，这里不是写最终找到问题原因的那个排查方向，而是把所有做了的，都按照顺序记录下来。因此，下次在遇到类似问题，可能问题原因不是上次的原因，但是排查方向是可以参考的。

**2.回顾排查过程，提出更好的思路。**

在排查完成后，要复盘下排查的过程，设计更好的排查思路，在下次遇到类似问题时，可以更快地找准排查方向。

**3.要有交付意识****。**

在记录相关文档时，要有交付的意识，即你写的东西是为了让别人能看懂，而不是写给自己看，要从方便他人阅读的角度去写，尤其是有些业务背景知识或技术知识，不能默认大家都知道就不写，应该关注的是逻辑链的完整性，如果缺少了某个知识，逻辑推断会有点跳跃，就要把它也记录下来。