แนวทางประสิทธิภาพการทํางานในคลังข้อมูล Fabric

นําไปใช้กับ:✅ Warehouse ใน Microsoft Fabric

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

เมื่อต้องการตรวจสอบประสิทธิภาพการทํางานบนคลังสินค้าของคุณ ให้ดู ตรวจสอบคลังข้อมูลผ้า

ประสิทธิภาพคิวรี

สถิติ

สถิติจะยังคงเป็นวัตถุที่แสดงข้อมูลในตารางของคุณ ตัวปรับให้เหมาะสมคิวรีใช้สถิติเพื่อเลือกและประเมินต้นทุนของแผนคิวรี Fabric Data Warehouse และจุดสิ้นสุดการวิเคราะห์ของ Lakehouse SQL ใช้และรักษาสถิติฮิสโทแกรม สถิติความยาวคอลัมน์โดยเฉลี่ย และสถิติคาร์ดินาลลิตี้ของตารางโดยอัตโนมัติ สําหรับข้อมูลเพิ่มเติม ดูสถิติในคลังข้อมูล Fabric

• คําสั่ง T-SQL ของ CREATE STATISTICS และ UPDATE STATISTICS ได้รับการสนับสนุนสําหรับสถิติฮิสโทแกรมคอลัมน์เดียว คุณสามารถใช้ประโยชน์จากสิ่งเหล่านี้ได้ถ้ามีหน้าต่างขนาดใหญ่พอระหว่างการแปลงตารางของคุณและปริมาณงานคิวรีของคุณ เช่น ระหว่างหน้าต่างการบํารุงรักษาหรือเวลาหยุดทํางานอื่นๆ ซึ่งจะช่วยลดโอกาสที่คิวรีของ SELECT คุณจะต้องอัปเดตสถิติก่อน
• ลองกําหนดสคีมาของตารางที่รักษาพาริตี้ของชนิดข้อมูลในการเปรียบเทียบคอลัมน์ทั่วไป ตัวอย่างเช่น ถ้าคุณทราบว่าคอลัมน์จะถูกเปรียบเทียบกันบ่อยครั้งใน WHERE คําสั่งหรือใช้เป็น JOIN ... ON เพรดิเคต โปรดตรวจสอบให้แน่ใจว่าชนิดข้อมูลตรงกัน หากไม่สามารถใช้ชนิดข้อมูลเดียวกันได้ ให้ใช้ชนิดข้อมูลที่คล้ายกันเพื่อให้สามารถแปลงโดยนัยได้ หลีกเลี่ยงการแปลงข้อมูลที่ชัดเจน สําหรับข้อมูลเพิ่มเติม โปรดดู การแปลงชนิดข้อมูล

เมื่อกรองตาราง lakehouse ในคอลัมน์ประทับเวลาก่อนรันไทม์ Apache Spark 3.5.0 จะไม่มีการสร้างสถิติระดับ rowgroup สําหรับคอลัมน์ประทับเวลา การขาดสถิตินี้ทําให้ระบบเช่น Fabric Warehouse สามารถกําจัดกลุ่มแถวได้ยาก (หรือที่เรียกว่าการข้ามข้อมูลหรือการพุชดาวน์เพรดิเคต) ซึ่งเป็นการเพิ่มประสิทธิภาพการทํางานที่ข้ามกลุ่มแถวที่ไม่เกี่ยวข้องในระหว่างการดําเนินการคิวรี หากไม่มีสถิติเหล่านี้ คิวรีการกรองที่เกี่ยวข้องกับคอลัมน์ประทับเวลาอาจจําเป็นต้องสแกนข้อมูลเพิ่มเติม ซึ่งนําไปสู่การลดประสิทธิภาพการทํางานอย่างมาก คุณสามารถอัปเกรด รันไทม์ Apache Spark ใน Fabric ได้ Apache Spark 3.5.0 และเวอร์ชันที่สูงกว่าสามารถสร้างสถิติระดับ rowgroup สําหรับคอลัมน์ประทับเวลา จากนั้นคุณจะต้องสร้างตารางใหม่และนําเข้าข้อมูลเพื่อให้มีการสร้างสถิติระดับ rowgroup

ประสิทธิภาพแคชเย็น

การดําเนินการครั้งแรกของคิวรีใน Fabric Data Warehouse อาจช้ากว่าการเรียกใช้ที่ตามมาโดยไม่คาดคิด การดําเนินการนี้เรียกว่าการ เริ่มต้นอย่างเย็นชาซึ่งเกิดจากการเตรียมใช้งานระบบหรือกิจกรรมการปรับมาตราส่วนที่เตรียมสภาพแวดล้อมสําหรับการประมวลผล

เริ่มต้นความเย็นมักเกิดขึ้นเมื่อ:

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

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

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

คุณสามารถตรวจหาผลกระทบเริ่มต้นเย็นที่เกิดจากการดึงข้อมูลจากที่เก็บข้อมูลระยะไกลลงในหน่วยความจําโดยการคิวรีมุมมอง queryinsights.exec_requests_history data_scanned_remote_storage_mbตรวจสอบคอลัมน์:

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

การแคชชุดผลลัพธ์ (ตัวอย่าง)

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

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

คิวรีบนตารางที่มีคอลัมน์สตริง

