Referenzarchitektur für die Verarbeitung genomischer Daten

In diesem Dokument werden Referenzarchitekturen für die Verwendung der Cloud Life Sciences API mit anderen Google Cloud-Produkten für die Verarbeitung genomischer Daten mithilfe verschiedener Methoden und Workflow-Engines beschrieben. Dieses Dokument befasst sich insbesondere mit den Ausrichtungs- und Variantenaufrufschritten der Sekundäranalyse und richtet sich an Bioinformatiker, Forscher, IT-Teams und andere technische Experten in einer Biowissenschaftsorganisation.

Google Cloud bietet eine flexible Reihe von APIs, Diensten und Tools zum Ausführen einer umfassenden, kostengünstigen Lösung für Sekundäranalysen. Die sekundäre Analyse umfasst unter anderem das Filtern von Rohlesevorgängen, das Ausrichten und Zusammenstellen von Sequenzlesevorgängen sowie QA und Variantenaufrufe bei ausgerichteten Lesevorgängen.

Architektur

Das folgende Diagramm zeigt die Schritte zur Verarbeitung umfassender genomischer Daten und zeigt, welche Schritte in Google Cloud ausgeführt werden.

Diagramm: Umfassende genomische Daten mit Google Cloud verarbeiten

Wie das vorherige Diagramm zeigt, wird eine Stichprobe genomischer Daten zuerst einer primären Analyse unterzogen. Diese werden dann als Rohdaten zur sekundären Analyse in Google Cloud aufgenommen. Die verarbeiteten Daten werden anschließend einer Tertiäranalyse unterzogen. Danach werden Berichte wie PDFs erstellt, die von Bioinformatikern und anderen technischen Experten aus der Cloud heruntergeladen werden können.

Komponenten der Referenzarchitektur für die Verarbeitung genomischer Daten

Dieses Dokument enthält Details zur Verwendung der Cloud Life Sciences API sowie zwei Übersichten zur Referenzarchitektur, die verschiedene Möglichkeiten zur Verwendung der API für die Verarbeitung genomischer Daten beschreiben.

Cloud Life Sciences API verwenden

Die Cloud Life Sciences API bietet einen vollständig verwalteten Computing-Service, der optimale Rechenressourcen basierend auf den Ressourcenanforderungen für einen Batchjob bietet. Die API bietet Ihnen die Möglichkeit, Befehlszeilentools auf Compute Engine-Instanzen zu erstellen, auszuführen und zu überwachen, die in einem Docker-Container ausgeführt werden. Sie können mehrere Befehlszeilentools so organisieren, dass sie in einer bestimmten Reihenfolge und mit Abhängigkeiten zwischen den Schritten ausgeführt werden. Die Cloud Life Sciences API enthält den Service WorkflowsServiceV2Beta, mit dem Sie Workflows ausführen können, z. B. Pipelines, die aus Docker-Containern bestehen.

Ein Pipeline-Objekt besteht aus einer oder mehreren Action-Beschreibungen und einer Resources-Nachricht, die beschreibt, welche Cloudressourcen zum Ausführen der Pipeline erforderlich sind. Jede Aktion beschreibt eine einzelne Docker-Containerausführung, die ein oder mehrere command-Objekte enthalten kann. Action-Objekte werden nacheinander ausgeführt. Dabei wird jedes Objekt erst ausgeführt, wenn das vorherige Objekt beendet wurde, es sei denn, das vorherige Objekt ist für die Ausführung im Hintergrund festgelegt. Es gibt Flags, die beeinflussen, wie jedes Action-Objekt ausgeführt wird und wie sich der Exit-Status auf Aktionen in der Pipeline auswirkt, z. B. ob ein Action-Objekt im Hintergrund ausgeführt werden soll oder ob der Exit-Status ignoriert werden soll. Als Pipeline-Autor erstellen Sie eine Resources-Nachricht, die beschreibt, welche Cloudressourcen zum Ausführen der Pipeline erforderlich sind.

