对端到端参考架构的另一项需求，是通过集成能被映射到不同需求的各种新旧构建块，使平台和基础设施有机增长，这些构建块可以是不同的类型、模式、大小和系统架构，如独立服务器、云虚拟机、高性能计算集群、低延迟网络、扩展型存储系统、大数据集群、磁带归档或元数据管理系统等等。对于可融入架构的构建块，需遵循行业标准化数据格式，通用软件框架和硬件协同操作性三项标准，这样实施和扩展基因组基础设施可以多种灵活的方式进行：

小规模起步：由于是基于软件定义，如果关键能力和功能到位，为符合有限的预算，系统、平台和基础设施可以相当小。例如，临床测序实验室可部署一个仅由1至2个服务器组成的小型系统，并提供少量磁盘存储和关键软件进行管理。

快速增长：由于计算和存储的增长，已有的基础设施可在不中断操作的情况下迅速扩展到很大规模。如年底，锡德拉湾医疗研究中心建立了属于它们自己的基因组研究基础设施，随后通过参考架构添加了一个新的构建块(60个节点的高性能计算集群)，最终于年中期将存储基础设施增加了三倍。这一健壮的能力使得锡德拉湾成为阿拉伯卡塔尔基因项目的基础设施供应者。

跨地域分布：这是高性能计算领域近期出现的新功能，即数据的共享和联合特性：数据和计算资源被部署在不同的位置，与此同时仍可供用户、应用和工作流访问。在参考架构中，数据集线器和负载编排器与此紧密相关。

很多全球领先的医疗保健和生命科学机构都在积极探索这样的架构，以支持他们的综合研究计算基础设施。下面的章节，将阐述此类参考架构的关键部件、各种最佳实践及项目经验。

数据集线器

数据管理是基因组研究平台最根本的能力，因为海量的数据需要在正确的时间和地点以恰当的成本进行处理。时间方面，可以是在高性能计算系统中进行数小时的数据分析，如果数据需要从存储归档中调出进行再分析，可能需要数年的时间。空间方面，可以在当地的基础设施间实施近线存储，或是云端远程物理存储。

数据管理的挑战

大数据的四个V恰恰是基因组数据管理的挑战：非常大的数据流和容量(数据量Volume)，苛刻的I/O速度和吞吐量要求(数据存取速度Velocity)，快速进化的数据类型和分析方法(数据多样性Variety)，以及共享能力和探索大量数据的环境和可靠性(数据置信度Veracity)。此外，还有法规(患者数据隐私与保护)，种源管理(全版本控制与审计跟踪)和工作流编排等额外的需求，使数据管理难上加难。

数据量

基因组数据因测序成本的急剧下降不断涌现，对于配备了新一代测序技术的学术医学研究中心AMRC，数据存储容量每6至12个月翻一番已变得司空见惯。AMRC作为纽约的尖端研究机构，于年以TB的数据存储能力起步，截至年底，存储量激增超过1PB(TB)，超12个月前存储总量三倍。更令人吃惊的是，这一增长仍在加速并一直延续至今。对一些世界领先的基因组医药项目，如英格兰基因组(英国)、沙特阿拉伯基因组(卡塔尔)、百万精英项目(美国)以及中国国家基因库等，数据量的起点或基准都不再以千兆字节(TB)计，而是成百上千拍字节(PB)。

数据存取速度

基因组平台对数据存取速度的需求非常苛刻，原因有三点：

文件非常大：在基因研究中，文件通常用来存放研究对象的基因组信息，它可以是单个患者的，亦或是一组患者的。主要有两种类型：二进制队列或图即BAM(由基因组序列比对产生)和变型调用文件即VCF(处理后得到的基因变型)，此类文件往往大于1TB，可占用典型基因组数据仓库存储总量的一半。此外，通过扩大研究范围，使用更高的覆盖分辨率，可得出更多的基因组信息(如30至倍全基因组)，这会使存储文件迅速增大。由于基因组研究通常从对罕见变异的研究(单个病人变异提取)演变为常见变异研究，于是出现了一种新的需求：共享成千上万患者的提取样本。以布罗德研究所提供的一个假设为例：对于个共享提取的样品，BAM输入文件有1.4PB，而VCF输出文件有2.35TB，两者以现有水准衡量都是海量数据，但可能在不久的将来变得很普遍。

