<!-- Canonical URL: https://ask.atlascloud.ai/th/product-csv-recoverable-video-production-queue -->

# จะเปลี่ยน CSV สินค้าให้เป็นคิวผลิตวิดีโอที่กู้คืนได้อย่างไร?

> เปลี่ยนแต่ละแถวสินค้าให้เป็นงานที่มีเวอร์ชัน พร้อม ID คงที่ อินพุตที่ผ่านการตรวจสอบ สถานะชัดเจน บันทึกแต่ละความพยายาม และตำแหน่งเอาต์พุตถาวร คิวจะกู้คืนได้เมื่อ worker สามารถทำงานต่อหลังระบบล่มอย่างปลอดภัยโดยไม่สูญงานหรือสร้างวิดีโอเดิมซ้ำ

<!-- Canonical URL: https://ask.atlascloud.ai/product-csv-recoverable-video-production-queue -->

# จะเปลี่ยน CSV สินค้าให้เป็นคิวผลิตวิดีโอที่กู้คืนได้อย่างไร?

ไฟล์แคตตาล็อกคือข้อมูลอินพุต ไม่ใช่คิวการผลิต หากสคริปต์เพียงอ่านแถวที่ 17 เรียก API วิดีโอ และเขียน URL ลงคอลัมน์ถัดไป การล่มของเครื่องหรือ timeout จะทำให้ไม่สามารถตอบคำถามสำคัญสามข้อได้อย่างน่าเชื่อถือ ได้แก่ มีการขออะไร ผู้ให้บริการยอมรับหรือไม่ และสินทรัพย์ที่เสร็จแล้วถูกบันทึกหรือยัง

แนวทางที่ใช้ได้จริงคือเก็บ CSV เป็นการนำเข้าแบบเปลี่ยนแปลงไม่ได้ ขยายเป็นระเบียนงานถาวร และทำให้ทุกขั้นตอนของ worker ทำซ้ำได้อย่างปลอดภัย ระบบจึงหยุดได้หลังคำสั่งใดก็ได้และเริ่มต่อจากสถานะยืนยันล่าสุด แทนที่จะเริ่มทั้งชุดใหม่

## แยกข้อมูลแคตตาล็อกจากงานการผลิต

แถวสินค้าบรรยายสินค้า แต่งานวิดีโอบรรยายเอาต์พุตครีเอทีฟหนึ่งรายการที่ร้องขอ ทั้งสองเป็นคนละระเบียน เพราะสินค้าหนึ่งรายการสร้างชิ้นงานส่งมอบได้หลายชิ้น

สมมติว่าหนึ่งแถวมี ID สินค้า ชื่อ URL รูปภาพ ราคา หมวดหมู่ และคำอธิบายสั้น แผนการผลิตต้องการสอง hook สาม locale และสองอัตราส่วนภาพ แถวเดียวจึงขยายเป็นงานวิดีโอสิบสองงาน การแก้คำอธิบายสินค้าในภายหลังไม่ควรเปลี่ยนคำขอที่กำลังทำงานโดยไม่แจ้งให้ทราบ

จัดเก็บสามชั้น:

* การนำเข้าต้นฉบับ รวมแฮชไฟล์และเวลานำเข้า;
* snapshot สินค้าที่ปรับรูปแบบแล้วสำหรับรอบการผลิตนี้;
* หนึ่งงานต่อทุกชุดผสมของเทมเพลต locale อัตราส่วน และตัวแปร

การแยกนี้ทำให้การรันซ้ำเกิดขึ้นโดยตั้งใจ ไฟล์แคตตาล็อกใหม่สร้างเวอร์ชันนำเข้าใหม่ ขณะที่งานที่ไม่เปลี่ยนสามารถนำกลับมาใช้เมื่อ fingerprint อินพุตทั้งหมดตรงกัน

## ตรวจสอบ CSV ก่อนขยายงาน