ใช้ความยาวคอลัมน์ของสตริงที่เล็กที่สุดที่สามารถรองรับค่าได้ คลังสินค้าผ้ากําลังปรับปรุงอย่างต่อเนื่อง อย่างไรก็ตาม คุณอาจประสบปัญหาประสิทธิภาพการทํางานที่ไม่เหมาะสมหากใช้ชนิดข้อมูลสตริงขนาดใหญ่ โดยเฉพาะอย่างยิ่งวัตถุขนาดใหญ่ (LOB) ตัวอย่างเช่น สําหรับcustomer_nameชนิดข้อมูลของคอลัมน์ ให้พิจารณาความต้องการทางธุรกิจของคุณและข้อมูลที่คาดหวัง และใช้ความยาวnที่เหมาะสมเมื่อประกาศ varchar(n)เช่น varchar(100) แทนที่จะเป็น varchar(8000) หรือ varchar(max) สถิติและการประเมินต้นทุนการคิวรีมีความแม่นยํามากขึ้นเมื่อความยาวของชนิดข้อมูลแม่นยํามากขึ้นสําหรับข้อมูลจริง

• ใน Fabric Data Warehouse T-SQL ดูคําแนะนําสําหรับการเลือกความยาวที่เหมาะสมสําหรับชนิดข้อมูลสตริง
• คอลัมน์สตริงตาราง Lakehouse โดยไม่มีความยาวที่กําหนดไว้ใน Spark รับรู้โดย Fabric Warehouse เป็น varchar(8000) เพื่อประสิทธิภาพสูงสุด ให้ใช้ CREATE TABLE คําสั่ง ใน SparkSQL เพื่อกําหนดคอลัมน์สตริงเป็น varchar(n)โดย n ที่มีความยาวคอลัมน์สูงสุดที่สามารถรองรับค่าได้

ธุรกรรมและการเกิดพร้อมกัน

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

Fabric Data Warehouse สนับสนุนธุรกรรมที่สอดคล้องกับ ACID โดยใช้การแยกสแนปช็อต ซึ่งหมายความว่า:

• การดําเนินการอ่านและเขียนสามารถถูกจัดกลุ่มลงในธุรกรรมเดียวได้โดยใช้ T-SQL มาตรฐาน (BEGIN TRANSACTION, COMMIT) ROLLBACK
• ความหมายทั้งหมดหรือไม่มีเลย: ถ้าทรานแซคชันนั้นครอบคลุมหลายตารางและการดําเนินการหนึ่งล้มเหลว ธุรกรรมทั้งหมดจะถูกย้อนกลับ
• ความสอดคล้องในการอ่าน: SELECT คิวรีภายในทรานแซคชันจะเห็นสแนปช็อตที่สอดคล้องกันของข้อมูล ซึ่งไม่ได้รับผลกระทบจากการเขียนพร้อมกัน

สนับสนุนธุรกรรมคลังสินค้าผ้า:

• ภาษากําหนดโครงสร้างข้อมูล (DDL) ภายในธุรกรรม: คุณสามารถรวม CREATE TABLE ไว้ภายในบล็อคธุรกรรม
• ทรานสชันระหว่างฐานข้อมูล: ได้รับการสนับสนุนภายในพื้นที่ทํางานเดียวกัน รวมถึงการอ่านจากจุดสิ้นสุดการวิเคราะห์ SQL
• การย้อนกลับตาม Parquet: เนื่องจาก Fabric Data Warehouse จัดเก็บข้อมูลในไฟล์ Parquet ที่ไม่สามารถนําเข้าได้ การย้อนกลับจึงรวดเร็ว การย้อนกลับเพียงแค่แปลงกลับเป็นไฟล์เวอร์ชันก่อนหน้า
• การกระชับข้อมูลและการตรวจสอบอัตโนมัติ:การกระชับข้อมูลช่วยปรับการจัดเก็บข้อมูลและอ่านประสิทธิภาพการทํางานโดยการผสานไฟล์ Parquet ขนาดเล็กและลบแถวที่ถูกลบอย่างมีตรรกะ
• การตรวจสอบอัตโนมัติ: การดําเนินการเขียนทั้งหมด (INSERT, UPDATE, DELETE) ผนวกไฟล์บันทึก JSON ใหม่ไปยังบันทึกธุรกรรม Delta Lake เมื่อเวลาผ่านไป การดําเนินการนี้อาจส่งผลให้มีไฟล์บันทึกหลายร้อยหรือหลายพันไฟล์ โดยเฉพาะในสถานการณ์การนําเข้าข้อมูลด้วยความถี่สูงหรือการสตรีม การตรวจสอบอัตโนมัติช่วยปรับปรุงประสิทธิภาพการอ่านเมตาดาต้าโดยการสรุปบันทึกธุรกรรมเป็นไฟล์จุดตรวจสอบเดียว โดยไม่ต้องตรวจสอบ ทุกครั้งที่อ่านต้องสแกนประวัติล็อกธุรกรรมทั้งหมด ด้วยจุดตรวจสอบบันทึกที่อ่านได้คือไฟล์จุดตรวจล่าสุดและบันทึกหลังจากนั้น การดําเนินการนี้จะลดการแยกวิเคราะห์ I/O และเมตาดาต้าได้อย่างมาก โดยเฉพาะอย่างยิ่งสําหรับตารางขนาดใหญ่หรือตารางที่อัปเดตบ่อย

ทั้งการกระชับและการตรวจสอบจุดเป็นสิ่งสําคัญสําหรับสถานภาพตารางโดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่ทํางานนานหรือภาวะพร้อมกันสูง

