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

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

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

เขียนและอ่านเมทริกซ์สถานการณ์สมมติ

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

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

เค้าโครงไฟล์ที่เหมาะสมที่สุดตามเอ็นจิ้น

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

คําแนะนําสําหรับปลายทางการวิเคราะห์ SQL และ Fabric Data Warehouse

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

• ขนาดไฟล์เป้าหมาย: ประมาณ 400 MB ต่อไฟล์
• ขนาดกลุ่มแถว: ประมาณ 2 ล้านแถวต่อกลุ่มแถว
• V-Order: ปรับปรุงประสิทธิภาพการอ่าน 10%

คลังสินค้าใช้เกณฑ์เหล่านี้เพื่อค้นหาผู้สมัครการบดอัด:

• ค่าโสหุ้ยของไฟล์ตารางมากกว่า 10%
• แถวที่ลบตามตรรกะของตารางมีมากกว่า 10%
• ขนาดโต๊ะมีขนาดใหญ่กว่า 1,024 แถว

ในระหว่างการดําเนินการบดอัด กระบวนการจะเลือกผู้สมัครตามเกณฑ์เหล่านี้:

• ไฟล์ใดๆ มีขนาดเล็กกว่า 25% ของขนาดที่เหมาะสม (ตามจํานวนแถว)
• ไฟล์ใดๆ มีแถวที่ถูกลบมากกว่า 20 แถว%

Spark

Spark มีประสิทธิภาพเมื่ออ่านไฟล์ขนาดต่างๆ เพื่อประสิทธิภาพสูงสุด:

• ขนาดไฟล์เป้าหมาย: 128 MB ถึง 1 GB ขึ้นอยู่กับขนาดตาราง
• ขนาดกลุ่มแถว: 1 ล้านถึง 2 ล้านแถวต่อกลุ่มแถว
• V-Order: ไม่จําเป็นสําหรับประสิทธิภาพการอ่าน Spark (สามารถเพิ่มค่าใช้จ่ายในการเขียน 15-33%)

การอ่าน Spark ได้รับประโยชน์จาก ขนาดไฟล์เป้าหมายที่ปรับเปลี่ยนได้ ซึ่งจะปรับโดยอัตโนมัติตามขนาดตาราง:

• ตารางที่มีขนาดต่ํากว่า 10 GB: เป้าหมาย 128 MB
• ตารางที่มีขนาดมากกว่า 10 TB: เป้าหมายสูงสุด 1 GB

Power BI Direct Lake

เพื่อประสิทธิภาพสูงสุดของ Direct Lake:

• ขนาดกลุ่มแถวเป้าหมาย: 8 ล้านแถวขึ้นไปต่อกลุ่มแถวเพื่อประสิทธิภาพที่ดีที่สุด
• V-Order: มีความสําคัญต่อการปรับปรุง 40-60% ในการสืบค้นแคชเย็น
• จํานวนไฟล์: ลดจํานวนไฟล์เพื่อลดค่าใช้จ่ายในการแปลงรหัส
• ขนาดไฟล์ที่สอดคล้องกัน: สําคัญสําหรับประสิทธิภาพการสืบค้นที่คาดการณ์ได้

โมเดลความหมายของ Direct Lake ทํางานได้ดีที่สุดเมื่อ:

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

สําหรับข้อมูลเพิ่มเติม โปรดดู ทําความเข้าใจประสิทธิภาพของคิวรี Direct Lake

Mirroring

การมิเรอร์จะปรับขนาดไฟล์โดยอัตโนมัติตามโวลุ่มตาราง:

ขนาดโต๊ะ	แถวต่อกลุ่มแถว	แถวต่อไฟล์
ขนาดเล็ก (สูงสุด 10 GB)	2 ล้าน	10 ล้าน
ปานกลาง (10 GB ถึง 2.56 TB)	4 ล้าน	60 ล้าน
ขนาดใหญ่ (มากกว่า 2.56 TB)	8 ล้าน	80 ล้าน

รูปแบบการเขียนและการกําหนดค่า

รูปแบบการเขียน Spark