การปฏิเสธอินพุตผิดก่อนเรียก API ถูกกว่าการวิเคราะห์ข้อผิดพลาดหลายแบบหลังปล่อยงานหลายร้อยงาน ตรวจ encoding คอลัมน์บังคับ รหัสสินค้าไม่ซ้ำ รูปแบบ URL และขีดจำกัดของเทมเพลตครีเอทีฟ

| การตรวจสอบ | ตัวอย่างข้อผิดพลาด | การดำเนินการของคิว |
|---|---|---|
| ID สินค้าคงที่ | SKU ว่างหรือซ้ำ | หยุดการนำเข้า |
| สื่อต้นทางที่จำเป็น | ไม่มีภาพหลัก | ทำเครื่องหมายแถวไม่ถูกต้อง |
| ความยาวข้อความ | คำอธิบายเกินขีดจำกัดเทมเพลต | ส่งไปตรวจคำโฆษณา |
| แหล่ง locale | รหัส locale ไม่รองรับ | ทำเครื่องหมายการขยายไม่ถูกต้อง |
| ข้อมูลตัวเลข | ราคามีข้อความที่ parse ไม่ได้ | ปรับรูปแบบหรือปฏิเสธ |
| การเข้าถึง URL | รูปภาพตอบกลับข้อผิดพลาด | ลองตรวจใหม่แล้วส่งตรวจ |

สร้างรายงานการตรวจสอบที่ระบุแถว ฟิลด์ ค่า และเหตุผล อย่าแก้ CSV ต้นฉบับเพื่อซ่อนปัญหา ไฟล์ที่แก้ไขควรมีแฮชใหม่และความสัมพันธ์ที่ติดตามได้กับการนำเข้าที่ถูกปฏิเสธ

## กำหนดตัวตนแบบกำหนดซ้ำได้ให้ทุกงาน

คิวที่กู้คืนได้ต้องมีตัวตนที่อยู่รอดจากการเรียงใหม่ การรีสตาร์ต worker และการนำเข้าซ้ำ หมายเลขแถว CSV ไม่เหมาะ เพราะเปลี่ยนทุกครั้งที่แทรกหรือจัดลำดับข้อมูล

สร้างออบเจ็กต์อินพุตมาตรฐานจากฟิลด์ที่กำหนดเอาต์พุตที่ร้องขอ:

```json
{
  "catalog": "spring-2027",
  "product_id": "SKU-1042",
  "template_version": "ugc-demo-v3",
  "locale": "en-US",
  "aspect_ratio": "9:16",
  "variant": "hook-b"
}
```

serialize ออบเจ็กต์โดยเรียงคีย์คงที่ แล้วคำนวณแฮช เก็บทั้งฟิลด์ที่อ่านได้และแฮช พร้อมตั้ง unique constraint บนคีย์งาน หากการขยายเดิมรันสองครั้ง ฐานข้อมูลจะคืนงานที่มีอยู่แทนการสร้างใหม่

เนื้อหาที่มีผลต่อเอาต์พุตต้องเป็นส่วนหนึ่งของตัวตน หาก prompt หรือภาพต้นทางเปลี่ยนโดยไม่เปลี่ยนเวอร์ชันเทมเพลต ให้รวมแฮชของสิ่งเหล่านั้น มิฉะนั้นระบบอาจนำผลลัพธ์เก่ากลับมาใช้ผิด

## สร้างแบบจำลองคิวด้วยสถานะที่ชัดเจน

ธง `done` เพียงค่าเดียวอธิบายไม่ได้ว่างานหยุดตรงไหน ใช้สถานะที่ตรงกับขอบเขตที่กู้คืนได้ในเวิร์กโฟลว์

| สถานะ | ความหมาย | การดำเนินการถัดไปที่ปลอดภัย |
|---|---|---|
| `ready` | อินพุตผ่านการตรวจสอบ | รับงาน |
| `leased` | worker ถือสิทธิ์ชั่วคราว | สร้างคำขอ |
| `submitting` | เตรียมคำขอแล้ว | ส่งพร้อม idempotency key หากรองรับ |
| `accepted` | ผู้ให้บริการคืน ID งาน | ตรวจสถานะ |
| `downloading` | เอาต์พุตพร้อมแล้ว | คัดลอกไปยังพื้นที่เก็บถาวร |
| `review` | มีสินทรัพย์และต้องตรวจ | ใช้กฎการตรวจ |
| `complete` | บันทึกสินทรัพย์ถาวรและ metadata แล้ว | ส่งมอบหรือส่งออก |
| `retry_wait` | เกิดข้อผิดพลาดชั่วคราว | ทำต่อหลัง backoff |
| `needs_attention` | ต้องใช้การตัดสินใจของมนุษย์ | แสดงบริบทแก่ผู้ปฏิบัติงาน |

