数据开发、数据仓库工作和业务系统开发工作很大的一个不同是，业务系统功能开发一旦完成并通过测试，一般就可以比较稳定地长期运行，因为它的输入是相对稳定的。但是数据仓库开发加工的数据模型、数据指标和分析结论，却很难保持稳定。因为输入数据每天都在源源不断产生，很难保证数据没有大的波动，而输入的不稳定，就可能会引发数据问题。另外，由于指标数量众多，数据处理和加工分析的流程很长，中间环节出现纰漏也在所难免。当然，这里说的数据问题，不一定是真有问题，但是出现大的波动，也总要排查一轮心里才比较安心，才敢相信这是合理的波动。有时候数据出现问题并不一定真的存在问题，可能只是看起来有问题，实际上就是一种正常的模型抖动。数据问题排查到最后，一般有两种原因，一种是存在bug或者流程异常，导致数据结果不对，修复相应bug，恢复数据即可；还有一种是，业务出现了问题，通过数据表现了出来。
2、常见数据问题
数据缺失
即缺少某个应该存在的数据，有以下这些情况
1、每天都在统计的指标，突然某天没数据了。
案例：每日申请借款人数，突然有一天没数据了。对比发现同一个业务系统的抽的数据都为空值，在经过打印数据源那块日志，发现采集异常，抽不到数。最后经由前端同事协助排查发现是合作方的 SDK 在一个 bug，导致我们数据上报时存在漏报的情况。
思路：1）先观察下其他每日指标是否有问题，如果多个每日指标出现问题，那么极有可能是数据源出了问题，优先排查数据源。2）如果其他每日指标没有问题，极有可能就是统计程序出了问题，没能正确计算出结果。
2、某个统计维度下，缺少了某个维度值的数据。
案例：各渠道申请借款人数，少了某个渠道的申请人数数据。经过检查发现我们第三方的渠道某个APP 被临时整改下架了，导致该渠道的相关指标发生变化。
思路：1）指标比对，同样渠道的其他指标有没有数据，如果也没有那么很可能是数据源出了问题（数据源打印日志），如果有数据，那么很可能代码有问题，就去检查代码。2）如果是新做的指标，就检查代码逻辑。3）如果是之前做了很久的指标，最近出了问题，那么极有可能是谁改动了相关逻辑，影响到了这个统计程序，要从最近的代码改动入手去排查。也要考虑到数据仓库相关的代码逻辑改动。
3、多指标联合的场景，缺少某个维度值的数据。
案例：各渠道的新增用户数、日活、总用户数的数据，缺少某个渠道的数据。
思路：极有可能是join时没有考虑到某个渠道可能在某个指标上没有数据，例如，缺失的渠道没有新增用户数，采用内连接的方式，就会导致这个渠道在最终结果里看不到。
数据偏高或偏低
数据偏高或偏低，都属于数据表现出离群性，看上去有点不合理。（离群值(outlier)，也称逸出值，是指在数据中有一个或几个数值与其他数值相比差异较大。）但数据不一定真的有问题，要根据业务特点与实际场景分析，有可能就是某些突发事件，造成的业务以及数据模型抖动。例如，某天发现前一天申请借款人数下降了20%左右，一番排查后，发现前一天我们第三方的渠道某个APP被临时整改下架，导致当天我们的申请借款人数产生了比较大的抖动，第二天就恢复正常了。
案例：之前发现公司新上线的 APP 应用，在推广一段时间后，人均浏览时长逐步下降。最后增设版本维度，对比发现新版本的人均浏览时长明显降的更厉害，最终确定是由于新版本不稳定，数据漏报，导致数据偏低。
思路
1、首先要排除数据源层面的问题，可以和上周、上个月的相同时间点的总体数据量做比对，也可以查看24时段分布情况。同时排查数据收集系统和ETL程序有没有异常日志。
2、其次，可以采用对照比较的方法，将该数据和其他相近的数据做比较。例如，现在的问题是某个渠道的申请借款人数偏高，可以对比该渠道过来的用户的曝光、点击等行为的统计数据，另外还可以和相近事件(OCR识别等)的其他专题做比较。有了对照做参考，就容易确认是否存在异常。
3、再次，还有一种可能性是和版本升级有关，可以增加一个版本维度，对比各版本的数据是否存在某个版本明显不正常的情况。
数据趋势存在异常
指应该呈现规律性变化的数据，出现了不符合历史规律的情况。这种问题一般很难排查。
首先要区分该数据是呈现强规律，还是弱规律。
如果是弱规律，那么波动可能是正常的，只需要确认数据源和统计程序没有问题就行了。
如果是强规律，则要分析数据是高了还是低了，头脑风暴下可能的原因是什么，然后逐个排查。一般容易出问题的点是，数据源的问题或者特殊事件的影响。
数据相互矛盾
指多个数据之间存在矛盾。常见的一种情况是，从报表系统查出来多个有关联关系的指标，结果发现他们有矛盾。
案例：某一天发现各个渠道的人均在线时长的平均值，比总体的人均在线时长大很多。发现发现申请借款单量乘以平均申请贷款金额和申请贷款总金额差异很大。
思路：不同指标的统计口径有差异，需要重新理清各指标读取的数据源以及统计逻辑，找到矛盾点。
数据违背常识
指数据出现了常识性的错误。
案例：比如用户的申请借款时长大于使用应用的时长，风控转化率大于 100%等。
思路：这类问题通常都是统计逻辑的问题，应该重点排查程序的统计逻辑。也有可能是数据源存在问题，需要对数据追踪溯源，排查是哪个环节导致了数据的丢失。
3、数据问题排查方式
在进行问题排查时，我们要抱着大胆怀疑，小心求证的态度。不要假设某个地方不会出问题。
排查数据源
在遇到数据问题时，最好首先保证数据源没有问题。但是，并非每次都要去查一遍数据源，而是要有这方面的意识。
1、最好在数据采集和数据ETL过程中，多打一些日志，并对程序和关键节点做监控，如有异常，要及时告警。这样，每次排查问题前，可以先检查下，是否有错误日志或者告警信息。
2、有时即便没有错误日志或告警信息，也不代表数据源没有问题，可能是数据程序中的某个bug，导致数据不正常。这时，需要首先缩小范围，明确是数据源层面的问题后，再去排查相关的代码逻辑。
3、也有可能是采集端版本更新引入的bug导致的，所以在排查时也要考虑到这个因素，请相关部门的同事协助排查。
多维分析
有些数据问题，排查方向一开始会觉得比较模糊，这时可以使用多维度分析的方式，使其逐步清晰。
例如，遇到日活下降的问题，数据偏低，可以对日活的时段、地域、版本、终端、渠道等维度进行分析，查看是否在某个纬度值上有明显的降低，以进一步的去排查。举个实际案例，之前发现公司新上线的APP应用，在推广一段时间后，人均浏览时长逐步下降。我们通过上述各维度的分析，最后发现新版本的人均浏览时长明显降的更厉害，所以猜测可能是版本问题，最后经由前端同事协助排查发现是合作方的SDK存在一个bug，导致我们数据上报时存在漏报的情况。
对照分析
对照分析的要点是找到一个参照系，从而确定是否有问题，以及问题的大致范围。这种方法是要找一个相近的其他数据，来做一个对比。比如，时间上的相近（上周、上月），位置上的相近（临近的广告推荐位），类型上的相近（形态上相似），或者业务上的相近（相似的业务事件场景）等，有了参考之后，你更容易判断数据的合理性。对照分析的核心要点是找到可以对比参考的内容，最好是可以找到多个可以对比的点，综合分析，得出结论。
debug代码逻辑
大部分的数据问题，最后查下来都是程序bug。但是，有时统计逻辑过于复杂，bug非常不好找。此时应该分段排查，可以考虑把中间结果存储下来，或者抽取部分数据打印出来，然后分段逐个比对，不断缩小范围，最后定位到问题。
由近到远由简单到复杂
排查的过程，应该符合先考虑和异常数据关系最近的维度或指标，排查过后再考虑较远的指标。执行排查时，也要先排查简单的方案，再排查复杂的方案。这是因为，排查过程中，可能会发现新的疑点，帮你找到新的线索，所以要先做能尽快执行的方案。
4、数据排查的总结
排查数据问题，是数据仓库工程师工作中很重要的一部分。而且同样的数据问题可能会反复出现。所以比较好的做法是，每次排查后都做总结，在一个公共页面(WIKI)上，记录下问题的现象、排查的过程、找到的原因、对应的解决方案。这样不断积累下来，后续排查问题的效率就会越来越高，并且可以让自己以后避免再犯类似的错误，持续精进自己。
在进行总结时，要注意以下几点：
1.问题描述要清晰，排查步骤要明确。描述清晰指要把问题发生的背景和现象都要写清楚，这样其他人才容易看明白。排查步骤要进行总结，不仅要写最终找到问题原因的那个排查方向，而是把所有做了的，都按照顺序记录下来。下次再遇到类似问题，可能问题原因不是上次的原因，但是排查方向是可以参考的。
2.回顾排查过程，提出更好的思路。在排查完成后，要复盘下排查的过程，设计更好的排查思路，在下次遇到类似问题时，可以更快地找准排查方向。
3.要有交付意识。在记录相关文档时，要有交付的意识，即你写的东西是为了让别人能看懂，而不是写给自己看，要从方便他人阅读的角度去写，尤其是有些业务背景知识或技术知识，不能默认大家都知道就不写，应该关注的是逻辑链的完整性，如果缺少了某个知识，逻辑推断会有点跳跃，就要把它也记录下来。