ทําความเข้าใจเกี่ยวกับที่เก็บข้อมูลสําหรับแบบจําลองความหมาย Direct Lake

  • บทความ

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

ตาราง Delta

มีตาราง Delta อยู่ใน OneLake พวกเขาจัดระเบียบข้อมูลที่ยึดตามไฟล์ลงในแถวและคอลัมน์ และพร้อมใช้งานสําหรับเครื่องคํานวณ Microsoft Fabric เช่น สมุดบันทึก Kusto และ lakehouse และคลังสินค้า คุณสามารถคิวรีตาราง Delta ได้โดยใช้ Data Analysis Expressions (DAX), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL และแม้แต่ Python

หมายเหตุ

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

ตาราง Delta จัดเก็บข้อมูลของพวกเขาในไฟล์ Parquet ซึ่งโดยทั่วไปแล้วจะถูกจัดเก็บไว้ใน lakehouse ที่แบบจําลองความหมาย Direct Lake ใช้เพื่อโหลดข้อมูล อย่างไรก็ตามไฟล์ Parquet ยังสามารถจัดเก็บภายนอกได้ ไฟล์ Parquet ภายนอกสามารถอ้างอิงได้โดยใช้ทางลัด OneLake ซึ่งจะชี้ไปยังตําแหน่งที่เก็บข้อมูลเฉพาะ เช่น Azure Data Lake Storage (ADLS) Gen2, บัญชีที่เก็บข้อมูล Amazon S3 หรือ Dataverse ในเกือบทุกกรณี กลไกการคํานวณจะเข้าถึงไฟล์ Parquet โดยการคิวรีตาราง Delta อย่างไรก็ตาม โดยทั่วไปแล้วแบบจําลองความหมาย Direct Lake จะโหลดข้อมูลคอลัมน์โดยตรงจากไฟล์ Parquet ที่ปรับให้เหมาะสมใน OneLake โดยใช้กระบวนการที่เรียกว่า การแปลงรหัส

การกําหนดรุ่นข้อมูล

ตาราง Delta ประกอบด้วยไฟล์ Parquet อย่างน้อยหนึ่งไฟล์ ไฟล์เหล่านี้จะมาพร้อมกับชุดของไฟล์ลิงก์ที่ใช้ JSON ซึ่งติดตามลําดับและลักษณะของไฟล์ Parquet แต่ละรายการที่เชื่อมโยงกับตาราง Delta

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

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

ProductID StockOnHand
A 1
B 2
C 3

ข้อมูลตาราง Delta ถูกเก็บไว้ในไฟล์ Parquet เดียวที่มีข้อมูลทั้งหมด และมีไฟล์ลิงก์เดียวที่มีเมตาดาต้าเกี่ยวกับเมื่อแทรกข้อมูล (ต่อท้าย)

  • ไฟล์ Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • ไฟล์ลิงก์ 1:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 1 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก

แทรกการดําเนินการ

พิจารณาสิ่งที่เกิดขึ้นเมื่อมีการแทรกการดําเนินการ: แถวใหม่สําหรับผลิตภัณฑ์ C ที่มีมูลค่าสินค้าคงคลังคงเหลือ 4 จะถูกแทรก การดําเนินการนี้ส่งผลให้เกิดการสร้างไฟล์ Parquet ใหม่และไฟล์ลิงก์ ดังนั้นจึงมีไฟล์ Parquet สองไฟล์และไฟล์ลิงก์สองไฟล์ตอนนี้

  • ไฟล์ Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • ไฟล์ Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • ไฟล์ลิงก์ 1:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 1 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก
  • ไฟล์ลิงก์ 2:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 2 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก

ในตอนนี้ คิวรีของตาราง Delta จะส่งกลับผลลัพธ์ต่อไปนี้ ไม่สําคัญว่าผลลัพธ์จะมาจากไฟล์ Parquet หลายไฟล์

ProductID StockOnHand
A 1
B 2
C 3
D 4

ทุก ๆ การดําเนินการแทรกที่ตามมาจะสร้างไฟล์ Parquet และไฟล์ลิงก์ใหม่ ซึ่งหมายความว่า จํานวนของไฟล์ Parquet และไฟล์ลิงก์จะเพิ่มขึ้นทุกการดําเนินการแทรก