การควบคุมภาวะพร้อมกันและการแยก

คลังสินค้าข้อมูล Fabric ใช้การแยกสแนปช็อตโดยเฉพาะ ความพยายามที่จะเปลี่ยนระดับการแยกผ่านทาง T-SQL จะถูกละเว้น

แนวทางปฏิบัติที่ดีที่สุดกับธุรกรรม

• ใช้ธุรกรรมที่ชัดเจนอย่างชาญฉลาด เสมอ COMMIT หรือROLLBACK อย่าปล่อยให้ธุรกรรมเปิดอยู่
  • ทําให้ธุรกรรมมีอายุสั้น หลีกเลี่ยงการใช้ธุรกรรมที่ใช้เวลานานซึ่งมีการล็อคอยู่โดยไม่จําเป็น โดยเฉพาะอย่างยิ่งสําหรับธุรกรรมที่ชัดเจนที่มี DDLs ซึ่งอาจทําให้เกิดการเนื้อหาด้วย SELECT คําสั่งในมุมมองแค็ตตาล็อกระบบ (เช่น sys.tables) และอาจทําให้เกิดปัญหากับพอร์ทัล Fabric ที่ขึ้นกับมุมมองแค็ตตาล็อกระบบได้
• เพิ่มตรรกะการลองใหม่ที่มีความล่าช้าในไปป์ไลน์หรือแอปเพื่อจัดการความขัดแย้งชั่วคราว
  • ใช้ backoff แบบเอ็กซ์โพเนนเชียลเพื่อหลีกเลี่ยงพายุซ้ําที่แย่ลงจากการหยุดชะงักของเครือข่ายชั่วคราว
  • สําหรับข้อมูลเพิ่มเติม ให้ดู รูปแบบลองใหม่
• ตรวจสอบการล็อคและความขัดแย้งในคลังสินค้า
  • ใช้ sys.dm_tran_locks เพื่อตรวจสอบล็อคปัจจุบัน

ลดขนาดชุดข้อมูลที่ส่งกลับ

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

• พาร์ทิชันตารางขนาดใหญ่ในเลคเฮ้าส์
• จํากัดจํานวนของคอลัมน์ที่แสดง SELECT * มีค่าใช้จ่าย
• จํากัดจํานวนของแถวที่ส่งกลับ ดําเนินการกรองข้อมูลมากที่สุดในคลังสินค้าที่เป็นไปได้ไม่ได้อยู่ในแอปพลิเคชันไคลเอ็นต์
  • ลองกรองก่อนที่จะรวมเพื่อลดชุดข้อมูลในช่วงต้นของการดําเนินการคิวรี
  • กรองคอลัมน์ที่มีคาร์ดินาลลิตี้ต่ําเพื่อลดชุดข้อมูลขนาดใหญ่ก่อน JOINs
  • คอลัมน์ที่มีคาร์ดินาลลิตี้สูงเหมาะสําหรับการกรองและ JOIN ส่วนเหล่านี้มักจะถูกใช้ใน WHERE คําสั่งและได้รับประโยชน์จากเพรดิเคตที่ถูกนําไปใช้ในขั้นตอนก่อนหน้าในการดําเนินการคิวรีเพื่อกรองข้อมูล
• ใน Fabric Data Warehouse เนื่องจากไม่ได้บังคับใช้คีย์หลักและข้อจํากัดของคีย์ที่ไม่ซ้ํากัน คอลัมน์ที่มีข้อจํากัดเหล่านี้ไม่จําเป็นต้องเป็นผู้สมัครที่ดีสําหรับ JOINs

แผนคิวรีและคําแนะนําคิวรี

ใน Fabric Data Warehouse ตัวปรับคิวรีให้เหมาะสมจะสร้างแผนการดําเนินการคิวรีเพื่อกําหนดวิธีที่มีประสิทธิภาพที่สุดในการดําเนินการคิวรี SQL ผู้ใช้ขั้นสูงอาจพิจารณาการตรวจสอบปัญหาด้านประสิทธิภาพการทํางานของคิวรีด้วยแผนคิวรี หรือโดยการเพิ่มคําแนะนําคิวรี

• ผู้ใช้สามารถใช้ SHOWPLAN_XML ใน SQL Server Management Studio เพื่อดูแผนโดยไม่ต้องดําเนินการคิวรี
• สามารถเพิ่ม คําแนะนําคิวรี ทางเลือกลงในคําสั่ง SQL เพื่อให้คําแนะนําเพิ่มเติมไปยังตัวปรับปรับคิวรีให้เหมาะสมก่อนที่จะสร้างแผน การเพิ่มคําแนะนําคิวรีจําเป็นต้องมีความรู้ขั้นสูงเกี่ยวกับปริมาณงานคิวรี ดังนั้นมักจะใช้หลังจากที่มีการนําแนวทางปฏิบัติที่ดีที่สุดอื่น ๆ ไปใช้ แต่ปัญหายังคงอยู่

การดําเนินงานที่ไม่สามารถปรับขนาดได้

Fabric Data Warehouse ถูกสร้างขึ้นบนสถาปัตยกรรมการประมวลผลแบบขนาน (MPP) จํานวนมาก ซึ่งมีการดําเนินการคิวรีในโหนดการคํานวณหลายรายการ ในบางสถานการณ์ การดําเนินการโหนดเดียวจะเท่ากัน:

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

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

