การถ่ายโอนไฟล์แบบ CDC

 (github.com/google)
2 คะแนน โดย GN⁺ 2025-10-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • CDC File Transfer เป็นเครื่องมือโอเพนซอร์สที่พัฒนาโดย Google รองรับ การซิงก์ไฟล์และการสตรีมระหว่าง Windows กับ Linux
  • ใช้เทคโนโลยี Content Defined Chunking (CDC) ที่ ส่งเฉพาะส่วนที่มีการเปลี่ยนแปลงของไฟล์ ทำให้ทำความเร็วได้สูงสุดมากกว่า rsync แบบเดิมถึง 30 เท่า
  • มีเครื่องมือหลัก 2 ตัวคือ cdc_rsync และ cdc_stream โดยทำหน้าที่ซิงก์ไฟล์และสตรีมแบบเรียลไทม์ตามลำดับ
  • ออกแบบมาสำหรับนักพัฒนาบน Windows ที่ต้องการดีพลอยและทดสอบไฟล์บนสภาพแวดล้อม Linux อย่างมีประสิทธิภาพ จึงโดดเด่นมากใน งานพัฒนาระยะไกลและสภาพแวดล้อมการพัฒนาเกม
  • รองรับ การยืนยันตัวตนผ่าน ssh และ sftp ใช้งานได้ตรงไปตรงมา และมีไบนารีสำหรับหลายแพลตฟอร์ม

ภาพรวมและความสำคัญของโครงการ

  • CDC File Transfer คือชุดเครื่องมือถ่ายโอนไฟล์ที่ Google เปิดซอร์ส ซึ่งช่วยจัดการ การซิงก์ไฟล์และการสตรีม ระหว่าง Windows กับ Linux หรือระหว่าง Windows ด้วยกันได้อย่างรวดเร็วและมีประสิทธิภาพ
  • โครงการนี้ถูกสร้างขึ้นสำหรับสภาพแวดล้อมการพัฒนาเกมของ Stadia และถือกำเนิดขึ้นเพื่อแก้ข้อจำกัดของ scp และ rsync แบบเดิม (ถ่ายโอนช้า คัดลอกทั้งไฟล์ และไม่มีโหมดเดลตา)
  • เทคโนโลยีหลักคืออัลกอริทึม FastCDC ซึ่งเป็น Content Defined Chunking ที่ส่งเฉพาะข้อมูลที่เปลี่ยนจริงเมื่อไฟล์มีการแก้ไข จึงเหมาะอย่างยิ่งกับการซิงก์ซ้ำ ๆ ของข้อมูลขนาดใหญ่
  • แม้จะเป็นโอเพนซอร์ส แต่ให้ประสิทธิภาพระดับเชิงพาณิชย์ (เช่น ความเร็วซิงก์ 1500 MB/s และสตรีมเร็วกว่า sshfs 2~5 เท่า) พร้อมประสิทธิภาพที่เหนือกว่าบริการคู่แข่งอย่างชัดเจนในสภาพแวดล้อมคลาวด์/การพัฒนาระยะไกล

คำอธิบายเครื่องมือหลัก

cdc_rsync

  • เป็นเครื่องมือสำหรับซิงก์ไฟล์จาก Windows ไปยัง Linux และแก้ข้อด้อยของ rsync บน Linux แบบเดิม
  • ไฟล์ที่เวลาและขนาดไฟล์ตรงกันจะถูกข้ามอย่างรวดเร็ว และจะส่งเฉพาะไฟล์ที่มีการเปลี่ยนแปลงอย่างมีประสิทธิภาพ
  • ใช้ FastCDC เพื่อตรวจจับตำแหน่งของข้อมูลที่เปลี่ยนและส่งเฉพาะส่วนนั้น จึงใช้ทราฟฟิกน้อยและถ่ายโอนได้รวดเร็ว
  • ผลการทดสอบการซิงก์แสดงว่าทำงานได้เร็วกว่า rsync ที่รันบน Cygwin ประมาณ 3 เท่า และเร็วกว่ามาตรฐาน rsync บน Linux อย่างมาก
  • รองรับ การบีบอัดความเร็วสูง และมีโครงสร้างอัลกอริทึมที่เรียบง่ายแต่มีประสิทธิภาพ ซึ่งตรวจสอบไฟล์ได้ละเอียดถึงระดับไบต์

