Query DataSet タイル

​

はじめに

• ソケットタイムアウトエラー。大きなDataSetに対するクエリの応答に時間がかかりすぎる場合に発生します。
• メモリ不足エラー。単一のロードがCDWで処理するには大きすぎる場合（最大ヒープサイズの16 GBを超える場合など）に発生します。

• Query partition key — 結果セットをバッチに分割するために使用する列。
• # of Loads — 処理するバッチの数。

​

必要な許可

​

Query DataSet タイルにアクセスする

​

Query DataSet タイルを使用する

1. Query DataSet タイルを左側のActionsペインからオーサリングキャンバスにドラッグします。
2. Input DataSet メニューからDatabricks DataSetを選択します。
3. DataFlowに読み込む行を識別する SELECT ステートメントを記述します。
   注記： クエリは単一の SELECT である必要があります。共通テーブル式（CTE）はサポートされていません。
4. Query partition key を設定します。タイルが結果セットをバッチに分割するために使用する列を選択します。
   重要： パーティションキーの列に NULL 値が含まれていてはいけません。ガイダンスについては、「パーティションキーを選択する」を参照してください。
5. # of Loads を設定します。これは結果セットを分割するバッチの数です。推奨される上限については、「ロードのサイズを設定する」を参照してください。

​

パーティション分割の仕組みを理解する

​

ロードのサイズを設定する

1. テーブルの合計サイズを確認します。Databricksの UI を使用するか、次を実行します。
   DESCRIBE DETAIL <catalog>.<schema>.<table>;
   
2. sizeInBytes をGBに変換し、4 GBで割って、予備的な分割数を見積もります。
   divisions = (sizeInBytes / 2^30) / 4
   
   これは中間値です。すべてのパーティションキーの値に行が完全に均等に分布している場合にのみ、目的の # of Loads と等しくなりますが、そうなることはまれです。
3. テーブルの合計行数を取得します。
4. 単一の4 GBバッチの行数の上限を見積もります。
   max_rows = row_count / divisions
   
5. パーティションキーの候補列を選択します。 NULL 値が含まれていてはいけません。
6. 候補列の個別の値の数をカウントします。
   SELECT COUNT(DISTINCT <column>) AS distinct_count
   FROM <table>;
   
7. 候補列に沿ってテーブルがどの程度偏っているかを確認するため、候補列全体の行数の分布を調べます。
   SELECT <column>, COUNT(*) AS row_count
   FROM <table>
   GROUP BY <column>
   ORDER BY row_count DESC;
   
8. 最悪のケースの累計（行数の多いパーティションキーの値から順にバッチを満たすと仮定した場合の累積行数）を計算します。
   WITH grouped_counts AS (
     SELECT <column>, COUNT(*) AS row_count
     FROM <table>
     GROUP BY <column>
   )
   SELECT
     <column>,
     row_count,
     SUM(row_count) OVER (
       ORDER BY row_count DESC
       ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
     ) AS cumulative_row_count
   FROM grouped_counts
   ORDER BY row_count DESC;
   
   例えば、ある日付列をパーティションキーの候補として評価するとします。

   <column>	row_count	cumulative_row_count
   2024-10-13	100	100
   2024-02-21	80	180
   2024-05-17	60	240
   2024-08-19	50	290
   2024-03-06	30	320
   2024-02-10	20	340
   2024-11-30	10	350

9. 手順4の max_rows の上限内に収まる個別の値の数を求めます。
   WITH grouped_counts AS (
     SELECT <column>, COUNT(*) AS row_count
     FROM <table>
     GROUP BY <column>
   ),
   ranked_counts AS (
     SELECT
       <column>,
       row_count,
       SUM(row_count) OVER (
         ORDER BY row_count DESC
         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
       ) AS cumulative_row_count
     FROM grouped_counts
   )
   SELECT COUNT(*) AS max_column_values
   FROM ranked_counts
   WHERE cumulative_row_count < max_rows;
   
   max_rows を手順4で計算した値に置き換えます。
10. 最大のバッチを4 GB未満に保つために必要な最小の # of Loads を、切り上げて計算します。
    # of Loads >= distinct_count / max_column_values
    

​

パーティションキーを選択する

• NULL 値が含まれていない。これは必須です。パーティションキーの値が NULL である行はスキップされるためです。
• 個別の値が多い。これにより、結果セットを十分な数のバッチに分割し、各バッチをCDWの制限内に収めることができます。
• 個別の値ごとの行数が比較的均等に分布している。これにより、バッチサイズが予測可能になります。

​

関連記事

• Domo on Databricks
• Cloud Integrations Overview