企业官网建设流程全解析

很多企业一做数据治理，就会碰到一个词：

数据血缘。

乍一听很好理解，无非就是搞清楚“数据从哪里来、最后去了哪里”。

但真正落地以后，你会发现，企业对“血缘”的理解经常混在一起。

领导看到经营看板上的“销售收入”突然下降，问一句：

这个数字是怎么来的？

这句话背后其实可能包含三个完全不同的问题：

• 第一，这个数字经过了哪些数据库、表、任务和加工链路？

• 第二，它对应的是订单、发货、开票还是收入确认这个业务过程？

• 第三，它具体用了哪些字段、过滤掉哪些数据、按照什么公式计算？

这三个问题，分别对应：

技术血缘、业务血缘、指标血缘。

很多企业血缘不好用，不是因为“没有血缘”，而是因为只把其中一层做出来，就以为整个数据链路已经透明了。

如果你正在做数据治理、数据仓库或者数据集成，我也整理了一份《数据仓库建设解决方案》，里面有不少数据建设、治理和分析相关的方法与实践，可以结合本文一起看。

需要自取：https://s.fanruan.com/7igmg（复制到浏览器）

下面把这三种血缘彻底拆开。

一、技术血缘：回答“数据究竟怎么流过来的？”

技术血缘是整个血缘体系最底层的一层。

它描述的是数据在不同技术对象之间发生了什么：

源系统 → 源表 → 同步任务 → ODS → DWD → DWS → ADS → API / 报表。

比如ERP里的订单数据，每天同步到数仓。

技术血缘真正应该回答的，不只是：

“这张表来自哪张表？”

而是继续往下追：

• 哪个任务读取了它？

• 中间经过了哪些SQL或者加工节点？

• 字段有没有重命名、拆分、合并？

• 下游有哪些表依赖它？

• 最后被哪些API、报表或任务使用？

它解决的是两个非常现实的问题。

一个叫向上追溯。

今天经营报表上的订单数突然少了20%，可以沿着结果表一路往上查，看问题究竟出在ADS聚合、DWS加工、DWD清洗，还是最开始的数据源就没进来。

另一个叫向下影响分析。

源系统准备修改一个字段，不能只问“数据库能不能改”，而要先知道：

这个字段后面到底挂着多少任务、多少表、多少报表。

这也是技术血缘最适合交给系统自动沉淀的部分。数据真正经过哪里，最好直接从实际运行的数据链路里生成，而不是项目结束以后再让人补一张Visio图。

在FineDataLink 5.0的数据管理中，数据表能够继续关联到定时任务节点、实时管道、数据服务API等对象。这样排查一张表时，看到的不只是静态表关系，而是数据在实际集成链路里经过了哪些任务、又被哪些下游对象继续使用。

但技术血缘只能说明：

数据“怎么走”。

它还解释不了：

这些数据在企业里究竟代表什么。

这就进入第二层。

二、业务血缘：回答“这些表和字段到底在描述什么业务？”

假设技术人员看到这样一条链路：

ERP_ORDER → ODS_ORDER → DWD_SALES_DETAIL → DWS_SALES

技术上完全没问题。

但业务人员看到这些名字，大概率还是不知道：

这到底对应企业里的哪一个业务环节？

业务真正理解的是：

客户下单 → 支付 → 发货 → 签收 → 收入确认。

这就是业务血缘和技术血缘最大的区别。

技术血缘连接的是：

表、字段、任务、接口。

业务血缘连接的是：

客户、商品、订单、合同、供应商、库存、收入、成本，以及它们所在的业务流程。

所以真正的业务血缘，本质上是在技术对象上补一层“业务语义”。

例如：

customer_id

技术上只是一个字段。

进入业务血缘以后，要继续明确：

• 它代表哪个客户主体？

• 来自哪个权威系统？

• 是不是企业统一客户ID？

• 多个系统里的客户编码是否已经映射？

再比如“订单”。

电商系统、ERP、CRM里可能都有订单。

如果业务定义没有统一，即使技术血缘全部连通，最后还是会出现：

三个系统都叫订单，但统计出来完全不是一回事。

所以业务血缘真正治理的，并不是表本身。

它治理的是：

企业如何用统一的业务语言解释这些数据。

三、为什么很多企业做了技术血缘，还是不好用？

这是很多项目最容易踩的坑。

数据平台里已经有一张巨大血缘图：

几百张表、上千个字段，线密密麻麻。

技术人员觉得信息已经非常完整。

业务人员却仍然不知道从哪里看。

原因很简单：

血缘有关系，不代表关系有意义。

假设某个字段叫：

valid_order_flag

技术血缘可以告诉你，它由：

order_status、refund_status、pay_status

三个字段加工而来。

但真正决定这个字段含义的，其实是一条业务规则：

已支付、未关闭、未发生全额退款的订单，才算有效订单。

技术链路本身并不会解释：

• 为什么是这三个条件？

• 谁定义的？

• 什么时候改过？

所以做到这一层以后，企业不能继续无限增加技术节点，而应该给核心技术对象补充：

• 业务名称；

• 字段定义；