cdc_stream

  • ทำให้โฟลเดอร์และไฟล์บน Windows สามารถเข้าถึงจาก Linux ได้แบบสตรีมเรียลไทม์ราวกับเป็นไฟล์ในเครื่อง
  • โครงสร้างคล้าย sshfs แบบเดิม แต่มีการปรับแต่ง ความเร็วในการอ่านไฟล์และประสิทธิภาพแคช ให้ดีขึ้น
  • ผ่าน การตรวจจับการเปลี่ยนแปลงและการสตรีมแบบแตกต่างเฉพาะส่วน จึงส่งซ้ำเฉพาะข้อมูลที่เปลี่ยน และจัดการเมตาดาต้าได้รวดเร็ว
  • ไดเรกทอรีฝั่ง Linux จะถูกให้บริการแบบ readonly และไฟล์ที่เปลี่ยนบน Windows จะสะท้อนไปยัง Linux แทบจะทันที (สูงสุดในระดับไม่กี่วินาที)
  • ในสภาพแวดล้อมพัฒนาที่ต้องเข้าถึงไฟล์ขนาดใหญ่ เช่น ข้อมูลเกม พบว่าให้ประสิทธิภาพดีกว่า sshfs จริง 2~5 เท่า

แพลตฟอร์มที่รองรับ

  • cdc_rsync: รองรับหลักระหว่าง Windows x86_64 ↔ Ubuntu 22.04 x86_64 และกำลังขยายการรองรับทั้งการซิงก์ระยะไกล/การซิงก์ภายในเครื่องอย่างต่อเนื่อง
  • cdc_stream: รองรับการสตรีมจาก Windows x86_64 ไปยัง Ubuntu 22.04 x86_64 โดยยังไม่รองรับทิศทางกลับกันหรือแพลตฟอร์มอื่น

วิธีการยืนยันตัวตน/การตั้งค่า

  • การยืนยันตัวตนแบบไม่ใช้รหัสผ่านผ่าน ssh.exe และ sftp.exe (แนะนำการยืนยันตัวตนด้วยกุญแจ)
  • บน Windows สามารถระบุพาธของคำสั่งหรือเส้นทางผ่านตัวแปรสภาพแวดล้อมได้
  • รองรับออปชันคำสั่ง SSH เพิ่มเติม และสามารถใช้ไฟล์ตั้งค่ารายผู้ใช้ (%USERPROFILE%\\.ssh\\config) ได้
  • ผู้ใช้ภายใน Google มีตัวแปรสภาพแวดล้อมสำหรับการยืนยันตัวตนด้วยกุญแจความปลอดภัยโดยเฉพาะ

ตัวอย่างการใช้งาน

ตัวอย่างการใช้ cdc_rsync

  • ซิงก์ไฟล์: cdc_rsync C:\path\to\file.txt user@linux.device.com:~
  • รองรับไวลด์การ์ดและการซิงก์ทั้งไดเรกทอรีแบบ recursive: cdc_rsync C:\path\to\assets\* user@linux.device.com:~/assets -r
  • ตรวจสอบสถานะการซิงก์แบบเรียลไทม์ได้ (ออปชัน -v) และสามารถซิงก์ระหว่างไฟล์ในเครื่องได้เช่นกัน

