1 \/ 33

Seajs 的爱与恨

作者 \/ 黑带大师单东林

近年来，模块化开发已经趋于成熟，传统的开发模式不断被撇弃，特别是大型项目的开发，

维护起来困难、成本过大。种种利弊之下，模块化开发方案和工具如雨后春笋般出现，而且 EC5

页提出了模块化方案，不需要借助第三方类库，直接实现模块化。最近，项目中用到了 Seajs，

所以，还是比较熟悉的（主要是踩坑才多了），所以就 介绍一下 Seajs 的模块化。Seajs 本身

遵循 KISS（Keep It Simple, Stupid）理念进行开发，其本身仅有个位数的 API，因此学习起

来毫无压力。在学习 Seajs 的过程中，处处能感受到 KISS 原则的精髓——仅做一件事，做好

一件事。

一、 传统开发模式

1. 单文件过大，维护成本高，有损性能

2. 同步阻塞式加载，影响网站打开速度

2 \/ 33

3. 异步无阻加载的配置过重，维护不便

4. 命名空间的记忆负担与潜在冲突

5. 类库升级成本等因素导致版本“锁定”

6. 开发、部署与上线后的 bug fix 不够便捷

7. 跨环境开发的通用模块的共享问题

等等一系列问题 Seajs 都能帮助解决

1. 一个模块一个文件

2. 高性能：异步+并行

3. 使用简单

4. 无命名空间冲突+多版本共存

5. 弱依赖：浏览器即服务器

6. 通用模块只需编写一次

7. 稳定可靠、可扩展

二、 Seajs 的介绍

Seajs 的作者是前淘宝 UED,现支付宝前端工程师玉伯。Seajs 是一个遵循 CMD 规范的

JavaScript 模块加载框架，可以实现 JavaScript 的模块化开发及加载机制。 Seajs 是一个适

用于 Web 浏览器端的模块加载器。使用 Seajs，可以更好地组织 JavaScript 代码。 在

Seajs 的世界里，一个文件就是一个模块。所有模块都遵循 CMD 规范，我们可以像在 Node

环境中一样来书写模块代码。 无论是中小型站点，还是大型复杂应用，使用 Seajs，都可以

让我们的工作变得更轻松愉悦。

3 \/ 33

这样看来，Seajs 的听着还挺高大上的呵，其实了解了实现方式，就简单了很多，下面来揭

开他的面纱。

Seajs 其实就是把 js 的加载封装起来，在 html 里面动态添加 script 标签来加载 js，然后

又来了个 define 方法，给模块化提供一个 寄身的场所，然后提供一个可配置的文件，实现一

些简单的功能（好像说的太简单了哈，其实里面还是有很多的想法和解决方案的，理想状态下，

是没有全局变量的，当然这是很难实现的，但是可以极大的减少全局变量的使用，是业务逻辑

更清晰，后期维护更简便）就是因为 Seajs 简单，所以才易用。

优点吗，其实就是简单易用，百度百科上也就两句话概括：简单友好的模块定义规范，自

然直观的代码组织方式。还真是惜字如金啊。当然作者还是有很多的话要说的， 就像上面介

绍的那样，能解决很多传统开发模式的弊端。还有很多 Seajs 插件，在 github 上都有，可以

让你轻松构建中大型项目。

当然，最吸引我的还是使用简单。

init.js

define(function(require, exports) {

var module1 = require('.\/module1');

alert('hello world');

exports.message = “this is export message”;

});

test.html

seajs.use('.\/init');

4 \/ 33

一个模块一个文件；使用 define 定义模块；使用 use 异步加载模块；使用 exports 对外

提供接口；使用 use 回调函数获取加载的模块对象；使用 require 获取其他模块对象；自动处

理依赖；关注点分离：直接依赖的模块+向外提供的接口。

用了一段时间的 Seajs，感觉除了简单易用之外，就是有些概念设计很不易理解，往往导致

第一次使用的人一头扎进坑里，糊里糊涂的。还有个别功能不太强大，所以在这里就给大家科

普一下，用 Seajs 的时候一定要掌握的一个知识点就是“模块标识命名”。如果没有完全理解，

