基于元数据的ETL系统

 从努力到选择
 从实现到设计
从部分到整体
以下是我对DW design的一些想法
下次使用C#来实现一下
 
ETL中Source 的信息 
     数据提供形式:DB(ORACLE SQLSERVER VERTICA ...) FLAT FILE (EXCEL , CSV, TXT...)
     源系统 db:host port databasename  flat file:  share folder path
     数据更新周期:dayly weekly monthly
     数据提供形式:full data .delta data
     提供数据的业务含义描述:
     主要是事实表还是维度表来源:
 
ETL中数据的mapping信息:
     数据如何从stage表map到Dimension或Fact表的信息
     可以配置在mapping表中?
     在做ETL的时候进行获取,动态生成sql来完成数据的ETL?
     还是尽可能地根据这些信息生成包,然后再去执行包。
         
     聚合计算元数据的说明:
     这些元数据说明我们的metric是如何被计算的,
     我们可以把这些元数据应用在报表中,让看报表的业务人员理解metric是怎么计算的,
     以免对数字产生误解。
     如果有必要,可以专门设计一个页面进行说明,对我们计算的基本流程进行说明。
     要让业务人员清楚我们的计算流程没有违背他们的意愿。     
 
ETL中的job依赖关系与执行记录
     job与subjob之间的依赖关系
     job与job之间的依赖关系
     job的控制情况怎么样?
 
     JOB执行成功率怎么样?
     不同job的执行时长怎么样? 执行的时间趋势怎么样?
     (开始时间,结束时间,时长)
     (失败后如何处理?重做?发送邮件进行通知?)
   
ETL中的数据和使用情况的audit:
     加载过来的源数据有多少条?
     加载到DW听数据有多少条?
     数据from source to target, how about the data record count every load?
     and the data volume trend?
    每次执行事实表或维度表大概多大的数据量?以及数据量的变化趋势怎么样?
    有没有需要以报表的形式呈现出来?
    
    有没有机制来监控我们提供的入口或报表被用户访问的情况?
     (让我们知道我们做的东西是否被使用,使用情况怎么样?)
    描述:哪些用户在什么时候访问我们的报表,访问频率是怎么样的?
     哪些报表是他们最在意的?
 
ETL中data quality 相关的操作:
     确定一些检查规则,检查源数据。
     这只是关于源数据的检查,
 
    检查源数据,是否违反了我们后续操作的一些基本假设,
     示例:
     检查 否则字段是否为空(不能为空的字段)
     检查 某些日期字段的情况(startdate<enddate)
     检查数据是否duplicate
     检查使用的业务主键是否重复
 
     基于业务和TestCase的检查:
     关于业务相关的对于dimention和fact表关系的检查的一些testcases,可以一直运行,
     以保持数据库数据的一致性检查?
     就像QA人员写的test cases,写一个系统可以让其一直按配置的周期执行,而且测试的效率也会得到提高。
    
     Data Enrichment:
     主要是数据从旧的字段的派生,derived column完成的功能,是否可以可配置化地完成,可以随时停止这种配置?
     数据从字段中抽取
     数据的内容进行标准化
 
   
 业务数据源的元数据、数据仓库的元数据、抽取任务的元数据、转换规则的元数据、数据库操作元数据、异常元数据、ETL任务调度的元数据等 
   
     
   实时ETL:在线实时处理 简单的交易型数据 转换比较少 速度是成功的主要因素
   批量ETL:在点上批量处理 转换比较多 适合复杂的用时长的ETL
 
1.如何处理相同数据的多个来源?
2.如何确定数据的默认值?
上一篇:h5的video标签


下一篇:树形dp--hdu 3534 Tree