8,935 測定値

現代のデータレイクを構築するために必要なトップ 10 ツールに関するアーキテクトガイド

に MinIO8m2024/08/27

長すぎる; 読むには

以下は、最新のデータレイクを構築するために必要なベンダーとツールのリストです。各エントリには、生成 AI をサポートするために必要な機能が記載されています。

featured image - 現代のデータレイクを構築するために必要なトップ 10 ツールに関するアーキテクトガイド

以前、最新のデータレイクリファレンスアーキテクチャは、あらゆる企業が抱える課題（データの増加、Hadoop ツールの老朽化（特に HDFS）、RESTful API（S3）とパフォーマンスに対する需要の高まり）に対処していますが、いくつかのギャップを埋めたいと考えています。

最新のデータレイク (データレイクハウスとも呼ばれる) は、半分がデータレイクで、半分が Open Table Format Specification (OTF) ベースのデータウェアハウスです。どちらも最新のオブジェクトストレージ上に構築されています。

同時に、私たちは、トレーニングセット、検証セット、テストセットの生のストレージだけでなく、AI/ML のあらゆるニーズに対応できる AI データインフラストラクチャを組織が構築する方法を深く考えてきました。言い換えれば、大規模な言語モデル、MLOps ツール、分散トレーニングなどをトレーニングするために必要なコンピューティングが含まれている必要があります。この考え方の結果として、最新のデータレイクの使用方法に関する別の論文をまとめました。 AI/MLをサポートするリファレンスアーキテクチャニーズは以下のとおりです。下の図は最新のデータレイクリファレンスアーキテクチャ生成 AI に必要な機能が強調されています。

ソース：最新のデータレイク内の AI/ML

どちらの論文も、特定のベンダーやツールについては言及していません。ここでは、最新のデータレイクを構築するために必要なベンダーとツールについて説明したいと思います。このトップ 10 リストの各項目は、生成 AI をサポートするために必要な機能です。

1.データレイク

エンタープライズデータレイクは、オブジェクトストレージ上に構築されます。安価で大規模なアーカイブのユースケースに使用されていた旧式のアプライアンスベースのオブジェクトストレージではなく、最新の GenAI スタックの基礎となる、最新の高性能なソフトウェア定義の Kubernetes ネイティブオブジェクトストアです。これらは、サービス (AWS、GCP、Azure) として、またはオンプレミスで、あるいは MinIO などのハイブリッド/両方で利用できます。これらのデータレイクは、ストリーミングワークロードをサポートし、非常に効率的な暗号化と消去コーディングを備え、オブジェクトとともにメタデータをアトミックに保存し、Lambda コンピューティングなどのテクノロジをサポートする必要があります。これらの最新の代替手段はクラウドネイティブであるため、ファイアウォールから可観測性、ユーザーおよびアクセス管理まで、他のクラウドネイティブテクノロジのスタック全体とすぐに統合されます。

2.OTFベースのデータウェアハウス

オブジェクトストレージは、OTP ベースのデータウェアハウスの基盤となるストレージソリューションでもあります。データウェアハウスにオブジェクトストレージを使用するのは奇妙に聞こえるかもしれませんが、このように構築されたデータウェアハウスは、次世代のデータウェアハウスを表しています。これは、Netflix、Uber、Databricks によって作成された OTF 仕様によって可能になり、データウェアハウス内でオブジェクトストレージをシームレスに使用できるようになります。

OTF (Apache Iceberg、Apache Hudi、Delta Lake) は、作成者のデータニーズに対応できる製品が市場になかったために作成されました。基本的に、これらはすべて (方法は異なりますが)、オブジェクトストレージ上に構築できるデータウェアハウスを定義します。オブジェクトストレージは、他のストレージソリューションでは実現できない、スケーラブルな容量と高いパフォーマンスの組み合わせを提供します。これらは最新の仕様であるため、パーティション進化、スキーマ進化、ゼロコピーブランチなど、旧式のデータウェアハウスにはない高度な機能を備えています。

MinIO 上で OTF ベースのデータウェアハウスを実行できる 2 つの MinIO パートナーは、Dremio と Starburst です。

Dremio Sonar (データウェアハウス処理エンジン)

Dremio Arctic (データウェアハウスカタログ)

Open Data Lakehouse | Starburst (カタログと処理エンジン)

3.機械学習オペレーション（MLOps）

MLOps は機械学習にとって、DevOps は従来のソフトウェア開発にとってのような関係にあります。どちらも、エンジニアリングチーム (Dev または ML) と IT 運用 (Ops) チーム間のコラボレーションを改善することを目的とした一連のプラクティスと原則です。目標は、計画と開発から展開と運用まで、自動化を使用して開発ライフサイクルを合理化することです。これらのアプローチの主な利点の 1 つは、継続的な改善です。

MLOps の技術と機能は絶えず進化しています。主要なプレーヤーによってサポートされ、ツールが継続的に開発および改善され、長期サポートが提供されるツールが必要です。これらの各ツールは、モデルのライフサイクル中に使用される成果物を保存するために、内部で MinIO を使用しています。

MLRun (Iguazio、McKinsey & Company が買収)

MLflow (データブリックス)

Kubeflow (Google)

4.機械学習フレームワーク

機械学習フレームワークは、モデルを作成し、モデルをトレーニングするコードを書くために使用するライブラリ (通常は Python 用) です。これらのライブラリは、さまざまな損失関数、オプティマイザー、データ変換ツール、ニューラルネットワーク用の事前構築されたレイヤーのコレクションを提供するため、機能が豊富です。これら 2 つのライブラリが提供する最も重要な機能はテンソルです。テンソルは、GPU に移動できる多次元配列です。また、モデルのトレーニング中に使用される自動微分化機能も備えています。