小文件很多：此类文件用于存储原始或临时的基因组信息，如测序器输出(像Illumina公司的BCL格式文件)。它们通常小于64KB，可占典型基因组数据仓库文件数量一半以上。与处理大文件不同，因为每个文件的I/O都需要对数据和元数据进行两次操作，生成和访问大量文件的负载会非常大，如果按每秒操作数(IOPS)衡量速度，底层存储系统的IOPS可达数百万次。由此可以想到，对于AMRC在圣地亚哥的基础设施，未曾对小文件处理的存储做过任何优化，诸如BCL转换(像Illumina公司的CASAVA算法)这样的负载会因基础设施有限的I/O能力(尤其是IOPS)，导致计算资源枯竭而最终瘫痪。基准测试证实，因计算能力浪费在等待数据就位上，CPU效率会下降至个位数。为了缓解这种计算瓶颈，需要使用数据缓存技术将I/O操作从磁盘转移到内存。

并行和工作流操作：为提高性能、加快时间，基因组计算通常以编排好的工作流批量进行。从小范围目标测序到大范围全基因组测序，为使负载在快速运转中发挥更高效能，并行操作不可或缺。随着成百上千种不同的负载在并行计算环境中同时运行，以I/O带宽和IOPS衡量的存储速度将不断累积并爆发式增长。纽约AMRC的生物信息学应用可并发运行在个计算核心，以每秒写一个文件的速度创建百万级数据对象，无论是个目录、每个目录个文件，亦或是一个目录中的万个文件都能被及时处理。而对于一个拥有6亿对象、万目录、每个目录仅含一个文件的数据仓库，这仅仅是其众多负载中的一小部分。由于元数据是海量的，IOPS负荷会约束整体性能，即使一个列出文件的系统命令(如Linux的ls)也不得不耗费几分钟的时间才能完成，并行应用程序如GATK队列也遭遇了这种低性能。年初，文件系统以改善元数据基础结构为着眼点进行了大幅修正，带宽和IOPS性能均得到显著改善，基准测试显示，在没有任何应用程序调整的情况下，基因疾病应用程序的计算加速了10倍。

数据多样性

按存储和访问方式，数据格式可有多种类型，如多步工作流生成的中间文件，亦或是一些输出文件，其中包含维持生命必需的基因组信息参考数据，而这些数据需要谨慎的进行版本控制。目前常规的方法是，不考虑费用，在一个存储层把所有数据在线或近线存储，这样做会导致大数据生命周期管理能力的缺失。如果基因组数据仓库要用很长时间扫描文件系统，迁移或备份就不可能及时被完成。一家美国大型基因组中心，在采用了Illumina公司的X10全基因组测序算法后，一直挣扎于如何管理快速增长的数据。目前他们完成整个文件系统的扫描需要四天，使得每日或更长一点时间的备份变得不可能。其结果是，数据在单层存储快速堆积，元数据扫描性能不断下降，导致数据管理恶性循环。

另一个新的挑战是数据位置的管理。由于机构间的合作变得越来越普遍，大量的数据需要共享或联合，这使得地理位置成为数据不可缺少的一个特征。同样的数据集，特别是参照数据或输出数据，可以在不同地理位置存在多个拷贝，或者因法规要求在同一位置存在多个拷贝(如因临床测序平台与研究机构物理隔离产生的多重数据副本)。在这种情况下，有效的管理元数据以减少数据移动或复制，不仅能降低额外存储所需成本，还能减少版本同步带来的问题。

数据置信度

许多复杂的身心机能失调，如糖尿病、肥胖、心脏病、阿尔茨海默氏症和自闭症谱系障碍等，要研究它们的多因素特性，需要在广泛的来源中实施缜密复杂的计算，统计分析大流量数据(基因组、蛋白质组、成像)和观察点(临床、症状、环境、现实证据)。全球数据共享和网络联合保证了访问和分析数据的进程以前所未有的规模和维度不断创新和智能化，数据库和文件仓库的进化也由此相互关联在一起。在这样的前提下，数据置信度作为一个不可或缺的元素在研究中得以被考量。例如，临床数据(基因组和成像)需要被恰当和完整的标识以保护研究课题的机密性。基因组数据需要端到端的溯源以提供完整的审计跟踪和可重复能力。数据的著作权和所有权需要由一个多用户协作机构恰当申明。借助内置特性处理数据准确性，基因组计算机构可以让研究人员和数据科学家根据上下文和置信度分享和探讨大量数据。