บันทึก ID งานของผู้ให้บริการทันทีเมื่อยืนยันการยอมรับ Timeout ระหว่างส่งมีผลลัพธ์ไม่แน่นอน จึงต้องเก็บความพยายามในสถานะที่ตรวจสอบย้อนหลังได้ แทนการสันนิษฐานว่าไม่มีอะไรเกิดขึ้น

## ใช้ lease แทน lock ถาวร

worker ควรรับงานเป็นช่วงเวลาจำกัด เก็บเจ้าของ lease และเวลาหมดอายุในการอัปเดตแบบ atomic เดียวกับที่เปลี่ยนงานจาก `ready` เป็น `leased` worker อื่นรับงานได้หลัง lease หมดเท่านั้น

worker ต่ออายุ lease ขณะประมวลผล หากโปรเซสล่ม lease จะหมดอายุและ worker อื่นตรวจสอบความพยายามได้ worker ใหม่ไม่ควรส่งซ้ำโดยไม่ตรวจ แต่ต้องค้นหา ID งานผู้ให้บริการ คีย์คำขอ หรือเอาต์พุตที่เสร็จแล้วก่อน

กำหนด lease ให้นานกว่าขั้นตอนภายในตามปกติ แต่สั้นกว่าระยะเวลาที่พร้อมรอเพื่อกู้จากการล่ม งานระยะยาวของผู้ให้บริการไม่ต้องให้ worker หนึ่งตัวถือ lease ตลอดเวลา ให้เก็บ ID ระยะไกล ปล่อย worker และกำหนดตรวจสถานะภายหลัง

## บันทึกความพยายามแยกจากงาน

งานแสดงเจตนา ส่วน attempt บันทึกสิ่งที่เกิดขึ้นในการทำงานหนึ่งครั้ง การแยก attempt ป้องกันไม่ให้แถวหลักถูกเขียนทับด้วยข้อผิดพลาดล่าสุด

สำหรับทุก attempt ให้บันทึก:

* หมายเลข attempt และเวลา;
* ตัวตน worker และเวอร์ชันซอฟต์แวร์;
* แฮชคำขอที่ปรับรูปแบบแล้ว;
* ผู้ให้บริการและเส้นทางโมเดล;
* ID คำขอหรืองานของผู้ให้บริการ;
* สถานะ HTTP และประเภทข้อผิดพลาดผู้ให้บริการ;
* ประวัติ polling หรือสถานะสุดท้ายของผู้ให้บริการ;
* checksum ขนาด ระยะเวลา และคีย์จัดเก็บของเอาต์พุต;
* การใช้ทรัพยากรอินพุตและเอาต์พุตเมื่อมี

อย่าเก็บ secret หรือข้อมูลลูกค้าที่ไม่จำกัดใน log เก็บหลักฐานที่ปกปิดข้อมูลพอสำหรับตรวจสอบ timeout, retry หรือใบแจ้งหนี้ภายหลัง

## ทำให้ขั้นตอนส่งและดาวน์โหลดทำซ้ำได้

idempotency ต้องมีมากกว่าหนึ่งขอบเขต unique constraint ในฐานข้อมูลป้องกันระเบียนงานภายในซ้ำ idempotency key ของผู้ให้บริการเมื่อมีเอกสารรองรับช่วยป้องกันการส่งงานระยะไกลซ้ำ และคีย์จัดเก็บแบบกำหนดซ้ำได้ช่วยไม่ให้การดาวน์โหลดสองครั้งสร้างสินทรัพย์แยกกัน

