ディープラーニングのためのレイクハウス「Deep Lake」: Deep Lake システムの概要

リンク一覧

• 概要と序文
• 現在の課題
• テンソル保存形式
• ディープレイクシステムの概要
• 機械学習のユースケース
• パフォーマンスベンチマーク
• 議論と制限
• 関連作業
• 結論、謝辞、参考文献

4. ディープレイクシステムの概要

図 1 に示すように、Deep Lake は生データとビューを S3 などのオブジェクト ストレージに保存し、完全な系統を持つデータセットを具体化します。ストリーミング、Tensor Query Language クエリ、および視覚化エンジンは、外部の管理サービスや集中サービスを必要とせずに、ディープラーニング コンピューティングまたはブラウザー上で実行されます。

4.1 摂取

4.1.1 抽出。メタデータがすでにリレーショナルデータベースに存在する場合があります。私たちはさらに、Airbyte[3] [22]を使用してETL宛先コネクタを構築しました。このフレームワークにより、SQL / NoSQLデータベース、データレイク、データウェアハウスなど、サポートされている任意のデータソースに接続し、データをDeep Lakeに同期することができます。コネクタプロトコルは、データを列形式に変換します。

4.1.2 変換。データ処理ワークフローを大幅に高速化し、ユーザーがチャンクのレイアウトを気にしなくて済むように、Deep Lake では Python 変換を並列で実行するオプションを提供しています。変換ではデータセットを受け取り、最初の次元をサンプルごとに反復処理して、新しいデータセットを出力します。ユーザー定義の Python 関数には、2 つの必須引数 𝑠𝑎𝑚𝑝𝑙𝑒_𝑖𝑛、𝑠𝑎𝑚𝑝𝑙𝑒_𝑜𝑢𝑡 が必要で、@𝑑𝑒𝑒𝑝𝑙𝑎𝑘𝑒.𝑐𝑜𝑚𝑝𝑢𝑡𝑒 で装飾されています。単一のデータセットで、複数のデータセットを動的に作成できます。これにより、1対1と1対多の両方の変換が可能になります。新しいデータセットを作成せずに、変換をその場で適用することもできます。

舞台裏では、スケジューラが近くのチャンクで動作するサンプル単位の変換をバッチ処理し、プロセスプールにスケジュールします。オプションで、計算をRayクラスター[53]に委任することもできます。入力データセットを定義する代わりに、ユーザーはカスタムオブジェクトを含む任意のイテレータを提供して、取り込みワークフローを作成できます。ユーザーは複数の変換を積み重ねて複雑なパイプラインを定義することもできます。

4.2 バージョン管理

Deep Lake は、実験の再現性と完全なデータ系統への準拠の必要性にも対応しています。データセットの異なるバージョンが同じストレージ内に存在し、サブディレクトリで区切られています。各サブディレクトリは、メタデータ ファイルを持つ独立したデータセットとして機能します。バージョン管理されていないデータセットとは異なり、これらのサブディレクトリには、特定のバージョンで変更されたチャンクと、変更されたすべてのチャンクの名前を含むテンソルごとの対応する chunk_set のみが含まれます。ディレクトリのルートにあるバージョン管理情報ファイルは、分岐バージョン管理ツリーとしてこれらのバージョン間の関係を追跡します。特定のバージョンのテンソルのチャンクにアクセスすると、バージョン管理ツリーは現在のコミットから開始して最初のコミットに向かってトラバースされます。トラバース中、各バージョンのチャンク セットで必要なチャンクが存在するかどうかがチェックされます。チャンクが見つかった場合は、トラバースが停止され、データが取得されます。バージョン間の差異を追跡するために、各バージョンでは、テンソルごとにコミット diff ファイルも保存されます。これにより、バージョン間およびブランチ間の比較が高速になります。さらに、データセットの作成中にサンプルの ID が生成され、保存されます。これは、マージ操作中に同じサンプルを追跡するために重要です。Deep Lake のバージョン管理インターフェイスは Python API であり、機械学習エンジニアは CLI を切り替えることなく、データ処理スクリプト内でデータセットのバージョンを管理できます。以下のコマンドがサポートされています。

