MiTCRは、新しいタイプを診断するためのプラットフォームです。 ヤンデックスワークショップ

Dmitry Bolotinの物語は、免疫受容体のレパートリーの分析のために開発されたMiTCRソフトウェアに捧げられています。 彼のレポートでは、生のシーケンスデータの分析の主な機能、特にソースデータのシーケンスアライメントとエラー修正アルゴリズムを検討し、プログラムのアーキテクチャ、パフォーマンス、および即時開発計画についても簡単に説明しました。 MiTCRのソースコードは公開されています。 将来、このソフトウェアはバイオインフォマティクスの共通プラットフォームとなり、データを処理して他の研究者と共有できるようになる可能性があります。 この共同作業の結果は新しいタイプの診断になるはずです：血液検査の助けを借りて、人が特定の病気にかかっているかどうかの質問に答えるだけでなく、彼が正確に何で病気にかかっているかをすぐに判断することができます。







ビデオを報告する



どのデータをどのデータから取得したのかが明確になるように、遠くから始めます。 カットの下の写真では、免疫が非常に概略的に示されています。 同じ特異性を持つ細胞は同じ色で染色されます（つまり、同じタイプの感染を認識します）。 このような細胞をクローンと呼びます。 感染症の攻撃中、それを認識する細胞の数が増加します。



これらの細胞の特異性は、表面にT細胞受容体があり、その集合規則が対応する遺伝子に記録されているという事実によるものです。 その後の物語では、その構造を理解することが重要です。











遺伝子はDNAの断片であり、4文字のアルファベットで構成されるシーケンスと考えることができます。 T細胞受容体遺伝子の独自性は、細胞ごとに異なるということです。 私たちの細胞にある他のすべての遺伝子は同じで、T細胞受容体と抗体の遺伝子のみがそれぞれTリンパ球とBリンパ球で異なります。







この遺伝子は4つの主要な部分から成ります。 T細胞受容体の一部は常に同じです。 他の2つのセクション（図の赤と緑）は、小さなセットから選択されます。 これらの2つのセクションのアセンブリ中に、ランダムな文字（10個程度）がそれらの間に追加され、このような受容体の巨大な種類の形成につながります。 タンパク質内の抗原を認識する領域は、CDR3と呼ばれます。







両面から興味深いです：一方で、抗原認識に関与する受容体部位をコード化するのは生物学であるため、特異性を決定します。他方では、すべての多様性がそれに集中しているため、識別子として便利です。赤の断片、緑の断片。 これらの断片から、これらのセグメントのセットのどれが選択されたかを完全に判断でき、これらのランダムな文字はすべて完全にその中に集中しています。 したがって、CDR3を知っていると、タンパク質全体を再構築できます。 CDR3が同じであれば、遺伝子全体も同じであるため、これを識別子として使用することもできます。



そこで、血液サンプルを入手し、CDR3を含むDNA配列を分離するために、複雑な分子生物学的反応の特定のシーケンスを実行します。 次に、それらをシーケンサーにロードすると、出力で次のようになります。







これは、シーケンスセンターから送られてくる実際のデータです。 余分なものを捨てると、実際には100〜250ヌクレオチド長のDNA配列にすぎません。 そして、そのようなシーケンスはたくさんあります。



私たちのタスクは、このデータから最初にあったものを再構築することです。 プライマリサンプルに含まれていたクローンの数と数を調べます。



データにはさまざまなエラーがあるため、すべてが複雑になっています。 これらのエラーは、サンプルの準備中、シーケンス中など、すべての段階で発生します。 エラーの発生率は、一般的にすべてから使用されたシーケンサーの実験のアーキテクチャに応じて異なる場合があります。 これらは、挿入、削除、および置換です。







そして、これはまず第一に、サンプル上のデータが歪められ、人為的な多様性が導入されるという観点から悪いです。 サンプルが1つのクローンのみで構成されていたが、準備エラーの結果としてそこに導入されたとします。 その結果、以前よりも多くのクローンがあり、患者のT細胞のレパートリーについて間違った見方をしていることがわかります。



次に、使用しているデータについて簡単に説明します。 入力では、約1億個の配列、または10億個から100〜250個のヌクレオチド長が得られます。 これらはすべて合計で最大100 GBです。 また、CDR3の濃度は、1/5（非常にまれなケースではそれ以上）から最大数百万のシーケンスまで可能です。



当社が開発したMiCTRソフトウェアのスキームは、およそ次のとおりです。







MiCTRは、前述の問題を解決します。データからクローンのリストを作成し、エラーを修正します。 最初のブロックはデータからCDR3を抽出し、次のブロックはCDR3でのみ機能し、それらをクローンに結合してエラーを修正します。



最初のブロックにはあまり集中しません。 彼はアライメントに従事しており、これはバイオインフォマティクスの大きな部分であり、別個の講義が必要です。 要するに、このブロックは入力シーケンスをマークし、それらのどこが赤で、どこが緑のセクションかを決定します。 それらが選択されるセットは既知であり、データベース内にあり、すべての人にとってまったく同じです。 これらの赤いパッチのどれがどこで見つかったかを判断します。 緑のエリアでも同じことを行います。 これらのアラインメントを構築したので、CDR3がどこにあるかをすでに知っているので、シーケンスからそれらを選択して操作できます。