การเขียน Spark ใช้การกําหนดค่าเริ่มต้นต่อไปนี้:

การกําหนดค่า	ค่าพื้นฐาน	คำอธิบาย
spark.microsoft.delta.optimizeWrite.fileSize	128 ล้านบาท	ขนาดไฟล์เป้าหมายสําหรับการเขียนที่ปรับให้เหมาะสม
spark.databricks.delta.optimizeWrite.enabled	แตกต่างกันไปตามโปรไฟล์	เปิดใช้งานการรวมไฟล์อัตโนมัติ
spark.databricks.delta.autoCompact.enabled	ถูกปิดใช้งาน	เปิดใช้งานการบดอัดหลังการเขียน
spark.sql.files.maxRecordsPerFile	ไม่จำกัด	ระเบียนสูงสุดต่อไฟล์

ในการกําหนดค่าการเขียน Spark สําหรับการใช้ SQL ดาวน์สตรีม:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

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

รูปแบบการเขียนคลังสินค้า

คลังสินค้าจะปรับเค้าโครงข้อมูลให้เหมาะสมโดยอัตโนมัติในระหว่างการเขียน:

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

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

การดําเนินการบํารุงรักษาโต๊ะ

คําสั่ง OPTIMIZE

OPTIMIZEคําสั่งจะรวมไฟล์ขนาดเล็กเป็นไฟล์ขนาดใหญ่:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

สำคัญ

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

สําหรับข้อมูลเพิ่มเติม โปรดดู การบดอัดตาราง

การบดอัดอัตโนมัติ

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

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

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

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

สําหรับข้อมูลเพิ่มเติม โปรดดู การบดอัดอัตโนมัติ

เพิ่มประสิทธิภาพการเขียน

การเพิ่มประสิทธิภาพการเขียนช่วยลดค่าใช้จ่ายของไฟล์ขนาดเล็กโดยการบดอัดก่อนเขียน ซึ่งจะสร้างไฟล์ที่ใหญ่ขึ้นและน้อยลง:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

เพิ่มประสิทธิภาพการเขียนมีประโยชน์สําหรับ:

• ตารางที่มีการแบ่งพาร์ติชัน
• โต๊ะที่มีเม็ดมีดขนาดเล็กบ่อยครั้ง
• การทํางานที่สัมผัสไฟล์จํานวนมาก (MERGE, UPDATE, ) DELETE

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

คําสั่ง VACUUM

คําสั่งจะ VACUUM ลบไฟล์เก่าที่บันทึกตารางเดลต้าไม่ได้อ้างอิงอีกต่อไป:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

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

สําหรับข้อมูลเพิ่มเติม โปรดดู การบํารุงรักษาโต๊ะเลคเฮาส์

การเพิ่มประสิทธิภาพ V-Order

V-Order เป็นการเพิ่มประสิทธิภาพเวลาเขียนที่ใช้การเรียงลําดับการเข้ารหัสและการบีบอัดที่เข้ากันได้กับ VertiPaq กับไฟล์ Parquet:

• Power BI Direct Lake: การปรับปรุง 40-60% ในคิวรีแคชเย็น
• จุดสิ้นสุดการวิเคราะห์ SQL และคลังสินค้า: การปรับปรุงประสิทธิภาพการอ่านประมาณ 10%
• Spark: ไม่มีประโยชน์ในการอ่านโดยธรรมชาติ เขียนช้าลง 15-33%

เมื่อใดควรเปิดใช้งาน V-Order

V-Order ให้ประโยชน์สูงสุดสําหรับ:

• ตารางเลเยอร์สีทองที่ให้บริการ Power BI Direct Lake
• ตารางที่คิวรีบ่อยผ่านปลายทางการวิเคราะห์ SQL
• ปริมาณงานที่ต้องอ่านหนักซึ่งประสิทธิภาพการเขียนมีความสําคัญน้อยกว่า

เมื่อใดที่ควรหลีกเลี่ยง V-Order

พิจารณาปิดใช้งาน V-Order สําหรับ:

• ตารางชั้นบรอนซ์เน้นความเร็วในการกลืนกิน
• ไปป์ไลน์ Spark-to-Spark ที่ SQL และ Power BI ไม่ใช้ข้อมูล
• ปริมาณงานที่เขียนหนักซึ่งเวลาแฝงของข้อมูลเป็นสิ่งสําคัญ

กําหนดค่า V-Order

V-Order ถูกปิดใช้งานตามค่าเริ่มต้นในพื้นที่ทํางาน Fabric ใหม่ หากต้องการเปิดใช้งาน:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

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

สําหรับข้อมูลเพิ่มเติม ดูการปรับตาราง Delta Lake ให้เหมาะสมและ V-Order

Liquid Clustering และ Z-Order

การคลัสเตอร์ของเหลว

Liquid Clustering เป็นแนวทางที่แนะนําสําหรับการจัดระเบียบข้อมูล ซึ่งแตกต่างจากการแบ่งพาร์ติชันแบบดั้งเดิม Liquid Clustering:

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

เปิดใช้งาน Liquid Clustering เมื่อสร้างตาราง:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-ออเดอร์

Z-Order จะรวบรวมข้อมูลที่เกี่ยวข้องในไฟล์เดียวกัน คุณจึงได้รับประสิทธิภาพการสืบค้นที่ดีขึ้นบนเพรดิเคตตัวกรอง

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

ใช้ Z-Order เมื่อ:

• ตารางของคุณถูกแบ่งพาร์ติชัน เนื่องจาก Liquid Clustering ไม่ทํางานกับตารางที่แบ่งพาร์ติชัน
• คิวรีของคุณมักจะกรองคอลัมน์ตั้งแต่สองคอลัมน์ขึ้นไปพร้อมกัน
• เพรดิเคตของคุณคัดเลือกได้มากพอที่จะได้รับประโยชน์จากการข้ามไฟล์

คําแนะนําสถาปัตยกรรม Medallion

สถาปัตยกรรมเหรียญ (ชั้นบรอนซ์ เงิน ทอง) เป็นกรอบการทํางานสําหรับการเพิ่มประสิทธิภาพกลยุทธ์การบํารุงรักษาโต๊ะตามวัตถุประสงค์ของแต่ละชั้น

ชั้นบรอนซ์ (โซนลงจอด)

ตารางบรอนซ์มุ่งเน้นไปที่ประสิทธิภาพการเขียนและการนําเข้าที่มีเวลาแฝงต่ํา:

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

ตารางบรอนซ์ไม่ควรให้บริการโดยตรงไปยังจุดสิ้นสุดการวิเคราะห์ SQL หรือผู้บริโภค Power BI Direct Lake

ชั้นเงิน (โซนคัดสรร)

ตารางสีเงินสมดุลประสิทธิภาพการเขียนและการอ่าน:

• ลําดับความสําคัญของการเพิ่มประสิทธิภาพ: สมดุลระหว่างการนําเข้าและประสิทธิภาพของคิวรี
• ขนาดไฟล์: ปานกลาง (128-256 MB) เพื่อรองรับทั้งการเขียนและการอ่าน
• V-Order: ไม่จําเป็น; เปิดใช้งานหากจุดสิ้นสุดการวิเคราะห์ SQL หรือการใช้ Power BI มีนัยสําคัญ
• Liquid Clustering หรือ Z-Order: แนะนําเพื่อเพิ่มประสิทธิภาพการสืบค้น
• การบดอัดอัตโนมัติและการเพิ่มประสิทธิภาพการเขียน: เปิดใช้งานตามความต้องการดาวน์สตรีม
• เวกเตอร์การลบ: เปิดใช้งานสําหรับตารางที่มีการอัปเดตบ่อยครั้ง
• เพิ่มประสิทธิภาพตามกําหนดเวลา: เรียกใช้อย่างจริงจังเพื่อรักษาเค้าโครงไฟล์

ชั้นทอง (โซนเสิร์ฟ)

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

