視商品目錄而定,可能需要進行資料分割 (或將動態饋給拆分成多個檔案)。
使用分片的時機
動態饋給的單一檔案 (經過 gzip 壓縮後) 超過 200 MB。
- 示例:產生的供應情形動態饋給為 1 GB。這個檔案應分片為 5 個以上的獨立檔案 (或分片)。
合作夥伴廣告空間分散在各個系統和/或區域,導致廣告空間難以比對。
- 範例:合作夥伴的美國和歐盟庫存在不同系統中。動態消息可能會產生 2 個檔案 (或分片),1 個用於美國,1 個用於歐盟,兩者具有相同的
nonce和generation_timestamp。
- 範例:合作夥伴的美國和歐盟庫存在不同系統中。動態消息可能會產生 2 個檔案 (或分片),1 個用於美國,1 個用於歐盟,兩者具有相同的
通則
- 每個分片不得超過 200 MB (經過 gzip 壓縮後)。
- 建議每個動態饋給最多使用 20 個分片。如有正當理由需要超過該金額,請與支援團隊聯絡,瞭解進一步的指示。
-
個別記錄 (例如一個
Merchant物件) 必須透過單一資料分片傳送,無法分割成多個資料分片。不過,不需要用同一個資料分片傳送多個記錄供日後的動態饋給使用。shard_number - 為提升效能,請將資料平均分配給資料分片,讓所有資料分片檔案的大小都相似。
如何分割動態饋給
針對每個檔案 (或分片),將 FeedMetadata 設為下列值:
processing_instruction設為PROCESS_AS_COMPLETE。shard_number設為動態饋給的目前分片 (從 0 開始,到total_shards- 1,不得中斷)total_shards設為動態消息的資料分割總數 (從 1 開始)。nonce,並設為專屬 ID,該 ID 在相同動態饋給的所有分片中相同,但與其他動態饋給的值不同。generation_timestamp是以 UNIX 和 EPOCH 格式表示的時間戳記。動態饋給的所有分片都應相同。
建議:為每個檔案 (或資料分割) 設定檔案名稱,指出動態饋給類型、時間戳記、資料分割編號,以及資料分割總數。資料分割的大小應大致相等,且會在所有資料分割上傳完畢後處理。
Example:“availability_feed_1574117613_001_of_002.json.gz”
分片供應情形動態消息範例
分片 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"
}
]
}
]
}資料分割 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"
}
]
}
]
}分片 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"
}
]
}
]
}使用分片功能處理合作夥伴分散式目錄
合作夥伴可能難以將分散在多個系統和/或區域的商品目錄整合到單一動態饋給。您可以將每個分片設為與每個分散式系統的廣告空間集相符,藉此解決對帳問題。
舉例來說,假設合作夥伴的廣告空間分為 2 個區域 (美國和歐盟廣告空間),且分別位於 2 個系統。
合作夥伴可將每個動態饋給分成 2 個檔案 (或分片):
- 商家動態饋給:美國 1 個資料分片,歐盟 1 個資料分片
- 服務動態饋給:美國 1 個資料分片,歐盟 1 個資料分片
- 預訂情形動態饋給:美國 1 個資料分片,歐盟 1 個資料分片
請按照下列步驟操作,確保動態饋給處理程序正常運作:
- 決定上傳時間表,並將每個商品目錄例項設定為遵循該時間表。
- 為每個執行個體指派不重複的 shard 編號 (例如:美國 = N,歐盟 = N + 1)。
將
total_shards設為分片總數。 - 在每個排定的上傳時間,決定
generation_timestamp和nonce。在FeedMetadata中,將所有例項的這兩個欄位都設為相同值。generation_timestamp應為目前或最近的過去時間 (理想情況下,應為合作夥伴的資料庫讀取時間戳記)
- 上傳所有分片後,Google 會透過
generation_timestamp和nonce將分片分組。
即使每個分片代表合作夥伴目錄的不同區域,且上傳時間可能不同,只要所有分片的 generation_timestamp 相同,Google 就會將動態饋給視為一個。
依區域分片的供應情形動態饋給範例
分片 0 - 美國廣告空間
{
"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"
}
]
}
]
}分片 1 - 歐盟廣告空間
{
"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"
}
]
}
]
}