このデータで行う最も一般的なことは、同じ方法でそれらを結合することです。同じCDR3を収集してカウントする必要があります。 しかし、以来 データには修正が必要なエラーがあり、修正のために、CDR3のセットでファジー検索を実行します（たとえば、1文字だけ異なるCDR3を検索します）。その後、ストレージには、このような操作に非常に便利なプレフィックスツリー（トライ）を使用します。 さらに、成長とともにこのツリーは再構築されないため、あらゆる種類の競合アルゴリズムを実装するのが非常に便利です。 複雑な同期について心配する必要はありません。 このツリーは非常に使いやすいですが、欠点もあります。 それは重く、RAMのかなりの重さです。 ただし、実際の条件では、これは特定の問題を引き起こさないことが判明しているため（1〜2の範囲内で保持できます）、したがって、このようなデータの理想的なコンテナーです。



エラーで何をしますか？ 実際、これらのクローンはすべて、シーケンスの一部からのみ収集されます。 事実、シーケンサーは、読んだ文字を提供することに加えて、エラーの確率を決定する各位置に品質値を設定します。 つまり シーケンサーは手紙を読みましたが、彼はそれを確信できるかどうかはわかりません。 そして、各位置について、エラーの確率が確立されます。 そして、ここではかなり単純なトリックを行っています。エラーの確率のしきい値、たとえば100分の1を費やすだけです。 エラーの可能性が高いすべての文字は、badと呼ばれます。 したがって、そのような手紙を含むすべてのCDR3は、我々も悪いと見なします。 これらはすべて、豊富なデータを収集するだけでなく、他の情報も収集するコンテナに保存されます。同等のCDR3、または品質の低い位置のみが異なるCDR3を検索します。 したがって、エラーの大部分を修正することができます。 残念ながら、すべてのエラーを取り除くことはできません。エラーの一部はシーケンサーの前に行われるため、エラーに関する追加情報はありません。



そして、ここではかなり単純なことを行っています。1文字だけ異なり、集中度が大きく異なるCDR3のペアを見つけます。 ほとんどの場合、これは明示的なエラーマーカーです。 そして、私たちはそのようにそれらを削除し、集中度で1から10のオーダーの閾値を選択します：シーケンスごとに1つのエラー。



全体として、これらすべてにより、エラーの95％を修正すると同時に、自然の多様性を除去することができません。 このようなアルゴリズムを使用すると、間違いを犯して自然なクローンをエラーと見なすことができますが、実際には非常に多様であるため、これは起こりません。 このようなパフォーマンスは、実際の作業に適した数値です。



これらすべてのソフトウェア実装を説明するのは少し価値があります。 多くのシステムがあり、マークアップシーケンスは並行して実行されます。 ユニプロセッサシステムでは、スレッドの数がコアの数に対応する場合、最良の結果が得られます。 上の図は、2つのストリームでの作業を示しています。1つは良いCDR3からのクローンの形成に、もう1つは悪いCDR3からのクローンの形成に関与しています。 これはすべて適切にスケーリングされます。たとえば、6コアプロセッサでは、コードの実行速度は約3.5〜4倍になります。 パフォーマンスに関しては、完全に普通のハードウェア（AMD Phenom II X4 @ 3.2 GHz）では、1秒あたり50,000シーケンスが処理されます。 1つのクロノタイプのストレージには、約5 KBのRAMが必要です。 したがって、私たちの経験から最も複雑な（多様な）アレイは、上記のプロセッサと16 GBのRAMを搭載したマシンで20分で処理することができました。



すべてがJavaで書かれており、 ソースはオープンで、十分に文書化されたAPIがあります 。これは、バイオインフォマティクスがコードの一部に何かを埋め込むのが便利な場合が多いためです。



現在、このデータから診断を行う方法に近づいています。 すでに、ゲノム配列決定に関するこれらすべての実験は、いくつかの新薬を思い付くのに役立ちます。 ただし、このデータをそのまま使用するには、パターンからパターンを抽出する方法を学ぶ必要があります。



確かに可能であり、多くの記事は、同じタイプの感染が同じCDR3を生成することを示しています。 これは、診断を構築できることを示唆しています。 あまり目立たないパターンを生じる複雑なオブジェクトがあることは明らかです。 そして、そのようなパターンを検出するためには、多くの統計、コントロールデータ（健康なドナー）と既知の病気の病気の患者の両方の大きなセットが必要です。 おそらく、あるクリニックでは、このような多数のサンプルを蓄積して、広範な疾患に必要なパターンを追跡することはできません。 そして、コラボレーションのための単一の場所は、診断の開発に貢献します。



このようなデータベースは、パターンの計算とサンプルの分析に必要な特定のキャストを作成できる便利な構造でこのデータを保存する必要があります。 アクセスを区別する必要があるため、 多くの臨床データを公衆と共有することはできません。 また、このデータベースが仕事をすることも必要です。データパターンをキャッチし、新しいデータでそれらを検索し、同じ新しいデータを使用して徐々に改良し、パフォーマンスを向上させます。