•コミット: データセットの現在の状態の不変のスナップショットを作成します。

•チェックアウト: 既存のブランチ/コミットにチェックアウトするか、存在しない場合は新しいブランチを作成します。

• Diff : データセットの 2 つのバージョン間の違いを比較します。

•マージ: データセットの 2 つの異なるバージョンをマージし、ユーザーが定義したポリシーに従って競合を解決します。

4.3 テンソルの可視化

データの視覚化は、特にデータを解析的に解析するのが難しい場合、ML ワークフローの重要な部分です。高速でシームレスな視覚化により、データ収集、注釈、品質検査、トレーニングの反復を高速化できます。Deep Lake ビジュアライザー エンジンは、ソースから直接大規模なデータを視覚化するための Web インターフェイスを提供します。テンソルの htype を考慮して、視覚化に最適なレイアウトを決定します。画像、ビデオ、オーディオなどのプライマリ テンソルが最初に表示され、テキスト、class_label、bbox、binary_mask などのセカンダリ データと注釈がオーバーレイされます。ビジュアライザーは、シーケンスなどのメタ タイプ情報も考慮して、データのシーケンシャル ビューを提供します。これにより、シーケンスを再生したり、データ全体を取得せずにシーケンスの特定の位置にジャンプしたりできます。これは、ビデオやオーディオのユース ケースに関連します。ビジュアライザーは、ML ワークフローの重要なニーズに対応し、ユーザーがデータを理解してトラブルシューティングしたり、データの進化を描写したり、予測を真実と比較したり、複数の画像シーケンス (カメラ画像と視差マップなど) を並べて表示したりできるようにします。

4.4 テンソルクエリ言語

データセットのクエリとバランス調整は、ディープラーニングワークフローのトレーニングにおける一般的なステップです。通常、これはデータローダー内でサンプリング戦略またはデータセットをサブ選択するための個別の前処理ステップを使用して実現されます。一方、従来のデータレイクは外部の分析クエリエンジン [66] に接続し、データフレームをデータサイエンスワークフローにストリーミングします。特定のデータへのフォーマットと高速アクセスのギャップを解決するために、C++ で実装された Tensor Query Language (TQL) と呼ばれる組み込み SQL のようなクエリエンジンを提供します。クエリの例を図 5 に示します。SQL パーサーは Hyrise [37] から拡張されて Tensor Query Language を設計しましたが、オプションで外部のテンソル計算フレームワークに計算を委任できるプランナーと実行エンジンを実装しました。クエリプランは、テンソル操作の計算グラフを生成します。次に、スケジューラがクエリグラフを実行します。

クエリの実行は、PyTorch [58] や XLA [64] などの外部テンソル計算フレームワークに委任して、基盤となる高速ハードウェアを効率的に利用することができます。標準の SQL 機能に加えて、TQL は数値計算も実装します。新しいクエリ言語を実装する主な理由は 2 つあります。まず、従来の SQL では、画像ピクセルの平均を計算したり、特定の次元に配列を投影したりするなどの多次元配列操作がサポートされていません。TQL は、Python/NumPy スタイルのインデックス作成、配列のスライスを追加し、配列を操作するための便利な関数を多数提供することでこの問題を解決します。これらの関数の多くは、NumPy でサポートされている一般的な操作です。次に、TQL により、クエリと Deep Lake の他の機能 (バージョン管理、ストリーミング エンジン、視覚化など) とのより深い統合が可能になります。たとえば、TQL を使用すると、特定のバージョンまたはデータセットの複数のバージョンにわたるデータのクエリを実行できます。TQL は、クエリ結果の視覚化をカスタマイズするための特定の命令や、フィルタリングされたストリーミングのためのデータローダーとのシームレスな統合もサポートしています。埋め込みクエリ エンジンは、リモート コンピューティング インスタンスでモデルをトレーニングするとき、または WebAssembly 経由でコンパイルされたブラウザー内でクライアントとともに実行されます。TQL は、多次元列の上で数値計算を行う SQL を拡張します。データセットのビューを構築し、それを視覚化したり、ディープラーニング フレームワークに直接ストリーミングしたりできます。ただし、クエリ ビューはスパースになる可能性があり、ストリーミングのパフォーマンスに影響する可能性があります。

