MTD与YTD的计算

1,035 views
Skip to first unread message

EricWang

unread,
Mar 6, 2006, 6:58:43 AM3/6/06
to ttnn BI 观点(282成员)
在做项目的过程中，经常能够碰到MTD(当月累计)与YTD(当年累计)的计算。
通用的做法是用前一天的MTD加上当天的增量，一般情况下这种做法没有问题。
但是如果FACT
TABLE中的记录有UPDATE操作时（比如前10天一个订单的状态是OPEN，今天更新成COMPLETE)，DATA
MART中最近10天，状态为OPEN和COMPLETE的所有的订单的MTD与YTD的量都需要重新计算。
一直找不到一个比较好的解决方法，不知道大家有没有好的方法。

innovate511

unread,
Mar 6, 2006, 8:52:48 AM3/6/06
to ttnn BI 观点(282成员)
建议根据用户周期的需求，建立对应的事实表，粒度当然和这个周期对应，比如Mon_xx_fact,
Year_xx_fact，他们的时间粒度分别就只是月和年，而其他维和指标可以和日事实表差不多。

然后分别形成各自的conform table,
供前端查询或者汇总分析（报表\Olap\dm都可）使用，就不会出现楼上的麻烦。

这种项目的思维，是典型的把一些汇总集放在一起，这样的最大缺点，就是可扩展性太小，稍微变化，就得全部重来。要知道之所以有个抽取周期，就是因为不同周期的数据变化不一样的，数据仓库虽然是历史的，但是不能超越了历史，如果一周/月/年的数据是每一天积累起来，就相当于你提前定义了数据在以后也不会变化的，然后周期到来之前，数据是变化的。这就是为什么需要不同周期要从不同周期结束的数据源抽取的道理。

EricWang

unread,
Mar 6, 2006, 10:57:13 PM3/6/06
to ttnn BI 观点(282成员)
Hi,Innovate
我没有理解你的思路，按日和月进行汇总的DATA
MART基本都会建立，但是我不知道如何解决我上面所提到的问题。
我在这里再详细说明一下：
Source System:
TransDate OrderNumber OrderStatus Amount UpdatedDate
Comments
01/01/2006 1001 OPEN 100
01/01/2006 1002 COMPLETE 200
01/02/2006 1003 OPEN 100
01/02/2006 1004 COMPLETE 200
01/01/2006 1001 COMPLETE 100 01/03/2006
在1月3号，1001的状态更新为Complete
01/02/2006 1003 COMPLETE 100 01/03/2006
在1月3号，1003的状态更新为Complete

FactTable
01/02/2006 Snapshot
TransDate OrderNumber OrderStatus Amount
01/01/2006 1001 OPEN 100
01/01/2006 1002 COMPLETE 200
01/02/2006 1003 OPEN 100
01/02/2006 1004 COMPLETE 200
01/03/2006 Snapshot

TransDate OrderNumber OrderStatus Amount

01/01/2006 1001 COMPLETE 100

01/01/2006 1002 COMPLETE 200
01/02/2006 1003 COMPLETE 100
01/02/2006 1004 COMPLETE 200

DataMart
01/02/2006 Snapshot
TransDate OrderStatus Amount MTD Amount
01/01/2006 OPEN 100 100
01/01/2006 COMPLETE 200 200
01/02/2006 OPEN 100 200
01/02/2006 COMPLETE 200 400

01/03/2006 Snapshot(这样01/01--01/03的MTD
数据都需要重新计算)
TransDate OrderStatus Amount MTD Amount
01/01/2006 COMPLETE 100 100
01/01/2006 COMPLETE 200 200
01/02/2006 COMPLETE 100 200
01/02/2006 COMPLETE 200 400

BI&DW

unread,
Mar 6, 2006, 11:11:38 PM3/6/06
to ttnn BI 观点(282成员)
这个可以保留MTD和YTD的下一个层，也就是Feed数据一段时间，至变化周期结束即可。

EricWang

unread,
Mar 6, 2006, 11:48:05 PM3/6/06
to ttnn BI 观点(282成员)

BI&DW 写道：

> 这个可以保留MTD和YTD的下一个层，也就是Feed数据一段时间，至变化周期结束即可。

你的意思是MTD和YTD不能及时提供正确的信息给客户，必须等到数据停止变化的时候才能提供准确的信息。

不知道我的理解是不是有问题。

innovate511

unread,
Mar 7, 2006, 12:14:11 AM3/7/06
to ttnn BI 观点(282成员)
这样说吧，无论MTD还是YTD，都是截止时间之后，统一设定一个时间去跑，一般根据数据量的大小，MTD跑一次可能需要好几个小时到10多小时，YTD需要1-2天时间。所以在数据源具备和客户最终要看结果的协调上一定要说好，特别是跑年数据，不是马上就能得到，需要有一个缓冲时间。