Die Spezifikationen in der Resources-Nachricht können Folgendes enthalten:

  • Größen virtueller Maschinen (VMs), einschließlich benutzerdefinierter Maschinenformen und Abrufbarkeit
  • Zonen und Regionen für die VM-Zuordnung
  • Netzwerkoptionen (wichtig für große Verarbeitungsprojekte aufgrund von Beschränkungen der Netzwerkgröße)
  • Angehängte Beschleuniger (GPUs)
  • Angehängte Laufwerke
  • Dienstkonten und Bereich

Wenn die Cloud Life Sciences API ein Pipeline-Objekt über einen API-Aufruf empfängt, führt sie folgende Aufgaben aus:

  1. Erstellt eine Compute Engine-VM-Instanz basierend auf dem Nachrichteninhalt Resources.
  2. Lädt alle Docker-Images herunter, die in einer Action-Beschreibung angegeben sind.
  3. Führt jedes Action-Objekt als neuen Docker-Container mit dem angegebenen Image und Befehl aus.
  4. Löscht die Compute Engine-VM-Instanz.

Eine typische Reihe von Aufgaben, die in einer Action-Beschreibung beschrieben wird, kann Folgendes umfassen:

  • Laden Sie die Eingabedateien herunter.
  • Führen Sie die Befehle aus.
  • Kopieren Sie Logs in Cloud Storage.
  • Laden Sie die Ausgabedateien hoch.

Die Cloud Life Sciences API nutzt die skalierbare und starke Speicher- und Verarbeitungsleistung von Google Cloud zusammen mit VM-Instanzen, GPUs und Tensor Processing Units (TPUs), um eine sichere und skalierbare Umgebung für die Datenanalyse bereitzustellen. Dies umfasst die schnelle, einfache und kostengünstige Ausführung branchenüblicher Frameworks für die Sekundäranalyse einzelner Stichproben oder gemeinsamer Datasets, z. B. Genome Analysis Toolkit (GATK) und DeepVariant.

Die Cloud Life Sciences API ist in Open-Source-Workflow-Engines wie Cromwell, Nextflow und Galaxy eingebunden. Darüber hinaus unterstützen Nextflow und Galaxy die Datenverarbeitung in Google Cloud durch direkte Einbindung in Compute Engine und Cloud Storage. Das folgende Diagramm zeigt eine Referenzarchitektur, die Komponenten der Cloud Life Sciences API sowie andere Dienste enthält, die zum Ausführen einer Pipeline für genomische Sekundäranalysen in Google Cloud erforderlich sind.

Diagramm: Referenzarchitektur, die zeigt, wie die Cloud Life Sciences API auf Compute Engine-Rechenknoten mit Persistent Disk, Container-Optimized OS und GPUs ausgeführt wird

Verarbeitung genomischer Daten: Mit Cromwell GATK Best Practices-Workflows ausführen

Sie können die Cloud Life Sciences API mit einer Workflow-Engine zum Orchestrieren von Aufgaben verwenden. Im folgenden Beispiel wird Cromwell für die sekundäre Analyse verwendet, während die GATK Best Practices-Workflows angewendet werden.

Cromwell ist ein Open-Source-Workflow-Verwaltungssystem, das für die Planung, Ausführung und Verwaltung von Workflows in verschiedenen Umgebungen ausgeführt werden kann. Cromwell liest einen in der Workflow Description Language (WDL) definierten Workflow und führt mithilfe der Cloud Life Sciences API einzelne Aufgaben aus dem Workflow aus. In diesem Fall wird ein Cromwell-Server auf einer Compute Engine-VM-Instanz mit einem Cloud SQL-Server zum Speichern von Betriebsdaten ausgeführt. Die Cromwell-VM führt dann alle durch API-Aufrufe an die Cloud Life Sciences API definierten Aufgaben aus, um VM-Instanzen für jede der Aufgaben, wie in der WDL konfiguriert, zu starten.

Das GATK enthält Tools zur Variantenerkennung und Genotypisierung. Die GATK Best Practices-Workflows enthalten eine Reihe von Pipelines für bestimmte Anwendungsfälle. In diesem Beispiel geht es um den Produktionsworkflow PairedEndSingleSampleWf. Der Workflow umfasst die Datenvorverarbeitung, den ersten Aufruf von Varianten für Genom-Einzelnukleotid-Polymorphismen (SNPs) und die Indel-Entdeckung in einer einzigen Stichprobe von Sequenzdaten für das gesamte Genom.

