ETL程序设计的一点思考

ETL设计的一点思考

 

前些天写了篇文章叫做什么是好的代码？？这是对J2EE开发的一点思考。对于ETL开发来讲，其与常规的J2EE系统开发有所不同，在面向对象设计的方法大行其道的现在，对于操作关系型数据库还是采用过程化的思想，但也有通用的地方。

 

1、选择SQL还是ETL工具

 

ETL工具都有join group by操作，复杂sql完成的事情ETL工具很多都能完成，所以存在一个SQL处理与ETL工具处理的矛盾问题。到底是在ETL工具端处理还是数据库SQL、处理。我想从代码的可读性以及操作的简便性考虑，如果SQL不是很复杂，用SQL可以清楚表达你的逻辑，优先考虑SQL。毕竟一般跑批在晚上，充分利用数据库的性能，ETL工具承担调度的功能。

 

2、ETL系统分层设计

 

 

一般来讲都有数据源层、中间处理层、前台展示层或者说目标层。

 

对于数据源层，我不希望对于数据源表的名称在ETL过程中到处都是，一般外部系统的表只在ETL数据源层出现，其他各层不不要依赖外部系统表。尽可能地将与外界通信减少到最少。这也是符合迪米特法则的。而系统的分层也从一定程度上进行了处理过程间的相对解耦，每个层次的变化不影响或者很少影响其他层次。

 

3、粒度问题

 

中间层往往需要不止一个处理过程，那么在处理过程中如何划分呢？？我想还是要粒度合适。怎么叫合适？？每个处理不要太大，可读性好一点。第二处理过程划分为几个步骤，那么需要考虑哪些步骤对于查错是方便的，必备的，那么就需要分离这个过程，这是需要从业务上斟酌的。

 

4、日志记录问题

 

这是个基本问题，执行在哪一步，就应该记录哪一步的日志，便于查找错误

 

5、数据清洗

 

跑批过程，经常碰到跑不下去的问题。究其原因，跑不下去一定是抛出异常，是数据约束导致。是不是将数据清洗固定作为ETL过程的一个任务阶段。我们ETL系统的数据约束应该有哪些，数据的入口处应该拦截哪些数据，不符合规格的脏数据作何处理。

 

 

6、单表的数据量问题

 

数据量很大的表应该采用横切纵切的方法。那么多大的数据量应该切分了呢？？对于实时查询，即使建立索引太大的数据量也是个压力，所以应有个标准，比如上千万的量是不是考虑切分，或者构建为分区表。