Data Pipeline Design Patterns(3) Accumulated Mirroring

保存歷史狀態

適用情境

當原始表格的狀態會隨時間改變，又需要去長期追蹤狀態的改變時可以使用這種簡易的方式。

例如我有一個記錄使用者 Tag 的表格，裡面會記錄：

• 每個使用者最近一個禮拜觀看的電影，每週更新一次。
• 每個使用者昨天看的電影，每天更新
• 每個使用者最近一次登入的地點，每次上線時更新
• 每個使用者在下個月的流失機率，每個月更新一次

之所以會那麼多相異的邏輯，在於這個表格設計上會根據不同單位在撈取使用者時的需求而定。由於這個表著重的是使用者在撈取「當下」最新的狀態，所以這個表一開始在設計上沒有記錄過去每次的變化。

在這個情況下，如果有一個模型（或某種分析方式），需要去根據過去一年使用者每天看的電影、過去每週觀看的電影、過去每天登入地點、每個月的流失機率、甚至更多特徵來做計算時，我們不可能每次需要時在去重算一次這些特徵（這樣計算量和計算費用會很可觀），這時候我們要做的事情就是把這個表的隨著時間變化的每個時間切片記錄下來。(如下圖)

Limitation

在這情境下，每個時間切片都會 Mirror 當下所有資料的狀態，時間切片之間的間隔越細（例如一小時），資料量的成長速度就會相當的可觀，如果一天存一次的話相對來說就還好。也是需要評估原始資料量的大小以及成長速度來做評估。

Prerequisite

基於上述限制，當情境落入技術規格討論時，需要確認

1. 原始 Table 的筆數和欄位數量
2. 原始 Table 每天的變化量，以預測這樣的方式能夠是用多久
3. 每天適合撈取資料的時間（通常會是過了半夜十二點後，或是來源資料庫負擔較輕的時候）
4. 撈取資料的頻次
5. 確認來源資料庫與目標資料庫使用的技術
6. 根據對應的技術來選擇存放方式，如果是 Hive 或 AWS Athena 可能就可以以日期作為 Partition 來存放。
7. 確認雙邊資料的 Schema，根據技術不同，能夠支援的 Data Type 也會不一樣。
8. 確認要保留的 time window，因為空間有限/需要錢，不可能無限制地保留所有歷史資料，所以可以訂一個需要觀察的 time window（例如兩年）作為保存。

處理流程

針對這樣的需求，Data Pipeline 流程大致如下

1. 建立 Target Table Schema 時需要另外增加記錄時間切片的欄位（例如 DT）
2. 讀取完整 Source Table 的資料，並將資料新增一欄位（呈上，例如 DT），並加入對應的時間戳記（最小單位需要與時間切片的間隔相同，如果是每天存取一次的話，這個值就是到日期）
3. 將新增欄位的資料寫入 Target Table 對應的 Partition 中
4. 比對 Source Table 和 Target Table 篩選最新的時間戳記的資料並計算比筆數（例如：Select count(1) from target_table where dt = max(dt)）
5. 根據資料的 Time Window 刪除過去的資料。