This topic has been archived. It cannot be replied.
-
工作学习 / 学科技术讨论 / 转帖.<ETL的考虑> BY shwenwen.ITPUB //国内的ETL高手功力很深.
-findinghouse(不写错别字。8);
2007-10-18
{18575}
(#3999116@0)
-
还停留在应用层上，应该看一下Kimball的bible，更原理些
-sosad(ROLIA森林的故事);
2007-10-18
(#3999328@0)
-
我觉得ETL最难取舍的是如何UPDATE SLOWLY CHANGING DIM. 保留历史记录多了影响速度, 保留少了不能向REPORT或数据挖掘提供足够的信息. Kimball也只给出原理,实战还得靠个人体会.
-findinghouse(不写错别字。8);
2007-10-19
(#4001493@0)
-
这个可以讨论讨论。Slowly changing dimension慢是慢在对Record操作，而失去了批处理的优势。诸位有什么好的经验可以交流交流？
-bdbs(不多不少);
2007-10-19
(#4001655@0)
-
比较粗暴的做法, 假设每月更新,DIM里直接加TIME_KEY把它变成FACT,存到历史库里不用. 同时执行现有的逻辑更新当前的DIM,尽量不增加记录. 这样日后用户可以从历史库挖掘全部信息. 多存没坏处.
-findinghouse(不写错别字。8);
2007-10-19
(#4002408@0)
-
有没有不粗暴的方法？
-bdbs(不多不少);
2007-10-23
(#4010422@0)
-
再细腻一点我觉得应该是怎么DELETE 当前的DIM中过时的记录．DIM不能无限增长. 可这个问题又得和AGGREGATION联合起来考虑. 理论上只AGG FACT, KEEP DIM会对查询提供最大灵活性,可把DIM的某些列混入AGG FACT中性能会更好. 但RE_AGG的需求会增加.每个环节都要考虑, ETL DEVELOPER难呀. 你老兄有何见解随便说.
-findinghouse(不写错别字。8);
2007-10-24
{58}
(#4013063@0)
-
俺也只有粗暴的方法，没啥见解。：（
-bdbs(不多不少);
2007-10-26
(#4018164@0)