时间：2021-07-01 10:21:17 帮助过：27人阅读
Forecast这一节我们专门拉出来看。本文考察了以下几个model：
作者在实验中发现：
综合上述结果，作者提出了一个HYBRID模型，自动根据不同情况决定采用上面哪种model。针对尖峰这个feature我们可以这样设计：如果KR预测出的结果（its predicted workload volume）比ENSEMBLE的结果大K%（K是一个threshold，这里定为150%），就使用KR的结果，否则使用ENSEMBLE的结果。
接下来还有些细节需要考虑。比如Prediction Horizons（要预测多长时间内的workload，相当于Regression图上x坐标的范围）和Prediction Intervals（模型的直接输出结果是预测多长时间内的Query数量，相当于x坐标上每个点的单位）。这里作者把interval设为一分钟。也就是对于horizon时间段内的每一分钟，预测这一分钟内的arrival rate of queries。（还有些细节可参考6.2节）
最后是实验环节啦。对于cluster，结论是选择top5的类就可以了，后面训练的时候把这top5的cluster混合到一起作为training data，只训练一个model。我们重点关注Forecast的效果。在下面的实验中，使用过去3周的数据Train，然后实验了不同的Prediction Horizon。
对于模型的选择，理论上说应该是不能选择对超参数过于敏感的模型，这是因为fne-tuning a model’s hyperparameters is by itself a hard optimization task。而在实验中也证实了这一点（Fig7，但这里好像没有说实验的Prediction interval.....好在后面还会专门讨论这个）：
另外作者还选择了如下几个模型做对比：
对于有尖峰的workload pattern，这里使用1 hour的interval，用full workload history来训练，然后试图预测出一周后的workload是否会出现尖峰。在这种情况下，只有KR顺利预测出了尖峰（Fig9）。这是因为its prediction is based on the distance between the test points and training data, where the in?uence of each training data point decreases exponentially with its distance from the test point。
对于Prediction Horizon的选择，在BusTracker的数据上测试发现还是Prediction Horizon比较短的时候效果好...比如1 hour的时候就比1 week好（Fig8）
对于Prediction Interval的选择，interval越短的效果会越好（shorter intervals provide more training samples and better information for learning），但interval太小了也会导致noise多，模型更复杂，训练也更久，因此这也是个tradeoff。最终实验发现总的来说1 hour的interval比较好。（一个future work就是自动设置interval）
Link：
https://zhuanlan.zhihu.com/p/37182849
https://github.com/pentium3/QueryBot5000
这篇paper介绍了如何分析实际场景中的workload，以三种典型的workload（UDB，ZippyDB，UP2X）为例。
之前我们用ycsb等工具做过benchmark，但它只能支持有限的几种key-value分布[ YCSB-generated workloads ignore key space localities. In YCSB, hot KV-pairs are either randomly allocated across the whole key-space or clustered together. This results in an I/O mismatch between accessed data blocks in storage and the data blocks associated with KV queries. ]，很难准确的模拟实际情况。而本文的工作是将线上的实际数据进行trace，然后replay并且analyze。在分析的过程中，我们重点关注热点数据落在哪些kv区间[ The whole key space is partitioned into small key-ranges, and we model the hotness of these small key-ranges. ]，试图发现其中和业务场景相关的一些pattern，然后在设计benchmark时，queries are assigned to key-ranges based on the distribution of key-range hotness, and hot keys are allocated closely in each key-range.
Trace和Replay都是比较工程化的东西...也不太是本文的重点。第三章介绍了这一过程中需要记录的一些metrics。
接下来都是analyze出来的一些东西：
在analyze之后，作者探索了是否能用benchmark工具来模拟出尽可能和现实情况像的workload。
....
...
...
...
...
...
....
Paper Reading_Database and Storage System
标签：data with 上层 abs task hyper 总数 using OLE