数据生命周期管理的初步实现

这是学习笔记的第2013篇文章

最近几天在整理数据生命周期的一些东东，也码了几篇文章。

开始的调研只是验证了这个可行性，当然也是想的过于乐观，导致在实现的时候翻车。

就好比我要榨果汁，本来是用火龙果和香蕉，最后实现的时候用的是草莓和香蕉，看上去颜色差别不大，但是口感差别很大。

我们首先来说下生命周期能干嘛，其实对于DBA来说，最大的好处就是数据的周期管理都可以一目了然，一切都在掌握之中，言外之意就是哪些流程计划外的变更我们都可以捕捉到，而数据也是在多维的交互中才产生了更丰富的业务含义，此外可以对整个数据环境的质量和变化可以做到整体的管理，比如我们可以通过这些数据分析得到有100张表，但是很长一段时间以来的数据变化之后20张，那么剩下的80张表就需要打个问号了。 哪些数据是冷数据，哪些是热数据，哪些数据可能是已经不在维护的数据了，这些信息在没有产生连锁反应之前，是一种难以量化的状态，但是能够经过这种梳理和可视化的方式展示出来，从DBA的角度可以得到更加宏观的信息，对于数据质量的改进是一种可以看得到的改进。

而对于业务同学来说，这个模块的意义就在于可以得到一段时间以来的数据变化，我们设定一个场景，在数据流转中，源头是不需要关注目标端的数据消费情况的，那么如果上游的结构发生了变化，对于下游是很难以感知的，最直接的感知就是报错，而如果更加平滑一下，我们可以通过订阅或者指定的API来承接，让这个变化能够成为流程化的操作。

如下是一个初步的页面实现，我来简单解释一下，在这个基础上，我也整理了10多个改进的方案和建议。

左上角的图是DDL的次数，可以标识出整个实例的DDL变化情况，而接下来的那个图是一个数据的热度趋势图，比如数据库中有100张表，我们每隔30分钟抓取一个快照，如果有20张在快照抓取过程中始终出现，那么我们可以标记数据库的热度为20%。如果一个业务长期处于1%以下或者为0，我们可以基本断定是一个僵尸业务。

中间的表格是热度表的榜单，我们把热度最高的表整理出来（基于DML的变化频率），对热度打上标识，这样就可以明确的看到热度的一个整体分布了。右边的饼图需要持续调整，目前的设想是出现一个数据库画像，即把数据库的对象分布通过饼图展示出来。

对于每一条数据变化，我们都可以下钻，得到更加详细有效的信息。比如表结构信息和轨迹变化等。