USER MANUALS

並列処理

Denodo のオプティマイザーは、さまざまな超並列処理 (MPP) システムとネイティブに統合して、多大な処理を必要とする特定のクエリを高速化します。

注釈

この機能は Denodo Standard では使用できません。「 Denodo Standard の制限事項 」も参照してください。

Denodo では、Hadoop に基づく以下の MPP システムとの統合がサポートされています。

  • Databricks

  • Impala バージョン 2.3

  • PrestoDB バージョン 0.1x

  • PrestoSQL バージョン 3xx

  • Spark バージョン 1.5、1.6、および 2.x

この最適化は、コストベースのオプティマイザーと連携し、最適化によって利点が得られる操作を検出します。Denodo で大量のデータを処理する必要があるクエリで、ストリーミングモードではその処理を実行できない場合に、そのクエリ処理が MPP エンジンにプッシュされます。これは、データを部分的にディスクにオフロードして、サーバーのリソースを使い切らないようにすることが必要な状況です。

オプティマイザーでは、MPP を使用するうえで適切な時期がクエリ単位で判断されます。この判断は、クエリで指定した操作のタイプ、ビューの統計情報、およびサーバーの構成に基づきます。最適化によって、以下のタイプの操作で利点が得られます。

  • 集計のように MPP で並列化できる操作

  • Denodo による後処理ではディスクへのスワップが発生する以下の操作

    • ハッシュ結合

    • Group By

    • Order By

    • DISTINCT

以下の例を考えます。

データソース DS1 に customer ビューがあり、行数は 1,000 万です。

2 つの基本ビューの和結合である sales ビューがあります。その基本ビューの 1 つは recent_sales で、最近の 1 年の売上を収めています。もう 1 つの基本ビューは old_sales で、それ以前の年の売上情報を収めています。 recent_sales 基本ビューは DS2 データソースにあり、その行数は 1 億です。 old_sales は DS3 データソースにあり、行数は 10 億です。これらの基本ビューには属性 customer_id があり、特定のセールで製品を購入した顧客を指定しています。したがって、顧客ごとの平均売上件数は約 110 です。

以下のクエリは顧客ごとの売上高を取得します。

SELECT c.id as CustomerId, SUM(s.amount) as TotalSales
FROM Customer c JOIN Sales s ON c.id = s.customer_id
GROUP BY c.id

Denodo オプティマイザーによって、集計のプッシュダウンによる最適化が適用されます。この最適化では、データソースごとに売上が集計され、データソースから返される行数が削減されます。

この最適化により、1,000 万件の顧客、および売上データベースごとに 1,000 万件ずつ、合計約 3,000 万行がネットワーク経由で転送されます。一方、Denodo では、1,000 万行の分岐と 2,000 万行の分岐の結合を実行して、その結合結果である 2,000 万行を集計する必要があります。この結合操作とグループ化操作では大量のデータを処理する必要があり、メモリの過剰な消費を避けるために、ディスクへのスワップが必要になります。

Parallel Processing: aggregation push down

並列処理: 集計のプッシュダウン

並列処理の最適化が有効な場合、クエリオプティマイザーでは、集計のプッシュダウンを適用した後、顧客データと集計した売上データを MPP エンジンに移動し、クラスタリソースを利用して結合と集計を実行します。

Parallel Processing: aggregation push down and parallel processing

並列処理: 集計のプッシュダウンと並列処理

キャッシュとしての MPP エンジンの使用

MPP エンジンの並列処理機能を利用すると同時に、同じ MPP エンジンを Denodo キャッシュとして使用できます。これにより、クエリの高速化を目的として MPP に移動したデータセットで、データのキャッシュ機能の利点を利用できます。

一定の状況では、Denodo 管理者が一部のデータベース向けにキャッシュシステムをセットアップし、一方でそれらのデータベースで MPP によるクエリの高速化を有効または無効にすることができます。

ここでは、このような動作を実現できるように Virtual DataPort サーバーを構成する方法を、2 つの例を引いて説明します。

  • サーバーのキャッシュで MPP を有効にし、いくつかの VDP データベースでは同じキャッシュを使用して MPP を無効にした構成。

    1. MPP エンジンを使用するようにサーバーのキャッシュを構成して、データソース設定で並列処理を有効にします。

    2. サーバー構成のクエリ最適化のセクションで並列処理を有効にして、キャッシュデータソースを選択します。

    3. VDP データベースで使用するキャッシュを、グローバルキャッシュではなく、そのデータベースと同じコネクションパラメータを使用するカスタムキャッシュデータソースとするように構成します。ただし、データソースの [Read & Write] 構成で MPP 移動は許可しないようにします (クエリの最適化設定で並列処理を選択しません)。

  • サーバーのキャッシュで MPP を有効にし、いくつかのデータベースでは別のキャッシュシステムを使用して、グローバルキャッシュへの MPP 移動も許可した構成。

    1. データソースを作成し、MPP へのコネクションパラメータを使用するように構成して、並列処理を有効にします。

    2. サーバーのキャッシュ構成で、そのデータソースをキャッシュデータソースとして選択します。

    3. サーバー構成のクエリ最適化のセクションで並列処理を有効にして、[Custom data source] オプションで上記と同じキャッシュデータソースを選択します。

    4. データベースは、サーバーとは別の、独自のデータソースを使用するキャッシュシステムを使用するように構成します。

CONTEXT 句による、MPP エンジンへのビューの強制移動

ビューに対するクエリの実行またはビューの作成で、 CONTEXT 句を使用して、MPP システムに移動するビューの名前を指定できます。データ移動を指定する句と同様の構文を使用しますが、コンテキストトークンの名前が MPPMOVEMENTPLAN である点が異なります。

この句を使用して 1 つまたは複数のビュー名を指定できます。また、クエリにビューを記述した箇所ごとに以下を指定できます。

  • (ON): MPP にビューを移動します。

  • (OFF): MPP へのビューの移動を無効にします。

  • (): このビューを記述した箇所では設定を指定しません。

SELECT c.id as CustomerId, SUM(s.amount) as TotalSales
FROM customer c JOIN sales s ON c.id = s.customer_id
GROUP BY c.id CONTEXT(MPPMOVEMENTPLAN = customer: (ON)  store_sales_oracle: (ON))
Add feedback