• พิจารณาการลดขนาดของชุดข้อมูลที่กรองของคิวรี
• ถ้าตรรกะคิวรี่ไม่จําเป็นต้องดําเนินการโหนดเดียว ให้ลองบังคับใช้แผนคิวรีแบบกระจายกับ FORCE DISTRIBUTED PLAN เป็นต้นOPTION (FORCE DISTRIBUTED PLAN);

คิวรีจุดสิ้นสุดการวิเคราะห์ SQL

คุณสามารถใช้จุดสิ้นสุดการวิเคราะห์ SQL เพื่อคิวรีตาราง Lakehouse ที่ถูกสร้างขึ้นด้วย Spark SQL โดยไม่ต้องคัดลอกหรือนําเข้าข้อมูลลงใน Warehouse ได้

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

ดําเนินการบํารุงรักษาตารางทั่วไปสําหรับตารางเลคเฮ้าส์

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

ปรับตารางหรือทางลัดของ lakehouse ให้เหมาะสมด้วยไฟล์ขนาดเล็กจํานวนมาก

การมีไฟล์ขนาดเล็กจํานวนมากสร้างค่าใช้จ่ายสําหรับการอ่านเมตาดาต้าของไฟล์ ใช้ คําสั่ง OPTIMIZE ในพอร์ทัล Fabric หรือสมุดบันทึกเพื่อรวมไฟล์ขนาดเล็กเข้าด้วยกันเป็นไฟล์ขนาดใหญ่ ทําซ้ํากระบวนการนี้เมื่อจํานวนไฟล์เปลี่ยนแปลงอย่างมาก

หากต้องการปรับตารางให้เหมาะสมใน Fabric Lakehouse ให้เปิดเลคเฮ้าส์ในพอร์ทัล Fabric ใน Explorer คลิกขวาบนตาราง เลือกการบํารุงรักษา เลือกตัวเลือกจากหน้า เรียกใช้คําสั่งการบํารุงรักษา จากนั้นเลือก เรียกใช้ทันที

ตารางหรือทางลัดของทะเลสาบคิวรีอยู่ในภูมิภาคเดียวกัน

Fabric ใช้การคํานวณที่ความจุ Fabric อยู่ การคิวรีข้อมูล เช่น ใน Azure Data Lake Storage ของคุณเองหรือใน OneLake ในภูมิภาคอื่นส่งผลให้เกิดค่าใช้จ่ายด้านประสิทธิภาพเนื่องจากเวลาแฝงบนเครือข่าย ตรวจสอบให้แน่ใจว่าข้อมูลอยู่ในภูมิภาคเดียวกัน พิจารณาการเก็บเฉพาะตารางขนาดเล็กเช่น ตารางมิติในภูมิภาคระยะไกล โดยขึ้นอยู่กับข้อกําหนดด้านประสิทธิภาพของคุณ

กรองตารางและทางลัดของเลคเฮ้าส์บนคอลัมน์เดียวกัน

หากคุณมักจะกรองแถวของตารางในคอลัมน์เฉพาะ ให้พิจารณาการแบ่งพาร์ติชันตาราง

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

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

การจัดกลุ่มข้อมูล

คุณยังสามารถจัดกลุ่มข้อมูลบนคอลัมน์เฉพาะในคําสั่ง T-SQL และ CREATE TABLECREATE TABLE AS SELECT (CTAS) ได้อีกด้วย การจัดกลุ่มข้อมูลทํางานโดยการจัดเก็บแถวที่มีค่าคล้ายกันในตําแหน่งที่อยู่ติดกันบนพื้นที่จัดเก็บระหว่างการนําเข้า

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

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

• สําหรับข้อมูลที่สมบูรณ์เกี่ยวกับการจัดกลุ่มข้อมูล โปรดดู การจัดกลุ่มข้อมูลใน Fabric Data Warehouse
• สําหรับบทช่วยสอนเกี่ยวกับการจัดกลุ่มข้อมูลและวิธีวัดผลเชิงบวกต่อประสิทธิภาพ โปรดดู ใช้การจัดกลุ่มข้อมูลใน Fabric Data Warehouse

การปรับชนิดข้อมูลให้เหมาะสม

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับชนิดข้อมูลที่ได้รับการสนับสนุนโดย Fabric Data Warehouse ดูชนิดข้อมูลใน Fabric Data Warehouse

จับคู่ชนิดข้อมูลกับตรรกะข้อมูล

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

• ใช้ วันที่เวลา หรือ datetime2(n) สําหรับค่าชั่วขณะแทนการจัดเก็บเป็นสตริง
• ใช้ชนิดจํานวนเต็มสําหรับค่าตัวเลข เว้นแต่ว่าจะต้องมีการจัดรูปแบบ (ตัวอย่างเช่น จําเป็นต้องมีศูนย์นําหน้า)
• ใช้ชนิดอักขระ (char, varchar) เมื่อการรักษาการจัดรูปแบบเป็นสิ่งสําคัญ (ตัวอย่างเช่น ตัวเลขที่สามารถเริ่มต้นด้วยศูนย์ รหัสผลิตภัณฑ์ ตัวเลขด้วยเส้นประ)

ใช้ชนิดจํานวนเต็มสําหรับจํานวนเต็ม