ตัวอย่างการใช้ cdc_stream

  • เริ่มสตรีมไดเรกทอรี: cdc_stream start C:\path\to\assets user@linux.device.com:~/assets
  • หยุดเซสชันสตรีม: cdc_stream stop user@linux.device.com:~/assets
  • จัดการหลายเซสชันด้วยไวลด์การ์ดได้

การแก้ปัญหาและการบันทึกล็อก

  • cdc_stream ทำงานโดยอิงกับบริการเบื้องหลัง โดยค่าเริ่มต้นล็อกจะถูกเก็บไว้ที่ %APPDATA%\cdc-file-transfer\logs
  • มีตัวเลือกสำหรับล็อกแบบละเอียดและการดีบัก (ตั้งค่าระดับ verbosity ผ่าน JSON)
  • cdc_rsync แสดงล็อกทางคอนโซล และสามารถใช้ -vvv, -vvvv เพื่อแสดงล็อกแบบละเอียดได้
  • สามารถติดตามคำสั่ง SSH/SFTP ที่ล้มเหลวและนำไปรันโดยตรงเพื่อวิเคราะห์สาเหตุของปัญหาได้ง่าย

เทคโนโลยีสแตกและข้อมูลการดำเนินงาน

  • ภาษาในการพัฒนาหลักคือ C++ และมี Python/Starlark บางส่วนสำหรับการจัดการบิลด์
  • ใช้ไลเซนส์ Apache-2.0 มีผู้ร่วมพัฒนามากกว่า 8 คน และมี 3.3k stars บน GitHub
  • ตั้งแต่ปี 2023 เป็นต้นมา โครงการอยู่ในสถานะ Archived โดยไม่มีการพัฒนาเพิ่มเติม

สรุป

  • CDC File Transfer มอบ ประสิทธิภาพและความเร็วระดับแนวหน้าของอุตสาหกรรม สำหรับการถ่ายโอนไฟล์และไดเรกทอรีขนาดใหญ่ซ้ำ ๆ ระหว่าง Windows กับ Linux
  • มีข้อดีในการลดเวลาอย่างมากของกระบวนการซิงก์และสตรีมใน สภาพแวดล้อมทำงานข้ามแพลตฟอร์ม เช่น การพัฒนาระยะไกล เกม สื่อ และการวิเคราะห์ข้อมูล
  • เมื่อเทียบกับเครื่องมือซิงก์/สตรีมอื่น ๆ แล้ว มีความสามารถในการแข่งขันสูงจาก ความเรียบง่าย การตรวจจับการเปลี่ยนแปลงเฉพาะส่วนอย่างรวดเร็ว และระบบแคชที่ยอดเยี่ยม
  • รองรับการยืนยันตัวตนผ่าน SSH/SFTP และการตั้งค่าสภาพแวดล้อมที่ยืดหยุ่นผ่านคำสั่งหรือไฟล์ตั้งค่า ทำให้วิศวกรนำไปใช้และดูแลได้ง่าย
  • สามารถอ่านและปรับแต่งซอร์สโค้ดได้ และได้รับชื่อเสียงกับการใช้งานในระดับสูงจากชุมชนโอเพนซอร์สแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-02