Der Workflow verwendet menschliche Sequenzdaten für das gesamte Genom im unmapped BAM-Format (uBAM) mit einer oder mehreren Read-Gruppen und verwendet das Hg38-Referenzgenom mit ALT-Contigs. Die Ausgaben umfassen eine Cram-Datei, einen Cram-Index, Cram md5, GVCF und einen entsprechenden Index sowie einen BQSR-Bericht und mehrere Zusammenfassungsmesswerte. Das verwendete Beispiel ist eine heruntergeladene Version von NA12878, die nur drei Read-Gruppen des vollständigen Beispiels enthält. Der Workflow ist in einer Reihe von WDL-Dateien zusammengefasst, die die einzelnen Aufgaben sowie eine Eingabespezifikation und allgemeine Optionen definieren. Die WDL-Dateien geben die Cloudressourcen für die einzelnen Aufgaben an, z. B. die Anzahl der CPU-Kerne und den Arbeitsspeicher für jede VM-Instanz, den auf jeder VM-Instanz zu installierenden Container und den auszuführenden Befehl sowie Speicherorte der Ein- und Ausgabedateien. Es gibt noch weitere Spezifikationen, z. B., ob ein Schritt auf präemptiven Maschinen ausgeführt werden soll und wie oft ein Action-Objekt wiederholt werden soll.

Das folgende Diagramm zeigt eine typische Architektur für die Durchführung einer genomischen Sekundäranalyse mit Cromwell zur Ausführung der GATK Best Practices-Workflows mit der Cloud Life Sciences API, einschließlich der Schritte, die für die Analyse erforderlich sind.

Diagramm: Cromwell verwenden, um GATK Best Practices mit der Cloud Life Sciences API auszuführen

Das Diagramm zeigt die folgenden Schritte zum Ausführen einer Sekundäranalyse:

  1. Nach der Sequenzierung speichern Sie die unbearbeiteten Basisaufrufe im lokalen Speicher oder im Network Attached Storage (NAS), wo sie in uBAM-Dateien konvertiert werden. Anschließend übertragen Sie diese uBAM-Dateien in einen Cloud Storage-Bucket.
  2. Sie authentifizieren sich mit der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM), um als Dienstkonto zu fungieren.

  3. Senden Sie den Job dann an den Cromwell-Server, der auf Compute Engine ausgeführt wird.

    Die Anfrage wird über den Identity-Aware Proxy geleitet, der so konfiguriert ist, dass er mithilfe von Google Cloud-Firewallregeln den Zugriff auf Virtual Private Cloud zulässt.

  4. Der Cromwell-Server ruft den Workflow für das GATK aus öffentlichen Repositories ab.

  5. Der Cromwell-Server ruft die Cloud Life Sciences API auf, um Jobs zu starten.

  6. Die Cloud Life Sciences API ruft die jeweiligen Container für die Aufgaben aus den öffentlichen GATK-Repositories ab.

  7. Die Cloud Life Sciences API startet für jede Aufgabe VMs in Compute Engine und den Container auf jeder Maschine.

  8. Die VM-Instanz ruft Eingabedateien aus Cloud Storage-Buckets ab.

  9. Die VM-Instanz führt Berechnungsaufgaben aus und speichert Zwischen-, Log- und Ausgabedateien in einem Cloud Storage-Bucket.

Verarbeitung genomischer Daten: DeepVariant ausführen

DeepVariant ist eine Open-Source-Analysepipeline, die in einem neuronalen Deep-Learning-Netzwerk genetische Varianten von DNA-Sequenzierungsdaten der nächsten Generation aufruft. Diese Analyse-Pipeline wurde von einem Forschungsteam bei Google entwickelt und verwendet TensorFlow für SNP- und Indel-Variantenaufrufe für Exome oder Genome. DeepVariant wird verwendet, um ausgerichtete Sequenz-Reads in Variantenaufrufe umzuwandeln.

