Omilayers：助力多组学分析的高效数据管理 Python 神器

为解决多组学数据管理难题，如数据存储、检索和分布问题，研究人员开展了关于 Omilayers 这一 Python 包的研究。结果显示，Omilayers 可有效管理数据，且 DuckDB 性能优于 SQLite。该研究为多组学分析提供了便利，推动相关领域发展。

　　在生命科学研究领域，多组学分析（multi-omic analysis）正逐渐成为解开生物奥秘的关键钥匙。它通过整合基因组学（genomics）、代谢组学（metabolomics）、转录组学（transcriptomics）和蛋白质组学（proteomics）等多层面的数据，深入剖析生物系统的复杂性，从而为精准医疗、疾病机制研究等提供有力支撑。然而，多组学数据的管理却面临着诸多挑战。一方面，不同类型的组学数据具有不同的特征和数据类型，传统的数据管理系统难以满足快速存储、检索以及扩展数据的需求；另一方面，现有的数据库接口和查询语言繁杂多样，用户在使用时需要学习不同的语法，操作不便，尤其是对于不熟悉结构化查询语言（SQL）的用户来说，更是困难重重。为了解决这些问题，来自西班牙巴斯克研究与技术联盟（Basque Research and Technology Alliance，BRTA）旗下的合作生物科学研究中心（Center for Cooperative Research in Biosciences，CIC bioGUNE）整合基因组学实验室（Integrative Genomics Lab）的 Dimitrios Kioroglou 开展了一项关于多组学数据分析和管理的研究。该研究成果发表在《BMC Bioinformatics》杂志上，为多组学数据管理提供了创新的解决方案。

在研究方法上，研究人员主要运用了以下几种关键技术：首先，利用模拟合成数据的方法，构建了包含队列特征、代谢组学、转录组学、肠道微生物组以及 DNA 测序数据等多组学层面的虚拟数据集。例如，从人类代谢组数据库（HMDB）下载代谢物数据，从 GENCODE 门户提取基因 ENSEMBL ID，从 GMrepo 门户获取人类肠道微生物组数据等，并通过均匀分布生成相应的数据值。其次，在数据库操作方面，借助 Python 包 Omilayers 对 SQLite 和 DuckDB 这两种嵌入式数据库进行封装，利用其提供的统一应用程序编程接口（API）进行数据的存储、检索和修改操作。最后，使用线性回归等统计方法对数据库在不同操作下的性能进行评估，对比分析 SQLite 和 DuckDB 在处理多组学数据时的表现差异。

研究结果如下：

1. 数据库性能对比 - 存储时间：在存储合成的多组学数据时，SQLite 和 DuckDB 都展现出了良好的性能，运行时间适用于分析目的。对于小数据集，SQLite 的存储速度略快于 DuckDB；但随着数据集增大，SQLite 的性能逐渐下降。不过，在存储 VCF 层数据时情况有所不同，由于该层数据是以分块形式存储，DuckDB 的存储速度比 SQLite 慢近两倍，这表明 DuckDB 在处理频繁小数据块的磁盘读写操作方面不如 SQLite 优化。通过线性回归分析（不考虑 VCF 层存储时间，因其涉及多次磁盘读写的额外因素），研究发现数据量每增加 1MB，SQLite 存储数据的时间增加 25ms（95% 置信区间 23 - 28ms），DuckDB 增加 10ms（95% 置信区间 1 - 19ms）。
2. 数据库性能对比 - 检索时间：在数据检索方面，除了 VCF 层数据（该层仅解析给定样本的所有存储变异，内存占用为 803MB），其他组学层数据均加载到内存中进行测试。结果显示，DuckDB 在所有数据大小情况下的检索性能都优于 SQLite。经线性回归分析（包括 VCF 层数据检索结果），数据量每增加 1MB，SQLite 检索数据的时间增加 88ms（95% 置信区间 83 - 92ms），DuckDB 仅增加 2.3ms（95% 置信区间 2.1 - 2.4ms）。这主要是因为 DuckDB 是列存储数据库，能够进行矢量化执行，相比 SQLite 的行存储方式，更适合批量处理数据。
3. 数据库性能对比 - 磁盘空间使用：DuckDB 在磁盘空间使用效率上高于 SQLite。不考虑 VCF 层时，其他组学层数据存储后，SQLite 的总磁盘占用为 67MB，DuckDB 为 66MB；而存储 VCF 层数据后，两者差异显著增大，SQLite 的磁盘占用增加到 37GB，DuckDB 仅增加 13GB，接近压缩后的 VCF 文件大小。
4. 数据库性能对比 - 扩展和查询操作：在扩展存储数据（列向操作）方面，研究人员重点对转录组学和 VCF 层数据进行测试。结果显示，添加新列时，SQLite 的运行时间明显长于 DuckDB，且磁盘空间增加量也更大。例如，对于转录组学层添加包含 60,649 行（473.6KB）的新列，SQLite 运行时间为 520ms，DuckDB 为 140ms；对于 VCF 层添加包含 9,640,953 行（803MB）的新列，SQLite 运行时间为 316.49s，DuckDB 为 9.87s 。在基于行的查询操作中，以 VCF 层数据为例，DuckDB 的性能也远超 SQLite。平均而言，SQLite 返回查询结果的时间为 33.07s（标准差 SD = 0.31s），DuckDB 仅为 0.10s（标准差 SD = 0.008s）；在并行执行 297 个查询时，两者的性能差异更为明显，SQLite 运行时间为 1800s，DuckDB 仅为 8.47s。

研究结论与讨论部分指出，Omilayers 作为一个 Python 包，成功封装了 SQLite 和 DuckDB 的功能，为生物信息学分析和多组学数据管理提供了便利。它通过统一的 API，使研究人员无需编写复杂的 SQL 查询语句，即可轻松进行数据操作，大大降低了多组学数据分析的门槛。总体来看，DuckDB 在性能上优于 SQLite，因此成为 Omilayers 的默认数据库。但 SQLite 也有其优势，对于小到中等规模的数据集，在需要频繁进行小数据量磁盘读写操作的情况下，SQLite 可能是更好的选择，而且它具有完全向后兼容性，而 DuckDB 从 v0.10 版本才添加该功能。此外，研究也指出了 DuckDB 的一些局限性，如不支持跨多台机器的工作负载分配和多进程写入（除非使用数据库锁），并且该研究未模拟合成单细胞 RNA 测序（scRNA-seq）转录组数据，这是未来研究可以进一步拓展的方向。尽管如此，Omilayers 的出现仍然为多组学研究领域带来了新的曙光，为深入探索生命奥秘提供了更强大的数据管理工具，有望推动精准医学、疾病机制研究等相关领域的快速发展。