การดำเนินการปรับปรุง

ตอนนี้ให้พิจารณาว่าจะเกิดอะไรขึ้นเมื่อการดําเนินการอัปเดตเกิดขึ้น: แถวสําหรับผลิตภัณฑ์Dมีค่าสต็อกคงเหลือเปลี่ยนเป็น10 การดําเนินการนี้ส่งผลให้เกิดการสร้างไฟล์ Parquet ใหม่และไฟล์ลิงก์ดังนั้นจึงมีไฟล์ Parquet สามไฟล์และไฟล์ลิงก์สามไฟล์ตอนนี้

  • ไฟล์ Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • ไฟล์ Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • ไฟล์ Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • ไฟล์ลิงก์ 1:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 1 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก
  • ไฟล์ลิงก์ 2:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 2 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก
  • ไฟล์ลิงก์ 3:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 3 ถูกสร้างขึ้น และบันทึกที่มีการอัปเดตข้อมูล

ในตอนนี้ คิวรีของตาราง Delta จะส่งกลับผลลัพธ์ต่อไปนี้

ProductID StockOnHand
A 1
B 2
C 10
D 4

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

การดำเนินการลบ

ตอนนี้ให้พิจารณาว่าเกิดอะไรขึ้นเมื่อการดําเนินการลบเกิดขึ้น: แถวสําหรับผลิตภัณฑ์ B จะถูกลบ การดําเนินการนี้ส่งผลให้ไฟล์ Parquet ใหม่และไฟล์เชื่อมโยงดังนั้นขณะนี้มีไฟล์ Parquet สี่ไฟล์และไฟล์ลิงก์สี่ไฟล์

  • ไฟล์ Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • ไฟล์ Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • ไฟล์ Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • ไฟล์ Parquet 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • ไฟล์ลิงก์ 1:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 1 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก
  • ไฟล์ลิงก์ 2:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 2 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกผนวก
  • ไฟล์ลิงก์ 3:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 3 ถูกสร้างขึ้น และบันทึกที่มีการอัปเดตข้อมูล
  • ไฟล์ลิงก์ 4:
    • ประกอบด้วยประทับเวลาเมื่อ Parquet file 4 ถูกสร้างขึ้น และบันทึกที่ข้อมูลถูกลบ

โปรดสังเกตว่า Parquet file 4 ไม่มีข้อมูลสําหรับผลิตภัณฑ์ Bอีกต่อไป แต่จะมีข้อมูลสําหรับแถวอื่น ๆ ทั้งหมดในตาราง

ในตอนนี้ คิวรีของตาราง Delta จะส่งกลับผลลัพธ์ต่อไปนี้

ProductID StockOnHand
A 1
C 10
D 4

หมายเหตุ

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

สำคัญ

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

หากต้องการจัดการจํานวนไฟล์ Parquet โปรดดู การบํารุงรักษา ตาราง Delta ในภายหลังในบทความนี้

การเดินทางเวลาเดลต้า

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

พิจารณาตัวอย่างคิวรีต่อไปนี้

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

เคล็ดลับ

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

นี่คือตัวอย่างคิวรีก่อนหน้านี้ที่เขียนใหม่ด้วยไวยากรณ์แบบย่อ

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

สำคัญ

เวอร์ชันตารางที่สามารถเข้าถึงได้ด้วยการเดินทางเวลาจะถูกกําหนดโดยการรวมกันของขีดจํากัดการเก็บข้อมูลสําหรับไฟล์บันทึกธุรกรรมและความถี่และการเก็บข้อมูลที่ระบุสําหรับการดําเนินการสูญญากาศ (อธิบายไว้ใน ส่วนการบํารุงรักษา ตาราง Delta) หากคุณเรียกใช้สูญญากาศทุกวันตามค่าเริ่มต้น ข้อมูลเจ็ดวันจะพร้อมใช้งานสําหรับการเดินทางในเวลา

กรอบ

การ เฟรมคือการดําเนินการ Direct Lake ที่ตั้งค่าเวอร์ชันของตาราง Delta ที่ควรใช้ในการโหลดข้อมูลลงในคอลัมน์แบบจําลองเชิงความหมาย สิ่งสําคัญเท่ากัน เวอร์ชันยังกําหนดสิ่งที่ควรแยกออกเมื่อโหลดข้อมูล

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

