大数据上的数据稽查原理和方法介绍（下）

前情回顾

脏数据的存在会影响查询的执行过程和准确度，因此要求业务分析人员在将数据整合进数仓前进行清洗。然而，由于有时清洗不彻底，脏数据可能难以避免。其实如果完全剔除脏数据确实有难度，只要保证其不被访问，就不会影响语句的执行，也意味着能够接受它的存在。数据稽查就是用来避免脏数据被语句访问的一种功能，它将作为一道防守，在查询语句访问数据时，使引擎绕过脏数据，直达合法数据。通过它就可以在脏数据存在的情况下，提升查询和分析的准确度，甚至提高决策的可靠性。

在《大数据上的数据稽查原理和方法介绍（上）》中我们已经介绍了数据稽查的基本概念、Inceptor是如何利用Log Error Table做到稽查的，以及数据稽查的启用方法和特征。本文将继续深入Inceptor数据稽查，介绍其属性控制手段，分析如何理解Log Error Table的内容，以及对它的权限控制。

控制指定表的数据稽查属性

Inceptor允许用户以表为粒度维护数据稽查属性，包括对某张表的数据稽查的开启和关闭，和对这张表的稽查属性的更改。

1. 停止某表的数据稽查

   下面的语句将停止对table_name做数据稽查，不再记录其脏数据信息。这只是对table_name的数据稽查属性所做的变化，不影响其他表。

   ALTER TABLE table_name SET ERRORS LOG OFF;
   

2. 开始某表的数据稽查

   使数据稽查重新作用于table_name，此时必须设置OVERWRITE和REJECT的状态，n必须为整数。

   ALTER TABLE table_name 

   SET ERRORS LOG ON OVERWRITE [on|off] 
   REJECT [on|off] LIMIT n ROWS;

   没错，该语句也可以用于修改OVERWRITE和REJECT的设置。

例 1. 通过SET OFF LOG，停止对employee做数据稽查

① SET OFF LOG之后，“SELECT * FROM employee”将返回包括脏数据在内的全部数据。

② 对employee关闭数据稽查后，count(age)返回总字段数。

③ 查询Log Error Table，发现没有脏数据信息录入。

例 2. 对employee表重新打开数据稽查，OVERWRITE on，REJECT on LIMIT 2 ROWS

① 启用数据稽查属性后，“SELECT * FROM employee”将脏数据剔除出返回结果。

② 此时，count(age)返回age字段合法数据的总行数。

③ 可以发现employee_error_table中成功覆写了三条报错信息。

Log Error Table的相关信息

使用数据稽查时，有下面三种关于Log Error Table的信息我们可能是会关心的。

检查是否成功指定Log Error Table

拿到一张表table_name，我们有时会想查看这张表的Log Error Table是否已被指定。这可通过“DESC FORMATTED table_name”实现。如果在返回结果中存在形式如下的信息，则表示该表已有关联的Log Error Table。

ErrorTableSetting{errorTableName='employee_error_table', rejectEnable=true, overwriteOn=false, rowCount=2}

Log Error Table的结构

Log Error Table的构造语句如下，由系统自动构建不用手动操作：

CREATE TABLE error_table_name (     

sql__time string,     

issue__sql string,     

real__table__name string,     

error__file__name string,     

error__block__offset bigint,     

error__msg string,     

raw__data string     

);

以下为各字段的代表含义：

• sql__time：报错语句在何时被执行。

• issue__sql：执行什么语句时报的错。

• real__table__name：在访问哪张表时读到脏数据。

• error__file__name：脏数据具体所在的文件。

• error__block__offset：脏数据所在文件的块偏移。

• error__msg：报错原因。

• raw__data：出错记录的原始数据。

或者可以通过“DESC error_table_name;”亲自查看Log Error Table的结构。

查看Log Error Table内容

从操作的角度讲，Log Error Table可视为普通表，也就是说通过SQL访问其内容。例如，通过“SELECT * FROM error_table_name”就能够查看其中完整内容。在之前的例子中也可以看到，我们是用“SELECT count(*) FROM error_table_name”获得脏数据记录行数的。

例 3. 查看Log Error Table的内容

① 该语句用于查看employee_error_table(employee的Log Error Table）内容，因为显示信息过长，可以把返回信息保存在文件“/tmp/error”中以便显示。

Log Error Table的权限控制

对于Log Error Table，Inceptor设定了如下的授权规则：

• 如果外表的SELECT权限被GRANT给用户B，用户B只拥有该外表的读权限以及相关Log Error Table的写权限，但是没有该Log Error Table的读权限。也就是说，如果需要读Log Error Table，必须将该Log Error Table的SELECT权限额外GRANT给用户B。

• 如果外表的权限没有被GRANT给用户B，用户B将不具有对Log Error Table的任何权限。

总结

我们通过两篇文章介绍了Inceptor的数据稽查功能，解析了它的诞生原因，提供了它的控制使用方法。由于脏数据不仅对查询结果有影响，而且可能导致执行中断，所以数据稽查功能的出现，不仅能提高结果准确度，还能保证语句顺畅运行。为分析者减少了清理脏数据问题的任务量，提高分析效率，节省分散给彻查脏数据的精力。

---

往期原创文章

大数据开放实验室由星环信息科技（上海）有限公司运营，专门致力于大数据技术的研究和传播。若转载请在文章开头明显注明“文章来源于微信订阅号——大数据开放实验室”，并保留作者和账号介绍。