การบํารุงรักษาและการเพิ่มประสิทธิภาพตารางข้ามปริมาณงานใน Microsoft Fabric

ตาราง Delta ใน Microsoft Fabric สามารถรองรับ Spark, SQL analytics endpoint, Power BI Direct Lake, Warehouse และประสบการณ์ Fabric อื่น ๆ จากข้อมูลที่จัดเก็บใน OneLake ประสิทธิภาพที่เหมาะสมระหว่างงานข้ามประเภทขึ้นอยู่กับสองปัจจัย:

• งานที่สร้างและดูแลตาราง
• เครื่องยนต์ที่ใช้ตาราง

ตาราง Lakehouse มักถูกจัดการโดย Spark, Fabric pipeline Copy activity หรือ Dataflow Gen2 Spark เป็นตัวเขียนที่พบมากที่สุดและให้การควบคุมการจัดวางและบํารุงรักษาที่กว้างที่สุด การมิเรอร์คลังสินค้าและฐานข้อมูลจัดการการจัดวางทางกายภาพโดยอัตโนมัติ แคตตาล็อกที่สะท้อนจะยังคงรูปแบบที่จัดการในระบบต้นทาง ความต้องการของผู้บริโภคโดยทั่วไปสามารถเข้ากันได้ แต่ Power BI Direct Lake มีความต้องการจัดเก็บข้อมูลเพิ่มเติมเพื่อประสิทธิภาพสูงสุด

ใช้ตารางแชร์เดียวเมื่อข้อกําหนดของมันสอดคล้องกัน สําหรับข้อยกเว้นที่จัดเต็มตารางอื่น ดูที่ เมื่อสร้างตารางใหม่

เข้าใจการเป็นเจ้าของเลย์เอาต์

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

คําแนะนําข้ามภาระงาน

ตารางต่อไปนี้สรุปแนวทางที่แนะนําโดยผู้ผลิตและผู้บริโภค

ปรับแต่งตาราง Lakehouse

ตาราง Lakehouse Delta ต้องการกลยุทธ์การบํารุงรักษาที่ชัดเจน ไม่ว่าจะเขียนโดย Spark, Pipeline Copy activity หรือ Dataflow Gen2 Spark เป็นตัวอย่างหลักในส่วนนี้เพราะให้การควบคุมการจัดวางและบํารุงรักษาที่กว้างที่สุดใน Fabric

ใช้ค่าเริ่มต้นของรันไทม์ Spark

เมื่อ Spark เขียนตาราง ให้ใช้ค่าเริ่มต้นของ Fabric Spark runtime 2.0 หรือใหม่กว่า:

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

ใน Fabric Spark runtime 1.3 ขนาดไฟล์เป้าหมายแบบปรับได้, เป้าหมายการบีบอัดระดับไฟล์ และเวกเตอร์การลบมีให้เลือกเป็นการตั้งค่าแบบเลือกเข้า

เมื่อ Pipeline Copy activity หรือ Dataflow Gen2 เขียนตาราง ให้ตรวจสอบเค้าโครงไฟล์ที่ได้และตั้งเวลาบํารุงรักษาแยกต่างหาก อย่าคิดว่าผู้เขียนเหล่านี้จะใช้ค่าเริ่มต้นของ Spark ขณะรันไทม์

• ท่อส่งของ Fabric สามารถจัดการกิจกรรมบํารุงรักษา Lakehouse หลังจากเขียนเสร็จแล้ว

ป้องกันและบีบอัดไฟล์ขนาดเล็ก

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

ใช้คําแนะนําต่อไปนี้สําหรับข้อยกเว้นและฟีเจอร์เสริม:

OPTIMIZE บีบอัดไฟล์และล้างเวกเตอร์ลบไฟล์โดยอัตโนมัติเมื่อมีเวกเตอร์ลบมากกว่า 5% ถูกอ้างอิงด้วยเวกเตอร์ลบ ใช้ REORG TABLE ... APPLY (PURGE) เฉพาะเมื่อคุณต้องลบข้อมูลที่ต่ํากว่าเกณฑ์นั้นหรือต้องปฏิบัติตามข้อกําหนดเฉพาะเท่านั้น

รัน VACUUM ในตารางเวลาแยกต่างหากเพื่อลบไฟล์ที่ไม่ได้อ้างอิงหลังจากช่วงเวลาการเก็บรักษา VACUUM กู้คืนพื้นที่จัดเก็บแต่ไม่ปรับปรุงการจัดวางไฟล์ที่ใช้งานอยู่