そのような基盤は、かなり遠い未来に向けて設定されています。 最初から、なぜそれが必要なのかは明確ではないかもしれません。 しかし、このデータ自体は複雑です。 数百の配列を操作していると想像してください。各配列には100万のシーケンスがあります。 この場合、それらの間のパターンを探す必要があり（非常に複雑になる可能性があります）、必ずしも完全に同等のCDR3ではなく、たとえば類似のものを探しています。 また、検索は多くの配列ですぐに実行されます。 一般に、パターンを見つけることは非常に困難です。 これをすべて説明できるような高レベルの言語が必要です。 現在、このデータを扱う研究者は、毎回何らかのスクリプトを書くことを余儀なくされています。 実際、いくつかの明確なパターンをトレースすることは、同じアレイ内で同じアレイの同じクローンを見つけることよりも複雑です。今ではうまくいかず、必要なツールはありません。 したがって、このようなベースを作成すると、人々にとって興味深いものになります。 特定の研究問題を解決します。 生物学者はしばしばこのデータを扱うので、グラフィカルインターフェイスが必要なだけなので、これらはすべて便利で明確でなければなりません。 本当に興味深い結果を得るには、さまざまなソースから1つの場所に集まってくる大量のデータが必要なので、コラボレーションのためのプラットフォームが必要です。



このような共通データベースを編成する際の主な問題は、研究者からのこのデータの配信です。 私たちは数百GB、さらにはテラバイトについて話しています。 徐々に、この問題はクラウドサービスのおかげで解決され始めます。 多くの研究者は、自分の作業の結果をYandex.Disk、Dropboxなどにアップロードします。 専用のクラウドストレージもあります。 たとえば、BaseSpaceはイルミナシーケンサー用に特別に調整されています。 つまり シーケンサーを購入すると、BaseSpaceで自動的にアカウントが取得され、シーケンス処理の過程でデータがロードされます。 さらに、BaseSpaceには、外部アプリケーションからアクセスできる便利なAPIがあります。 そのため、インフラストラクチャの一部として使用できます。



すでにいくつかのプロトタイプデータベースがあります。 アイデアは、生データがしばらくしてから再処理を必要とする可能性がある場合、テープに書き込み、どこかに別々に保存できるということです。 これは、大量のデータを保存する最も安価な方法です。 このようなサービスは、たとえばAmazon Glacierによって提供されます。 処理されたデータはリレーショナルデータベースに保存できますが、これは完全にオプションです。 実際、これは非構造化データ-CDR3リストです。 したがって、それらはファイルとしてブロックリポジトリに保存され、データベース構造の再構築時にロードされます。



低レベルでパターンを計算する場合、バイオインフォマティクスでは次のクエリが必要になる可能性が高くなります。

• 特定のクローンが一致するすべてのアレイを見つけます。
• アレイグループで見つかったすべてのクローンを見つけます。
• さまざまなファジー検索とグループ化

独自のアルゴリズムを記述せずにこれを迅速かつ簡単に行うには、PostgreSQLを使用できますが、これが唯一の方法ではなく、プロトタイプで使用されている可能性が高いです。 PostgreSQLには逆キーのようなものがあります。フィールドにintの配列をそれぞれ保存するだけで、「これらのフィールドに数字3、5、8を含むすべてのレコードをください」などのクエリを作成できます。 そして、これらのクエリは非常に高速です。 以下の画像は、プロトタイプの単純化されたモデルを示しています。 CDR3に付属する他の付随情報であるメタ情報がまだたくさんあるはずです。 実際、キーがCDR3であり、データにこのCDR3が参加しているデータセットのリストが含まれていたため、良好なパフォーマンスを達成しました。 したがって、このキーに対するクエリは、このようなデータベースが通常実行するクエリと完全に一貫しています。



プロトタイプのパフォーマンスについて詳しく説明できます。 たとえば、クアッドコアIntel Core i7 2600 @ 3.8 GHzプロセッサ、16 GBのRAM、およびそれぞれ128 GBの2つのSSDのソフトウェアRAID1を搭載したマシンを取り上げます。 合計4,500万列を含む112個のアレイが入り口に送られました。 これらはすべて、SSDで70 GBに収まります。 その結果、「2つのアレイからのすべてのクローン」などのリクエストでは、約150ミリ秒の遅延で毎秒50操作のパフォーマンスを達成することができました。



結論として、このようなことを診断として機能させるには、1か所にデータを蓄積する必要があることを繰り返したいと思います。 現在、すべてのテストは、人が特定の病気にかかっているかどうかを判断することを目的としています。 新しいタイプの診断は、ある分析の助けを借りて、正確に人が病気にかかっているものに即座に答えを出すことを目的としています。 これを行うには、大量のデータを収集して処理する必要がありますが、プロトタイプは非常に現実的であり、あまりリソー​​スを消費しないことを示しています。