การเลือกเคอร์เนลโน้ตบุ๊กใน Microsoft Fabric

สมุดบันทึกใน Microsoft Fabric สนับสนุนเคอร์เนลสามชนิด: Python, Spark และ T-SQL เคอร์เนล Spark รองรับสี่ภาษา ได้แก่ PySpark, SparkSQL, Scala และ SparkR ซึ่งทั้งหมดนี้ได้รับการสนับสนุนโดยการประมวลผล Spark เดียวกัน คู่มือนี้มุ่งเน้นไปที่การตัดสินใจระหว่างเคอร์เนล Python และเคอร์เนล Spark เนื่องจากเคอร์เนลเหล่านี้เป็นตัวเลือกที่พบบ่อยที่สุดสําหรับปริมาณงานวิศวกรรมข้อมูล ทั้งสองทํางานในประสบการณ์โน้ตบุ๊กเดียวกัน แต่แตกต่างกันในรูปแบบการประมวลผล ความสามารถในการปรับขนาด ความสามารถของกลไกจัดการ และความเข้ากันได้ของ Delta Lake คู่มือนี้ให้การประเมินที่สมดุลเพื่อช่วยคุณเลือกเคอร์เนลที่เหมาะสม และหลีกเลี่ยงความเข้าใจผิดทั่วไปเกี่ยวกับต้นทุนและประสิทธิภาพ

สำคัญ

การเลือกเคอร์เนลโน้ตบุ๊กไม่ได้เกี่ยวกับต้นทุนหรือขนาดข้อมูลเท่านั้น การกําหนดค่าการประมวลผล ข้อกําหนดคุณลักษณะ Delta Lake ความสมบูรณ์ของกลไกจัดการ และการเติบโตของข้อมูลที่คาดหวัง ล้วนมีบทบาทสําคัญในการตัดสินใจที่ถูกต้อง

ทําความเข้าใจตัวเลือกการประมวลผลของคุณ

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

การประมวลผลเคอร์เนล Python

เคอร์เนล Python ทํางานบนเครื่องโหนดเดียวที่มีค่าเริ่มต้นเป็น 2 vCores (1 CU) และสามารถกําหนดค่าให้เริ่มต้นได้สูงสุด 64 vCores (32 CU) สภาพแวดล้อมนี้ไม่มีการดําเนินการแบบกระจาย พูลเริ่มต้นเริ่มต้นในเวลาประมาณ 5 วินาที ทําให้ทํางานแบบโต้ตอบได้อย่างรวดเร็ว

การประมวลผลเคอร์เนลสปาร์ค

เคอร์เนล Spark ใช้พูล Spark พร้อมตัวเลือกการกําหนดค่าหลายแบบ:

การกําหนดค่าคลัสเตอร์ vCores พร้อมใช้งานสําหรับผู้ดําเนินการ เวลาเริ่มต้นเซสชัน CU ที่ใช้หลังจากเริ่มเซสชัน
พูลเริ่มต้น (ค่าเริ่มต้น) โหนดผู้ปฏิบัติงาน 8 คอร์ เปิดใช้งานการปรับขนาดอัตโนมัติ เริ่มต้นเป็นโหนดเดียวและปรับขนาดเชิงรุกเป็นผู้ปฏิบัติงานเฉพาะหนึ่งคนภายในไม่กี่นาทีหลังจากเริ่มเซสชัน ~5 วินาที 8 CU (ขั้นต่ํา หลังขยายขนาดเชิงรุก)
โหนดเดียว*, 8-vCore (ผ่านพูลเริ่มต้น) ตัวดําเนินการและไดรเวอร์ 8 คอร์ใช้โหนดเดียวกัน ~5 วินาที (พร้อมสระอุ่น) 4 คิว
โหนดเดียว*, พูลแบบกําหนดเอง 4-vCore ตัวดําเนินการและไดรเวอร์ 4 คอร์ใช้โหนดเดียวกัน ต้องใช้พูลที่กําหนดเอง การเริ่มต้นเซสชันโดยทั่วไปจะอยู่ระหว่าง 3-5 นาที 2 คิว
พูลแบบกําหนดเองแบบหลายโหนด เครื่องชั่งที่มีขนาดคลัสเตอร์ โดยทั่วไปการเริ่มต้นเซสชันจะอยู่ระหว่าง 3-5 นาที แตก ต่าง กัน

เมื่อใช้พูลเริ่มต้น เซสชัน 8-vCore Spark โหนดเดียวจะเริ่มในเวลาประมาณ 5 วินาที ซึ่งเทียบได้กับเคอร์เนล Python คลัสเตอร์ Spark โหนดเดียวรักษาต้นทุนใกล้เคียงกับเคอร์เนล Python ในขณะที่ให้การเข้าถึงความสามารถดั้งเดิมของ Spark ทั้งหมด รวมถึง Native Execution Engine (NEE)