就不要进行开发了，各种路径的问题会让你崩溃掉的。

三、 模块标识命名

1. 顶级目录：（也叫顶级路径、顶级标识）， 就是不能以 . 或 .. 或 \/ 开头的路径，就

是顶级路径，会在路径前面直接加上 config 中定义的 base 的值（如果没有设置 base，

base 就是 Seajs 的路径）

Seajs.use(\"js\/module1\", function(module1) {

module1.init();

});

2. 相对路径： 其实就是以 . 或 .. 开头的路径。

Seajs.use([\".\/js\/module1\", \"..\/js\/module1\"], function(module1) {

module1.init();

});

3. 普通路径：除相对和顶级路径外的，比如（\/ 根路径）开头的，\"http:\/\/\" 、\"https:\/\/\" 、

\"file:\/\/\/\" 等协议标识开头

5 \/ 33

Seajs.use([\"http:\/\/loalhost\/test\/js\/module1\"], function(module1) {

module1.init();

});

然而这些还没有完，你理解了这些，只能在 require（）括号中和 Seajs.use（）的括号

中起作用，如果在模块内部，要加载一个 tpl（template），你也用上面的定义运用，就会

出问题。特别是这个模块是公共模块而被其他模块调用的时候（而且调用的模块的目录不

定，就有可能找不到文件） 解决办法： 上面提到的定义一定要深刻的理解，在模块内部调

用 tpl 时，前缀加上 Seajs.data.base 这个就是动态的获得顶级绝对路径，这样就不会出现

找不到文件了，因为 base 在同一个项目中一定是一样的。

四、 预加载（preload）问题

由于项目需要，要用到预加载，一开始以为 Seajs 不支持预加载，因为按照 Seajs 官网上

说的使用，没有效果，最后再 github 上才看到，要引一个额外的 preload.js 才能用预加载

的功能。 然后就引用了，但是有遇到了新的问题，预加载的模块直接有依赖，而恰恰

preload 又不支持有依赖的预加载（感觉这就是个累赘功能）。

解决办法：

1. 要想完美的解决，只有一个办法，就是改 preload 的源码，加上预加载依赖的功能就

行了。

2. 当然还有其他的方法，将被依赖的模块放到 preload 数组里面，将依赖的模块放到

Seajs.use 里面，而这个 Seajs.use 是放在 config 中的（巧妙的实现了有依赖的预加

载，但是不完美，要分开写成两个数组）。

6 \/ 33

Seajs.config({

base: \"\/text\/\",

preload: [

'js\/common.js',

'js\/module1.js', \/\/module2 依赖 common

'js\/module3.js'

]

});

Seajs.use(['js\/module2.js'],function(module2){

});

3. 单独写个预加载的 js，在里面用 require 把所有 js 都引进去，然后在页面上在易用这

个 js（这种方法没用过）。

五、 Seajs 的打包

模块分完了，最后上生产肯定是要打包的，总不能把源代码放上去吧。提到打包，Seajs 有

个打包叫 spm，唉，配置起来太麻烦，不想用，幸好还有 grunt 和 gulp，虽然也不好用，总

比没有强，总之，Seajs 的一整套解决方案让人用着很别扭，最起码在官网上应该说明，给出

一个整套的解决方案，但是官网上就一些简单的 api。

最后有个建议，虽然 Seajs 支持 require()可以放到任何地方，就是用到的时候再去加载，

这样可以提高性能。但是，还是强烈建议放在最上面，因为全部放到上面代码更易阅读，除非

一些对性能要求特高的需求外。

7 \/ 33

六、 总结

总体来说，用着还是可以的，就像介绍的那样：简单友好的模块定义规范和自然直观的代

码组织方式。简单好用胜过一切！

完

8 \/ 33

Linux 利用 perf 工具进行性能调优

作者 \/ 亚信国际韦昌太

在对自研 C++ RPC 框架进行性能调优时，linux 下 perf 工具作为我们使用的诸多工具中

的一种，其强大的功能为我们的测试工作提供了很大的帮助，在这分享给大家，希望能给大家

带来帮助。

一、 perf record

性能测试的最直接手段即为找到程序中的热点代码，对热点代码的优化可以比较明显地提

