Pliki kanału z udziałem (starsza wersja)

W zależności od asortymentu może być konieczne podzielenie plików danych na kilka mniejszych plików.

Kiedy używać dzielenia na fragmenty

Rozmiar pliku danych przekracza 200 MB (po skompresowaniu za pomocą gzip).
- Przykład: wygenerowany plik danych o dostępności ma rozmiar 1 GB. Powinien być podzielony na co najmniej 5 osobnych plików (lub fragmentów).
Zasoby reklamowe partnera są rozproszone w różnych systemach lub regionach, co utrudnia ich uzgadnianie.
- Przykład: partner ma asortyment w Stanach Zjednoczonych i Unii Europejskiej, który znajduje się w osobnych systemach. Plik danych może być generowany z 2 plików (lub fragmentów): 1 dla Stanów Zjednoczonych i 1 dla Unii Europejskiej z tymi samymi wartościami nonce i generation_timestamp.

Ogólne zasady

Rozmiar każdego fragmentu nie może przekraczać 200 MB w przypadku 1 pliku (po skompresowaniu za pomocą gzip).
Zalecamy, aby każdy plik danych zawierał nie więcej niż 20 fragmentów. Jeśli masz uzasadnienie biznesowe, które wymaga większej kwoty, skontaktuj się z zespołem pomocy, aby uzyskać dalsze instrukcje.
Poszczególne rekordy (np. jeden obiekt Merchant) muszą być wysyłane w jednym fragmencie. Nie można ich dzielić na kilka fragmentów. Nie muszą być jednak wysyłane w tym samym fragmencie z tym samym shard_number w przypadku przyszłych plików danych.
Aby uzyskać lepszą wydajność, dane powinny być równomiernie rozdzielone między fragmenty, tak aby wszystkie pliki fragmentów miały podobny rozmiar.

Dzielenie plików danych na części

W przypadku każdego pliku (lub fragmentu) ustaw wartość FeedMetadata na:

processing_instructionustawiono na PROCESS_AS_COMPLETE.
shard_number ustawiony na bieżący fragment pliku danych (od 0 do total_shards – 1 bez przerw)
total_shards ustawiony na łączną liczbę fragmentów pliku danych (zaczynając od 1).
nonce ustawiony na unikalny identyfikator, który jest taki sam we wszystkich fragmentach tego samego pliku danych, ale różni się od wartości innych plików danych.
generation_timestamp to sygnatura czasowa w formacie systemu Unix i EPOCH. We wszystkich fragmentach pliku danych powinna być taka sama.

Zalecane: w przypadku każdego pliku (lub fragmentu) ustaw nazwę pliku tak, aby wskazywała typ pliku danych, sygnaturę czasową, numer fragmentu i łączną liczbę fragmentów. Fragmenty powinny mieć mniej więcej taki sam rozmiar i są przetwarzane po przesłaniu wszystkich fragmentów.

Example: “availability_feed_1574117613_001_of_002.json.gz”

Przykład pliku danych o dostępności we fragmentach

Fragment 0

{
  "metadata": {
    "processing_instruction": "PROCESS_AS_COMPLETE",
    "shard_number": 0,
    "total_shards": 3,
    "nonce": "111111",
    "generation_timestamp": 1524606581
  },
  "service_availability": [
    {
      "availability": [
        {
          "spots_total": 1,
          "spots_open": 1,
          "duration_sec": 3600,
          "service_id": "1000",
          "start_sec": 1577275200,
          "merchant_id": "merchant1",
          "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
        }
      ]
    }
  ]
}

Fragment 1

{
  "metadata": {
    "processing_instruction": "PROCESS_AS_COMPLETE",
    "shard_number": 1,
    "total_shards": 3,
    "nonce": "111111",
    "generation_timestamp": 1524606581
  },
  "service_availability": [
    {
      "availability": [
        {
          "spots_total": 1,
          "spots_open": 1,
          "duration_sec": 3600,
          "service_id": "1000",
          "start_sec": 1577620800,
          "merchant_id": "merchant2",
          "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
        }
      ]
    }
  ]
}