Note

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

  • โหนดเดียวที่จัดเตรียมมากเกินไป: เริ่มต้นด้วย Spark Pool (นั่นคือ Starter Pool) ที่กําหนดค่าด้วยการ ปรับขนาดอัตโนมัติ และ การจัดสรรแบบไดนามิก ที่เปิดใช้งานโดย ตั้งค่าการปรับขนาดอัตโนมัติ เป็น 1 ถึง > 1 โหนด สร้างรายการ สภาพแวดล้อม ที่อ้างอิง Spark Pool และตั้งค่าจํานวนผู้ดําเนินการเป็น 1 โน้ตบุ๊กที่ใช้การจัดเตรียมสภาพแวดล้อมนี้กับคลัสเตอร์ Spark โหนดเดียว ซึ่งทั้งไดรเวอร์และตัวดําเนินการใช้ทรัพยากรทั้งหมดร่วมกัน
  • โหนดเดี่ยวแบบคลาสสิก: สร้าง Spark Pool โดยตั้งค่าจํานวนโหนดสูงสุดเป็น 1 การกําหนดค่านี้ใช้ได้กับการเปิดหรือปิดใช้งาน การปรับขนาดอัตโนมัติ และ การจัดสรรแบบไดนามิก เนื่องจากการเลือกไม่มีผลต่อกลยุทธ์การเตรียมใช้งาน โน้ตบุ๊กที่ใช้ Spark Pool นี้มีวี-คอร์ 50% ที่จัดสรรให้กับไดรเวอร์ และ 50% ที่จัดสรรเป็นตัวดําเนินการ

ประสิทธิภาพตามมาตราส่วนปริมาณงาน

เกณฑ์มาตรฐานที่เปรียบเทียบ Fabric Spark กับ Native Execution Engine กับเอ็นจิ้น Python เครื่องเดียว (เช่น Pandas, DuckDB หรือ Polars) ในปริมาณงาน ELT แบบ end-to-end แสดงรูปแบบที่ชัดเจนตามมาตราส่วนข้อมูล:

มาตราส่วนข้อมูล (บีบอัด) ข้อได้เปรียบของเครื่องยนต์
ขนาดเล็กพิเศษ (< ~140 MB) เอ็นจิ้น Python เครื่องเดียว (DuckDB, Polars) เร็วกว่า
ขนาดเล็ก (~1–2 GB) เอ็นจิ้น Python ยังคงมีข้อได้เปรียบ แต่ Fabric Spark พร้อม NEE สามารถแข่งขันได้เนื่องจากจํานวนคอร์ที่ใช้ได้สําหรับแต่ละเอ็นจิ้นเพิ่มขึ้น โดยเฉพาะอย่างยิ่งสําหรับการดําเนินการที่เขียนหนัก
ขนาดเล็ก-กลาง (~10–13 GB) Fabric Spark พร้อม Native Execution Engine สามารถแข่งขันได้หรือเร็วกว่าเครื่องยนต์เครื่องเดียวส่วนใหญ่ เอ็นจิ้น Python เครื่องเดียวอาจพบข้อผิดพลาดหน่วยความจําไม่เพียงพอ (OOM) ที่จํานวน vCore ที่ต่ํากว่า
ปานกลางขึ้นไป (~100 GB+) สําหรับปริมาณงานส่วนใหญ่ Fabric Spark พร้อม Native Execution Engine เป็นเครื่องมือที่เร็วและน่าเชื่อถือที่สุด

ปรับขนาดได้มากกว่าข้อมูลขนาดเล็ก

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

ความเข้ากันได้ของ Delta Lake

ความเข้ากันได้ของ Delta Lake เป็นข้อพิจารณาที่สําคัญในการเลือกเอ็นจิ้น Fabric Spark รองรับ Delta Lake แบบเนทีฟและมีคุณสมบัติครบถ้วน ในขณะที่เอ็นจิ้น Python อาจมีช่องว่างที่มีความหมาย:

สำคัญ

ตารางการสนับสนุนคุณลักษณะต่อไปนี้แสดงสถานะของแต่ละเอ็นจิ้น ณ เดือนมิถุนายน 2026 และอิงตามการทดสอบโดยตรงกับ Fabric Spark Runtime 1.3 และ 2.0 ระบบนิเวศ Python ของซอฟต์แวร์โอเพ่นซอร์ส (OSS) สําหรับ Delta Lake กําลังเคลื่อนที่อย่างรวดเร็ว delta-rs, DuckDB และ Polars ทั้งหมดจัดส่งรุ่นที่เผยแพร่บ่อยครั้งซึ่งเพิ่มการสนับสนุนเพิ่มเติมสําหรับโปรโตคอลเดลต้าเป็นระยะ ตรวจสอบกับเอกสารปัจจุบันและบันทึกประจํารุ่นสําหรับแต่ละเครื่องยนต์เสมอก่อนที่จะใช้คุณสมบัติเฉพาะในการผลิต:

คุณสมบัติทะเลสาบเดลต้า ผ้าประกายไฟ เดลต้า-อาร์เอส (Python) ดั๊กดีบี ขั้วโลก
อ่านตารางเดลต้า ✅ ✅ ✅ ✅
เขียนตารางเดลต้า ✅ ✅ ผนวก เขียนทับ (รวมถึง predicate-based), UPDATE, DELETE, MERGE ⚠️ แทรกเท่านั้น (ต้อง); ATTACH ... (TYPE delta, READ_WRITE)ไม่มี UPDATE/DELETE/MERGE; ใช้ delta-rs สําหรับการดําเนินการเขียนอื่นๆ ⚠️ ผนวก เขียนทับ (รวมถึง predicate-based) ผสานเท่านั้น ไม่มีการอัปเดต/ลบ
การรับประกัน ACID / การควบคุมการทํางานพร้อมกันในแง่ดี ✅ ✅ ⚠️ INSERT เป็นภาคผนวกเท่านั้น ไม่มีการตรวจจับความขัดแย้งของพื้นเมือง ใช้ delta-rs กับการปักหมุดเวอร์ชันสําหรับการแยกการอ่านแล้วเขียน ⚠️ OCC ในการเขียน การอ่านโพลาร์อยู่นอกขอบเขตธุรกรรม—ต้องมีการปักหมุดเวอร์ชันที่ชัดเจนสําหรับการแยกการอ่านแล้วเขียน
วิวัฒนาการของสคีมาในการเขียน ✅ ✅ ❌ ไม่มีวิวัฒนาการของสคีมาใน INSERT ✅
การแม็ปคอลัมน์ ✅ ❌ ✅ ❌
เวกเตอร์การลบ (อ่าน) ✅ ❌ ✅ ✅
เวกเตอร์การลบ (เขียน) ✅ ❌ ❌ ❌
การขยายประเภท (อ่าน) ✅ ❌ ✅ ❌
การขยายประเภท (เขียน) ✅ ❌ ❌ ❌
การข้ามไฟล์ ✅ ✅ ✅ ✅
การเขียนแบบแบ่งพาร์ติชัน ✅ ✅ ❌ ใช้ delta-rs เพื่อเขียนด้วยการแบ่งพาร์ติชัน ✅
การจัดกลุ่มของเหลว (เขียน) ✅ ❌ ❌ ❌
การเดินทางข้ามเวลา ✅ ✅ ✅ ✅
ฟื้นฟู ✅ ✅ ❌ ใช้ delta-rs เพื่อคืนค่าตาราง ❌ ใช้ delta-rs เพื่อคืนค่าตาราง
โคลนตื้น (สร้าง) ✅ ❌ ❌ ❌
โคลนตื้น (อ่าน) ✅ ❌ ❌ ❌
การติดตามแถว ✅ ⚠️ การอ่านและเขียนสําเร็จ แต่ไม่สามารถเข้าถึงการติดตาม _metadata แถวได้ ไปป์ไลน์ที่ใช้ row_id สําหรับการขจัดข้อมูลซ้ําซ้อนหรือการเก็บข้อมูลการเปลี่ยนแปลง (CDC) ต้องใช้ Spark เพื่ออ่าน ⚠️ การอ่านและเขียนสําเร็จ แต่ไม่สามารถเข้าถึงการติดตาม _metadata แถวได้ไปป์ไลน์ที่ใช้ row_id สําหรับการขจัดข้อมูลซ้ําซ้อนหรือ CDC ต้องใช้ Spark เพื่ออ่าน ⚠️ การอ่านและเขียนสําเร็จ แต่ไม่สามารถเข้าถึงการติดตาม _metadata แถวได้ไปป์ไลน์ที่ใช้ row_id สําหรับการขจัดข้อมูลซ้ําซ้อนหรือ CDC ต้องใช้ Spark เพื่ออ่าน
คอลัมน์ข้อมูลประจําตัว (อ่าน) ✅ ✅ ✅ ✅
คอลัมน์ข้อมูลประจําตัว (เขียน) ✅ ❌ ❌ ❌
คอลัมน์ที่สร้างขึ้น (อ่าน) ✅ ✅ ✅ ✅
คอลัมน์ที่สร้างขึ้น (เขียน) ✅ ❌ ❌ ❌
เปลี่ยนฟีดข้อมูล (อ่าน) ✅ ✅ ❌ ใช้ delta-rs เพื่ออ่านฟีดข้อมูลการเปลี่ยนแปลง ❌ ใช้ delta-rs เพื่ออ่านฟีดข้อมูลการเปลี่ยนแปลง
เปลี่ยนฟีดข้อมูล (เขียน) ✅ ❌ ❌ ❌
จุดตรวจ V2 (อ่าน) ✅ ❌ ✅ ❌
จุดตรวจ V2 (เขียน) ✅ ❌ ❌ ❌
ช่วงเวลาจุดตรวจ ✅ กําหนดค่าได้ (ค่าเริ่มต้น 10) ⚠️ กําหนดค่าได้ (ค่าเริ่มต้น 100) ❌ INSERT ไม่ได้เขียนจุดตรวจ บันทึกเติบโตอย่างไร้ขอบเขตโดยไม่ต้องบํารุงรักษาจากภายนอกผ่าน Delta-RS ⚠️ กําหนดค่าได้ (ค่าเริ่มต้น 100)
เพิ่มประสิทธิภาพ ✅ ✅ ❌ ใช้ delta-rs เพื่อเพิ่มประสิทธิภาพ ❌ ใช้ delta-rs เพื่อเพิ่มประสิทธิภาพ
การกระชับอัตโนมัติ ✅ ❌ ❌ ❌
สูญญากาศ ✅ ❌ ความเสี่ยง: สะสมไฟล์กําพร้า ❌ ความเสี่ยง: สะสมไฟล์กําพร้า ❌ ความเสี่ยง: สะสมไฟล์กําพร้า
ไลท์สูญญากาศ ✅ ✅ ❌ ใช้ delta-rs เพื่อดูดฝุ่น lite ❌ ใช้ delta-rs เพื่อดูดฝุ่น lite