現在最も人気のある 2 つの機械学習フレームワークは、PyTorch (Facebook 社) と Tensorflow (Google 社) です。

パイトーチ

テンソルフロー

5.分散トレーニング

分散モデルトレーニングは、複数の計算デバイスまたはノードにわたって機械学習モデルを同時にトレーニングするプロセスです。このアプローチは、特に複雑なモデルをトレーニングするために大規模なデータセットが必要な場合に、トレーニングプロセスを高速化します。

分散モデルトレーニングでは、データセットは小さなサブセットに分割され、各サブセットは異なるノードによって並列に処理されます。これらのノードは、クラスター内の個々のマシン、個々のプロセス、または Kubernetes クラスター内の個々のポッドである可能性があります。これらは GPU にアクセスできる場合があります。各ノードはデータのサブセットを独立して処理し、それに応じてモデルパラメータを更新します。以下の 5 つのライブラリにより、開発者は分散トレーニングの複雑さのほとんどから解放されます。クラスターがない場合はローカルで実行できますが、トレーニング時間を大幅に短縮するにはクラスターが必要です。

DeepSpeed (Microsoft 社製)

Horovod (Uber より)

Ray (Anyscale より)

Spark PyTorch ディストリビューター (Databricks より)

Spark TensorFlow ディストリビューター (Databricks より)

6. モデルハブ

モデルハブは、実際には最新のデータレイクリファレンスアーキテクチャの一部ではありませんが、生成 AI をすぐに開始するために重要なため、ここに含めています。Hugging Face は、大規模な言語モデルを探す場所となっています。Hugging Face は、エンジニアが事前トレーニング済みのモデルをダウンロードしたり、自分で作成したモデルを共有したりできるモデルハブをホストしています。Hugging Face は、大規模言語モデル (LLM) と、そのトレーニングや微調整に使用するデータを扱う Transformers ライブラリと Datasets ライブラリの作成者でもあります。

他にもモデルハブはあります。主要なクラウドベンダーはすべて、モデルをアップロードして共有する何らかの方法を提供していますが、モデルとライブラリのコレクションを備えた Hugging Face がこの分野のリーダーとなっています。

抱きしめる顔

7. アプリケーションフレームワーク

アプリケーションフレームワークは、LLM をアプリケーションに組み込むのに役立ちます。LLM の使用は、標準 API の使用とは異なります。ユーザーリクエストを LLM が理解して処理できるものに変換するには、多くの作業を行う必要があります。たとえば、チャットアプリケーションを構築して Retrieval Augmented Generation (RAG) を使用する場合は、リクエストをトークン化し、トークンをベクターに変換し、ベクターデータベース (後述) と統合し、プロンプトを作成してから、LLM を呼び出す必要があります。生成 AI 用のアプリケーションフレームワークを使用すると、これらのアクションを連結できます。現在最も広く使用されているアプリケーションフレームワークは LangChain です。これは、Hugging Face Transformer ライブラリやドキュメント処理用の Unstructured ライブラリなど、他のテクノロジと統合されています。機能が豊富で、使用が少し複雑になる可能性があるため、複雑な要件がなく、LangChain よりもシンプルなものを求めている人向けに、以下にいくつかの代替手段を示します。

TensorFlow (Keras API)

8. 文書処理

ほとんどの組織には、クリーンで正確なドキュメントを保管する単一のリポジトリがありません。むしろ、ドキュメントはさまざまなチームポータルにさまざまな形式で組織全体に分散しています。ジェネレーティブ AI の準備の最初のステップは、ジェネレーティブ AI での使用が承認されたドキュメントのみを取得してベクターデータベースに配置するパイプラインを構築することです。これは、大規模なグローバル組織にとってジェネレーティブ AI ソリューションの最も困難なタスクになる可能性があります。

ドキュメントパイプラインは、ドキュメントをテキストに変換し、ドキュメントをチャンク化し、チャンク化されたテキストを埋め込みモデルに通して、そのベクトル表現をベクトルデータベースに保存できるようにする必要があります。幸いなことに、いくつかのオープンソースライブラリが、多くの一般的なドキュメント形式でこれを実行できます。以下にいくつかのライブラリを示します。これらのライブラリを LangChain と共に使用して、完全なドキュメント処理パイプラインを構築できます。

非構造化

オープンパース

9. ベクターデータベース

ベクターデータベースはセマンティック検索を容易にします。これがどのように行われるかを理解するには、多くの数学的背景が必要であり、複雑です。ただし、セマンティック検索は概念的には理解しやすいものです。たとえば、「人工知能」に関連するあらゆることを論じているすべてのドキュメントを検索したいとします。従来のデータベースでこれを行うには、「人工知能」のあらゆる略語、同義語、関連用語を検索する必要があります。クエリは次のようになります。

 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...

この手動の類似性検索は面倒でエラーが発生しやすいだけでなく、検索自体も非常に低速です。ベクターデータベースは、以下のようなリクエストを受け取り、より高速かつ正確にクエリを実行できます。検索拡張生成を使用する場合は、セマンティッククエリを迅速かつ正確に実行できることが重要です。

 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }

以下に、人気のある 4 つのベクターデータベースを示します。

10. データの探索と視覚化

データを整理し、さまざまな方法で視覚化できるツールを用意しておくことは常に良い考えです。以下にリストされている Python ライブラリは、データ操作と視覚化の機能を提供します。これらは従来の AI にのみ必要なツールのように思えるかもしれませんが、生成 AI でも役立ちます。たとえば、感情分析や感情検出を行う場合は、トレーニング、検証、テストセットをチェックして、すべてのクラスに適切な分布があることを確認する必要があります。