微软BI 之SSIS 系列 - 使用 SQL Profilling Task (数据探测) 检测数据源数据

开篇介绍

SQL Profilling Task 可能咱们不少人都没有在 SSIS 中真正使用过，因此对于这个控件的用法可能也不太了解。那咱们换一个讲法，假设咱们有这样的一个需求 - 须要对数据库表中的一些数据作一些数据分析，好比统计一下数据表中各列中实际数据的长度，各长度区间范围；好比统计一下各数据列中非空字段的比例，表的行数，重复字段等等。那么若是不是专门作过这种数据源数据分析的话，可能不知道用什么方式可以很是快的获得这些信息。写 SQL 语句？我想这个过程也是很是耗费时间和精力的。

实际上，在 SSIS 2012 中有这么一个控件 SQL Profilling Task 能够帮助咱们作到这些事情，对数据源的数据快速的作出分析。可以很是快速的弄清楚咱们面对的数据源是什么样的一种特征，这些将在实际 ETL 处理过程当中对咱们 BI 开发人员是很是有帮助的。而且，还有一种状况，咱们能够将这种数据分析的结果直接在 SSIS 中经过邮件发送给相关的数据库管理员，或者数据分析和管理人员，那么他们对这种数据的了解会更加清晰，更早的判断出数据源中的数据异常等问题。

SQL Profilling Task 的初步体验

新建一个包，并新建一个 ADO.NET 连接管理器，此次咱们的测试源对象能够换成任意一个数据库，那我这里把数据源换成 AdventureWorkLT2012 数据库。

注意：在这里必须使用 ADO.NET 连接管理器，这是一个特别的限制，而且只支持 SQL Server 版本。另一个就是必须对 tempdb 数据库有读写权限，由于这里面有大量的计算，聚合汇总等过程。

拖放一个 SQL Profilling Task到控制流中。

双击编辑，第一件要作的事情就是建立一个 XML 文件来保存 SQL Profilling Task 对指定数据源，表的分析结果的文件。OverwriteDestination 能够每次指定让它覆盖掉之前的旧文件，可是另一种方式就是根据执行日期去生成不一样的文件，关于这一点在前面不少例子中就已经提到了。

选择 Quick Profile 

在这里选择好以前建立好的 ADO.NET 连接管理器，并选择表或者视图； 咱们在这里首先配置的是表 Product，配置完成以后对于后面全部的表是均可以看的到的。

上面配置完成后，将跳转到 Profile Requests 处，在这里须要选中每一种 Profile，而后根据须要对每一张表的所有字段 (*) 或者某一个字段作 NULL 值检查。里面的每一项 Profile Type 都是进行差别化配置的，即不一样的表，不一样的列能够配置或者不配置，默认状况下都是 Product 表的配置。

这一点体验是不太好的，就是若是我须要从新添加一张新的表的话，咱们须要建立新的 Profile Type - 在 Profile Type 下面点击空白的地方新建立一个 Profile Request。

咱们继续为 SalesOrderHeader 表的 AccountNumber 作出空值统计处理。

保存以后运行包，并打开生成以后的 XML 文件。

很明显，这个 XML 文件即便拿到手也是看不出来什么的，正确的打开方式应该是经过 SQL Server 2012 自带的 Data Profile Viewer 工具来查看。

打开 Data Profile Viewer 以后加载包产出的 XML 文件，能够看到图形化的分析结果。

以 Product 表中 Color 为例，NULL 值的条数有50条，占了总行数的 16.94 %。

咱们来验证一下结果，发现和上面的分析结果是一致的。

下面就对这几种 Profile Type 作一个详细的解释。

单列统计类型

Null Ratio Profile (NULL 比率统计)

通常用来检查在数据列中 NULL 值的所占比例，好比说经过分析的结果发现某一列的 NULL 值所占比较太高，可能超过了预期，那么这种状况下是否是数据不太正常，丢值太多。好比在客户关系管理系统中，做为很是重要的联系方式 - 手机号码，电子邮件，地址等。对于这三者来讲 NULL 值所占的比例应该手机号码最小，地址和电子邮件其次，而且手机号码的 NULL 值比例应该很是很是小才是正常的。若是做为重要分析因素的手机号码的 NULL 值比例很是高，这时就说明咱们的数据源数据存在一些问题，那么就须要引发注意。有多是业务操做不规范，也有多是数据源准备数据的时候出现问题。