4.5 具体化

ディープラーニングに使用される生データのほとんどは、ローカルまたはクラウド上に生ファイル（JPEG などの形式で圧縮）として保存されます。データセットを構築する一般的な方法は、これらの生ファイルへのポインターをデータベースに保存し、これをクエリして必要なデータのサブセットを取得し、フィルタリングされたファイルをマシンにフェッチしてから、ファイルを反復処理してモデルをトレーニングすることです。さらに、データ系統は、出所ファイルを使用して手動で維持する必要があります。Tensor Storage Format は、リンクされたテンソルを使用してこれらの手順を簡素化します。つまり、元のデータへのポインター（1 つまたは複数のクラウド プロバイダーへのリンク/URL）を保存します。単一のテンソル内のポインターは複数のストレージ プロバイダーに接続できるため、ユーザーは複数のソースに存在するデータの統合ビューを取得できます。クエリ、バージョン管理、ディープラーニング フレームワークへのストリーミングなど、Deep Lake のすべての機能は、リンクされたテンソルで使用できます。ただし、データ ストリーミングのパフォーマンスは、デフォルトのテンソルほど最適ではありません。クエリによって作成されたスパース ビューにも同様の問題が発生しますが、チャンク レイアウトにより非効率的にストリーミングされます。さらに、マテリアライゼーションはデータセット ビューを最適なレイアウトに変換し、ディープラーニング フレームワークにストリーミングして反復処理を高速化します。マテリアライゼーションでは、リンクまたはビューから実際のデータを取得し、それを効率的にチャンクにレイアウトします。このステップを機械学習ワークフローの最後に実行すると、データの重複が最小限に抑えられ、最適なストリーミング パフォーマンスと最小限のデータ重複が確保され、完全なデータ リネージュが実現します。

4.6 ストリーミング データローダー

データセットが大きくなるにつれて、リモートに分散されたストレージからネットワーク経由で保存および転送することが避けられなくなります。データ ストリーミングにより、すべてのデータがローカル マシンにコピーされるのを待たずにモデルをトレーニングできます。ストリーミング データローダーは、データの取得、解凍、変換の適用、照合、およびトレーニング モデルへのデータの引き渡しを確実に実行します。ディープラーニング データローダーは通常、同期計算を回避するために、取得と変換を並列実行プロセスに委任します。次に、データはプロセス間通信 (IPC) を介してメイン ワーカーに転送されますが、これによりメモリ コピーのオーバーヘッドが発生するか、共有メモリが使用され、信頼性に問題が生じます。対照的に、Deep Lake データローダーは、グローバル インタープリター ロックを回避するために、プロセスごとに C++ で高度に並列化された取得とインプレース解凍を委任します。次に、ユーザー定義の変換関数にメモリ内ポインターを渡し、ディープラーニング ネイティブ メモリ レイアウトでトレーニング ループに公開する前に照合します。ネイティブ ライブラリ ルーチン呼び出しのみを使用する場合、変換は並列で同時に実行され、それに応じて Python グローバル インタープリター ロック (GIL) が解放されます。その結果、次のようになります。

•パフォーマンス: GPU が最大限に活用されるか、コンピューティングによってボトルネックになるくらいの速さで、ディープラーニング モデルにデータを配信します。

•スマート スケジューラ: CPU を集中的に使用するジョブとそれほど集中しないジョブを動的に区別して優先順位を設定します。

• 効率的なリソース割り当て: メモリの消費量を予測して、メモリの過剰充填によるトレーニング プロセスの中断を回避します。

[3] ソースコードはhttps://github.com/activeloopai/airbyteのブランチ@feature/connector/deeplakeから入手可能