SQL/SSIS DataWareHouse事实表加载,最佳实践？
8 sql sql-server lookup ssis data-warehouse
我正在SQL 2008/SSIS中构建我的第一个数据仓库,我正在寻找有关加载事实表的一些最佳实践.
目前在我的DW中,我有大约20个尺寸(办公室,员工,产品,客户等)属于1型SCD.在我的dw结构中,我已经应用了一些东西:
- No Nulls(在分段期间替换为空白表示文本或0表示数字)
- 每个维度中填充的未知密钥成员(SK ID 0)
- UPSERT用于SCD类型1从阶段到生产表的装载
- 选择DISTINCT以加载尺寸
在我的事实加载SSIS项目中,我用于加载维度的当前方法是对每个DIM进行多次查找(20+),然后用数据填充FACT表.
对于我的查找,我设置:
- 完全缓存
- 忽略"无匹配条目"的失败
- 每个SK使用"ISNULL(surrogate_idkey)？0:surrogate_idkey"派生转换,这样如果查找失败,它们将默认为SK ID 0(未知成员).
- 我的一些维度查找具有多个业务键
这是最好的方法吗？附上图片以帮助我上面的描述.
看起来很好.如果你开始遇到性能问题,有一些选择,但如果这是稳定的(在数据加载时间窗口内完成,源系统没有耗尽资源等),那么我认为没有理由改变.
一些潜在的问题需要关注......
- 如果你的尺寸增加,那么有20多个全缓存查找转换可能会造成问题...由于SSIS系统的内存限制......但由于它们是类型1,我不担心.
- 全高速缓存查找"水合"预执行...有20多个它们可能会减慢你的速度
一个常见的替代方法(上面提到的)是从源系统中提取事实表数据,并在通过单个SQL语句执行维度键查找之前将其置于暂存区域中.有些人甚至在临时区域中保留了一组维度键映射表,专门用于此目的.这减少了源系统上的锁定/阻塞...如果每次加载都有大量数据,并且在将数据输出并通过这20多个查找转换运行时必须阻止源系统.
当您拥有大量数据,大尺寸,复杂的键映射(通常由于多个源系统)和短的数据加载时间窗口时,具有良好的临时区域策略变得更加重要.