การปรับขนาดที่มีประสิทธิภาพและตัวจัดการการสับเปลี่ยนระยะไกล

นําไปใช้กับ:✅ วิศวกรรมข้อมูล Fabric และวิทยาศาสตร์ข้อมูล

การปรับขนาดที่มีประสิทธิภาพเป็นคุณลักษณะใน Microsoft Fabric Spark ที่แยกข้อมูลการสับเปลี่ยน Spark ออกจากอายุการใช้งานของตัวดําเนินการ แทนที่จะปักหมุดเอาต์พุตการสับเปลี่ยนไปยังดิสก์ตัวดําเนินการภายในเครื่อง Fabric Spark จะกําหนดเส้นทางข้อมูลการสับเปลี่ยนไปยัง Azure Blob Storage (หรือโยกย้ายไปที่นั่นตามความต้องการ) และให้ Adaptive Query Execution (AQE) กําหนดรูปร่างการเขียนเอง ผลลัพธ์คือการลดขนาดคลัสเตอร์ได้เร็วขึ้น ต้นทุนการประมวลผลต่ํา และงานที่มีความยืดหยุ่นมากขึ้น — โดยไม่มีการเปลี่ยนแปลงใด ๆ กับคําสั่งค้นหา สมุดบันทึก หรือท่อส่งของคุณ

Overview

การลดขนาดที่มีประสิทธิภาพสร้างขึ้นจากความสามารถในการทํางานร่วมกันสี่ประการ:

ความสามารถ	การทำงานของมัน
ตัวจัดการการสับเปลี่ยนระยะไกล (RSM)	เขียนและอ่านการสับเปลี่ยนข้อมูลไปยัง Azure Blob Storage แทนดิสก์ภายในเครื่องของตัวดําเนินการ
การย้ายแบบสับเปลี่ยน	ย้ายสับเปลี่ยนบล็อกออกจากผู้ดําเนินการก่อนที่จะถูกปลดประจําการ แทนที่จะทิ้ง
ชั้นการตัดสินใจ	การกําหนดเส้นทางรันไทม์ต่อขั้นตอนที่เก็บการสับเปลี่ยนขนาดเล็กไว้ในเครื่องและถ่ายโอนการสับเปลี่ยนขนาดใหญ่ไปยังที่เก็บข้อมูลระยะไกล
AQE สับเปลี่ยนเขียน	ให้ Adaptive Query Execution มีส่วนร่วมในขั้นตอนการเขียนแบบสุ่มเพื่อให้การแบ่งพาร์ติชันถูกต้องในครั้งแรก

ข้อกําหนดเบื้องต้น

• เปิดใช้งาน Native Execution Engine (NEE)
• เปิดใช้งานการปรับขนาดอัตโนมัติ (แนะนํา) การลดขนาดอย่างมีประสิทธิภาพยังทํางานได้โดยไม่ต้องปรับขนาดอัตโนมัติผ่านการตั้งค่า Spark ที่อธิบายไว้ในบทความนี้
• รันไทม์ 1.3 (Apache Spark 3.5) หรือใหม่กว่า

วิธีการทำงาน

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

การลดขนาดที่มีประสิทธิภาพจะทําลายการมีเพศสัมพันธ์นี้:

• การสุ่มขนาดใหญ่ ไปที่ Azure Blob Storage โดยตรงผ่านตัวจัดการการสุ่มระยะไกล
• การสับเปลี่ยนเล็ก ๆ จะอยู่บนดิสก์ในเครื่องเพื่อความเร็ว หากต้องปล่อย executor ในภายหลัง การย้ายแบบสับจะย้ายบล็อกไปยัง peer หรือไปยัง fallback storage ในพื้นหลัง
• ชั้นตัดสินใจจะเลือกเส้นทางที่ถูกต้องต่อแต่ละขั้นตอนขณะรันไทม์
• AQE Shuffle Write ช่วยให้มั่นใจได้ว่าผู้เขียนจะสร้างการแบ่งพาร์ติชันที่ AQE ดาวน์สตรีมใช้โดยไม่ต้องรวมตัวกันใหม่

                ┌───────────────────────────┐
   Query  ───►  │   AQE + decision layer    │   per-stage choice
                └─────────────┬─────────────┘
                              │
                ┌─────────────▼─────────────┐
                │   AQE Shuffle Write       │   partition-aware writer
                └─────┬─────────────────┬───┘
                      │                 │
              local   ▼                 ▼   remote
        ┌────────────────────┐   ┌──────────────────┐
        │  Local disk +      │   │  RSM → Azure     │
        │  shuffle migration │   │  Blob Storage    │
        └─────────┬──────────┘   └─────────┬────────┘
                  │ on decommission        │
                  ▼                        ▼
        fallback storage   Remote shuffle store