升性能表现。

perf record 可以以固定的时间间隔对 CPU 利用率进行采样，采样可精确到函数级别其生

成的 perf.data 可通过其他工具或方式处理后得到格式友好的分析数据。

下图中，以 99HZ 为频率对 PID 为 9176 的服务进行持续 60 秒的采样，-g 参数为获取采

样的 call-graph。

9 \/ 33

接下来可以使用 perf script 对 perf.data 进行分析，perf script 自动搜索当前目录下

perf.data 文件进行处理，得到调用栈采样及 event-cycles 次数。

通过 perf script 对采样数据的输出分析起来仍旧不够直观，为了能更直观形象的观察程序

中的热点，我们借助 FlameGraph 即火焰图来生成 SVG 文件。

执行如下命令，生成 SVG 文件后使用浏览器打开。

perf script > out.perf

flamegraph\/stackcollapse-perf.pl out.perf > out.folded

flamegraph\/flamegraph.pl out.folded > out.svg

10 \/ 33

从火焰图上我们可以清晰地看出主要热点函数及其调用堆栈，可喜的是用户态及内核态的

调用堆栈都得以展示。

如下的示例火焰图中，内核函数 tcp_sendmsg 的耗时有相当一部分消耗在 release_sock

函数中，这通常由于未正确使用 socket 全双工模式造成的，进而可以为后续的优化方案提供

指导。

而下图示例火焰图中展示的则是，用户态下一个接口的耗时热点在 boost 实现的线程局部

存储的实现上。

11 \/ 33

二、 perf top

如果想要实时获取服务即时热点及函数中具体热点指令，perf top 可作为首选工具。同 Top

工具类似，perf top 可以根据采样中 event 的占比进行排序，并按固定的频率刷新展示结果。

如下图：

执行命令 sudo perf top –G -p 9167

使用-p pid 参数抓取的一个服务的各函数热点占比排序，第三列[k]表示内核态函数，[.]则

表示用户态函数，通过-K、-U 参数可以分别隐藏内核态及用户态函数。指定-G 参数(call-

graph)，可以获取指定函数的简单堆栈(按 Enter 键即可)，如下图中的 malloc 函数。

指定到特定的函数后，按“a”键可以直接查看汇编指令详情(更多其他交互指令信息可键

入“?”获取)，如占比最高的 decode_struct 函数的汇编指令显示较多的耗时发生在获取函数

指针的语句上。请参见下图：

12 \/ 33

三、 perf stat

有时候我们需要获取对一个程序运行的整体状况，如 context-switches 等，perf stat 便

可派上用场了。

如下图，对一个程序 60 秒内汇总数据：

我们的测试程序是一个 IO bound 型程序，在汇总数据中，context-switches 是一个较

高值，同时 ipc(insns per cycle)则相对较低。若只关心单一指标时，如 branch-misses，通

过-e 选项指定缺省事件即可。

13 \/ 33

四、 总结

使用 perf list 我们可以看到，perf 还有非常多多其他采样点事件，perf 在包含诸多事件

的同时而无需在程序中设置锚点，为使用者带来了很大的灵活性。

在对热点数据的抓取上，相对与强大的 vtune 各有优劣，比如，vtune 的 2016 版本中提供了

非常丰富的多种维度的数据维展示，但想要使用 vtune 抓取内核态调用堆栈则会相当复杂。

在不同的场景下使用不同的工具，多种工具配合使用可事半功倍。

FlameGraph 不仅仅支持 perf event 还支持 systemstap 及 DTrace 等工具的采样数据生

成火焰图，项目请参见：https:\/\/github.com\/brendangregg\/FlameGraph

完

14 \/ 33

QA Review UT 的那些事儿

转载自\/ ThoughtWorks

作者简介：李春辉，ThoughtWorks 咨

询师，在测试行业将近 7 年，对测试

理论和方法有深入的理解，擅长敏捷

软件开发模式下的质量保障

一个风和日丽的下午，眉清目秀的 Dev 小乒挺了一下腰，喊了 BA、UX 还有 QA 小乓一

同 SignOff，十几分钟后，场景验收完毕，BA 和 UX 退位，只有 QA 小乓还定坐在那里，斩

