增量/存量數據按時間維度分組

數據統計分析常用的統計方式：

1、存量：系統在某一時間點下數據在某個條件下的總數；

例：

需求：假設房源狀態流轉為：上架->下架->上架  （形成閉環） ，按日的維度統計時間范圍內每天處於上架狀態的存量房源數量

        設計中間表（time 時間 , nums 上架房源數量）用來給用戶統計用。因為是按日分組，所以每一天都會對應有處於上架狀態的存量房源的數量。因此這里每天都會生成一行記錄，且該行的數據繼承於昨天的數據，如 2號的上架狀態的房源數據=1號上架的房源數據+2號新增上架的房源數-下架數。因此：新增上架的房源數時 數量加1，新增下架房源數時減1

 

這里選取1月1號為初始節點，這時候處於上架狀態房源總數為 10 套

時間	上架房源數量
2012-01-01	10

 

1月2號，此時新上架了 20套

時間	上架房源數量
2012-01-02	30

 

1月3號，此時新上架了 10套 下架了15套

 

時間	上架房源數量
2012-01-03	25

說明：

當按日分組統計每天處於狀態的房源總數時：select 上架房源數量  from t_housing group by 時間

　　　數據獲取

　　　　　　在第二天統計前一天處於上架狀態的房源數，如1月1號的數據則在1月2號凌晨通過定時任務，執行統計數據的sql將1月1號的數據查出來之后，再放入中間表里。每次需要統計的時候，再從中間表中執行SQL 獲得統計好的數據（類似SQL為：insert(time,nums) value(now(),select count(*) from t_housing where status = '上架')）

優點

• 該方法將統計的數量與具體的房源隔離開，不需要關心系統的房源總數，只需要一年生成365條記錄即可
• 可以兼容 按月統計、按年統計（統計最后一天）

 

缺點

 

• 如果需要同時查詢房源的其他屬性時，則一年的數據量與該屬性的總數成正比。如：同時需要增加查詢條件—小區，假設有1000個小區，那么數量級將增加1000倍（上架時某房源時，需要找到房源所在的小區的行，再把該房源數量加1）
  
  如：

  時間	小區名稱	上架房源數量
  2012-01-03	小區A	5
  2012-01-03	小區B	7
  2012-01-03	.....	9
  2012-01-03	小區Z	10

  
  
  

• 擴展性不好，如果需要臨時增加查詢條件，無法兼容之前的數據
• 閉環的狀態增加了對同一行數據的寫（如：房源中的上架與下架，下架時，需要將數量減 1）

 

2、流量：是指在某一段時間內流入/出系統的數量

3、增量：則是指在某一段時間內系統中增加的數量

4、增量=流入量 - 流出量

5、本期期末存量=上期期末存量+本期內增量

6、拉鏈表：記錄數據變化的完整狀態

例：

假設訂單狀態流轉為   創建訂單→支付完成→已出庫

 

6月20號有3條記錄：

訂單創建日期	訂單編號	訂單狀態
2012-06-20	001	創建訂單
2012-06-20	002	創建訂單
2012-06-20	003	支付完成

到6月21日，表中有5條記錄：

訂單創建日期	訂單編號	訂單狀態
2012-06-20	001	支付完成（從創建到支付）
2012-06-20	002	創建訂單
2012-06-20	003	支付完成
2012-06-21	004	創建訂單
2012-06-21	005	創建訂單

 

到6月22日，表中有6條記錄：

 

訂單創建日期	訂單編號	訂單狀態
2012-06-20	001	支付完成（從創建到支付）
2012-06-20	002	創建訂單
2012-06-20	003	已發貨（從支付到發貨）
2012-06-21	004	創建訂單
2012-06-21	005	支付完成（從創建到支付）
2012-06-22	006	創建訂單

 

數據倉庫中對該表的保留方法：

 

1. 只保留一份全量，則數據和6月22日的記錄一樣，如果需要查看6月21日訂單001的狀態，則無法滿足；
2. 每天都保留一份全量，則數據倉庫中的該表共有14條記錄，但好多記錄都是重復保存，沒有任務變化，如訂單002,004，數據量大了，會造成很大的存儲浪費；

 

如果在數據倉庫中設計成歷史拉鏈表保存該表，則會有下面這樣一張表：

訂單創建日期	訂單編號	訂單狀態	dw_begin_date	dw_end_date
2012-06-20	001	創建訂單	2012-06-20	2012-06-20
2012-06-20	001	支付完成	2012-06-21	9999-12-31
2012-06-20	002	創建訂單	2012-06-20	9999-12-31
2012-06-20	003	支付完成	2012-06-20	2012-06-21
2012-06-20	003	已發貨	2012-06-22	9999-12-31
2012-06-21	004	創建訂單	2012-06-21	9999-12-31
2012-06-21	005	創建訂單	2012-06-21	2012-06-21
2012-06-21	005	支付完成	2012-06-22	9999-12-31
2012-06-22	006	創建訂單	2012-06-22	9999-12-3

說明：

1. dw_begin_date表示該條記錄的生命周期開始時間，dw_end_date表示該條記錄的生命周期結束時間；
2. dw_end_date = ‘9999-12-31’表示該條記錄目前處於有效狀態；
3. 如果查詢當前所有有效的記錄，則select * from order_his where dw_end_date = ‘9999-12-31′
4. 如果查詢2012-06-21的歷史快照，則select * from order_his where dw_begin_date <= ‘2012-06-21′ and end_date >= ‘2012-06-21’，這條語句會查詢到以下記錄：

訂單創建日期	訂單編號	訂單狀態	dw_begin_date	dw_end_date
2012-06-20	001	支付完成	2012-06-21	9999-12-31
2012-06-20	002	創建訂單	2012-06-20	9999-12-31
2012-06-20	003	支付完成	2012-06-20	2012-06-21
2012-06-21	004	創建訂單	2012-06-21	9999-12-31
2012-06-21	005	創建訂單	2012-06-21	2012-06-21

缺點：不支持按時間進行分組，分別統計每個時間點的存量數據總和