管理事务数据库和分析数据库之间的模式更改

Question

您将如何管理影响分析数据库的事务性数据库中的更改？

环境：

• 事务数据库是当前或接近当前版本的 MySQL。事务数据库的大小似乎在几 TB 左右，但数据库每天的增长只有几百兆。
• 分析数据库是当前或接近当前版本的蒙德里安

场景：给定一个自动从事务数据库加载数据的分析数据库——当模式更改导致大段数据在数据库事务数据库中重新定位时，也会导致分析数据库发生变化。给我的唯一例子是数据库中事务数据库模式的一小部分发生了变化，据我所知大约有 300 个表；这意味着我猜想通过添加/删除/移动列/表/行，5-10% 的事务数据库模式会以某种方式发生变化，并且在某些情况下，数据的格式会发生全局变化事务数据库。

_{这个问题的相关元问题。}

Answer 1

您将无法自动执行此过程。基础系统的任何发布都需要包括影响分析和对分析系统的更改，这将是一个手动过程。您将不得不更新 ETL 过程以从新结构中获取数据，并且可能还需要修改数据集市。

这会增加发布过程的延迟，而且我已经看到很多情况下忽略了这一点并且分析系统崩溃了。事务系统的企业或所有者必须执行以下三件事之一：

1. 将对分析系统和 ETL 流程的影响分析纳入其对运营系统的变更控制。

2. 承认发布有时会破坏分析系统，可能以不明显的方式（数据的未识别语义更改）。对分析系统的修复可能会或可能不会很快实施。他们有可能做一些需要数天或数周才能在分析中修复的事情。

3. 构建系统将数据导出到的稳定接口层，并重构数据集市 ETL 以通过该接口填充。

除非企业不能容忍延迟发布，否则选项 1 几乎总是更可取。.com 类型的企业可能就是这种情况，其中快速发布时间表很重要。

如果对发布的影响是不可接受的，那么企业必须要么实施 (3) 要么签署他们对 (2) 感到满意，并对因破坏分析系统的更改造成的任何停机时间承担责任。

选项 3 将使分析系统的更改陷入困境，因为它们可能变得依赖于界面的更改，因此需要发布具有更改的操作系统以填充更新的界面。

如果企业坚持坚持 (1)，那么让他们签署一些承担分析计划外停机责任的事情。如果您没有书面记录表明您已向他们提出此问题，那么您就有可能因无法控制的事情承担责任。