从努力到选择
从实现到设计
从部分到整体
以下是我对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.如何确定数据的默认值？