Sie müssen drei Eingaben bereitstellen, um DeepVariant auf oberster Ebene zu verwenden:

  • Ein Referenzgenom im FASTA-Format und die entsprechende .fai-Indexdatei, die mit dem faidx-Befehl in Samtools generiert wurde.
  • Eine Datei mit alignierten Reads im BAM-Format und die zugehörige Indexdatei (.bai). Die Reads müssen auf das angegebene Referenzgenom ausgerichtet sein.
  • Das DeepVariant ML-Modell, das für den Variantenaufruf verwendet werden soll.

DeepVariant gibt eine Liste aller Variantenaufrufe im VCF-Format aus. DeepVariant ist in das Framework für maschinelles Lernen TensorFlow eingebunden.

Sie können DeepVariant in einem Docker-Container, in den direkten Binärdateien, mit lokaler Hardware oder in der Cloud ausführen. DeepVariant unterstützt die Verwendung von Hardwarebeschleunigern wie GPUs und TPUs. Sie können Docker verwenden, um DeepVariant von einem Docker-Container aus mit nur einem Befehl auszuführen. Eine Beschreibung hierzu finden Sie in der DeepVariant-Kurzanleitung. Für Produktionsanwendungsfälle in Google Cloud sollten Sie den DeepVariant-Prozess in Ihren Workflow einbinden und den Aufruf über Ihre Workflow-Engine ausführen.

Alternativ können Sie den DeepVariant Runner verwenden, der die Cloud Life Sciences API ähnlich wie die in der Anleitung DeepVariant ausführen erläuterten Methoden verwendet. Auf diese Weise können Sie DeepVariant mithilfe einer Docker-basierten Pipeline ausführen, die für Kosteneinsparungen und Geschwindigkeit optimiert ist.

Das folgende Diagramm zeigt eine typische Architektur zum Ausführen einer DeepVariant-Pipeline in Google Cloud.

Diagramm: Architektur zum Ausführen einer DeepVariant-Pipeline in Google Cloud

Führen Sie die folgenden Schritte aus, um DeepVariant auszuführen, wie im vorherigen Diagramm dargestellt:

  1. Nachdem Sie zugeordnete DNS-Reads aus Stichproben erstellt haben, übertragen Sie diese BAM-Dateien in einen Cloud Storage-Bucket.
  2. Sie authentifizieren mit IAM um als Dienstkonto zu fungieren.
  3. Sie führen DeepVariant aus, das Aufrufe an die Cloud Life Sciences API sendet, um Jobs zu starten.
  4. Die Cloud Life Sciences API ruft den DeepVariant-Container für jede Aufgabe aus den öffentlichen Repositories ab.
  5. Die Cloud Life Sciences API startet für jede Aufgabe VMs in Compute Engine und den Container auf jeder Maschine.
  6. Die VM-Instanz ruft Eingabedateien aus Cloud Storage-Buckets ab.
  7. Die VM-Instanz führt Berechnungsaufgaben aus und speichert Zwischen-, Log- und Ausgabedateien in einem Cloud Storage-Bucket.

Data Governance

Die in diesem Dokument beschriebene Architektur konzentriert sich auf die Komponenten, die für die Analyse genomischer Daten spezifisch sind. Für eine Produktionsintegration, die menschliche Genomdaten enthält, müssen Sie möglicherweise je nach Anforderungen und Best Practices in Ihrer Rechtsprechung zusätzliche Komponenten in Google Cloud konfigurieren.

Google Cloud bietet eine End-to-End-Architektur, die Best Practices für Google Cloud umfasst und Sie dabei unterstützt, die Anforderungen im Bereich Sicherheit, Datenschutz und Compliance im Gesundheitswesen zu erfüllen. Das Cloud Healthcare Data Protection Toolkit enthält viele der Best Practices für Sicherheit und Datenschutz, die für Gesundheitsdaten empfohlen werden. Dazu gehören das Konfigurieren eines angemessenen Zugriffs, das Verwalten von Audit-Logs und Monitoring auf verdächtige Aktivitäten. Weitere Informationen zu diesen Funktionen und dazu, wie Google Cloud zum Schutz von Kundendaten beiträgt, finden Sie im Whitepaper Trusting your data with Google Cloud.