เมื่อจัดเก็บค่าเช่น ตัวระบุ ตัวนับ หรือจํานวนเต็มอื่นๆ ควรใช้ชนิดจํานวนเต็ม (smallint, int, bigint) มากกว่าตัวเลข/ ชนิดจํานวนเต็มจําเป็นต้องใช้ที่เก็บข้อมูลน้อยกว่าชนิดข้อมูลที่อนุญาตให้มีตัวเลขทางด้านขวาของจุดทศนิยม ผลที่ได้คือการดําเนินการดังกล่าวจะช่วยให้การดําเนินการทางคณิตศาสตร์และการเปรียบเทียบเร็วขึ้นและปรับปรุงการจัดทําดัชนีและประสิทธิภาพการคิวรี

ควรระวังช่วงของค่าสําหรับชนิดข้อมูลจํานวนเต็มแต่ละชนิดที่ได้รับการสนับสนุนโดย Fabric Data Warehouse สําหรับข้อมูลเพิ่มเติม int, bigint, smallint (Transact-SQL)

พิจารณาการใช้ความแม่นยําและตัวเลขและสเกล

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

• คาดว่าคลังสินค้าของคุณจะเติบโตและความต้องการที่คาดหวัง ตัวอย่างเช่น หากคุณวางแผนที่จะจัดเก็บตัวเลขไม่เกินสี่หลักทางด้านขวาของจุดทศนิยม ให้ใช้ ทศนิยม (9,4) หรือ ทศนิยม (19,4) สําหรับการจัดเก็บที่มีประสิทธิภาพมากที่สุด
• ระบุความแม่นยําและมาตราส่วนเสมอเมื่อสร้างคอลัมน์ตัวเลข/ เมื่อสร้างในตารางที่กําหนดเป็น เพียงแค่ decimalโดยไม่ระบุ(p,s)ความแม่นยําและมาตราส่วน คอลัมน์ตัวเลข/จะถูกสร้างขึ้นเป็นdecimal(18,0) ทศนิยมที่มีความแม่นยํา 18 ใช้ที่เก็บข้อมูล 9 ไบต์ต่อแถว มาตราส่วนของ 0 ไม่ได้จัดเก็บข้อมูลไว้ทางด้านขวาของจุดทศนิยม สําหรับจํานวนเต็มธุรกิจจํานวนมาก smallint, int, bigint มีประสิทธิภาพมากกว่า decimal(18,0)มาก ตัวอย่างเช่น สามารถจัดเก็บจํานวนเต็มเก้าหลักเป็นชนิดข้อมูล จํานวนเต็ม สําหรับที่เก็บข้อมูล 4 ไบต์ต่อแถว

สําหรับข้อมูลทั้งหมด ดู ทศนิยมและตัวเลข (Transact-SQL)

พิจารณาเวลาที่จะใช้ varchar over char

ใช้ varchar(n) แทน char(n) สําหรับคอลัมน์สตริง เว้นแต่ว่าต้องมีช่องว่างภายในความยาวคงที่อย่างชัดเจน คอลัมน์ varchar จัดเก็บเฉพาะความยาวสตริงจริงต่อแถวรวมถึงค่าใช้จ่ายขนาดเล็กและลดช่องว่างที่สิ้นเปลืองซึ่งช่วยปรับปรุงประสิทธิภาพ I/ O

• ใช้ varchar(n) สําหรับค่า เช่น ชื่อ ที่อยู่ และคําอธิบาย เนื่องจากมีค่าตัวแปรอย่างกว้างขวาง สถิติและการประเมินต้นทุนการคิวรีมีความแม่นยํามากขึ้นเมื่อความยาวของชนิดข้อมูลแม่นยํามากขึ้นสําหรับข้อมูลจริง
• ใช้ char(n) เมื่อคุณทราบว่าสตริงจะมีความยาวคงที่ในแต่ละครั้ง ตัวอย่างเช่น การจัดเก็บสตริง 000000000 เป็น อักขระ (9) จะสมเหตุสมผลหากสตริงเป็นอักขระตัวเลข 9 ตัวที่สามารถขึ้นต้นด้วยศูนย์ได้เสมอ
• ความยาว n ในการประกาศชนิดข้อมูลของคอลัมน์คือไบต์ที่เก็บข้อมูล สําหรับชุดอักขระการเข้ารหัสหลายไบต์ เช่น UTF-8 การเข้ารหัสสําหรับ Fabric Data Warehouse อักขระละตินและตัวเลขจะใช้เวลาเก็บข้อมูล 1 ไบต์ อย่างไรก็ตาม มีอักขระ Unicode ที่จําเป็นต้องใช้อักขระมากกว่า 1 ไบต์ เช่น อักขระภาษาญี่ปุ่นที่จําเป็นต้องมีการจัดเก็บ 3 ไบต์ ดังนั้นจํานวนของอักขระ Unicode ที่เก็บไว้จึงมีค่าน้อยกว่าความยาว nของชนิดข้อมูล สําหรับข้อมูลเพิ่มเติม ให้ดู อาร์กิวเมนต์ char และ varchar

หลีกเลี่ยงคอลัมน์ที่เป็นค่าว่างได้เมื่อเป็นไปได้

กําหนดคอลัมน์เมื่อ NOT NULL แบบจําลองข้อมูลอนุญาต ตามค่าเริ่มต้น คอลัมน์ในตารางจะอนุญาตให้มีค่าNULL คอลัมน์ที่สามารถเป็น Null ได้มีลักษณะดังต่อไปนี้:

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

การนําเข้าข้อมูลและการเตรียมการลงในคลังสินค้า

คัดลอกไปยัง

