标签：data with 上层 abs task hyper 总数 using OLE
最近（以及预感接下来的一年）会读很多很多的paper......不如开个帖子记录一下读paper心得
....
....
https://zhuanlan.zhihu.com/p/87030280
写到这里啦：Self-Driving Database
2333
笔记在这里：Link
后来我们借鉴OtterTune的思想，开发了AutoTiKV
Links:
https://www.cnblogs.com/pdev/p/10948322.html
https://www.cnblogs.com/pdev/p/11318880.html
在Self-driving Database这篇综述中，曾经提到过self-driving的DBMS需要能预测未来的workload情况。这篇文章就是来解决这个问题的，更具体一点说是predict the expected arrival rate of queries（也就是QPS） in the future based on historical data，并且特指是SQL Query。
其实有很多类似的工作也在试图做这个玩意儿，比如这篇是用LSTM预测应用程序的resource utilization（比如cpu usage, memory usage, balabala），但这些metric有个缺点就是比如硬件配置改变时（以及像本文的scenario下，当DBMS的底层设计改变了时），之前测的就不准啦。所以不如从上层的东西入手，预测业务的workload情况。比如能预测到双11，或者每天晚上是个访问高峰，那么就可以配合automatic knob tuning的一些工具来自动调优啦。其中本文重点关注了三种有代表性的workload pattern（见Fig1），个人感觉选的倒都挺经典的：
本文要解决这么几个难点：
根据上面的思路，本文开发了QueryBot5000（QB5000），它的pipeline如下图所示：
这三个部分的具体细节如下：
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
原文地址：https://www.cnblogs.com/pdev/p/11656171.html
