メインコンテンツまでスキップ
に最終更新

Ingest data from LinkedIn Ads

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

LinkedIn Ads から Databricks にデータを取り込むための管理された取り込みパイプラインを作成する方法を学びます。

Requirements​

  • 取り込み パイプラインを作成するには、次の要件を満たす必要があります。

    • ワークスペースでUnity Catalogが有効になっている必要があります。

    • Serverless compute must be enabled for your workspace. See Serverless compute requirements.

    • 新しい接続を作成するには、メタストアに対する CREATE CONNECTION 権限が必要です。Unity Catalog での権限の管理を参照してください。

      コネクタが UI ベースのパイプライン オーサリングをサポートしている場合、管理者はこのページのステップを完了することで、接続とパイプラインを同時に作成できます。 ただし、パイプラインを作成するユーザーが API ベースのパイプライン オーサリングを使用している場合、または管理者以外のユーザーである場合、管理者はまずカタログ エクスプローラーで接続を作成する必要があります。 「管理対象取り込みソースへの接続」を参照してください。

    • 既存の接続を使用するには、接続オブジェクトに対する USE CONNECTION 権限または ALL PRIVILEGES 権限が必要です。

    • ターゲットカタログに対するUSE CATALOG権限が必要です。

    • You must have USE SCHEMA and CREATE TABLE privileges on an existing schema or CREATE SCHEMA privileges on the target catalog.

  • To ingest from LinkedIn Ads, you must complete the steps in Create a LinkedIn Ads connection.

  • You need the sponsored ad-account ID for each ad account you want to ingest. Eleven of the twelve source tables live in a per-account namespace named after that ID. See Source namespaces.

取り込みパイプラインを作成​

LinkedIn Ads supports API-based pipeline authoring only. Use Declarative Automation Bundles or the Pipelines REST API.

このtabでは、Declarative Automation Bundles を使用して取り込みパイプラインをデプロイする方法について説明します。バンドルにはジョブとタスクの YAML 定義を含めることができ、Databricks CLI を使用して管理され、異なるターゲット ワークスペース（開発、ステージング、本番運用など）で共有および実行できます。詳細については、「宣言型オートメーションバンドルとは？」をご覧ください。

  1. Databricks CLI を使用してバンドルを作成するには、次の手順を実行します。

    Bash
    databricks bundle init

  2. バンドルに2つの新しいリソースファイルを追加します：

    • パイプライン定義ファイル（例：resources/linkedin_ads_pipeline.yml）。
    • データ取り込みの頻度を制御するジョブ定義ファイル（例：resources/linkedin_ads_job.yml）。

    「pipeline.ingestion_definition」を参照してください。および「Examples」を参照してください。

  3. Databricks CLI を使用してパイプラインをデプロイします：

    Bash
    databricks bundle deploy

例​

The following examples show YAML specifications that Declarative Automation Bundles or the REST API can use to create pipelines.

Ingest all five entity tables from one ad account​

account_history テーブルは default 名前空間から取得されます。他の4つのエンティティテーブルは広告アカウント独自の名前空間から取得されるため、source_schema にスポンサー広告アカウントIDを設定してください。

YAML
resources:
  pipelines:
    pipeline_linkedin_ads:
      name: <pipeline-name>
      catalog: <destination-catalog>
      target: <destination-schema>
      ingestion_definition:
        connection_name: <connection-name>
        objects:
          - table:
              source_schema: default
              source_table: account_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: campaign_group_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: campaign_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: creative_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: account_user_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>

カスタム同期オプションを使用して構築済みのレポートを取り込む​

Each report takes its own settings from connector_options.linkedin_ads_options, which accepts sync_start_date (an ISO date string) and lookback_window_days (an integer from 0 to 365). Omit either key to take its default: a two-year start date and a seven-day lookback. Set the options per report, because each report tracks its own cursor.

All seven reports are per-account, so source_schema is always the sponsored ad-account ID.

YAML
resources:
  pipelines:
    pipeline_linkedin_ads_reports:
      name: <pipeline-name>
      catalog: <destination-catalog>
      target: <destination-schema>
      ingestion_definition:
        connection_name: <connection-name>
        objects:
          # Daily campaign report: backfill from an explicit date and widen the
          # lookback to 30 days so late-attributed conversions are re-read.
          - table:
              source_schema: <ad-account-id>
              source_table: ad_analytics_by_campaign_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              connector_options:
                linkedin_ads_options:
                  sync_start_date: '2026-01-01'
                  lookback_window_days: 30
          # Daily creative report: same start date, default seven-day lookback.
          - table:
              source_schema: <ad-account-id>
              source_table: ad_analytics_by_creative_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              connector_options:
                linkedin_ads_options:
                  sync_start_date: '2026-01-01'
          # Monthly demographic report: the start date is aligned to the first of
          # its month, so 2026-05-15 fetches all of May 2026.
          - table:
              source_schema: <ad-account-id>
              source_table: monthly_ad_analytics_by_member_industry_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              connector_options:
                linkedin_ads_options:
                  sync_start_date: '2026-05-15'
                  lookback_window_days: 45
          # Monthly demographic report with no options: defaults to a two-year
          # start date, capped by the two-year demographic retention horizon.
          - table:
              source_schema: <ad-account-id>
              source_table: monthly_ad_analytics_by_member_seniority_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>

Ingest from more than one ad account​

Because the per-account tables live in a namespace named after the ad-account ID, ingest a second account by repeating the table definitions with a different source_schema. Give each destination table a distinct name so the two accounts don't collide, because Databricks cannot ingest two tables with the same name in one pipeline.

YAML
resources:
  pipelines:
    pipeline_linkedin_ads_multi_account:
      name: <pipeline-name>
      catalog: <destination-catalog>
      target: <destination-schema>
      ingestion_definition:
        connection_name: <connection-name>
        objects:
          - table:
              source_schema: <first-ad-account-id>
              source_table: campaign_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              destination_table: campaign_history_account_1
          - table:
              source_schema: <second-ad-account-id>
              source_table: campaign_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              destination_table: campaign_history_account_2

パイプラインの起動、スケジュール、アラートの設定​

  1. パイプラインが作成されたら、Databricks ワークスペースに戻り、左側のペインで ジョブとパイプライン をクリックします。

    The new pipeline appears in the list. Click the pipeline name to view its details.

  2. On the pipeline details page, click Start to run the pipeline immediately. To run it on a schedule, click Schedule . For details, see Run a pipeline update.

  3. To set alerts on the pipeline, use the job that schedules it. From the pipeline details page, click Schedule , then select one of your schedules to show the job details.

  4. ジョブ詳細ペインの ジョブ通知 で、通知を設定します。ジョブに通知を追加するを参照してください。

  5. Monitor the pipeline update on the pipeline details page. After the update completes successfully, query your destination tables to confirm the data arrived.

その他のリソース​

このページの見出し