การกําหนดเส้นทางอัจฉริยะ (ชั้นตัดสินใจ)

ชั้นตัดสินใจจะประเมินการแลกเปลี่ยนการสับแต่ละครั้งและตัดสินใจว่า:

• การสับเปลี่ยนขนาดใหญ่→ Azure Blob Storage การลดขนาดสูงสุดและประโยชน์ในการทนต่อความผิดพลาด
• การสับเปลี่ยนเล็กน้อย→ดิสก์ภายในเครื่อง ไม่มีค่าใช้จ่าย I/O บนคลาวด์สําหรับการถ่ายโอนเพียงเล็กน้อย หากผู้จัดการมรดกยกเลิกในภายหลัง การย้ายข้อมูลแบบสับเปลี่ยนจะเข้ามาแทนที่

ชั้นตัดสินใจจะส่งข้อมูลสับเปลี่ยนโดยอัตโนมัติและไม่ต้องการข้อมูลจากคุณ ความละเอียดที่แนะนําคือต่อขั้นตอน

ประโยชน์ที่สำคัญ

ต้นทุนที่ต่ํากว่า: จ่ายเฉพาะการประมวลผลที่คุณใช้

ด้วยการลดขนาดที่มีประสิทธิภาพ ผู้ดําเนินการจะถูกปล่อยตัวทันทีที่งานเสร็จสิ้น พวกเขาไม่ได้นั่งเฉยๆ เก็บข้อมูลสับเปลี่ยนที่งานดาวน์สตรีมอาจอ่านได้ในที่สุด

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

งานที่ยืดหยุ่นมากขึ้น

เมื่อการสับเปลี่ยนข้อมูลอยู่บนดิสก์ในเครื่องเท่านั้นการขัดข้องของตัวดําเนินการหมายความว่าข้อมูลหายไปและ Spark ต้องคํานวณใหม่ ด้วยการปรับขนาดที่มีประสิทธิภาพข้อมูลจะอยู่ในที่เก็บข้อมูล blob อยู่แล้วหรือย้ายไปที่นั่นก่อนที่ตัวดําเนินการจะหายไป

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

การออกแบบนี้ช่วยขจัดสาเหตุที่พบบ่อยที่สุดของ FetchFailedException การผลิต

การปรับขนาดที่ยืดหยุ่นและรวดเร็วอย่างแท้จริง

หากไม่มีการปรับขนาดที่มีประสิทธิภาพ autoscaler จะไม่สามารถเรียกคืนโหนดได้ในขณะที่ตัวดําเนินการใดๆ ยังคงเก็บข้อมูลการสับเปลี่ยนหรือข้อมูลที่แคชไว้ การปรับขนาดที่มีประสิทธิภาพแยกทั้งสอง:

• การสับเปลี่ยนข้อมูลอยู่ในที่เก็บข้อมูล Blob (หรือย้ายไปที่นั่นเมื่อปิดเครื่อง)
• แคชจะไม่ปักหมุดผู้ดําเนินการอีกต่อไป แคชที่ทําซ้ําได้ เช่น แคชสแนปช็อตเดลต้าจะไม่รวมอยู่ในการป้องกันการลดขนาด

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

ประสิทธิภาพที่ดีขึ้นในการสับเปลี่ยนแบบเอียงและขนาดใหญ่

AQE Shuffle Write ช่วยให้ Adaptive Query Execution กําหนดรูปแบบการเขียนแบบสุ่มเอง — เลือกพาร์ติชันที่ AQE ใช้ไปหลังจากนั้นโดยไม่รวมตัวกันใหม่ และสร้างบล็อกจํานวนน้อยลงและมีขนาดดีกว่าสําหรับการจัดเก็บระยะไกล เมื่อรวมกับชั้นการตัดสินใจ คุณจะได้เวลาบนวอลล์นาฬิกาเร็วขึ้นสําหรับคําสั่งค้นหาขนาดใหญ่หรือเบี่ยงเบ้ และความหน่วงไม่เปลี่ยนแปลงสําหรับคําสั่งเล็ก

Get started

การกําหนดค่าที่แนะนํา

ใช้การกําหนดค่านี้เพื่อเปิดใช้งานสแต็กการปรับขนาดที่มีประสิทธิภาพเต็มรูปแบบ:

# Remote Shuffle Manager
spark.conf.set("spark.remote.shuffle.enabled", "true")

# Decision layer — per-stage routing of local vs. remote shuffle
spark.conf.set("spark.sql.rsm.decisionlayer.enabled.level", "stage")

# AQE participates in shuffle write
spark.conf.set("spark.sql.adaptive.shuffleWrite.enabled", "true")

