背景：前日在出數據需求文檔時，錯將不可上卷彙總的需求提成了最細粒度化的需求，導致數據無法上卷，因此無法展現的事情，現將此情況進行review，以幫助自己的成長。
review：有些數據是無法用最細粒度的數據上卷得到的，比如除數數據：可發週轉天數(可發庫存/日銷)，對於小倉來說就是sum(小倉的可發天數)/sum(小倉的日銷)，對於項目組來說就是sum(項目組的可發天數)/sum(項目組的可發天數)，其中項目組可由小倉進行彙總，但是除數之間分開是不可相加的，之前出的取數邏輯是最小化到最細粒度，因此上卷數據會有問題。
反思結果：業務出數時給出各種維度的組合場景及所有指標
mysql和kylin需求設計時都保持此法，取數邏輯也不可公用
2.具體需求
日期統一爲“yyyy-MM-dd”數據
2.1 總數據
說明：所有大倉彙總後的總數據
場景一：
- 維度：
- 日期
- 指標：
- 可發庫存
- 可發庫存金額
- 在途庫存數量
- 在途庫存金額
- 總庫存數量(可發+在途)
- 總庫存金額(可發+在途)
- 滯銷庫存數量
- 滯銷金額
場景二：
- 維度：
- 日期
- SKU(spec_no、spec_name)
- 指標
- 可發庫存
- 可發庫存金額
- 在途庫存數量
- 在途庫存金額
- 總庫存數量(可發+在途)
- 總庫存金額(可發+在途)
- 滯銷庫存數量
- 滯銷金額
2.2 大倉數據
場景一：
- 維度：
- 日期
- 大倉(大倉id、大倉name)
場景二：
- 維度：
- 日期
- SKU(spec_no、spec_name)
- 大倉(大倉id、大倉name)
2.3項目組數據
場景一：
- 維度：
- 日期
- 項目組
- 指標
- 可發庫存
- 可發庫存金額
- 在途庫存
- 在途庫存金額
- 庫存數量(可發+在途)
- 庫存金額(可發+在途)
場景二：
- 維度：
- 日期
- SKU(spec_no、spec_name)
- 項目組
- 指標
- 可發庫存
- 可發庫存金額
- 在途庫存
- 在途庫存金額
- 庫存數量(可發+在途)
- 庫存金額(可發+在途)
- 可發週轉天數(可發庫存/日銷)
- 週轉天數((可發+在途庫存)/日銷)
- 日銷(7天銷量/7*0.6+14天銷量/14*0.4)
- 7日銷量
- 14日銷量
- 庫存預警（是否滯銷品）
- 若可發週轉天數>90——滯銷品
- 若可發週轉天數>45&若可發週轉天數<=90——高庫存
- 若可發週轉天數<=45&可發週轉天數>14——正常庫存
- 若可發週轉天數<=14——低庫存
- 預警等級
- 若(可發週轉天數<=3) | (可發週轉天數>90)——Ⅰ級
- 若(可發週轉天數<=7&可發週轉天數>3) | 可發週轉天數>60&可發週轉天數<=90——Ⅱ級
- 若(可發週轉天數<=14&可發週轉天數>7) | (可發週轉天數>45&可發週轉天數<=60) ——Ⅲ級
- 高庫存解決方案 總過濾條件：若滯銷品&Ⅰ級
- 若滯銷品&Ⅰ級&可發庫存<=1000——藍色預警，組內自行處理高庫存
- 若滯銷品&Ⅰ級&可發庫存<=50000&可發庫存>1000——黃色預警，綜合運維部跟進項目組處理高庫存
- 若滯銷品&Ⅰ級&可發庫存<=100000&可發庫存>50000——橙色預警，項目組提報處理計劃，綜合運維部監控處理
- 若滯銷品&Ⅰ級&可發庫存>100000——紅色預警，項目組提報處理計劃，綜合運維部重點監控處理進度
- 低庫存解決方案 總過濾條件：低庫存&Ⅰ級，大倉的可發週轉天數是指：總數據場景二種的可發數量——即該sku所有的可發庫存數量/sum(該產品的日銷)
- 大倉可發週轉天數>120——全倉貨品充裕，關注調撥
- (大倉可發週轉天數<120&大倉可發週轉天數>45)&項目組在途庫存>0——全倉貨品充足，關注調撥；本組有在途，關注催到貨
- (大倉可發週轉天數<120&大倉可發週轉天數>45)&項目組在途庫存<=0——全倉貨品充足，關注調撥；本組無在途，關注補訂單
- (大倉可發週轉天數<45&大倉可發週轉天數>14)&項目組在途庫存>0——全倉貨品不足，關注調撥；本組有在途，關注催到貨
- (大倉可發週轉天數<45&大倉可發週轉天數>14)&項目組在途庫存<=0——全倉貨品不足，關注調撥；本組無在途，關注補訂單"
- 大倉可發週轉天數<14&項目組在途庫存>0——全倉貨品短缺，不可調撥；本組有在途，緊急催到貨
- 大倉可發週轉天數<14&項目組在途庫存<=0——全倉貨品短缺，不可調撥；本組無在途，緊急補訂單
3.數據結構設計
數據中有可上卷數據，有不可上卷數據，有兩種數據結構設計模式：
第一種：將所有可上卷數據進行最細粒度的設計，其他單拎出來。
第二種：單獨每個環節出一個數據(數據複用性不好，代碼重複)。
綜合來看使用第一種數據結構設計方式：
將公共的字段(可累加的數據)細粒化
- 維度
- 日期
- SKU(spec_no、spec_name)
- 大倉(大倉id、大倉name)
- 項目組
- 指標
- 可發庫存
- 可發庫存金額
- 在途庫存
- 在途庫存金額
- 庫存數量(可發+在途)
- 庫存金額(可發+在途)
下面兩個指標在出數的時候動態彙總(前端彙總)
- 可發週轉天數(可發庫存/日銷)
- 週轉天數((可發+在途庫存)/日銷)
不可累加的分開設計：
- 維度：
- 日期
- SKU(spec_no、spec_name)
- 項目組
- 指標
- 可發庫存
- 可發庫存金額
- 在途庫存
- 在途庫存金額
- 庫存數量(可發+在途)
- 庫存金額(可發+在途)
- 可發週轉天數(可發庫存/日銷)
- 週轉天數((可發+在途庫存)/日銷)
- 日銷(7天銷量/7*0.6+14天銷量/14*0.4)
- 7日銷量
- 14日銷量
- 庫存預警（是否滯銷品）——使用1、2、3、4進行狀態代替即可
- 若可發週轉天數>90——滯銷品
- 若可發週轉天數>45&若可發週轉天數<=90——高庫存
- 若可發週轉天數<=45&可發週轉天數>14——正常庫存
- 若可發週轉天數<=14——低庫存
- 預警等級——使用1、2、3、4進行狀態代替即可
- 若(可發週轉天數<=3) | (可發週轉天數>90)——Ⅰ級
- 若(可發週轉天數<=7&可發週轉天數>3) | 可發週轉天數>60&可發週轉天數<=90——Ⅱ級
- 若(可發週轉天數<=14&可發週轉天數>7) | (可發週轉天數>45&可發週轉天數<=60) ——Ⅲ級
- 高庫存解決方案——使用1、2、3、4進行狀態代替即可，總過濾條件：若滯銷品&Ⅰ級
- 若滯銷品&Ⅰ級&可發庫存<=1000——藍色預警，組內自行處理高庫存
- 若滯銷品&Ⅰ級&可發庫存<=50000&可發庫存>1000——黃色預警，綜合運維部跟進項目組處理高庫存
- 若滯銷品&Ⅰ級&可發庫存<=100000&可發庫存>50000——橙色預警，項目組提報處理計劃，綜合運維部監控處理
- 若滯銷品&Ⅰ級&可發庫存>100000——紅色預警，項目組提報處理計劃，綜合運維部重點監控處理進度
- 低庫存解決方案——使用1、2、3、4進行狀態代替即可，總過濾條件：低庫存&Ⅰ級，總可發週轉天數是指：即該sku所有的可發庫存數量/sum(該產品的日銷)
- 總可發週轉天數>120——全倉貨品充裕，關注調撥
- (總可發週轉天數<120&大倉可發週轉天數>45)&項目組在途庫存>0——全倉貨品充足，關注調撥；本組有在途，關注催到貨
- (總可發週轉天數<120&大倉可發週轉天數>45)&項目組在途庫存<=0——全倉貨品充足，關注調撥；本組無在途，關注補訂單
- (總可發週轉天數<45&大倉可發週轉天數>14)&項目組在途庫存>0——全倉貨品不足，關注調撥；本組有在途，關注催到貨
- (總可發週轉天數<45&大倉可發週轉天數>14)&項目組在途庫存<=0——全倉貨品不足，關注調撥；本組無在途，關注補訂單"
- 總可發週轉天數<14&項目組在途庫存>0——全倉貨品短缺，不可調撥；本組有在途，緊急催到貨
- 總可發週轉天數<14&項目組在途庫存<=0——全倉貨品短缺，不可調撥；本組無在途，緊急補訂單