Data Pipeline Design Patterns(1) Mirroring

完全鏡像

過去大部分時間都在 Inhouse 環境處理資料管線，好處就是只要自己能夠理解問題，自己能夠解決就好。現在在乙方除了要跟客戶溝通，也需要幫助團隊成員跟能夠客戶溝通，所以開始整理過去做 Data Pipelines 比較有印象、也比較常遇到的 Case，根據之前處理的經驗整理成 Pattern 來幫助大家理解、溝通需求。

適用情境

將原始資料表一模一樣的複製到其他地方供其他應用取用。

例如後端有個存放使用者個人資料的 Table，資料科學家會需要用來 Join 一些事件資料，通常我們會避免資料科學家直接 Access 後端 Serving 的 Table，所以需要將資料搬出來。如果這個資料表沒有很大（<100萬），我們會直接採用 Mirror 的方式將整張表 Copy 到其他地方（例如 Data Warehouse）存放。

Limitation

在這情境下：

1. 因為是採用全表讀取與寫入，所以不適合太大的表。
2. 呈上，為避免造成原始資料庫負擔，更新頻次不會太即時，適用於不需要即時同步的資料。

Prerequisite

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

1. 原始 Table 的筆數
2. 原始 Table 每天的變化量，以預測這樣的方式能夠是用多久
3. 每天適合同步的時間（通常會是過了半夜十二點後，或是來源資料庫負擔較輕的時候）
4. 確認來源資料庫與目標資料庫使用的技術
5. 確認雙邊資料的 Schema，根據技術不同，能夠支援的 Data Type 也會不一樣

處理流程

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

1. 刪除 Mirrored Table （需要使用 If exist 避免冷啟動時失敗）
2. 建立 Mirrored Table Schema
3. 讀取 Source Table 的資料並將資料寫入 Mirrored Table（如果原始資料量 > 10000 筆，建議使用 mini-batch 的方式處理）
4. 比對 Source Table 和 Mirrored Table 的資料筆數