JindoCube の使用

JindoCube は、E-MapReduce（EMR）V3.24.0 以降でサポートされています。このトピックでは、EMR で JindoCube をインストール、デプロイ、および使用する方法について説明します。

前提条件

テーブルまたはビューが作成されていること。

概要

JindoCube は、EMR Spark の高度な機能です。事前計算を実装してデータ処理を高速化します。クエリのパフォーマンスを数十倍、場合によっては数百倍向上させます。ビューのデータを、HDFS や Object Storage Service（OSS）など、EMR Spark でサポートされているデータソースに永続化できます。EMR Spark は、使用可能な永続データを自動的に検出し、データの実行プランを最適化します。このプロセスはユーザーには完全に透過的です。 JindoCube は、固定クエリモードが使用されるビジネスシナリオに適用されます。 JindoCube は、データクエリを高速化するために、データを事前計算および事前編成します。たとえば、JindoCube を使用して、多次元オンライン分析処理（MOLAP）の実装、データレポートの生成、データダッシュボードの作成、クラスター間のデータの同期を行うことができます。

JindoCube のインストールとデプロイ

JindoCube は、EMR Spark の高度な機能です。 JindoCube を使用すると、EMR Spark を使用して送信されるすべての Dataset、DataFrame API、および SQL タスクを高速化できます。追加のコンポーネントのデプロイやメンテナンスは必要ありません。

Spark Web UI で JindoCube を管理する。

Spark Web UI で JindoCube を管理できます。たとえば、JindoCube キャッシュの作成、削除、更新ができます。 JindoCube キャッシュを作成すると、クラスター内のすべての Spark クエリが自動的に高速化されます。 [spark.sql.cache.tab.display] パラメーターを使用して、Spark Web UI に [Cube Management] タブを表示するかどうかを指定できます。このパラメーターは、EMR コンソールの Spark サービスの構成ページ、または Spark タスク送信コマンドで指定できます。このパラメーターのデフォルト値は [false] です。 Spark_UI

また、[spark.sql.cache.usedatabase] パラメーターを使用して、ビジネス要件に基づいてデータベースを作成し、キャッシュを作成するビューをこのデータベースに格納することもできます。パーティションテーブルを使用する場合は、[spark.sql.cache.cachebypartition] パラメーターを使用して、パーティションごとにデータをキャッシュするかどうかを指定できます。

パラメーター	説明	例
spark.sql.cache.tab.display	[Cube Management] タブを表示するかどうかを指定します。	true
spark.sql.cache.useDatabase	キューブが格納されるデータベース。	db1,db2,dbn
spark.sql.cache.cacheByPartition	パーティションごとにキューブを格納するかどうかを指定します。	true

Spark クエリの最適化。
[spark.sql.cache.queryrewrite] パラメーターを使用して、JindoCube キャッシュを使用して Spark クエリを高速化するかどうかを指定できます。このパラメーターは、クラスター、セッション、または SQL ステートメントレベルで指定できます。デフォルト値は [true] です。

JindoCube キャッシュを作成する。

Alibaba Cloud アカウントを使用して、Alibaba Cloud EMR コンソールにログインします。
[クラスター管理] タブをクリックします。
JindoCube キャッシュを作成するクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションペインで、[接続文字列] をクリックします。
[パブリック接続文字列] ページで、YARN UI のリンクをクリックして、Knox ユーザーとして YARN Web UI に移動します。
Knox の詳細については、「Knox」をご参照ください。
ApplicationMasterアプリケーションの種類SPARK[name] が [thrift JDBC/ODBC Server] で、がである行のをクリックします。
Spark Web UI で、[cube Management] タブをクリックします。

[new Cache] をクリックします。

テーブルまたはビューを選択し、アクション列で [raw cache] または [cube cache] をクリックします。次の 2 種類のキャッシュを作成できます。

Raw キャッシュ: キャッシュ構成に基づいてテーブルまたはビューのデータを永続化します。

Raw キャッシュを作成する場合は、次の表に示すパラメーターを指定します。

パラメーター	説明	必須
キャッシュ名	キャッシュの名前。名前には、文字、数字、ハイフン（-）、アンダースコア（_）のみを含めることができます。	はい
列セレクター	データをキャッシュする列。	はい
書き換え	後続のクエリの実行プランの最適化にキャッシュを使用するかどうかを指定します。	はい
プロバイダー	キャッシュデータのストレージ形式。このパラメーターは、JSON、Parquet、ORC など、Spark でサポートされている形式に設定できます。	はい
パーティション列	データがキャッシュされるパーティションフィールド。	いいえ
ZOrder 列	データをフィルタリングするために使用される Z オーダー列。Z オーダーは複数列のソート方法です。キャッシュされたデータがこの方法でソートされると、Spark クエリ中に Z オーダー列に基づいてデータがフィルタリングされます。これにより、Spark クエリがさらに高速化されます。	いいえ

Cube キャッシュ: テーブルまたはビューの生データに基づいてキューブを構築し、キューブデータを永続化します。

