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

最新推荐文章于 2022-08-11 09:59:00 发布

名字被猪吃掉了

最新推荐文章于 2022-08-11 09:59:00 发布

阅读量376

点赞数

分类专栏：数据挖掘数据库

本文链接：https://blog.csdn.net/hhuzxx/article/details/98381046

版权

数据挖掘同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

数据库

8 篇文章 0 订阅

订阅专栏

Mining Precision Interface From Query Logs》是SIGMOD2019所接收到的papers当中的一篇。

花了大概4天时间阅读，全英文的paper读起来还是有点吃力的，不过好在大部分还是能看懂。下面写写自己的学习笔记：

摘要（Abstract）

摘要其实就能概括整个文章所要解决的问题或者提出的一种新技术：可视化交互工具让数据分析越来越有效，并且对普通大众也更加的友好。但现有的界面大部分都是针对特定任务的界面，没有针对每个用户每个任务的交互界面。作者提出了一种基于查询日志生成定制界面的一种方法。这种方法经过实验，可以改进现有界面的交互设计，并且与手工制作的界面可以媲美。

1 介绍

此部分开始引入，即提出问题的背景，介绍了一些现有的交互界面，例如用户可以通过使用Google的股票走势可视化交互界面的时间过滤器了解一段范围内的股票趋势。但相同的界面对市场分析员分析数据就不适合。总之，此段说明数据分析背景下交互界面的重要性。交互界面的有效性取决于该构成界面的程序集合（程序集合也就是可以改变查询操作的相关程序的集合）是否与用户想要表达的查询操作匹配。

设计界面有两个传统上由专家解决的挑战：一是确定与给定任务相关的程序集，二是开发能表达该任务的交互界面。作者举例Tableau可视化数据分析工具，软件开发者花费大力气开发的工具却不是对每种任务都有效。接着引出作者在此方面的尝试：提出用query logs作为生成交互界面的API，因为很多数据处理系统可以自动捕获logs。然后作者又举了两个关于用从logs生成界面的实例。

基于上面所述，作者提出本文主题：精确界面，即一种可以从query logs自动生成对确定任务的交互界面的工具，它以logs作为输入，生成一组web交互应用程序来表达logs中的查询。它通过把queries转换成语法树，利用树的结构的变化，把相同的变化映射成界面中的组件。

要开发这样的精确界面工具，作者提出了三个挑战：

（1）要为queries和interfaces建立统一的数学模型，这种模型的适用范围要广，支持用户首选项，并且操作性要好

（2）要找到一种可以识别和过滤出有意义的树结构改变的方法，因为并不是所有的结构变化都是有意义的，若把所有结构变化都映射到交互界面会导致界面不可用。

（3）要定义约束和启发式规则来快速找到good solution和缩小 size of logs，因为对query logs中的查询可以生成交互界面的解空间是以指数级增长的。

针对上面的三个挑战，作者提出如下解决方案：

（1）将问题形式化，问题定义对任何语法定义良好的语言和交互组件都是通用的。

（2）提出一种叫做PILANG的语言来确定重要的结构变化。这可以帮助生成交互图。交互图中每个顶点都是一个query，每条标记的边都是用PILANG语句标识的结构变化。

（3）把界面构建问题映射成交互图的边的生成问题，用启发式算法快速解决问题

（4）最后对该工具进行评估，该生成工具表现优秀

2 概述

本部分概述精确界面的建立过程以及在后序过程过程中要设法解决的技术挑战。

选用query logs作为API的原因：因为logs详细的记录了分析人员实际执行的分析操作（也就是分析时用到的查询操作），并且logs能从很多源头获得。而且现代数据处理引擎已经应用这种 log 机制来进行恢复和调试，这种方式在现代工业和研究中也非常普遍。

作者把生成界面问题分解完成两个子任务：

（1）找到不同查询语句形成的语法树之间的结构变化

（2）把这些变化映射到界面中去

解决这个问题很困难，原因有：用户交互可能表达的范围不受限（不同用户使用不同的查询语句，千差万别），很容易导致不可用的界面。针对问题，作者提出解决方案：

① 限制语法树结构变化的复杂性，提供简单的机制来指定有意义的结构变化

② 系统要很容易适应新的编程语言和新的交互组件（例如变成了触屏）

基于上面这些内容，作者把精确界面生成过程分为三个步骤：

（1）Representation Canonicalizer：把查询语句序列转换成规范化的语法树（AST）结构

（2）Interaction Miner & Distiler：基于有序树匹配算法识别 AST之间的结构变化，然后形成交互图，使用PILANG来简化图，指定重要的结构改变。

（3）Interaction Mapper：把交互图中的边的集合映射到界面中的交互组件。因为问题是NP困难，采用启发式算法找最优解，然后将生成的界面组合成一个 web交互应用程序。

