หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
บทความนี้เป็นระยะที่ 1 จาก 4 ในชุดแนวทางปฏิบัติที่ดีที่สุดสําหรับการโยกย้าย Azure Synapse Spark ไปยัง Microsoft Fabric
เริ่มต้นที่นี่ก่อนที่คุณจะย้ายสมุดบันทึก ข้อกําหนดงาน Spark พูล หรือข้อมูลเมตาของทะเลสาบ บทความนี้ช่วยคุณประเมินขอบเขตของอสังหาริมทรัพย์ Synapse Spark เลือกวิธีการย้ายข้อมูลที่ตรงกับความเสี่ยงที่ยอมรับได้และไทม์ไลน์การจัดส่ง และทําความเข้าใจความแตกต่างของ Fabric ที่ส่งผลต่อการวางแผน
ในตอนท้ายของขั้นตอนนี้ คุณควรทราบว่าต้องย้ายอะไรบ้าง ควรใช้รูปแบบการโยกย้ายใด ความเสี่ยงหลักที่เข้ากันได้อยู่ที่ใด และข้อจํากัดการย้อนกลับหรือการเรียกใช้แบบขนานใดที่คุณต้องคํานึงถึง
ในบทความนี้ คุณจะได้เรียนรู้วิธีการ:
- ประเมินรอยเท้า Synapse Spark ของคุณ
- เลือกระหว่างการยกและเปลี่ยน การปรับปรุงให้ทันสมัยเป็นระยะ และการวิ่งแบบขนาน
- บัญชีสําหรับข้อจํากัดการย้อนกลับและการซิงโครไนส์
- ตรวจสอบคุณสมบัติหลักและความแตกต่างของสถาปัตยกรรมระหว่าง Synapse Spark และ Fabric Spark
ประเมินรอยเท้า Synapse Spark ของคุณ
Azure Synapse Analytics ครอบคลุมปริมาณงานหลายประเภท คู่มือนี้เน้นการย้าย Spark pools, notebooks, คํานิยามงาน Spark, ฐานข้อมูล lake และ metadata ของ Hive Metastore ไปยัง Fabric สําหรับพูล SQL เฉพาะ ไปป์ไลน์ Data Explorer และคําแนะนําในการย้ายความปลอดภัย โปรดดูคู่มือที่แสดงร่วมกัน
| ปริมาณงาน Synapse | Fabric ปลายทาง | เครื่องมือ/เส้นทางการโยกย้าย |
|---|---|---|
| สปาร์คพูล | Fabric Spark (เลคเฮาส์) | Spark Migration Assistant (พรีวิว); การโยกย้ายพูล/env ด้วยตนเอง |
| โน้ต บุ๊ค | สมุดบันทึกผ้า | Spark Migration Assistant; การปรับโครงสร้างโค้ดสําหรับ API เฉพาะ Synapse |
| ข้อกําหนดงาน Spark | คําจํากัดความของงาน Fabric Spark | Spark Migration Assistant (แนะนํา);การสร้างด้วยตนเองหากจําเป็น |
| ฐานข้อมูลทะเลสาบ | แคตตาล็อก Fabric Lakehouse | Spark Migration Assistant (ตารางเดลต้าผ่านทางลัด); การส่งออก/นําเข้า HMS สําหรับที่ไม่ใช่เดลต้า |
| ไฮฟ์ เมตาสโตร์ | แคตตาล็อก Fabric Lakehouse | โน้ตบุ๊กส่งออก/นําเข้า HMS; ทางลัด OneLake สําหรับข้อมูล |
| บริการที่เชื่อมโยง | การเชื่อมต่อ Fabric / Key Vault | สร้างการเชื่อมต่อ Fabric โยกย้ายข้อมูลลับไปยัง Key Vault ปรับโครงสร้างโค้ดโน้ตบุ๊ก |
เรียกใช้เครื่องมือการประเมิน Fabric
ก่อนวางแผนการย้ายข้อมูล ให้เรียกใช้ Fabric Assessment Tool เพื่อสร้างรายงานที่ครอบคลุมของพื้นที่ทํางานต้นทาง Synapse ของคุณ เครื่องมือนี้จะสแกนพื้นที่ทํางานของคุณและรวบรวมข้อมูลสรุปของออบเจ็กต์ทั้งหมด เช่น พูล Spark, สมุดบันทึก, คําจํากัดความของงาน Spark, ฐานข้อมูล Lake, บริการที่เชื่อมโยง และการกําหนดค่า ซึ่งจะทําให้คุณเห็นภาพที่ชัดเจนของขอบเขตการย้ายข้อมูล
ดาวน์โหลดเครื่องมือ เครื่องมือการประเมิน Fabric มีอยู่ในที่เก็บ GitHub Microsoft fabric-toolbox ที่ microsoft/fabric-toolbox
เรียกใช้การประเมิน ชี้เครื่องมือไปที่พื้นที่ทํางาน Azure Synapse ของคุณ โดยจะสแกนรายการที่เกี่ยวข้องกับ Spark ทั้งหมดและสร้างรายงานที่มีจํานวนออบเจ็กต์ การกําหนดค่า การขึ้นต่อกัน และปัญหาความเข้ากันได้ที่อาจเกิดขึ้น
ตรวจสอบรายงาน ใช้ผลลัพธ์การประเมินเพื่อทําความเข้าใจขอบเขตของการย้ายข้อมูลของคุณ: จํานวนสมุดบันทึก พูล SJD และฐานข้อมูลที่ต้องย้าย บริการที่เชื่อมโยงใดที่กําลังใช้งานอยู่ และตัวบล็อกที่อาจเกิดขึ้น (พูล GPU คุณสมบัติที่ไม่รองรับ และอื่นๆ)
เคล็ดลับ
เรียกใช้เครื่องมือการประเมินตั้งแต่เนิ่นๆ ในกระบวนการวางแผนของคุณ รายงานช่วยให้คุณประเมินความพยายาม ระบุตัวบล็อก และจัดลําดับความสําคัญของปริมาณงานที่จะโยกย้ายก่อน นอกจากนี้ยังทําหน้าที่เป็นสินค้าคงคลังพื้นฐานสําหรับระยะที่ 1 ของรายการตรวจสอบการย้ายข้อมูล
รูปแบบการโยกย้าย
เลือกรูปแบบการโยกย้ายของคุณตามข้อจํากัดขององค์กร ความเสี่ยงที่ยอมรับได้ และไทม์ไลน์
รูปแบบการยกและเปลี่ยน
ย้ายปริมาณงาน Spark ทั้งหมดพร้อมกันโดยใช้ Migration Assistant โดยมีการเปลี่ยนแปลงเพียงเล็กน้อย มุ่งเน้นไปที่การทําให้สมุดบันทึกและงานทํางานใน Fabric โดยเร็วที่สุด — ปรับโครงสร้างเฉพาะสิ่งที่หยุดทํางาน (บริการที่เชื่อมโยง เส้นทางไฟล์ API ที่ไม่รองรับ) ยอมรับ as-isสถาปัตยกรรมปัจจุบัน
ใช้การยกและเลื่อนเมื่อ:
- พื้นที่ทํางาน Synapse ของคุณกําลังถูกปลดประจําการตามกําหนดเวลาที่กําหนด และคุณต้องดําเนินการอย่างรวดเร็ว
- ปริมาณงาน Spark ของคุณมีสถาปัตยกรรมที่ดีอยู่แล้ว (เดลต้าเป็นอันดับแรก โค้ดสะอาด การขึ้นต่อกันของบริการที่เชื่อมโยงเพียงเล็กน้อย)
- พื้นที่ทํางานของคุณสามารถจัดการได้สําหรับการโยกย้ายแบบครั้งเดียว และทีมของคุณสามารถจัดการกับความพยายามในการปรับโครงสร้างใหม่ได้ในสปรินต์เดียว
- ผู้บริโภคดาวน์สตรีม (Power BI, API) สามารถทนต่อหน้าต่างการสลับสั้นๆ ได้
การปรับปรุงให้ทันสมัยเป็นระยะ
โยกย้ายปริมาณงานทีละน้อยตามลําดับความสําคัญ และสร้างสถาปัตยกรรมใหม่ตามที่คุณดําเนินการ เริ่มต้นด้วยปริมาณงานที่มีมูลค่าสูงสุดหรือความเสี่ยงต่ําที่สุดก่อน เมื่อคุณย้ายแต่ละชุด ให้รวม Spark pools ให้อยู่ใน Environment น้อยลง นําแนวทางปฏิบัติที่ดีที่สุดของ lakehouse มาใช้ (Delta-first, V-order สําหรับผู้บริโภค BI) เปิดใช้งาน NEE และออกแบบใหม่สําหรับ Direct Lake
ใช้การปรับปรุงให้ทันสมัยแบบค่อยเป็นค่อยไปเมื่อ:
- คุณมีสภาพแวดล้อม Synapse ขนาดใหญ่หรือซับซ้อนที่มีหลายทีมและปริมาณงานที่หลากหลายซึ่งไม่สามารถย้ายได้ในช็อตเดียว
- สถาปัตยกรรมปัจจุบันของคุณมีหนี้ทางเทคนิคที่คุณต้องการจัดการ (รูปแบบที่ไม่ใช่เดลต้า การขึ้นต่อกันของจุดต่อเชื่อม พูล Spark ที่แผ่กิ่งก้านสาขา)
- คุณมีความยืดหยุ่นในไทม์ไลน์และต้องการปรับปรุงประสิทธิภาพและประสิทธิภาพด้านต้นทุนในระหว่างการย้ายข้อมูล
- ปริมาณงานที่แตกต่างกันมีเจ้าของที่แตกต่างกันและต้องการกําหนดการย้ายข้อมูลอิสระ
รูปแบบการวิ่งแบบขนาน
เรียกใช้ทั้งสองสภาพแวดล้อมพร้อมกันระหว่างการเปลี่ยน กําหนดเส้นทางปริมาณงาน Spark ใหม่ไปยัง Fabric ในขณะที่ปริมาณงานเดิมยังคงดําเนินต่อไปบน Synapse ตรวจสอบปริมาณงานที่ย้ายโดยการเปรียบเทียบผลลัพธ์แบบเคียงข้างกันก่อนที่จะตัด ค่อยๆ เลิกใช้งาน Synapse เมื่อสร้างความมั่นใจ
ใช้การเรียกใช้แบบขนานเมื่อ:
- ปริมาณงานของคุณมี SLA หรือข้อกําหนดด้านกฎระเบียบที่เข้มงวดซึ่งต้องการการตรวจสอบเพิ่มเติมก่อนที่จะมีการเคลื่อนย้าย
- คุณต้องพิสูจน์ประสิทธิภาพของ Fabric ตรงหรือเกินกว่า Synapse ก่อนที่ผู้มีส่วนได้ส่วนเสียจะอนุมัติการปลดประจําการ
- ผู้บริโภคปลายทางของคุณ (แดชบอร์ด, API, โมเดล ML) ไม่สามารถทนต่อความคลาดเคลื่อนใดๆ ระหว่างการเปลี่ยนผ่านได้
- คุณกําลังโยกย้ายไปป์ไลน์การผลิตที่ผลลัพธ์ที่ไม่ถูกต้องมีผลกระทบทางธุรกิจสูง (การรายงานทางการเงิน การปฏิบัติตามกฎระเบียบ)
การเรียกใช้แบบขนานทําให้เกิดปัญหาการซิงโครไนส์ข้อมูลที่คุณต้องออกแบบไว้ล่วงหน้า เลือกรูปแบบใดรูปแบบหนึ่งต่อไปนี้
- เลเยอร์ที่เก็บข้อมูลที่ใช้ร่วมกัน:ให้ทั้ง Synapse และ Fabric อ่านและเขียนไปยังที่เก็บข้อมูล ADLS Gen2 เดียวกันผ่านทางลัด OneLake วิธีนี้จะทําให้ทั้งสองแพลตฟอร์มอยู่ในไฟล์เดลต้าเดียวกัน แต่คุณต้องป้องกันความขัดแย้งในการเขียนโดยตรวจสอบให้แน่ใจว่ามีเพียงแพลตฟอร์มเดียวเท่านั้นที่เขียนลงในตารางที่กําหนดในแต่ละครั้ง
- เขียนครั้งเดียว อ่านทั้งสองอย่าง: ให้ Synapse เป็นตัวเขียนหลักในระหว่างการเปลี่ยน และให้ Fabric อ่านข้อมูลเดียวกันผ่านทางลัด หลังจากที่คุณตรวจสอบความถูกต้องของสมุดบันทึกที่ย้ายใน Fabric แล้ว ให้สลับเส้นทางการเขียนไปยังเป็น Fabric และทําให้ Synapse เป็นผู้บริโภคแบบอ่านอย่างเดียวจนกว่าจะเลิกใช้งาน นี่เป็นตัวเลือกที่ปลอดภัยที่สุดสําหรับการย้ายข้อมูลส่วนใหญ่
- การเขียนแบบสองทิศทาง: หลีกเลี่ยงการเรียกใช้ ETL เดียวกันในทั้งสองสภาพแวดล้อมพร้อมกัน เว้นแต่คุณจะมีเครื่องมือเปรียบเทียบและการกระทบยอดอัตโนมัติอยู่แล้ว การรวมแบบสองทิศทางมีแนวโน้มที่จะสร้างความแตกต่าง ความซ้ําซ้อน และค่าใช้จ่ายในการดําเนินงาน
การรันแบบขนานยังส่งผลต่อการจัดการการเปลี่ยนแปลง ในขณะที่ Synapse ยังคงเป็นสภาพแวดล้อมการพัฒนาที่ใช้งานอยู่ แต่โน้ตบุ๊ก ข้อกําหนดงาน Spark การกําหนดค่าพูล Spark หรือการเปลี่ยนแปลง Schema ฐานข้อมูลทะเลสาบที่ทําใน Synapse จะไม่แสดงโดยอัตโนมัติใน Fabric คุณต้องย้ายข้อมูลเนื้อหาที่ได้รับผลกระทบอีกครั้งเพื่อให้สภาพแวดล้อมทั้งสองสอดคล้องกัน
-
การเปลี่ยนแปลงรหัสสมุดบันทึก:เรียกใช้ Spark Migration Assistant อีกครั้ง หรือส่งออกซ้ําและนําเข้าสมุดบันทึกที่อัปเดตอีกครั้งด้วยตนเอง ใช้การปรับโครงสร้างโค้ดเฉพาะ Fabric อีกครั้ง รวมถึง
notebookutilsการอัปเดตเส้นทางไฟล์ และข้อมูลลับ Key Vault - จุดประกายการเปลี่ยนแปลงข้อกําหนดของงาน: ย้ายข้อมูลใหม่ผ่าน Migration Assistant หรือสร้าง SJD ที่อัปเดตใหม่ด้วยตนเองใน Fabric
- การเปลี่ยนแปลงการกําหนดค่าพูล Spark: อัปเดตสภาพแวดล้อม Fabric ที่สอดคล้องกันเพื่อให้ตรงกับขนาดโหนด การตั้งค่าการปรับขนาดอัตโนมัติ และไลบรารีที่แก้ไขแล้ว
- <การเปลี่ยนแปลงสคีมาฐานข้อมูล c0>Lake:เรียกใช้สมุดบันทึกการส่งออก/นําเข้า HMS อีกครั้ง หรือสร้างหรือแก้ไขตารางที่ได้รับผลกระทบด้วยตนเองในเลคเฮาส์ Fabric
เพื่อลดค่าใช้จ่ายในการโยกย้ายซ้ํา ให้สร้างการหยุดการเปลี่ยนแปลงที่ฝั่ง Synapse เมื่อการโยกย้ายเริ่มต้นขึ้น หากหลีกเลี่ยงการเปลี่ยนแปลงไม่ได้ ให้เก็บบันทึกการเปลี่ยนแปลงไว้เพื่อให้คุณสามารถเล่นซ้ําใน Fabric ก่อนตัดเปลี่ยนได้
ข้อควรพิจารณาในการย้อนกลับ
การโยกย้าย Synapse-to-Fabric เป็นการดําเนินการคัดลอก — จะไม่แก้ไขหรือลบพื้นที่ทํางาน Synapse ต้นทางของคุณ พูล Spark สมุดบันทึก และข้อมูลเดิมของคุณจะยังคงเหมือนเดิมตลอดกระบวนการ สิ่งนี้ทําให้การย้อนกลับตรงไปตรงมา:
- หากผลการย้ายข้อมูลไม่เป็นที่น่าพอใจ ให้ใช้พื้นที่ทํางาน Synapse ที่มีอยู่ต่อไป ไม่จําเป็นต้องย้อนกลับการเปลี่ยนแปลง
- ลบรายการ Fabric ที่ย้ายมา (โน้ตบุ๊ก, สภาพแวดล้อม, คําจํากัดความงาน Spark) และลองใหม่หลังจากแก้ไขปัญหาแล้ว
- ทางลัด OneLake ชี้ไปที่ที่เก็บข้อมูล ADLS Gen2 ที่มีอยู่ของคุณ — การลบทางลัดจะไม่ส่งผลต่อข้อมูลพื้นฐาน
- อย่าเลิกใช้งานพื้นที่ทํางาน Synapse ของคุณจนกว่าปริมาณงานที่ย้ายทั้งหมดจะได้รับการตรวจสอบความถูกต้องใน Fabric และผู้บริโภคดาวน์สตรีมจะถูกเปลี่ยนเส้นทาง
เคล็ดลับ
เริ่มต้นเล็ก ๆ และพิสูจน์ความมีชีวิตได้อย่างรวดเร็ว เลือกปริมาณงาน Spark ที่เป็นตัวแทนและโยกย้ายแบบ end-to-end ตั้งแต่การตั้งค่าพูลผ่านการปรับโครงสร้างโน้ตบุ๊กไปจนถึงการตรวจสอบความถูกต้อง เลือกสิ่งที่ใช้รูปแบบที่พบบ่อยที่สุดของคุณ (การเข้าถึงข้อมูล บริการที่เชื่อมโยง การดําเนินการแค็ตตาล็อก) แต่มีความเสี่ยงต่ําพอที่จะทําซ้ํา จัดทําเอกสารขั้นตอน ปัญหาที่พบ และวิธีแก้ไขเพื่อสร้างกระบวนการที่ทําซ้ําได้สําหรับการย้ายข้อมูลในภายหลัง
ความเท่าเทียมกันของคุณลักษณะและความแตกต่างที่สําคัญ
การทําความเข้าใจความแตกต่างทางสถาปัตยกรรมระหว่าง Synapse และ Fabric เป็นสิ่งสําคัญสําหรับการวางแผน ตารางต่อไปนี้เน้นความแตกต่างที่สําคัญในสถาปัตยกรรมการประมวลผลและความสามารถของ Spark
สําหรับการเปรียบเทียบแบบเต็ม โปรดดู เปรียบเทียบ Fabric และ Azure Synapse Spark: ความแตกต่างที่สําคัญ
การประมวลผลและสถาปัตยกรรม
| สมรรถนะ | <ค 0>Azure Synapse | ผ้า |
|---|---|---|
| โมเดลการปรับใช้ | PaaS (กําหนดค่าและจัดการทรัพยากร) | SaaS (ตามความจุ ไม่มีการจัดการโครงสร้างพื้นฐาน) |
| โมเดลการประมวลผล | สปาร์คพูล (ตามโหนด); ต้องมีอย่างน้อย 3 โหนด | หน่วยความจุ (CU) ที่ใช้ร่วมกันในปริมาณงานทั้งหมด Spark pools เป็นเทมเพลตการกําหนดค่า รองรับการดําเนินการโหนดเดียว การเรียกเก็บเงินแบบปรับขนาดอัตโนมัติสําหรับ Spark (จ่ายต่อการใช้งาน คล้ายกับโมเดล Synapse) |
| เครื่องยนต์ประกายไฟ | พูล Synapse Spark (Spark 3.4, 3.5); รองรับพูล GPU | Fabric Spark (รันไทม์ 1.2/1.3/2.0: Spark 3.4–4.0); ไม่รองรับ GPU ทํางานบนฮาร์ดแวร์รุ่นล่าสุดเพื่อประสิทธิภาพที่ดีขึ้น |
| การปรับมาตราส่วน | การปรับขนาดโหนดอัตโนมัติสําหรับ Spark (ขั้นต่ํา 3 โหนด) | โหนดปรับขนาดอัตโนมัติสําหรับ Spark (โหนดเดียวขั้นต่ํา); การปรับขนาดตามความจุ |
| การเริ่มต้นเซสชัน | ตามสระว่ายน้ํา; สตาร์ทเย็นสําหรับคลัสเตอร์ใหม่ | Starter Pools (การเริ่มต้นระดับวินาที); พูลสดแบบกําหนดเอง โหมดการทํางานพร้อมกันสูง |
| แบบจําลองต้นทุน | ต่อโหนดชั่วโมง (Spark); หยุดชั่วคราว/ดําเนินการต่อ | สองตัวเลือก: (1) Fabric Spark ใช้แบบจําลองการใช้ร่วมกันตามหน่วยความจุ (CU) หรือ (2) การเรียกเก็บเงินปรับขนาดอัตโนมัติสําหรับ Spark – จ่ายตามการใช้งานโหมด Spark |
จุดประกาย: Synapse Spark กับ Fabric Spark
| สมรรถนะ | ไซแนปส์ สปาร์ค | Fabric ประกายไฟ |
|---|---|---|
| เวอร์ชัน Spark | Spark 3.4 (EOL), 3.5 (พรีวิว) | Spark 3.4 (RT 1.2 EOL), 3.5 (RT 1.3 GA), 4.0 (RT 2.0 พรีวิว) |
| การเร่งความเร็วคิวรี | ไม่มีเอ็นจิ้นเร่งความเร็วดั้งเดิม | Native Execution Engine (Velox/Gluten สูงสุด 4x บน TPC-DS) |
| โมเดลพูล | คงที่พูลที่มีจํานวนโหนดสูงสุดต่อพูล ขั้นต่ํา 3 โหนด | Starter Pools (การเริ่มต้นระดับวินาที ไม่จําเป็นต้องกําหนดค่า); พูลที่กําหนดเองสําหรับขนาดโหนดเฉพาะและไลบรารีที่กําหนดเอง รองรับการดําเนินการโหนดเดียว |
| ความปลอดภัย (เครือข่าย) | เครือข่ายเสมือนที่มีการจัดการ อุปกรณ์ปลายทางส่วนตัว | อุปกรณ์ปลายทางส่วนตัวที่มีการจัดการ (MPE); นโยบายการเข้าถึงขาออก (OAP); ปุ่ม Customer-Managed (CMK) |
| รองรับ GPU | มีพูลเร่งความเร็ว GPU | ไม่รองรับ |
| ภาวะพร้อมกันสูง | ไม่รองรับ | รองรับ: สมุดบันทึกหลายเล่มแชร์เซสชัน Spark หนึ่งเซสชัน |
| การจัดการไลบรารี | ไลบรารีระดับพูลและระดับพื้นที่ทํางาน อัปโหลดล้อ JAR tar.gz ด้วยตนเอง | การจัดการไลบรารีตามสภาพแวดล้อม: ฟีดสาธารณะ (PyPI/Conda) + การอัปโหลดแบบกําหนดเอง (ล้อ, JAR) หากต้องการจําลองไลบรารีระดับพื้นที่ทํางาน Synapse ให้สร้างสภาพแวดล้อมที่มีไลบรารีที่จําเป็นและตั้งค่าเป็นค่าเริ่มต้นของพื้นที่ทํางาน สมุดบันทึกและ SJD ทั้งหมดในพื้นที่ทํางานจะสืบทอดโดยอัตโนมัติ |
| ลําดับ V | ไม่มี | การเพิ่มประสิทธิภาพไม้ปาร์เก้เวลาเขียน การปรับปรุง 40-60% สําหรับ Power BI Direct Lake และ ~10% สําหรับปลายทางการวิเคราะห์ SQL ไม่มีประโยชน์ในการอ่าน Spark ค่าใช้จ่ายในการเขียน 15-33% |
| เพิ่มประสิทธิภาพการเขียน | ปิดใช้งานโดยค่าเริ่มต้น | เปิดใช้งานตามค่าเริ่มต้น |
| รูปแบบตารางเริ่มต้น | ปาร์เก้ (ตัวเลือกเดลต้า) | Delta Lake (ค่าเริ่มต้นและจําเป็นสําหรับตาราง Lakehouse) |
| ไฮฟ์ เมตาสโตร์ | HMS ในตัว; HMS ภายนอกผ่าน Azure SQL DB หรือ MySQL (เลิกใช้แล้วหลังจาก Spark 3.4) | แคตตาล็อก Fabric Lakehouse; การโยกย้าย HMS ผ่านสคริปต์การส่งออก/นําเข้า |
| DMTS ในสมุดบันทึก | ได้รับการสนับสนุน | รองรับในโน้ตบุ๊ก ยังไม่ได้รับการสนับสนุนในข้อกําหนดงาน Spark |
| ข้อมูลประจําตัวที่มีการจัดการสําหรับ KV | ได้รับการสนับสนุน | ได้รับการสนับสนุนในสมุดบันทึกและข้อกําหนดงาน Spark |
| mssparkutils | ห้องสมุดเต็มรูปแบบ (fs, ข้อมูลประจําตัว, สมุดบันทึก, env, เลคเฮาส์) | notebookutils (API ที่คล้ายกัน ความแตกต่างบางประการในชื่อเมธอด) |