数据探查（三）

    昨天去面试,被问到数据探查心得,想了想,自己理解的数据探查还是比较浅显的,只是意识到了对于表内数据的探查,即表内数据量、空值、关键字段、类型、数据格式等的探查，而没有站在更高的角度去想数据探查。

 

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

 

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

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

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

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

   

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

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