การสร้างแบบจําลองเชิงมิติใน Microsoft Fabric Warehouse: ตารางโหลด

นําไปใช้กับ:✅ จุดสิ้นสุดการวิเคราะห์ SQL และ Warehouse ใน Microsoft Fabric

หมายเหตุ

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

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

หมายเหตุ

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

เคล็ดลับ

หากคุณไม่มีประสบการณ์ด้านการสร้างแบบจําลองมิติ ให้พิจารณาชุดบทความนี้ในขั้นตอนแรกของคุณ ซึ่งไม่ได้มีไว้เพื่อการสนทนาที่สมบูรณ์เกี่ยวกับการออกแบบแบบจําลองเชิงมิติ สําหรับข้อมูลเพิ่มเติม ให้ดูที่เนื้อหาที่เผยแพร่ที่ปรับใช้อย่างกว้างขวางโดยตรง เช่น ชุดเครื่องมือคลังข้อมูล: คําแนะนําในการสร้างแบบจําลอง เชิงมิติฉบับสมบูรณ์ (รุ่นที่ 3, 2013) โดย Ralph Kimball และอื่น ๆ

โหลดแบบจําลองมิติ

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

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

โดยเฉพาะ คุณสามารถ:

• ใช้ ไปป์ไลน์ ข้อมูลเพื่อสร้างเวิร์กโฟลว์เพื่อปรับกระบวนการ ETL ไปป์ไลน์ข้อมูลสามารถดําเนินการสคริปต์ SQL ขั้นตอนการจัดเก็บ และอื่น ๆ
• ใช้ กระแส ข้อมูลเพื่อพัฒนาตรรกะที่มีรหัสต่ําเพื่อนําเข้าข้อมูลจากแหล่งข้อมูลหลายร้อยแหล่ง กระแสข้อมูลสนับสนุนการรวมข้อมูลจากหลายแหล่งข้อมูล แปลงข้อมูล และโหลดข้อมูลดังกล่าวไปยังปลายทาง เช่น ตารางแบบจําลองมิติ กระแสข้อมูลถูกสร้างขึ้นโดยใช้ประสบการณ์ Power Query ที่คุ้นเคยซึ่งปัจจุบันมีให้ใช้งานในผลิตภัณฑ์ของ Microsoft มากมาย รวมถึง Microsoft Excel และ Power BI Desktop ด้วย

หมายเหตุ

การพัฒนา ETL อาจซับซ้อน และการพัฒนาอาจเป็นเรื่องท้าทาย มีการประเมินว่า 60-80 เปอร์เซ็นต์ของความพยายามในการพัฒนาคลังข้อมูลนั้นอุทิศให้กับกระบวนการ ETL

การประสานรวม

ขั้นตอนการทํางานทั่วไปของกระบวนการ ETL คือ:

1. หรือ โหลดตารางการจัดเตรียม
2. ประมวลผลตารางมิติ
3. ประมวลผลตารางข้อเท็จจริง
4. อีกทางหนึ่งคือ ดําเนินงานหลังการประมวลผล เช่น การทริกเกอร์การรีเฟรชเนื้อหา Fabric ที่ขึ้นต่อกัน (เช่น แบบจําลองความหมาย)

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

สามารถประมวลผลตารางข้อเท็จจริงได้เมื่อมีการประมวลผลตารางมิติทั้งหมด

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

ข้อมูลขั้นตอน

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

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

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

หมายเหตุ

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

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

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

• มิเรอร์ ซึ่งเป็นโซลูชันแบบครบวงจรที่มีต้นทุนต่ําและเวลาแฝงต่ําที่ช่วยให้คุณสามารถสร้างแบบจําลองข้อมูลของคุณใน OneLake ได้ สําหรับข้อมูลเพิ่มเติม โปรดดูเหตุใดจึงใช้มิลเลอร์ใน Fabric
• ทางลัด OneLake ซึ่งจะชี้ไปยังตําแหน่งที่เก็บข้อมูลอื่น ๆ ซึ่งอาจประกอบด้วยข้อมูลต้นทางของคุณ ทางลัดสามารถใช้ เป็นตารางในคิวรี T-SQL ได้
• PolyBase ใน SQL Server ซึ่งเป็นคุณลักษณะการจําลองภาพเสมือนข้อมูลสําหรับ SQL Server PolyBase อนุญาตให้คิวรี T-SQL รวมข้อมูลจากแหล่งข้อมูลภายนอกไปยังตารางเชิงสัมพันธ์ในอินสแตนซ์ของ SQL Server
• การจําลองเสมือนข้อมูลด้วยอินสแตนซ์ที่จัดการแล้วของ Azure SQL ซึ่งช่วยให้คุณสามารถดําเนินการคิวรี T-SQL บนไฟล์ที่จัดเก็บข้อมูลในรูปแบบข้อมูลทั่วไปใน Azure Data Lake Storage (ADLS) Gen2 หรือ Azure Blob Storage และรวมเข้ากับข้อมูลเชิงสัมพันธ์ที่จัดเก็บไว้ในเครื่องโดยใช้การรวม