หากผู้ให้บริการไม่ได้ระบุพฤติกรรม idempotency ให้ถือว่า timeout ระหว่างส่งเป็นผลลัพธ์ไม่ทราบ ค้นบันทึก attempt ของคุณและใช้ความสามารถแสดงรายการหรือค้นคำขอของผู้ให้บริการก่อนส่งอีกครั้ง หากตรวจสอบไม่ได้ ให้ส่งกรณีไปสู่นโยบาย เช่น รอ ตรวจด้วยคน หรือส่งใหม่พร้อมบันทึกต้นทุนซ้ำที่อาจเกิดขึ้นอย่างชัดเจน

สำหรับพื้นที่เก็บข้อมูล ให้เขียนลงออบเจ็กต์ชั่วคราว ตรวจ checksum และคุณสมบัติ media แล้วเลื่อนไปยังคีย์สุดท้าย บันทึก URI ถาวรหลังการตรวจผ่านเท่านั้น การดาวน์โหลดซ้ำควรยืนยัน checksum เดิมหรือแทนที่เฉพาะออบเจ็กต์ชั่วคราวที่ยืนยันแล้วว่าเสีย

## สร้างการกู้คืนจาก checkpoint ที่สังเกตได้

ทดสอบการกู้คืนโดยหยุด worker ที่ทุกขอบเขตสถานะ การทดสอบที่มีประโยชน์รวมถึงหยุดก่อนส่งทันที หลังผู้ให้บริการรับงาน ระหว่าง polling ระหว่างดาวน์โหลด และหลังเขียนสินทรัพย์แต่ก่อนอัปเดตฐานข้อมูล

| จุดที่หยุด | หลักฐานสำหรับกู้คืน | พฤติกรรมที่คาดหวัง |
|---|---|---|
| ก่อนเรียก API | ไม่มี ID ผู้ให้บริการ ไม่ได้ทำเครื่องหมายว่าส่ง | ส่งหนึ่งครั้ง |
| หลังยอมรับ | บันทึก ID ผู้ให้บริการแล้ว | ทำ polling ต่อ |
| timeout ระหว่างส่ง | fingerprint คำขอ ผลลัพธ์ไม่แน่นอน | ตรวจสอบก่อน retry |
| ระหว่างดาวน์โหลด | ออบเจ็กต์ชั่วคราวและ metadata ที่คาดไว้ | ทำต่อหรือเริ่มดาวน์โหลดใหม่ |
| หลังเขียนถาวร | checksum ออบเจ็กต์ แต่สถานะงานไม่สมบูรณ์ | ตรวจออบเจ็กต์แล้วทำเครื่องหมายเสร็จ |

ติดตามอายุคิว เวลาในแต่ละสถานะ จำนวน attempt ต่อ job การหมดอายุ lease การส่งที่ไม่ทราบผล แถวไม่ถูกต้อง และ backlog การตรวจ ตัวชี้วัดเหล่านี้แสดงสุขภาพการทำงานได้ชัดกว่าอัตราความสำเร็จรวมค่าเดียว

## ทำให้ชั้นโมเดลเปลี่ยนได้

คิวควรพึ่ง adapter แบบมาตรฐาน ไม่ใช่ออบเจ็กต์ตอบกลับเฉพาะผู้ให้บริการทั่วทั้งโค้ด Adapter แปลงคำของานทั่วไปเป็น schema ของแต่ละโมเดลและคืนระเบียนการยอมรับ สถานะ การใช้ทรัพยากร ข้อผิดพลาด และเอาต์พุตแบบมาตรฐาน

[Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=product-csv-recoverable-video-production-queue) มีประโยชน์เมื่อแผนการผลิตครอบคลุมโมเดลข้อความ ภาพ และวิดีโอ แต่ทีมต้องการแพลตฟอร์มที่เข้ากันได้กับ OpenAI และความสัมพันธ์การเรียกเก็บเงินเพียงหนึ่งเดียว ซึ่งช่วยลดงานเชื่อมต่อและบัญชีบางส่วน แต่ไม่ลดความจำเป็นของตัวตนงาน บันทึก attempt พื้นที่เก็บถาวร หรือการตรวจความสามารถเฉพาะโมเดล