钉截铁地说了句：“看下 UT 吧”，故事也就从这里开始了…

“嗯？还要看 UT?” Dev 小乒一脸突然。

“嗯，看下吧！” QA 小乓谈定的说。

“好吧……”Dev 小乒边回话边打开 Git 翻找，嘴里好像还在嘀咕着什么。

“这部分测了保险单的消息提醒功能” Dev 小乒随手打开一个测试文件。

15 \/ 33

“那理财单的消息提醒测了没？” QA 小乓追问道。

“没测，不用测，实现都一样！” Dev 小乒顺口答道。

“只测保险单，那理财单的挂了怎么办，它们是不同的业务，难道，还得手动一遍遍测

试？” QA 小乓皱了皱眉看了一眼 Dev 小乒。

“不用，相信我，我们是 TDD，测试驱动开发，再加也驱动不出新代码，再说实现都一

样，加了也是重复代码。”

说完这段话后，Dev 小乒身子往后一靠、椅子向后一滑，身体转向 QA 小乓，语重心长地

说：“小乓呀！我觉得吧，你不用看 UT，对你没啥用，再说都跟实现相关的，也很难给你讲

清楚……”

此处的 QA 小乓仿佛看到了无数只黑乌鸦从眼前飞过……

一、 为什么要 Review UT

1. 先从 UT 的重要性说起

根据测试金字塔，UT 处于测试金字塔的最底端。其特点是更贴近于代码，运行速度快，成

本相对较低，对问题的反馈也更准确。所以通常情况下，绝大部分的业务代码都会在 UT 层被

覆盖，也就意味着有近 70%或更高比例的业务逻辑会由 UT 来保护。

2. 再从”QA 对 UT”不可见的弊端谈谈

16 \/ 33

作为把控质量的 QA，对于这类在测试策略中占比最大的单元测试（UT）却通常是不可见

的。因为 UT 通常都是由开发人员编写，与实现紧密相关，又纷繁复杂，所以 QA 通常都不知

道在 UT 中到底测了哪些、没测哪些。这样一来，只能通过手动一遍遍测试或编写更加昂贵的

UI 回归测试予以保障，不仅耗费了很多精力，而且还可能会与 UT 测试有很大的重复。

但如果加入了 UT Review，使 UT 对 QA 可见，可以让 QA 更好的了解产品的质量情况，

制定更加有效的测试策略，就可以在增加整个团队对于产品质量信心的同时，使工作更加高效

合理，测试策略更加精简有效。

由于 QA 对于业务的理解也比较深入，有时还能在 Review 中发现漏掉的测试场景，在更

早期识别风险，避免更大问题的产生。

由此可见，Review UT 很必要，可是往往好事多磨，就像一开始的故事，QA 小乓就遇到

了很多困难。

二、 Review UT 过程中的那些困难

1. 开发人员内心排斥 QA Review UT

回想一下一开始的场景，Dev 小乒对 QA 小乓要 Review UT 表现得有些突然，包括 Dev

小乒最后语重心长的那句话。从 Dev 的角度，UT 是与实现相关的，与技术架构、工具选型、

17 \/ 33

甚至是底层设计相关，QA 又不懂。另外，QA 要 Review 他们写的 UT，可能会让 Dev 觉得

这是对他们的不信任。再者，SignOff 加入 Review UT 后，时间变的更长，成本也会相应变

高。所以，在刚开始推行 Review UT 的过程中，会出现双方合作不畅的情况。

【解决方案】：在 Review UT 这件事上团队内必须先达成共识，通过沟通使团队明白 QA

Review UT 不是因为对 Dev 不信任，也不是为了挑刺儿；而是为了挖掘前文中为什么要

Review UT 章节中阐述的 QA Review UT 能给项目带来的好处。另外，作为 QA 也需要了解

些代码方面的知识，比如：系统架构、Dev 用的 TDD 等，以便于更好的理解 UT，最终通过双

方的努力，不断的降低 Review UT 带来的成本，实现利益的最大化。

2. 测试结构乱，看不懂

刚开始 Review UT 就发现，UT 结构零散，经常需要在不同代码库、文件、及 Commit 中

