ETL－谁是最终使用者

ETL－谁是最终使用者
--------------------------------------------------------------------------------
2006-02-27 0607 数据仓库之路 【文章字体：大 中 小】 

ETL工具的使用者是谁？ 在大部分BI项目组，都有一个专职的ETL工程师，负责ETL的正常调度和错误处理，此人是主要使用者。 另外就是项目组其他成员，这些人一般都会SQL语句，会写存储过程，还懂一点业务，是数据仓库建设的中坚力量，他们直接影响了数据仓库好坏，但一般不会象ETL工程师一样，深入追究具体的ETL步骤，他们只关心数据流，数据的依赖关系。ETL工具做为数据仓库的驱动器，应该着力为这批人服务，就是要清晰的展现出数据流，明确的标明数据流向。另外一点是绝大多数的转换规则、映射关系都出之这部分人，然后由专门的ETL工程师来实现，由于在交接时会产生一些理解偏差，会带来一些问题，同时，这些规则在项目初创时期会经常变动，导致ETL工程师非常被动，严重拖延进度。 一直以来，我都有一个想法，开发一个易于部署、使用的ETL工具，弱化ETL工程师的责任，转换规则、映射关系由数据仓库设计人员自己来实现，目前已经有了比较清晰的方案，无论是前台界面还是后台结构，都初见雏形。但需要较多的人力、物力，个人是无法完成的。同时也很想证实一下，方案是不是合理，毕竟我经历了一个在ETL上遇到很大困难的BI项目和其他几个小项目，参与过数据仓库建设，维护过一个很难使用的ETL工具，参加了一个极度延时的ETL工具开发项目，经历了这么多的磨难，对ETL工具开发这块至少是积累了不少的行业经验，同时也从客户那里直接获得了不少的需求，对于功能的取舍相对理性。 还有一些，就是客户，他们都会有专门的技术人员跟踪进度，时不时的关注一下ETL过程，毕竟ETL占有60%以上的工作量，但他们一般也只关心数据流，偶尔对数据质量有一些疑问，比如记录数变动过大，KPI效验无法通过。 在ETL中，有两种图，一种是“控制流程图”，另外一个是“数据流程图”。 常见的ETL工具，如Datastage，Informatica都会展现“控制流程图”，并以此来进行调度。例如前者流程图中的每个节点是Job、命令行或是异常处理，而后者的节点是session、worklet等，他们的节点都是过程。而其箭头连线表示的是控制转换，过程执行的顺序，并行还是串行。一个节点指向另一个节点，意味着，当头一个节点运行结束，或者到某种状态时，执行后一个节点，这种流程图的好处是对ETL过程了如指掌。(此段为 头头脑脑 所写，我没有用过这两个东东)。 但“数据流程图”比较少见，一般在元数据中见的比较多。这种图，关注的是数据之间的依赖关系。比如一张A表，其数据的来源是哪里，又派生出来多少数据集，派生的依据是什么。由于此图清晰的描述了数据之间的关系，在数据仓库应用中有着至关重要的作用。我刚到中国移动省级项目组时，要为一级经营分析准备数据，但当时，对业务的理解非常弱，面对纷乱复杂的数据流，根本不知道从哪里下手，每次都要问一经的负责人。现在看来，如果在ETL中提供了数据流的描述，效率要高很多。后来，新到的项目总监安排了一个人专门绘制这样图，项目组获益非常大。 个人认为做为数据仓库驱动器的ETL工具，应该能够清晰的展现数据流图。目前绝大多数ETL工具的调度图都是按照抽取、转换、装载和清洗4大步骤展现，如此并没有大的错误，但没有真正理解ETL工具存在的最终目的。这些步骤只是手段，但最终目的是为了建设、维护数据仓库。因此，在ETL中至少应该看到如下的数据流图。 在ETL工具中，对数据流进行描述是不是很困难？我看未必！目前，数据流向无非4种：表→表，表→文件，文件→表，文件→文件，应该很容易定义才对。元数据其实就是干这个工作的！如果能借鉴元数据，应该不难实现。个人认为难点在于与ETL本身的调度联系起来，对调度策略会有一些特殊的要求。一个大的数据流动才定为一个job，比如从接口到表，虽然经过了转换、清洗、装载，但这个步骤都只为一个目的服务：将数据从接口装入到表，因此可以定为一个job，而不是象常见的ETL工具，定为3个job，否则就割裂了之间的联系，不便于描述数据流向。我曾看过另外一个公司的中国移动经营分析项目资料，从接口层到dw层，足有500多个任务，并以此做为宣传点。乍一看，觉得很专业，但做久了之后，觉得很不可思议，简直就是自讨苦吃，不仅割裂了数据之间的联系，也增加了维护难度，每修改一个接口都必须同时修改3处地方，苦不堪言。我以前使用的一个ETL工具也是采用类似的方法，吃尽了苦头。