แปลงข้อมูล

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

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

หมายเหตุ

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

นี่คือการแปลงบางอย่างที่กระบวนการ ETL ของคุณสามารถดําเนินการได้

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

โหลดข้อมูล

คุณสามารถโหลดตารางใน Fabric Warehouse ได้โดยใช้ตัวเลือกการนําเข้าข้อมูลต่อไปนี้

• คัดลอกลงใน (T-SQL): ตัวเลือกนี้มีประโยชน์เมื่อข้อมูลต้นฉบับประกอบด้วยไฟล์ Parquet หรือ CSV ที่จัดเก็บในบัญชีเก็บข้อมูล Azure ภายนอก เช่น ADLS Gen2 หรือ Azure Blob Storage
• ไปป์ไลน์ข้อมูล: นอกเหนือจากการประมวลกระบวนการ ETL ไปป์ไลน์ข้อมูลสามารถรวมกิจกรรมที่เรียกใช้คําสั่ง T-SQL ดําเนินการค้นหา หรือคัดลอกข้อมูลจากแหล่งข้อมูลไปยังปลายทางได้
• กระแสข้อมูล: เป็นทางเลือกสําหรับไปป์ไลน์ข้อมูล กระแสข้อมูลมอบประสบการณ์ที่ไม่มีรหัสในการแปลงและทําความสะอาดข้อมูล
• การนําเข้าข้ามคลังสินค้า: เมื่อข้อมูลถูกเก็บไว้ในพื้นที่ทํางานเดียวกันการนําเข้าข้ามคลังสินค้าจะอนุญาตให้รวมตารางคลังสินค้าหรือตารางเลคเฮ้าส์ที่แตกต่างกัน รองรับคําสั่ง T-SQL เช่น INSERT…SELECTSELECT INTO, และCREATE TABLE AS SELECT (CTAS) คําสั่งเหล่านี้จะมีประโยชน์โดยเฉพาะอย่างยิ่งเมื่อคุณต้องการแปลงและโหลดข้อมูลจากตารางการกําหนดระยะภายในพื้นที่ทํางานเดียวกัน นอกจากนี้ยังเป็นการตั้งค่าการดําเนินการตาม ซึ่งอาจเป็นวิธีที่มีประสิทธิภาพและเร็วที่สุดในการโหลดตารางแบบจําลองมิติ

เคล็ดลับ

สําหรับคําอธิบายที่สมบูรณ์ของตัวเลือกการนําเข้าข้อมูลเหล่านี้รวมถึงแนวทางปฏิบัติที่ดีที่สุด ดูการนําเข้าข้อมูลลงใน Warehouse

การบันทึก

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

พิจารณาการบันทึก:

• กระบวนการ ETL:
  • ID เฉพาะสําหรับการดําเนินการ ETL แต่ละรายการ
  • เวลาเริ่มต้นและเวลาสิ้นสุด
  • สถานะ (ความสําเร็จหรือล้มเหลว)
  • ข้อผิดพลาดใด ๆ ที่พบ
• แต่ละตารางการจัดเตรียมและแบบจําลองมิติ:
  • เวลาเริ่มต้นและเวลาสิ้นสุด
  • สถานะ (ความสําเร็จหรือล้มเหลว)
  • แถวที่แทรก อัปเดต และถูกลบ
  • จํานวนแถวของตารางสุดท้าย
  • ข้อผิดพลาดใด ๆ ที่พบ
• การดําเนินการอื่น ๆ:
  • เวลาเริ่มต้นและเวลาสิ้นสุดของการดําเนินการรีเฟรชแบบจําลองความหมาย