ความหมายที่สําคัญ:

  • คุณสมบัติเดลต้าที่ใหม่กว่า: การรองรับคุณสมบัติ Delta Lake ที่ใหม่กว่า รวมถึงการขยายประเภท จุดตรวจสอบ v2 การจัดกลุ่มของเหลว คอลัมน์ข้อมูลประจําตัว การเขียนฟีดข้อมูลเปลี่ยน และการอ่านโคลนแบบตื้น ไม่สอดคล้องกันหรือไม่มีในเอ็นจิ้น OSS Python หากไปป์ไลน์ข้อมูลของคุณขึ้นอยู่กับคุณลักษณะใดๆ เหล่านี้ ให้ใช้ Fabric Spark ถือว่าเอ็นจิ้น Python เป็นส่วนเสริมของ Spark สําหรับปริมาณงานเฉพาะ (การอ่านที่มีน้ําหนักเบา การพัฒนาในเครื่อง ภาคผนวกอย่างง่าย) แทนที่จะเป็นการแทนที่เอนกประสงค์

  • เวกเตอร์การลบ: เวกเตอร์การลบเป็นแนวทางปฏิบัติที่ดีที่สุดสําหรับตารางเดลต้า (เปิดใช้งานโดยค่าเริ่มต้นโดยเริ่มใน Fabric Spark Runtime 2.0) เนื่องจากช่วยปรับปรุงประสิทธิภาพของการดําเนินการ MERGE, UPDATE และ DELETE อย่างมากผ่านกลยุทธ์การผสานเมื่ออ่าน ไม่มีเอ็นจิ้น Python (delta-rs, DuckDB หรือ Polars) รองรับการเขียนเวกเตอร์การลบ หากคุณใช้กลไกจัดการ Python ใดๆ เพื่อเขียนลงในตารางที่เปิดใช้งานเวกเตอร์การลบ คุณจะพบข้อผิดพลาดความเข้ากันได้

  • การรับประกัน ACID: ไม่ใช่ทุกเอ็นจิ้น Python ที่ให้การรับประกัน ACID ดั้งเดิม Delta-rs รองรับการควบคุมการทํางานพร้อมกันในแง่ดี (OCC) สําหรับการดําเนินการผสาน อัปเดต และลบ อย่างไรก็ตาม ไปป์ไลน์ข้ามเครื่องยนต์ที่ DuckDB หรือ Polars ทําการอ่านและ delta-rs ทําการเขียนจําเป็นต้องมีการปักหมุดเวอร์ชันที่ชัดเจนทั้งสองด้านเพื่อรักษาการแยกการอ่าน-เขียน DuckDB INSERT เป็นการดําเนินการผนวกอย่างเดียวโดยไม่มีการตรวจหาข้อขัดแย้ง

  • จุดตรวจสอบ: ไม่ใช่ทุกเอ็นจิ้น Python ที่เขียนจุดตรวจสอบ และเอ็นจิ้นเหล่านั้นที่มีค่าเริ่มต้นเป็นทุกๆ 100 คอมมิต แทนที่จะเป็นค่าเริ่มต้นของ Spark ของทุกๆ 10 คอมมิต DuckDB INSERT ไม่เคยเขียนจุดตรวจสอบ ทําให้บันทึกธุรกรรมเดลต้าเติบโตขึ้นโดยไม่มีขอบเขต พิจารณาตั้งค่าช่วงเวลาจุดตรวจสอบที่ต่ํากว่าใน delta-rs และ Polars และเรียกใช้การบํารุงรักษา delta-rs เป็นระยะสําหรับตารางที่เขียนโดย DuckDB

  • การติดตามแถว: กลไกจัดการ Python ทั้งหมดสามารถอ่านและเขียนลงในตารางที่เปิดใช้งานการติดตามแถว แต่_metadataคอลัมน์ที่มีrow_idและไม่row_commit_versionสามารถเข้าถึงได้ภายนอก Spark ไปป์ไลน์ที่ใช้ row_id ในการขจัดข้อมูลซ้ําซ้อนหรือ CDC ต้องใช้ Spark ในการอ่าน

  • เพิ่มประสิทธิภาพและสูญญากาศ: เอ็นจิ้น Python อาศัยdeltalakeไลบรารีสําหรับการบดอัดและสุญญากาศ แม้ว่า delta-rs จะรวดเร็วสําหรับการดําเนินการเหล่านี้ แต่วิธีการนี้แนะนําการจัดการการพึ่งพาเพิ่มเติม และการดําเนินการไม่ได้ถูกประสานโดยกําเนิดในแบบที่อยู่ใน Spark ตารางที่เขียนผ่านเอ็นจิ้น Python โดยเฉพาะจะสะสมไฟล์ขนาดเล็กและบันทึกธุรกรรมที่ไม่มีขอบเขตโดยไม่มีการบํารุงรักษาอย่างชัดเจน

  • โคลนตื้น: เอ็นจิ้น Python ไม่รองรับการอ่านตารางที่สร้างผ่านโคลนตื้นเนื่องจากข้อจํากัดในการแก้ปัญหาเส้นทางสัมบูรณ์ ไม่มีเอ็นจิ้น Python รองรับการสร้างโคลนตื้น