คําสั่ง T-SQL COPY INTO เป็นวิธีที่แนะนําสําหรับการนําเข้าข้อมูลจาก Azure Data Lake Storage ลงใน Fabric Data Warehouse สําหรับข้อมูลและตัวอย่างเพิ่มเติม โปรดดูการนําเข้าข้อมูลลงใน Warehouse ของคุณโดยใช้คําสั่ง COPY

พิจารณาคําแนะนําต่อไปนี้เพื่อประสิทธิภาพการทํางานที่ดีที่สุด:

• ขนาดไฟล์: ตรวจสอบให้แน่ใจว่าแต่ละไฟล์ที่คุณกําลังนําส่งนั้นมีความเหมาะสมระหว่าง 100 MB และ 1 GB สําหรับอัตราความเร็วสูงสุด ซึ่งจะช่วยปรับกระบวนการการนําเข้าข้อมูลให้เหมาะสมและปรับปรุงประสิทธิภาพการทํางาน
• จํานวนไฟล์: เมื่อต้องการขยายความขนานและประสิทธิภาพการทํางานของคิวรี ให้มุ่งสร้างไฟล์จํานวนมาก จัดลําดับความสําคัญของการสร้างไฟล์ให้มากที่สุดเท่าที่เป็นไปได้ในขณะที่รักษาขนาดไฟล์ต่ําสุด 100 MB
• การโหลดแบบขนาน: ใช้คําสั่งหลาย COPY INTO คําสั่งที่ทํางานควบคู่ไปกับการโหลดข้อมูลลงในตารางที่แตกต่างกัน วิธีการนี้สามารถลดหน้าต่าง ETL/ELT ได้อย่างมากเนื่องจากความขนาน
• ขนาดความจุ: สําหรับปริมาณข้อมูลขนาดใหญ่ ให้พิจารณาขยายความจุ Fabric ให้ใหญ่ขึ้นเพื่อรับทรัพยากรการคํานวณเพิ่มเติมที่จําเป็นเพื่อให้สอดคล้องกับจํานวนการประมวลผลแบบขนานและปริมาณข้อมูลขนาดใหญ่ขึ้น

นอกจากนี้ Fabric Data Warehouse ยังสนับสนุนBULK INSERTคําสั่ง ที่เป็นคําพ้องสําหรับCOPY INTO คําแนะนําเดียวกันนี้ใช้กับ BULK INSERT คําสั่ง

CTAS หรือ INSERT

ใช้ CREATE TABLE AS SELECT (CTAS) หรือ INSERT รวมกับ SELECT FROM คําสั่งตาราง/ทางลัดของ Lakehouse วิธีการเหล่านี้อาจมีประสิทธิภาพและมีประสิทธิภาพมากกว่าการใช้ไปป์ไลน์ ซึ่งช่วยให้การถ่ายโอนข้อมูลที่รวดเร็วและเชื่อถือได้มากขึ้น สําหรับข้อมูลและตัวอย่างเพิ่มเติม โปรดดูการนําเข้าข้อมูลลงในคลังสินค้าของคุณโดยใช้ Transact-SQL

แนวคิดของการเพิ่มจํานวนความขนานและการปรับมาตราส่วนไปยังความจุผ้าที่มีขนาดใหญ่ขึ้นยังนําไปใช้กับการดําเนินการ CTAS/INSERT เพื่อเพิ่มอัตราความเร็ว

อ่านข้อมูลจาก Azure Data Lake Storage หรือ Blob Storage ด้วย OPENROWSET

ฟังก์ชัน OPENROWSET ช่วยให้คุณสามารถอ่านไฟล์ CSV หรือ Parquet จาก Azure Data Lake หรือที่เก็บข้อมูล Azure Blob โดยไม่ต้องส่งไปที่ Warehouse สําหรับข้อมูลและตัวอย่างเพิ่มเติม ดูเรียกดูเนื้อหาไฟล์โดยใช้ฟังก์ชัน OPENROWSET

เมื่ออ่านข้อมูลโดยใช้ฟังก์ชัน OPENROWSET ให้พิจารณาคําแนะนําต่อไปนี้เพื่อประสิทธิภาพที่ดีที่สุด:

• Parquet: ลองใช้ Parquet แทน CSV หรือแปลง CSV เป็น Parquet หากคุณมักคิวรีไฟล์ Parquet เป็นรูปแบบคอลัมน์ เนื่องจากข้อมูลถูกบีบอัด ขนาดไฟล์จะเล็กกว่าไฟล์ CSV ที่ประกอบด้วยข้อมูลเดียวกัน Fabric Data Warehouse ข้ามคอลัมน์และแถวที่ไม่จําเป็นในคิวรีถ้าคุณกําลังอ่านไฟล์ Parquet
• ขนาดไฟล์: ตรวจสอบให้แน่ใจว่าแต่ละไฟล์ที่คุณกําลังนําส่งนั้นมีความเหมาะสมระหว่าง 100 MB และ 1 GB สําหรับอัตราความเร็วสูงสุด ซึ่งจะช่วยปรับกระบวนการการนําเข้าข้อมูลให้เหมาะสมและปรับปรุงประสิทธิภาพการทํางาน เป็นการดีกว่าที่จะมีไฟล์ที่มีขนาดเท่ากัน
• จํานวนไฟล์: เมื่อต้องการขยายความขนานและประสิทธิภาพการทํางานของคิวรี ให้มุ่งสร้างไฟล์จํานวนมาก จัดลําดับความสําคัญของการสร้างไฟล์ให้มากที่สุดเท่าที่เป็นไปได้ในขณะที่รักษาขนาดไฟล์ต่ําสุด 100 MB
• ผนัง: แบ่งพาร์ติชันข้อมูลของคุณโดยการจัดเก็บพาร์ติชันไว้ในโฟลเดอร์หรือชื่อไฟล์ที่แตกต่างกันถ้าปริมาณงานของคุณกรองตามคอลัมน์พาร์ติชัน
• การประเมิน: ลองตั้งค่า ROWS_PER_BATCH ให้ตรงกับจํานวนแถวในไฟล์พื้นฐานถ้าคุณรู้สึกว่าคุณไม่ได้รับประสิทธิภาพที่คาดหวัง
• ขนาดความจุ: สําหรับปริมาณข้อมูลที่มีขนาดใหญ่ขึ้น พิจารณาปรับมาตราส่วนออกเป็น SKU ที่มีขนาดใหญ่ขึ้นเพื่อรับทรัพยากรการคํานวณเพิ่มเติมที่จําเป็นเพื่อให้เหมาะสมกับจํานวนการประมวลผลแบบขนานและปริมาณข้อมูลขนาดใหญ่ขึ้น

หลีกเลี่ยงการแทรก การอัปเดต และการลบด้วยเคล็ดลับ

เพื่อให้แน่ใจว่าเค้าโครงไฟล์มีประสิทธิภาพและประสิทธิภาพการคิวรีที่เหมาะสมที่สุดใน Fabric Data Warehouse ให้หลีกเลี่ยงการใช้ธุรกรรมที่มีขนาดเล็กและINSERTจํานวนมากUPDATEDELETE การเปลี่ยนแปลงระดับแถวเหล่านี้สร้างไฟล์ Parquet ใหม่สําหรับแต่ละการดําเนินการ ส่งผลให้มีไฟล์ขนาดเล็กและกลุ่มแถวที่กระจัดกระจายจํานวนมาก การกระจายตัวนี้นําไปสู่:

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

วิธีการที่แนะนํา:

• ธุรกรรมชุดงานที่เขียนลงในคลังข้อมูล Fabric
  • ตัวอย่างเช่น แทนที่จะใช้คําสั่งขนาดเล็ก INSERT หลายคําสั่ง ข้อมูลขั้นตอนล่วงหน้าร่วมกัน และแทรกข้อมูลในหนึ่ง INSERT คําสั่ง
• ใช้ คัดลอกลงใน สําหรับการแทรกจํานวนมากและดําเนินการอัปเดตและลบเป็นชุดเมื่อใดก็ตามที่เป็นไปได้
• รักษาขนาดไฟล์ที่นําเข้าต่ําสุดที่ 100 MB เพื่อให้แน่ใจว่าการก่อตัวของกลุ่มแถวมีประสิทธิภาพ
• สําหรับคําแนะนําเพิ่มเติมและแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการนําเข้าข้อมูล โปรดดู แนวทางปฏิบัติที่ดีที่สุดในการนําเข้าข้อมูลลงในคลังข้อมูล

การกระชับข้อมูล

ใน Fabric Data Warehouse การบีบอัดข้อมูลเป็นกระบวนการเพิ่มประสิทธิภาพพื้นหลังที่รวมไฟล์ Parquet ขนาดเล็กที่ไม่มีประสิทธิภาพเป็นไฟล์ที่ใหญ่ขึ้นและน้อยลง บ่อยครั้งที่ไฟล์เหล่านี้จะถูกสร้างขึ้นโดยการดําเนินการ ของ เคล็ดลับ INSERT, UPDATEหรือ DELETE ที่ใช้บ่อย การกระชับข้อมูลช่วยลดการกระจายตัวของไฟล์ ปรับปรุงประสิทธิภาพกลุ่มแถว และปรับปรุงประสิทธิภาพการคิวรีโดยรวม

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

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

การบดอัดข้อมูลล่วงหน้า

Fabric Data Warehouse หลีกเลี่ยงความขัดแย้งในการเขียน-เขียนอย่างชาญฉลาดและเชิงรุกระหว่างงานการบดอัดพื้นหลังและการดําเนินการของผู้ใช้ ตั้งแต่เดือนตุลาคม 2025 การบดอัดข้อมูลล่วงหน้าจะเปิดใช้งาน

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

ข้อขัดแย้งในการเขียน-เขียนกับบริการการบดอัดข้อมูลเบื้องหลังของ Fabric Data Warehouse ยังคงเป็นไปได้ เป็นไปได้ที่จะสร้างข้อขัดแย้งในการเขียน-เขียนด้วยการบดอัดข้อมูล เช่น หากแอปพลิเคชันใช้ธุรกรรมที่ชัดเจนและทํางานที่ไม่ขัดแย้งกัน (เช่น INSERT) ก่อนการดําเนินการที่ขัดแย้งกัน (UPDATE, DELETE, ) MERGE การบดอัดข้อมูลสามารถคอมมิตได้สําเร็จ ทําให้ธุรกรรมที่ชัดเจนในภายหลังล้มเหลวเนื่องจากข้อขัดแย้ง สําหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อขัดแย้งในการเขียน-เขียนหรือการปรับปรุง โปรดดู ธุรกรรมในตารางคลังสินค้าใน Microsoft Fabric

