Mining Precision Interface From Query Logs -- 学习笔记（三）

读完第五部分，全文的重中之重也可以说是学习完毕了。前半部分是对提出的问题的一个解决方案。接下来，作者要阐述的是针对这个问题，有没有更进一步的优化方案，使得生成精确界面的成本代价更小。优化也是问题研究中一个很重要的方面，当数据量庞大时，好的算法有时可以降低很大级别数量级的复杂度，提高性能。下面，来读一读作者关于此问题的优化方案：

先回顾一下解决问题的步骤：

（1）计算出query logs中不同成对树之间的差异

（2）使用 $PIL_{ANG}$ 语句过滤出有意义的差异

（3）将结果转换为交互图

（4）执行启发式算法导出界面

然而，这几个步骤执行的代价太过大，尤其是在成千对queries中寻找树之间的差异。下面，作者基于 3个问题的本质属性来减少这种成对的转换：（1）转换的传递性（2）存在模板（3）所有转换可能不相关的事实

6 优化

实现精确界面的过程需要4步：

（1）从 $logs$ 中找出成对AST树之间的 $diffs$ 表

（2）用 $PIL_{ANG}$ 语句来筛选 $diffs$ 表

（3）将结果转为交互图

（4）执行启发式算法导出界面

Q1： $PIL_{ANG}$ 语句的传递性

一个 $PIL_{ANG}$ 语句可传递： $s(p_{1},p_{2})\neq \o \wedge s(p_{2},p_{3})\neq \o \rightarrow s(p_{1},s_{3})\neq \o$

如果 $PIL_{ANG}$ $s$ 可传递，则它所匹配的程序集就形成一个集合。新的程序 $p$ 只需要检查和任意一个程序 $p_{c}\in C$ 匹配，就可以说明和集合中任何一个都匹配。作者针对这个传递性，提出了一个能直接在程序日志中检测 $PIL_{ANG}$ 语句构成程序集合的算法：

Data: PILANG statement: s, Programs: P
result: C
initialize C = {};
while p∈P do:matched = false;while c∈C do:  //将与C中匹配的程序p放入小集合cif( 存在C中的程序pc，使得s(p,pc)≠∅ ):c.add(p);matched = true;endendif(!mathched):C.add({p});end
end

利用启发式算法识别出所写 $PIL_{ANG}$ 语句中的传递语句：检查 $PIL_{ANG}$ 语句的 WHERE子句是否只包含传递性的逻辑表达式（e.g.，＝，≠）

事实上，交互图不实用，因为它非常密集。对一个包含 N 个查询的交互图，其中有 $O(N^{2})$ 条边。但是这个算法可以压缩交互图。它把一个边的集合压缩成一个集合的集合，降低了一个数量级的存储代价。这可以获得在主存中处理大量查询log 的能力。

（我的理解是有很多重复的边，现在要找出这些边。我们不必一个一个区匹配这些边，只需要在匹配程序集里匹配，如果有，那么和程序集里其他的程序也一定匹配。如果没有。就单独成一个程序集）

Q2：程序模板

$query\ log$ 中经常存在解析结构相同而值不同的程序集合。

例如，通过改变距离阈值或者函数参数形成的查询在任何地方都相同。把这种集合叫做 $templated$ $cliques$ . 为了检测这种 clique，作者采用了和提取模板函数一致的方法：用未命名的变量替换查询AST树中的值，散列结果，并通过散列值将它们分组。这样，就可以用一个模板和一个值的列表来表示结构相同的 AST树了。接下来就可以针对集合进行差异的寻找以及 $PIL_{ANG}$ 语句过滤了，不用再针对单个的查询了。对每个模板 clique，为到每个变量的路径建立索引，并在 $PIL_{ANG}$ 语句中用这个路径表达式进行匹配。一个匹配的 $PIL_{ANG}$ 语句可以利用这个索引快速的识别出 AST间的改变并且评估它们。

Q3：指定程序对优化界面生成