ความสมบูรณ์ของกลไกจัดการและการสนับสนุนของ Microsoft

รองรับ Fabric Spark

Fabric Spark เป็น Apache Spark แบบโอเพ่นซอร์สของ Microsoft Microsoft รักษาและจัดส่งรันไทม์ ซึ่งหมายความว่า:

  • Microsoft รองรับการติดต่อภายในของ Spark และ Delta Lake แบบครบวงจร รวมถึง Native Execution Engine (NEE) ซึ่งสร้างขึ้นบน Velox และ Apache Gluten
  • คุณสามารถเปิดตั๋วสนับสนุนสําหรับพฤติกรรม Spark แผนการสืบค้น ปัญหาหน่วยความจํา และข้อบกพร่องของกลไกจัดการได้
  • การปรับปรุงประสิทธิภาพจะถูกจัดส่งอย่างต่อเนื่องโดยเป็นส่วนหนึ่งของการอัปเดตรันไทม์ของ Fabric โค้ดที่มีอยู่ของคุณจะเร็วขึ้นโดยไม่ต้องเปลี่ยนโค้ด

รองรับเอ็นจิ้น Python

Microsoft ไม่ได้รักษาส้อมของเอ็นจิ้น OSS Python เช่น DuckDB หรือ Polars การสนับสนุนจํากัดเฉพาะปัญหาในการผสานรวม OneLake ที่จัดส่งโดยเป็นส่วนหนึ่งของรันไทม์ Fabric เช่น การรับรองความถูกต้องหรือการเข้าถึงระบบไฟล์ หากคุณพบการถดถอยของประสิทธิภาพ ข้อบกพร่องของกลไกจัดการ หรือ API ที่ใช้งานไม่ได้ระหว่างเวอร์ชันไลบรารี คุณจําเป็นต้องมีส่วนร่วมโดยตรงกับชุมชนโอเพนซอร์สสําหรับไลบรารีเหล่านั้น

วุฒิภาวะการดําเนินงาน