สั่งซื้อ V-in Fabric Data Warehouse

V-Order เป็นการเพิ่มประสิทธิภาพเวลาในการเขียนเป็นรูปแบบไฟล์ปาร์เก้ที่ช่วยให้สามารถอ่านได้อย่างรวดเร็วใน Microsoft Fabric V-Order in Fabric Data Warehouse ช่วยปรับปรุงประสิทธิภาพคิวรีโดยใช้การเรียงลําดับและการบีบอัดไปยังไฟล์ตาราง

ตามค่าเริ่มต้น V-Order จะเปิดใช้งานบนคลังสินค้าทั้งหมดเพื่อให้แน่ใจว่าการอ่านการดําเนินการ โดยเฉพาะอย่างยิ่งคิวรีการวิเคราะห์เป็นไปอย่างรวดเร็วและมีประสิทธิภาพที่สุด

อย่างไรก็ตาม V-Order แนะนําค่าใช้จ่ายในการนําเข้าขนาดเล็กที่เห็นได้ชัดเจนในปริมาณงานที่เขียนหนัก ด้วยเหตุนี้ การปิดใช้งาน V-Order จึงควรได้รับการพิจารณาเฉพาะสําหรับคลังสินค้าที่มีการเขียนอย่างเข้มงวดเท่านั้นและไม่ได้ใช้สําหรับแบบสอบถามที่ใช้บ่อย สิ่งสําคัญคือต้องทราบว่าเมื่อปิดใช้งาน V-Order บนคลังสินค้าแล้ว จะไม่สามารถเปิดใช้งานอีกครั้งได้

ก่อนตัดสินใจที่จะปิดใช้งาน V-Order ผู้ใช้ควรทดสอบประสิทธิภาพของปริมาณงานอย่างละเอียดเพื่อให้แน่ใจว่าการแลกเปลี่ยนนั้นเป็นธรรม รูปแบบทั่วไปคือการใช้จัดเตรียมคลังสินค้าที่มี V-Order ที่ปิดใช้งานสําหรับการนําเข้าอัตราความเร็วสูง การแปลงข้อมูล และการนําเข้าข้อมูลพื้นฐานลงในคลังข้อมูลที่เปิดใช้งาน V-Order เพื่อประสิทธิภาพการอ่านที่ดีขึ้น สําหรับข้อมูลเพิ่มเติม ดูปิดใช้งาน V-Order on Warehouse ใน Microsoft Fabric

ลอกแบบตารางแทนการคัดลอกตาราง

การลอกแบบตารางใน Fabric Data Warehouse เป็นวิธีที่รวดเร็วและมีประสิทธิภาพในการสร้างตารางโดยไม่ต้องคัดลอกข้อมูล ด้วยวิธีการลอกแบบศูนย์สําเนา เฉพาะเมตาดาต้าของตารางเท่านั้นที่จะซ้ํากัน ในขณะที่ไฟล์ข้อมูลพื้นฐานจะถูกอ้างอิงโดยตรงจาก OneLake ซึ่งช่วยให้ผู้ใช้สามารถสร้างสําเนาตารางที่สอดคล้องกันและเชื่อถือได้เกือบทันทีโดยไม่ต้องทําสําเนาข้อมูลเต็มรูปแบบ

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

• ตารางที่ถูกโคลนยังคัดลอก คุณลักษณะความปลอดภัย ที่สําคัญทั้งหมดจากแหล่งข้อมูล รวมถึง Row-Level Security (RLS), Column-Level Security (CLS) และ Dynamic Data Masking (DDM) โดยไม่จําเป็นต้องใช้นโยบายอีกครั้งหลังจากการลอกแบบ
• ลอกแบบสามารถสร้างได้ตามช่วงเวลาเฉพาะภายในระยะเวลาการเก็บข้อมูลซึ่งสนับสนุนความสามารถในการเดินทางในเวลา
• ตารางที่ถูกโคลนมีอยู่โดยอิสระจากแหล่งข้อมูลการเปลี่ยนแปลงที่ทํากับแหล่งข้อมูลไม่ส่งผลกระทบต่อการลอกแบบและการเปลี่ยนแปลงไปยังการลอกแบบไม่ส่งผลกระทบต่อแหล่งข้อมูล แหล่งข้อมูลหรือลอกแบบสามารถถูกปล่อยได้อย่างอิสระ

มุมมองเมตาดาต้าของคิวรี

• ประวัติการดําเนินการคิวรี (30 วัน)

  • queryinsights.exec_requests_history
  • queryinsights.exec_sessions_history

• ข้อมูลเชิงลึกรวม

  • queryinsights.long_running_queries
  • queryinsights.frequently_run_queries

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับqueryinsightsมุมมอง ดูข้อมูลเชิงลึกของคิวรีในคลังข้อมูล Fabric

• DMV วงจรชีวิตคิวรี
  • sys.dm_exec_connections
  • sys.dm_exec_sessions
  • sys.dm_exec_requests

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ DMV วงจรชีวิตคิวรี ดู ตรวจสอบการเชื่อมต่อ เซสชัน และคําขอโดยใช้ DMV

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

• ตรวจสอบคลังข้อมูลผ้า
• แอปเมตริกความจุ Microsoft Fabric คืออะไร
• ข้อมูลเชิงลึกของคิวรี
• สถิติใน Fabric Data Warehouse
• ส่งข้อมูลไปยังคลังสินค้าของคุณโดยใช้คําสั่ง COPY