首页 / 新闻

03.

24

2017

大数据上的数据稽查原理和方法介绍(下)

技术博客

前情回顾

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

在《大数据上的数据稽查原理和方法介绍(上)》中我们已经介绍了数据稽查的基本概念、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的数据稽查功能,解析了它的诞生原因,提供了它的控制使用方法。由于脏数据不仅对查询结果有影响,而且可能导致执行中断,所以数据稽查功能的出现,不仅能提高结果准确度,还能保证语句顺畅运行。为分析者减少了清理脏数据问题的任务量,提高分析效率,节省分散给彻查脏数据的精力。

对此篇文章如有任何问题,欢迎以邮件形式联系我们:bigdataopenlab@transwarp.io