รูปแบบงาน dbt ทั่วไปใน Microsoft Fabric (ตัวอย่าง)

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

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

เลือกรูปแบบก่อนที่คุณจะนําไปใช้

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

สรุปย่อ

รูปแบบที่ 1: เหรียญสําหรับคลังสินค้าเท่านั้น

เก็บ Bronze, Silver และ Gold ไว้ใน Fabric คลังข้อมูล ใช้สคีมาหรือรายการคลังสินค้าแยกกันเพื่อแยกชั้นข้อมูล

รูปที่ 1. เหรียญตราสําหรับโกดังเท่านั้น

ใช้รูปแบบนี้เมื่อ: แหล่งข้อมูลส่วนใหญ่เป็นแบบสัมพันธ์ ทีมงานเน้น SQL เป็นหลัก และคลังสินค้าเป็นแพลตฟอร์มที่เปลี่ยนแปลงและให้บริการตามธรรมชาติ

ตําแหน่งที่ dbt เหมาะสม: dbt จัดการการแปลง การทดสอบ การพึ่งพาโมเดล และ marts ที่คัดสรรมาอย่างดี ชั้น DBT เชิงตรรกะ เช่น staging, intermediate และ marts สามารถแมปไปยัง schema ของ Warehouse ได้โดยไม่ถูกมองว่าเป็นแนวคิดเดียวกัน

Where Fabric เหมาะสม: เก็บรักษาและดําเนินการโมเดลในคลังสินค้า Fabric pipeline สามารถประสานงานการนําเข้าและการดําเนินงานได้ Power BI ใช้ชั้น Gold ที่คัดสรรไว้

ทําไมต้องเลือก

• แพลตฟอร์มที่เน้น SQL สําหรับทุกเลเยอร์
• หลีกเลี่ยงการแนะนํา Spark เมื่องานไม่จําเป็น
• เหมาะสําหรับการย้ายคลังสินค้าและงาน BI มิติ

ข้อควรพิจารณา

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

รูปแบบที่ 2: ลานจอดบ้านพักริมทะเลสาบพร้อมการเปลี่ยนแปลงเป็นโกดัง

ลงดินข้อมูลดิบใน Lakehouse แล้วสร้างโมเดล Silver และ Gold ใน Warehouse พร้อม dbt

รูปที่ 2. ลงจอดบ้านเลคเฮาส์พร้อมแปลงโฉมโกดัง

ใช้รูปแบบนี้เมื่อ: ใช้รูปแบบนี้เมื่อข้อมูลดิบมาถึง OneLake แต่ทีมที่เน้น SQL ต้องการสร้างโมเดลทั้ง Silver และ Gold ใน Fabric คลังข้อมูล ด้วย T-SQL แนวทางนี้ทําให้การแปลงและการให้บริการอยู่ในเครื่องยนต์ความสัมพันธ์เดียวกัน

ตําแหน่งที่เหมาะสมของ dbt: dbt อ่านข้อมูล Lakehouse ผ่านจุดสิ้นสุดการวิเคราะห์ SQL แบบอ่านอย่างเดียว โดยใช้คําสั่งค้นหาข้ามฐานข้อมูล T-SQL และการตั้งชื่อสามส่วน เช่น LakehouseName.dbo.TableName. เส้นทางการเข้าถึงนี้จํากัดเฉพาะรายการที่อยู่ในพื้นที่ทํางาน Fabric เดียวกันเท่านั้น สําหรับสถานการณ์ข้ามพื้นที่ทํางาน สามารถใช้ทางลัด OneLake เพื่อเปิดเผยตาราง Delta ที่ต้องการ

จุดที่ Fabric เหมาะสม: Lakehouse เก็บข้อมูลดิบไว้ ร้านค้าในคลังสินค้าได้ปรับรูปแบบและคัดสรรโมเดลความสัมพันธ์ ท่อส่งข้อมูลประสานงานการนําเข้าข้อมูลและการประมวลผลฐานข้อมูล

ทําไมต้องเลือก

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

ข้อควรพิจารณา