Datenstandort

Für Organisationen mit Anforderungen an den Datenstandort finden Sie im Abschnitt "Allgemeine Dienste" des Dokuments Dienstspezifische Bedingungen zur Überprüfung der Google Cloud-Datenstandortzusicherung Informationen zu Tools und Steuerelementen, die zur Konfiguration der Nutzerumgebung zur Verfügung stehen, um solche Anforderungen zu erfüllen.

Organisationsrichtlinien

Wenn Sie den physischen Standort einer Ressource in einem Projekt beschränken möchten, können Sie eine Organisationsrichtlinie festlegen, die eine Standortbeschränkung für Ressourcen enthält. Eine Liste der unterstützten Dienste finden Sie unter Unterstützte Dienste für Ressourcenstandorte.

Google Cloud-Ressourcenkennungen

Im Rahmen dieses Dokuments gelten die Zusicherungen zum Datenstandort nicht für Ressourcenkennungen, Attribute oder andere Datenlabels. Es liegt in Ihrer Verantwortung, dass in diesen Kennungen, Attributen oder anderen Datenlabels, z. B. in einem Dateinamen, keine vertraulichen Daten offengelegt werden.

Cloud Life Sciences API-Regionen und -Zonen

Wenn Sie Cloud Life Sciences API-Aufrufe ausführen, müssen Sie die Region angeben, in die die Anfrage gesendet wird. Das folgende Beispiel zeigt einen Endpunkt-URI zum Ausführen einer Pipeline im Google Cloud-Projekt foo und der Region us-central1:

v2beta/projects/foo/locations/us-central1/workflows:runPipeline

Alle Metadaten, die für den Vorgang gespeichert werden, einschließlich Container-Image-Namen, Ein- und Ausgabedateinamen und anderer Informationen, die in der Anfrage an die Cloud Life Sciences API gesendet werden, werden in dieser Region gespeichert.

Wenn die Cloud Life Sciences API eine Compute Engine-VM-Instanz startet, muss der API-Aufruf eine Region oder Zone enthalten, in der die VM-Instanz gestartet werden soll. Sie können eine oder mehrere Regionen oder Zonen konfigurieren, um den Standort der VM einzuschränken. Die VM-Instanz, inaktive Daten in Compute Engine und nichtflüchtige Speicher verbleiben in der angegebenen Region. Verfügbare Features für Compute Engine-Instanzen wie CPU-Plattformen, Maschinentypen, SSDs und GPUs unterscheiden sich je nach Region und Zone. Prüfen Sie daher, ob die erforderlichen Ressourcen in einer Region oder Zone verfügbar sind, bevor Sie die Nutzung auf diese Region oder Zone beschränken.

Weitere Informationen finden Sie unter Details und Bedingungen für den Compute Engine-Datenstandort.

Google Cloud Storage

Sie können in Cloud Storage Eingabe- und Ausgabedateien, temporäre Arbeitsdateien und Snapshots von nichtflüchtigem Speicher speichern. Inaktive Daten in Cloud Storage-Buckets verbleiben in der Region, Dual-Region oder Multi-Region, die Sie beim Konfigurieren des Buckets auswählen. Weitere Informationen finden Sie in der aktuellen Liste der Cloud Storage-Bucket-Standorte.

Zur Optimierung von Verfügbarkeit, Leistung und Effizienz können Sie eine Cloud Storage-Dual-Region verwenden. Wenn Sie diese Option auswählen, werden die Daten im Bucket asynchron in zwei bestimmte Regionen kopiert, sodass die Daten in verschiedenen Regionen redundant sind. Weitere Informationen finden Sie unter Dual-Regionen in Cloud Storage.

Verwenden Sie für Leistung und den Datenstandort, wenn möglich, dieselbe Region für Cloud Storage, Compute Engine und die Life Sciences API.

Weitere Informationen finden Sie unter Details und Bedingungen für den Cloud Storage-Datenstandort.

Nächste Schritte