我們前面聊過OLTP 到OLAP ，也講了資料流的設計，但在實際上運作的時候遇到了一個問題，讓我們有點頭痛，也就是系統資料表並沒有留存所有變更的紀錄，OLTP 的設計目的是為了讓系統功能的運作順暢，並不是針對分析的需求，所以很多時候有留存變化的資料，是幸運撿到而非必要，那我們要怎麼處理這個問題呢？
在進入解決方案討論前，我們先簡單聊聊有什麼原因需要去追蹤資料變化吧！
在我們一開始推動資料決策，最常被追殺的就是業務KPI 相關的指標，像是訂閱中的人數，因為系統功能也持續迭代，導致數據產出的規則會有些變化，有時候會遇到今天訂閱中的人數 不等於 昨天訂閱中人數+昨天新訂閱人數-昨天退訂人數，就被業務追殺，你在追蹤一些原因的時候，會需要某些相關的紀錄去追查。
有些時候是用戶對於自己使用資料的疑問，可能因為網路問題、認知不同而有疑慮，打到客服來詢問，客服就會請RD提供一些使用紀錄，來協助回應用戶問題。
當你的組織使用數據到一定的程度後，大家會好奇更多的事情，例如：我們想知道這個學生在每個年級的班級，以及他曾經收到的任務，我們可以追到任務資料，但是班級內有哪些學生可能只紀錄了當下，所以如果他退出了班級，或是老師使用會一直用同一個班級，每個學年把舊生移除，加入新生，就會影響到我們的分析需求。
如果你需要的資料，變更的頻率不高，定時做快照是一個最簡單的做法，你可以提高快照的頻率，從每週的快照增加到每天做快照，從每天的快照增加到每小時做快照。
確認你要追蹤的資料後，就可以直接從分析端的 ELT 排程安排想紀錄的變化以及頻率。
這個做法會遇到一個問題：如果中間有一些小的變化，你就會有機率的遺失資料，而無力回天。
方案一的做法是從分析端的角度切入處理，但就是有可能遺漏資料，那針對這個問題，是不是能回到更上游，請RD做紀錄呢？當然可以！請後端工程師在資料庫上面做調整紀錄，是一個解決方案沒錯。
對於你想追蹤的資料變化，不會再遺漏。
這樣的做法非常『客製化』，只能針對你特別要求的情境去追蹤變化，而有經驗的你也知道業務的變化很快速，可能你今天請工程師增加了『定價』的追蹤，下次行銷就跑來說要追蹤『折扣』的變化，最後 ＯLTP 的資料表混雜了不同的目的，混亂而難以管理。
當時遇到這問題時諮詢過一些前輩，某些前輩提供了這個方向，就是從 RD API 被呼叫的紀錄去清理出自己想要追蹤的資料變化。
RD 不需要額外做什麼事，也能盡可能追蹤所有系統上發生過的事件
和方案一類似的做法，除了請RD 額外用程式處理外，可以在 OLTP 裡面加上 Trigger ，在資料變更的時候觸發，把變更記錄下來，但我並不太推薦這做法。
不用額外請RD做，可以開一個Read Replica，不影響系統的前提下，讓分析師在上面自行設置很多 Trigger。
Trigger 一開始用起來很開心，數量持續增加後會很難追蹤管理。
透過第三方工具去解析OLTP的交易日誌，像是 MySQL 的 binlog，可以 realtime 紀錄資料庫的變化紀錄，持續匯出到 Data Lake，最後一個方案是我們最後有採用的方案。
資料的變更追蹤是一定會遇到的問題，今天分享了一些營運的做法、跨部門合作的作法，還有技術上的作法，你可以依照組織的需求去選擇現階段的作法，也許你只是在剛起步階段，不需要追蹤所有的變化，也許只是研究分析需求，可以從其他紀錄裡去逼近重現，不需要事前都把變更記錄下來，又或是你已經走到較成熟的應用，事後追溯已經無法滿足業務分析的深度和變化，那就可以考慮導入 Debezium 這樣的技術工具，讓不同的角色協作都不需要花非常大的力氣，卻能讓組織可以有效地提升分析的深度和廣度，也更靈活彈性！
iThome鐵人賽
看影片追技術