ประสบการณ์ในโลกแห่งความเป็นจริงในการสร้างเกณฑ์มาตรฐาน ELT แบบ end-to-end ด้วยกลไกเหล่านี้เน้นความแตกต่างที่มีความหมายในวุฒิภาวะการดําเนินงาน:

  • Spark: โค้ดที่เขียนสําหรับรันไทม์เวอร์ชันเดียวจะทํางานโดยไม่มีการแก้ไขในเวอร์ชันที่ใหม่กว่า และทํางานได้เร็วขึ้นเนื่องจากการลงทุนด้านวิศวกรรมของ Microsoft อย่างต่อเนื่อง Spark UI และการวัดและส่งข้อมูลทางไกลของ Fabric ให้การตรวจสอบแบบสดพร้อมการมองเห็นแบบสอบถามที่ใช้งานอยู่ แผนการดําเนินการ และการเรียกใช้งานในอดีตอย่างเต็มที่
  • DuckDB และ Polars: การเปลี่ยนแปลง API และพฤติกรรมระหว่างเวอร์ชันอาจต้องมีการปรับโครงสร้างโค้ดใหม่เมื่อเอ็นจิ้นเติบโตเต็มที่และ API มีการพัฒนา เอ็นจิ้นทั้งสองไม่มีการตรวจสอบแบบสด - เมื่องานทํางานนานกว่าที่คาดไว้ จะไม่มีอะไรเทียบเท่ากับ Spark UI เพื่อทําความเข้าใจว่าเกิดอะไรขึ้น การรับรองความถูกต้องกับ OneLake อาจต้องมีวิธีแก้ปัญหาเฉพาะรุ่น
  • ค่าใช้จ่ายของสแต็กข้อมูลที่ประกอบได้: การใช้ DuckDB หรือ Polars สําหรับเวิร์กโฟลว์ ELT เต็มรูปแบบโดยทั่วไปหมายถึงการรวมไลบรารีหลายไลบรารีเข้าด้วยกัน (เช่น DuckDB สําหรับการสแกนและแปลง delta-rs ข้อมูล สําหรับการเขียนและการบํารุงรักษา) ความเข้ากันได้ของไลบรารีจําเป็นต้องได้รับการรักษาระหว่างส่วนประกอบ และควรพิจารณาเมื่อใดก็ตามที่เวอร์ชันของไลบรารีได้รับการอัปเกรดเกินกว่าที่จัดส่งในรันไทม์

คําแนะนําในการตัดสินใจ

ใช้เคอร์เนล Python เมื่อ

  • ข้อมูลของคุณมีขนาดเล็ก - บีบอัดประมาณ 1 GB - และประสิทธิภาพดิบบนกลไกเครื่องเดียวมีความสําคัญที่สุด
  • คุณกําลังสร้างการประสานงาน API ที่มีน้ําหนักเบา การผสานรวม REST/gRPC หรือระบบอัตโนมัติของโฟลว์การควบคุม ซึ่งการประมวลผลแบบกระจายจะเพิ่มค่าใช้จ่ายที่ไม่จําเป็น
  • คุณกําลังทําการสํารวจแบบโต้ตอบอย่างรวดเร็วของชุดข้อมูลขนาดเล็ก ซึ่งเวลาแฝงของคิวรีเฉพาะกิจเป็นสิ่งสําคัญ
  • ปริมาณงานของคุณต้องการเวอร์ชัน Python ที่เก่ากว่าที่จัดส่งในรันไทม์ Fabric Spark ปัจจุบัน
  • คุณเข้าใจและยอมรับข้อจํากัดของคุณลักษณะ Delta Lake ของกลไกจัดการ Python ที่คุณใช้อยู่

ใช้เคอร์เนล Spark เมื่อ

  • ข้อมูลของคุณมีขนาด 1 GB หรือใหญ่กว่าในรูปแบบบีบอัด หรือคุณคาดหวังว่าข้อมูลจะเติบโตถึงขนาดนั้น
  • คุณต้องเข้ากันได้กับ Delta Lake อย่างเต็มรูปแบบ รวมถึงเวกเตอร์การลบ การแมปคอลัมน์ การขยายประเภท OPTIMIZE, VACUUM และการรับประกัน ACID
  • คุณต้องมีคุณลักษณะระดับการผลิต เช่น ตัวแปรสภาพแวดล้อม การจัดการไลบรารีตามรายการ การทํางานพร้อมกันสูง และการจัดกําหนดการงาน FAIR หรือเข้าก่อนออกก่อน (FIFO)
  • คุณต้องการการตรวจสอบแบบสดและการมองเห็นการดําเนินงานอย่างเต็มรูปแบบในงานที่กําลังทํางานอยู่
  • คุณพึ่งพา Spark-native APIs เช่น MLlib, Spark SQL หรือ Spark Streaming
  • คุณต้องการการสนับสนุนแบบครบวงจรของ Microsoft สําหรับกลไกการประมวลผลข้อมูลของคุณ
  • คุณต้องการความสามารถในการปรับขนาดจากการประมวลผลแบบโหนดเดียวเป็นแบบหลายโหนดโดยไม่ต้องเขียนโค้ดใหม่
  • คุณต้องเขียนสมุดบันทึกใน PySpark, SparkSQL, Scala หรือ SparkR

เคล็ดลับ

