ตัวควบคุมแหล่งที่มา, CI/CD และ ALM สําหรับตัวแทนข้อมูล Fabric (พรีวิว)

บทความนี้อธิบายวิธีจัดการตัวแทนข้อมูล Fabric โดยใช้การรวม Git และไปป์ไลน์การปรับใช้ซึ่งเป็นส่วนหนึ่งของความสามารถ Application Lifecycle Management (ALM) ของ Microsoft Fabric คุณเรียนรู้วิธีเชื่อมต่อพื้นที่ทํางานกับที่เก็บ Git นอกจากนี้ คุณยังจะได้เรียนรู้วิธีติดตามและกําหนดเวอร์ชันการกําหนดค่าตัวแทนข้อมูล สุดท้าย คุณจะได้เรียนรู้วิธีโปรโมตการอัปเดตในสภาพแวดล้อมการพัฒนา การทดสอบ และการผลิต ไปป์ไลน์การรวมและการปรับใช้ Git ช่วยให้สามารถผสานรวมและการปรับใช้อย่างต่อเนื่อง (CI/CD) ของการเปลี่ยนแปลงตัวแทนข้อมูล ทําให้สามารถทดสอบและเลื่อนระดับการอัปเดตโดยอัตโนมัติโดยเป็นส่วนหนึ่งของเวิร์กโฟลว์ ALM ของคุณ การควบคุมแหล่งที่มาสําหรับตัวแทนข้อมูล Fabric อยู่ในการแสดงตัวอย่าง

คุณสามารถใช้วิธีการเสริมสองวิธีเพื่อสนับสนุนตัวแทนข้อมูล ALM สําหรับ Fabric:

• การรวม Git: ซิงค์พื้นที่ทํางานทั้งหมดกับที่เก็บ Git (ไม่ว่าจะเป็น Azure DevOps หรือ GitHub ในฐานะผู้ให้บริการ Git) เพื่อเปิดใช้งานการควบคุมเวอร์ชัน การทํางานร่วมกันผ่านสาขา และการติดตามประวัติสําหรับแต่ละรายการ รวมถึงตัวแทนข้อมูล Fabric
• ไปป์ไลน์การปรับใช้: โปรโมตเนื้อหาระหว่างพื้นที่ทํางานที่แยกจากกันซึ่งแสดงถึงขั้นตอนการพัฒนา การทดสอบ และการผลิตโดยใช้ไปป์ไลน์ในตัว

ความสามารถเหล่านี้ร่วมกันให้การสนับสนุน ALM แบบ end-to-end สําหรับตัวแทนข้อมูล Fabric

ข้อกําหนดเบื้องต้น

• ความจุ Fabric แบบชําระเงิน F2 หรือสูงกว่า หรือความจุ Power BI Premium ต่อความจุ (P1 หรือสูงกว่า) ที่ เปิดใช้งาน Microsoft Fabric
• เปิดใช้งานการตั้งค่าผู้เช่าของบริษัทตัวแทนข้อมูล Fabric แล้ว
• เปิดใช้งานการประมวลผลข้ามภูมิศาสตร์สําหรับ AI
• เปิดใช้งานการจัดเก็บข้ามภูมิศาสตร์สําหรับ AI
• อย่างน้อยหนึ่งรายการที่มีข้อมูล: คลังสินค้า เลคเฮาส์ แบบจําลองความหมาย Power BI อย่างน้อยหนึ่งตัว ฐานข้อมูล KQL หรือออนโทโลยี
• แบบจําลองความหมายของ Power BI ผ่านสวิตช์ผู้เช่าตําแหน่งข้อมูล XMLA จะเปิดใช้งาน สําหรับแหล่งข้อมูลแบบจําลองความหมายของ Power BI

การรวม Git

