离线数仓数据源的变化对数仓的影响是巨大的，所以我们不但要做好事后监控，也要做好事前的各种流程制度规范，比如所有业务的升库语句需要DBA对其进行管控，只能由DBA进行升库处理，并且做好处理记录，同时把相关变更通知到数据部门。为了防止有导致异常的致命性错误，最好能把binlog监控的就监控起来，这样数据部门才能更好的管控数据，这里我们只罗列相关的变更场景及事后的应对方案。
变更场景:
1.业务方的相关业务下线，表数据一直未更新。
2.业务逻辑变化，某些字段暂停使用。
3.业务新增字段。
4.业务删除字段。
5.业务新增业务，新建表。
6.业务删除表。
应对方案:
针对第1点，源头表未使用这种场景不会导致数仓任务报错，但是比较致命和浪费集群资源，可以在表入仓时，标记好相关表的更新频率，在线业务表，变更会比较频繁，字典表、码表之类的变更没那么频繁，可以针对在线业务表进行binlog监控，如果30天甚至更久都没有变化，可以发一个告警通知给相关方，并且创建需求备忘录，如果没有影响，则由项目负责人进行关闭。
针对第2点，某些字段暂停使用的情况，这种场景下只有通过监控字段的空值率来判断，关键字段空值率高了就告警。
针对第3点，新增字段对于数仓现有业务影响不大的，可暂时忽略，只需通知出来即可，但是数仓为了任务不报错，在开发数据同步任务时需要指定同步的字段。
针对第4点，删除字段这种情况数仓如果未提前做处理，必然会导致数仓报错，可在同步系统添加一个源表字段和数仓表字段的映射关系校验，发现源头没有的字段，数仓有的进行紧急告警。
针对第5点，新建表这种数仓不会有任何报错，可以在binlog监控到这种情况后，提示通知数据分析人员，可能有新增业务。
针对第6点，业务删除表，如果数仓正在用这个表，任务未提前下线，数仓任务会报错,这种场景可以在拉数据前，先判断一下表是否存在。
总之源头表变化对数仓的应用有影响的，需要把从源头表开始下游的所有表梳理出来，并提示可能受影响的数据应用负责人。