好比在下面的几个列中， Color, Size, Weight 就能够经过 SQL Profilling Task 获取到具体的 NULL Ratio 比例。

能够看出数据源中的 Weight, Size, Color NULL 值比较从高到低，Weight 列种有97条空值，所占比例 32.88%。至于这个数据是否合理就须要和业务人员来肯定了，也就是说咱们在设计咱们的数据仓库时，作为数据分析的依据时这些信息是事先就应该要了解的。

 

Column Length Distribution Profiles ( 列长度分布统计数据 )

对于列中的数据长度去重并进行统计各长度所占所有数据行的个数与比例。这个 Profile 有助于帮助咱们了解，第一是业务数据源中的数据长度定义是不是合理的，好比说业务数据源中的这一列在历史 5 - 10 年中的数据长度最长就是 35，可是定义了255 的长度。那么咱们在数据抽取的时候，来定义咱们表列的长度时这个就是依据，由于咱们发现历史上全部的数据长度都没有超过 35。第二是能够查看到异常数据，好比身份证号码通常默认大概是 18 位，那么在这个图中就能够很是容易的看出来是否存在异常数据，好比说有大量的超过 18 位，或者小于 18 位的数据。

好比下图中，Name 列中最小长度是5，最大是 32，长度为 23 的数据占据比例最高。

固然在设计长度检测时候，对于空格的处理也是很是方便的。IgnoreLeadingSpaces - 是否忽略开通的空格，IgnoreTrailingSpaces - 是否忽略结尾的空格。

Statistics Profiles (列统计信息)

这种统计是很是有意义的，特别是对于数字，日期类型的字段，能够很是直观的看到它们的最大，最小，平均值，以及标准差值（时间只有最大，最小）。经过这些统计能够看到数据是否存在异常状况，好比价格的最大和最小值会不会出现负值，最大值是否偏离的离谱等等。

关于这里面的平均值 Mean 还有 Standard Deviation 请参考统计学中的平均值和标准差等计算方式。

Value Distribution (列值分布统计)

去重以后列的值分布状况，那么这种统计一方面能够帮助了解源数据中有哪些数据能够做为分类出现，哪些数据基数很大不适合作这种分类。另一个，这种统计也能够帮助咱们鉴别列中数据的质量。好比说中国的省份经值分布统计以后发现多达上百个，那么这种数据是有问题的，会很是容易的看出来。

如下图为例，能够很是明显的看到各个列中值的分配状况，像 Color 这种列是很是适合做为维度的一个属性用来分析事实表中的数据的，可是像 ProductNumber 这种基数太大不适用用来分析事实数据。而且在 Color 列中也能够很是直观的看到哪种颜色的产品目前最多，所占的比例是多少都很是清楚。

Pattern Profiles(列模式，正则表达式分配统计)

为字符串类型的数据提供正则统计，好比邮件地址的正则通常只有有一种正则表达式，若是看到的是其它的表达式有可能说明之前的验证是错误的。还有就是经过对统计数据的分析能够看到哪种表达式所占据的比例多，高，越多越高的说明这种比例应该是正常的，能够考虑之后全部的验证按照这一种走。至于其它的能够考虑若是是业应用中修改，或者在抽取数据的时候认为这种数据是异常的，是须要处理的。

例以下图中产品 Size 大小的表达式正则为 \d\d，占据了 84% 的数据比，说明大多数 Size 的内容都是数字类型的，可是也有一些填写的值是 M, L 这种字符类型的；那么像这种数据再抽取到数据仓库以前就能够发现，因此才有时间来考虑这种少许的非规则的数据应该如何来处理了。

多列或表级别探测类型

Candidate Key Profile (候选主键探查)

对于选择要探测统计的列进行统计，看看它是否符合主键的特征，或者近似主键。好比说，咱们可能以为某一列应该做为主键，可是最终统计下来发现由于存在重复值只能做为近似主键存在，那么在选择时候就要注意了。

好比在下图中的这三列都是非重复列，100%的符合了主键的特征，所以这几列能够做为主键候选列来考虑。固然最终如何选择，这个分析只能是一个参考，好比咱们还须要考虑字段的类型，长度等因素，尽可能选择整型数据；即便是字符串的话，也应该选择长度更短的列。

