Motivation
数据搬运耗时，加上存储性能提升，近存计算和存内计算优势逐渐显现。将query offload到SSD上去，以此来减少开销（DRAM和虚拟核资源等的占用）。以前的工作或是支持的sql操作不多，或是能够处理的数据量不大。AQUOMAN目标是对于1TB数量级的数据处理有明显的提升，同时能支持所有的sql操作。
Related Work
对于data center加速方面的研究包括Operator-specific和Query-specific，前者包括加速排序和join等单一操作，后者针对完整的query语句。
最初研究人员尝试利用SSD controller(见下图)中的ARM核进行简单的filter操作，但是性能相比x86核很不理想，之后的工作多是考虑借助于ASIC(以Q100为代表)和FPGA进行优化（以Insider为代表）。
Architecture Overview
此项工作基于column-oriented MonetDB，将每一列进一步划分为多个32-element的Row vector，并进行编号(Row Vector ID)。
整体思路是将query plan转换成Table Task，支持所有sql操作；对于TPC-H的22个SQL，每次都需要依据静态的dataflow graph（辅助作用）重新生成。
FPGA在其中扮演什么样的角色呢？是Table Task在FPGA上执行完毕再传输到SSD中去？那这和In storage Processor有什么关系？还是说离Flash更近了，做的是近存计算？
对于某一sql 的query plan来说，可以对应划分成多组Table Task。Table Task是作者设计提出，可以分为Row Selector、Row Transformer、SQL Swissknife三部分。Row selector针对不同的predicate（where saledate > 2018-03-15）选取符合条件的行，借助Row-Mask Vector（类似于子网掩码与IP做and运算得到网络号）进行标记。Row Transformer完成如"l_extendedprice*(1-l_discount)"的映射转换。SQL Swiss-knife包括TOPK, SORT, AGGREGATE-GROUPBY, AGGREGATE, NOP, MERGE和SORT_MERGE七项基本操作，其内部实现均借助于以前研究的成果，而不过分关注于此，需要考虑的更多是如何利用好flash的带宽。Row selector和Row Transformer的输出结果无需存储在DRAM中，也是减少DRAM使用的一个原因。SQL Swissknife输出结果可以存至DRAM等待下一个Table Task调用，或者直接返回给host端。
注：本图左侧有缺失，应该是论文排版或者作者截图的锅。
对System Stack的关注点重点在于上图中蓝色区域，AQUOMAN Compiler和AQUOMAN Executor与位于Flash Drive的AQUOMAN之间有一条无需通过Filesystem和Block Device Driver的通道。AQUOMAN Compiler和Executor分别对应什么呢？依据后文来看，作者只是在FPGA上实现了TPC-H的Q01，Q06，Q03和Q10，其余均是基于自行设计的仿真器进行模拟的。如此看来，AQUOMAN Compiler应该是将sql的query plan转换成相应的Table Task，那么AQUOMAN Executor是负责什么？最终是生成AQUOMAN programs发送给AQUOMAN。