# Shuffle migration on executor decommission
spark.conf.set("spark.storage.decommission.shuffleBlocks.enabled", "true")
spark.conf.set("spark.storage.decommission.shuffleBlocks.cleanup", "true")
spark.conf.set("spark.storage.decommission.shuffleBlocks.migrateToFallbackStorage", "true")
spark.conf.set("spark.storage.decommission.fallbackStorage.cleanUp", "true")

ไม่จําเป็นต้องเปลี่ยนรหัส คุณยังสามารถตั้งค่าคุณสมบัติเหล่านี้ในคุณสมบัติ Spark สภาพแวดล้อมของคุณได้

การอ้างอิงการกําหนดค่า

ตัวจัดการการสับเปลี่ยนระยะไกล (RSM)

Setting	แนะนำ	ฟังก์ชันการควบคุม
spark.remote.shuffle.enabled	true	เปิดการลดขนาดอย่างมีประสิทธิภาพ การสับเปลี่ยนข้อมูลไปที่ Azure Blob Storage แทนดิสก์ภายในเครื่องของตัวดําเนินการ

ชั้นการตัดสินใจ

Setting	แนะนำ	ฟังก์ชันการควบคุม
spark.sql.rsm.decisionlayer.enabled.level	stage	ความละเอียดที่ชั้นตัดสินใจจะสับเปลี่ยนเส้นทาง stage ประเมินแต่ละขั้นตอน Spark อย่างอิสระ

AQE สับเปลี่ยนเขียน

Setting	แนะนำ	ฟังก์ชันการควบคุม
spark.sql.adaptive.shuffleWrite.enabled	true	ให้ AQE มีส่วนร่วมในขั้นตอนการเขียนแบบสุ่ม สร้างการแบ่งพาร์ติชันที่ AQE ปลายน้ําใช้โดยไม่ต้องรวมตัวกันใหม่

หมายเหตุ

AQE เอง (spark.sql.adaptive.enabled) ต้องเปิดอยู่ โดยค่าเริ่มต้นจะเปิดอยู่ใน Fabric Spark

การย้ายถิ่นแบบสับเปลี่ยนเมื่อปลดประจําการ

Setting	แนะนำ	ฟังก์ชันการควบคุม
spark.storage.decommission.shuffleBlocks.enabled	true	โยกย้ายบล็อกสับเปลี่ยนออกจากตัวดําเนินการที่กําลังเลิกใช้งาน แทนที่จะทิ้งบล็อกเหล่านั้น
spark.storage.decommission.shuffleBlocks.cleanup	true	ล้างบล็อกการสับเปลี่ยนบนตัวดําเนินการต้นทางหลังจากการย้ายข้อมูลสําเร็จ
spark.storage.decommission.shuffleBlocks.migrateToFallbackStorage	true	หากไม่มีตัวดําเนินการเพียร์สามารถยอมรับบล็อกได้ ให้โยกย้ายไปยังที่เก็บข้อมูลสํารอง (Azure Blob Storage)
spark.storage.decommission.fallbackStorage.cleanUp	true	ลบบล็อกการสับเปลี่ยนออกจากที่เก็บข้อมูลสํารองเมื่อไม่ต้องการอีกต่อไป

การจัดสรรแบบไดนามิกที่รับรู้แคช

Setting	แนะนำ	ฟังก์ชันการควบคุม
spark.dynamicAllocation.preventShutdownExecutorWithCache	false	อนุญาตให้จัดสรรแบบไดนามิกเพื่อปล่อยตัวดําเนินการแม้ว่าจะเก็บบล็อกแคชไว้ก็ตาม
spark.dynamicAllocation.excludeDeltaSnapshotCache	true	ละเว้นแคชสแนปช็อตเดลต้าเมื่อตัดสินใจว่าผู้ดําเนินการยังคงมีแคชที่มีประโยชน์อยู่หรือไม่ แคชสแนปช็อตเดลต้าสามารถทําซ้ําได้และไม่ควรบล็อกการลดขนาด

การปรับแต่งขั้นสูง (RSM)

ผู้ใช้ส่วนใหญ่ไม่จําเป็นต้องเปลี่ยนค่าเริ่มต้นเหล่านี้

ประสิทธิภาพการเขียน

Setting	ค่าเริ่มต้น	ฟังก์ชันการควบคุม
spark.remote.shuffle.partition.buffersize	16777216 (16 MB)	บัฟเฟอร์ต่อพาร์ติชันก่อนเขียนไปยังที่เก็บข้อมูล
spark.remote.shuffle.blocksize	8388608 (8 MB)	ขนาดของแต่ละบล็อกที่อัปโหลดไปยัง Blob Storage
spark.remote.shuffle.write.maxthreads	cores × 16	เธรดสูงสุดที่ใช้สําหรับการเขียนข้อมูลการสุ่ม
spark.remote.shuffle.write.maxtasks	16384	การดําเนินการเขียนพร้อมกันสูงสุด