สำคัญ

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับเฟรมมิ่ง ดู ภาพรวม Direct Lake

การแบ่งพาร์ติชันตาราง

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

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

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

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

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

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

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

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

สำคัญ

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

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

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

คำเตือน

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

ไฟล์ Parquet

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

หมายเหตุ

คุณสามารถเข้าถึงไฟล์ Parquet ที่เชื่อมโยงกับตาราง Delta ได้โดยใช้เครื่องมือเช่น OneLake file explorer สามารถดาวน์โหลดคัดลอกหรือย้ายไฟล์ไปยังปลายทางอื่น ๆ ได้อย่างง่ายดายเช่นเดียวกับการย้ายไฟล์อื่น ๆ อย่างไรก็ตามเป็นการผสมผสานของไฟล์ Parquet และไฟล์ลิงก์ที่ใช้ JSON ที่อนุญาตให้กลไกการคํานวณออกคิวรีกับไฟล์เป็นตาราง Delta

รูปแบบไฟล์ Parquet

รูปแบบภายในของไฟล์ Parquet แตกต่างจากรูปแบบพื้นที่จัดเก็บข้อมูลทั่วไปอื่น ๆ เช่น CSV, TSV, XMLA และ JSON รูปแบบเหล่านี้จัดระเบียบข้อมูลตามแถว ในขณะที่ Parquet จัดระเบียบข้อมูลตามคอลัมน์ นอกจากนี้รูปแบบไฟล์ Parquet ยังแตกต่างจากรูปแบบเหล่านี้เนื่องจากจัดระเบียบแถวของข้อมูลลงในกลุ่มแถวอย่างน้อยหนึ่งกลุ่ม

โครงสร้างข้อมูลภายในของแบบจําลองความหมายของ Power BI นั้นยึดตามคอลัมน์ ซึ่งหมายความว่าไฟล์ Parquet แชร์ร่วมกันอย่างมากกับ Power BI ความคล้ายคลึงกันนี้หมายความว่าแบบจําลองความหมาย Direct Lake สามารถโหลดข้อมูลจากไฟล์ Parquet ลงในหน่วยความจําได้โดยตรงได้อย่างมีประสิทธิภาพ อันที่จริงแล้ว สามารถโหลดข้อมูลจํานวนมากได้ภายในไม่กี่วินาที เปรียบเทียบความสามารถนี้กับการรีเฟรชแบบจําลองความหมายแบบนําเข้าซึ่งต้องดึงข้อมูลบล็อกหรือข้อมูลต้นฉบับ จากนั้นประมวลผล เข้ารหัส จัดเก็บ และโหลดลงในหน่วยความจํา การดําเนินการรีเฟรชแบบจําลองความหมายการนําเข้าสามารถใช้การคํานวณ (หน่วยความจําและ CPU) จํานวนมาก และใช้เวลามากในการดําเนินการให้เสร็จสมบูรณ์ อย่างไรก็ตามด้วยตาราง Delta ความพยายามส่วนใหญ่ในการเตรียมข้อมูลที่เหมาะสมสําหรับการโหลดโดยตรงลงในแบบจําลองความหมายจะเกิดขึ้นเมื่อสร้างไฟล์ Parquet

วิธีที่ไฟล์ Parquet จัดเก็บข้อมูล

พิจารณาชุดตัวอย่างของข้อมูลต่อไปนี้

วันที่ ProductID StockOnHand
2024-09-16 ท 10
2024-09-16 B 11
2024-09-17 ท 13
…

เมื่อจัดเก็บในรูปแบบไฟล์ Parquet ตามแนวคิดแล้ว ชุดข้อมูลนี้อาจมีลักษณะเหมือนกับข้อความต่อไปนี้

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

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

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

เมื่อแบบจําลองความหมาย Direct Lake ต้องการข้อมูลเพื่อคํานวณผลรวมของ StockOnHand คอลัมน์ที่จัดกลุ่มตาม ProductIDจะต้องมีพจนานุกรมและข้อมูลที่เกี่ยวข้องกับสองคอลัมน์เท่านั้น ในไฟล์ขนาดใหญ่ที่มีหลายคอลัมน์ คุณสามารถข้ามส่วนที่สําคัญของไฟล์ Parquet เพื่อช่วยเร่งความเร็วกระบวนการอ่านได้

