群友分享美团数据实习面试题（问的都是数据质量相关）

最近群里有同学找实习被某大厂问到数据基线和sla提效的问题，

在我的简历中，说到了数据基线和sla提效的问题，被问到了是怎么提效的？

（1）基线排查问题：首先点开基线，基线有个甘特图，点开后会展示每一个任务的运行时间，知道末尾的节点，及运行时长，因此可以定位它每一段到底哪个任务运行时间最长，在哪个任务卡住，甚至还能发现，部分任务中间有间隔（例如任务定时7点执行，但上游5点执行结束，导致2小时浪费），先定位各任务样貌。

（2）同步任务运行时间过长：在梳理完基线后，由于数据表是全量同步，因此发现同步数据花了近3小时，同时dwd也保持全量读取，因此都会导致数据变慢，可以对任务进行全量改增量处理。

（3）计算任务运行时间过长：毫无疑问属于这种情况明显是数据倾斜，因此需要通过web ui看到任务卡点进展，从而做出倾斜优化操作，由于倾斜优化也可以谈很久这里简单带过。

（4）基线重叠：多条高优先级基线重叠一个时间去运行，一般来说凌晨3-5点是任务高峰期，对于非核心基线如果要求上班前产出可以将基线任务往后挪一些，例如6-8点执行，不要占着资源，因为那个时间，别人高优任务你的任务抢不过，因此要么往前推 （从0.10分附近提前运行即可），要么往后挪，分流治理。

（5）依赖算法等任务产出过晚：还有一个情况就是你的任务依赖了别人的任务，别人的任务依赖了算法任务，只是为了添加个字段，算法任务每天跑4-5小时，导致依赖别人的数据表整体产出晚，可能那个算法标签对于那个任务很重要，因此可以提前跳过他，往更上游去取逻辑，把算法任务跳过。

（6）烟囱表过多导致数据链路较长：经过长期迭代后，数仓内部数据表及任务都在野蛮生长，因此数据表越来越宽，整条链路依赖错综复杂，最终使产出时间也越来越晚，因此需要对指标及逻辑下沉放入模型中，减少ads建设数量，缩短链路，减少任务运行时间。

数仓建设中如何降低开发返工率

重点保障上线前质量，开发前会进行数据模型评审，开发后进行试跑、数据探查、数据比对、抽量数据比对、空置预览、DQC配置等，最后让mentor code review，这些前置措施都可以保障数据质量交付，减少事故发生，返工率更多是业务方提出数据质量问题情况导致继续返工开发，因此简化版可以使用飞书问卷让业务填报数据问题进行记录再每日将飞书数据同步至数仓中进行计算，复杂版可以做一个数据问题申报平台让业务方填报数据问题。

数仓建设中出现源头数据质量问题如何修复监控

这个问题和我之前讲的课程中源头数据质量长期跟踪监测方案是一个问题，那假设我们有一个用户表，用户的年龄是空或者说部分字段有缺失，这种需要长期监测跟踪并把问题数据提供给后端填补上，同时可以做一套dwd明细模型出来去监控存在问题的数据，并传输给后端修复，同时也可以给予明细表搭建看板，让参与人能看到治理效果，双方都可以拿到治理绩效。

如何减少DQC的误报和漏报

DQC频繁告警，像表行数波动，是最多告警的，可以用线性回归的办法去再次跟踪他的一个情况，或者说我们可以通过同环比同时去限制，去决定是否高级。还可以通过或者说我自己手写sql，我自己去看一下，比如说哪一个时间段儿，那他报的是正常的，哪一个时间段儿他报的是不正常的，都可以去监督现在告警误报，漏报通常是配置DQC出现了问题导致没监测到。