สําหรับปริมาณงานที่หรือสูงกว่ามาตราส่วนบีบอัด 1 GB ให้พิจารณาเริ่มต้นด้วยคลัสเตอร์ 8-vCore Spark โหนดเดียวโดยใช้พูลเริ่มต้น คุณจะได้รับเวลาเริ่มต้นเซสชันเกือบจะทันที ความสามารถของ Fabric Spark เต็มรูปแบบ รวมถึง NEE และความสามารถในการปรับขนาดเป็นหลายโหนดเมื่อจําเป็น ทั้งหมดนี้ในขณะที่ทํางานบนโหนดเดียว เช่น เคอร์เนล Python

ความแตกต่างที่สําคัญโดยย่อ

หมวดหมู่ เคอร์เนล Python เคอร์เนลสปาร์ค
การประมวลผลเริ่มต้น เครื่องเสมือนโหนดเดียว (VM) 2-vCore (ปรับขนาดได้สูงสุด 64 vCores) พูลเริ่มต้น: โหนดผู้ปฏิบัติงาน 8-vCore พร้อมการปรับขนาดอัตโนมัติ
การกําหนดค่าโหนดเดียวขั้นต่ํา 2 วีคอร์ 8 vCores (พูลเริ่มต้น, เริ่มต้น ~5 วินาที); 4 vCores (พูลที่กําหนดเอง เริ่มต้นนานขึ้น)
เวลาเริ่มต้น ~5 วินาที ~5 วินาที (สระเริ่มต้น); นานขึ้นสําหรับพูลที่กําหนดเอง
การดําเนินการแบบกระจาย No Yes
ภาษาที่รองรับ Python PySpark, SparkSQL, สกาล่า, SparkR
เวอร์ชัน Python มีหลายเวอร์ชัน เชื่อมโยงกับเวอร์ชันรันไทม์ของ Fabric Spark
Delta Lake (รองรับคุณสมบัติเต็มรูปแบบ) No Yes
การตรวจสอบแบบสด จำกัด แบบเต็ม (หน้าตรวจสอบงาน + Spark UI)
การสนับสนุนกลไกของ Microsoft การผสานรวม OneLake เท่านั้น รองรับรันไทม์เต็มรูปแบบ
การเข้าถึงไลบรารี Python ติดตั้ง pip pip ติดตั้ง + รายการสภาพแวดล้อม
API ดั้งเดิมของ Spark (MLlib, สตรีมมิ่ง) No Yes
คุณสมบัติการผลิต (สภาพแวดล้อม สภาพแวดล้อม) จำกัด แบบเต็ม
การสนับสนุนพร้อมกันสูง No Yes
ลําดับ V สําหรับโมเดลเซแมนติก Direct Lake ที่รวดเร็ว No Yes
แคชที่เก็บวัตถุที่เปิดใช้งานการเร่งการอ่านซ้ํา ขึ้นอยู่กับเครื่องยนต์ (DuckDB มีการแคชในตัว Polars ไม่มี) มี (แคชอัจฉริยะ)
ปรับขนาดเป็นหลายโหนด No Yes