精确界面生成界面的依据是不同程序之间的差异。作者认为可以根据性能和个性化目的对这些程序对的范围做出限制。将程序日志建模为一种关系为系统选择程序对提供很大的灵活性。

7 实验

本部分是作者进行了一系列的实验。作者用 5 个 $query\ logs$ 。4个是SQL书写，1个是 SPARQL，而且这些日志是以人工可视化的方式生成的。做此实验的目的是想回答精确界面生成工具的四个相关问题：

（1）精确界面能否表示 $query\ logs$

（2）运行时是否可接受

（3）是否支持多种语言

（4）和现有的以及手工设计的界面相比，用户更喜欢哪个

解析树和界面挖掘是用Java实现，组件映射和生成使用Python实现（生成了HTML+Javasprict的界面）。定义了12种组件并且人共为SQL和 SPARQL定义了 $exec()$ 函数和 $render()$ 函数。

Q1：精确界面能否表示 $query\ logs$

作者从两个 $logs$ 展示界面生成和能表达出 $query\ logs$ 的程度（人工生成的基于实时数据库的OLAP日志）

作者做此实验的目的是希望能从OLAP查询空间中生成一个和 Tableau相似的界面，为了模仿这个探索的过程，生成器一一个分组查询开始然后在每一步随机改变子句（GROUPBY，WHERE，SELECT）。维度、过滤器以及度量都丛均匀分布随机抽样。然后慢慢的进行改变，每一步只改变一下。作者写了 7 个与生成器表达的结构变化和值变化相关的 $PIL_{ANG}$ 语句。

这幅图是生成器生成的界面。左边的两个框用户可以选择度量和维度。最下方的选择框提供了三个过滤器，每个都有一个下拉框选择列或者文本来确定一个值。这个界面可以表达日志中所有的查询。Tableau这个工具，它让用户自己拖动列到架子上来生成OLAP查询。

这个生成界面是通过修改代价函数的权重，来获得简单界面，这个界面更注重简单。作者将界面复杂性的权重设置较高，将用户使用性权重设置偏低。可以看到，用户必须通过自己手动输入来生成查询

这个界面，可以看到所有的选择都被罗列了处理。作者将权重设置反过来，界面复杂性的权重设置较低，将用户使用性权重设置较高。它忽视了视觉上的复杂性。

作者通过让12个学生用实时数据库完成三个不同的任务专门生成了一个查询日志（这些问题并不是直接的查询数据的问题，而是需要查询数据进行一些分析才能回答的问题）。作者读取了所有这个过程中执行查询语句所记录的日志。一共298个语句，有148个不同。作者写了15个 $PIL_{ANG}$ 语句。这个生成的日志比合成的日志更具变化性。

这张图显示了界面覆盖查询的覆盖率。可以看到，初始的第一个界面能覆盖大约166（55%）的查询，后面的生成的界面所包含的查询都 < 10，可以看出这个日志的交互图是个稀疏图。

这幅图对比了精确界面生成的三个界面，左边的界面是可以让用户通过选择来比较，中间的界面为始发机场和目的机场延误数据的汇总，右边的界面为每个航班都做了分析。这三个界面都没有完整覆盖整个日志，但却仅用6个交互组件就表达的主要的查询结构的变化.

Q2: 是否支持多种语言 & 运行时是否可接受

这个实验作者要测试精确界面的语言支持性和可扩展性。作者选择了两个程序日志，一个是用SQL语言书写的 SDSS（有125,603条，112,603条不同），还有一个是SRAPQL书写的British Museum‘s web collection（11,0,667条，39,933条不同）对第一方面，作者对两个由不同查询语言书写的日志进行测试。对第二方面，作者通过使用不同的优化方法测试运行时间。最后作者得出结论：界面生成的90%的时间花在了交互分析上面，因此必须优化这个地方。

作者用了两个不同语言的日志，比较了四种不同优化方式下的运行时：

（1）无优化

