您將如何管理影響分析數據庫的事務數據庫中的更改？

環境：

• 事務數據庫是 MySQL 的目前或接近目前版本。事務數據庫的大小似乎在幾 TB 左右，但數據庫的增長每天只有幾百兆字節。
• 分析數據庫是 Mondrian 的目前或接近目前版本

**場景：**給定一個自動從事務數據庫載入數據的分析數據庫——當架構更改導致大部分數據在數據庫事務數據庫中重新定位時，也會導致分析數據庫中的更改。給我的唯一範例是事務數據庫模式的一小部分在數據庫中發生了更改，據我了解，大約有 300 個表；這意味著我猜測事務數據庫的 5-10% 的架構會通過添加/刪除/移動列/表/行以某種方式發生變化，並且在某些情況下，數據的格式會發生全域變化事務數據庫。

這個問題的相關元問題。

您將無法自動執行此過程。基本系統的任何版本都需要包括影響分析和對分析系統的更改，這將是一個手動過程。您必須更新 ETL 流程以從新結構中獲取數據，並可能還修改數據集市。

這會增加發布過程的延遲，我見過很多情況下忽略了這一點並且分析系統崩潰了。交易系統的企業或所有者必須做以下三件事之一：

1. 將對分析系統和 ETL 流程的影響分析納入其對作業系統的變更控制中。
2. 接受發布有時會破壞分析系統，可能以不明顯的方式（數據的未辨識語義更改）。對分析系統的修復可能會也可能不會很快實施。他們可能會做一些需要幾天或幾週才能在分析中修復的事情。
3. 建構系統將數據導出到的穩定介面層，並重構數據集市 ETL 以通過該介面填充。

除非企業不能容忍延遲發布，否則選項 1 幾乎總是更可取的。這可能是 .com 類型的業務，其中快速發布計劃很重要。

如果對發布的影響是不可接受的，那麼企業必須實施 (3) 或簽署他們對 (2) 滿意的聲明，並對因更改破壞分析系統而導致的任何停機負責。

選項 3 將阻礙對分析系統的更改，因為它們可能會依賴於界面的更改，因此需要發布具有更改的作業系統以填充更新的界面。

如果企業堅持堅持（1），那麼讓他們簽署一些協議，對分析的計劃外停機負責。如果您沒有書面記錄表明您已經向他們提出了這個問題，那麼您就有可能為您無法控制的事情承擔責任。

引用自：https://dba.stackexchange.com/questions/14097