• การเข้าถึงข้ามพื้นที่ทํางานต้องใช้ทางลัด OneLake เพื่อให้ตาราง Delta ที่จําเป็นพร้อมใช้งานในพื้นที่ทํางานที่ใช้ข้อมูล
• เฉพาะตาราง Delta ในพื้นที่ Lakehouse Tables เท่านั้นที่สามารถใช้งานได้ผ่าน SQL analytics endpoint
• คํานึงถึงพฤติกรรมการซิงโครไนซ์เมตาดาต้าและความแตกต่างระหว่างชนิดข้อมูล Delta และ T-SQL ที่รองรับ
• Lakehouse SQL analytics endpoint เป็นแบบอ่านอย่างเดียว dbt ผลิตโมเดล Silver และ Gold ในคลังสินค้าเป้าหมาย
• การใช้ทั้ง Lakehouse และ Warehouse ทําให้เกิดขอบเขตการดําเนินงานเพิ่มเติม

รูปแบบที่ 3: การปรับปรุงบ้านริมทะเลสาบพร้อมบริการในคลังสินค้า

ใช้ Lakehouse สําหรับ Bronze และ Silver แล้วเผยแพร่โมเดล Gold ที่คัดสรรไว้ไปยัง Warehouse

รูปที่ 3. การตกแต่งแบบ Lakehouse พร้อมบริการในคลังสินค้า

ใช้รูปแบบนี้เมื่อ: เลือกรูปแบบนี้เมื่อทีมวิศวกรรมข้อมูลปรับแต่งและเก็บรักษาข้อมูลบรอนซ์และซิลเวอร์ใน Lakehouse โดยใช้เครื่องมือที่เน้น Delta ขณะที่ทีมวิเคราะห์หรือ BI เผยแพร่โมเดลทองคําที่คัดสรรมาให้ Fabric คลังข้อมูล แนวทางนี้ให้ขอบเขตการปรับแต่งแบบ Lakehouse และ Warehouse ที่ชัดเจน

ตําแหน่งที่ dbt เหมาะสม: dbt สามารถเป็นเจ้าของการแปลง Lakehouse, โมเดล Warehouse Gold หรือทั้งสองอย่างผ่านโปรเจกต์หรืองานที่แยกจากกันอย่างชัดเจน รักษาให้แต่ละโปรเจกต์สอดคล้องกับขอบเขตของอะแดปเตอร์ เป้าหมาย และเจ้าของ

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

ทําไมต้องเลือก

• ช่วยให้ทีมวิศวกรรมข้อมูลใช้ Lakehouse เพื่อปรับแต่งที่เน้น Delta ขณะที่ทีมวิเคราะห์และ BI ใช้ Fabric คลังข้อมูล สําหรับการให้บริการเชิงสัมพันธ์
• ให้พื้นผิวคลังสินค้าที่คัดสรรมาอย่างดีสําหรับ BI แบบมิติ
• เก็บรักษาข้อมูลซิลเวอร์โดยละเอียดเพื่อการใช้งานในวงกว้าง

ข้อควรพิจารณา

• การดําเนินงานขั้นตอนการแปลงสภาพ Lakehouse และคลังสินค้าต้องใช้ทักษะทั้งสองด้าน และเพิ่มความซับซ้อนในการติดตั้ง การทดสอบ และการตรวจสอบ
• หลีกเลี่ยงการใช้กฎเดียวกันทั้งใน Lakehouse และ Warehouse
• กําหนดสัญญาที่ชัดเจนระหว่าง Silver และ Gold

รูปแบบที่ 4: เหรียญตราเฉพาะ Lakehouse

เก็บ Bronze, Silver และ Gold ไว้ใน Lakehouse ใช้อะแดปเตอร์ Fabric Lakehouse (dbt-fabricspark) เพื่อรันโมเดล dbt เป็น Spark SQL ผ่าน Fabric Livy API และเขียนผลลัพธ์เป็นตาราง Delta ใน OneLake

รูปที่ 4. เหรียญเฉพาะที่เก็บในเลคเฮาส์

ใช้รูปแบบนี้เมื่อ: แพลตฟอร์มนี้เน้น Lakehouse เป็นหลัก ข้อมูลควรอยู่ในรูปแบบ Delta และทีมงานต้องการโครงสร้างและการทดสอบโครงการ dbt

ตําแหน่งที่ dbt เหมาะสม: dbt เป็นเจ้าของการแปลง Lakehouse, การทดสอบ, การพึ่งพา และการทําให้เป็นวัตถุที่เลือกไว้ ตัดสินใจว่าการแยกทางกายภาพจะใช้สคีมา บ้านทะเลสาบแยกต่างหาก หรือขอบเขตการปกครองอื่น ๆ