跳来跳去，全程 Review 下来经常会感觉一片混乱，也搞不清哪些测了哪些没测。甚至还会使

得双方怨念四起、互相嫌弃，QA 嫌弃 Dev 写的乱、又讲不明白，Dev 嫌弃 QA 看不懂、还

嘚吧嘚！

【解决方案】：首先 Review UT 对 QA 提出了更高的要求，要对代码架构提前有个了解。

而 Dev 在写 UT 时，也要尽可能写的结构清淅易读、命名准确。在每张卡 SignOff 时，开发

人员可以先简短介绍清楚 UT 的结构（也可以简单画一画），再介绍哪部分 Test Case 放在了

哪里，然后去对应的结构里看相应的测试 。这样整个过程才会更加的顺畅，也才能真正的起

到预期的作用。

18 \/ 33

3. 根据现有实现，不需要再加

开发人员有时会说：“根据现有实现不需要加，这个业务和另一个业务实现代码是一样的。

再比如，这方法的实现是用数组，你提到的两种业务场景在这里就是数组里的 1 和 2，处理上

没区别”。

【解决方案】：测试验证的应该是业务价值，而不是具体的实现方式。而在业务价值不变

的前提下，实现代码却可能会发生变化，比如：代码可能被重构。所以测试也不该根据代码实

现来设计 CASE，更应该从业务价值来设计。当然实际情况中会有一些特殊情况，但总体原则

不变，即我们应该更多的通过测试来保障我们交付价值而不是具体实现。

三、 收获

经过一段时间的实践 QA Review UT，我们发现在不同程度上，都有了很大的收获。

1. 及时发现了 UT 上的一些问题并改进

Review UT 以后，SignOff 时发现了不少漏掉的测试场景，让一些 Defect 提前被识别出

来，避免了更大的损失和风险。

2、QA 越来越熟悉 Code&Test 结构

要想 Review 好 UT，QA 要大致了解系统的技术架构，而且每次 Review UT 前，开发人

员还会给介绍或画一下测试结构，时间久了，对于代码和测试的结构就会越来越熟悉，从而让

整个 Review 过程变得越来越有效率。

19 \/ 33

3、QA 和开发人员更近了

在 Review UT 的过程中，QA 和开发人员之间更多的交流，介绍测试结构时，会提到实现

架构与实现等，渐渐 QA 对 DEV 的术语也懂的多了，也更了解了开发人员的测试思维，沟通

合作起来更顺了，Review UT 过程中遇到双方争异也更易解决了。

4、开发人员测试 sense 提高

QA 更多地从业务角度以及从测试专业角度思考问题、交流，在 QA 潜移默化地影响下，

开发人员对于测试和质量的 Sense 也有了提升，UT 的质量也有了明显的提升。

5、团队对质量更有信心

QA 参与和开发人员一同严格把控了重要的 UT 环节，也清楚了哪些业务价值已经在 UT 中

被覆盖，所以在设计更高层次的测试时就会更加有针对性，减少了重复测试带来的浪费，同时

团队对产品质量也更有信心了。

6、QA 做更多有价值的事儿

被 UT 覆盖的业务价值对于 QA 来讲不需要做完整的细枝末节的手动回归测试了，只需要

做一些针对性的探索性测试，这样 QA 就有了更多的时间做更有价值的事情。比如：更早参与

需求分析、Review Story，写 Regression 测试，实施內建安全&性能， 以及生产环境下 QA

的事儿等等！

完

20 \/ 33

指标同名同义的自动化分析方法和应用

作者\/ 黑带大师王全胜

一、 背景

一个企业，在长期的经营过程中，会积累大量的指标信息。所谓的指标如用户到达数，收

入，使用次数等。

在指标的管理过程中，一个指标一版都会有一下关键属性：

指标编码：指标的唯一标识

指标名称：指标的短名称。如活跃客户数

指标单位：指标的计量单位，如户，万元等

指标类别：指标的分类。如收入类，市场竞争类

指标业务定义：企业管理人员或业务人员可以理解的一段文字描述

指标统计口径\/计算公式：从技术定义，比如查询统计脚本，或计算公式

