Analytics Generic Concepts#
このハブでは、最新のデータ分析プラットフォームの基礎を形成する主要な業界概念、アーキテクチャ、およびテクノロジーについて説明します。
このページは、Analytics Hubの一部です。完全なナビゲーションについては、次をご覧ください Analytics Hub — Analytics Accelerator Concepts — How-Tos (Runbook-Aligned)
これらの概念を理解することは、EDBのアナリティクスアクセラレーターが実証済みのパターンに基づいてどのように構築されているかを理解するのに役立ちます。 EDBがこれらのアイデアを実装する方法については、 Analytics Accelerator Concepts にアクセスしてください。
アーキテクチャ#
データウェアハウス#
内容 構造化されたSQLベースの分析用に最適化された一元化リポジトリ。これらはスキーマオンライトを使用し、高速な分析クエリー用に設計されています。
理由 ビジネスインテリジェンスチームは、レポートと履歴分析のために信頼できる一貫したデータを必要としています。
方法 データは、ETLプロセスを介して、強い型付けと制約を使用してリレーショナルテーブルにロードされます。
使用する理由 既知の一貫したレポートニーズとデータ品質に対する強力なガバナンスに対応する高いパフォーマンスが必要な場合。
これが Analytics Accelerator Concepts に与える影響を学びます。
データレイク#
内容 生データ構造化、半構造化、非構造化のための柔軟なリポジトリ。スキーマオンリード。
理由 データレイクを使用すると、すべてのデータを低コストでネイティブ形式で保存できます。
方法 データはファイルとしてオブジェクトストレージS3、GCSなどにロードされます。多くの場合ParquetまたはORC形式で。
使用する理由 使用可能なすべてのデータを完全なユースケースを知る前にキャプチャし、後で柔軟な処理を実行する必要がある場合。
これが Analytics Accelerator Concepts に与える影響を学びます。
データレイクハウス#
内容 データレイクの柔軟性とデータウェアハウスのパフォーマンスと信頼性を組み合わせた最新のアーキテクチャ。
理由 組織は、大量のデータを移動せずに、データサイエンスとBIの両方に対応する1つのシステムを望んでいます。
方法 データは、構造、トランザクション、メタデータを追加するオープンテーブル形式を使用してレイクオブジェクトストレージに保存されます。
使用する理由 スケーラブルで低コストのストレージが必要だが、ACID保証と高パフォーマンスのクエリーも必要な場合。
Lakehouse architecture paper (Armbrust et al.)
これが Analytics Accelerator Concepts にどのような影響を与えるかを学びます。
主要テクノロジー#
カラムナストレージ形式#
内容 行ではなく列をまとめて保存するデータ形式。
理由 ほとんどの分析クエリは、列のサブセットにのみアクセスします。列を直接読み取ると、パフォーマンスが向上し、I/Oが削減されます。
方法 一般的な形式は Apache Parquet および Apache ORC で、圧縮と列プルーニングをサポートしています。
使用する理由 大規模で読み取り負荷の高い分析クエリを実行し、最大のスキャン速度が必要な場合。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
ベクトル化されたクエリエンジン#
内容 行ごとではなく列方向のバッチベクトルでデータを処理するクエリエンジン。
理由 カラムナバッチはCPUキャッシュ動作とSIMD命令と一致し、分析を大幅に高速化します。
方法 Apache DataFusion や Velox のようなエンジンは、ベクトル化された実行を実装します。
使用する理由 分析ワークロードがCPUバウンドであり、パフォーマンスが重要な場合。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
ストレージとコンピューティングの分離#
内容 コンピューティングクエリエンジンとストレージオブジェクトストレージが分離されたアーキテクチャ。
理由 これにより、それらを個別にスケーリングでき、コストとパフォーマンスを最適化できます。
方法 アナリティクスアクセラレーターのようなシステムは、データにオブジェクトストレージS3などを使用し、クエリにステートレスコンピューティングノードを使用します。
使用する理由 コンピューティングニーズがバーストまたは予測不能で、オーバープロビジョニングを回避したい場合。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
オープンテーブルフォーマット#
内容 データベース機能ACIDトランザクション、スキーマの進化をデータレイクに提供するフォーマット。
理由 オープンテーブル形式がないと、レイクデータはルーズファイルのセットです。構造とガバナンスが必要です。
方法
Apache Iceberg はメタデータレイヤーとマニフェストファイルを使用します
Delta Lake はトランザクションログを使用します delta-rs
Apache Hudi はストリームファースト更新に焦点を当てています
使用する理由 レイクベースのデータの強力なデータ管理が必要な場合。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
コアコンセプト#
OLAP / OLTP#
内容
OLAP 大規模なデータセットの分析クエリ集計、トレンド
OLTP 大容量、小規模トランザクション更新、挿入
理由 ワークロードが異なると、パフォーマンスプロファイルも異なります。
方法 OLAPは、カラム型ストレージとパラレル実行で最適化されます。 OLTPは、行ベースのストレージとトランザクション保証を使用します。
使用する理由 ワークロードの種類ごとに適切なアーキテクチャを選択するため。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
ETL / ELT#
内容
ETL 抽出、変換、ロード
ELT 抽出、ロード、変換レイクまたはウェアハウスで
理由 ELTは、最新のレイクハウスの大規模な生データを処理する機能を利用します。
方法 データはオブジェクトストレージにステージングされ、クエリエンジンまたはパイプラインを使用して変換されます。
使用する理由 データの取り込みを簡素化し、パイプラインをより柔軟にするため。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
データ階層化#
内容 アクセスパターンに基づいて、データをホット、ウォーム、コールドに分類します。
理由 すべてのデータが高速ストレージを必要とするわけではありません。コールドデータをより安価なストレージに移動すると、コストを節約できます。
方法 データはストレージタイプ高速SSD、オブジェクトストレージを超えて物理的に分離されます。
使用する理由 ストレージコストとパフォーマンスを最適化するため。
これが Analytics Accelerator Concepts でどのように使用されるかを見てください。
セマンティック検索#
内容 キーワードだけでなく、意味を理解する検索。
理由 ユーザーは、よりスマートな検索エクスペリエンスを期待しています。
方法 データはベクトル埋め込みとして表され、類似性検索を使用して比較されます。
使用する理由 AIと最新のアプリの検索アプリケーションをサポートするため。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
ベクター埋め込み#
内容 高次元空間におけるデータテキスト、画像、音声の数値表現。
理由 完全一致を超えた類似性比較を有効にします。
方法 FAISS 、 Pinecone 、および多くのMLモデルのようなライブラリ、および多くのMLモデルは、エンベディングを生成および使用します。
使用する理由 AI / MLの検索および取得タスク用。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
取得拡張生成RAG#
内容 LLMが回答する前に外部ソースからドキュメントを取得するAIパターン。
理由 LLM応答をより正確に、データに基づいたものにします。
方法 ベクトル検索は、関連するエンベディングを取得します。 LLMは、それらをプロンプトと組み合わせます。
使用する理由 AI駆動型アプリの事実の精度を向上させるため。
これが Analytics Accelerator Concepts でどのように使用されるかを確認してください。
追加の概念#
マルチエンジンの相互運用性#
内容 マルチプルのクエリエンジンがレイク内の共有データにアクセスできるアーキテクチャ。
理由 組織は柔軟性を求めています。さまざまなユースケースに応じたさまざまなツールSQLエンジン、データサイエンスノートブック、ストリーミングエンジン。
方法 オープンテーブルフォーマットIceberg、Delta Lakeはマルチエンジンアクセスを有効にします。
Sparkはデータを書き込みます→ Trino、Postgres Lakehouse、および他のエンジンがそれを照会できます。
PGDデータをオフロード→Lakehouseクラスターと外部エンジンが分析できます。
使用する場合 ベンダーロックインなしで柔軟なデータアーキテクチャを構築します。
データの鮮度とレイテンシー#
内容 湖に着くとすぐに、最小限の遅延でデータを照会する機能。
理由 ビジネスユーザーは、新しいデータへのほぼリアルタイムのアクセスをますます期待しています。
方法 Lakehouseアーキテクチャはこれをサポートしています。
ELTパイプラインは、レイクデータを継続的に更新できます。
オープンテーブルフォーマットは、アトミックコミットとトランザクションの可視性をサポートしています。
ベクトル化されたLakehouseエンジンは、更新されたデータをすぐに照会できます。
使用する場合 完全なウェアハウスETLサイクルを必要とせずに、業務データまたはストリーミングデータの分析。
次に探索する#
Analytics How-To Guides