Fragment 2

{
  "metadata": {
    "processing_instruction": "PROCESS_AS_COMPLETE",
    "shard_number": 2,
    "total_shards": 3,
    "nonce": "111111",
    "generation_timestamp": 1524606581
  },
  "service_availability": [
    {
      "availability": [
        {
          "spots_total": 1,
          "spots_open": 1,
          "duration_sec": 3600,
          "service_id": "1000",
          "start_sec": 1576670400,
          "merchant_id": "merchant3",
          "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
        }
      ]
    }
  ]
}

Używanie podziału na fragmenty w przypadku rozproszonych zasobów reklamowych partnera

Konsolidacja asortymentu rozproszonego w wielu systemach lub regionach w jednym pliku danych może być dla partnerów trudna. Partycjonowanie może pomóc w rozwiązaniu problemów z uzgadnianiem, ponieważ każda partycja jest dopasowana do zestawu zasobów reklamowych każdego systemu rozproszonego.

Załóżmy na przykład, że zasoby reklamowe partnera są podzielone na 2 regiony (zasoby reklamowe w Stanach Zjednoczonych i w Unii Europejskiej), które znajdują się w 2 oddzielnych systemach.

Partner może podzielić każdy plik danych na 2 pliki (lub fragmenty):

Plik danych sprzedawcy: 1 fragment dla Stanów Zjednoczonych, 1 fragment dla UE
Plik danych o usługach: 1 fragment dla Stanów Zjednoczonych, 1 fragment dla UE
Plik danych o dostępności: 1 fragment dla Stanów Zjednoczonych, 1 fragment dla Unii Europejskiej

Aby mieć pewność, że pliki danych są przetwarzane prawidłowo, wykonaj te czynności:

Ustal harmonogram przesyłania i skonfiguruj każdą instancję asortymentu tak, aby była zgodna z tym harmonogramem.
Przypisz unikalne numery fragmentów do każdej instancji (np. Stany Zjednoczone = N, Europa = N + 1). Ustaw total_shards na łączną liczbę fragmentów.
W każdym zaplanowanym czasie przesyłania określ generation_timestamp i nonce. W sekcji FeedMetadata ustaw we wszystkich instancjach te same wartości w tych 2 polach.
- generation_timestamp powinna być bieżąca lub z niedalekiej przeszłości (najlepiej sygnatura czasowa z bazy danych partnera, która wskazuje, kiedy użytkownik przeczytał artykuł).
Po przesłaniu wszystkich fragmentów Google grupuje je za pomocą znaków generation_timestamp i nonce.

Google przetworzy plik danych jako jeden, mimo że każdy fragment reprezentuje inny region asortymentu partnera i może być przesyłany o innej porze dnia, o ile generation_timestamp jest taki sam we wszystkich fragmentach.

Przykład podzielonego pliku danych o dostępności według regionu

Shard 0 - US Inventory

{
  "metadata": {
    "processing_instruction": "PROCESS_AS_COMPLETE",
    "shard_number": 0,
    "total_shards": 2,
    "nonce": "111111",
    "generation_timestamp": 1524606581
  },
  "service_availability": [
    {
      "availability": [
        {
          "spots_total": 1,
          "spots_open": 1,
          "duration_sec": 3600,
          "service_id": "1000",
          "start_sec": 1577275200,
          "merchant_id": "US_merchant_1",
          "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
        }
      ]
    }
  ]
}

Shard 1 - EU Inventory

{
  "metadata": {
    "processing_instruction": "PROCESS_AS_COMPLETE",
    "shard_number": 1,
    "total_shards": 2,
    "nonce": "111111",
    "generation_timestamp": 1524606581
  },
  "service_availability": [
    {
      "availability": [
        {
          "spots_total": 1,
          "spots_open": 1,
          "duration_sec": 3600,
          "service_id": "1000",
          "start_sec": 1577620800,
          "merchant_id": "EU_merchant_1",
          "confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
        }
      ]
    }
  ]
}