数据探查

接触数据仓库也半年多了，一直都知道数据质量的重要性， 前面也看过几篇数据质量的博文，但是没有真正的在实践中去做过。上周接触了一下数据探查，发现数据探查对于数据质量是非常重要的一个环节，它是决定最后数据正确性的非常关键的一步。   数据探查阶段为ETL团队提供了指导，告诉他们需要使用多少数据清洗机制，并且使他们不会因为创建处理脏数据的系统分散了注意力而遗漏项目的主要环节。一定要预先进行数据探查工作！使用数据探查结果，可以设定业务发起人对于实际开发时间表、源数据的局限性和对更好地源数据捕捉方法进行投资的需求等的期望。

        在启动主数据管理项目之前，需要了解数据的内容、质量和结构。在数据源进行的数据探查使数据管理员和数据仓库管理员能够在数据进入主数据管理项目之前，快速发现和分析跨所有数据源的所有数据异常，此流程可极大加快从主数据管理项目实施中获取价值。

        由于数据清洗增强了数据的准确度，带来了数据完整性，并从源头增进了数据的可信度，因此数据清洗改善了主数据管理项目系统中的数据一致性。

     “数据探查、数据质量和数据集成是三个搭配使用的商业惯例，就像面包、黄油和果酱⋯⋯。数据管理专业人士及其商业对手需要协调工作并设计有效结合所有这三个惯例的项目。”

从上图可以发现，

数据探查在数据质量流程中的位置。我们从源系统中查询到各种数据，然后对数据进行分析和探查，而数据清洗过程将利用数据探查的结果进行有效的清洗，最后达到数据集成，以提供正确的数据。

本次用到的具体的数据探查语句：

1.Null值统计

• selectcount(*)总记录数
         round(sum(decode(A,null,1,0)) /count(*) * 100,2) from t

2.主键ID长度的统计

selectdistinct (length(A))from t

3.码表或者状态值的数量的统计

    码表类型名称及其每个类型下数据量的统计

项目中，我们需要给其他系统对抽表数据，对抽表的数据就是将源表中的数据，完全对抽到目标表中。这个过程本来觉得很简单，直接将数据抽取过去就可以了，但是后来发现不是那么回事，你要对你送出的数据负责。

       这些数据到底是什么数据？这些传过去的数据是否正确，业务含义是什么，表的用处是什么？表中某个字段的字段结构是什么，等等这些都要知道。

        1.源表的数据量的统计          

           select   count(*)  as 总记录数 from t
        2.源表字段空值的统计

           select round(sum(decode(A,null,1,0)) /count(*) * 100,2)   from t

        3.源表字段的业务含义是什么

           比如一个表中有inputdate，有datadate，那这时候你就要去探究了，这两个字段到底都是什么业务含义，他跟增量规则是否有关。

        4.源表字段的数据格式

          比如一个表中有Inputdate字段，这个字段就是增量时间戳字段，在做增量加载时，是采用 where inputdate =date  '业务日期'   还是采用where inputdate=trunc('业务日期)，这时候就要看inputdate中存放的数据的格式了。如果有时分秒，则需要用后者，否则用前者。

          还有金额字段，是否有小数位等等。

        5.增量规则

           我们一般采用的增量规则方式为时间戳方式。这时，对于一个表，就要探查它是业务源表，还是SGA层表？如果为sga层表，那么这个表是日增量表还是日全量表，如果为日增量表，那么它的增量规则是什么？

        6.是否符合需求

           这个大方向一定要把握好。源数据-->数据仓库，数据仓库提供接口数据--->A系统。不但要把表中的数据探查清楚，还要通过探查数据，看传过去的数据是否符合A系统的需求。

 

         数据探查使数据质量中关键的一步，要认真做好这一步，才能真正把控数据来源，减少返工。

只是意识到了对于表内数据的探查,即表内数据量、空值、关键字段、类型、数据格式等的探查，而没有站在更高的角度去想数据探查。

 

        数据探查，是在拿到需求后，首先从战略上去探查确定候选数据源，即去探查会涉及到哪些源系统，涉及到源系统中的哪些表，对于系统中涉及到的表的表结构，表内数据，表与表之间的关系（一对一，多对一，一对多等），及其选定的数据源是否适合包含在数据仓库中，而我所理解的数据探查只是在选定了数据源之后的更细的数据方面技术性的探查，具体见数据探查（一）  和数据探查（二）。

 

    数据探查是对数据的技术性分析，对数据的内容、一致性和结构进行描述。

    数据探查担负着两种不同的任务：战略性的和战术性的。

    战略性：一旦确定了某个候选数据源，就应当进行一次轻量级的探查评估来确定该数据源是否适合于包含到数据仓库中，针对早期的采纳/不采纳问题提供决策。理想情况下，应当在业务需求分析过程中确定出一个候选数据源之后立即进行战略性评估。较早地找出那些不合格的数据源是一个责任重大的步骤，即使带来的是坏消息，也是必要的一步。如果很晚才发现数据源无法支持要做的工作，对DW/BI团队的积极性将产生重大的打击，特别是当项目已经展开数月之后才发现数据源存在问题时更是如此。

    战术性：一旦将某个数据源引入项目的基本战略决策已经定下来，就需要进行一系列战术性的数据探查工作来尽可能多地确定出各种问题。通常这一工作从数据建模过程就开始了，一直到ETL系统设计过程。有时ETL团队也可能需要使用一个其内容没有经过彻底评估的数据源。系统也可能支持产品过程的需求，但是却存在ETL方面的难题，因为对产品处理并不重要的字段用来进行分析也是不可靠和不完整的。该子系统中揭示出来的问题最终会产生两种详细说明：1)将数据送回原来的数据源中，请求改善数据质量；2)构成了数据质量子系统的需求。

   

    总结：探查阶段是建设DW模型的基础，也是ETL设计的基础，唯有做好数据探查才可以使得DW的工作更加顺畅。

          探查阶段为ETL团队提供了指导，告诉他们需要使用多少数据清洗机制，并且使他们不会因为创建处理脏数据的系统分散了注意力而遗漏项目的主要环节。一定要预先进行数据探查工作！使用数据探查结果，可以设定业务发起人对于实际开发时间表、源数据的局限性和对更好的源数据捕捉方法进行投资的需求等的期望。