• 责任部门；

• 数据标准；

• 业务规则；

• 使用范围。

而且血缘最好跟着生产链路变化。

当新的同步任务上线、实时管道调整、目标表发生变化以后，原来的关系也应该同步更新。FineDataLink 5.0把这类血缘关系建立在实际数据集成过程上，可以先把“真实发生的数据流”沉淀下来，再在此基础上补业务语义。

否则血缘图最容易变成一种新的文档债务：

上线时是对的，半年以后已经没人敢信。

四、指标血缘：回答“这个数字到底怎么算出来的？”

如果说业务血缘解决的是“这是什么”，那么指标血缘解决的是：

这个数字为什么是现在这个结果。

例如：

销售收入。

公式看起来似乎很简单。

但真正做指标治理时，问题马上就来了：

• 按下单时间还是发货时间统计？

• 未支付订单算不算？

• 退款订单什么时候扣除？

• 税额算不算收入？

• 跨月退款冲减哪个月份？

• 内部交易是否剔除？

所以指标血缘最重要的从来不是保存一个公式。

而是保存一整条计算证据链：

指标 → 计算规则 → 过滤条件 → 时间口径 → 来源字段 → 来源表 → 加工任务 → 源系统。

例如：

经营看板中的“销售收入”为1.25亿元，财务报表却只有1.2亿元。

如果没有指标血缘，大家通常会开始：

导Excel、找SQL、对订单、问开发。

最后发现一个按“订单完成时间”统计，一个按“会计收入确认时间”统计。

两个数字都没算错。

错的是大家一开始以为它们是同一个指标。

这也是技术血缘为什么是指标追溯的重要底座。指标系统可以管理定义和公式，但真正需要查到字段和数据来源时，仍然要继续向底层的数据表和加工任务穿透。通过FineDataLink 5.0已经沉淀的数据表、任务、管道等关系，可以继续回答“这个字段到底从哪里来”，把指标口径追溯和底层数据链路连接起来。

注意，这里不能混淆：

技术血缘不会自动替代指标治理。

因为“字段来自哪里”和“为什么按照这个口径计算”，本来就是两个问题。

五、三种血缘真正应该怎么串起来？

真正成熟的数据血缘，不应该是三套各自独立的系统。

它应该最终形成一条完整链路：

业务过程↓业务对象↓指标↓计算规则↓字段↓数据表↓加工任务↓源系统

这样管理层看到“毛利率下降3个百分点”，就可以逐层往下追。

先通过指标血缘看：

到底是收入下降，还是成本上升？

再继续看指标依赖哪些字段。

然后进入技术血缘，找到字段来自哪些表、哪些任务。

最后回到业务血缘：

异常究竟发生在销售价格、采购成本、产品结构，还是某个区域和客户群体。

这时候血缘才真正从一个IT工具，变成经营分析和问题定位的基础设施。

所以三个血缘解决的是三个层次的问题：

• 技术血缘：数据怎么走？

• 业务血缘：数据是什么意思？

• 指标血缘：数字怎么算？

少任何一层，追溯都会在某个位置断掉。

六、企业真正落地时，应该先做到什么程度？

很多企业做血缘失败，另一个原因是：

一开始就想把全公司的几十万字段全部治理完。

结果项目做半年，业务还没感受到任何变化。

更合理的方法，是先抓关键链路。

第一步：先锁定核心数据域

客户、订单、商品、合同、库存、财务。

不要一开始追求全覆盖。

第二步：把核心技术链路跑通

源系统、同步任务、核心数仓表、API和关键报表之间的关系先建立起来。

第三步：再补业务语义

给核心表、核心字段补充业务定义、责任人和规则。

第四步：重点治理关键指标

先从收入、利润、毛利率、库存周转、现金流等真正影响经营决策的指标开始。

而且做到最后，企业还会发现：

有血缘，并不代表数据可信。

如果上游已经缺数、重复或者主键异常，那么后面的血缘再完整，也只是清楚地告诉你：

“错误是怎么一路传下来的。”

所以血缘最终还必须和数据质量放在一起看。

在FineDataLink 5.0的数据管理体系里，除了血缘分析，还可以继续通过数据检测规则去检查完整性、唯一性、准确性等质量问题。这样真正出现指标异常时，团队不仅能够沿着链路寻找来源，还能进一步判断：

究竟是口径出了问题，链路出了问题，还是数据本身已经出了问题。

这才是血缘真正进入生产体系以后应该发挥的作用。

结语

数据血缘真正难的，从来不是“画关系”。

而是让企业里的每一个重要数字，都能够回答三句话：

我从哪里来。

我代表什么。

我是怎么算出来的。

技术血缘解决第一句。

业务血缘解决第二句。

指标血缘解决第三句。

三者真正连起来以后，企业面对“这个数字为什么不一样”“这张表改了会影响谁”“这个指标是谁定义的”这些问题时，才不需要重新拉群、找人、翻SQL、对Excel。

真正成熟的数据治理，不应该让人去猜数据的来路。

它应该让每一个关键数字，都有一条能够被追溯、被解释、也能够被验证的完整路径。