การรวม Microsoft Fabric Git จะซิงโครไนซ์พื้นที่ทํางาน Fabric กับที่เก็บ Git ทําให้คุณสามารถใช้กระบวนการพัฒนา เครื่องมือ และแนวทางปฏิบัติที่ดีที่สุดที่มีอยู่ได้โดยตรงในแพลตฟอร์ม Fabric รองรับ Azure DevOps และ GitHub และพร้อมใช้งานที่ระดับพื้นที่ทํางาน เมื่อคุณยอมรับการเปลี่ยนแปลงจาก Fabric รวมถึงการอัปเดตการกําหนดค่าตัวแทนข้อมูล การเปลี่ยนแปลงเหล่านั้นจะถูกบันทึกเป็นไฟล์ในที่เก็บ Git ที่เชื่อมต่อ ความสามารถที่สําคัญ ได้แก่ :

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการรวม Git คุณสามารถดูแหล่งข้อมูลต่อไปนี้

• การรวม Microsoft Fabric Git คืออะไร
• แนวคิดพื้นฐานในการรวม Git
• เริ่มต้นใช้งานการรวม Git

ตั้งค่าการเชื่อมต่อกับตัวควบคุมแหล่งที่มา

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

1. ดู เริ่มต้นใช้งานการรวม Git สําหรับขั้นตอนโดยละเอียดในการเชื่อมต่อกับที่เก็บ Git ใน Azure DevOps หรือ GitHub

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

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

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

   • การเปลี่ยนการเลือก Schema
   • การอัปเดตคําแนะนํา AI หรือคําแนะนําแหล่งข้อมูล
   • การแก้ไขคิวรีตัวอย่าง
   • การเผยแพร่ตัวแทนข้อมูลหรือการอัปเดตคําอธิบายการเผยแพร่

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

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

โครงสร้างโฟลเดอร์และไฟล์ในที่เก็บ Git

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

โครงสร้างราก

ที่รูท เนื้อหาตัวแทนข้อมูลจะถูกเก็บไว้ในโฟลเดอร์ไฟล์ ภายในไฟล์ คุณจะพบโฟลเดอร์กําหนดค่า ซึ่งประกอบด้วย data_agent.json, publish_info.json, โฟลเดอร์ฉบับร่าง และโฟลเดอร์ที่เผยแพร่

ภายในโฟลเดอร์ configpublish_info.json มีคําอธิบายการเผยแพร่สําหรับตัวแทนข้อมูล ไฟล์นี้สามารถอัปเดตเพื่อเปลี่ยนคําอธิบายที่ปรากฏขึ้นเมื่อเผยแพร่ตัวแทนข้อมูล

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

• โฟลเดอร์แหล่งข้อมูล ที่มีหนึ่งโฟลเดอร์สําหรับแต่ละแหล่งข้อมูลที่ใช้โดยตัวแทนข้อมูล
  • แหล่งข้อมูลเลคเฮาส์หรือคลังสินค้า: ชื่อโฟลเดอร์ขึ้นต้นด้วย lakehouse-tables- หรือ warehouse-tables-ตามด้วยชื่อเลคเฮาส์หรือคลังสินค้า
  • แหล่งข้อมูลแบบจําลองความหมาย: ชื่อโฟลเดอร์เริ่มต้นด้วย semantic-model-ตามด้วยชื่อของแบบจําลองความหมาย
  • แหล่งข้อมูลฐานข้อมูล KQL: ชื่อโฟลเดอร์ขึ้นต้นด้วย kusto-ตามด้วยชื่อฐานข้อมูล KQL
  • แหล่งข้อมูลออนโทโลยี: ชื่อโฟลเดอร์ขึ้นต้นด้วย ontology-ตามด้วยชื่อของออนโทโลยี

• stage_config.json ที่มี aiInstructionsซึ่งหมายถึงคําแนะนําของตัวแทน

โฟลเดอร์แหล่งข้อมูลแต่ละโฟลเดอร์ประกอบด้วย datasource.json และ fewshots.json อย่างไรก็ตาม ถ้าแหล่งข้อมูลเป็นแบบจําลองความหมาย จะไม่สนับสนุนคิวรีตัวอย่าง ดังนั้นโฟลเดอร์จึงมีเพียง datasource.jsonเท่านั้น

datasource.json กําหนดการกําหนดค่าสําหรับแหล่งข้อมูลนั้น รวมถึง:

• dataSourceInstructionsซึ่งแสดงถึงคําแนะนําที่ให้ไว้สําหรับแหล่งข้อมูลนั้น

• displayNameซึ่งแสดงชื่อของแหล่งข้อมูล