เคล็ดลับ

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

ประมวลผลตารางมิติ

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

ไดอะแกรมต่อไปนี้แสดงตรรกะที่ใช้ในการประมวลผลตารางสําหรับมิติ

พิจารณากระบวนการของ Product ตารางมิติ

• เมื่อเพิ่มผลิตภัณฑ์ใหม่ลงในระบบต้นทาง ระบบจะแทรกแถวลงใน Product ตารางมิติ
• เมื่อมีการปรับเปลี่ยนผลิตภัณฑ์ แถวที่มีอยู่ในตารางมิติจะถูกอัปเดตหรือแทรก
  • เมื่อมีการใช้ SCD ชนิดที่ 1 การอัปเดตจะถูกทํากับแถวที่มีอยู่
  • เมื่อมีการใช้ SCD ชนิดที่ 2 การอัปเดตจะเกิดขึ้นเพื่อ ทําให้เวอร์ชันของแถวปัจจุบันหมดอายุ และแถวใหม่ที่แสดงเวอร์ชันปัจจุบันจะถูกแทรก
  • เมื่อใช้ SCD ชนิดที่ 3 กระบวนการที่คล้ายกับ SCD ชนิดที่ 1 จะเกิดขึ้น ให้อัปเดตแถวที่มีอยู่โดยไม่ต้องแทรกแถวใหม่

คีย์ตัวแทน

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

สำคัญ

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

จัดการการเปลี่ยนแปลงในอดีต

เมื่อตารางมิติต้อง จัดเก็บการเปลี่ยนแปลงในอดีต คุณจะต้องใช้มิติที่มีการเปลี่ยนแปลงอย่างช้า ๆ (SCD)

หมายเหตุ

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

อาจเป็นไปได้ว่ามิติสามารถสนับสนุนการเปลี่ยนแปลงชนิด SCD ชนิดที่ 1 และ/หรือ SCD ชนิดที่ 2 ได้

SCD ชนิดที่ 1

เมื่อ ตรวจพบการเปลี่ยนแปลง SCD ชนิดที่ 1 ให้ใช้ตรรกะต่อไปนี้

1. อัปเดตแอตทริบิวต์ที่เปลี่ยนแปลง
2. ถ้าตารางมี วันที่ ปรับเปลี่ยนล่าสุดและ ปรับเปลี่ยนครั้งล่าสุดตาม คอลัมน์ ให้ตั้งค่าวันที่และกระบวนการปัจจุบันที่ทําการแก้ไข

SCD ชนิดที่ 2

เมื่อ ตรวจพบการเปลี่ยนแปลง SCD ชนิดที่ 2 ให้ใช้ตรรกะต่อไปนี้

1. ทําให้เวอร์ชันปัจจุบันหมดอายุโดยการตั้งค่าคอลัมน์ความถูกต้องของวันที่สิ้นสุดเป็นวันที่ประมวลผล ETL (หรือประทับเวลาที่เหมาะสมในระบบต้นทาง) และค่าสถานะปัจจุบันเป็นFALSE
2. ถ้าตารางมี วันที่ ปรับเปลี่ยนล่าสุดและ ปรับเปลี่ยนครั้งล่าสุดตาม คอลัมน์ ให้ตั้งค่าวันที่และกระบวนการปัจจุบันที่ทําการแก้ไข
3. แทรกสมาชิกใหม่ที่มีคอลัมน์วันที่เริ่มต้นที่ถูกต้องและตั้งค่าเป็นค่าคอลัมน์วันที่สิ้นสุดที่ถูกต้อง (ใช้เพื่ออัปเดตเวอร์ชันก่อนหน้า) และมีการตั้งค่าสถานะเวอร์ชันปัจจุบันเป็นTRUE
4. ถ้าตารางมี วันที่ สร้างและ สร้างโดย คอลัมน์ ให้ตั้งค่าวันที่และกระบวนการปัจจุบันที่ทําการแทรก

SCD ชนิดที่ 3

เมื่อตรวจพบการเปลี่ยนแปลง SCD ชนิดที่ 3 ให้อัปเดตแอตทริบิวต์โดยใช้ตรรกะที่คล้ายกันเพื่อประมวลผล SCD ชนิดที่ 1

การลบสมาชิกมิติ

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

