前段时间公司做了数据治理的专项，其中涉及到跨业务线hive表不合理依赖治理。经过多个周期的治理，取得了一些初步成效，现在将治理方案打包汇总，做一次简单介绍，也供自己复盘使用。
注：为保护公司信息安全，业务信息均为虚构，对于具体的治理节奏和治理成果，不做介绍。
一、背景
什么是跨业务线hive表
hive表所属业务线由hive表所承载的业务确定，以某电商为例，可以粗略划分出电商、外卖、借贷、ese、财务等业务线。跨业务线hive表是指某业务线hive表对其他业务线有一个及以上直接或间接依赖。
为什么要做跨业务线不合理依赖治理
目前跨业务线数仓间hive表引用错综复杂，以至于存在些本不该交叉影响的业务线间存在相互影响的风险。比如电商订单表延迟，导致财务9级基线破线，导致借贷10级基线破保障；比如财务数据产出延迟，导致外卖10级基线破线。业务线间不合理依赖导致一个业务线发生故障时，故障影响范围被不合理放大。
二、 现状盘点
2.1 扩散点数据分布
直接/间接依赖业务线>=3且存在直接跨业务线下游的hive节点
[圈选hive表] -> 扩散点且在10级基线
2.2 跨业务线依赖场景分类
2.2.1 定位为多业务线表，生产耦合
如ESE等中台形数仓，在定位上是多业务线数据，在生产业务线间耦合严重，导致一个业务线故障，所有下游依赖业务线都会受影响
2.2.2 依赖不合理，未依赖合理最小单元
场景1：业务线数仓订单中间表过早融合财务指标
场景2：部分业务线订单表维度过早宽表化
三、解决方案
3.1 治理思路-剪枝
思路一：找到扩散点，以扩散点为锚点，推动直接跨业务线下游切换标准接口；
「跨业务线依赖业务线数>=3」的表owner负责自己对别人的标准接口,推动直接跨业务线下游切换到标准接口以保障自己对下游的影响最小。
思路二：找到直接跨业务线依赖，以直接跨业务线依赖为锚点，和上游确认标准接口进行切换;
直接跨业务线依赖hive表owner推动上游提供标准接口进行自身切换：负责推动上游提供标准接口，来保障自己及下游受跨业务线影响最小
3.2 存量治理方案
思路一：
执行方案：
「跨业务线依赖业务线数>=3」的表owner推动跨业务线的直接下游切换到标准接口
在切换周期内没有完成切换的任务，切后周期后事故判责以
owner没有提供标准接口，且未通知协助下游切换，事故责任为owner
owner完成标准接口提供，且3次+通知下游切换，下游未配合在指定周期内切换，事故责任为下游
优点：
扩散点全部直接跨业务线下游不分等级切换，杜绝了任务优先级升级导致的增量
涉及人员范围固定，方便目标追踪
缺点：
没有直接解决扩散点owner本身的风险
思路二：
执行方案：
「直接跨业务线依赖」的表owner推动跨业务线的直接上游提供标准接口进行自身切换
case分析发现，直接跨业务线依赖表直接下游多为仓内，仓内逻辑一般较为复杂，如果出现上游接口本不该提供的数据，需要表owner协商仓内直接下游的切换处理
在切换周期内没有完成切换的任务，切后周期后事故判责以
owner上游没有提供标准接口，且未协助下游切换，事故责任为owner上游
owner上游完成标准接口提供，表owner未及时完成切换，事故责任为owner
优点：
直接解决可能是“扩散点”本身问题
缺点：
直接跨业务线依赖owner的直接下游大多为仓内，仓内的生产逻辑一般较复杂，比较难在直接跨业务线依赖owner这一层直接切断和直接上游跨业务线依赖
下游作为owner推动上游 这个逆向的解法在执行难度上非常高
3.3 增量治理方案
思路一&思路二：
跨业务线新增场景：
事前
业务线数仓定义跨业务线官方接口
跨业务线表权限审批增加卡口，业务线数仓只能对外提供本业务线数仓内容，不能作为多业务线扩散源
事中
监控增量直接跨业务线依赖
事后
对于增量直接跨业务线依赖合理性进行判断和推进治理
存量表升级（生效基线优先级）导致增量场景：
定制存量表因自身或下游基线升级导致生效基线优先级到10级的监控看板，周维度定点治理
四、 考核指标
目标指标：（限定k级基线）
k级基线n%扩散点完成直接跨业务线下游切换
f个业务线数仓完成跨业务线官方接口定义
观测指标：（限定k级基线）
跨业务线依赖风险系数：跨业务线依赖（依赖跨业务线数>=3）hive表数/全部hive表
k级基线hive表膨胀系数
生产深度：每条k级基线最大深度及叶子节点平均深度
五、总结
跨业务线hive表不合理依赖治理的长期目标是围绕两个核心诉求来设计的：安全、稳定。
安全
当前各业务线之间的表引用没有明确规范，一张表及其敏感数据能否被其他业务引用仅靠领导审批。未来会出台 安全仓 的概念。每个业务线需确定标准的数据对外接口，每个标准接口应符合安全仓规范，并纳入安全仓。
稳定
当前集团整个数据链路相互依赖，假设有5000个节点，那每天就需要保证5000个节点完全不出错才能保证当天的数据基线，通过该治理识别出不合理依赖，实现合理的剪枝，以减少节点保障数量，是的基线保障保障的是真正重要的节点，以提升整体链路的稳定性。
