事前定義された値セットに基づくセグメンテーションを発見する#

#目的

選択した値のセットに対してアクションを実行し、同時にそれらに基づいてセグメンテーションを行うことができます。

使用例：

• 特定のショッピングサイトやアイテムのプリセットに基づいてセグメンテーションを行う
• ビジネスルールAをデータセットAに対して集約アクションAで適用し、ビジネスルールBをデータセットBに対して集約アクションBで適用する

#必要条件

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

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

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

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

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

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

Data Processing Engine (DPE) が良好に動作するように、500を超えるタスクを持つステージを作成することはお勧めしません。

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

#互換性

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

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

以下に、表示モードと高度なJSONモードの違いを簡単にご紹介します。

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

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

事前定義されたセット / values: フィルタリングするためのハードコードされた値のセット。

#その他のヒント

#SQL式を使用できます

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

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

{
  "segmentation": {
    "active": true,
    "type": "predefined_set",
    "var_name": "DATE(datetime)",
    "values": ["2020-01-01","2020-01-02"]
    "chunksize": 1
  }
}

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

このセグメンテーションモードは、プロジェクトテーブルの属性に基づくセグメンテーションと同じように動作します。唯一の違いは、値が設定に既に設定されていることであり、Lakehouse Managerテーブル属性ではなく、プレステージが必要ないことです。

#さらに詳しく

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

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

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

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