• ลําดับความสําคัญของการเพิ่มประสิทธิภาพ: อ่านประสิทธิภาพสําหรับการวิเคราะห์
• ขนาดไฟล์: ใหญ่ (400 MB ถึง 1 GB) เพื่อประสิทธิภาพ SQL และ Power BI ที่เหมาะสมที่สุด
• V-Order: จําเป็นสําหรับ Power BI Direct Lake มีประโยชน์สําหรับปลายทางการวิเคราะห์ SQL
• Liquid Clustering: จําเป็นสําหรับการข้ามไฟล์ที่เหมาะสมที่สุด
• เพิ่มประสิทธิภาพการเขียน: จําเป็นสําหรับขนาดไฟล์ที่สอดคล้องกัน
• การเพิ่มประสิทธิภาพตามกําหนดเวลา: ทํางานอย่างจริงจังเพื่อรักษาเลย์เอาต์ที่เหมาะสมที่สุด

เพิ่มประสิทธิภาพตารางทองให้แตกต่างออกไปตามกลไกการบริโภคหลัก:

เครื่องยนต์การบริโภค	สั่งซื้อ V	ขนาดไฟล์เป้าหมาย	ขนาดกลุ่มแถว
จุดสิ้นสุดการวิเคราะห์ SQL	ใช่	400 ล้านบาท	2 ล้านแถว
Power BI Direct Lake	ใช่	400 MB ถึง 1 GB	8+ ล้านแถว
Spark	เลือกได้	128 MB ถึง 1 GB	1-2 ล้านแถว

สําเนาตารางหลายชุด

เป็นที่ยอมรับในการรักษาสําเนาหลายชุดของตารางที่ปรับให้เหมาะสมสําหรับรูปแบบการใช้ที่แตกต่างกัน:

• โต๊ะสีเงินที่ปรับให้เหมาะกับการประมวลผล Spark
• ตารางสีทองที่ปรับให้เหมาะสมสําหรับจุดสิ้นสุดการวิเคราะห์ SQL และ Power BI Direct Lake
• ไปป์ไลน์ข้อมูลที่แปลงและวางโครงสร้างที่เหมาะสมในแต่ละเลเยอร์

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

ระบุความสมบูรณ์ของตาราง

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

ตรวจสอบไฟล์ Parquet โดยตรง

คุณสามารถเรียกดูโฟลเดอร์ตารางใน OneLake เพื่อตรวจสอบขนาดของไฟล์ Parquet แต่ละไฟล์ ตารางที่สมบูรณ์มีขนาดไฟล์ที่กระจายอย่างสม่ําเสมอ ค้นหา:

• ขนาดไฟล์ที่สอดคล้องกัน: ไฟล์ควรมีขนาดเท่ากันโดยประมาณ (ไม่เกิน 2 เท่า)
• ไม่มีไฟล์ขนาดเล็กมาก: ไฟล์ที่มีขนาดต่ํากว่า 25 MB บ่งบอกถึงการกระจายตัว
• ไม่มีไฟล์ขนาดใหญ่มาก: ไฟล์ที่มีขนาดมากกว่า 2 GB สามารถลดความขนานได้

การกระจายขนาดไฟล์ที่ไม่สม่ําเสมอมักบ่งชี้ถึงการบดอัดที่ขาดหายไปหรือรูปแบบการเขียนที่ไม่สอดคล้องกันในงานต่างๆ

เพิ่มประสิทธิภาพ DRY RUN ใน Spark SQL

ใช้ตัวเลือก DRY RUN เพื่อดูตัวอย่างว่าไฟล์ใดมีสิทธิ์สําหรับการเพิ่มประสิทธิภาพโดยไม่ต้องดําเนินการบีบอัด:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

คําสั่งส่งคืนรายการของไฟล์ที่จะถูกเขียนใหม่ในระหว่างการเพิ่มประสิทธิภาพ ใช้เพื่อ:

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

การกระจายขนาดไฟล์

ใช้วิธีการต่อไปนี้เพื่อวิเคราะห์ขนาดและการกระจายไฟล์:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

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

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

กําหนดความต้องการในการเพิ่มประสิทธิภาพ

เปรียบเทียบขนาดไฟล์จริงกับขนาดเป้าหมายตามกลไกการใช้:

เครื่องยนต์	ขนาดไฟล์เป้าหมาย	หากไฟล์มีขนาดเล็กลง	ถ้าไฟล์มีขนาดใหญ่กว่า
จุดสิ้นสุดการวิเคราะห์ SQL	400 ล้านบาท	เรียกใช้ OPTIMIZE	ไฟล์เป็นที่ยอมรับ
Power BI Direct Lake	400 MB ถึง 1 GB	เรียกใช้ OPTIMIZE VORDER	ไฟล์เป็นที่ยอมรับ
Spark	128 MB ถึง 1 GB	เปิดใช้งานการบดอัดอัตโนมัติ	ไฟล์เป็นที่ยอมรับ

ประวัติตารางและบันทึกธุรกรรม

ตรวจสอบประวัติตารางเพื่อทําความเข้าใจรูปแบบการเขียนและความถี่ในการบํารุงรักษา:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

แนวทางปฏิบัติแนะนําในการกําหนดค่า

ใช้คุณสมบัติของตารางมากกว่าการกําหนดค่าเซสชัน

คุณสมบัติของตารางจะคงอยู่ตลอดเซสชันและรับรองพฤติกรรมที่สอดคล้องกันในงานและผู้เขียนทั้งหมด:

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

การกําหนดค่าระดับเซสชันใช้กับเซสชัน Spark ปัจจุบันเท่านั้น และอาจทําให้เกิดการเขียนที่ไม่สอดคล้องกันหากเซสชันที่แตกต่างกันใช้การกําหนดค่าที่แตกต่างกัน

เปิดใช้งานขนาดไฟล์เป้าหมายที่ปรับเปลี่ยนได้

ขนาดไฟล์เป้าหมายที่ปรับเปลี่ยนได้จะปรับเป้าหมายขนาดไฟล์โดยอัตโนมัติตามขนาดตาราง:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

คุณลักษณะนี้:

• เริ่มต้นด้วยไฟล์ขนาดเล็ก (128 MB) สําหรับตารางขนาดเล็ก
• ปรับขนาดได้สูงสุด 1 GB สําหรับตารางที่มีขนาดมากกว่า 10 TB
• ประเมินใหม่โดยอัตโนมัติระหว่าง OPTIMIZE การดําเนินงาน

เปิดใช้งานเป้าหมายการบีบอัดระดับไฟล์

ป้องกันการเขียนแฟ้มที่กระชับไว้ก่อนหน้านี้ใหม่เมื่อขนาดเป้าหมายเปลี่ยนไป:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

สรุปคําแนะนํา

ชั้น	การบดอัดอัตโนมัติ	เพิ่มประสิทธิภาพการเขียน	สั่งซื้อ V	การคลัสเตอร์ของเหลว	OPTIMIZE ตามกําหนดเวลา
Bronze	เปิดใช้งาน (ไม่บังคับ)	เปิดใช้งาน	ไม่	ไม่	เลือกได้
เงิน	เปิดใช้งาน	เปิดใช้งาน	เลือกได้	ใช่	ก้าวร้าว
ทอง	เปิดใช้งาน	เปิดใช้งาน	ใช่	ใช่	ก้าวร้าว

สําหรับสถานการณ์เฉพาะ ให้ใช้คําแนะนําต่อไปนี้:

• Spark-to-Spark: มุ่งเน้นไปที่การเพิ่มประสิทธิภาพขนาดไฟล์ V-Order เป็นตัวเลือก
• Spark-to-SQL: เปิดใช้งานการเพิ่มประสิทธิภาพการเขียนและการบดอัดอัตโนมัติ กําหนดเป้าหมายไฟล์ 400 MB ที่มีกลุ่มแถว 2 ล้านกลุ่ม
• การนําเข้าสตรีมมิ่ง: เปิดใช้งานการบดอัดอัตโนมัติ จัดกําหนดการงานเพิ่มเติมOPTIMIZEสําหรับผู้ใช้ SQL
• Power BI Direct Lake: เปิดใช้งาน V-Order; เป้าหมาย 8+ ล้านกลุ่มแถว วิ่ง OPTIMIZE VORDER.

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

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