หมายเหตุ

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

สั่งซื้อ V

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

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

หมายเหตุ

ไฟล์ Parquet ที่มีการใช้ V-Order ยังคงสอดคล้องกับรูปแบบไฟล์ Parquet โอเพนซอร์ส ดังนั้นสามารถอ่านได้โดยเครื่องมือที่ไม่ใช่ Fabric

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

การปรับตาราง Delta ให้เหมาะสม

ในส่วนนี้จะอธิบายหัวข้อต่าง ๆ สําหรับการปรับตาราง Delta ให้เหมาะสมสําหรับแบบจําลองเชิงความหมาย

ปริมาณข้อมูล

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

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

นอกจากนี้ ตรวจสอบให้แน่ใจว่ามี การใช้ V-Order เนื่องจากส่งผลให้มีขนาดเล็กลงและดังนั้นจึงทําให้ไฟล์เร็วขึ้นในการอ่าน

ชนิดข้อมูลของคอลัมน์

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

เมื่อคุณใช้ชนิดข้อมูลตัวเลขโดยประมาณ (เช่น เลขทศนิยมและจริง) ให้พิจารณาค่าการปัดเศษและใช้ความแม่นยําที่ต่ํากว่า

คอลัมน์ที่ไม่จําเป็น

เช่นเดียวกับตารางข้อมูลใด ๆ ตาราง Delta ควรจัดเก็บคอลัมน์ที่จําเป็นเท่านั้น ในบริบทของบทความนี้ ซึ่งหมายความว่าแบบจําลองความหมายต้องการ แม้ว่าอาจมีปริมาณงานวิเคราะห์อื่น ๆ ที่คิวรีตาราง Delta

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

เนื่องจากแบบจําลองความหมาย Direct Lake ไม่รองรับคอลัมน์จากการคํานวณ คุณควรแสดงคอลัมน์ดังกล่าวในตาราง Delta โปรดทราบว่าวิธีการออกแบบนี้เป็นรูปแบบป้องกันสําหรับแบบจําลองความหมายการนําเข้าและ DirectQuery ตัวอย่างเช่น ถ้าคุณมี FirstName และ LastName คอลัมน์ และคุณต้องการคอลัมน์ FullName ให้แสดงค่าสําหรับคอลัมน์นี้เมื่อแทรกแถวลงในตาราง Delta

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

ขนาดกลุ่มแถว

ภายใน ไฟล์ Parquet จัดระเบียบแถวของข้อมูลลงในหลายกลุ่มแถวภายในแต่ละไฟล์ ตัวอย่างเช่น ไฟล์ Parquet ที่ประกอบด้วย 30,000 แถวอาจแบ่งกลุ่มเป็นสามกลุ่ม แถวแต่ละกลุ่มมี 10,000 แถว

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

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

สำคัญ

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

การบํารุงรักษาตารางเดลต้า

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

ปรับให้เหมาะสม

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

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

สุญญากาศ

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

สำคัญ

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

ตาราง REORG

คุณสามารถใช้ ตาราง REORG เพื่อจัดระเบียบตาราง Delta ใหม่โดยการเขียนไฟล์ใหม่เพื่อล้างข้อมูลที่ถูกลบนุ่มนวล เช่น เมื่อคุณวางคอลัมน์โดยใช้ คอลัมน์ ALTER TABLE DROP

การบํารุงรักษาตารางโดยอัตโนมัติ

หากต้องการดําเนินการบํารุงรักษาตารางโดยอัตโนมัติ คุณสามารถใช้ Lakehouse API ได้ สําหรับข้อมูลเพิ่มเติม ดูจัดการเลคเฮ้าส์ด้วย Microsoft Fabric REST API

เคล็ดลับ

คุณยังสามารถใช้คุณลักษณะการบํารุงรักษา Lakehouse Table ในพอร์ทัล Fabric เพื่อลดความซับซ้อนของตาราง Delta ของคุณได้

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