จัดระเบียบข้อมูลสําหรับการข้ามไฟล์

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

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

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

ปรับแต่งตารางที่จัดการโดยคลังสินค้า

Fabric คลังข้อมูล จัดการการจัดวางตาราง Delta ทางกายภาพโดยไม่ขึ้นกับวิธีการนําเข้าข้อมูล

ใช้การควบคุมเชิงกลยุทธ์ที่ Warehouse เปิดเผยเพื่อปรับแต่งการจัดวางข้อมูล:

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

สําหรับคําแนะนําเกี่ยวกับคลังสินค้าอย่างครบถ้วน โปรดดูที่แนวทางประสิทธิภาพใน Fabric คลังข้อมูล

ปรับแต่งข้อมูลที่สะท้อน

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

• การมิเรอร์ฐานข้อมูล: Fabric จะจําลองข้อมูลต้นทางไปยังตาราง Delta ใน OneLake และจัดการการจัดวางและบํารุงรักษาไฟล์ V-Ordered คุณไม่สามารถกําหนดค่าขนาดไฟล์เป้าหมาย การทําความสะอาดเวกเตอร์การลบ การจัดกลุ่มของเหลว การแบ่งพาร์ติชัน หรือ V-Order บนปลายทางที่มิเรอร์ได้โดยตรง
• แคตตาล็อกแบบมิเรอร์: Fabric ซิงโครไนซ์ข้อมูลเมตาและใช้ทางลัด OneLake เพื่ออ้างอิงข้อมูลต้นทางที่มีอยู่ Fabric ไม่ได้เขียนใหม่หรือดูแลไฟล์เหล่านี้ ปรับปรุงการจัดวางและการทําความสะอาดระบบต้นฉบับเมื่อฟีเจอร์ที่รองรับอนุญาต การเปลี่ยนแปลงเหล่านั้นจะเห็นได้ผ่านทางลัดโดยไม่ต้องสร้างสําเนาใหม่ใน Fabric

สําหรับข้อมูลที่สะท้อนในฐานข้อมูล:

• ใช้เงื่อนไขเฉพาะและหลีกเลี่ยงคอลัมน์ที่ไม่จําเป็นในคําสั่ง Spark และ SQL
• ออกแบบโมเดลเชิงความหมายของ Power BI และมาตรการ DAX เพื่อการใช้พลังงาน Direct Lake อย่างมีประสิทธิภาพ

สําหรับแคตตาล็อกแบบมิเรอร์:

• ใช้ฟีเจอร์การดูแลตารางและการจัดวางที่แพลตฟอร์มต้นทางรองรับ
• ประเมินไฟล์ต้นทางและการกระจายกลุ่มแถวสําหรับผู้บริโภค Fabric ที่สอบถามทางลัด
• สําหรับ Direct Lake ให้ประเมินการสร้างเลเยอร์บริการแบบ V-Ordered ที่จําลองมิติเพิ่มเติมเมื่อเลย์เอาต์ต้นทางไม่สามารถตอบสนองความต้องการด้านประสิทธิภาพได้

สําหรับแนวคิด ประเภท และแหล่งข้อมูลที่รองรับการมิเรอร์ ดูที่ What is Mirroring in Fabric? และ How metadata mirroring work.

ใช้การปรับแต่งเฉพาะผู้บริโภค

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

Power BI Direct Lake

Direct Lake ใช้ตาราง Delta พื้นฐานเดียวกันแต่เพิ่มคําแนะนําเกี่ยวกับการแปลงรหัสและการ เฟรมแบบเพิ่มทีละน้อย:

• การจัดวางไฟล์และกลุ่มแถว: หลีกเลี่ยง กลุ่มแถว ขนาดเล็กและการกระจายกลุ่มแถวที่ไม่สม่ําเสมอ ซึ่งจะสร้างส่วนคอลัมน์ของ VertiPaq มากขึ้นและเพิ่มภาระการแปลงไฟล์
• ลําดับ V: ปฏิบัติตามคําแนะนําเฉพาะผู้ผลิตในแนวทางข้ามภาระงาน สําหรับตารางที่เขียนโดย Spark ซึ่งใช้หลักผ่าน Direct Lake ให้เปิดใช้งาน V-Order หรือใช้readHeavyForPBIโปรไฟล์ทรัพยากร
• รูปแบบการอัปเดต: ควรเลือก รูปแบบการอัปเดตที่เป็นมิตรกับการต่อท้าย เมื่อเป็นไปได้ เพื่อรักษาไฟล์ Parquet ที่มีอยู่และรองรับการจัดกรอบแบบเพิ่มขึ้น