ประสิทธิภาพการอ่าน

Setting	ค่าเริ่มต้น	ฟังก์ชันการควบคุม
spark.remote.shuffle.read.parallel.enabled	true	สตรีมการดาวน์โหลดแบบขนานสําหรับการอ่านแบบสุ่ม
spark.remote.shuffle.read.parallelism	4	สตรีมการดาวน์โหลดแบบขนานต่องาน
spark.remote.shuffle.read.prefetchqueuesize	250	ดึงความลึกของคิวล่วงหน้าระหว่างการอ่าน
spark.remote.shuffle.read.maxthreads	cores × 4	เธรดสูงสุดที่ใช้สําหรับการอ่าน

Reliability

Setting	ค่าเริ่มต้น	ฟังก์ชันการควบคุม
spark.remote.shuffle.retries	5	ลองอีกครั้งในข้อผิดพลาดของที่เก็บข้อมูลชั่วคราว
spark.remote.shuffle.retrydelayms	800	การย้อนกลับครั้งแรกระหว่างการลองใหม่
spark.remote.shuffle.retrymaxdelayms	60000	ฝาแบ็คออฟ

การบีบอัด

Setting	ค่าเริ่มต้น	ฟังก์ชันการควบคุม
spark.remote.shuffle.compression	ใช้ spark.io.compression.codec	รูปแบบการบีบอัดสําหรับข้อมูลการสับเปลี่ยนระยะไกล (เช่น lz4, ) zstd

ผลการดําเนินงาน

คํานวณการประหยัดต้นทุน (เกณฑ์มาตรฐานTPC-DS)

Metric	โดยไม่ต้องลดขนาดอย่างมีประสิทธิภาพ	ด้วยการลดขนาดที่มีประสิทธิภาพ
การประมวลผลทั้งหมด (VM-Minutes)	14,952	6,880
การลดต้นทุน	—	54%

รันไทม์งานทั้งหมดอาจนานขึ้น (การปรับขนาดอัตโนมัติใช้ตัวดําเนินการพร้อมกันน้อยลง) แต่การคํานวณที่เรียกเก็บเงินจะลดลงมากกว่าครึ่งหนึ่ง

ประสิทธิภาพของชั้นการตัดสินใจ (TPC-DS, RSM เปิด)

การส่งการสับไฟล์ขนาดเล็กไปยังดิสก์ท้องถิ่นและเฉพาะการสับสับขนาดใหญ่ไปยังที่เก็บข้อมูลระยะไกล ให้การปรับปรุงเวลาทํางานได้ถึง 57% เมื่อเทียบกับการส่งไฟล์ทั้งหมดจากระยะไกล พร้อมประโยชน์ในการลดขนาดเท่าเทียมกัน

ข้อจำกัด

• ต้องใช้ NEE การลดขนาดที่มีประสิทธิภาพขึ้นอยู่กับ Native Execution Engine
• Azure Blob Storage เท่านั้น มาตรฐาน BlockBlobStorage ที่ปิดใช้งาน HNS บัญชีที่เปิดใช้งาน Azure Data Lake Gen2 / HNS ไม่ได้รับการสนับสนุนเป็นที่เก็บการสับเปลี่ยนระยะไกล
• ไม่รองรับ Azure Private Link สภาพแวดล้อมที่ใช้เครือข่ายลิงก์ส่วนตัวยังเข้ากันไม่ได้ในขณะนี้
• ความละเอียดของชั้นการตัดสินใจในปัจจุบันเป็นแบบแยกตามขั้นตอน การกําหนดเส้นทางต่องานหรือต่อพาร์ติชันไม่อยู่ในขอบเขต
• การเปลี่ยนแปลงลักษณะการทํางานของแคช ด้วย preventShutdownExecutorWithCache=falseผู้ดําเนินการที่ถือ cache()/persist() ข้อมูลอาจถูกลดขนาดลง ปริมาณงานที่ต้องพึ่งพาแคชในเครื่องของตัวดําเนินการเป็นอย่างมากสําหรับข้อมูลยอดนิยมควรตรวจสอบความถูกต้อง

เนื้อหาที่เกี่ยวข้อง

• เอ็นจิ้นการดําเนินการแบบเนทีฟสําหรับวิศวกรรมข้อมูล Fabric
• กําหนดค่าโปรไฟล์ทรัพยากรใน Fabric
• ภาพรวมการเรียกเก็บเงิน Autoscale Spark
• รันไทม์ Apache Spark ใน Fabric