• elementsซึ่งอ้างถึงแผนผัง Schema และรวมรายการตารางและคอลัมน์ทั้งหมดจากแหล่งข้อมูล

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

• อนุสัญญาประเภท:

  • ถ้าชนิดเป็นแหล่งข้อมูล ก็เป็นเพียงชนิดแหล่งข้อมูล (ตัวอย่างเช่น: "type": "lakehouse_tables")
  • ถ้าชนิดเป็นตาราง จะลงท้ายด้วย .table (ตัวอย่างเช่น: "type": "lakehouse_tables.table")
  • ถ้าชนิดเป็นคอลัมน์ จะลงท้ายด้วย .column (ตัวอย่างเช่น: "type": "lakehouse_tables.column")

fewshots.json เก็บตัวอย่างคิวรีสําหรับแหล่งข้อมูล แต่ละรายการประกอบด้วย:

• id เป็นตัวระบุเฉพาะสําหรับคิวรีตัวอย่าง
• questionซึ่งอ้างถึงคําถามภาษาธรรมชาติ
• query แสดงข้อความคิวรี ซึ่งอาจเป็น SQL หรือ KQL ขึ้นอยู่กับชนิดแหล่งข้อมูล

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

ไปป์ไลน์การปรับใช้สําหรับตัวแทนข้อมูล

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

1. พัฒนาตัวแทนข้อมูลใหม่หรืออัปเดตตัวแทนข้อมูลที่มีอยู่ในพื้นที่ทํางานการพัฒนา
2. เลื่อนระดับการเปลี่ยนแปลงในพื้นที่ทํางานทดสอบสําหรับการตรวจสอบความถูกต้อง
3. เลื่อนระดับการเปลี่ยนแปลงที่ทดสอบไปยังพื้นที่ทํางานการผลิตที่พร้อมใช้งานสําหรับผู้ใช้ปลายทาง

ก่อนปรับใช้ คุณต้องกําหนดพื้นที่ทํางานให้กับแต่ละขั้นตอนในไปป์ไลน์การปรับใช้: การพัฒนา การทดสอบ และการผลิต ถ้าคุณไม่ได้กําหนดพื้นที่ทํางานให้กับขั้นตอนการทดสอบหรือการผลิต พื้นที่ทํางานจะถูกสร้างขึ้นโดยอัตโนมัติ พื้นที่ทํางานที่สร้างขึ้นโดยอัตโนมัติจะได้รับการตั้งชื่อตามพื้นที่ทํางานการพัฒนา โดยมี [test] หรือ [prod] ต่อท้าย

วิธีปรับใช้การเปลี่ยนแปลง

• ในไปป์ไลน์ ให้ไปที่ขั้นตอนที่คุณต้องการปรับใช้ (ตัวอย่างเช่น การพัฒนา)
• เลือกรายการในพื้นที่ทํางานที่คุณต้องการปรับใช้
• เลือก ปรับใช้ เพื่อเลื่อนระดับไปยังขั้นตอนถัดไป

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

เผยแพร่ตัวแทนข้อมูล Fabric สําหรับไปป์ไลน์การปรับใช้

การเผยแพร่ตัวแทนข้อมูล Fabric ทําให้พร้อมใช้งานในช่องทางการใช้ที่แตกต่างกันทั้งหมด รวมถึง Copilot สําหรับ Power BI, Microsoft Copilot Studio และ Azure AI Foundry Services ในการประเมินและใช้ตัวแทนข้อมูลในช่องทางเหล่านี้ จะต้องเผยแพร่ตัวแทนข้อมูล ตัวแทนข้อมูลที่ไม่ได้เผยแพร่ไม่สามารถเข้าถึงได้สําหรับการใช้งาน แม้ว่าจะอยู่ในพื้นที่ทํางานการผลิตก็ตาม เพื่อปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดตามไปป์ไลน์การปรับใช้ โปรดทราบว่า:

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

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

แนวทางปฏิบัติที่ดีที่สุด

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

ข้อจํากัดและข้อควรพิจารณา

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

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

• เริ่มต้นใช้งานการรวม Git
• แนวคิดพื้นฐานในการรวม Git
• การจัดการวงจรชีวิตใน Microsoft Fabric คืออะไร