เก็บผู้ให้บริการ รหัสโมเดลที่แน่นอน เวอร์ชัน adapter และพารามิเตอร์คำขอกับทุก attempt การเปลี่ยนเส้นทางไม่ควรทำให้เอาต์พุตเก่าอธิบายไม่ได้

## สรุป

เปลี่ยน CSV เป็นคิวการผลิตที่กู้คืนได้โดยถือไฟล์เป็นการนำเข้าที่มีเวอร์ชัน ขยายสินค้าเป็นงานแบบกำหนดซ้ำได้ และบันทึกสถานะกับความพยายามอย่างชัดเจน ใช้ lease ที่หมดอายุได้ ตรวจสอบการส่งที่ไม่แน่นอน และคัดลอกเอาต์พุตที่ผ่านการยืนยันไปยังพื้นที่เก็บถาวร การออกแบบสำเร็จเมื่อ worker ใดก็ตามเริ่มใหม่หลังระบบล่มและระบุการดำเนินการถัดไปที่ปลอดภัยได้จากหลักฐานที่บันทึกไว้เพียงอย่างเดียว

## FAQ

### ควรใช้ค่าใดเป็น ID ไม่ซ้ำของงานวิดีโอที่สร้างจาก CSV?

ใช้ ID แบบกำหนดซ้ำได้ที่สร้างจากแคตตาล็อก รหัสสินค้า เวอร์ชันเทมเพลตครีเอทีฟ locale และตัวแปรเอาต์พุต อย่าใช้หมายเลขแถว เพราะการเรียงหรือแทรกแถวจะทำให้หมายเลขเปลี่ยน

### หนึ่งแถว CSV ควรเท่ากับหนึ่งงานวิดีโอหรือไม่?

ไม่เสมอไป หนึ่งแถวสินค้าอาจขยายเป็นหลายงานเมื่อมีหลาย locale อัตราส่วนภาพ hook หรือเทมเพลตครีเอทีฟ ควรแยกแถวต้นทางออกจากระเบียนงานที่ขยายแล้ว

### worker ของคิวควรลองสร้างใหม่กี่ครั้งเมื่อเกิดข้อผิดพลาด?

กำหนดนโยบาย retry แบบจำกัดจำนวนน้อยตามประเภทข้อผิดพลาด ลองข้อผิดพลาดเครือข่ายและผู้ให้บริการชั่วคราวใหม่ด้วย backoff แต่ส่งอินพุตไม่ถูกต้องและความพยายามที่หมดแล้วไปยังสถานะตรวจสอบหรือ dead letter

### ควรเก็บวิดีโอที่สร้างแล้วไว้ที่ไหน?

คัดลอกเอาต์พุตที่สำเร็จไปยัง object storage แบบถาวรภายใต้คีย์ที่คาดเดาได้ อย่าถือ URL ดาวน์โหลดชั่วคราวของผู้ให้บริการเป็นตำแหน่งสินทรัพย์สุดท้าย

### จะทำให้คิวทำงานต่อหลังโปรเซสล่มได้อย่างไร?

บันทึกทุกการเปลี่ยนสถานะและใช้ lease ที่มีเวลาหมดอายุ เมื่อเริ่มใหม่ ให้รับงานที่ lease หมดอายุ ตรวจดูความพยายามล่าสุด และทำต่อเฉพาะขั้นตอนที่ยังไม่เสร็จ

### ใช้ Atlas Cloud ในคิวการผลิตหลายโมเดลได้หรือไม่?

ได้ Atlas Cloud ช่วยลดงานเชื่อมต่อเมื่อคิวใช้โมเดลข้อความ ภาพ และวิดีโอผ่านแพลตฟอร์มที่เข้ากันได้กับ OpenAI หนึ่งแห่ง แต่คิวยังต้องปรับสถานะงานและเอาต์พุตเฉพาะผู้ให้บริการให้เป็นรูปแบบกลาง