作者进行了一些假设：

（1）假设知道每种语言的语法，有可以将程序源代码变成 AST的分析器，有将 AST 解析为源代码的解析器，以及可以知道哪些结点是集合哪些是文本的结点类型注释

（2）核心假设：假设query logs中大多数语法变化是增量的，因此可将查询结构变化映射到交互界面的组件

（3）不存在逻辑依赖

（4）最后，设定两个函数exec（）和render（）；exec（）函数执行生成查询AST，render（）函数将SQL查询日志可视化输出

3 对交互进行建模

本部分描述query logs和交互的形式化模型，其要点是把交互（不同的查询语句）建模成树型的转换，因为这可以把结构差异和用户操作界面的组件直接联系起来。AST - > weidget。下面进行建模：

（1）输入部分：query logs plog被建模为：

为了支持多种编程语言，依赖语言的语法和解析结构，不依赖语义

（2）将一个 $\small query\ p$ 通过分析器（ $\small p\rightarrow AST$ ）抽象成语法树AST，假设树中每个结点都有自己的 $\small type$ ，一系列属性，和一个有序的孩子结点列表。此外，还假设存在一个表来表示叶子结点映射到基本数据类型的方法；结点类型就是子表达式列表的结点类型。如图：

（3）假定逻辑表达式被规范化为合取范式，将ANDs of ORs 化为一个逻辑表达式列表而不是复杂的二叉树结构。这减少了向逻辑表达式中添加表示式时可能导致的树对齐错误问题。

接下来就是找成对AST树之间的差异，作者使用了快速有序树匹配算法，当匹配两个树之间的节点时，它保留了祖先和从左到右的兄弟关系。算法流程如下：

（1）先计算出两棵树的先序遍历序列

（2）当一对结点匹配时，继续进行下一对结点的匹配；如果不匹配，则回溯到最近匹配的一对结点然后尝试与其他候选结点进行匹配。这个结点的复杂度是

$\small T$ ：树的大小

$\small L$ ：叶子的数量

$\small D$ ：树的深度

将一个查询集合中所有成对AST树之间的差异 组成一个差异表 $\small diffs_{p}$ ，通过将 $\small \tau _{1}$ ， $\small \tau _{2}$ 设置为null，可以表示AST的增加和删除

$\small pid_{1},pid_{2}$ ：对 $\small query\ p_{1},p_{2}$ 的外键引用

$\small \pi$ ：两棵子树唯一的不同路径

$\small \tau _{1}$ ， $\small \tau _{2}$ ：不同的两棵子树

交互建模：

交互（此处的交互可以说是用户使用界面时可以进行选择的地方）是对 $\small diffs$ 中记录的一种抽象，这些记录表示在查询结构更改时改变所在的位置和示例。因此，为交互 $\small t$ 建立树转换函数：

此函数的意思：这个交互 $\small t$ 通过在两棵子树结构开始变化的结点处用一棵新子树替换，来把查询 $\small p$ 的AST树转成另一个查询 $\small p{}'$ 的AST树

然后这个差异表 $\small diffs$ 就可以组成一个交互图，每个结点是一个查询 $\small query$ ，边是由交互（两棵不同AST树之间的变化） $p_{j}=t_{\pi }\left ( p_{i} ,\tau \right )$ 标识的。

界面的闭包：给定一个交互界面， $P_{0}^{I}：初始查询的AST树 W^{I}：一系列交互组件$ ：初始查询的AST树， $W^{I}$ ：一系列交互组件。

用 $W^{I}$ 中的每个小组件 $\small w$ 持续的把当前查询转换成下一查询 $p_{i+1}^{I}=w(p_{i}^{I})$ 。

通过把所有组件的可能组成序列 应用到其初始查询，形成界面闭包 $I_{closure}$ （所有能由初始查询转换而成的最终查询的界面集），这些操作由 $\small exec()$ 函数和 $\small render()$ 函数执行。

把小部件 $w^{^{\theta }}$ 看成小部件类型 $\theta$ 的一个实例。一个部件类型 $\theta$ 包括一个值域 $\Omega _{\theta }$ 和一个代价函数 $C_{\theta }(\Omega )\in R$ ，它衡量对给定的域 $\Omega \subseteq \Omega _{\theta }$ ，该部件类型是否合适的程度。

一个小部件 $w^{\theta }=(t_{\pi },\Omega _{w},f_{w})$ 是部件类型 $\theta$ 的一个实例，它由一个确定的域 $\Omega _{w}\subseteq \Omega _{\theta }$ 以及一个用小部件的状态来修改程序的规范来确定。这个规范通过一个交互（查询结构的变化） $t_{\pi }$ 和一个模板函数 $f_{w}(o) =\tau$ （这个 $\small \tau$ 就是变化发生处的子树）确定。