วิธีที่เหมาะสมในการจัดการการลบแหล่งข้อมูลคือ การบันทึกเป็นการลบแบบนุ่มนวล การลบแบบนุ่มนวลจะทําเครื่องหมายสมาชิกมิติว่าไม่ได้ใช้งานอยู่หรือไม่ถูกต้องอีกต่อไป เพื่อรองรับกรณีนี้ ตารางมิติของคุณควรมีแอตทริบิวต์บูลีนที่มีชนิดข้อมูลบิต เช่นIsDeleted อัปเดตคอลัมน์นี้สําหรับสมาชิกมิติที่ถูกลบใด ๆ เป็น TRUE (1) เวอร์ชันปัจจุบันของสมาชิกมิติอาจถูกทําเครื่องหมายในทํานองเดียวกันด้วยค่าบูลีน (บิต) ในIsCurrentคอลัมน์ หรือIsActive คิวรีการรายงานและแบบจําลองความหมายของ Power BI ทั้งหมดควรกรองระเบียนที่มีการลบแบบนุ่มนวล

มิติวันที่

มิติ ปฏิทินและเวลาเป็นกรณีพิเศษเนื่องจากโดยปกติแล้วจะไม่มีข้อมูลต้นทาง แต่ถูกสร้างขึ้นโดยใช้ตรรกะคงที่แทน

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

เมื่อตารางมิติวันที่ประกอบด้วยแอตทริบิวต์ออฟเซตที่สัมพันธ์กัน ต้องเรียกใช้กระบวนการ ETL ทุกวันเพื่ออัปเดตค่าแอตทริบิวต์ออฟเซตตามวันที่ปัจจุบัน (วันนี้)

เราขอแนะนําให้เขียนตรรกะเพื่อขยายหรืออัปเดตตารางมิติวันที่ใน T-SQL และห่อหุ้มไว้ใน Stored Procedure

ประมวลผลตารางข้อเท็จจริง

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

หมายเหตุ

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

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

สำคัญ

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

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

ไดอะแกรมต่อไปนี้แสดงตรรกะที่ใช้ในการประมวลผลตารางข้อเท็จจริง

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

สำคัญ

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

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

ถ้าคุณไม่สามารถพึ่งพาข้อมูลระบบต้นทางเพื่อตรวจจับข้อเท็จจริงใหม่ได้อย่างมีประสิทธิภาพ คุณอาจสามารถพึ่งพาความสามารถของระบบต้นทางเพื่อดําเนินการโหลดแบบเพิ่มหน่วย ตัวอย่างเช่น SQL Server และ Azure SQL Managed Instance มีคุณลักษณะที่เรียกว่า เปลี่ยนแปลงการจับข้อมูล (CDC) ซึ่งสามารถติดตามการเปลี่ยนแปลงของแต่ละแถวในตารางได้ นอกจากนี้ SQL Server, Azure SQL Managed Instance และ Azure SQL Database ยังมีคุณลักษณะที่เรียกว่า การติดตามการเปลี่ยนแปลง ซึ่งสามารถระบุแถวที่มีการเปลี่ยนแปลงได้ เมื่อเปิดใช้งาน จะช่วยให้คุณสามารถตรวจหาข้อมูลใหม่ หรือข้อมูลที่เปลี่ยนแปลงในตารางฐานข้อมูลได้อย่างมีประสิทธิภาพ คุณยังสามารถเพิ่มทริกเกอร์ไปยังตารางเชิงสัมพันธ์ที่จัดเก็บคีย์ของการแทรก ปรับปรุง หรือลบระเบียนตารางได้

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

อนุมานสมาชิกมิติ

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

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

การอัปเดตข้อเท็จจริงหรือการลบ

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

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

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

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการโหลดข้อมูลลงใน Fabric Warehouse โปรดดู:

• การนําเข้าข้อมูลลงในคลังสินค้า
• การนําเข้าข้อมูลลงในคลังสินค้าของคุณโดยใช้ไปป์ไลน์ข้อมูล
• ส่งข้อมูลไปยังคลังสินค้าของคุณโดยใช้คําสั่ง COPY
• การนําเข้าข้อมูลลงในคลังสินค้าของคุณโดยใช้ Transact-SQL
• บทช่วยสอน: ตั้งค่า dbt สําหรับ Fabric Warehouse