สําหรับตารางที่เขียนโดย Spark จะ spark.sql.parquet.native.writer.maxRowGroupRowCount ตั้งค่าจํานวนแถวสูงสุดต่อกลุ่มแถวเมื่อ เอนจินประมวลผลต้นฉบับ เขียนไฟล์ Parquet ค่าตั้งต้นคือ 0, ซึ่งไม่ได้กําหนดค่าสูงสุด หากการวิเคราะห์แสดงว่าขนาดกลุ่มแถวส่งผลต่อประสิทธิภาพของ Direct Lake ให้ตั้งขีดจํากัดที่ทดสอบก่อนเขียนหรือเขียนตารางใหม่ ตัวอย่างเช่น:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

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

สําหรับคําแนะนําโดยละเอียดเกี่ยวกับการจัดกรอบ การแปลงไฟล์ กลุ่มแถว รูปแบบการอัปเดต และ Delta Analyzer โปรดดูที่ เข้าใจประสิทธิภาพของคําสั่งค้นหา Direct Lake

นําคําแนะนําไปใช้กับเลเยอร์เมดัลเลียน

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

แก้ไขปัญหาการจัดวางและการบํารุงรักษา

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

สําหรับข้อมูลที่สะท้อน ให้ปฏิบัติตามการแก้ไขเฉพาะผู้ผลิตใน Optimize ข้อมูลที่สะท้อน การมิเรอร์ฐานข้อมูลถูกจัดการโดยระบบ; สําหรับแคตตาล็อกที่มิเรอร์ ให้ใช้การบํารุงรักษาที่รองรับในแพลตฟอร์มต้นทาง

สําหรับโต๊ะ lakehouse ตัวเลือกการตรวจสอบที่รองรับ Spark ได้แก่:

• เรียกใช้DESCRIBE DETAILเพื่อตรวจสอบจํานวนไฟล์ ขนาดรวม และคุณสมบัติที่ประเมินdelta.targetFileSize.adaptive
• รันเพื่อ DESCRIBE HISTORY ทบทวนรูปแบบการเขียนและประวัติการบํารุงรักษา
• ใช้ Delta Analyzer เมื่อคุณต้องการวิเคราะห์กลุ่มแถวและรูปแบบการอัปเดตของ Direct Lake อย่างละเอียด

ตรวจสอบขนาดไฟล์เฉลี่ย

ใช้ DESCRIBE DETAIL คํานวณขนาดไฟล์เฉลี่ยเป็นตัวบ่งชี้เบื้องต้นของเค้าโครงตาราง:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

ค่าเฉลี่ยสามารถซ่อนความเอียงระหว่างพาร์ติชันหรือไฟล์ที่บีบอัดล่าสุดและก่อนหน้าได้ หากค่าเฉลี่ยแสดงปัญหาเกี่ยวกับการจัดวาง ให้ตรวจสอบไฟล์ Parquet แต่ละไฟล์ หรือใช้ Delta Analyzer เพื่อประเมินการแจกจ่ายก่อนเปลี่ยนการตั้งค่าบํารุงรักษา

เมื่อใดควรสร้างตารางใหม่

อย่าสร้างตารางทางกายภาพอีกเพียงเพราะเอนจิน Fabric หลายตัวใช้ข้อมูลทั้งหมด

สร้างตารางอื่นเมื่อมีวัตถุประสงค์อิสระ เช่น:

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

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

• ปรับแต่งขนาดไฟล์ข้อมูลตาราง Delta
• การบีบอัดตารางเดลต้า
• เวกเตอร์การลบสําหรับตารางเดลต้า
• ใช้การจัดกลุ่มของเหลวบนตาราง Delta
• การแบ่งพาร์ติชันสําหรับตาราง Delta
• ปรับแต่งตาราง Delta Lake ด้วย V-Order
• ข้อควรพิจารณาเกี่ยวกับประสิทธิภาพของจุดสิ้นสุดการวิเคราะห์ SQL
• ทําความเข้าใจประสิทธิภาพการสืบค้น Direct Lake
• แนวทางประสิทธิภาพใน Fabric คลังข้อมูล
• การจัดกลุ่มข้อมูลใน Fabric คลังข้อมูล
• การมิเรอร์ใน Fabric คืออะไร