（2）clique优化

（3）模板树优化

（4）（2）+（3）

最后发现，同时使用两种优化比不使用优化的运行时提高了两个数量级。这使得界面能在分钟级别内处理万级级别的查询日志。

上面这幅图对精确界面生成界面的运行时间花费进行了分解，可以看到大部分的时间都花在了交互分析上面

上面的图表明对于两个日志，运行时都呈二次方增长，这是因为精确界面必须对齐和比较 $O(N^{2})$ 对程序来构造交互图。作者做了个实验发现比较的成本是恒定的，而这些成本来自大量的比较。

优化并不能减少算法 $O(N^{2})$ 的复杂度，但是它可以让系统避免比较。模板优化对比无优化已经带来了两个数量级的改进

上图是界面分析器的运行时随 $PIL_{ANG}$ 语句数量变化的所变化的图。查询语句的数量进行了删减，作者希望用少量样本来让这些算法的运行时都在一小时内。可以看到，增加 $PIL_{ANG}$ 语句的数量会线性的增加运行时间。

上图表明了应用 6.2节提取模板的方法后，两个查询日志的界面生成运行时都呈现二次方增加。

上图表明，交互分析的运行时随着模板数量的增加而线性增加。这表明模板优化成功地找出了日志中的结构。日志或者越多的模板，则交互分析运行的越快。

Q3：用户体验

作者在此实验中，引导用户原始的SDSS界面学习SDSS，来探究两个问题：

（1）生成的界面是否会减少响应时间和分析准确性

（2）生成的界面在用户体验上能否和原始的/人工定制的界面有竞争性

（一）和现有界面的比较

用户有5分钟时间来阅读针对4个任务的现有界面SDSS的说明书，然后操作界面。为了避免学习的影响，将用户随机分为两组，用不同的界面完成4个任务。然后作者记录了运行时间以及结果的准确性。

从图中可以看出，作者提出的精确界面对分析的准确性以及运行时间都有很大的改善。

（二）界面喜好

完成上面的试验后，作者收集了被测试者对着四个界面的喜好度

从图中可以看出，精确界面和右工程师绘制的界面都比原始界面更受被测试者喜欢。超过40人的被测试者，有70%选择人工界面2，但只有1个选择人工界面1，这表明人工定制的界面有很大差异。超过20%用户选择精确界面，没有人选择原始界面。这又说明精确界面可以和现有的界面进行竞争。此外，还说明在没有特定领域知识，精确界面可以通过分析日志总结交互中显著的操作，映射到交互界面。这比开发人员进行开发来的更容易。

Q4：Tableau 实验

这个实验直接将精确界面运用到Tableau生成查询日志上来测试：

（1）精确界面是否能检测到低层的交互

（2）是否能生成一个和 Tableau 相似的界面

最后得出的实验结果是这个界面能够只用4个组件就表达出 logs中所有的查询

小结

第二次读这篇文章就花了不少时间，第三第四第五部分花费的时间最长。每天读都会有新的理解，包括对单词，对句子的理解。

数据库中的操作大部分都是 Query 相关。Query的速度直接影响数据库的性能。这篇文章根据 query log ，通过不同 query 生成的 AST树之间的差异，将差异映射到界面的部件，生成定制界面，方便分析人员利用可视化界面查询数据、分析数据。

接下来说说阅读一篇论文步骤：

第一步：先看摘要，摘要其实是整篇文章中最能概括文章主题的部分，此部分可以了解到作者针对什么问题提出了什么解决方案以及该方案的效果如何。

第二步，看实验部分，可以大致了解这个问题的解决流程。

第三步，一般论文的第一部分是介绍论文研究问题的背景，可以暂且跳过。第二部分为论文的流程概述，我一般从此处开始看论文，接下来的部分则都是核心部分，需要精读。

论文最后一部分一般为总结，是对文章的总结。总结的前一部分一般是该领域问题的相关文献以及前人已经有的研究，这部分可以大致带过。