Analytics Accelerator generic concepts#
このハブでは、最新のデータ分析プラットフォームの基盤を形成する主要な業界の概念、アーキテクチャ、テクノロジーについて説明します。
これらの概念を理解することで、EDBのアナリティクス・アクセラレータが実証済みのパターンに基づいてどのように構築されているかを理解するのに役立ちます。EDBがこれらのアイデアをどのように実装しているかについては、 Analytics Accelerator concepts をご覧ください。
アーキテクチャ#
データウェアハウス#
概要: 構造化されたSQLベースの分析に最適化された集中型リポジトリ。スキーマオンライトを採用し、高速な分析クエリ向けに設計されています。
理由: ビジネス インテリジェンス チームには、レポート作成や履歴分析を行うための信頼できる一貫性のあるデータが必要です。
方法: データは、ETL プロセスを通じて、強力な型指定と制約を持つリレーショナル テーブルにロードされます。
使用する理由: 既知の一貫性のあるレポートのニーズに対応できる高いパフォーマンスと、データ品質に対する強力なガバナンスが必要な場合。
これが EDB Postgres Lakehouse にどのような影響を与えるかを学びます。
データレイク#
内容: 生データ（構造化データ、半構造化データ、非構造化データ）用の柔軟なリポジトリ。読み取り時にスキーマを実行します。
理由: データ レイクを使用すると、すべてのデータをネイティブ形式で低コストで保存できます。
方法: データはファイルとしてオブジェクト ストレージ (S3、GCS など) にロードされます。多くの場合、形式は Parquet または ORC です。
使用する理由: ユースケースの全セットを把握する前であっても、利用可能なすべてのデータをキャプチャし、後で柔軟な処理を実行する必要がある場合。
これが EDB Postgres Lakehouse にどのような影響を与えるかを学びます。
データレイクハウス#
概要: データ レイクの柔軟性とデータ ウェアハウスのパフォーマンスおよび信頼性を組み合わせた最新のアーキテクチャ。
理由: 組織は、大量のデータを移動することなく、データ サイエンスと BI の両方に 1 つのシステムを必要としています。
方法: データは、構造、トランザクション、メタデータを追加するオープン テーブル形式を使用してレイク (オブジェクト ストレージ) に保存されます。
使用する理由: スケーラブルで低コストのストレージが必要であり、ACID 保証と高パフォーマンスのクエリも必要な場合。
Lakehouse architecture paper (Armbrust et al.)
これが EDB Postgres Lakehouse にどのような影響を与えるかを学びます。
主要技術#
列指向ストレージ形式#
概要: 行ではなく列をまとめて保存するデータ形式。
理由: ほとんどの分析クエリは列のサブセットにのみアクセスします。列を直接読み取ることでパフォーマンスが向上し、I/O が削減されます。
方法: 一般的な形式は、圧縮と列プルーニングをサポートする Apache Parquet と Apache ORC です。
使用する理由: 大規模で読み取り負荷の高い分析クエリを実行し、スキャン速度を最大限に高めたい場合。
EDB Postgres Lakehouse でこれがどのように使用されるかを確認してください。
ベクトル化されたクエリエンジン#
概要: 行ごとではなく列のバッチ (ベクトル) でデータを処理するクエリ エンジン。
理由: 列形式のバッチは CPU キャッシュの動作と SIMD 命令に一致するため、分析が大幅に高速化されます。
方法: Apache DataFusion や Velox などのエンジンはベクトル化された実行を実装します。
使用する理由: 分析ワークロードが CPU に依存しており、パフォーマンスが重要である場合。
ベクトル化されたクエリの最適化 でこれがどのように使用されるかを確認してください。
ストレージとコンピューティングの分離#
概要: コンピューティング (クエリ エンジン) とストレージ (オブジェクト ストレージ) が分離されたアーキテクチャ。
理由: これにより、個別にスケーリングして、コストとパフォーマンスを最適化できます。
方法: Analytics Accelerator などのシステムは、データにはオブジェクト ストレージ (S3 など) を使用し、クエリにはステートレス コンピューティング ノードを使用します。
使用する理由: コンピューティングのニーズが急増したり予測不能になったりして、過剰なプロビジョニングを避けたい場合。
EDB Postgres Lakehouse でこれがどのように使用されるかを確認してください。
オープンテーブル形式#
概要: データベース機能 (ACID トランザクション、スキーマの進化) をデータ レイクに提供する形式。
理由: オープンテーブル形式がなければ、レイクデータはばらばらのファイルの集合体となってしまいます。そのため、構造化とガバナンスが必要です。
どうやって：
Apache Iceberg はメタデータ レイヤーとマニフェスト ファイルを使用します
Delta Lake はトランザクション ログを使用します ( delta-rs )
Apache Hudi はストリームファーストアップデートに重点を置いています
使用する理由: レイクベースのデータに対する強力なデータ管理が必要な場合。
EDB Postgres Lakehouse でこれがどのように使用されるかを確認してください。
コアコンセプト#
OLAP / OLTP#
何：
OLAP: 大規模データセットに対する分析クエリ（集計、傾向）
OLTP: 大容量、小規模なトランザクション（更新、挿入）
理由: ワークロードによってパフォーマンス プロファイルが異なります。
方法: OLAP は列ベースのストレージと並列実行によって最適化されます。OLTP は行ベースのストレージとトランザクション保証を使用します。
使用理由: ワークロードの種類ごとに適切なアーキテクチャを選択するため。
高度なクエリ最適化 でこれがどのように使用されるかを確認してください。
ETL/ELT#
何：
ETL: 抽出、変換、ロード
ELT: 抽出、ロード、変換 (レイクまたはウェアハウス内)
理由: ELT は、大規模な生データを処理する最新のレイクハウスの機能を活用します。
方法: データはオブジェクト ストレージにステージングされ、クエリ エンジンまたはパイプラインを使用して変換されます。
使用する理由: データの取り込みを簡素化し、パイプラインの柔軟性を高めます。
Analytics Accelerator concepts でこれがどのように使用されるかを確認してください。
データ階層化#
概要: アクセス パターンに基づいてデータをホット、ウォーム、コールドに分類します。
理由: すべてのデータに高速ストレージが必要なわけではありません。コールド データを安価なストレージに移動すると、コストを節約できます。
方法: データはストレージ タイプ (高速 SSD、オブジェクト ストレージ) 間で物理的に分離されます。
使用理由: ストレージコストとパフォーマンスを最適化するため。
Analytics Accelerator concepts でこれがどのように使用されるかを確認してください。
セマンティック検索#
内容: キーワードだけでなく意味を理解する検索。
理由: ユーザーはよりスマートな検索エクスペリエンスを期待しています。
方法: データはベクトル埋め込みとして表現され、類似性検索を使用して比較されます。
使用理由: AI および最新のアプリでの検索アプリケーションをサポートするため。
Analytics Accelerator concepts でこれがどのように使用されるかを確認してください。
ベクトル埋め込み#
概要: 高次元空間におけるデータ (テキスト、画像、音声) の数値表現。
理由: 完全一致を超える類似性の比較を有効にします。
方法: FAISS 、 Pinecone などのライブラリや多くの 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 サイクルを必要とせずに、運用データまたはストリーミング データを分析します。