k-mer matching算法以及它存储受限的原因

最近看了一篇ISCA2021的论文：

Sieve: Scalable In-situ DRAM-based AcceleratorDesigns for Massively Parallel k-mer Matching

对其中的应用程序基因序列对比不是很了解，不是很明白为什么会造成内存瓶颈以及cache缺失率较低。看了一下文中提到的相关文献的原理，记录一下。主要包括这两篇：

Kraken: ultrafast metagenomic sequenceclassification using exact alignments
Reducing storage requirements for biologicalsequence comparison

主要任务是将判断当前序列是属于哪种组织或者物种，判断方法就是通过将目标基因序列与现有的数据库中的基因序列进行对比。基因序列对比数据量可以达到TB级别甚至更高。传统的基因序列对比方法是通过将两个序列对齐，然后进行对比，对于这种数据量很大的场景，这种传统方法由于cache容量有限以及内存也不够大导致不断的访存以及从磁盘中获取数据，带来很大的性能开销。所以大家一般都选用k-mer matching的算法。

k-mer matching算法

通过将一个大的序列分割成大小为k的子序列，每个子序列称为k-mer。数据库也会进行处理，会生成一棵Taxonomy tree，用于记录各种k-mer属于哪个标签。孩子节点的序列信息包含了父节点的信息，也就是序列更长，对应图1中左边的树就是蓝色的比紫色的长。在图1中k取6，按照6个数据为一个k-mer，一个长为 l 的序列，使用k，可以得到 l-k+1个k-mer。

图1 ：

算法流程如下

图2：

先将要查询的query_seq分为kmer存放在kmer_list中，然后对于kmer_list中每个kmer进行查询结果，将结果保存在payload_list中。最后依据payload_list中的内容来进行分配，判断当前的query_seq属于哪个组织或者物种。通常来说在分类过程中通常采用计数的方法，最终选择数量最多的类别。如图3所示：

图3

为了做到分分类这件事，有许多的kmer的方法，CLARK和LMAT通过使用hash函数的方法将kmer模式映射为对应的Taxon，上图就是CLARK的做法。更加高级一点的Kraken利用hash以及一个简单的排序表的思想来完成这项任务，Kranken的主要思想如图4所示：

图4：

通过在k-mer中使用Reducing storage requirements for biologicalsequence comparison论文中的思想，选取一个大小为M的M-mer作为k-mer的特征代表，选取方式就是选字典序最小的，如图5所示，左边是M=3，右边是M=7。

图5：

将参考数据集中所有的Taxon按照对应的Mmer相同的在按照他们的字典序放在同一个序列中，最后再将所有的序列放在一起，构成Mmer的偏移表。当要对比时，按照Mmer偏移表中记录的区域去查找，查找方式为二分查找。
对比这两种方式，前一种由于hash表较大，而且程序呈随机访问的特性，cache的缺失率较高；后一种方式由于选取的M比k小，所以当处理相邻的kmer时，查询的有概率是同一个区域，这样就很好的增加了cache的命中率。

但是，尽管采用这种方法，cache的性能仍然不是很理想。主要原因如下：

k-mer matching算法存储受限的原因

①对于CLARK和LMAT这种将参考的 k-mers 存储在hash表中的序列分类器，访问hash表会由于链表遍历或再次hash（以解决哈希冲突）而产生大量缓存未命中。
②虽然hash表以及排序列表混合可以提供更好的局部性，但由于 k-mer 存储桶（同一个M-mer对应的范围）可以从之前的 k-mer 查找中提取到缓存中，使用 Kraken 及其提供的数据集，发现只有 8% 的连续 k-mers 索引到同一个存储桶中，从而导致从内存中重复获取新存储桶以服务请求。
③ k-mer 匹配还受益于更细粒度的内存访问，k-mer 记录通常约为 12 字节，而每次内存访问检索数据的缓存行，由于局部性较差，通常只服务一个请求，导致浪费带宽和功耗。
④k-mer 匹配的计算强度太小，无法掩盖数据访问延迟。以 CLARK为例，由于缓存未命中从数据库中检索 k-mers 需要很多周期，而更新匹配 k-mers 的计数器非常快，从而放大了内存墙的影响。