ความคิดเห็นใน Hacker News

  • ตั้งแต่ปีที่แล้วผมได้ลองทดลองกับ Content Defined Chunking อยู่หลายแบบ (โดยเฉพาะ bonanza.build) และพบว่าแม้แต่อัลกอริทึม FastCDC ที่ใช้กันแพร่หลายที่สุดก็ยังมีช่องให้ปรับปรุงได้ โดยเมื่อใช้แนวทาง lookahead แล้วประสิทธิภาพดีขึ้นมาก สำหรับ implementation ของแนวทางนี้ดูได้ที่ buildbarn/go-cdc

    • แนวทาง lookahead นี้ดูคล้ายกับ “lazy matching” ในตัวบีบอัดแบบ Lempel-Ziv มาก (บล็อกที่เกี่ยวข้อง) อยากรู้ผลการเปรียบเทียบกับ Buzhash ปกติคาดว่า gearhash จะเร็วกว่าเพราะโครงสร้างเรียบง่ายกว่า อีกอย่าง สำหรับการ init ของ gear อาจใช้ seeded generator ของ rand/v2 แทน mt19937 จะเหมาะกว่า
    • bonanza.build น่าประทับใจมาก ถ้ายังใช้ Bazel อยู่ก็คงอยากลองมาก
    • อยากรู้ว่าถ้าเอา go-cdc ไปใช้ใน cdc_rsync แทน fastcdc แล้วด้านประสิทธิภาพจะต่างกันแค่ไหน
    • ทำให้นึกว่า AI จะมีช่องให้ช่วยในด้านนี้ได้ไหม มีการใช้ AI อย่างมีประโยชน์อยู่แล้วในงานบีบอัดข้อมูล (ตัวอย่างการบีบอัดด้วย AI) และการเพิ่มประสิทธิภาพ RF modulation (ลิงก์งานวิจัย) จึงคาดว่าน่าจะเป็นไปได้ที่จะใช้โมเดลขนาดเล็ก (โดยเฉพาะสาย SSM) มาฝึกให้ปรับขอบเขต chunk ให้เหมาะสม

  • rsync ใช้การกำหนดขอบเขต chunk แบบ content-defined ด้วยเงื่อนไข rolling hash อยู่แล้วไม่ใช่หรือ? (ลิงก์วิกิ 1, ลิงก์วิกิ 2) สงสัยว่าความเร็วที่ดีขึ้นเมื่อเทียบกับ rsync น่าจะมาจากประสิทธิภาพของ rolling hash และการใช้ executable แบบเนทีฟบนวินโดวส์ (เพราะไฟล์ซิสเต็มของวินโดวส์ช้า) มากกว่าหรือเปล่า อย่างไรก็ดี การปรับปรุงประสิทธิภาพก็น่าสนใจ และการเปิดเป็นโอเพนซอร์สก็ดีด้วย หวังว่าวิธีนี้จะเข้าไปอยู่ใน rsync เองด้วย

    • rsync ไม่ได้ใช้ content-defined chunking แต่ใช้บล็อกขนาดคงที่บนไฟล์ปลายทาง จากนั้นใช้ rolling hash เพื่อตรวจจับบล็อกเหล่านั้นจากตำแหน่งใดก็ได้ในไฟล์ต้นทางเพื่อหลีกเลี่ยงการส่งซ้ำ (เอกสารเทคนิค)
    • ใน README ของ repo มีการอธิบายความแตกต่างของแนวทางเมื่อเทียบกับ rsync ไว้อย่างเป็นมิตรมาก
    • rsync ให้ความรู้สึกเหมือนเป็นโปรเจกต์ที่แทบหยุดนิ่งไปแล้ว แม้จะยังมีการดูแลมายาวนาน แต่ก็พลาดการปรับปรุงด้านคุณภาพหลายอย่าง และตอนนี้ให้ความรู้สึกคล้าย vim คือในทางทฤษฎียังถูกดูแลอยู่ แต่ในทางปฏิบัติแทบไม่มีพัฒนาการ

  • ดีใจที่ Stadia ยังทิ้งประโยชน์ระยะยาวไว้อีกอย่างแบบนี้ เสียดายที่ไม่มีเวอร์ชัน self-hosted ออกมา แต่ในโลกยุค DRM ทุกวันนี้ ถ้ามีก็คงโดนมองเป็นของเถื่อนทันที

    • ถ้าจะทำเกมสตรีมมิงแบบ self-hosted แนะนำใช้คู่ moonlight กับ sunshine ใช้งานได้ดีมาก
    • เท่าที่เข้าใจ Stadia ไม่สามารถทำแบบ self-hosted ได้โดยตรง นักพัฒนาต้อง build รองรับ Stadia แยกต่างหาก และอาจเป็นแพลตฟอร์มทดแทน DirectX แบบเฉพาะทางด้วย หรืออาจเป็นสภาพแวดล้อม emulation แบบเบาอย่าง Proton ก็ได้ แต่เกมที่ผมเคยเล่นมีการแสดงคีย์ไบน์ดิงแบบ custom สำหรับ Stadia โดยเฉพาะ (สัญลักษณ์เฉพาะของ Stadia) ในเกมเลย แปลว่ามีการปรับแต่งอย่างชัดเจน ซึ่งต่างจากเกมสตรีมมิงของ PlayStation, Xbox และ Nvidia อย่างเห็นได้ชัด ส่วน Amazon Luna ผมไม่แน่ใจ
    • ถ้าจะทำ remote game streaming แบบ self-hosted ให้ดู Moonlight/Sunshine(Apollo) แทน Stadia ต้องใช้ build เฉพาะจึงไม่ได้มีความหมายมากนัก
    • ในยุค DRM คำว่า ‘ของเถื่อน’ นี่จริง ๆ หมายถึงอะไร หมายถึงการสตรีมเกม PC ที่เราครอบครองเองขึ้นคลาวด์หรือ?
    • “self-hosting stadia” ที่จริงแล้วมีหลายบริการและหลายเครื่องมือทำได้อยู่แล้ว Steam เองก็มีระบบสตรีมเกมในตัวที่ยอดเยี่ยม Nvidia และ AMD ก็เคยใส่ฟีเจอร์นี้ไว้ในไดรเวอร์ GPU มาก่อน และ Steam Deck ก็สตรีมเกมได้เช่นกัน ยังมีตัวอย่างอีกหลายแบบ เช่น การสตรีมของ Sony บน PS4/PC หรือของ Microsoft บน Xbox

  • ถ้าใครเคยสงสัยว่า Content Defined Chunking สร้าง chunk จริง ๆ อย่างไร บล็อกนี้ กับ บล็อกนี้ อธิบายแนวคิดได้เข้าใจง่ายมาก

    • ขอบคุณ ลิงก์ต้นฉบับอธิบายละเอียดไม่พอจนคาใจอยู่พอดี เดี๋ยวจะลองอ่านเร็ว ๆ นี้

  • ประโยคสำคัญ: "อัลกอริทึม remote diffing นี้สร้างบน CDC (Content Defined Chunking) และจากการทดสอบเร็วกว่า rsync ได้สูงสุด 30 เท่า (1500MB/s เทียบกับ 50MB/s)"

  • ไม่รู้ว่ามีใครทราบไหมว่ากำลังมีงานเพื่อรวมฟีเจอร์นี้เข้าไปในเครื่องมือมาตรฐานของ rsync หรือเปล่า อยากให้ฟีเจอร์นี้ถูกใช้แพร่หลาย แต่ดูจากเว็บไซต์ทางการแล้วเหมือนยังไม่รองรับ Linux-to-Linux เลย ซึ่งน่าเสียดาย

    • ประเด็นเรื่องการรองรับ Linux-to-Linux และความเข้ากันได้ที่ใช้งานได้กว้างขึ้น มีการพูดคุยไว้ที่ ที่นี่ 1, ที่นี่ 2

  • โปรเจกต์นี้ก็ดูเจ๋งไม่น้อย ผมเคยทำของลักษณะคล้ายกันใช้เองให้เข้ากับงาน และในเงื่อนไขที่เข้มงวดมันสำคัญพอสมควร แต่อดคิดไม่ได้ว่าการเริ่มจาก rsync อาจจะง่ายกว่าหรือเปล่า

    • เขาบอกว่า “scp คัดลอกได้แค่ทั้งไฟล์ ไม่มีโหมด delta ช้าเมื่อมีไฟล์เล็กจำนวนมาก และการบีบอัดก็ช้า” แต่ใน rsync ใช้ตัวเลือก -z สำหรับการบีบอัดได้ (คำอธิบาย) ถ้า CPU เหลือพอ ปกติแนะนำให้ใช้ -z และมันก็ช่วยให้เร็วขึ้นด้วย แม้อาจไม่ได้เร็วมาก แต่ก็มองว่า rsync เป็นจุดเริ่มต้นที่ดีกว่า scp
    • “อัลกอริทึม remote diffing สร้างบน CDC และจากการทดสอบเร็วกว่า rsync ได้สูงสุด 30 เท่า (1500 MB/s vs 50 MB/s)”
    • ดูเหมือน rsync จะไม่ได้ถูกปรับให้เหมาะกับบางงาน โดยเฉพาะงานพัฒนาเกม ซึ่งมักต้องคัดลอกไฟล์และไดเรกทอรีตั้งแต่หลักหมื่นไปจนถึงหลักล้าน rsync มีแนวโน้มจะ serialize การสร้างไดเรกทอรี/ไฟล์ ทำให้ความเร็วตกหนัก ผมเคยลองแยกเป็น rsync จำนวน N งานด้วย GNU parallel หรือสร้างรายการไฟล์เองแล้วค่อยรัน แต่สุดท้ายก็ไปจบที่เครื่องมืออย่าง syncthing ที่ทำ pre-indexing ได้

  • สงสัยว่าเทคนิคนี้จะเอาไปใช้กับ git ได้ไหม git blob สร้าง hash โดยรวมข้อมูลความยาวไว้ด้วย ดังนั้นถ้าเปลี่ยนข้อมูลเพียงบางส่วนก็ต้องคำนวณ hash ใหม่ตั้งแต่ต้น ถ้าใช้ CDC น่าจะมีประสิทธิภาพกว่ามาก

    • มีการนำแนวทาง CDC ไปใช้จริงใน xet เพื่อแทน git lfs แล้ว (กรณีที่เกี่ยวข้อง)
    • เครื่องมือสำรองข้อมูลอย่าง restic/borg ก็ใช้ CDC เช่นกัน แต่ยังสงสัยว่าเคยมีความพยายามจริงจังในการทำตัวแทน git บ้างหรือยัง

  • คำอธิบายที่ว่า “เพียงดาวน์โหลดไบนารีแบบ precompiled ของรีลีสล่าสุดมาบนวินโดวส์แล้วแตกไฟล์ ไบนารีลินุกซ์จะถูก deploy อัตโนมัติไปที่ ~/.cache/cdc-file-transfer จากเครื่องมือบนวินโดวส์ ไม่ต้องติดตั้งเพิ่ม” ฟังดูน่าประทับใจ ต่างจาก rsync ตรงที่มันทำงานได้โดยไม่ต้องติดตั้งบริการเพิ่มบนปลายทางลินุกซ์ ซึ่งเป็นจุดที่ผมเคยรู้สึกว่ายุ่งยากกับ rsync เล็กน้อย

    • อันที่จริงวิธีใช้ rsync ที่พบบ่อยที่สุดคือให้มันรันตัวฝั่งรับบนเครื่องปลายทางผ่าน ssh แบบอัตโนมัติ และ cdc ก็ทำงานแบบเดียวกัน ดังนั้นที่บอกว่าการใช้ rsync ต้องติดตั้งบริการเพิ่มจึงเป็นความเข้าใจผิด

  • สงสัยว่า IBM Aspera ทำงานคล้ายแนวทางนี้หรือไม่ ตอนที่ทำงานเป็น QA ให้ผู้จัดจำหน่ายเกม ผมเคยอัปโหลดวิดีโอบันทึกหน้าจอผ่าน Aspera และมันทำความเร็วได้สูงกว่าอัตราอัปโหลดปกติของอินเทอร์เน็ตที่ออฟฟิศมาก (แนะนำ IBM Aspera)