Cube キャッシュを作成する場合は、次の表に示すパラメーターを指定します。

パラメーター	説明	必須
キャッシュ名	キャッシュの名前。名前には、文字、数字、ハイフン（-）、アンダースコア（_）のみを含めることができます。	はい
ディメンションセレクター	キューブの構築に使用されるディメンションフィールド。	はい
メジャーセレクター	キューブの構築に使用されるメジャーフィールドと事前計算関数。	はい
書き換え	後続のクエリの実行プランの最適化にキャッシュを使用するかどうかを指定します。	はい
プロバイダー	キャッシュデータのストレージ形式。このパラメーターは、JSON、Parquet、ORC など、Spark でサポートされている形式に設定できます。	はい
パーティション列	データがキャッシュされるパーティションフィールド。	いいえ
ZOrder 列	データをフィルタリングするために使用される Z オーダー列。Z オーダーは複数列のソート方法です。キャッシュされたデータがこの方法でソートされると、Spark クエリ中に Z オーダー列に基づいてデータがフィルタリングされます。これにより、Spark クエリがさらに高速化されます。	いいえ

JindoCube は、指定されたディメンションとメジャーに基づいてキューブを構築します。次の SQL ステートメントは、前の図の Cube キャッシュの構成を示しています。

SELECT c_city, c_nation, c_region, MAX(lo_quantity), SUM(lo_tax)
FROM lineorder_flatten
GROUP BY c_city, c_nation, c_region;

JindoCube は、ディメンションの最も細かい組み合わせを計算します。Spark のオンサイトコンピューティング機能を搭載した JindoCube は、再集計を実装して、粗い組み合わせのディメンションが使用されるクエリを最適化します。Cube キャッシュを定義するには、JindoCube でサポートされている事前計算関数を使用する必要があります。次の表に、サポートされている事前計算関数とそれに対応する集計関数を示します。

集計関数	事前計算関数
COUNT	COUNT
SUM	SUM
MAX	MAX
MIN	MIN
AVG	COUNT and SUM
COUNT (DISTINCT)	PRE_COUNT_DISTINCT
APPROX_COUNT_DISTINCT	PRE_APPROX_COUNT_DISTINCT

作成されたすべてのキャッシュは、[cube Management] タブに表示されます。キャッシュの [detail] をクリックすると、基本情報、パーティション情報、ビルド情報、ビルド履歴など、詳細を表示できます。

JindoCube キャッシュをビルドする。

キャッシュの作成中にメタデータは準備されますが、データは永続化されません。したがって、キャッシュを作成した後、キャッシュのビルドを続行する必要があります。これにより、関連データを HDFS や OSS などの永続ストレージに永続化できます。また、キャッシュのソーステーブルに新しいデータが追加されたり、更新されたりする可能性があります。この場合、データの整合性を確保するために、キャッシュ内のデータを更新する必要があります。次のいずれかの方法を使用してキャッシュをビルドできます。

キャッシュを手動でビルドする

[Build Cache] をクリックして、キャッシュを手動でビルドします。表示されるページで、次の図に示すようにパラメーターを構成します。

次の表にパラメーターを示します。

パラメーター

説明

保存モード

次のモードがサポートされています。

上書き: キャッシュ内の既存のデータを上書きします。
追加: キャッシュに新しいデータを追加します。

オプションフィルター

このパラメーターを選択して、フィルター条件を追加できます。これにより、JindoCube はデータを永続化する前に、フィルター条件に基づいてデータをフィルタリングします。

列: データのフィルタリングの基準となるフィールド。
フィルタータイプ: 固定値または値の範囲でデータをフィルタリングするかどうかを指定します。
- 固定値: このオプションを選択した場合は、1 つ以上の値を指定します。値はカンマ（,）で区切ります。
- 範囲値: このオプションを選択した場合は、最小値と最大値を指定します。最大値は空のままにすることができます。この場合、値の範囲は最小値とそれより大きいすべての値です。

次の SQL ステートメントは、前の図の lineorder_flatten ビューの Raw キャッシュの構成を示しています。

SELECT * FROM lineorder_flatten
WHERE s_region == 'ASIA' OR s_region == 'AMERICA';

[送信] をクリックして、キャッシュビルドタスクを Spark クラスターに送信します。タスクの状態は、キャッシュ詳細ページの [ビルド情報] セクションで確認できます。タスクが完了したら、[ビルド履歴] セクションでキャッシュ情報を確認できます。

説明 Spark は、一般的な Spark タスクがテーブルまたはディレクトリにデータを書き込むのと同じ方法で、キャッシュされたデータを指定されたディレクトリに書き込みます。複数のユーザーがデータ形式が Parquet、JSON、または ORC のキャッシュを同時にビルドすると、キャッシュされたデータが不正確になったり無効になったりする可能性があります。同時キャッシュビルド操作または更新が避けられない場合は、Delta など、同時書き込みをサポートするデータ形式を使用することをお勧めします。

定期的なキャッシュビルドを構成する