现有指标管理经常存在以下的问题：

（1） 存在歧义和冲突。从指标业务定义描述是一段自然的描述，缺失结构化标准化的要

21 \/ 33

求，造成描述不完整，无效描述，容易引起歧义。如常说的同名不同义，同义不同名等。

（2） 指标梳理归并和剃重。因此存在大量的歧义和冲突的指标，所以经常需要对指标进

行排重归并。在梳理归并和剃重过程中，需要业务管理人员、技术人员花费大量的精力进行梳

理完善和人工确认。工作量非常大，准确性不一定高。

二、 解决思路

根据指标名称和统计脚本，建立指标名与义一致性的自动化识别分析方法.输出问题指标

列表，并给出不一致的合并解决策略，优化指标的管理。关键的解决思路如下：

（1） 指标名称的分析。根据指标定义描述，指标名称，根据中文分词、匹配，发现指标

的相似程度，指标的关系。能够从成千上万的指标定义中自动发现指标的相似性，差

异性。

（2） 指标口径分析。根据指标的统计定义口径，发现指标计算过程的相似性和指标关

系。

（3） 基于上述两点技术手段，识别指标管理的难题：发现同名不同义、同义不同名、指

标之间包含关系，相似关系。然后根据自动化发现问题，为指标的归类、合并、质量

稽核、指标组合分析、清晰化定义提供重要的信息。

22 \/ 33

三、 详细技术方案

（1） 指标分析。此步骤是根据输入的大量指标列表，采用算法，自动分析指标的相似性，

输出同名不同义，同义不同名的问题指标，一方面可以提高指标的梳理效率，提升定

义的准确性，指标合并的策略依据；另外一方面，未来新增指标时，可以对新增指标

跟现有的指标的相识性一致性做出判断，确保新增指标的合理规范。

（2） 合并优化。根据上一步输出的结果，系统给出合并优化的策略。消除掉冗余有歧义

的指标。

（3） 对合并优化后的指标进行跟踪评估。验证合并优化的效果，确保指标管理的可持

续。

3. 指标名称分析

指标分析是根据输入的大量指标名称，系统自动计算出指标的关系。

对于一个指标名称我们分解为维度变量和度量变量。如下所标识：

23 \/ 33

指标的关系：我们将两指标之间的关系分为以下几种

一致关系：维度变量和度量变量一致

相关关系：维度变量一致，度量变量不一致

包含关系：一个指标维度变量多于另一个指标的维度变量，度量变量是一样的

无关关系：维度变量和度量变量都不一致

指标名称分析的计算过程：

关键算法说明如下：

（1） 指标名称分词处理

功能说明：指标名称分词处理，输入指标名称，从词库进行匹配切词，输出指标的维

度变量和计算变量。包括词库、分词算法。

词库：词库包括：通用的中文词库、维度词库、度量词库。

24 \/ 33

1） 通用词库：采用汉语词典词库，作为通用的分词词库。

2） 维度词库：维度词库保护维度名称以及维度的内容构成。如客户状态维度，词库

里面包含：有效客户，无效客户，客户类别包括：vip，普通，高端等。

3） 度量词库：是度量信息。比如客户数，收入，流量，访问次数。

4） 同义词库：同义词库是指虽然两个词中文不一样，但意思是一样的。如客户数和

用户数是同义词，通信和通话度量变量时是一致的。

分词算法

采用开源项目 Luence，结合词典分词和文法分析算法的中文分词组件，采用正向

迭代最细粒度切分算法。匹配查找顺序：度量词库、维度词库的内容、通用词库。分词的结

果如下示意：

（2） 分词结果的比较

对分词的结果进行比较。比较内容项目包括维度变量比较和度量变量的比较。如下示

意图：

25 \/ 33

特别说明：

度量单位的比较跟度量词所在的位置无关。如月沉默飞信用户数等同于月飞信沉默用

户数。

需要考虑别名。如客户数和用户数是一致的别名，因此度量变量虽然不一致，但结果

认为这两个指标是一致的。

（3） 指标关系的评判

根据分词的结果的比较，根据以下规则进行指标关系的评判：

