セグメンテーション「プロジェクトテーブルの属性に基づく」を発見する#

#目的

アクションは複数のタスクに分割されます。各タスクは、Lakehouse Managerの指定テーブルから選択した属性からの値の一部を管理します。

#要件

このセグメンテーションタイプを使用する前に、いくつかのポイントを確認する必要があります。

#1. ソーステーブルのvar_name属性はインデックス付けされていますか？

そうでない場合、抽出クエリは大幅に遅くなります。

#2. ソースおよび宛先データベースに十分なCPUがありますか？

• selectおよびinsert操作はCPU集約型です。
• 例えば、データベースにCPUが1つしかない場合、6つのワーカーを設定してDBMSインスタンスに対して同時に選択と挿入を行うのはおそらく良いアイデアではありません...

#3. 同じステージであまり多くのタスクを生成しないでください。

Data Processing Engine（DPE）が良好に動作するように、500を超えるタスクがあるステージを持つことは避けることをお勧めします。

これは厳密な制限ではありませんが、500を超えるタスクの数が増えるにつれてパフォーマンスの低下が観察されることがあります。 タスクの数を減らすには、バケットサイズを大きく設定して、各タスクがより多くの値を管理するようにすることができます（つまり、最終的にはタスクが少なくなります）。

#このタイプのセグメンテーションの使用方法

例として、aggregateアクションを、次のprim_ticketテーブルに対して使用し、dateごとにすべてのチケット収入を集計し、結果をテーブルagg_dateに挿入する場合を考えてみましょう。

このアクションの実行時間を最適化するために、ワークロードは各日付値に基づいて複数のタスクに分割されます。

#高度なパラメータの理解

さらに進む前に、PreferencesタブがAdvanced modeのJSONフィールドとどのように対応するかを説明します。 明確さのために、技術的なJSON名を以下に使用します。

ソースの属性 / var_name: ソースのフィルタリングに使用されるSQL属性。

参照属性 / Values: 値のセットが取得されるアドレス。 データセットテーブルからの場合は"dwh/TABLE_NAME/ATTRIBUTE_NAME"形式で指定する必要があります。 ソースからの場合は"dwh/SOURCE_NAME/TABLE_NAME/ATTRIBUTE_NAME"形式で指定する必要があります。

バケットサイズ / Chunksize: 各タスクでフィルタリングされる値の数。

#適切なセグメンテーション属性の選択

適切なセグメンテーション属性を選択することは、成功した高速なデータパイプラインの鍵です。良いセグメンテーション属性の特徴は次のとおりです。

#1. カーディナリティ

属性のカーディナリティは、ソーステーブルの行数に対してあまり高くない必要があります。

#2. 行の分布

理想的には、各値の行数の分布はほぼ等しくなる必要があります。

#3. 値は長いテキストではありません...

...そうでないとジョブコントローラーに負荷がかかります。

#4. aggregate, diff, delete_diffアクションの場合

そうでない場合、各グループのデータが不完全になる可能性があります。

例えば、ticket_idに基づくセグメンテーションを使用してdateごとに集計する場合、タスク1は最初のチケット収入を挿入し、次にタスク2は同じ日付内で発生したチケット2の収入で収入を更新します...

#5. 良い候補のヒント

• 事実の日付を説明する属性はしばしば良い候補です：
  • それはしばしばあなたの集計テーブルの主キーにあります
  • それは低いから中程度のカーディナリティを持つかもしれません
  • それは時間を通じて行の分布が比較的良いかもしれません
• 主要な参照テーブルの一部である属性も良い候補になることがあります。

#その他のヒント

#1. SQL式を使用できます

segmentation.values（属性の最後の部分）とsegmentation.var_nameの場合、DBMSと互換性のあるSQL式を使用できます。DBMSは時間の経過とともに変化する可能性があるため、それらのSQL式を使用することを決めた場合は、再確認して修正する必要があることをご了承ください。

例えば、次のようにすることができます：

"segmentation": 
{
   "active": true,
   "type": "dwh_attributes",
   "values": "dwh/default_dataset/tickets/DATE(datetime)",
   "var_name": "DATE(datetime)",
   "chunksize": 1
 }

#2. segmentation.valuesテーブルはソーステーブルと異なる場合があります

segmentation.valuesのセットがソーステーブルとは異なるテーブルに含まれている場合、アクションで使用されるソーステーブルとは異なるテーブルを指定できます。 これは、各回の計算を全テーブルに対して行わずに、いくつかの要素を絞り込むのに役立ちます。

例えば、segmentation.valuesは参照テーブルまたは一時テーブルから取得される場合があり、新しく入ってきたデータのみを管理できます。

#背景でどう動作するか？

アクションにプロジェクトテーブルの属性に基づくセグメンテーションがある場合、 アクションを実行するか、ワークフロー内のアクションを実行すると、次のように実行されます。

1. 隠しプリステージはsegmentation.valuesフィールドで指定されたtable/attributeのすべての異なる値を取得します。

1. ジョブコントローラーは、ステップ1で見つかった値の中から、各タスクで異なる値（またはchunksize構成に応じて値のセット）を持つ複数のタスクにアクションを分割します。
2. その後、各ワーカーがタスクを順番に実行します。 これは、タスクが何百もあっても問題ありません。アクションはワーカーの数に応じて並列化されます。

#技術的な説明

セグメンテーション構成の各部分がどのように使用されるかを正確に確認しましょう。 次のセグメンテーション構成を使用します。

{
    "segmentation": {
        "active": true,
        "type": "dwh_attributes",
        "values": "dwh/default_dataset/tickets/date",
        "var_name": "date",
        "chunksize": 1
    }
}

1. プリステージタスクはprim_ticketからすべての異なるdate値を取得し、segmentation.valuesアドレスを実際の値に置き換えます。 segmentation.valuesアドレスがどのように構築されるかを確認してください。 このアドレスは、アクションで実際に選択されたsource tableとは異なる場合があります。

2. ジョブコントローラーはsegmentation.valuesの長さとchunksize（各タスクが処理する必要がある値の数）に基づいてタスクを作成します。
3. 各ワーカーはタスクを順番に処理します。これは集計アクションの例です。注：segmentation.var_nameは抽出クエリのWHERE句でフィルタリングする属性として使用されます。したがって、segmentation.valuesで使用されるものとは異なる場合があります。

#さらに学ぶ

トレーニングや技術的なアシスタンスが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして見積もりを取得し、プロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼してください。

Data Platformを構築するチームと直接質問し、フィードバックを共有し、相互作用するには、専用のDiscordチャネルにアクセスしてください。

OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。

コミュニティに参加してください。