细说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 格式,不再具有业务含义。

相关文章
|
3月前
|
JSON 数据管理 关系型数据库
【Dataphin V3.9】颠覆你的数据管理体验!API数据源接入与集成优化,如何让企业轻松驾驭海量异构数据,实现数据价值最大化?全面解析、实战案例、专业指导,带你解锁数据整合新技能!
【8月更文挑战第15天】随着大数据技术的发展,企业对数据处理的需求不断增长。Dataphin V3.9 版本提供更灵活的数据源接入和高效 API 集成能力,支持 MySQL、Oracle、Hive 等多种数据源,增强 RESTful 和 SOAP API 支持,简化外部数据服务集成。例如,可轻松从 RESTful API 获取销售数据并存储分析。此外,Dataphin V3.9 还提供数据同步工具和丰富的数据治理功能,确保数据质量和一致性,助力企业最大化数据价值。
169 1
|
2天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
14 2
|
1月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
66 0
|
1月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
52 0
|
1月前
|
存储 Java C++
Collection-PriorityQueue源码解析
Collection-PriorityQueue源码解析
59 0
|
1月前
|
安全 Java 程序员
Collection-Stack&Queue源码解析
Collection-Stack&Queue源码解析
80 0
|
3天前
|
存储 安全 Linux
Golang的GMP调度模型与源码解析
【11月更文挑战第11天】GMP 调度模型是 Go 语言运行时系统的核心部分,用于高效管理和调度大量协程(goroutine)。它通过少量的操作系统线程(M)和逻辑处理器(P)来调度大量的轻量级协程(G),从而实现高性能的并发处理。GMP 模型通过本地队列和全局队列来减少锁竞争,提高调度效率。在 Go 源码中,`runtime.h` 文件定义了关键数据结构,`schedule()` 和 `findrunnable()` 函数实现了核心调度逻辑。通过深入研究 GMP 模型,可以更好地理解 Go 语言的并发机制。
|
15天前
|
消息中间件 缓存 安全
Future与FutureTask源码解析,接口阻塞问题及解决方案
【11月更文挑战第5天】在Java开发中,多线程编程是提高系统并发性能和资源利用率的重要手段。然而,多线程编程也带来了诸如线程安全、死锁、接口阻塞等一系列复杂问题。本文将深度剖析多线程优化技巧、Future与FutureTask的源码、接口阻塞问题及解决方案,并通过具体业务场景和Java代码示例进行实战演示。
36 3
|
1月前
|
存储
让星星⭐月亮告诉你,HashMap的put方法源码解析及其中两种会触发扩容的场景(足够详尽,有问题欢迎指正~)
`HashMap`的`put`方法通过调用`putVal`实现,主要涉及两个场景下的扩容操作:1. 初始化时,链表数组的初始容量设为16,阈值设为12;2. 当存储的元素个数超过阈值时,链表数组的容量和阈值均翻倍。`putVal`方法处理键值对的插入,包括链表和红黑树的转换,确保高效的数据存取。
53 5
|
1月前
|
Java Spring
Spring底层架构源码解析(三)
Spring底层架构源码解析(三)
107 5

热门文章

最新文章

相关产品

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

    更多