หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
ใช้แนวปฏิบัติที่ดีที่สุดเหล่านี้เพื่อกําหนดผลลัพธ์ที่สมบูรณ์ ปกป้องข้อมูลบ้านทะเลสาบ ทําให้การรันซ้ําสามารถคาดการณ์ได้ และต้องการหลักฐานความสําเร็จที่วัดได้จากงานตัวแทนวิศวกรรมข้อมูล Fabric (Project Osmos)
Important
เอเจนต์วิศวกรรมข้อมูล (Project Osmos) อยู่ในขั้นตอนพรีวิว ฟีเจอร์ตัวอย่างจะถูกปล่อยออกมาพร้อมความสามารถจํากัดและอยู่ภายใต้ เงื่อนไขการดูตัวอย่างเพิ่มเติมแยกต่างหาก ไม่ได้ออกแบบมาเพื่อใช้งานจริง ไม่ได้อยู่ภายใต้ข้อตกลงระดับการให้บริการ และอาจมีจําหน่ายเฉพาะในบางภูมิภาคเท่านั้น สําหรับข้อมูลเพิ่มเติม ให้ดูที่ Microsoft Fabric ข้อมูลตัวอย่าง
กําหนดผลลัพธ์ Project ที่สมบูรณ์
ทักษะนี้กําหนดผลลัพธ์ของ Project ดังนี้:
อธิบายงานวิศวกรรมข้อมูลแบบครบวงจร ตัวแทนวิศวกรรมข้อมูลจะได้รับข้อมูลเป็นโครงการเดียว
กําหนดผลลัพธ์ทั้งหมดแทนที่จะกําหนดเพียงขั้นตอนแรกของการนําไปใช้ รวมองค์ประกอบทั้งห้านี้ไว้ด้วย:
| องค์ประกอบ | คําถามที่ต้องตอบ | ตัวอย่าง |
|---|---|---|
| เป้าหมาย | ผลลัพธ์ที่ควรเกิดขึ้นเมื่อภารกิจเสร็จสิ้นคืออะไร? | สร้างตารางการใช้จ่ายรายเดือนของผู้จัดหา |
| แหล่ง | งานควรใช้ข้อมูลอะไรบ้าง? | อ่านไฟล์ CSV ของใบแจ้งหนี้และตาราง Suppliers Delta |
| การแปลงข้อมูล | ควรใช้กฎอะไรบ้างสําหรับงานนี้? | มาตรฐานรหัสผู้จัดหา ปฏิเสธวันที่ไม่ถูกต้อง เข้าร่วมกับผู้จัดหา และรวมค่าใช้จ่ายรายเดือน |
| ผลลัพธ์ | งานควรสร้างหรืออัปเดตอะไรบ้าง? | เขียน monthly_supplier_spend และบันทึกสมุดบันทึกการเปลี่ยนแปลง |
| การตรวจสอบความถูกต้อง | ตัวแทนวิศวกรรมข้อมูลควรพิสูจน์ความสําเร็จอย่างไร? | กระทบยอดยอดใบแจ้งหนี้ ตรวจสอบคีย์ซ้ํา และรายงานแถวที่ถูกปฏิเสธ |
ใช้เทมเพลตนี้:
<goal>. Read <sources>. Apply <transformations>.
Create or update <outputs>. Validate <success criteria>. Preserve
<important constraints>.
กําหนดขอบเขตอย่างชัดเจน
ระบุแหล่งที่มาที่เอเจนต์วิศวกรรมข้อมูลสามารถอ่านได้ ปลายทางที่สามารถเขียนไปยัง และอาร์ติแฟกต์ที่มีอยู่ที่ต้องเก็บรักษาไว้ ระบุข้อจํากัดของสคีมา การเก็บรักษา การประมวลผลระดับภูมิภาค หรือกฎทางธุรกิจที่ส่งผลต่องาน
สิทธิ์ Fabric และ OneLake ยังคงเป็นขอบเขตการอนุญาต อย่ารวมข้อมูลรับรอง โทเค็นการเข้าถึง ส่วนหัวการอนุญาต หรือข้อมูลที่ละเอียดอ่อนในผลลัพธ์ของ Project
เขียนผลลัพธ์เฉพาะของ Project
ตัวอย่างผลลัพธ์ของ Project ต่อไปนี้รวมเป้าหมาย แหล่งที่มา การแปลง ผลลัพธ์ ข้อจํากัด และเกณฑ์การตรวจสอบ
การสํารวจข้อมูล
Profile the customer_events table without modifying it.
Summarize schema, row count, date range, null rates, duplicate event IDs,
category distributions, and outliers. Save the analysis in a notebook.
การนําเข้าไฟล์
Ingest JSON files from Files/device-events. Flatten the
event payload, standardize timestamps to UTC, quarantine malformed records,
write valid rows to device_events_bronze, and report processed, accepted,
and rejected counts.
การแปลงข้อมูล
Join Orders, OrderLines, Customers, and Products. Create
a Delta table named sales_order_detail with calculated line revenue and margin.
Validate referential integrity, duplicate order-line keys, and source-to-output
revenue totals.
การแก้ไขคุณภาพข้อมูล
Assess customer_master for missing identifiers, invalid
email addresses, duplicate customers, and inconsistent country codes. Propose
a safe remediation plan, apply the approved changes to a staged table, and
produce before-and-after quality metrics.
การปรับปรุงสคีมาให้ทันสมัย
Migrate the legacy_sales table to a documented schema
with typed dates, decimal monetary values, and standardized region codes.
Preserve the source table, create a tested notebook, and reconcile record
counts and revenue totals.
การโหลดแบบเพิ่มหน่วย
Build an incremental load from Files/orders-daily into
the Orders Delta table. Deduplicate by order_id and modified_at, update changed
orders, preserve unchanged rows, save the notebook, and validate inserted,
updated, unchanged, and rejected counts.
สถาปัตยกรรมเหรียญ
Build bronze, silver, and gold layers for product,
inventory, and supplier files. Preserve raw inputs in bronze, standardize and
deduplicate entities in silver, create a gold inventory-risk table, save all
notebooks, and validate each layer.
เลือกรูปแบบการเขียนที่ปลอดภัย
เมื่อคุณสร้างงาน ให้เลือกรูปแบบการเขียนที่ตรงกับผลกระทบและความสามารถย้อนกลับของงานนั้น:
- โคลนและโปรโมท: ทดสอบการเปลี่ยนแปลงกับสําเนาก่อนย้ายผลลัพธ์ที่ได้รับการยืนยัน
- ตารางขั้นตอน: เขียนผลลัพธ์แยกต่างหากเพื่อการตรวจสอบหรือขั้นตอนการเลื่อนขั้นที่ควบคุมได้
- วนซ้ําในตําแหน่ง: แก้ไขเป้าหมายโดยตรง ใช้เฉพาะเมื่อคุณเข้าใจความเสี่ยงและแผนการฟื้นฟูเท่านั้น
- การลบ ซ้ํา:ใช้คีย์ธุรกิจที่เสถียรเพื่อป้องกันระเบียนซ้ํา
- สคีมาที่ถูกล็อก:ปฏิเสธการเปลี่ยนแปลงสคีมาที่ไม่คาดคิด
- สคีมาขยายประเภท: อนุญาตให้ขยายข้อมูลที่เข้ากันได้โดยป้องกันการเปลี่ยนแปลงโดยพลการ
สิทธิ์ Fabric ยังคงเป็นขอบเขตการอนุญาตแบบแข็ง อย่าพึ่งพาผลลัพธ์ของ Project เพียงอย่างเดียวในการปกป้องข้อมูลสําคัญ
ทําให้การออกอากาศซ้ําคาดเดาได้
บอกเอเจนต์วิศวกรรมข้อมูลว่าควรจัดการข้อมูลที่เคยประมวลผลไปก่อนหน้านี้อย่างไร ใช้คีย์ธุรกิจที่เสถียรและระบุว่าการรันซ้ําควรล้มเหลว เพิ่มข้อมูลใหม่ กําจัดข้อมูลซ้ํา รวมการเปลี่ยนแปลง หรือแทนที่เป้าหมาย
สําหรับงานแบบเพิ่มทีละน้อย ให้สอบถามจํานวนระเบียนที่แทรก อัปเดต ไม่เปลี่ยนแปลง และถูกปฏิเสธ เก็บรักษาข้อมูลต้นทางและผลลัพธ์ที่ได้รับการยืนยัน เว้นแต่การแทนที่จะเป็นส่วนหนึ่งที่ชัดเจนของผลลัพธ์ที่ร้องขอ