長週期指標的計算優化方案

在電子商務公司（如**），對使用者的資料分析的角度和思路可謂是應有盡有、層出不窮。所以在電商資料倉儲和商業分析場景裡，經常需要計算最近n天訪客數、最近n天的購買使用者數、老客數等等類似的指標。這些指標有乙個共同點：都需要根據使用者在電商平台上（或網上店鋪）一段時間積累的資料進行計算（這裡討論的前提是資料都儲存在maxcompute上）。

一般情況下，這些指標的計算方式就是從日誌明細表中計算就行了，如下**計算商品的最近30天訪客數：

select   item_id         --商品id    
,count(distinct visitor_id) as ipv_uv_1d_001 
from 使用者訪問商品日誌明細表 
where ds <= $ 
and ds >=to_char(dateadd(to_date($,'yyyymmdd'),-29,'dd'),'yyyymmdd') 
group by item_id

但是當每天的日誌量很大時，上面**存在乙個嚴重的問題，需要的map instance個數太多，甚至會超過99999個instance個數的限制，map task就沒有辦法順利執行，更別說後續的操作了。為什麼instance個數需要那麼多呢？原因：每天的日誌資料很大，30天的資料量更是驚人。這時候select 操作需要大量的map instance，結果查過了instance的上限，**無法執行

如何計算長週期的指標，又不影響效能？

1. 多天彙總的問題根源是資料量的問題，如果把資料量給降低了，就可以解決這個問題了。

2. 減少資料量最直接的辦法是把每天的資料量都給減少，因此需要構建臨時表，對1d的資料進行輕度彙總，這樣就能去掉很多重複資料，減少資料量。

1. 構建中間表，每天彙總一次，比如對於上面的例子，構建乙個item_id+visitor_id粒度的中間表

2. 計算多天的資料，依賴中間表進行彙總

例子如下：

step1:構建item_id+visitior_id粒度的日彙總表，記作a

insert overwrite table mds_itm_vsr_xx(ds='$ ')
select item_id,visitor_id,count(1) as pv
from
（select item_id,visitor_id
from 使用者訪問商品日誌明細表 
where ds =$ 
group by item_id,visitor_id
）a

setp2:對a進行30天彙總

select   item_id
,count(distinct visitor_id) as uv
,sum(pv) as pv
from mds_itm_vsr_xx
where ds <= '$ '
and ds >= to_char(dateadd(to_date('$ ','yyyymmdd'),-29,'dd'),'yyyymmdd')
group by item_id

上面講述的方法，對每天的訪問日誌明細資料進行單天去重，從而減少了資料量，提高了效能。缺點是每次計算多天的資料的時候，都要n個分割槽的資料，那麼能不能有一種方式，不需要讀取n個分割槽的資料，而是把n個分割槽的資料壓縮合併成乙個分割槽的資料，讓乙個分割槽的資料報含歷史資料的資訊。業務上是有類似場景的，有如下方式：

1. 增量累計方式計算長週期指標

例子：求最近1天店鋪商品的老買家數，老買家數的演算法定義為：過去一段時間有購買的買家（比如過去30天）。

一般情況下，老買家數計算方式：

select   item_id         --商品id    
,buyer_id as old_buyer_id
from 使用者購買商品明細表 
where ds < $ 
and ds >=to_char(dateadd(to_date($,'yyyymmdd'),-29,'dd'),'yyyymmdd') 
group by item_id
,buyer_id

改進思路：

1. 維護一張店鋪商品和買家購買關係的維表記作表a，記錄買家和店鋪的購買關係，以及第一次購買時間，最近一次購買時間，累計購買件數，累計購買金額等等資訊

2. 每天使用最近1天的支付明細日誌更新表a的相關資料

3. 計算老買家時，最需要判斷最近一次購買時間是否是30天之內就行了，從而做到最大程度上的資料關係對去重，減少了計算輸入資料量

長週期指標的計算優化方案

河長制方案優化

hive的優化方案

Mysql的優化方案

長週期指標的計算優化方案

河長制方案優化

hive的優化方案

Mysql的優化方案

相關推薦