ตําแหน่งที่เหมาะสมของ Fabric: OneLake และ Lakehouse เป็นที่เก็บข้อมูล ท่อส่งข้อมูลเป็นตัวกําหนดการนําเข้าและการเปลี่ยนแปลง Power BI สามารถใช้ข้อมูล Lakehouse ที่คัดสรรผ่าน Direct Lake, DirectQuery หรือ Import ขึ้นอยู่กับข้อกําหนดการรายงานและการกํากับดูแล

ทําไมต้องเลือก

• เก็บข้อมูลในรูปแบบ Delta ทั่วทั้งสถาปัตยกรรม
• ลดการเคลื่อนที่ระหว่าง Lakehouse และ Warehouse
• เหมาะสําหรับการใช้งานที่เน้นทะเลสาบและเน้น Spark

ข้อควรพิจารณา

• Lakehouse SQL analytics endpoint เป็นแบบอ่านอย่างเดียวและไม่ได้ใช้เขียนผลลัพธ์โมเดล dbt หากการแปลงของคุณต้องการการประมวลผล T-SQL ให้ใช้อะแดปเตอร์ Fabric คลังข้อมูล แทน
• อะแดปเตอร์ Fabric Lakehouse และ Fabric คลังข้อมูล ใช้เอนจินการประมวลผลที่แตกต่างกันและรองรับความสามารถที่แตกต่างกัน
• ยืนยันว่าอะแดปเตอร์ที่เลือกรองรับภาษา SQL, การทําให้เป็นวัสดุ, แพ็กเกจ และคําสั่งที่จําเป็นสําหรับโปรเจกต์ของคุณ
• พิจารณาชั้นทองเชิงสัมพันธ์ใน Fabric คลังข้อมูล สําหรับงาน BI ที่เน้นคลังสินค้า

เลือกโมเดลการเรียบเรียงเสียง

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

รูปที่ 5 Fabric pipeline ที่ควบคุม dbt ด้วยกิจกรรม ingestion, validation และ downstream

ใช้การจัดตารางเวลาแบบเนทีฟเมื่อ:

• งาน dbt จะทํางานอย่างอิสระตามตารางเวลาที่เกิดซ้ํา
• งานนี้ไม่ได้ขึ้นอยู่กับกิจกรรม Fabric ทั้งต้นน้ําหรือปลายน้ํา
• การติดตามระดับงานตอบสนองความต้องการเชิงปฏิบัติการ

ใช้ท่อ Fabric เมื่อ:

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

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

หลักการการดําเนินงาน

• กําหนดความเป็นเจ้าของที่ชัดเจนสําหรับการ ingestion, การปรับแต่งเงิน, การสร้างแบบจําลอง Gold, การเรียบเรียง และการสร้างแบบจําลองเชิงความหมาย
• ถือว่าการแบ่งขั้นตอนของ dbt, intermediate และ marts เป็นกลุ่มโมเดลเชิงตรรกะ; มันไม่ได้เท่ากับชั้นกายภาพของบรอนซ์ เงิน และทองโดยอัตโนมัติ
• หลีกเลี่ยงการซ้ํากันของตรรกะการแปลงข้อมูลข้ามฐานข้อมูล สมุดบันทึก ท่อส่งข้อมูล และโปรซีเยอร์ที่จัดเก็บ
• ใช้การจัดตารางงานแบบเนทีฟสําหรับงานอิสระ และใช้สายงาน Fabric สําหรับเวิร์กโฟลว์หลายกิจกรรม
• คํานึงถึงพฤติกรรมขณะรันไทม์ DBT job runtime V1.0 ไม่รองรับการแคช build หรือการนํา artifact กลับมาใช้ซ้ํา แต่ละรันจะคอมไพล์และรันโปรเจกต์จากซอร์สโค้ด สําหรับโครงการขนาดใหญ่ ให้รวมเวลาการคอมไพล์และการดําเนินการทั้งหมดเมื่อประมาณช่วงเวลาการตั้งเวลาและ SLA

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

• งาน dbt ใน Microsoft Fabric (ตัวอย่าง)
• จัดการงาน dbt ในสายงาน Fabric