模板函数将元素 $o\in \Omega _{w}$ 映射到子树 $\tau$ ，子树 $\tau$ 可以作为交互的参数进行传递。

让 $o_{w}\in \Omega _{w}$ 为当前小部件的状态，然后应用此部件到当前的查询等价于： $w(p)=t_{\pi }(p,f_{w}(o_{w}))$

因为精确界面的操作是在语法层面进行操作，某些AST转换的组合可能会导致不可用的查询（语义不正确）。

针对这种情况，作者提出了两种解决方案：（1）在 $I_{closure}$ 中有预见性地执行查询（2）在可视化界面上不允许出现能转换出这些AST的操作

还有一个问题：很多界面可以表示相同的查询，为了对界面进行排序，以选出最优的界面，需要定义一个代价函数来评价这些界面。为了灵活地支持对界面从不同方面进行度量，允许开发人员对部件类型指定多个代价函数。

部件类型 $\theta$ 的代价函数定义为： $C_{\theta }(\Omega )=\sum_{i=1}^{k}\alpha _{i} \times C_{\theta }^{i}(\Omega )$

其中： $C_{\theta }^{i}(\Omega )\in [0,1]$ ：开发人员为第 $i$ 个组件类型定义的代价函数； $\alpha _{i}$ ：该代价函数的权重

对于界面 $I$ ，通过衡量部件的代价函数的和 来估计界面的复杂性： $C_{I}=\sum_{w^{\theta} \in W}^{ }C_{\theta }(\Omega _{w})$ 。

在许多情况下，用一个界面表示所有的查询并不是最优方法。例如，假设一个查询日志中只有两个查询 { $p_{0},p_{1}$ } ，但这两个查询彼此有很大的差异。有两种方法：（1）生成一个复杂界面 $I = (p_{0},\left \{ w \right \})$ ， $w$ 就是表达 $p_{0},p_{1}$ 之间复杂转换的小部件。（2）分别生成两个界面 $I_{0}=(p_{0},\left \{ \right \}),I_{0}=(p_{1},\left \{ \right \})$ ，分别表达不同的查询。

为了能够支持这种复杂性，作者建立界面集 $\mathbb{I}$ ，界面集的复杂性由每个界面的代价和来估计： $C_{\mathbb{I}}=\sum_{I\in \mathbb{I}}^{ }(c_{0}+C_{I})$ ， $c_{0}\in [0,1]$ 是每个新界面的常量代价。作者还建立了界面闭包的闭包来表示界面闭包的集合： $\mathbb{I}_{closure}=\cup _{I\in \mathbb{I}}I_{closure}$

有了上述定义，就可以定义最终要解决的问题了：

PROBLEM1：给定一个查询日志 $P_{log}$ ，一个评价查询覆盖率的阈值 $\gamma$ ，和每个代价函数的权重 $\alpha _{i}$ ，生成最优界面集合 $\mathbb{I}^{\star }$ ：

$\left | \mathbb{I}_{closure}^{\star } \cap P_{log} | \geq \gamma \times |P_{log}\right |$
$C_{\mathbb{I}^{\star }}$ is minimal

本文的目标是：找到一个界面最小结合，它的闭包中包含给定比例 $\gamma$ 的查询

作者又重述解决问题的两个步骤并给出了解决思路：

（1）分析日志，识别有意义的结构变化；如果直接用 $diffs$ 表，会导致复杂的界面生成，因此作者用PILANG语句进行过滤。

（2）将结构变化部分映射到界面的部件：通过确定每个部件的 $\Omega ,t_{\pi },f_{w}$ 来映射。后续作者提出一种把界面生成问题建模成子集覆盖问题进行求解的方法。

小结：

本文作者希望开发一种针对特定任务能够生成精确可视化交互界面的工具。该工具通过分析查询日志生成交互界面。查询日志记录着分析人员的操作，从中发现查询语句之间的变化（变化就是一种交互），将这种变化建模为语法树之间结构的变化。通过将变化映射到界面的相关部件，实现可视化界面操作，方便分析人员操作。

是第二遍看文章，读的过程中会发现很多第一遍没有注意到的东西。所以，好的文章值得多读几遍~

2019.8.18

文中出现的绿色字体是今天对这篇文章的新的理解

名字被猪吃掉了

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Mining Precision Interface From Query Logs -- 学习笔记（一）

Mining Precision Interface From Query Logs》是SIGMOD2019所接收到的papers当中的一篇。花了大概4天时间阅读，全英文的paper读起来还是有点吃力的，不过好在大部分还是能看懂。下面写写自己的学习笔记：摘要（Abstract）摘要其实就能概括整个文章所要解决的问题或者提出的一种新技术：可视化交互工具让数据分析越来越有效，并且对普通大众...
复制链接

扫一扫