ワークフローで設定された日付範囲に基づくセグメンテーションを発見する#

#目的

よくある日常的な使用方法として、Data Processing Engine (DPE) のアクションを要求する際に、今日までの過去X日間のデータを管理する必要があります。

他の場合には、アクションが特定の歴史的な日付セットのみに作用するようにする必要があります。 このセグメンテーションタイプは基本的に、「テーブルの属性の値に基づくセグメンテーション」と同様に動作しますが、値はワークフロー設定で設定した日付から得られるものであり、Lakehouse Manager テーブルから得られるものではありません。

#使用例

• ソースからX日前から今日までのデータを取得する。（日次相対日付の使用）
• ソースから2つの正確な日付の間のデータを取得する。（歴史的データの取得、ワンショット使用）
• 2つの日付の間のみ集計テーブルを再計算する。（日次相対日付の使用またはワンショット使用）

ソースデータに日付属性が含まれている場合、アクションを別々のプロセスに分割し、各プロセスが特定の日付または日付グループに個別に対応させることができます。 この場合、各タスクは抽出する必要がある日付に対してフィルタを適用します。

#要件

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

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

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

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

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

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

Data Processing Engine (DPE) のパフォーマンスを維持するために、500タスクを超えるステージを設定しないことをお勧めします。

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

#互換性

このセグメンテーションオプションは、次のアクションとソースのみと互換性があります：

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

以下は、表示モードと高度なJSONモードの間のクイックビューです。

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

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

#その他のヒント

#SQL式を使用できます

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

例えば、以下のような式を使用できます：

"segmentation": 
{
   "active": true,
   "type": "workflow_dates",
   "var_name": "DATE(datetime)",
   "chunksize": 1
 }

#背景でどのように動作しますか？

このセグメンテーションモードは、プロジェクトテーブルの属性に基づくセグメンテーションと同様に動作します。唯一の違いは、値がワークフローの日付範囲から得られるものであり、Lakehouse Managerテーブルの属性から得られるものではないため、プレステージは必要ありません。

#さらに詳しく

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

Discordの専用チャネルでData Platformを構築するチームと直接質問し、フィードバックを共有し、交流してください。

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

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