Tue 08 June 2021
在科学中。
标签：sourmashMAGsearchSRAsoftwarek-mersminhash
为了准备我今天要参加的NIH/DOE关于 "PB级序列搜索的新兴解决方案 "的研讨会，我想我应该写下我们目前用sourmash进行公共元基因组搜索的情况。我写这篇博文很匆忙，我可能会在以后收到评论和反馈时进行修改；如果我这样做，我会指出一个不同的地方。
这主要是基于Luiz Irber博士去年所做的工作，作为他和我一起完成的博士工作的一部分。
sourmash本身是可用的（见sourmash.readthedocs.io/），而且我们昨天刚刚发布了v4.1.2版本它是在BSD 3条款许可下，通过conda和pip完全可用。
简而言之--用MAGsearch进行轻量级元基因组搜索
今天，我们可以使用MAGsearch在所有公开的元基因组中稳健地找到与10kb以上的序列（或10,000个以上的k-mers集合）的匹配，最高可达93%的ANI。
它对以下方面特别有用
- 从公共元基因组中收集候选基因，例如用于疫情检测。
- 寻找与某一特定物种或属相的匹配，以研究其生态分布。
- 收集数据集，以扩大我们对一个物种庞然大物的了解。
今天，一个有~100个查询基因组的搜索需要大约17个小时，将搜索58万个元基因组，代表530TB的原始序列数据。
它是如何在下面工作的
我们使用sourmash来支持元基因组的包含性搜索，并带有缩放的签名。
sourmash按比例的签名来自MinHash技术。它们是k-mer集合的压缩表示，可以可靠地用于寻找任何两个集合之间的~10kb的DNA片段的精确匹配；更大的匹配可以找到大约93%的ANI。
这里的一个关键方面是，可以在不接触原始数据的情况下进行搜索。
我们维护了一个~580,000个公共元基因组的签名集合，其SRA为k=21、31和51。目前，使用32个线程和48GB的内存（在我们的HPC上）进行大约100个基因组大小的查询需要17个小时。
我们完整的签名集约为10TB，尽管这其中包含的数据远远超过元基因组数据--它包含370万个签名，代表1.3PB的总数据（SRA元基因组+SRA非植物/动物+Genbank/Refseq微生物基因组）。
这个签名集由wort自动更新，它协调一个分布式的工作者集合，在新数据到达NCBI时计算签名。
简单的改进机会
MAGsearch是一个强大的原型，有许多直接的改进机会。我猜想，通过几周的集中投资，我们可以把每次搜索的时间缩短到大约1小时。
首先，MAGsearch的代码在加载方面没有做任何特别的事情；它使用默认的sourmash签名格式，也就是JSON。例如，二进制编码将大大减少集合的大小，同时也加快了搜索速度（通过减少加载时间）。
其次，搜索签名是以线性方式进行的，并使用Rust来进行并行搜索。它使用的是支撑sourmash的相同的Rust代码（但比最新版本晚了几个版本）。利用sourmash Rust代码的最新改进，可能会使其速度提高数倍。
第三，我们现在可以在我们的DNA签名集合中加入蛋白质签名，这将使搜索更加敏感。(不过，我们必须勾画出大量的数据。 :)
更广泛的限制
我们在sourmash中使用的内部数据结构是为相对较小的k-mer集合而优化的，因为sourmash是围绕k-mer集合的下采样而建立的。我们正在慢慢地改进我们的内部结构，但是支持所有的k-mer并不直接，也不是我们目前的路线图上的东西。
我们的草图技术只支持个别的K-mer大小/分子类型。因此，虽然我们可以计算、存储和搜索DNA、蛋白质、Dayhoff编码等的多种k-mer尺寸，但它们是分开存储的，不会 "压缩 "在一起。这意味着，当我们提供更多的K-mer大小和分子类型时，签名集的大小会迅速增长
我们还不太确定如何向人们提供我们目前的数据库。就我个人而言，我也没有真正准备好支持MAGsearch作为一项服务，但这部分是因为缺乏资金。
sourmash还提供什么？
sourmash本身是稳定的，经过良好的测试，可以放心地用来做许多生物信息学任务。它很容易安装（pip/conda），并且有相当好的文档。
我们的数据结构和算法是简单的，被充分理解的，并且可以直接（重新）实现。虽然它们还没有全部发表，但我们很乐意解释它们，并告诉你它们在什么地方能用，什么地方不能用。
sourmash速度快，内存小，即使是相当大的签名集，也只需要很少的磁盘空间。
sourmash有一个越来越有用的命令行界面，支持许多常见的k-mer和搜索操作。从这个意义上说，它可以作为基于k-mer的工具所能支持的一套良好的 "默认 "操作的部分指南。我们也对用户体验给予了相当多的关注。
在下面，sourmash有一个灵活的Python API，正在慢慢被下面的Rust取代。这意味着我们可以在重构下面的关键功能的同时，快速建立新功能的原型，因此sourmash的性能不断提高，同时我们也在处理新的用例。
我们有一个开放的、强大的软件开发方法，有越来越多的贡献者。我不确定我们是否已经准备好接受很多新的贡献者，因为我们的路线图流程还不是很成熟，但我们正在努力。
我们对sourmash包本身使用了语义版本，并且我们清楚地传达了关于破坏性的变化。因此，sourmash可以干净地集成到工作流程中，并有简单的版本钉住要求。
我们支持公共和私人的签名集，我们所有的主要搜索和分析方法都可以与多个数据库或签名集一起使用，而不需要重新索引或从头开始组合它们。
我们还支持灵活的 "自由形式 "分类法，特别是支持NCBI和GTDB分类法。
我希望看到petabase规模的搜索走向何方？
我不主张将sourmash本身（无论是软件还是基础技术）作为搜索所有（元）基因组数据的真正方法。在其他方面，sourmash有很多其他的用例，对我们来说很重要！但我认为我们有一些经验。
但我认为我们有一些经验可以提供给任何这样的努力 --
- 我们有支持元基因组搜索和分析的一些真正有用的用例的功能实现。如果不失去这些用例就好了
- 高灵敏度的预过滤方法是很好的，可以在事后进行灵活的分类。我们主要使用sourmash作为一种轻量级的方法来找到我们可能关心的所有东西，然后再做更深入的分析。
- 拥有命令行和Python API是非常有用的，我认为绕过好的API而选择网络API是一个错误。当然，这也大大增加了开发人员的工作量，但回报是你可以实现更多的灵活性。
- 在此基础上，我认为编写一个只适用于NCBI格式和分类法的自定义网络托管索引和搜索工具将是一个错误。
- 更进一步说，能够快速添加数据库/集合进行搜索是非常好的，既支持完全的私人数据库，又支持快速更新公共数据库集合，与其他许多元基因组分析工具相比，这一点真的非常有用。
- 数据结构和算法的简单性对我们sourmash有很大的帮助。软件支持从根本上说是一个维护的游戏，能够用多种语言重新实现我们的核心数据结构和算法已经很不错了。特别是，当我看其他软件包时，我很担心过早的优化问题。
Luiz还通过Dat和IPFS做了很多关于分布式计算和去中心化的思考，我认为这可能是有价值的，但我不是专家，不能自己总结出来。希望Luiz能写点东西出来:)。(你可以看看他的博士论文，第4章和第5章，了解一些多汁的细节和讨论。)
对于大规模的搜索，我们还应该关注哪些工具？
我认为Serratus在展示大规模元基因组搜索的一些可能性方面做得很好！有很多工具可以使用。
有很多工具处于不同的发展阶段，但我对metagraph特别感兴趣。
我很想听到更多的工具和方法--请在评论中或在twitter上提出来!
--titus
