它主要涉及数据库血缘、数据表血缘和数据字段血缘三种实体。本文将深入探讨这三种实体的定义及其在数据治理中的作用,并结合具体实践原则进行阐述。 将数据血缘分为数据库血缘、数据表血缘和数据字段血缘三类,可以提供不同层次的精细化管理:数据库血缘帮助理解数据在全局系统间的流动路径,确保数据传输的透明性;数据表血缘关注数据在表级别的传输过程,确保表与表之间的数据准确性和一致性 这三者共同作用,全面保障数据从源头到终端的完整性和可靠性。 数据库血缘、数据表血缘和数据字段血缘三者在数据血缘分析中各司其职,共同保障了数据的透明性、准确性和合规性。 数据库血缘提供宏观的全局视角,数据表血缘确保数据在表级别上的正确传输,而数据字段血缘则深入细节,保障数据在字段级别上的一致性和准确性。 这样,数据血缘三个实体,数据库血缘、数据表血缘、字段血缘已经了解了,下一章我们继续了解数据血缘的几种类型:逻辑血缘、物理血缘、时间血缘、操作血缘、业务血缘。 我们下一章再见!
在当今数据驱动的商业环境中,数据治理成为企业成功的关键因素之一,而数据血缘正是数据治理成功的一个关键。 本文我们详细探讨下数据血缘与主数据有什么关系?他们之间又是如何配合实现数据治理的。 主数据与数据血缘 数据血缘是指数据在不同系统和过程中的流转和变更历史。了解主数据的数据血缘对于确保数据的质量和一致性具有重要意义。数据血缘的特征包括来源追溯、变更历史、影响分析和透明性与可追溯性。 通过数据血缘,可以识别和修正主数据中的错误和不一致,提高数据质量。数据血缘为主数据的治理提供了基础,帮助制定和执行数据治理政策。 合规性和审计方面,数据血缘记录了主数据的变更历史,有助于合规审计,确保数据管理符合相关法规和标准。在业务决策支持方面,了解主数据的血缘关系,有助于进行准确的业务分析和决策,提高业务运营效率。 下一章我们继续来了解数据血缘与业务数据之间的联系。 我们下一章再见!
在当今数据驱动的商业环境中,数据治理成为企业成功的关键因素之一,而数据血缘正是数据治理成功的一个关键。 本文我们详细探讨下数据血缘与元数据有什么关系?他们之间又是如何配合实现数据治理的。 本文为《数据血缘分析原理与实践 》一书读书笔记,部分观点参考自书中原文,如需更详细的了解学习,请大家支持原作者的辛苦付出。 元数据和数据血缘的联系 数据血缘(Data Lineage)是指数据从其来源到最终目的地的生命周期中所有变更的跟踪和记录。数据血缘包括数据的来源、流向、变换规则和依赖关系等。 在数据治理中,元数据和数据血缘紧密相关。元数据记录了数据的来源和目标,使数据血缘分析能够准确地追踪数据的流动路径。 通过元数据和数据血缘的结合,企业可以更好地理解和管理其数据资产,提升数据的价值和利用水平。元数据和数据血缘在数据治理中具有不可替代的重要作用。
什么是数据血缘? 数据的产生、加工融合、流转流通,到最终消亡,数据之间自然会形成一种关系。借鉴人类社会中类似的一种关系来表达数据之间的这种关系,称之为数据的血缘关系。数据血缘是元数据的组成部分之一。 它分析表和字段从数据源到当前表的血缘路径,以及血缘字段之间存在的关系是否满足,关注的数据一致性以及表设计的合理性。 可追溯性 数据的血缘关系,体现了数据的生命周期,体现了数据从产生到消亡的整个过程,具备可追溯性。 层次性 数据的血缘关系是有层次的。 数据血缘分析 即数据“前向”血缘。通过指定表/字段,来追溯其前向多级对象。 数据影响分析 即数据“后向”血缘。通过指定表/字段,来关联其后向多级对象。 数据全局血缘 不局限于单个对象,可从更大尺度(例如:项目内等),了解整体数据流转情况。这对于分析热点对象、数据清理等需求都很有意义。 数据计算血缘 即从“作业”角度入手,分析其前向、后向作业情况。
常见的数据血缘主要包括两大类: SQL血缘:基于SQL解析AST语法树,获取SQL的表、字段血缘; 业务血缘:常为基于任务调度DAG生成的数据流向关系; 业界方案 业界实现方案,开源项目数据血缘对比 项目 但如果关系层级超过3层,查询时会出现性能瓶颈,可选择基于图数据库存储。 图数据库是一个使用图结构进行语义查询的数据库,它使用节点、边和属性来表示和存储数据。 血缘解析应用流程如下: 生产数据:上层数据地图、数据开发等功能在SQL和任务过程中,主动push给元数据应用层,元数据应用层基于固定消息格式将对应的数据生产到消息中间件; 消费数据:血缘服务定时从消息中间件消费数据进行处理 血缘服务可分为三个模块:血缘解析、血缘存储、血缘查询。 总结 数据血缘是数据治理的重要应用之一,通过血缘信息可清晰识别出表之间的依赖关系,追踪数据的来源和流向过程。 数据血缘对于数据质量管理、合规性以及数据安全都有重要的作用。在复杂的数据环境中,维护准确的数据血缘信息是一个挑战性问题。
比如数据表格的Schema信息,任务的血缘关系,用户和脚本/任务的权限映射关系信息等等。 数据的血缘关系信息 血缘信息或者叫做Lineage的血统信息是什么,简单的说就是数据之间的上下游来源去向关系,数据从哪里来到哪里去。知道这个信息有什么用呢? 以hive表为例,通过分析hive脚本的执行计划,是可以做到相对精确的定位出字段级别的数据血缘关系的。 最后,关于数据的血缘关系跟踪,再多说两句。 ,不能提前获取血缘信息 临时脚本或者错误的脚本逻辑对血缘关系数据的污染 简单总结一下,就是基于运行时的信息来采集血缘关系,由于缺乏静态的业务信息辅助,如何甄别和更新血缘关系的生命周期和有效性会是一个棘手的问题
前几天,Datahub提供了最新的字段级别数据血缘功能,很多朋友迫不及待想对比一下Datahub的字段级血缘与Atlas的区别。 这个时候问题来了,在Atlas收集Hive血缘的时候,由于部分版本问题,没有显示出字段级的数据血缘。这是为什么呢?其实只要做一个简单的修复就可以了,但是知其然也要知其所以然。 正文开始: 通过本文档,可以快速的解决Hive在Altas字段级血缘没有生成的问题,并了解Hive数据血缘实现原理。更多元数据管理,数据血缘相关文章,可以关注后续的文章更新。 但是,很多同学在按该步骤操作完以后,字段级数据血缘并未生成。这是为什么呢? 四、Hive表数据血缘实现 表的实现就比较简单了。
目前,Amundsen并不支持表级别和列级别的数据血缘功能,也没有办法展示数据的来龙去脉。 作为Amundsen一项非常核心的功能,Lineage功能早已经提上日程,并进入设计与研发阶段。 新的概念 Lineage:这是一个术语,代表了数据流的传递过程,从一个实体到另一个实体。特别是ETL的过程,重点关注表到表,列到列的数据流转过程。 Upstream:数据从上游流向下游,Upstream就代表着当前的数据来源。 Downstream:代表了使用了当前数据的相关实体。 每个选项卡将包含从中继承或使用数据的表的列表。这允许用户以非常简单的方式查看。 image.png 列级别 和表级别相似,可通过扩展列的元数据来查看。
特征血缘不是数据血缘:厘清两个容易混淆的概念 你能追溯到数据表的来源,能查到字段的上下游关系,却依然回答不了"这个特征从哪来、改了会影响谁"。 这不是工具不够强大,而是把"数据血缘"和"特征血缘"混为一谈了。 这个特征从 v3 到 v4 改了啥逻辑?哪些模型还在用 v3? 线上特征服务读的字段,和离线训练时用的是同一套定义吗(online/offline parity)? ,这些字段血缘根本抓不到。 **第二,**多数公司先建数据血缘,没有"特征定义层"。 数据血缘工具成熟得早,大家习惯了用它解决所有追溯问题。 数据血缘解决数据链路问题,特征血缘解决语义定义问题,模型血缘解决训练复现问题。缺了任何一环,"全链路"都是残缺的。
一、前言 什么是数据血缘?数据血缘是数据产生、加工、转化,数据之间产生的关系。随着公司业务发展,通过数据血缘,能知道数据的流向,以便我们更好地进行数据治理。 二、为什么选择 Spline? Kafka,应用可消费 Kafka 数据获取字段血缘数据进行解析,但政采云大数据平台,基于业务需要,字段血缘需要跟作业绑定,若通过消费 Kafka 的方式,无法在获取字段血缘数据的同时跟作业绑定。 附,Spline REST 文档 1、血缘解析流程 Htools:政采云大数据平台的一个调度工具 IData:政采云大数据平台应用层 2、基于接口解析血缘 解析字段血缘,主要涉及到 Consumer 3、示例 以下案例基于 insert into …… select …… 语句的解析 (1)执行计划 从下图,可以看到一个 insert into …… select …… 语句,被解析成几个步骤,下列截图所对应的步骤 (2)根据 applicationId 获取 planId (3)根据 planId 获取执行节点信息 (4)根据节点 id 获取对应的信息 a、根据 Project 节点,获取输入表和输出表之间的字段血缘关系
比如数据表格的Schema信息,任务的血缘关系,用户和脚本/任务的权限映射关系信息等等。 数据的血缘关系信息 血缘信息或者叫做Lineage的血统信息是什么,简单的说就是数据之间的上下游来源去向关系,数据从哪里来到哪里去。知道这个信息有什么用呢? 以hive表为例,通过分析hive脚本的执行计划,是可以做到相对精确的定位出字段级别的数据血缘关系的。 最后,关于数据的血缘关系跟踪,再多说两句。 ,不能提前获取血缘信息 临时脚本或者错误的脚本逻辑对血缘关系数据的污染 简单总结一下,就是基于运行时的信息来采集血缘关系,由于缺乏静态的业务信息辅助,如何甄别和更新血缘关系的生命周期和有效性会是一个棘手的问题
问题:我们的数据在数百个微服务之间进行处理和传输,并以不同的格式存储在包括 Redshift、S3、Kafka、Cassandra 等在内的多个数据存储中。 它提供数据旅程的可视化表示,包括从起点到目的地的所有步骤,并提供有关数据去向、谁拥有数据以及在每个步骤中如何处理和存储数据的详细信息。 图 3. Spark-ETL 作业的示例图 在后端,我们直接在 Spark-ETL 中实现 Spark-Lineage,以从每个批处理作业中提取所有具有依赖关系的源表和目标表对。 例如,(输入表 1,输出表 2)是图 3 中的一对,因为它们之间存在路径,而(输入表 2,输出表 2)则不是。 Schema_id: Yelp 的所有现代数据都被模式化并分配了一个 schema_id,无论它们是存储在 Redshift、S3、Data Lake 还是 Kafka 中。
来源:火山引擎 DataFun 公众号后台回复: 报告 获取源文件 欢迎添加本站微信:datajh (可上下滑动或点单个图片放大左右滑动查看)
兴业银行异构平台血缘治理、敏感数据打标数据链路完整性从 20% 提升至 90%;变更影响分析扩散度降低 80%。 组织保障:建立业务、科技、数据、合规的联合团队,并将数据溯源能力建设成效纳入相关考核,形成治理闭环。六、 常见问题(FAQ)Q1: 表级血缘和算子级血缘的核心区别是什么? Q3: 建设这种精准溯源能力,投入和周期是否很长?并非如此。建议从小范围高价值场景试点开始。 Q4: 除了应对监管,高精度数据血缘还有哪些业务价值? 价值广泛,主要包括:1) 变更风控:精准评估上游变更对下游的影响,避免资损;2) 根因定位:快速定位数据异常源头,提升排障效率;3) 成本治理:识别冗余计算与无效模型,优化资源;4) DataOps 协同
大数据血缘主要体现在表与表之间的关系,描述了我的数据从哪里来,经过怎样的关联处理,流到哪里去,弄清楚关系是做数据治理的关键一环。大数据中涉及的数据表成百上千,表与表之间的关系,交叉依赖,错中复杂的。 今天我们从一个简单的SQL开始,去构建血缘关系及可视化。SQL查询客户的销售额,并将数据写入表table_user_dt_tg中:血缘关系解析图谱:使用PlantUML做可视化展示:关键血缘分析1. 分区策略分区字段:dt分区值来源:硬编码值'20250216'(通过WHERE条件过滤)动态性:静态分区(每次写入固定分区)3. 需确认业务是否需要保留明细)有了血缘数据之后,我们请能清楚的看出 数据的流向以及使用哪些字段,做了哪些计算统计等,数据治理才有了抓手。 比如基于血缘数据分析。可以评估出S QL存在的风险点以及优化建议。
二、数据血缘的构成要素知道了数据血缘是什么,可能有小伙伴好奇它是由哪些部分构成的。以下这些要素合在一起,才构成了完整的血缘关系。1. (3)第三步是加载(Load):把改好的数据放到目标系统里去。这一步还可以:直接写到数据库表,也能生成新文件,或者发到消息队列里。 3. 数据去向数据处理完了,总有个去处,这些去处决定了数据最后能派上什么用场、有什么价值。第一个去向是数据库存储:存到各种数据库里,方便后面查和分析。 实际业务里,数据的来源可复杂着呢。3. 可追溯性你可以把它理解成:从数据刚产生,到中间经过多少次处理、转换,再到最后用在哪个报表、哪个分析里,甚至最后什么时候被删除,整个过程血缘关系都能记下来。 最终的报表数据跟原始数据能不能对上?也就是说:有了这些记录,审计效率能提高不少,也能及时发现潜在的风险点。3. 数据资产管理企业里的数据越来越多,哪些该重点管?哪些可以精简?
大数据血缘主要体现在表与表之间的关系,描述了我的数据从哪里来,经过怎样的关联处理,流到哪里去,弄清楚关系是做数据治理的关键一环。 大数据中涉及的数据表成百上千,表与表之间的关系,交叉依赖,错中复杂的。 今天我们从一个简单的SQL开始,去构建血缘关系及可视化。 分区策略 分区字段:dt 分区值来源:硬编码值'20250216'(通过WHERE条件过滤) 动态性:静态分区(每次写入固定分区) 3. (需确认业务是否需要保留明细) 有了血缘数据之后,我们请能清楚的看出 数据的流向以及使用哪些字段,做了哪些计算统计等,数据治理才有了抓手。 比如基于血缘数据分析。可以评估出S QL存在的风险点以及优化建议。
从数据的产生,通过加工融合流转产生新的数据,到最终消亡,数据之间的关联关系可以称之为数据血缘关系。 、数据血缘、安全和生命周期管理在内的元数据治理核心能力。 社区提供了一个Demo,演示地址:https://demo.datahubproject.io/ 与Airflow集成较好,支持数据集级别血缘,字段级别在2021Q3的Roadmap。 只输入需要用到的字段即可,而是需要将所有后续用到的字段都输入到自定义脚本,脚本再决定输出哪些字段,这其中列与列之间的映射关系无法通过执行计划获得,只能简单的记录输出列的表达式,如transform(c1,c2,c3) 随着业务需求和数据的增长,数据的加工流程越来越复杂,构建一套数据血缘,可以轻松查询到数据之间的关系,进行表和字段级的血缘追溯,在元数据管理,数据治理,数据质量上承担重要一环。
最近在进行数据逆向分析,无业务无界面无数据库的情况下,想通过对存储过程中关于输出输入表的分析快速了解业务的核心问题,然后再对核心业务进行逆向回溯。 其实问题很简单,一个存储过程会有多个输入表和输出表,一个存储过程的输出表可能会成为另外一个存储过程的输入表,从而将整个数据库的业务逻辑串接起来,基于长链会形成血缘关系,基于关联会形成聚合。 这里需要构造的节点数据和连接数据,节点数据是输入表和输出表剔重后的编号和标签,连接数据通过存储过程标签将节点数据进行关联。 代码之前有测试过,所以这次实现无太多需要讲解。 #!
其实,这个问题用一个专业术语就能解决:数据血缘。 但恕我直言,市面上99%声称"建立了数据血缘"的企业,其实都是在自欺欺人。 经过排查发现,不同团队使用的数据加工逻辑不一致,有的用了近30天的数据,有的只用了7天。如果没有完整的数据血缘,这个问题的定位至少需要一周时间。 这就是数据血缘的第一个核心价值:快速问题定位。 当数据质量告警时,系统会自动沿血缘链路上溯,帮助快速定位问题根源。同时,如果业务方发现某个血缘关系不准确,可以通过系统直接反馈给数据团队。 数据血缘背后的管理哲学 说了这么多技术层面的东西,但我觉得数据血缘更深层次的价值在于管理理念的转变。 传统的数据团队更像是一个"数据加工车间",进来什么数据,出去什么报表,全凭经验和手工操作。 结语 数据血缘不是什么高深莫测的技术概念,它更像是数据团队走向成熟的必经之路。 在这个数据爆炸的时代,我们不缺数据,缺的是对数据的理解和掌控。数据血缘就是帮助我们建立这种掌控感的工具。