1） 一致关系：如果两指标的维度变量和度量变量一致,则关系为：

2） 相关关系：如果两指标的维度变量一致，度量变量不一致，则关系为：

3） 包含关系：一个指标维度变量多于另一个指标的维度变量，度量变量是一样的，

则为。

指标名称分析关系评判结果表：

4. 指标统计口径分析

指标统计口径分析，是根据指标的统计 sql 脚本，识别指标是否是一致的，判断出指标的

关系。其计算过程如下图：

26 \/ 33

关键算法说明如下：

1. Sql 解析器。本计算过程用到一个关键技术，sql 解析器。

所谓的 sql 解析器，其能力是根据输入的 sql 语句，经过解析器解析之后，可以输出：

sql 的输入表，sql 查询条件，关联条件，计算字段。如下示意图。更多关于 sql 解析器

原理查看另外一个发明专利。

27 \/ 33

2. 数据血缘关系。数据血缘关系记录的是数据表的来源，是由哪些输入表经过 sql 语句的统

计计算而来的。

数据血缘关系的建立，是经过一段时间采集，从程序运行日志或数据库的执行记录中，

获取数据中心所有的执行 sql 脚本，经过 sql 解析器，建立数据的输入和输出的关系。

详细信息参考数据血缘关系自动化建立的技术方案。

3. 计算过程

（1） 判断指标统计口径是否同一统计表。输入待分析的指标的统计 sql 脚本，进行

sql 解析。如果统计的表是同一张表，则转到 2；否则转 3.

（2） 判断 sql 的关系。判断 sql 的关系是根据输入的两端 sql 脚本，根据 sql 解析

器进行条件解析，判断 sql 是否一致，或其之间的关系。这是本案的一个技术难点。

关键的算法如下：

A. 将 sql 语句经过解析处理，对象化

B. 从 TWhere 的节点获取子条件

28 \/ 33

C. 根据 where 条件比较 sql 之间的关系：

D. 输出比较的结果。根据上述的比对，最终形成。转（5）.

（3） 判断两指标的统计 sql 是否有共同的表。

假设一个数据流图如下：

系统建立完善血缘关系。关系表如下：

29 \/ 33

判断两个 sql 在血缘路径上是否有相同的表，其计算构成如下：

A. 分别对每个 sql，分析其查询的源表，根据源表，再从关系表进行递归查找，

得到其路径上的所有源表。将路径上的表信息保存到一个数组列表。

B. 分别比较数组，如果数组存在相同的表，就说明这两个 sql 有共同的源表，即

说明他们有共同的血缘。

C. 如果没有共同的血缘，则说明这两个指标在统计口径上不相关。如果有共同的

血缘则转（4）.

（4） 将 sql 统计脚本转移到其血缘关系上的指定表的统计脚本。

此步骤的功能是将基于某个表的查询统计脚本，源着这张表的血缘路径上的表，

转换为等价统计脚本。

如下图：两个指标分别从统计的数据路径上的表统计，判断着两个指标的统计口

径的关系。

30 \/ 33

具体的分析过程如下：

示例说明如下：

然后转到步骤（2）.

31 \/ 33

（5） 经过计算之后输出的结果。

5. 指标分析结果的评判

对指标名称分析和指标统计口径分析，进行评判。评判的类型如下：

如果指标名称分析发现指标名称一致，但指标口径分析发现统计口径不一样，则两指

标属于同名不同义；

如果指标名称分析发现指标名称不一致，但指标口径分析发现口径含义不一样，则两

指标属于同义不同名；

如果指标名称分析发现的关系类别和指标统计口径发现的关系类别不一致，则指标之

间有问题。

32 \/ 33

6. 指标优化策略

如果发现两指标之间存在问题（名称判定的关系和口径判断的关系不一致时），根据不一

致的情况，采用不同策略进行优化。优化策略如下表

7. 跟踪与评估

主要对两类的指标进行跟踪评估：

如果存在名称一致，统计口径一致，查看数据是否一致，如果一致，说明确定可以下线一

个指标。

如果 A 与 B 指标的名称为包含关系，但统计值 A 却小于 B，说明质量问题，需要进一步

核查数据。

完

33 \/ 33