Introduction ============ 分析アクセラレータの操作 ------------------------ アクセラレータはコンテンツを次の 4 つの領域に整理します。 - **概念の基礎** 分析の原則と EDB のアプローチについての理解を深めます。 - **EDB コア分析テクノロジー** 当社の分析サービスを強化する EDB ソリューションとテクノロジーについて学習します。 - **実用的なガイダンスとソリューション** ユースケース、ペルソナベースのガイド、ハウツー記事、チュートリアルを見つけます。 - **製品固有の実装** EDB Hybrid Manager などの EDB 製品でこれらの分析機能がどのように表示され、管理されるかについてのドキュメントにアクセスします。 概念的基礎 ---------- 最新のデータ分析と EDB のアプローチの背後にある原則と戦略を理解します。 - :ref:`Generic analytics concepts ` データ アーキテクチャ (データ ウェアハウス、データ レイク、レイクハウス) と基礎テクノロジー (列指向ストレージ、ベクトル化エンジンなど) について学習します。 - :ref:`EDB analytics concepts ` EDB の Postgres® 分析に関するビジョンと、EDB がコア テクノロジーをどのように活用しているかをご覧ください。 - :ref:`Explained: Analytics ` EDB の分析機能、設計上の選択肢、高度なトピックに関する詳細な説明を確認します。 *(近日公開)* EDBコア分析テクノロジー ----------------------- EDB の分析テクノロジーとそれが Postgres® をどのように拡張するかについて学びます。 - :ref:`EDB Postgres Lakehouse ` オブジェクト ストレージの分析を可能にするためのEDB Postgres® Lakehouse ソリューションとそのコンポーネントを確認します。 - :ref:`Apache Iceberg ` EDB ソリューションが Apache Iceberg を使用して大規模な分析データセットを管理する方法について理解します。 - :ref:`Delta Lake ` EDB Postgres® が Delta テーブルと連携して信頼性の高いデータ レイクを実現する方法について学習します。 - :ref:`EDB Postgres分散 (PGD) と階層化テーブル ` EDB Postgres Distributed (PGD) と Lakehouse 機能を使用してストレージ層全体でデータを管理し、コストとパフォーマンスを最適化します。 実践的なガイダンスと解決策 -------------------------- ニーズに合わせて EDB の分析機能を適用します。 - :ref:`Analytics Accelerator for your role: a persona-based guide ` DBA、DevOps エンジニア、データ サイエンティスト、アプリケーション開発者向けの学習パスに従ってください。 製品固有の実装 -------------- EDB 分析の概念とテクノロジーが EDB 製品にどのように実装されているかを確認します。 - :ref:`Introduction ` EDBハイブリッドマネージャーの分析機能に関するドキュメントをご覧ください。これには、HM Lakehouseクラスター、HMでのIceberg、Delta、階層化テーブルの使用、HM固有のチュートリアルが含まれます。 どこから始めるか ---------------- - コアとなる考え方を理解するには、 :ref:`Generic analytics concepts ` と :ref:`EDB Postgres Lakehouse ` から始めてください。 - 可能な場合は実用的なガイダンスを調べます。 - EDB Hybrid Manager を使用する場合は、製品固有のドキュメントを使用します。 Postgres Lakehouse は、さまざまなテクノロジーを使用して構築されています。 - PostgreSQL - `Seafowl `_ 、分析データベース - `Apache DataFusion `_ 、Seafowl で使用されるクエリ エンジン - `Delta Lake `_ (特に `delta-rs `_ ) は、デルタテーブルの保存および取得レイヤーを実装します。 レベル100 ^^^^^^^^^ Postgres Lakehouse について理解すべき最も重要な点は、ストレージとコンピューティングが分離されていることです。この設計により、ストレージとコンピューティングを独立してスケーリングできるため、クエリが予測不可能でスパイクが発生する分析ワークロードに最適です。接続されたハードドライブにデータを保持するためだけに、マシンをほぼアイドル状態にしておくのは望ましくありません。その代わりに、データをオブジェクトストレージ（しかも高度に圧縮可能な形式）に保存し、必要な時にクエリを実行するために必要なコンピューティングリソースのみをプロビジョニングできます。 .. figure:: /images/level-100.png :width: 70% :alt: Level 100 Architecture Level 100 Architecture コンピューティング側では、ベクトル化されたクエリ エンジンが Lakehouse テーブルをクエリするように最適化されていますが、完全な互換性のために Postgres にフォールバックします。 ストレージ側では、Lakehouse テーブルは分析用に最適化された、高度に圧縮可能な列指向ストレージ形式を使用して保存されます。 レベル200 ^^^^^^^^^ これらのサービスがどのように組み合わされているかを示す、もう少し包括的な図を以下に示します。 .. figure:: /images/level-200.png :width: 70% :alt: Level 200 Architecture Level 200 Architecture レベル300 ^^^^^^^^^ 以下は、「箱の中身」のより詳細な拡大図です。 .. figure:: /images/level-300.png :width: 70% :alt: Level 300 Architecture Level 300 Architecture