BI&DW

unread,
Mar 7, 2006, 12:15:27 AM3/7/06
to ttnn BI 观点(282成员)
不是的。
可以在数据变化后立即重新聚集处理得到MTD和YTD值，或者在分析查询前定时聚集。

BI&DW

unread,
Mar 7, 2006, 12:19:35 AM3/7/06
to ttnn BI 观点(282成员)
时间没有这么长吧！
MTD就是跑本月到当天的天数据。
YTD就是跑本日前的本年所有完整月加和MTD值即可了。
呵呵！
Message has been deleted

BI&DW

unread,
Mar 7, 2006, 12:20:49 AM3/7/06
to ttnn BI 观点(282成员)
不是的。
可以在数据变化后立即重新聚集处理得到MTD和YTD值，或者在分析查询前定时聚集。

EricWang

unread,
Mar 7, 2006, 12:22:36 AM3/7/06
to ttnn BI 观点(282成员)
基本上明白了。还是要重新刷新DataMart来更新以前的数据。
我以前有时候也采用此方法。只不过觉得不是一个比较好的解决方法。

谢谢楼上各位的建议。

innovate511

unread,
Mar 7, 2006, 12:37:24 AM3/7/06
to ttnn BI 观点(282成员)
我说的办法是最保险的办法，如果生产系统以前的数据的状态有所变动，将不能体现在你聚集的数据之中。所以既然变化后需要重新聚集，不如在截至时间之后一个周期就跑那么一次。

BI&DW

unread,
Mar 7, 2006, 12:41:50 AM3/7/06
to ttnn BI 观点(282成员)
有更好的办法，可以把MTD,YTD在Dashboard中展现处理。

BI&DW

unread,
Mar 7, 2006, 12:44:06 AM3/7/06
to ttnn BI 观点(282成员)
Innovate511，MTD和YTD两个KPI是客户每天早上上班都要看的啊。

BI&DW

unread,
Mar 7, 2006, 12:50:26 AM3/7/06
to ttnn BI 观点(282成员)
既然要计算MTD和YTD，当然源数据至少要每天更新加载一次了，这样在ETL处理时如果发现MTD和YTD的Feed数据有变化，就重新聚集计算好了。只要保留变化周期内的最详细的Feed数据就可以了，不能为了计算MTD和YTD要运算那么久的，这样的设计是不能容忍的。^_^

BI&DW

unread,
Mar 7, 2006, 12:54:56 AM3/7/06
to ttnn BI 观点(282成员)
BTW:
MTD:Month to Date
YTD:Year to Date

BI&DW

unread,
Mar 7, 2006, 12:55:32 AM3/7/06
to ttnn BI 观点(282成员)
Or
MTD:Month to Day
YTD:Year to Day

innovate511

unread,
Mar 7, 2006, 2:24:01 AM3/7/06
to ttnn BI 观点(282成员)
数据源当然要更新加载了。我的意思是从DW到DM这样的大型ETL处理，只需要一个周期做一次就行了，客户每天要看就能看到历史纪录，如果每天都在更新MTD和YTD，那就不叫MTD和YTD了。

EricWang

unread,
Mar 7, 2006, 3:30:54 AM3/7/06
to ttnn BI 观点(282成员)
BI&DW
说可以采用Dashboard来展现数据，是指用前端工具及时计算MTD和YTD吧，数据量大的情况可能会有性能问题。

还有你们提到的周期性的刷性DATAMART，但是往往这个周期不是确定的，而且可以是几个月之前的，如果刷新几个月的数据，时间也是个问题。
而且客户的希望是最好每天的mtd和ytd都是正确的，如果某些天是对的，偶尔几天是错的，那他们也不知道哪些是对的，哪些是错的，这个指标就没有意义了/

gavin...@gmail.com

unread,
Mar 20, 2006, 9:44:18 PM3/20/06
to ttnn BI 观点(306成员)
可不可以在fact表中为每个月再增加一个改变的字段，每次都把这个改变的字段的计算考虑进去？

kevinshij

unread,
Mar 27, 2006, 2:05:49 AM3/27/06
to ttnn BI 观点(316成员)
对于你这种情况,应该建立缓慢渐变维,在status发生改变时,记录历史,这样就不用担心记录变化问题.

kevinshij

unread,
Mar 27, 2006, 2:07:44 AM3/27/06
to ttnn BI 观点(316成员)
对于你这种情况,应该根据status建立缓慢渐变维.

BI4Fun

unread,
Mar 30, 2006, 10:22:05 PM3/30/06
to ttnn BI 观点(327成员)
可以考虑使用OLAP
FUNCTION来是实现,DataMart中的数据还是按照先前的规则加载就可以啊。
Reply all
Reply to author
Forward
0 new messages