数据仓库体系 第一模块:场景题深度剖析

转载 果汁私房课

第一模块:场景题深度剖析

1. “数据出现问题怎么排查”？排查数据问题思维!!

1.1、为什么要讲排查”数据”相关问题的思维？

数据开发、数据仓库工作和业务系统开发工作很大的一个不同是，业务系统功能开发一旦完成并通过测试，一般就可以比较稳定地长期运行，因为它的输入是相对稳定的。但是数据仓库开发加工的数据模型、数据指标和分析结论，却很难保持稳定，因为输入数据是每天都在源源不断产生，你很难保证数据没有大的波动，而输入的不稳定，就可能会引发数据问题。

另外，由于指标数量众多，数据处理和加工分析的流程很长，中间环节出现纰漏也在所难免。当然，这里说的数据问题，不一定是真有问题，但是出现大的波动，你也总要排查一轮，心里才比较安心，才敢相信这是合理的波动。

场景:金融信贷业务，月初的时候和月末的时候，你的申请借款人数和逾期率出现大波动，降低幅度超过20%，你猜想很大概率是和？？？有关。但是，你又不得不排查一轮，才能安心地相信就是这个原因，因为既然是数仓工程师，当然要用数据说话喽。至于怎么查，我们下边细说。

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

怎么监控指标波动？怎么预警？

1.2、目的是让大家在面试和入职后都有一个思路去解决数据排查相关问题？

这次分享是将比较重要的思路和做法，讲解给大家听，希望可以对大家的工作能够有所帮助。你也可以在自己的工作中，结合自己公司的业务，不断实践和总结出自己的一套方法论出来。

1.3、常见的数据问题类型和排查思路？

⼀个数据质量引发的问题

业务人员问你们

你们出的数为啥跟xxx出的不⼀样，我该信任哪个？

我们拿到的设备性别数据，⼀半都是空的，我咋算偏好？

我们买量的数据，都是下午才出来，早上的时候，我拍脑袋？

有时候的数据问题不一定是真的存在问题，可能只是看起来像是有问题一样，实际上就是一种正常的模型抖动。

实时数仓架构

数据问题排查到最后，一般有两种原因，一种是存在bug或者流程异常，导致数据结果不对，修复相应bug，恢复数据即可；

还有一种是，业务出现了问题，通过数据表现了出来。以下罗列也只是常见的问题类型，不一定穷尽了所有情况。

1.3.1、数据缺失

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

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

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

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

1.3.2、数据偏高或偏低

数据偏高或偏低，都是属于数据表现出离群性(离群值(outlier)，也称逸出值，是指在数据中有一个或几个数值与其他数值相比差异较大。)，看上去有点不合理，虽然造成它们的原因可能不同，但是排查思路是相似的，所以，后面我们就以数据偏高为例来进行说明。

首先要说明一点，不论是偏高或者偏低，不一定是真的有问题，要结合自身的业务特点与实际场景，有可能就是某些突发事件，造成的业务以及数据模型抖动。

例如，某天我们发现前一天申请借款人数下降了20%左右，一番排查后，发现前一天我们第三方的渠道某个P2PAPP被临时整改下架了.........，结果导致当天我们的申请借款人数产生了比较大的抖动，第二天就恢复正常了。

数据偏高问题，首先要排除数据源层面的问题，可以和上周、上个月的相同时间点的总体数据量做比对，也可以查看24时段分布情况，同时排查数据收集系统和ETL程序有没有异常日志。

其次，可以采用对照比较的方法，将该数据和其他相近的数据做比较。例如，现在的问题是某个渠道的申请借款人数偏高，可以对比该渠道过来的用户的曝光、点击等行为的统计数据，另外还可以和相近事件(OCR识别等)的其他专题做比较。有了对照做参考，我们容易确认是否存在异常。

另外，还有一种可能性是和版本升级有关，可以增加一个版本维度，对比各版本的数据是否存在某个版本明显不正常的情况。

1.3.3、数据趋势存在异常

这里我们所说的趋势异常，是指应该呈现规律性变化的数据，出现了不符合历史规律的情况。这种问题一般很难排查，首先你要区分，该数据是呈现强规律，还是弱规律。

如果是弱规律，那么波动可能是正常的，只需要确认数据源和统计程序没有问题就行了。

如果是强规律，则要分析数据是高了还是低了，头脑风暴下可能的原因是什么，然后再逐个排查。一般容易出问题的点是，数据源的问题或者特殊事件的影响，可以考虑优先排查数据源，然后通过多维分析的方法，对可能引发问题的原因进行排查。

1.3.4、数据互相矛盾

数据相互矛盾，是指多个数据之间存在矛盾。常见的一种情况是，从报表系统查出来多个有关联关系的指标，结果发现他们有矛盾。

比如，查到申请人数量、平均申请贷款额和申请贷款总金额三个数据，发现申请借款单量乘以平均申请贷款金额和申请贷款总金额差异很大；

或者是各个渠道的人均在线时长的平均值，比总体的人均在线时长大很多。这种情况，最常见的一种原因是不同指标的统计口径有差异，需要重新理清各指标读取的数据源以及统计逻辑，找到矛盾点。

1.3.5、数据违背常识

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

1. 排查数据问题总结

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

2.1、排查数据源

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

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

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

2.2、多维度分析

有些数据问题，排查方向一开始会觉得比较模糊，这时可以使用多维度分析的方式，使其逐步清晰。

例如，遇到日活下降的问题，数据偏低，可以对日活的时段、地域、版本、终端、渠道等维度进行分析，查看是否在某个纬度值上有明显的降低，以进一步的去排查。

实际场景中，之前发现公司新上线的APP应用，在推广一段时间后，人均浏览时长逐步下降。我们通过上述各维度的分析，最后发现新版本的人均浏览时长明显降的更厉害，所以猜测可能是版本问题，最后经由前端同事协助排查发现是合作方的SDK存在一个bug，导致我们数据上报时存在漏报的情况。

2.3、对照分析

对照分析的要点是找到一个参照系，从而确定是否有问题，以及问题的大致范围。这种方法是要找一个相近的其他数据，来做一个对比。

比如，时间上的相近（上周、上月），位置上的相近（临近的广告推荐位），类型上的相近（形态上相似），或者业务上的相近（相似的业务事件场景）等。有了参考之后，你才更容易判断数据的合理性。对照分析的核心要点是找到可以对比参考的内容，最好是可以找到多个可以对比的点，综合分析，得出结论。

2.4、debug代码逻辑

其实大部分的数据问题，最后查下来都是程序bug。但是，有时统计逻辑过于复杂，bug非常不好找。

我的建议是，分段排查，可以考虑把中间结果存储下来，或者抽取部分数据打印出来，然后分段逐个比对，不断缩小范围，最后定位到问题。

2.5、由近到远，由简单到复杂

排查的过程，应该符合先考虑和异常数据关系最近的维度或指标，排查过后再考虑较远的指标。

执行排查时，也要先排查简单的方案，再排查复杂的方案。

这是因为，排查过程中，可能会发现新的疑点，帮你找到新的线索，所以要先做能尽快执行的方案。

排查数据问题，是数据仓库工程师、数据分析师、数据产品经理工作中很重要的一部分。

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

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

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

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

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