一、元数据管理平台介绍
背景介绍
1. 货拉拉大数据体系
首先来介绍一下货拉拉大数据体系的整体架构，这一体系自底向上构建，其中基础层与接入层，这两层主要承载着最基础的存储能力、计算能力以及数据接入功能。向上是平台和数仓层，这里集成了数据研发平台、数据治理平台，以及数据资产管理。再向上是服务层，这层面向多样化服务场景，开发的大数据一系列应用，涵盖数据应用支撑、各类服务工具、数据服务工具，以及数据智能所需的支撑工具。最上层是应用层，聚集了辅助决策类应用和赋能业务类应用，它们直接服务于公司的决策制定与业务优化。整个大数据体系中呈现出一种相互依存、相互支持的紧密关系。
本次分享的重点是元数据管理平台，该平台作为大数据体系的元数据中心，其核心职责涵盖了元数据管理、数据资产管理以及成本治理三大方面。
2. 元数据管理平台
当大数据体系发展到一定规模时，必然会遇到一系列挑战，例如：所需数据究竟在何处？如何清晰梳理这些数据之间的上下游关系？数据治理靠什么来驱动？以及数据资产是如何管理的？为解决这些难题，元数据管理平台应运而生。接下来将重点围绕这四个核心议题，介绍货拉拉针对这些问题所制定的解决方案及实践经验。通过这些内容，您将更加全面地了解我们如何利用元数据管理平台来保证数据的可寻、可溯、可治，进而提升数据的价值。
3. 元数据管理平台建设过程
元数据管理平台的发展轨迹紧密贴合业务需求的演进，其发展历程可以划分为三个阶段。
早期（21 年之前）：在这一时期，业务场景相对简单，数据资产的规模也不大，主要依赖 Hive ETL 工具进行处理。因此，对于元数据的需求也停留在基础层面，简单的查询功能便足以满足业务需求。
发展阶段（21 年至 22 年）：随着业务的迅猛增长，数据表和任务的资产规模急剧扩张，用户对“找数”和“找关系”的需求日益凸显。为应对这一变化，我们构建了元数据管理系统，支持通过资产名称和描述信息进行搜索，还支持了数据血缘能力。
成熟阶段（22 年之后）：在这一阶段，大数据领域的开源组件与自研平台纷纷登场，元数据管理平台需要承接更多种类的资产类型，并应对更为复杂且时效性要求更高的数据血缘链路。为此，我们升级了元数据管理平台，实现了字段级别的实时血缘追踪能力，以满足上述需求。同时，面对存储与计算资源的紧张，成本治理体系也提上日程。此外，随着资产量的剧增和研发团队的扩大，找数场景也越来越复杂，我们结合大模型将检索能力演进为 AI 智能检索，提供了对话式的找数体验。
发展到现阶段，元数据管理平台的能力趋近于完善。
4. 元数据管理平台系统架构
元数据管理平台的系统架构如上图所示，其核心由采集层、服务层、存储层以及平台数仓层构成。在此架构的两侧，分别对接了多元化的接入方和丰富的应用层。
接入方：涵盖了大数据生态中的基础设施、各类平台工具以及业务系统，它们是元数据管理平台数据来源的基石。
采集层：作为架构中的关键一环，采集层负责适配并对接生产方，采集各类元数据。
服务层：该层提供了查询与分析的服务。
平台数仓层：平台数仓层专注于加工与成本治理相关的数据。通过对底层计算与存储资源的消耗数据的深度挖掘与分析，为企业的成本控制和治理决策提供有力支持。
应用层：最终，这一架构支撑起了一系列应用场景，包括但不限于找数、找关系、资产管理等。这些应用充分利用了元数据管理平台的能力，为用户提供便捷、高效的数据服务体验。
二、元数据管理平台实践
1. 数据血缘
（1）数据链路介绍
数据血缘作为元数据基础设施中的核心要素，其实现与演进过程至关重要。下面，我将详细阐述我们是如何构建和不断完善这一关键环节的。
首先，从宏观视角来看，我们的数据整体链路清晰地划分为采集、存储、计算以及应用四大层面。这一流程始于数据采集阶段，我们采集来自日志、埋点以及订单业务等多个维度的数据，并将这些数据汇聚至大数据平台。
随后，这些数据被妥善存储在大数据平台中，为后续的处理与分析奠定坚实基础。然后通过实时和离线链路分别构建的数仓体系，对数据进行加工处理，加工好的数据提供给各类应用服务进行使用，比如各类报表、看板、用户画像等。这些应用依托高质量的数据支持，为企业决策提供了有力依据。
在这个过程中，数据血缘链路贯穿始终，它详尽地记录了上游数据从采集、存储、加工到最终应用于出口的每一个环节。这种全面的血缘追踪能力不仅有助于我们更好地理解数据的来龙去脉，还能在数据出现问题时迅速定位问题源头，从而保障数据的质量与准确性。
（2）架构演进
在早期（1.0 版本），我们的业务场景较为简单，血缘关系的需求也相对基础。因此我们构建了一个基础的血缘追踪系统。
数据源与血缘追踪：
- 数据源：血缘数据主要来源于研发平台和指标报表等系统。
- 执行引擎：数据通过 Hive、Spark 等大数据处理引擎进行执行。
- 血缘捕获：通过 hook 机制，我们在 SQL 执行过程中捕获并解析输入输出表的信息，随后将这些血缘信息推送到下游系统供其使用。
- 非 SQL 链路处理：针对 MySQL 到 Hive、Hive 到下游终端等非 SQL 数据链路，我们预先定义了一套标准的格式，要求各业务系统按照此格式将他们的血缘关系推送到离线血缘数据仓库中。
数据处理与存储：
- 数据存储：采集到的血缘数据通过定时调度进行解析，并存储至 MySQL 数据库中。
- 血缘更新：我们以产生血缘的调度任务为单位进行血缘的更新。当新版本血缘生成时，旧版本血缘将被替换。
随着血缘能力在研发场景中的价值逐渐被认可，我们对系统提出了更高的要求，特别是血缘的时效性和字段级血缘的支持。为此，我们在 1.0 版本的基础上对系统架构进行了优化和升级。
实时血缘解析：
- 增量更新机制：我们新增了一个实时血缘解析模块，该模块替代了原有的定时更新机制，实现了近实时的增量更新。
- 调度任务变更上报：由于大多数血缘信息是由调度任务产生的，我们引入了调度任务变更上报机制。当任务发生下线或 SQL 更新时，这些信息能够及时反映到血缘数据中，提高了血缘更新的时效性。
存储升级：
- 图数据库 Neo4J：为了支撑更大量级的字段级血缘查询，我们将存储从 MySQL 升级为 Neo4J 图数据库。Neo4J 的强大性能支持了 10 层以上的节点查询，这对许多分析类场景至关重要。
通过上述升级，我们的血缘追踪系统不仅提升了数据的时效性和准确性，还大大增强了处理复杂血缘关系的能力，为研发场景提供了更为强大的支持。
（3）存储模型
在业界主要有两种设计思路。第一种方案是将任务作为节点，通过这些节点来关联不同表之间的关系。这种方式在涉及以任务为切入点进行血缘查询时更加灵活。然而，当查询表之间的关联，尤其是需要进行多层表关系查询时，这种方案可能会增加查询和维护的复杂度，尤其是在节点数量较多的情况下。
相比之下，第二种方案将任务作为边的属性，而表和表之间则建立直接的关联。这种设计在查询和维护方面更为直观和简便。考虑到我们当前的实际业务需求中，暂时没有需要通过任务作为切入点进行查询的场景，我们决定采纳第二种方案作为实现方式。这样做不仅简化了查询路径，还优化了系统的维护效率，更贴合我们当前的业务需求。
（4）解析
接下来是血缘的解析，目前我们以 Hive 作为主引擎，因此接下来主要讲解 Hive 类的血缘解析方式。
在我们开发平台中，Hive 任务形式多样，包括纯 SQL、Python 程序及脚本类任务，这增加了解析的复杂性。
当前，业界主要讨论两种解析方法：一是通过 Hive hook 实现，即在任务执行时从 Hive hook 的上下文中捕获输入输出信息，这种方式无需关心 SQL 的提交方式，但可能存在滞后，因为血缘的更新仅在任务执行后才能生效；另一种是静态 SQL 解析，一般利用开源的语法解析工具在任务提交前进行，虽能即时反映 SQL 变更，但对 Python 或脚本任务的 SQL 提取较为复杂。
因此综合考虑背景和实现复杂度，我们选择了 Hive hook 作为实现方式。
然而，这一过程中也面临了几个挑战：
①血缘与任务关系打通：由于 Hive hook 本身无法直接获取任务信息，我们推动研发平台进行了改造，要求在提交 SQL 时将任务信息一并放入 hiveConf 中，以便在 hook 中能够关联这些信息并传递给下游系统使用。
②任务更新与血缘同步：为确保血缘信息的时效性，我们采用了研发平台主动上报任务下线和更新的机制。这样，当下线或更新任务时，相应的血缘信息也会得到及时更新。
③临时表处理：对于包含临时表的 SQL，如 CREATE TEMPORARY TABLE T1 AS SELECT ... FROM a; INSERT INTO b SELECT * FROM T1;，直接解析会产生不必要的临时节点和关系，影响后续使用。因此，我们在实现中引入了一个缓存机制，构建血缘关系树，并在新血缘到来时进行合并判断。只有当临时表的使用能够合并为正式表之间的直接血缘关系时（如 a 写 b），才会进行下一步的对比、更新和入库操作。
通过这些措施，我们成功实现了基于 Hive hook 的血缘解析，既满足了业务需求，又有效解决了实施过程中遇到的问题。
（5）应用场景
在数据应用方面，我们聚焦于三个核心场景：数据开发效率提升、数仓开发优化、以及数据治理与安全保障。
这里列举了大数据凌晨值班时，链路出问题，需要降级，数据血缘能力在里面起到的一些作用。
在大数据值班的场景中，偶尔会遇到链路故障，导致某些重要数据表当日的数据无法按时产出。此时，为了保障数据供应的连续性，可能需要进行降级处理，比如使用前一日（T+2）的数据作为替代。然而，这一决策并非轻率之举，它要求迅速评估降级操作对下游数据使用方的具体影响范围，并据此做出及时通知。
在这一紧急响应过程中，字段级的数据血缘能力显得尤为重要。它能够直接追溯到受影响的最下游终端，特别是那些标记为 P0 或 P1 优先级的数据出口应用，帮助值班人员快速、准确地评估影响面。这种能力不仅提升了决策的效率和准确性，还有效防止了影响范围的扩大或因降级不当而引发的潜在故障，乃至经济损失。
此外，为了加速信息传递，我们还提供了一键拉群功能，使得值班人员能够迅速将相关团队和人员拉入紧急沟通群组，实现问题的即时通报与协同解决。
2. AI 智能检索
在深入探讨了数据血缘的重要性之后，接下来将介绍我们的元数据检索系统的演进过程。起初，我们采用的是传统的基于关键字的检索方式，这种方式以其快速响应和直接返回匹配结果集列表的特点，满足了基本的检索需求。然而，随着数据使用场景的日益多样化，用户对检索功能的需求也变得更加复杂和精细。
具体而言，传统的关键字检索在面对多关键字组合查询、查询数据表含义、询问数据口径以及业务咨询等场景时，显得力不从心。这些需求要求检索系统能够更深层次地理解用户的查询意图，并返回更加精准和全面的结果。
为了应对这些挑战，我们紧跟技术发展的步伐，特别是在 AIGC（人工智能生成内容）技术蓬勃发展的背景下，我们探索性地将大模型的自然语言处理能力引入到了元数据检索的实际生产场景中。这一创新举措旨在通过大模型对自然语言的深刻理解，来更好地捕捉用户的查询意图，从而提供更加智能化、个性化的检索服务，以满足用户多样化的需求。
为了应对大模型在实际企业应用中面临的本地知识库匮乏及更新时效性问题，我们选择了业界广泛采用的 RAG（Retrieval-Augmented Generation）方案来落地元数据检索场景。
RAG 方案的核心在于，它不仅仅依赖于大模型自身训练时获取的静态知识（这通常主要来源于互联网上的公开信息，且难以实时更新），而是通过引入外部数据源的检索机制，为大模型提供实时的上下文信息。这一机制允许大模型在回答企业专业领域的问题时，能够结合最新的、特定于企业的数据，从而大大提升了答案的准确性和时效性。
具体来说，RAG 方案首先会利用检索技术从外部数据源中检索与用户查询相关的上下文信息，然后将这些信息与用户的原始查询一同输入到大模型中。大模型在接收到这些信息后，会综合考虑检索到的上下文内容和自身的知识库，生成更加精准、全面的回答。这种方式不仅解决了大模型在本地知识库上的局限性，还避免了因直接暴露企业内部数据给大模型而可能引发的数据安全问题。
因此，通过采用 RAG 方案，我们能够更好地将大模型的自然语言处理能力应用于企业的实际生产场景中，为用户提供更加智能、高效的元数据检索服务。
在 RAG 方案的实现中，我们的中间服务层（rag）聚焦于四大核心流程：数据提取、检索、索引与生成。首先，业务知识被接入并分块处理，随后灌入向量数据库中，以便进行高效的向量相似度检索。检索结果随后被送入大模型，结合定制的 prompt 生成最终响应。模型层则灵活适配多种模型，支持找数、口径查询、业务咨询等多样化场景。
针对库表源数据的检索，我们采用的切片策略，是以单个字段为单位进行切割。这种方式确保每个字段独立成块，并在块中保留必要的表信息，优化向量数据库中的存储与检索效率。相较于整表切割，字段级切片有效避免了检索结果超出大模型处理 token 限制的问题。
问答流程简述如下：用户问题首先经过增强处理，并转化为向量化表示；随后通过检索系统获取相关结果，并进行智能重排序；优化后的检索结果结合 prompt 工程进行精细组装，最终由大模型生成准确答案。这一过程确保了问答系统的高效、准确与灵活性。
在实现过程中，我们遭遇了检索漏召、大模型表现不稳定、响应速度慢及测评难题等挑战。针对这些问题，我们采取了以下优化措施：
（1）检索漏召问题
- 问题增强：在向量化检索前，对复杂问题进行拆分或语义增强，以捕捉更多相关信息。例如，将“订单宽表中，这两个字段，哪个字段表示司机实际收入”这个问题拆分为多个子问题分别检索，从而提高信息覆盖率和回答准确性。
- 重排序优化：通过引入轻量级模型对检索结果进行重排序，筛选出与用户问题匹配度最高的前 N 条记录（如 TOP10）再送入大模型处理，以减少大模型处理时间，同时避免信息过载。
（2）测评问题
建立更完善的测评体系，包括自动化测试和人工审核，确保系统性能与用户体验持续提升。
此外，我们认识到最终表现效果还受到底层知识完备率的影响，因此加强与数仓等部门的合作，共同构建和完善专业知识库，为系统提供坚实的数据支撑。
这是我们上线的一版库表智能检索产品的示意图。用户提出查询需求，寻找特定字段信息。系统首先利用大模型进行智能总结回答，直接呈现给用户一个概括性的结果。随后，系统进一步挖掘并展示与该字段相匹配或相关的库表信息，以满足用户的深入查询需求。
3. 支撑成本治理场景
在探讨货拉大数据成本治理面临的挑战时，我们注意到，未经有效治理前，成本与单均成本均呈现快速上涨趋势，且缺乏有效管控手段。具体而言，存在三大问题：一是成本分配不明，难以追踪至具体资产及责任人；二是成本使用效率存疑，是否存在浪费现象难以评估；三是成本水位健康状况模糊，缺乏清晰判断标准。
为应对上述挑战，我们构建了大数据成本治理体系，该体系以元数据为核心驱动力，通过以下策略实现持续降本：
- 资产可视化度量：利用元数据构建资产全景图，实现成本在资产层面的可视化展示，清晰呈现成本分布与流向。
- 辅助治理能力：针对存储和计算层面的资源浪费，提供一系列技术能力，帮助减少资源使用。
- 健康度导向的成本运营：建立成本健康度评估体系，定期监测成本水位，确保成本使用合理且高效，同时指导成本优化策略的制定与实施。
数据资产度量体系旨在量化大数据资产的消耗与成本，并提供强大的查询与统计分析功能。以下是该体系的框架概述：
我们聚焦于任务产出的核心资产，如表、报表、看板指标等，从底层存储与计算引擎精准采集其消耗数据。这些数据随后通过平台数仓的精细加工，转化为按个人及部门维度划分的成本数据，使用户能直观了解各自名下资产的消耗情况。
此外，系统还能自动生成部门级别的成本账单，为资源优化、任务调度优化、存储治理及成本运营等关键场景提供坚实的数据支撑，助力企业实现更加精准与高效的成本管理。
第二部分聚焦于辅助治理能力，特别针对货拉拉大数据中占据主导地位的离线存储成本。鉴于大数据环境中普遍存在的“冰数据”现象，即大量数据虽占用资源却鲜少被访问，我们致力于优化存储效率。
首先，我们面对的挑战在于如何界定冷热数据，因业界标准不一且难以直接套用于我司业务。为此，我们借鉴了美团的数据分类方法（基于 90 天内访问频次），并结合云厂商的归档存储费用模型，进行了深入的分析与调整。
通过分析最近 90 天内的数据访问次数与归档收益的关系，我们发现访问次数为 0 的数据占比最高且归档收益显著，而访问次数极少的数据归档收益则相对较低。基于这一发现，我们制定了数据温度的打标策略，将数据明确划分为不同热度等级。
针对不同温度的数据，实施差异化的治理措施：对于冰数据（长期未访问的数据），建议用户优先删除以释放存储资源；对于冷数据（偶尔被访问的数据），则推荐用户进行归档处理，以平衡存储成本与数据可访问性。这一策略旨在最大化存储效益，减少不必要的资源浪费。
理论上，数据随时间推移会逐渐失去活跃性，即“冷却”。为此，我们为数据表设定了生命周期与归档周期两大属性，以实现对超出特定存活期限数据的自动化滚动清理与归档。在图示中，该表的生命周期被设定为180 天，归档周期为 90 天。这意味着，超过 180 天的数据将被系统删除以释放资源，而介于 90 天至 180 天之间的数据则会被自动归档至更低成本的存储介质中。
前述技术辅助能力为业务成本治理提供了有力支持，但要激发业务团队的主动参与，还需构建一套完善的成本运营能力。该体系能够自动侦测数据资产在计算与存储层面的成本浪费问题，生成治理点并即时通知相关用户，促其采取主动治理措施。治理点涵盖未配置生命周期的存储与计算资源、未归档的冗余数据、长期未访问的数据或任务等。
结合成本消耗数据，我们设计了一套健康分模型，以量化评估治理效果。此模型不仅为个人及部门提供成本健康状态的直观展示，还辅以奖惩机制与红黑榜排名，激励用户持续优化存储与计算成本，共同维护成本水位处于健康状态。图示展示了当前资产健康分的评估结果，涵盖个人与部门两个维度，以及治理效果的排行榜，确保每位用户及其领导层都能及时获得反馈，共同推动成本治理工作的深入进行。
经过一系列存储优化策略的实施，包括生命周期管理、数据归档、文件压缩、格式算法升级以及深度专项治理等，我们取得了显著的成效。上图展示了存储成本的优化成果：在优化前，存储成本呈现快速线性增长趋势；而优化后，存储成本在八个月内实现了零增长，并持续走低，累计节省了高达 54% 的存储成本，成效颇为可观。
4. 数据安全场景
元数据服务离不开分级打标，分级主要是法律法规的要求，二是权限控制的需要，三是方便管理与审计，这方面的工作会借助安全定级系统，由其负责对元数据进行分类定级打标，打标完成后会针对 C4 以上的个人敏感信息进行信息加密并打标以实现敏感的管控，降低数据泄露的风险。
场景支撑：元数据作为数据管理平台的底层基座，支撑库表安全和数据下载两大安全应用场景。
- 库表安全场景：依赖自研的库表权限系统可进行权限的申请与查询，实现有效期的管理；后台任务方面使用的底层策略是 Rager，鉴权服务方面已经实现劣迹鉴权的应用。
- 数据下载场景：依托自研的大数据研发平台，可以进行 SQL 查询与数据下载，同时 ETL 的离线任务也在此平台实现。
数据的分类分级标准与规范
数据的分类分级结合了公司的业务场景，主要从数据的敏感性与价值性出发，同时参考了金融数据安全分类分级标准《金融数据安全数据安全分级指南》，将货拉拉的数据安全等级分为四大等级：
- 公开数据（C1）：已通过正规渠道正式对外发布的数据，不会对公司造成影响的数据；这部分数据基本无价值，可外部公开
- 限制数据（C2）：不适合对外公开，但是对内部人员访问基本无限制的数据，一旦发生泄露，不会对数据主体造成直接损害；这部分数据有低价值，公司内部可基本无限制访问
- 商业秘密（C3）：公司专有或公司保密的，一旦发生泄露，将显著影响相关业务的开展，对数据主体造成直接或者间接损害；这部分数据有中价值间接利用，公司内部限于相关人员按规使用
- 核心秘密（C4）：具有最高安全属性要求，一旦发生泄露，可能导致公司法律或商业上造成重大影响和损失；这部分数据最重要关乎用户敏感数据，高价值可直接利用，限于公司重要部门特定人员授权使用
库表的分类分级
库表的分类分级分为增量数据与存量数据，二者类别采用不同的分级达标方案；
- 增量数据：针对单个库表分级达标，用户可以通过元数据服务进行建表，建表后通过审批，审批后进行元数据更新，这一批更新的元数据会异步发布到 Kafka，通过定级系统进行消费数据，并进行算法打标，打标主要依据字段名称以及字段备注信息进行打标，打标完成后将此批数据返回给 Kafka，然后在元数据服务系统进行 Kafka 服务，以进行元数据更新；
- 存量数据：设置定时任务每天进行全表扫描，后发送给 Kafka，经定级系统进行消费数据，并进行算法打标，打标后返回 Kafka，并在元数据服务系统进行 Kafka 服务，以更新元数据。
针对算法打标的误判，也支持人工修正，主要由有安全经验的安全人员来进行判断并修正。
分级分类安全场景
分类分级在库表的具体应用场景，货拉拉采用按照人员类别以及入职天数开放不同权限的数据安全策略。
针对以下的情形采用不同的安全权限策略：
- 入职多少天内不能申请任何数据；
- 入职不满多少天，严格限制了申请 C3 及以上等级的数据，只能申请 C1、C2 等级的数据；
- 外包、实习生、兼职类别人员只能申请 C1、C2 的数据，不能申请 C3 及以上数据权限。
限制人员若需要申请相应库表权限，需通过邮件申请白名单。在具体的库表审批方面，会针对 C3、C4 敏感等级数据自动进行标红处理，提醒审批人员对此部分数据的权限进行更加严格的审批，确保权限不会被错误授权。
加密字段的打标方案
加密字段打标方案主要依赖于元数据服务和数据研发平台。
通过元数据服务会设置定时任务定时扫描敏感数据，像扫描到 C3、C4 数据，会进行 select 列 from 表 limit 多少条数据后执行 SQL 查询，返回获取这些样例数据，然后根据数据的规则进行打标，具体的达标规则会对数据进行长度检测和字符规则检测。
通过自研的数据研发平台，执行 SQL 查询，后台解析此 SQL 查询包含哪些表、哪一些字段，后向元数据服务申请调用得到相关的元数据，后通过数据研发平台查询此部分数据的 Hive 结果。若需要下载，会根据元数据的加密以及敏感等级走不同的审批流。
具体的审批策略针对敏感数据和非敏感数据采用不同的方式：
- 敏感数据：针对 C3、C4 级的敏感数据使用，需要上级+大数据或安全部门人员进行审批；
- 非敏感数据：非敏感数据单日小于等于多少条是不需审批的；单日大于多少条数据，才采用上级+部门负责人审批的方式。
加密打标应用场景
加密打标的应用场景：数据下载。
数据下载需走审批程序，针对 C3、C4 敏感数据的下载，会有敏感数据下载标识进行提醒，数据下载详情里会有解析到的敏感字段，如表名、字段名、注释等，以供给审批人员参考。针对一些特别敏感的个人信息而且量多的情形，此时安全人员会找申请人员进行核对，以确保数据可以下载。
数据安全更多的应用场景：
- 安全等级打标传染：通过血缘的传染能力给它的下游数据进行打标，提高库表分级的准确率；
- 数据加密治理：对存量敏感数据漏打标情形进行识别，如个人信息，并进行批量打标、加密，以保障数据安全；
- 数据灾备：通过元数据打标，实现数据自动灾备。
三、未来规划
未来的规划与建设重点包括更高效的检索服务、数据血缘的标准化以及降本增效三个方面。
- 更高效的检索服务：进一步优化和探索 AI 大模型在数据检索领域的应用，更好的识别用户意图并更好的回答。
- 数据血缘标准化：数据血缘建立标准的 SDK，减少重复造轮子；提高数据血缘质量度量的准确率，以便于数据分析。
- 自动化成本治理：持续降本，尽可能多的步骤实现自动化处理，减少一些不必要的成本。