อภิธานศัพท์

  • ธุรกรรม ACID: ชุดคุณสมบัติ (Atomicity, Consistency, Isolation, Durability) ที่รับประกันว่าการดําเนินการฐานข้อมูลจะได้รับการประมวลผลอย่างน่าเชื่อถือ Delta Lake ใช้ความหมายของ ACID โดยใช้การควบคุมการทํางานพร้อมกันในแง่ดีและบันทึกธุรกรรม
  • การควบคุมการทํางานพร้อมกันในแง่ดี (OCC): กลยุทธ์การทํางานพร้อมกันที่ธุรกรรมดําเนินการโดยไม่ล็อก จากนั้นตรวจสอบ ณ เวลาคอมมิตว่าไม่มีการเปลี่ยนแปลงที่ขัดแย้งกันเกิดขึ้น Delta Lake ใช้ OCC ไปป์ไลน์ข้ามเครื่องยนต์ (เช่น การอ่าน Polars ตามด้วยการเขียน delta-rs) ต้องการการปักหมุดเวอร์ชันที่ชัดเจนเพื่อรักษาการแยก
  • การบดอัดอัตโนมัติ: คุณลักษณะ Delta Lake ในรันไทม์ Fabric Spark ที่รวมไฟล์ขนาดเล็กเป็นไฟล์ขนาดใหญ่โดยอัตโนมัติหลังจากการดําเนินการเขียน ซึ่งช่วยลดการกระจายตัวของไฟล์โดยไม่ต้องใช้ขั้นตอน OPTIMIZE แยกต่างหาก
  • เปลี่ยนฟีดข้อมูล (CDF): คุณลักษณะ Delta Lake ที่บันทึกการเปลี่ยนแปลงระดับแถว (แทรก อัปเดต ลบ) ในตาราง ทําให้สามารถประมวลผลข้อมูลส่วนเพิ่มและไปป์ไลน์ CDC ได้ เฉพาะ Fabric Spark เท่านั้นที่รองรับการเขียนข้อมูลเมตาของฟีดข้อมูลการเปลี่ยนแปลง (CDF) เอ็นจิ้น OSS Python สามารถอ่านได้ แต่ไม่สามารถสร้างได้
  • การแมปคอลัมน์: คุณลักษณะ Delta Lake ที่อนุญาตให้เปลี่ยนชื่อหรือทิ้งคอลัมน์ได้โดยไม่ต้องเขียนไฟล์ Parquet ต้นแบบใหม่ รองรับโดย Fabric Spark;ไม่รองรับโดย delta-rs หรือ Polars
  • delta-rs: การใช้งาน Rust แบบโอเพ่นซอร์สของโปรโตคอล Delta Lake พร้อมการผูก Python (deltalakeแพ็คเกจ PyPI) ให้การสนับสนุนการอ่าน/เขียนแบบเดลต้าในสภาพแวดล้อม OSS Python แต่มีความครอบคลุมคุณลักษณะที่แคบกว่าdelta-sparkที่รันไทม์ Fabric Spark กลับมา
  • เวกเตอร์การลบ: การเพิ่มประสิทธิภาพ Delta Lake ที่ใช้การผสานเมื่ออ่านเพื่อลดปริมาณข้อมูลที่เขียนใหม่ระหว่างการดําเนินการ MERGE, UPDATE และ DELETE เปิดใช้งานโดยค่าเริ่มต้นใน Fabric Spark Runtime 2.0 ไม่รองรับการเขียนโดยเอ็นจิ้น OSS Python ใดๆ
  • การจัดกําหนดการที่ยุติธรรม: นโยบายการจัดกําหนดการ Spark ที่จัดสรรทรัพยากรคลัสเตอร์อย่างเป็นธรรมในงานที่เกิดขึ้นพร้อมกัน เพื่อให้มั่นใจว่าไม่มีงานเดียวผูกขาดคลัสเตอร์
  • การจัดกําหนดการ FIFO: นโยบายการจัดกําหนดการ Spark ที่ดําเนินการงานตามลําดับ First-In-First-Out โดยให้ความสําคัญกับงานที่ส่งครั้งแรก
  • Liquid Clustering: คุณลักษณะ Delta Lake ที่จัดระเบียบข้อมูลใหม่ทีละน้อยเพื่อประสิทธิภาพการสืบค้นที่เหมาะสมที่สุดโดยไม่ต้องมีการแบ่งพาร์ติชันที่ชัดเจน รองรับโดย Fabric Spark เท่านั้น
  • NEE (Native Execution Engine): เอ็นจิ้นการสืบค้น C++ แบบเวกเตอร์ที่สร้างขึ้นบน Velox และ Apache Gluten ที่เร่งปริมาณงาน Fabric Spark NEE พร้อมใช้งานโดยไม่มีค่าใช้จ่ายในการประมวลผลเพิ่มเติมและไม่ต้องเปลี่ยนโค้ด
  • การติดตามแถว: คุณลักษณะ Delta Lake ที่กําหนดเสถียร row_id ภาพและ row_commit_version ให้กับแต่ละแถวผ่าน _metadata คอลัมน์ กลไกจัดการทั้งหมดสามารถอ่านและเขียนไปยังตารางที่เปิดใช้งานการติดตามแถว แต่มีเพียง Fabric Spark เท่านั้นที่สามารถเข้าถึงเนื้อหาของ_metadataคอลัมน์ได้
  • พูล Spark: ทรัพยากรการประมวลผลที่ใช้ร่วมกันสําหรับการเรียกใช้ปริมาณงาน Spark แบบกระจาย พูลเริ่มต้นมีโหนดที่อุ่นไว้ล่วงหน้าสําหรับเวลาเริ่มต้นเซสชันที่เกือบจะทันที (~5 วินาที) โดยเปิดใช้งานการปรับขนาดอัตโนมัติโดยค่าเริ่มต้น
  • ลําดับ V: การปรับแต่งการเขียนแบบ Fabric ที่จัดเรียงและบีบอัดข้อมูล Parquet ในลักษณะที่ช่วยเพิ่มประสิทธิภาพการอ่านสําหรับโมเดลเชิงความหมาย Power BI Direct Lake และเส้นทางการอ่าน Fabric อื่น ๆ
  • แคชอัจฉริยะ: แคชดิสก์อัจฉริยะใน Fabric Spark ที่เพิ่มความเร็วในการอ่านซ้ําๆ ของไฟล์ตารางเดลต้าเดียวกันโดยการแคชข้อมูลไฟล์ในเครื่องบนโหนดตัวดําเนินการ

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

  • Last updated on