可是这个值是否是 100% 彻底与实际相符的，不必定，这里的显示和配置 Candidate Key Profile 时有关。

好比在选择 Specified 的时候就能够列出全部的列 (*)，当非重复率达到 95%以上的时候就应该认为是 100%了。

而在选择 None 的时候这时须要选择到固定的列，或者一个列两个列组合造成。

Functional Dependency Strength Profile (函数依赖关系统计)

能够这么来理解这个统计所作的事情，好比说在一个销售统计里，有国家，省份和城市，一个城市一定属于一个省份，而一个省份也一定属于一个国家。若是在数据中好比说咱们发现了城市，例如杭州属于浙江的同时，它在另外的一条记录中也属于了省份江苏，那么很明显这个数据是有问题的。

函数依赖关系就能够检测这种依赖关系，好比在 1000 条带有杭州的数据中，有 999个杭州的数据对应的省份是浙江，有1个不是，那么杭州对浙江的依赖比率应该达到 90%以上了。

好比下面这幅图中，SalesPerson 对 CompanyName 的“依赖”，CompanyName 对 SalesPerson 的"决定性"达到了 99.76%。换句话说，只要知道了 Company Name 就有 99.76% 的可能可以肯定它的 Sales Person 是谁? 只要知道了城市是杭州，那么就有百分之多少的可能知道省份是谁，固然城市与省份之间的决定应该达到 100%。

在 Friendly Bike Shop 中有 4 条数据，其中两条是可以决定 Sales Person 是  adventure-works\david8，另外两条不是的，所以这种依赖率是 50%，可是总体上全部的数据这种依赖率是 99.76%。

Value Inclusion Profile 值包含统计

主要用来计算两个列之间或者多个组合列之间列值的重合状况，经过 Value Inclusion 值统计能够大概决定好比两个表之间的列是否适合创建外键的引用关系。或者，从另外的一个角度来讲，若是这一张表的某列引用了另一张表，造成了理论上的这种外键关联；那么经过值包含统计就能够看出来这种关联是否正确，好比 B 表的某列的值都是来源于 A 表的某列，可是经过探测发现 B 表某列的值在  A 表中是找不到的。

由于在这里没有特别好的例子，在已经创建好外键关系的表中这种探测确定是没有任何问题的，因此咱们在这里只是来理解一下 Value Inclusion 的用法便可。

咱们来看看 Product 表中的 ProductCategoryID 对 ProductCategory 表中的 ProductCategoryID 的引用状况（值包含状况）。

最后的结果不出意料基本上就是 100%的关联率。

总结

在 BI 系统中，最重要的一个环节莫过于 ETL 了，而数据源又与 ETL 的设计与开发息息相关。特别对于一些没有良好维护的数据源，其质量的好坏将在很大程度上影响 ETL 的设计。所以理解好数据源，分析好数据源的数据对后期的 ETL ，表的设计起着很是重要的做用。 咱们能够经过 SQL Profilling Task 对咱们的数据源有一个大体的了解，经过以上的这几种方式的分析，基本上能够知足绝大部分数据探测的须要。特别对于那种应用系统边升级，BI 系统边升级的的项目，应用系统自己并不健全的状况下，其数据的质量上也多是存在很大问题的，这样就给咱们的 BI 设计带来了不少不很差的影响。因此在一些 ETL 设计中，咱们甚至能够采用在 SSIS 中经过邮件周期性的发送这种探测报告给 BI 系统维护人员，尽可能地作到周期性的对源数据的预防性检查工做，提早避免一些不规范的数据带来的意外后果。

 

最后提一下，还有一件事情要作! 若是总是去分析这个 XML 是不该该的，由于这种数据都不能集中呈现历史数据的。所以最好的方式是解析 XML 文件，将数据解析的结果保存到数据库中，本身用报表的形式来呈现。这样不光能够看到当前的结果，并且还能够对比以前全部的历史结果，作到对数据源的探测管理 - 数据源的监控管理也是属于 BI 监控管理的一部分，关于这一部分就不详细展开了！

更多 BI 文章请参看 BI 系列随笔列表 (SSIS, SSRS, SSAS, MDX, SQL Server)  若是以为这篇文章看了对您有帮助，请帮助推荐，以方便他人在 BIWORK 博客推荐栏中快速看到这些文章。