การย้าย: Azure Synapse Analytics เฉพาะกลุ่ม SQL สําหรับ Fabric
นําไปใช้กับ:✅ Warehouse ใน Microsoft Fabric
บทความนี้แสดงกลยุทธ์ ข้อควรพิจารณา และวิธีการโยกย้ายคลังข้อมูลในพูล SQL เฉพาะของ Azure Synapse Analytics ไปยัง Microsoft Fabric Warehouse
บทนําการโยกย้าย
ในฐานะที่ Microsoft ได้แนะนํา Microsoft Fabric ซึ่งเป็นโซลูชันการวิเคราะห์ SaaS แบบครบวงจรสําหรับองค์กรที่มีชุดบริการที่ครอบคลุม ซึ่งรวมถึง Data Factory, วิศวกรข้อมูล ing, คลังข้อมูล, วิทยาศาสตร์ข้อมูล, ข่าวกรองแบบเรียลไทม์ และ Power BI
บทความนี้มุ่งเน้นไปที่ตัวเลือกสําหรับการโยกย้าย schema (DDL) การย้ายรหัสฐานข้อมูล (DML) และการโยกย้ายข้อมูล Microsoft มีหลายตัวเลือกและที่นี่เรากล่าวถึงแต่ละตัวเลือกโดยละเอียดและให้คําแนะนําเกี่ยวกับตัวเลือกเหล่านี้ที่คุณควรพิจารณาสําหรับสถานการณ์ของคุณ บทความนี้ใช้เกณฑ์มาตรฐานอุตสาหกรรม TPC-DS สําหรับภาพประกอบและการทดสอบประสิทธิภาพ ผลลัพธ์จริงของคุณอาจแตกต่างกันโดยขึ้นอยู่กับปัจจัยหลายอย่าง รวมถึงชนิดของข้อมูล ชนิดข้อมูล ความกว้างของตาราง เวลาแฝงของแหล่งข้อมูล ฯลฯ
เตรียมพร้อมสําหรับการโยกย้าย
วางแผนโครงการการย้ายของคุณอย่างระมัดระวังก่อนที่คุณจะเริ่มต้นใช้งาน และตรวจสอบให้แน่ใจว่า Schema โค้ด และข้อมูลของคุณเข้ากันได้กับ Fabric Warehouse มีข้อจํากัดบางอย่างที่คุณต้องพิจารณา วัดปริมาณงานการปรับโครงสร้างของรายการเข้ากันไม่ได้ ตลอดจนทรัพยากรอื่น ๆ ที่จําเป็นก่อนที่จะส่งการโยกย้ายข้อมูล
เป้าหมายสําคัญอีกประการหนึ่งของการวางแผนคือการปรับการออกแบบของคุณเพื่อให้แน่ใจว่าโซลูชันของคุณใช้ประโยชน์จากประสิทธิภาพการคิวรีสูงที่ Fabric Warehouse ออกแบบมาเพื่อให้เต็มที่ การออกแบบคลังข้อมูลสําหรับมาตราส่วนแนะนํารูปแบบการออกแบบที่ไม่ซ้ํากัน ดังนั้นวิธีดั้งเดิมจึงไม่ได้ดีที่สุดเสมอไป ตรวจสอบหลักเกณฑ์ด้านประสิทธิภาพการทํางานของ Fabric Warehouse เนื่องจากแม้ว่าการปรับปรุงการออกแบบบางอย่างจะสามารถดําเนินการได้หลังจากการโยกย้ายข้อมูล แต่การเปลี่ยนแปลงก่อนหน้านี้ในกระบวนการจะช่วยคุณประหยัดเวลาและความพยายาม การโยกย้ายจากเทคโนโลยี/สภาพแวดล้อมหนึ่งไปยังอีกเทคโนโลยีหนึ่งเป็นความพยายามที่สําคัญเสมอ
แผนภาพต่อไปนี้แสดงถึงวงจรชีวิตการโยกย้ายที่แสดงเสาหลักที่ประกอบด้วยประเมินและประเมินแผนและออกแบบโยกย้ายการตรวจสอบและควบคุมปรับให้เหมาะสมและปรับโครงสร้างให้ทันสมัยด้วยงานที่เกี่ยวข้องในแต่ละเสาเพื่อวางแผนและเตรียมพร้อมสําหรับการโยกย้ายที่ราบรื่น
Runbook สําหรับการโยกย้าย
พิจารณากิจกรรมต่อไปนี้เป็นคู่มือการวางแผนสําหรับการโยกย้ายของคุณจากพูล SQL เฉพาะ Synapse ไปยัง Fabric Warehouse
- ประเมินและประเมิน
- ระบุวัตถุประสงค์และแรงจูงใจ สร้างผลลัพธ์ที่ชัดเจนตามที่ต้องการ
- การค้นพบ การประเมิน และพื้นฐานสถาปัตยกรรมที่มีอยู่
- ระบุผู้ถือผลประโยชน์ร่วมและผู้สนับสนุนหลัก
- กําหนดขอบเขตของสิ่งที่จะโยกย้าย
- เริ่มต้นด้วยขนาดเล็กและเรียบง่าย เตรียมพร้อมสําหรับการโยกย้ายข้อมูลขนาดเล็กหลายรายการ
- เริ่มต้นการตรวจสอบและจัดทําเอกสารลําดับขั้นทั้งหมดของกระบวนการ
- สร้างสินค้าคงคลังของข้อมูลและกระบวนการสําหรับการโยกย้าย
- กําหนดการเปลี่ยนแปลงแบบจําลองข้อมูล (ถ้ามี)
- ตั้งค่าพื้นที่ทํางานของผ้า
- skillset/preference ของคุณคืออะไร?
- ทํางานโดยอัตโนมัติได้ทุกที่ที่เป็นไปได้
- ใช้เครื่องมือและคุณลักษณะที่มีอยู่ภายใน Azure เพื่อลดความพยายามในการโยกย้าย
- ฝึกอบรมพนักงานก่อนเวลาบนแพลตฟอร์มใหม่
- ระบุความต้องการที่เพิ่มขึ้นและสินทรัพย์การฝึกอบรม รวมถึง Microsoft Learn
- การวางแผนและการออกแบบ
- กําหนดสถาปัตยกรรมที่ต้องการ
- เลือก วิธีการ/เครื่องมือสําหรับการโยกย้าย เพื่อทํางานต่อไปนี้ให้สําเร็จ:
- การแยกข้อมูลจากแหล่งข้อมูล
- การแปลง Schema (DDL) รวมถึงเมตาดาต้าสําหรับตารางและมุมมอง
- การนําเข้าข้อมูล รวมถึงข้อมูลในอดีต
- หากจําเป็น ให้วิศวกรแบบจําลองข้อมูลอีกครั้งโดยใช้ประสิทธิภาพของแพลตฟอร์มใหม่และการปรับขนาด
- การโยกย้ายรหัสฐานข้อมูล (DML)
- โยกย้ายหรือปรับโครงสร้างขั้นตอนการจัดเก็บและกระบวนการทางธุรกิจใหม่
- สินค้าคงคลังและแยกคุณลักษณะการรักษาความปลอดภัยและสิทธิ์ของวัตถุจากแหล่งข้อมูล
- ออกแบบและวางแผนเพื่อแทนที่/ปรับเปลี่ยนกระบวนการ ETL/ELT ที่มีอยู่สําหรับการโหลดแบบเพิ่มหน่วย
- สร้างกระบวนการ ETL/ELT แบบขนานไปยังสภาพแวดล้อมใหม่
- เตรียมแผนการย้ายข้อมูลโดยละเอียด
- แมปสถานะปัจจุบันไปยังสถานะใหม่ที่ต้องการ
- อพยพ
- ดําเนินการ Schema ข้อมูล การโยกย้ายโค้ด
- การแยกข้อมูลจากแหล่งข้อมูล
- การแปลงเค้าร่าง (DDL)
- การนําเข้าข้อมูล
- การโยกย้ายรหัสฐานข้อมูล (DML)
- หากจําเป็น ให้ปรับมาตราส่วนทรัพยากรพูล SQL เฉพาะเพื่อช่วยความเร็วในการโยกย้ายชั่วคราว
- ใช้ความปลอดภัยและสิทธิ์
- โยกย้ายกระบวนการ ETL/ELT ที่มีอยู่สําหรับการโหลดแบบเพิ่มหน่วย
- โยกย้ายหรือปรับโครงสร้างกระบวนการโหลด ETL/ELT แบบเพิ่มหน่วย
- ทดสอบและเปรียบเทียบกระบวนการโหลดส่วนเพิ่มแบบขนาน
- ปรับแผนการย้ายรายละเอียดข้อมูลตามความจําเป็น
- ดําเนินการ Schema ข้อมูล การโยกย้ายโค้ด
- การตรวจสอบและกํากับดูแล
- เรียกใช้พร้อมกัน เปรียบเทียบกับสภาพแวดล้อมต้นทางของคุณ
- ทดสอบแอปพลิเคชัน แพลตฟอร์มข่าวกรองธุรกิจ และเครื่องมือคิวรี
- Benchmark และปรับประสิทธิภาพคิวรีให้เหมาะสม
- ตรวจสอบและจัดการค่าใช้จ่าย ความปลอดภัย และประสิทธิภาพการทํางาน
- มาตรฐานนโยบายการกํากับดูแลและการประเมิน
- เรียกใช้พร้อมกัน เปรียบเทียบกับสภาพแวดล้อมต้นทางของคุณ
- ปรับให้เหมาะสมและปรับให้ทันสมัย
- เมื่อธุรกิจมีความสะดวก แอปพลิเคชันการเปลี่ยนแปลงและแพลตฟอร์มการรายงานหลักไปยัง Fabric
- ปรับมาตราส่วนทรัพยากรขึ้น/ลงเป็นการเปลี่ยนปริมาณงานจาก Azure Synapse Analytics เป็น Microsoft Fabric
- สร้างเทมเพลตที่ทําซ้ําได้จากประสบการณ์สําหรับการโยกย้ายในอนาคต ย้ํา
- ระบุโอกาสสําหรับการปรับต้นทุนให้เหมาะสม การรักษาความปลอดภัย ความสามารถในการปรับขนาด และความเป็นเลิศในการดําเนินงาน
- ระบุโอกาสในการปรับปรุงอสังหาริมทรัพย์ของคุณให้ทันสมัยด้วย คุณลักษณะ Fabric ล่าสุด
- เมื่อธุรกิจมีความสะดวก แอปพลิเคชันการเปลี่ยนแปลงและแพลตฟอร์มการรายงานหลักไปยัง Fabric
'ลิฟท์และกะ' หรือทันสมัย?
โดยทั่วไปแล้ว มีสถานการณ์การโยกย้ายข้อมูลสองประเภทโดยไม่คํานึงถึงวัตถุประสงค์และขอบเขตของการย้ายที่วางแผนไว้: การยกและเปลี่ยนตามที่เป็น หรือวิธีการแบบเป็นระยะที่รวมการเปลี่ยนแปลงสถาปัตยกรรมและรหัส
ลิฟท์และกะ
ในการโยกย้ายลิฟท์และเลื่อน แบบจําลองข้อมูลที่มีอยู่จะถูกโยกย้ายด้วยการเปลี่ยนแปลงเล็กน้อยไปยัง Fabric Warehouse ใหม่ วิธีการนี้จะลดความเสี่ยงและเวลาการโยกย้ายข้อมูลโดยลดการทํางานใหม่ที่จําเป็นในการตระหนักถึงประโยชน์ของการโยกย้ายข้อมูล
การโยกย้ายแบบยกและเลื่อนนั้นเหมาะสมสําหรับสถานการณ์เหล่านี้:
- คุณมีสภาพแวดล้อมที่มีอยู่ที่มีดาต้ามาร์ทจํานวนน้อยเพื่อโยกย้าย
- คุณมีสภาพแวดล้อมที่มีข้อมูลที่อยู่ในโครงสร้างแบบดาวหรือแบบจําลองแบบจําลองที่ออกแบบมาอย่างดีแล้ว
- คุณอยู่ภายใต้เวลาและค่าใช้จ่ายที่ต้องย้ายไปยัง Fabric Warehouse
โดยสรุป วิธีการนี้ใช้ได้ดีกับปริมาณงานที่ถูกปรับให้เหมาะสมกับสภาพแวดล้อมของพูล SQL Synapse เฉพาะในปัจจุบันของคุณ ดังนั้นจึงไม่จําเป็นต้องมีการเปลี่ยนแปลงที่สําคัญใน Fabric
ปรับให้ทันสมัยด้วยวิธีการแบบเป็นระยะ ๆ ด้วยการเปลี่ยนแปลงทางสถาปัตยกรรม
หากคลังข้อมูลเดิมมีการพัฒนามาเป็นเวลานาน คุณอาจต้องทําวิศวกรใหม่เพื่อรักษาระดับประสิทธิภาพที่จําเป็น
นอกจากนี้คุณอาจต้องการออกแบบสถาปัตยกรรมใหม่เพื่อใช้ประโยชน์จากเครื่องมือและคุณลักษณะใหม่ที่พร้อมใช้งานในพื้นที่ทํางาน Fabric
ความแตกต่างในการออกแบบ: พูล SQL เฉพาะ Synapse และ Fabric Warehouse
พิจารณาความแตกต่างของคลังข้อมูล Azure Synapse และ Microsoft Fabric ต่อไปนี้ เปรียบเทียบกลุ่ม SQL เฉพาะกับ Fabric Warehouse
ข้อควรพิจารณาของตาราง
เมื่อคุณย้ายตารางระหว่างสภาพแวดล้อมที่แตกต่างกัน โดยทั่วไปแล้วเฉพาะข้อมูลดิบและการโยกย้ายเมตาดาต้าจริง องค์ประกอบฐานข้อมูลอื่น ๆ จากระบบต้นทาง เช่น ดัชนี โดยปกติแล้วจะไม่ถูกโยกย้ายเนื่องจากอาจไม่จําเป็นหรือนํามาใช้แตกต่างกันในสภาพแวดล้อมใหม่
การปรับประสิทธิภาพให้เหมาะสมในสภาพแวดล้อมต้นทาง เช่น ดัชนี ระบุตําแหน่งที่คุณอาจเพิ่มการปรับประสิทธิภาพให้เหมาะสมในสภาพแวดล้อมใหม่ แต่ตอนนี้ Fabric จะดูแลคุณโดยอัตโนมัติ
ข้อควรพิจารณาของ T-SQL
มีความแตกต่างของไวยากรณ์ Data Manipation Language (DML) หลายแบบที่ต้องระวัง อ้างอิงถึงพื้นที่พื้นผิว T-SQL ใน Microsoft Fabric พิจารณาการประเมินโค้ดเมื่อเลือกวิธีการโยกย้ายสําหรับรหัสฐานข้อมูล (DML)
คุณอาจจําเป็นต้องเขียนส่วนต่างๆ ของรหัส T-SQL DML ของคุณใหม่ ทั้งนี้ขึ้นอยู่กับความแตกต่างของพาริตีในช่วงเวลาของการโยกย้าย
ความแตกต่างในการแมปชนิดข้อมูล
มีความแตกต่างของชนิดข้อมูลหลายอย่างใน Fabric Warehouse สําหรับข้อมูลเพิ่มเติม ดูชนิดข้อมูลใน Microsoft Fabric
ตารางต่อไปนี้มีการแมปของชนิดข้อมูลที่ได้รับการสนับสนุนจากพูล SQL เฉพาะ Synapse ไปยัง Fabric Warehouse
พูล SQL เฉพาะ Synapse | คลังสินค้าผ้า |
---|---|
เงิน | ทศนิยม(19,4) |
smallmoney | ทศนิยม(10,4) |
smalldatetime | datetime2 |
datetime | datetime2 |
nchar | เผา |
nvarchar | varchar |
tinyint | smallint |
ไบ นารี | varbinary |
datetimeoffset* | datetime2 |
* Datetime2 ไม่จัดเก็บข้อมูลออฟเซตของโซนเวลาพิเศษที่จัดเก็บไว้ เนื่องจากชนิดข้อมูล datetimeoffset ไม่ได้รับการรองรับใน Fabric Warehouse ในขณะนี้ ข้อมูลออฟเซตโซนเวลาจะต้องแยกออกเป็นคอลัมน์แยกต่างหาก
วิธีการสคีมา รหัส และการย้ายข้อมูล
ตรวจทานและระบุตัวเลือกใดที่เหมาะสมกับสถานการณ์ชุดทักษะของพนักงาน และลักษณะของข้อมูลของคุณ ตัวเลือกที่เลือกจะขึ้นอยู่กับประสบการณ์ การกําหนดลักษณะ และประโยชน์จากเครื่องมือแต่ละอย่างของคุณ เป้าหมายของเราคือการพัฒนาเครื่องมือการโยกย้ายต่อไปเพื่อลดแรงเสียดทานและการแทรกแซงด้วยตนเองเพื่อให้ประสบการณ์การโยกย้ายข้อมูลเป็นไปอย่างราบรื่น
ตารางนี้จะสรุปข้อมูลสําหรับ Schema ข้อมูล (DDL) รหัสฐานข้อมูล (DML) และวิธีการโยกย้ายข้อมูล เราจะขยายเพิ่มเติมในแต่ละสถานการณ์ในภายหลังในบทความนี้ ซึ่งเชื่อมโยงในคอลัมน์ตัวเลือก
หมายเลขตัวเลือก | ตัวเลือก | สิ่งที่ทำ | ทักษะ/การกําหนดลักษณะ | สถานการณ์สมมติ |
---|---|---|---|---|
1 | โรงงานข้อมูล | การแปลงเค้าร่าง (DDL) การดึงข้อมูล การนำเข้าข้อมูล |
ADF/ไปป์ไลน์ | ทําให้ทุกอย่างง่ายขึ้นในสคีมาหนึ่ง (DDL) และการโยกย้ายข้อมูล แนะนําสําหรับ ตารางมิติ |
2 | Data Factory พร้อมพาร์ติชัน | การแปลงเค้าร่าง (DDL) การดึงข้อมูล การนำเข้าข้อมูล |
ADF/ไปป์ไลน์ | การใช้ตัวเลือกการแบ่งพาร์ติชันเพื่อเพิ่มการทํางานแบบขนานในการอ่าน/เขียนซึ่งมีอัตราความเร็ว 10x เทียบกับตัวเลือกที่ 1 แนะนําสําหรับ ตารางข้อเท็จจริง |
3 | Data Factory ที่มีรหัสเร่ง | การแปลงเค้าร่าง (DDL) | ADF/ไปป์ไลน์ | แปลงและโยกย้าย Schema (DDL) ก่อน จากนั้นใช้ CETAS เพื่อแยกและคัดลอก/โรงงานข้อมูลไปยังการนําเข้าข้อมูลเพื่อประสิทธิภาพการนําเข้าโดยรวมที่ดีที่สุด |
4 | โค้ดเร่งขั้นตอนที่จัดเก็บไว้ | การแปลงเค้าร่าง (DDL) การดึงข้อมูล การประเมินโค้ด |
T-SQL | ผู้ใช้ SQL ที่ใช้ IDE ที่มีการควบคุมงานที่ละเอียดมากขึ้นซึ่งพวกเขาต้องการใช้งาน ใช้คัดลอก/โรงงานข้อมูลเพื่อนําเข้าข้อมูล |
5 | ส่วนขยายโครงการฐานข้อมูล SQL สําหรับ Azure Data Studio | การแปลงเค้าร่าง (DDL) การดึงข้อมูล การประเมินโค้ด |
โครงการ SQL | โครงการฐานข้อมูล SQL สําหรับการปรับใช้ด้วยการรวมกันของตัวเลือกที่ 4 ใช้คัดลอกหรือโรงงานข้อมูลเพื่อนําเข้าข้อมูล |
6 | สร้างตารางภายนอกเป็นการเลือก (CETAS) | การดึงข้อมูล | T-SQL | ค่าใช้จ่ายในการแยกข้อมูลที่มีประสิทธิภาพและประสิทธิภาพสูงลงใน Azure Data Lake Storage (ADLS) Gen2 ใช้คัดลอก/โรงงานข้อมูลเพื่อนําเข้าข้อมูล |
7 | โยกย้ายโดยใช้ dbt | การแปลงเค้าร่าง (DDL) การแปลงรหัสฐานข้อมูล (DML) |
dbt | ผู้ใช้ dbt ที่มีอยู่สามารถใช้ตัวปรับต่อ dbt Fabric เพื่อแปลง DDL และ DML ของพวกเขาได้ จากนั้นคุณต้องโยกย้ายข้อมูลโดยใช้ตัวเลือกอื่นในตารางนี้ |
เลือกปริมาณงานสําหรับการโยกย้ายเบื้องต้น
เมื่อคุณกําลังตัดสินใจว่าจะเริ่มต้นที่ใดบนพูลเฉพาะ Synapse SQL สําหรับโครงการการโยกย้าย Fabric Warehouse ให้เลือกพื้นที่ทํางานที่คุณสามารถ:
- พิสูจน์ความมีชีวิตชีวาของการโยกย้ายข้อมูลไปยัง Fabric Warehouse ด้วยการส่งมอบประโยชน์ของสภาพแวดล้อมใหม่อย่างรวดเร็ว เริ่มต้นด้วยขนาดเล็กและเรียบง่าย เตรียมพร้อมสําหรับการโยกย้ายข้อมูลขนาดเล็กหลายรายการ
- ช่วยให้พนักงานด้านเทคนิคของคุณจะได้รับประสบการณ์ที่เกี่ยวข้องกับกระบวนการและเครื่องมือที่พวกเขาใช้เมื่อโยกย้ายข้อมูลไปยังพื้นที่อื่น ๆ
- สร้างเทมเพลตสําหรับการโยกย้ายเพิ่มเติมที่เฉพาะเจาะจงกับสภาพแวดล้อม Synapse ต้นทาง และเครื่องมือและกระบวนการเพื่อช่วย
เคล็ดลับ
สร้างคลังวัตถุที่จําเป็นต้องโยกย้าย และจัดทําเอกสารกระบวนการโยกย้ายตั้งแต่ต้นจนจบ เพื่อให้สามารถทําซ้ําสําหรับพูล SQL หรือปริมาณงานอื่นๆ โดยเฉพาะได้
ปริมาณของข้อมูลที่ถูกโยกย้ายข้อมูลในการโยกย้ายข้อมูลเบื้องต้นควรมีขนาดใหญ่พอที่จะแสดงให้เห็นถึงความสามารถและประโยชน์ของสภาพแวดล้อม Fabric Warehouse แต่ไม่ใหญ่เกินกว่าที่จะแสดงค่าได้อย่างรวดเร็ว ขนาดในช่วง 1-10 เทราไบต์เป็นเรื่องปกติ
การย้ายข้อมูลด้วยโรงงานข้อมูล Fabric
ในส่วนนี้ เราจะกล่าวถึงตัวเลือกโดยใช้ Data Factory สําหรับ persona แบบ low-code/no-code ที่คุ้นเคยกับ Azure Data Factory และ Synapse Pipeline ตัวเลือก UI แบบลากแล้วปล่อยนี้จะให้ขั้นตอนง่ายๆ ในการแปลง DDL และโยกย้ายข้อมูล
โรงงานข้อมูลผ้าสามารถทํางานต่อไปนี้:
- แปลง schema (DDL) เป็นไวยากรณ์ Fabric Warehouse
- สร้าง Schema (DDL) บน Fabric Warehouse
- ย้ายข้อมูลไปยัง Fabric Warehouse
ตัวเลือกที่ 1 การโยกย้าย Schema/ข้อมูล - ตัวช่วยสร้างการคัดลอกและกิจกรรมการคัดลอกของ ForEach
วิธีนี้ใช้ตัวช่วย Data Factory Copy เพื่อเชื่อมต่อกับแหล่งพูล SQL เฉพาะ แปลงไวยากรณ์ DDL ของพูล SQL เฉพาะเป็น Fabric และคัดลอกข้อมูลไปยัง Fabric Warehouse คุณสามารถเลือกตารางเป้าหมาย 1 ตารางขึ้นไป (สําหรับชุดข้อมูล TPC-DS มี 22 ตาราง) จะสร้าง ForEach เพื่อวนรอบผ่านรายการของตารางที่เลือกใน UI และสร้างเธรดกิจกรรมการคัดลอกแบบขนาน 22 รายการ
- 22 คิวรี SELECT (หนึ่งคิวรีสําหรับแต่ละตารางที่เลือก) ถูกสร้างขึ้นและดําเนินการในกลุ่ม SQL เฉพาะ
- ตรวจสอบให้แน่ใจว่า คุณมี DWU และคลาสทรัพยากรที่เหมาะสมเพื่ออนุญาตให้คิวรีที่สร้างขึ้นเพื่อดําเนินการ สําหรับกรณีนี้ คุณจําเป็นต้องมี DWU1000
staticrc10
ขั้นต่ําเพื่อให้มีคิวรีได้สูงสุด 32 คิวรีสําหรับการจัดการ 22 คิวรีที่ส่ง - ข้อมูลโรงงานคัดลอกโดยตรงจากกลุ่ม SQL เฉพาะไปยัง Fabric Warehouse จําเป็นต้องมีการจัดเตรียม กระบวนการการนําเข้าข้อมูลประกอบด้วยสองขั้นตอน
- ระยะแรกจะประกอบด้วยการดึงข้อมูลจากพูล SQL เฉพาะลงใน ADLS และเรียกว่าการจัดเตรียม
- ระยะที่สองประกอบด้วยการนําเข้าข้อมูลจากการจัดเตรียมลงใน Fabric Warehouse เวลาการนําเข้าข้อมูลส่วนใหญ่อยู่ในระยะการจัดเตรียม โดยสรุป สเตจจิ้งมีผลต่อประสิทธิภาพการนําเข้าอย่างมาก
การใช้งานที่แนะนำ
การใช้ตัวช่วยสร้างการคัดลอกเพื่อสร้าง ForEach มี UI อย่างง่ายเพื่อแปลง DDL และนําเข้าตารางที่เลือกจากกลุ่ม SQL เฉพาะไปยัง Fabric Warehouse ในขั้นตอนเดียว
อย่างไรก็ตาม การดําเนินการนี้ไม่เหมาะสมกับปริมาณงานโดยรวม ข้อกําหนดในการใช้การจัดเตรียม ความจําเป็นในการอ่านและการเขียนแบบขนานสําหรับขั้นตอน "แหล่งที่มาไปยังลําดับขั้น" เป็นปัจจัยหลักสําหรับเวลาแฝงด้านประสิทธิภาพการทํางาน ขอแนะนําให้ใช้ตัวเลือกนี้สําหรับตารางมิติเท่านั้น
ตัวเลือกที่ 2 การโยกย้าย DDL/ข้อมูล - ไปป์ไลน์ข้อมูลโดยใช้ตัวเลือกพาร์ติชัน
หากต้องการแก้ปัญหาการปรับปรุงปริมาณงานเพื่อโหลดตารางข้อเท็จจริงที่มีขนาดใหญ่ขึ้นโดยใช้ไปป์ไลน์ข้อมูล Fabric ขอแนะนําให้ใช้คัดลอกกิจกรรมสําหรับตารางข้อเท็จจริงแต่ละตารางด้วยตัวเลือกพาร์ติชัน ซึ่งมีประสิทธิภาพที่ดีที่สุดด้วยกิจกรรมการคัดลอก
คุณมีตัวเลือกในการใช้การแบ่งพาร์ติชันจริงของตารางต้นทาง ถ้ามี ถ้าตารางไม่มีพาร์ติชันจริง คุณต้องระบุคอลัมน์พาร์ติชันและใส่ค่าต่ําสุด/สูงสุดเพื่อใช้การแบ่งพาร์ติชันแบบไดนามิก ในสกรีนช็อตต่อไปนี้ ตัวเลือกแหล่งข้อมูลของไปป์ไลน์ข้อมูลจะระบุช่วงแบบไดนามิกของพาร์ติชันตามws_sold_date_sk
คอลัมน์
ในขณะที่ใช้พาร์ติชันสามารถเพิ่มปริมาณงานด้วยขั้นตอนการแบ่งระยะ มีข้อควรพิจารณาเพื่อทําการปรับเปลี่ยนที่เหมาะสม:
- ซึ่งอาจใช้สล็อตพร้อมกันทั้งหมดเนื่องจากอาจสร้างคิวรีมากกว่า 128 คิวรีบนพูล SQL เฉพาะ ทั้งนี้ขึ้นอยู่กับช่วงของพาร์ติชันของคุณ
- คุณจําเป็นต้องปรับมาตราส่วนเป็น DWU6000 น้อยที่สุดเพื่อให้สามารถดําเนินการคิวรีทั้งหมดได้
- ตัวอย่างเช่น สําหรับตาราง TPC DS
web_sales
คิวรี 163 รายการจะถูกส่งไปยังกลุ่ม SQL เฉพาะ ที่ DWU6000 มีการดําเนินการคิวรี 128 รายการในขณะที่มีคิวคิวรี 35 รายการ - พาร์ติชันแบบไดนามิกจะเลือกพาร์ติชันช่วงโดยอัตโนมัติ ในกรณีนี้ เป็นช่วง 11 วันสําหรับแต่ละคิวรี SELECT ที่ส่งไปยังกลุ่ม SQL เฉพาะ ตัวอย่าง:
WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080') ... WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
การใช้งานที่แนะนำ
สําหรับตารางข้อเท็จจริง เราแนะนําให้ใช้ Data Factory กับตัวเลือกการแบ่งพาร์ติชันเพื่อเพิ่มปริมาณงาน
อย่างไรก็ตาม การอ่านแบบขนานที่เพิ่มขึ้นจําเป็นต้องมีพูล SQL เฉพาะเพื่อปรับขนาดเป็น DWU ที่สูงขึ้นเพื่อให้สามารถดําเนินการคิวรีแยกได้ การใช้ประโยชน์จากการแบ่งพาร์ติชัน อัตราได้รับการปรับปรุง 10x โดยไม่มีตัวเลือกพาร์ติชัน คุณสามารถเพิ่ม DWU เพื่อรับปริมาณงานเพิ่มเติมผ่านทรัพยากรการคํานวณ แต่กลุ่ม SQL เฉพาะมีคิวรีที่ใช้งานอยู่สูงสุดที่อนุญาต 128 รายการ
หมายเหตุ
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ Synapse DWU ไปยัง Fabric map โปรดดู ที่ บล็อก: การแมปกลุ่ม SQL เฉพาะของ Azure Synapse ไปยังการคํานวณคลังข้อมูล Fabric
ตัวเลือกที่ 3 การโยกย้าย DDL - ตัวช่วยสร้างการคัดลอกกิจกรรมการคัดลอกของ ForEach
ตัวเลือกสองข้อก่อนหน้านี้เป็นตัวเลือกการโยกย้ายข้อมูลที่ยอดเยี่ยมสําหรับฐานข้อมูลที่มีขนาดเล็กลง แต่ถ้าคุณต้องการปริมาณงานที่สูงขึ้น เราขอแนะนําให้เลือกตัวเลือกอื่น:
- แยกข้อมูลจากกลุ่ม SQL เฉพาะเป็น ADLS ดังนั้นจึงลดค่าใช้จ่ายด้านประสิทธิภาพการทํางานของขั้นตอน
- ใช้ Data Factory หรือคําสั่ง COPY เพื่อนําเข้าข้อมูลลงใน Fabric Warehouse
การใช้งานที่แนะนำ
คุณสามารถใช้ Data Factory เพื่อแปลง Schema (DDL) ของคุณได้ต่อไป ด้วยการใช้ตัวช่วยสร้างสําเนา คุณสามารถเลือกตารางเฉพาะหรือ ตารางทั้งหมดได้ โดยการออกแบบ การดําเนินการนี้จะย้าย Schema และข้อมูลในขั้นตอนเดียว การแยก schema โดยไม่มีแถวโดยใช้เงื่อนไข TOP 0
เท็จในคําสั่งคิวรี
ตัวอย่างรหัสต่อไปนี้ครอบคลุมการโยกย้าย schema (DDL) ด้วย Data Factory
ตัวอย่างโค้ด: การย้าย Schema (DDL) ด้วย Data Factory
คุณสามารถใช้ Fabric Data Pipelines เพื่อโยกย้ายผ่าน DDL (schema) ของคุณสําหรับวัตถุตารางจากแหล่งฐานข้อมูล Azure SQL ใดๆ หรือพูล SQL เฉพาะได้อย่างง่ายดาย ไปป์ไลน์ข้อมูลนี้จะโยกย้ายผ่าน Schema (DDL) สําหรับตารางพูล SQL เฉพาะของแหล่งข้อมูลไปยัง Fabric Warehouse
การออกแบบไปป์ไลน์: พารามิเตอร์
ไปป์ไลน์ข้อมูลนี้ยอมรับพารามิเตอร์ SchemaName
ซึ่งช่วยให้คุณสามารถระบุ Schema ที่จะโยกย้ายได้ เค้าร่าง dbo
เป็นค่าเริ่มต้น
ในเขตข้อมูล ค่าเริ่มต้น ให้ใส่รายการแบบคั่นด้วยจุลภาคของ Schema ตารางที่ระบุว่า Schema ใดที่จะโยกย้าย: 'dbo','tpch'
เพื่อให้สอง schema dbo
และtpch
การออกแบบไปป์ไลน์: กิจกรรมการค้นหา
สร้างกิจกรรมการค้นหา และตั้งค่าการเชื่อมต่อเพื่อชี้ไปยังฐานข้อมูลต้นทางของคุณ
ในแท็บ การตั้งค่า :
ตั้งค่าชนิดที่เก็บข้อมูลเป็นภายนอก
การเชื่อมต่อ คือกลุ่ม SQL เฉพาะของ Azure Synapse ของคุณ ชนิดการเชื่อมต่อคือ Azure Synapse Analytics
ใช้คิวรีถูกตั้งค่าเป็นคิวรี
จําเป็นต้อง สร้างเขตข้อมูลคิวรี โดยใช้นิพจน์แบบไดนามิก ที่อนุญาตให้ใช้พารามิเตอร์ SchemaName ในคิวรีที่แสดงรายการของตารางแหล่งข้อมูลเป้าหมาย เลือก คิวรี จากนั้นเลือก เพิ่มเนื้อหาแบบไดนามิก
นิพจน์นี้ภายในกิจกรรม LookUp สร้างคําสั่ง SQL เพื่อคิวรีมุมมองระบบเพื่อเรียกใช้รายการของสคีมาและตาราง อ้างอิงพารามิเตอร์ SchemaName เพื่ออนุญาตให้มีการกรองบน SQL schema ผลลัพธ์ของนี่คืออาร์เรย์ของ SCHEMA SQL และตารางที่จะใช้เป็นข้อมูลป้อนเข้าในกิจกรรม ForEach
ใช้รหัสต่อไปนี้เพื่อแสดงรายการตารางผู้ใช้ทั้งหมดที่มีชื่อแผนการ
@concat(' SELECT s.name AS SchemaName, t.name AS TableName FROM sys.tables AS t INNER JOIN sys.schemas AS s ON t.type = ''U'' AND s.schema_id = t.schema_id AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),') ')
การออกแบบไปป์ไลน์: ForEach Loop
สําหรับ ForEach Loop ให้กําหนดค่าตัวเลือกต่อไปนี้ใน แท็บ การตั้งค่า :
- ปิดใช้งาน ตามลําดับ เพื่ออนุญาตให้มีการวนซ้ําหลายๆ ครั้งเพื่อเรียกใช้พร้อมกัน
- กําหนด จํานวน ชุดงานเป็น
50
โดยจํากัดจํานวนสูงสุดของการทําซ้ําที่เกิดขึ้นพร้อมกัน - เขตข้อมูลรายการจําเป็นต้องใช้เนื้อหาแบบไดนามิกเพื่ออ้างอิงผลลัพธ์ของกิจกรรม LookUp ใช้ส่วนย่อยของโค้ดต่อไปนี้:
@activity('Get List of Source Objects').output.value
การออกแบบไปป์ไลน์: คัดลอกกิจกรรมภายใน ForEach Loop
ภายในกิจกรรม ForEach เพิ่มกิจกรรมการคัดลอก วิธีนี้ใช้ Dynamic Expression Language ภายในไปป์ไลน์ข้อมูลเพื่อสร้าง SELECT TOP 0 * FROM <TABLE>
เพื่อโยกย้ายเฉพาะ Schema ที่ไม่มีข้อมูลลงใน Fabric Warehouse
ในแท็บ แหล่งข้อมูล :
- ตั้งค่าชนิดที่เก็บข้อมูลเป็นภายนอก
- การเชื่อมต่อ คือกลุ่ม SQL เฉพาะของ Azure Synapse ของคุณ ชนิดการเชื่อมต่อคือ Azure Synapse Analytics
- ตั้งค่า ใช้คิวรี เป็น คิวรี
- ใน เขตข้อมูลคิวรี ให้วางในคิวรีเนื้อหาแบบไดนามิกและใช้นิพจน์นี้ซึ่งจะส่งกลับแถวศูนย์ เฉพาะสคีมาของตาราง:
@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)
ใน แท็บปลายทาง :
- ตั้งค่าประเภทที่เก็บข้อมูลเป็นพื้นที่ทํางาน
- ประเภทที่เก็บข้อมูลพื้นที่ทํางานคือคลังข้อมูลและคลังข้อมูลได้รับการตั้งค่าเป็น Fabric Warehouse
- สคีมาและชื่อของตารางปลายทางจะถูกกําหนดโดยใช้เนื้อหาแบบไดนามิก
- Schema อ้างอิงถึงเขตข้อมูลของการเกิดซ้ําปัจจุบัน SchemaName ที่มีส่วนย่อย:
@item().SchemaName
- ตารางจะอ้างอิง TableName ด้วยส่วนย่อย:
@item().TableName
- Schema อ้างอิงถึงเขตข้อมูลของการเกิดซ้ําปัจจุบัน SchemaName ที่มีส่วนย่อย:
การออกแบบไปป์ไลน์: จม
สําหรับอ่างล้างหน้า ให้ชี้ไปที่คลังสินค้าของคุณและอ้างอิง Schema ต้นทางและชื่อตาราง
เมื่อคุณเรียกใช้ไปป์ไลน์นี้ คุณจะเห็นคลังข้อมูลของคุณที่เติมด้วยแต่ละตารางในแหล่งข้อมูลของคุณด้วยสคีมาที่เหมาะสม
การโยกย้ายโดยใช้ขั้นตอนที่จัดเก็บไว้ในพูล SQL เฉพาะ Synapse
ตัวเลือกนี้ใช้ขั้นตอนที่จัดเก็บไว้เพื่อดําเนินการ Fabric Migration
คุณสามารถรับตัวอย่างโค้ดได้ที่ microsoft/fabric-migration บน GitHub.com โค้ดนี้ถูกแชร์เป็นโอเพนซอร์ส (Open Source) ดังนั้นอย่าลังเลที่จะมีส่วนร่วมในการทํางานร่วมกันและช่วยเหลือชุมชน
ขั้นตอนการโยกย้ายที่เก็บไว้สามารถทําอะไรได้บ้าง:
- แปลง schema (DDL) เป็นไวยากรณ์ Fabric Warehouse
- สร้าง Schema (DDL) บน Fabric Warehouse
- แยกข้อมูลจากพูล SQL เฉพาะ Synapse ไปยัง ADLS
- ค่าสถานะไวยากรณ์ Fabric ที่ไม่รองรับสําหรับรหัส T-SQL (กระบวนงานที่เก็บไว้ ฟังก์ชัน มุมมอง)
การใช้งานที่แนะนำ
นี่เป็นตัวเลือกที่ยอดเยี่ยมสําหรับผู้ที่:
- คุ้นเคยกับ T-SQL
- ต้องการใช้สภาพแวดล้อมการพัฒนาแบบรวม เช่น SQL Server Management Studio (SSMS)
- ต้องการควบคุมอย่างละเอียดมากขึ้นว่างานใดที่พวกเขาต้องการใช้งาน
คุณสามารถดําเนินการกระบวนงานที่จัดเก็บเฉพาะสําหรับการแปลง Schema (DDL) การแยกข้อมูล หรือการประเมินรหัส T-SQL
สําหรับการโยกย้ายข้อมูล คุณจะต้องใช้ทั้ง COPY INTO หรือ Data Factory เพื่อนําเข้าข้อมูลลงใน Fabric Warehouse
โยกย้ายโดยใช้โครงการฐานข้อมูล SQL
Microsoft Fabric Data Warehouse ได้รับการสนับสนุนในส่วนขยายโครงการฐานข้อมูล SQL ที่มีให้ใช้งานภายใน Azure Data Studio และ Visual Studio Code
ส่วนขยายนี้พร้อมใช้งานภายใน Azure Data Studio และ Visual Studio Code คุณลักษณะนี้ช่วยให้สามารถควบคุมแหล่งข้อมูล การทดสอบฐานข้อมูล และการตรวจสอบเค้าร่างได้
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวควบคุมแหล่งข้อมูลสําหรับคลังสินค้าใน Microsoft Fabric รวมถึงการรวม Git และไปป์ไลน์การปรับใช้ ดูตัวควบคุมแหล่งที่มากับ Warehouse
การใช้งานที่แนะนำ
นี่เป็นตัวเลือกที่ยอดเยี่ยมสําหรับผู้ที่ต้องการใช้โครงการฐานข้อมูล SQL สําหรับการปรับใช้ของพวกเขา ตัวเลือกนี้ทําการผสานรวมกระบวนการจัดเก็บ Fabric Migration ในโครงการฐานข้อมูล SQL เพื่อมอบประสบการณ์การโยกย้ายข้อมูลที่ราบรื่น
โครงการฐานข้อมูล SQL สามารถ:
- แปลง schema (DDL) เป็นไวยากรณ์ Fabric Warehouse
- สร้าง Schema (DDL) บน Fabric Warehouse
- แยกข้อมูลจากพูล SQL เฉพาะ Synapse ไปยัง ADLS
- ตั้งค่าสถานะไวยากรณ์ที่ไม่รองรับสําหรับรหัส T-SQL (กระบวนงานที่เก็บไว้ ฟังก์ชัน มุมมอง)
สําหรับการโยกย้ายข้อมูล คุณจะใช้ทั้งคัดลอกลงในหรือโรงงานข้อมูลเพื่อนําเข้าข้อมูลลงใน Fabric Warehouse
การเพิ่มความสามารถในการสนับสนุน Azure Data Studio ไปยัง Fabric ทีม Microsoft Fabric CAT มีชุดสคริปต์ของ PowerShell เพื่อจัดการการแยก การสร้างและการปรับใช้ Schema (DDL) และรหัสฐานข้อมูล (DML) ผ่านโครงการฐานข้อมูล SQL สําหรับการฝึกปฏิบัติของการใช้โครงการฐานข้อมูล SQL ด้วยสคริปต์ PowerShell ที่เป็นประโยชน์ของเรา โปรดดูที่ microsoft/fabric-migration บน GitHub.com
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับโครงการฐานข้อมูล SQL ดูเริ่มต้นใช้งานส่วนขยายโครงการฐานข้อมูล SQL และ สร้างและเผยแพร่โครงการ
การโยกย้ายข้อมูลด้วย CETAS
คําสั่ง T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) มีวิธีการที่คุ้มค่าและเหมาะสมที่สุดในการดึงข้อมูลจากพูล SQL เฉพาะ Synapse ไปยัง Azure Data Lake Storage (ADLS) Gen2
CETAS ทําอะไรได้บ้าง:
- แยกข้อมูลลงใน ADLS
- ตัวเลือกนี้ต้องการให้ผู้ใช้สร้าง schema (DDL) บน Fabric Warehouse ก่อนที่จะนําเข้าข้อมูล พิจารณาตัวเลือกในบทความนี้เพื่อโยกย้าย schema (DDL)
ข้อดีของตัวเลือกนี้คือ:
- ส่งคิวรีเดียวต่อตารางกับกลุ่ม SQL เฉพาะ Synapse ต้นทางเท่านั้น การดําเนินการนี้จะไม่ใช้ช่องสัญญาณพร้อมกันทั้งหมด และจะไม่บล็อก ETL/คิวรีการผลิตของลูกค้าพร้อมกัน
- ไม่จําเป็นต้องปรับขนาดไปยัง DWU6000 เนื่องจากมีการใช้สล็อตพร้อมกันเดียวสําหรับแต่ละตาราง เพื่อให้ลูกค้าสามารถใช้ DWUs ที่ต่ํากว่าได้
- การแยกจะทํางานควบคู่ไปกับโหนดการคํานวณทั้งหมด และนี่คือกุญแจสําคัญในการปรับปรุงประสิทธิภาพการทํางาน
การใช้งานที่แนะนำ
ใช้ CETAS เพื่อแยกข้อมูลไปยังไฟล์ ADLS เป็นไฟล์ Parquet ไฟล์ Parquet ให้ประโยชน์ของพื้นที่จัดเก็บข้อมูลที่มีประสิทธิภาพพร้อมการบีบอัดแบบคอลัมน์ซึ่งจะใช้แบนด์วิดธ์น้อยกว่าเมื่อย้ายผ่านเครือข่าย นอกจากนี้ เนื่องจาก Fabric จัดเก็บข้อมูลเป็นรูปแบบ Delta parquet การนําเข้าข้อมูลจะเร็วขึ้น 2.5 เท่าเมื่อเทียบกับรูปแบบไฟล์ข้อความ เนื่องจากไม่มีการแปลงเป็นค่าใช้จ่ายของรูปแบบ Delta ในระหว่างการนําเข้า
เมื่อต้องการเพิ่มปริมาณงาน CETAS:
- เพิ่มการดําเนินการ CETAS แบบขนาน เพิ่มการใช้ช่องสัญญาณพร้อมกัน แต่ให้ปริมาณงานเพิ่มขึ้น
- ปรับมาตราส่วน DWU บนพูล SQL เฉพาะ Synapse
การโยกย้ายผ่าน dbt
ในส่วนนี้ เราจะกล่าวถึงตัวเลือก dbt สําหรับลูกค้าที่กําลังใช้ dbt ในสภาพแวดล้อมพูล SQL เฉพาะของ Synapse ปัจจุบัน
dbt ทําอะไรได้บ้าง:
- แปลง schema (DDL) เป็นไวยากรณ์ Fabric Warehouse
- สร้าง Schema (DDL) บน Fabric Warehouse
- แปลงรหัสฐานข้อมูล (DML) เป็นไวยากรณ์ Fabric
เฟรมเวิร์ก dbt สร้าง DDL และ DML (สคริปต์ SQL) ในระหว่างเดินทางพร้อมกับการดําเนินการแต่ละครั้ง ด้วยไฟล์แบบจําลองที่แสดงในคําสั่ง SELECT สามารถแปล DDL/DML ได้ทันทีไปยังแพลตฟอร์มเป้าหมายใด ๆ โดยการเปลี่ยนโปรไฟล์ (สายอักขระการเชื่อมต่อ) และประเภทอะแด็ปเตอร์
การใช้งานที่แนะนำ
เฟรมเวิร์ก dbt คือแนวทางแรกสําหรับโค้ด ข้อมูลต้องถูกโยกย้ายโดยใช้ตัวเลือกที่แสดงในเอกสารนี้ เช่น CETAS หรือ COPY/Data Factory
อะแดปเตอร์ dbt สําหรับ Microsoft Fabric Synapse Data Warehouse ช่วยให้โครงการ dbt ที่มีอยู่ที่กําหนดเป้าหมายแพลตฟอร์มต่างๆ เช่น พูล Synapse Dedicated SQL, Snowflake, Databricks, Google Big Query หรือ Amazon Redshift เพื่อโยกย้ายไปยัง Fabric Warehouse ที่มีการเปลี่ยนแปลงการกําหนดค่าอย่างง่าย
เมื่อต้องการเริ่มต้นด้วยโครงการ dbt ที่กําหนดเป้าหมาย Fabric Warehouse โปรดดูบทช่วยสอน: ตั้งค่า dbt สําหรับ Fabric Data Warehouse เอกสารนี้ยังแสดงรายการตัวเลือกเพื่อย้ายระหว่างคลังสินค้า/แพลตฟอร์มต่างๆ
การนําเข้าข้อมูลลงในคลังผ้า
สําหรับการนําเข้าลงใน Fabric Warehouse ให้ใช้ COPY INTO หรือ Fabric Data Factory ขึ้นอยู่กับการกําหนดลักษณะของคุณ ทั้งสองวิธีเป็นตัวเลือกที่แนะนําและมีประสิทธิภาพดีที่สุดเนื่องจากมีปริมาณงานประสิทธิภาพที่เทียบเท่าเนื่องจากข้อกําหนดเบื้องต้นที่ไฟล์ได้รับการแยกออกเป็น Azure Data Lake Storage (ADLS) Gen2 แล้ว
ปัจจัยหลายประการที่ควรทราบเพื่อให้คุณสามารถออกแบบกระบวนการของคุณเพื่อประสิทธิภาพการทํางานสูงสุด:
- ด้วย Fabric จะไม่มีข้อจํากัดด้านทรัพยากรใด ๆ เมื่อโหลดหลายตารางจาก ADLS ไปยัง Fabric Warehouse พร้อมกัน ผลที่ได้คือประสิทธิภาพการทํางานจึงลดลงเมื่อโหลดเธรดขนาน ปริมาณการนําเข้าข้อมูลสูงสุดจะถูกจํากัดด้วยกําลังการคํานวณของความจุ Fabric ของคุณเท่านั้น
- การจัดการปริมาณงานผ้ามีการแยกทรัพยากรที่จัดสรรสําหรับการโหลดและคิวรี ไม่มีการช่วงระยะของทรัพยากรในขณะที่คิวรีและข้อมูลกําลังโหลดที่ดําเนินการในเวลาเดียวกัน