[Trigger Period Build] をクリックして、定期的なキャッシュ更新ポリシーを構成し、キャッシュとソーステーブル間のデータの整合性を確保します。表示されるページで、次の図に示すようにパラメーターを構成します。

次の表にパラメーターを示します。

パラメーター	説明
保存モード	次のモードがサポートされています。上書き: キャッシュ内の既存のデータを上書きします。追加: キャッシュに新しいデータを追加します。
トリガー戦略	最初のビルドタスクの開始時刻とビルド間隔を指定します。開始日時: 最初のビルドタスクをトリガーする日時を選択または入力します。形式: yyyy-MM-dd hh:mm:ss。期間: キャッシュビルドタスクがトリガーされる間隔を指定します。
オプションステップ	キャッシュビルドのフィルター条件を指定します。JindoCube は、フィルター条件と間隔に基づいて、増分モードでキャッシュを更新します。[オプションステップ] を選択しない場合、JindoCube は毎回キャッシュ全体を更新します。ステップバイ: 増分モードで更新するフィールドのタイプを指定します。[TimeStamp Column(Long Type)] は LONG タイプのタイムスタンプフィールドを示します。[DateTime Column(String Type)] は STRING タイプの日時フィールドを示します。列名: 増分モードで更新するフィールドの名前を指定します。

キャッシュ詳細ページで、構成済みのキャッシュ更新ポリシーを表示できます。[Cancel Period Build] をクリックすると、定期的な更新をキャンセルできます。完了したビルドタスクの情報は、[ビルド履歴] セクションで確認できます。

説明

定期的なビルドタスクは Spark クラスターで実行されます。関連する構成はすべて SparkContext に保存され、タスクは Spark Driver によって定期的にトリガーされます。Spark クラスターを解放すると、定期的なビルドは無効になります。
[ビルド履歴] セクションには、現在の Spark クラスター内の完了した各タスクの次の情報が表示されます: 開始時刻、終了時刻、保存モード、ビルド条件、最終ステータス。Spark クラスターを解放すると、[ビルド履歴] セクションの情報はクリアされます。

JindoCube キャッシュを管理する。
JindoCube キャッシュを作成してビルドした後、[Cube Management] ページで管理できます。
- キャッシュを削除する
  [Cube Management] ページで、削除するキャッシュを見つけ、アクション列の [drop] をクリックします。キャッシュのすべてのメタデータとデータが削除されます。
- Spark クエリの最適化を有効化/無効化する
  JindoCube では、キャッシュレベルで Spark クエリの最適化を行うかどうかを指定できます。キャッシュの詳細ページで、[基本キャッシュ情報] セクションの下部にある [enabled] または [disabled] をクリックして、最適化を有効または無効にします。
- キャッシュからパーティションデータを削除する
  キャッシュ内のデータがパーティションごとに格納されている場合、不要なパーティションデータをキャッシュから削除して、スペースを解放できます。キャッシュの詳細ページで、データを削除するパーティションを見つけ、[アクション] 列の [削除] をクリックします。
  説明パーティションのデータを削除する前に、データが不要になったことを確認してください。後続のクエリに必要なデータを削除すると、クエリは無効な結果を返します。
Spark クエリの最適化。
JindoCube は、ビューベースのクエリを最適化します。ビューの Raw キャッシュまたは Cube キャッシュを作成した後、EMR Spark はこのビューに対するクエリの実行プランを上書きします。新しい実行プランは元の論理セマンティクスを引き続き使用しますが、キャッシュ内のデータに直接アクセスできます。これにより、Spark クエリが高速化されます。lineorder_flatten ビューを例にとります。これは、lineorder テーブルを他のディメンションテーブルに関連付けることによって生成されるワイドテーブルビューです。次の図は、このビューに関する情報を示しています。
次の図は、lineorder_flatten ビューに対する単純なクエリの実行プランを示しています。
lineorder_flatten ビューの Raw キャッシュを作成してビルドした後、同じクエリがビューに対して実行されます。EMR Spark は、キャッシュを自動的に使用して、元の実行プランを最適化します。次の図は、新しい実行プランを示しています。
新しい実行プランは、lineorder_flatten ビューの計算ロジックを使用しなくなりました。代わりに、HDFS 内のキャッシュデータに直接アクセスします。

使用上の注意

JindoCube は、キャッシュとソーステーブル間のデータの整合性を保証しません。データの整合性に関する要件に基づいて、データの更新を手動でトリガーするか、定期的な更新ポリシーを構成する必要があります。
JindoCube は、ビューのメタデータに基づいて、キャッシュを使用して実行プランを最適化するかどうかを判断します。JindoCube が実行プランを最適化する際にキャッシュデータが不完全な場合、クエリ結果が無効または不完全になる可能性があります。次の操作または構成により、キャッシュデータが不完全になる可能性があります。1. キャッシュ詳細ページで、後続のクエリに必要なパーティションデータを削除する。2. キャッシュのビルドまたは更新時に指定されたフィルター条件に基づいて、後続のクエリに必要なデータが除外される。3. クエリの実行時に、必要なデータがキャッシュに更新されていない。