MaxCompute:長期間メトリックの計算最適化

仕組み

30 個の生ログパーティションをクエリする代わりに、毎日ログを事前集計してサマリーテーブルに格納します。サマリーテーブルの各行は、その日のユニークな (item_id, visitor_id) ペアを表します。事前集計されたデータの 30 個のパーティションをクエリする方が、生ログの 30 個のパーティションをクエリするよりもはるかに安価です。これは、事前集計ステップによって、ローリングウィンドウクエリが実行される前にカーディナリティの高い重複行が削除されるためです。

ステップ 1: 日次サマリーの作成

これを、メトリックノードの前に DataWorks で日次スケジューリングノードとして実行します。

INSERT OVERWRITE TABLE mds_itm_vsr_xx (ds='${bdp.system.bizdate} ')
SELECT item_id,
       visitor_id,
       COUNT(1) AS pv
FROM (
    SELECT item_id,
           visitor_id
    FROM vistor_item_detail_log
    WHERE ds = ${bdp.system.bizdate}
    GROUP BY item_id, visitor_id
) a;

これにより、今日のデータパーティションの mds_itm_vsr_xx に、(item_id, visitor_id) ペアごとに重複排除された 1 行が書き込まれます。

ステップ 2: サマリーテーブルからのクエリ

サマリーテーブルが用意されている場合、ローリングウィンドウクエリがスキャンするデータははるかに少なくなります。

SELECT item_id,
       COUNT(DISTINCT visitor_id) AS uv,
       SUM(pv) AS pv
FROM mds_itm_vsr_xx
WHERE ds <= '${bdp.system.bizdate} '
  AND ds >= TO_CHAR(DATEADD(TO_DATE('${bdp.system.bizdate} ','yyyymmdd'),-29,'dd'),'yyyymmdd')
GROUP BY item_id;

仕組み

中間テーブルアプローチは、実行ごとに 30 個のパーティションをスキャンします。増分蓄積はさらに進んで、すべての既存データを単一の蓄積パーティションにマージし、毎日新しいデータのみを追加します。これにより、ローリングウィンドウクエリは 1 つのパーティションからのみ読み取ります。

これは、日次で変更されるデータの割合が、既存データセット全体に対して小さい場合に最も効果的です。つまり、蓄積パーティション内のほとんどのデータが実行間で安定している場合です。

実装: リピート購入者ディメンションテーブル

過去 30 日以内に購入した購入者であるリピート購入者のユースケースは良い例です。ナイーブなアプローチでは、実行ごとに課金ログの 30 個のパーティションをスキャンします。

SELECT item_id,
       buyer_id AS old_buyer_id
FROM buyer_item_detail_log
WHERE ds < ${bdp.system.bizdate}
  AND ds >= TO_CHAR(DATEADD(TO_DATE(${bdp.system.bizdate},'yyyymmdd'),-29,'dd'),'yyyymmdd')
GROUP BY item_id,
         buyer_id;

代わりに、購入者とアイテムの関係を表すディメンションテーブルを維持し、初回購入時間、最終購入時間、購入アイテムの合計、合計支出などのフィールドを記録します。これを前日の課金ログで毎日更新します。

購入者がリピート購入者であるかどうかを判断するには、その last_purchase_time が過去 30 日以内であるかどうかを確認します。これにより、課金ログの 30 パーティションスキャンが、ディメンションテーブルに対する単一パーティションルックアップに置き換えられ、実行ごとのフルスキャン重複排除が不要になります。