细说Dataphin自动解析

本文涉及的产品
智能数据建设与治理Dataphin,200数据处理单元
简介: 细说Dataphin自动解析

Dataphin v3.10 版本对调度依赖配置做了比较大的调整,主要的变更点有:

  1. 统一了 集成同步任务,计算任务和逻辑表的调度依赖交互
  2. 上游依赖列表调整
  1. 本周期依赖和上周期依赖合并到同一个列表
  2. 增加了依赖任务筛选
  3. 依赖任务列表项扩展展示更多信息,如: 调度周期,依赖周期,是否开启条件调度
  1. 自动解析优化,自动解析不再依赖节点输出名,而是直接使用任务与表的血缘关系,本文将着重说明。
  2. 弱化节点输出名,用户无需再配置输出名,也不用刻意关注。


自动解析流程

下图为 v3.10 版本自动解析的流程

细说Dataphin自动解析-流程图.jpg


新的流程与原来的旧流程的区别对比如下:

对比项

v3.9 及之前版本

v3.10 版本

改进点

解析结果

输入表

输入表

维护 输入表与产出任务关系 的系统

调度系统内部(节点输出名)

资产血缘

1. 集成任务,SQL 计算任务,逻辑表提交发布时,系统自动根据任务的逻辑生成任务与该任务的输出表的映射关系(即 表与产出任务 血缘),无须用户人工干预

2. shell/python/mr 等任务用户可以通过自定义血缘补充血缘数据

3. 血缘数据覆盖度和准确度比较高,原来的节点输出名覆盖度和准确度相对较低(节点输出名可以被人工干预,准确性不足)

找不到输入表对应产出任务时的处理策略

直接忽略

列举在依赖列表中,需要用户人工处理

可以帮助发现没有产出任务的依赖表,避免出现依赖缺失的情况


资产血缘

v3.10 自动解析使用了资产血缘,这又是什么呢?


在资产目录中,打开一个表,进入表资产详情,可以在资产信息中,看到该表的产出信息,见下图。


  1. 当集成任务,SQL 计算任务,逻辑表提交发布时,系统会自动将当前任务节点的信息与输出表之间的关系维护到资产中。
  2. 对于 shell/python/mr 等非 SQL 任务,Dataphin 无法从任务代码中解析到输出表,用户可以通过自定义血缘的方式补充血缘信息,见下图。


大部分的表与任务的映射关系都是由系统自动生成和维护的,保障了数据的准确度;人工填报的自定义血缘,提高了覆盖度。


节点输出名

v3.10 的自动解析已经不依赖节点输出名,此处还是解释下节点输出名是做什么的。

在此之前,先来说明几个概念:

  1. Dataphin 节点就是任务,包含 集成任务,计算任务,逻辑表任务 等
  2. 节点名称(任务名称) ,集成任务和计算任务创建时由用户输入的用户名称,逻辑表任务名称与逻辑表名相同。由于历史原因,节点名称没有设计为全局唯一,而是在导航目录下唯一。
  3. 节点(任务) ID,是节点(任务)提交时,系统自动生成的全局唯一 ID。任务发布后,开发环境与生产环境的 ID 需要保持一致。但由于历史原因,这个原则在历史版本中未落实(指向不唯一)。
  4. 任务提交发布后,调度系统需要一个全局唯一 ID 来明确定位某一个节点(任务),以生成调度依赖图(DAG)。

由于节点名称和节点 ID 无法确保全局唯一且指向唯一,因此引入了“节点输出名”来承担节点全局唯一 ID 的作用。


在 v3.9 及之前版本,节点输出名还承载着输出表与节点任务映射关系的作用。节点输出名称如果与某一个表的名称(格式为 {生产项目名.表名称})一致,则认为该节点产出了该表。节点输出名的生成机制:

  1. SQL 计算任务自动解析时,系统会自动为每一个输出表生成一个节点输出名
  2. 逻辑表任务的输出名就是逻辑表名
  3. 集成任务的输出名在早期版本需要用户人工填写,后期的版本自动解析为每一个输出表生成一个节点输出名
  4. shell/python/mr 等任务的节点输出名需要用户人工填写

存在以下问题:

  1. 系统自动生成的节点输出名可以被人工编辑修改,存在误操作风险
  2. 输出名的格式有严格的要求,必须是 {生产项目名.表名称},用户人工填写时,容易错误输入

以上问题导致节点输出名的准确度和覆盖度都不如资产血缘,因此 v3.10 自动解析升级后,切换到了后者。而节点输出名保持纯粹的唯一ID功能,由系统自动生成为 uuid 格式,不再具有业务含义。

相关文章
|
6月前
|
JSON 数据管理 关系型数据库
【Dataphin V3.9】颠覆你的数据管理体验!API数据源接入与集成优化,如何让企业轻松驾驭海量异构数据,实现数据价值最大化?全面解析、实战案例、专业指导,带你解锁数据整合新技能!
【8月更文挑战第15天】随着大数据技术的发展,企业对数据处理的需求不断增长。Dataphin V3.9 版本提供更灵活的数据源接入和高效 API 集成能力,支持 MySQL、Oracle、Hive 等多种数据源,增强 RESTful 和 SOAP API 支持,简化外部数据服务集成。例如,可轻松从 RESTful API 获取销售数据并存储分析。此外,Dataphin V3.9 还提供数据同步工具和丰富的数据治理功能,确保数据质量和一致性,助力企业最大化数据价值。
294 1
|
3月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
135 2
|
4月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
100 1
|
4月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
86 0
|
4月前
|
存储 Java C++
Collection-PriorityQueue源码解析
Collection-PriorityQueue源码解析
86 0
|
4月前
|
安全 Java 程序员
Collection-Stack&Queue源码解析
Collection-Stack&Queue源码解析
119 0
|
2月前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是"将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。创建型模式分为5种:单例模式、工厂方法模式抽象工厂式、原型模式、建造者模式。
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
2月前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
2月前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
1月前
|
自然语言处理 数据处理 索引
mindspeed-llm源码解析(一)preprocess_data
mindspeed-llm是昇腾模型套件代码仓,原来叫"modelLink"。这篇文章带大家阅读一下数据处理脚本preprocess_data.py(基于1.0.0分支),数据处理是模型训练的第一步,经常会用到。
53 0

热门文章

最新文章

相关产品

  • 智能数据建设与治理 Dataphin
  • 推荐镜像

    更多