产品
大多数管理过数仓的同学应该都有一个普遍共识是数据仓库建设时间越长，管理复杂度会越大。一是引入的数据技术越来越多，管理的集群会越来越多；二是参与数据生产和使用的角色和人员会越来越多；三是业务需要引入的数据会越来越多。最后会形成一个特别复杂的数据依赖网络，而数据管理的目标是要不断满足业务的效率、性能、质量、成本、安全等方面不断增长的需求。
在上述背景下，三个问题会越来越突出：
面对上述问题，数据管理复杂度与日俱增，因此我们需要更加精细和更加智能的数据管理手段。
在2022年Gartner提出通过主动元数据管理概念，认为数据管理的中心已经开始从专注于数据内容管理向元数据管理升级，主动元数据是实现智能数据管理最核心的基础。
元数据治理相比于传统的元数据管理平台，有三大区别：
因此，我们认为它是实现智能数据管理的关键。
过去我们碰到过很多问题，难以用人治的方式来解决。所以，在这个背景下我们设计了BigMeta 主动数据治理平台这一产品。其基于独创的算子级血缘技术，将所有数据生产的计算逻辑能够解析到最精细的程度，即算子粒度，通过精细的口径刻画，就可以有一个更加全面的理解，比如我们可以从用户使用数据的行为去进一步刻画这份数据，分析它经常被如何使用，它的重要性以及背后的业务语义是什么。可以建立数据与数据之间的关联，不仅是血缘关联，也可能是一个星型模型中维度表和事实表的关系。基于这样一份精准而全面的数据理解，就可以实现更智能的数据管理和治理。
这一能力是与我们的研发工具、数据工具以及协作工具无缝集成的，是伴随着这些工具一起使用的。
算子级血缘相对于列血缘或者表血缘来说，具有如下特点：
1）字段口径一目了然：无需人工层层分析 SQL 代码，算子级血缘能自动、精确地抽取两个字段之间的加工口径，让字段口径一目了然。
2） 精细刻画依赖关系：算子级血缘能精细刻画字段与字段之间的依赖关系，不论是上游库、表、列、schema变更还是加工口径变更，都可将变更影响评估到行级别，从而大幅降低变更影响评估面。
3） 端到端列级依赖可视：上至业务系统源端，下到BI、AI工具的每一个指标和图表，算子级血缘能更精细地刻画每一条数据链路， 实现更精细的数据治理。我们目前已经做到了99%的SQL解析准确率。
我们目前已经做到了99%的SQL解析准确率，并且在特别复杂的陈年老数仓的客户环境里面得到过验证。我们的算子级血缘能做到实时的五分钟内的变更感知。很多新上线的任务，或者待上线的任务都可以实时地反映到这个血缘里面去，能够更实时地实施数据管理策略。此外在构建血缘的速度上能实现百万级的表在一天内完成血缘构建。
基于算子级血缘，我们在两个地方进行了实践，一个是指标链路的盘点和治理，另一个是主动模型治理。首先来介绍一下指标链路盘点上的实践。
这里举一个我们合作客户的例子，这个客户是一家头部金融机构，其数仓建设已有五年多时间。碰到的最大的问题是监管报送数据经常出现数据质量问题。上游一旦变更，下游根本感知不到，就会导致监管报送的数据口径变化，造成数据质量偏差，受到监管处罚。
在这个背景下，他们希望能够快速理清所有监管指标的上下游依赖，并且能够把每一层链路的加工计算口径都梳理出来，一旦上游发生变更，可以及时快速感知，以便重点保障监管报送这条链路。由于数据链路非常复杂，并且只能做到表级血缘，很难看清楚数据的真正依赖，口径也难以看清，只能通过人工逐层盘点，以其数据规模来看，要盘点清楚整个链路，可能需要30个人盘点一年才能完成，这对业务来说是不可接受的。
我们的算子级血缘，具备口径自动抽取的能力，所以能够帮助他们自动而且持续地完成指标链路盘点。
首先我们实现了基于算子级血缘去对单独列的计算口径独立抽取。
可以通过对用户的ETL脚本进行算子级解析，可以产出如上图右侧所示的结果。上图左侧的SQL是只跟这个列相关的SQL，是对原始SQL做了相关性裁剪之后得到的一个可真实运行的只产出这个列的SQL，这样就能非常清晰地看到这个列的加工口径。
其次，对字段口径进行跨层溯源，自动梳理指标体系。
我们还经常会碰到重复指标或者相似指标的问题。通过对所有字段进行口径溯源，再去对比字段口径，就能够知道数据之间的重复以及差别。
在上图右侧的例子中，有两张表，里面有两个字段很有可能是重复字段，一张表是走规范化建模上去，通过公共层DWS到ADM，而另外一张表可能没那么规范，是直接从ODS和DWD抽数据做出来的。通过解析每一个字段的加工口径，并且基于算子级血缘去做分层展开，最后一直追溯到贴源表，就会发现实际上两张表的最大区别是过滤条件不一样，一般来说这种过滤条件不一样的情况，可以认为这两个指标属于同一个类别谱系。
我们可以通过这种方式对指标进行分类，分类之后再进一步去做精细化的判定。精细判定时，要考虑更多的细节问题，比如多表之间join可能会引起数据的膨胀或者缩减，来界定那两份指标是不是真的精确一致。在此基础上就可以把整个指标体系快速梳理出来，这对指标盘点的效率，是一个革命性的提升。
最后是精准识别业务基线，精准控制保障范围。
在识别出来这些指标之后要对其进行精准的保障。常规的做法是通过任务血缘去做上游追溯。在做指标表的时候为了方便下游使用，常常会把很多指标拼在一张表里，但一张表里面的指标的重要等级实际上是不一样的，它的保障等级也应该不一样。在这种情况下，如果把所有的任务保障全，以任务粒度去直接做上游穿透会发现要保障的面会非常宽，各种噪音也会特别多。有了算子级血缘管理之后，可以实现基于每一列去做上游穿透，能够裁剪掉大量无关的表任务，从而做到精准控制保障面。
如何实现更加智能的数据治理，是我们目前在做的一些实践。在整个数据治理里面最难的事情就是模型治理。数仓建设过程中，越来越多的“坏味道”会引发数据无序膨胀、链路不断加长、重复数据爆炸等问题。
比如同一个主体反复拼接维度形成套娃：一个用户可能看到有一张表中很多数据是他需要的，但是少两列，于是就自己拼两列，并且裁剪掉那些他不需要的列。之后可能其他用户又看到了这张新表，根据他的需要又继续拼。最后发现这些数据其实是可以被一张表或者几张表承载的。反复的拼接，就会导致数据重复和链路加长的问题。
另一个例子是重复计算，一份资产有多个相似的下游任务，我们建公共层的时候可能没有预期到有一些相似的下游需求，可能少建了一个或几个字段，其他同学就要基于这个字段进行重复加工。
还有一些情况是多个团队各自为政，对相似的需求做了不同数据链路，就形成了烟囱模式。
另一个常见的问题就是不合理的下游节点依赖，用户可能不知道数据仓库里面有多少数据，随便选张熟悉的表就开始依赖了，但实际上也许有更好的中间层可以被依赖，所以导致数据链路在不断加长，带来时效问题。
在这样的背景下，如果想实现整个模型治理的自动化或者说持续性治理，最关键的是要让模型治理更加主动，而不是等到问题出现之后再去做重构。
我们希望实现的第一个目标是主动识别链路中的坏味道；第二个是基于这个坏味道自动生成一些模型重构的建议；第三个是做出来这个模型上线之后能持续保持健康，能在一些错误用数的场景下，给用户更好的建议，保证用户可以正确地使用模型。
首要问题是如何识别数据链路中的问题。在规模特别大的数据网络中，要去逐一匹配工程浩大。所以，我们把问题分成两个步骤。由于大多数坏味道的关键特征是重复，所以我们基于字段口径以及溯源口径，做了一个自动的判重扫描算法。核心是基于一个给定的起点或者一批给定的起点去做多层的上下游扩散，去扩散出一批相似表，这批相似表的核心判断依据是字段口径的重复度。判断出来之后，就可以把这些相似表进行分组，再去还原其数据血缘，进行子图匹配。
以一个套娃为例，一旦发现这批相似资产，还原出它的数据血缘结构如上图所示，那么就认为其疑似套娃，接下来对它做进一步的确认和分析，去发现数据重构或者数据模型治理的机会，在这个阶段靠血缘就不够了，我们需要对整个图结构做算子展开。在算子展开之后，我们就能够发现这份数据的加工过程中先做了两表join，然后做了过滤等步骤之后，拿到了这张表，我们发现这些表最后是可以被合并的。合并依据是可以基于这个算子链路去做一个算子变换，我们可以有一个预设，就是把所有的数据都合并到顶端这张表里面来，那意味着要把一定的算子下推下去，比如过滤条件和汇总条件。下推下去之后就会有一张c表，就是完整的所有数据。原来的下游表t2和t3表，需要补上过滤条件。
模型治理完后，为时效和成本带来了哪些改变，我们可以基于算子去做代价评估,让评估结果做为治理的依据。
要保证模型的长治久安，关键就是下游后续的数据使用不会出现重复建设，或者使用到已下线的数据，最后导致模型要么被空心化，要么没有被真正用起来。我们目前正在探索的一件事情，就是把前述技术用在更实时或者更前置的阶段：当新的公共层模型建设出来之后，系统在下游用户编写SQL脚本时，能够自动分析用户的脚本编写逻辑，同时把它的算子数据去做展开，与已有数据模型去做对比。一旦发现已有非常相似的表存在，或者是用了一些即将下线的表，那么在代码编写过程中就直接给出建议，并且更进一步地，对他的代码能够进行改写。这样能够使得模型切换过程更加顺滑，它的保鲜能力也会更强。
最后，进行一下总结，我们认为一个主动元数据治理平台要解决三个问题，第一个问题是如何把全域元数据聚合起来，并形成相互联通的元数据图谱；第二个是精准地理解和刻画每份数据的计算口径和背后的业务语义；第三个是在数据治理、管理以及模型建设过程中，能够提供更加智能的建议。
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
