今天继续考虑训练数据。
泛化性的主要难点是如何找到一个通用的变量来作为内存预测行为的单位，这个变量确实应该只和SQL以及数据分布相关，但是这个值实际采集和转化比较复杂:
首先，内存调度肯定是一个归一化后的比值才能保证跨数据库的泛化性，但这个比值，与数据库物理大小和内存池总大小都有关系。比如我们假设一个schema和数据分布完全相同的，但是大小是1GB和10GB的数据库，他们分别在500MB和1500MB的内存预算下调度。
所以，这里要找的通用变量应该要考虑到要排除数据库物理大小和内存池总大小。
- 内存池总大小/数据库物理大小比例作为一个与模型预测值无关的系数。
- 数据库中不同表的列，和不同值类型的列的大小会不一样，列相互之间的大小比例，以及不同类型的值的列，也作为比例系数。
模型预测的应该是直接根据数据库分布和sql得到的一个归一化值作为输出，这个输出乘上前面的几个系数最终作为调度的比值大小，实际执行的内存调度执行量根据最后的调度比值乘以数据库总物理大小得出。
但…好像还不够。
从workload到预测出的比值，这个端到端过程并不是纯线性的转化，而是要考虑算子级别的行为。之前的工作是只针对特定算子（大内存开销），以及算子相关的数据分布进行编码，而不是给模型输入SQL。
到这里，考虑的仍然不算全面。因为TP是高度并发的，现在对互相影响的考虑可能还有欠缺。
训练数据
综合上面的讨论，训练数据需要：
- 在线的：
- 一批workload总的内存开销。
- 各个算子的内存开销？
- 离线的：
- 原始SQL。
- SQL中提取出来的大内存算子特征，这里最好是按直方图形式提取来保证输入维度固定。
- 各个大内存算子对应的数据特征，这里必须根据SQL中的参数检索到对应的数据库中的数据分布位置，这里也可以叫做估计基数。
- 当前数据库的物理大小/列的相互比例/列的值类型等。
- 总的内存池大小。