หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
Microsoft Fabric Dataflow Gen2 มีวิธีการหลายวิธีในการนําเข้า แปลง และโหลดข้อมูลอย่างมีประสิทธิภาพ วิธีการเหล่านี้ช่วยให้คุณสร้างสมดุลระหว่างประสิทธิภาพความสามารถในการปรับขนาด และต้นทุน
บทความนี้เป็นข้อมูลอ้างอิงด้านประสิทธิภาพและต้นทุนสําหรับ Dataflow Gen2 มันจะประเมินประสิทธิภาพงานทั่วไปสี่ประเภท ได้แก่ การคัดลอกจํานวนมาก, การจัดรูปแบบข้อมูลหนัก, การเขียนข้อมูลไปยังบ้านพักทะเลสาบอย่างเหมาะสม และการรวมไฟล์ที่แบ่งพาร์ติชันเข้าด้วยกัน พร้อมรายงานเวลารันและหน่วยความจุ (CUs) ที่แต่ละชิ้นใช้ไป วัดจากข้อมูลเทเลเมทรีความจุ ใช้มันเพื่อประมาณค่าใช้จ่ายในการรีเฟรชของคุณเอง และเลือกความสามารถที่เหมาะสมกับแต่ละงาน
ในระดับสเกล Dataflow Gen2 มีประสิทธิภาพเหนือกว่า Dataflow Gen1 อย่างมากทั้งในด้านความเร็วและต้นทุน และยิ่งภาระงานมากเท่าไร ช่องว่างก็ยิ่งกว้างขึ้น เมื่อรันสคริปต์ M เดียวกัน กับข้อมูลเดียวกัน และความจุ Fabric เดียวกัน Dataflow Gen2 สามารถทําการทดสอบประสิทธิภาพทุกครั้งในบทความนี้ได้เร็วกว่ามาตรฐาน Dataflow Gen1 อยู่ 1.7× ถึง 21× ในทุกสถานการณ์ที่มีการวัดการใช้ความจุของทั้งสองเจเนอเรชัน Dataflow Gen2 ทํางานได้เร็วขึ้นโดยใช้หน่วยความจุ น้อยลง 82% ถึง 95% — ดังนั้นการเร่งความเร็วจึงไม่แลกมาด้วยความจุที่เพิ่มขึ้น คุณจะได้ประโยชน์ทั้งสองอย่างพร้อมกันโดยไม่ต้องเขียนคําค้นหาใหม่แม้แต่ตัวเดียว
จํานวนที่คุณจะได้รับขึ้นอยู่กับปริมาณงานของคุณ และปัจจัยสําคัญที่สุดคือระยะเวลาที่คําค้นหาของคุณจะรันนานแค่ไหน Standard Compute คิดค่าบริการ 10 นาทีแรกของแต่ละคําสั่งที่ 12 CU ต่อทุกวินาที จากนั้นคิดค่าบริการเพียง 1.5 CU ต่อทุกวินาทีเพิ่มเติม ดังนั้นยิ่งคําสั่งรันนานขึ้น ต้นทุนเฉลี่ยต่อวินาทีก็จะยิ่งต่ําลง การไหลของข้อมูลสั้น ๆ จะจบลงในชั้นแรกและไม่เคยถึงอัตราที่ถูกกว่า ดังนั้นความแตกต่างระหว่างสองเจเนอเรชันจึงน้อยมาก ผลประโยชน์จะเพิ่มขึ้นตามปริมาณข้อมูลและเวลาทํางาน ซึ่งเป็นเหตุผลที่การทดสอบประสิทธิภาพในบทความนี้ใช้ชุดข้อมูลขนาดใหญ่ที่มีปริมาณมาก และการรีเฟรชข้อมูลที่ยาวนาน
Dataflow Gen2 ก็ยังคงถูกลงอย่างต่อเนื่องในแบบของตัวเอง: ราคาปัจจุบันและความสามารถปัจจุบันช่วยลดการใช้ CU ประมาณ 14% ถึง 84%ขึ้นอยู่กับปริมาณงาน เมื่อเทียบกับปริมาณงานเดียวกันก่อนปี 2026
หมายเหตุ
ตลอดบทความนี้ ต้นทุนและกําลังการผลิตจะถูกวัดเป็นหน่วยความจุ Fabric (CUs) สําหรับวิธีที่ Dataflow Gen2 ใช้ CU และวิธีที่มันสอดคล้องกับการเรียกเก็บเงิน ดูที่ Dataflow Gen2 pricing เกณฑ์มาตรฐานและตัวเลข CU เหล่านี้สะท้อนถึงโมเดลการตั้งราคาและความสามารถปัจจุบันของ Dataflow Gen2 รวมถึงการตั้งราคา Standard Compute แบบแบ่งชั้น, Fast Copy และ Modern Evaluator เนื่องจากประสิทธิภาพและต้นทุนของ Dataflow Gen2 ดีขึ้นตามเวลา ตัวเลขที่เผยแพร่ก่อนปี 2026 อาจไม่สะท้อนพฤติกรรมปัจจุบัน
ความสามารถต่อไปนี้ช่วยคุณปรับกระแสข้อมูลของคุณให้เหมาะสม:
- Fast Copy – เร่งการเคลื่อนย้ายข้อมูลจํานวนมากก่อนการแปลง
- Modern Evaluator – เร่งการสร้างข้อมูลจํานวนมากในแบบสอบถามที่ไม่สามารถพับได้
- การสืบค้นการจัดเตรียม – เชื่อมโยงข้อมูลในเลเยอร์กลางก่อนที่จะใช้การแปลง ซึ่งเปิดใช้งานรูปแบบ ELT
- การคัดลอกไปยัง Lakehouse ที่ปรับแต่งให้เหมาะสม – เร่งความเร็วในการเขียนข้อมูลแบบ staged ไปยังปลายทาง lakehouse ในงาน ELT
- Partitioned Compute (พรีวิว) – การแปลงขนาดระหว่างชุดข้อมูลขนาดใหญ่และชุดข้อมูลที่แบ่งพาร์ติชัน
บทความนี้ครอบคลุมกรณีการใช้งานทั่วไป ตัวอย่างในโลกจริง และผลการเปรียบเทียบมาตรฐาน เพื่อช่วยให้คุณเลือกความสามารถที่เหมาะสมกับภาระงานของคุณ
Dataflow Gen2 จะเรียกเก็บเงินแต่ละเอนจินแยกกัน ตามอัตราปัจจุบันดังนี้:
- Standard Compute (คําสั่ง mashup engine) - 12 CU สําหรับทุกวินาทีถึง 10 นาทีของแต่ละคําสั่ง จากนั้น 1.5 CU สําหรับทุกวินาทีที่เพิ่มขึ้น
- Fast Copy (การเคลื่อนย้ายข้อมูล) - 1.5 CU สําหรับทุกวินาทีของกิจกรรมการคัดลอก วัดจากทุกคอร์ที่ใช้
สําหรับโมเดลอัตราทั้งหมด ดูที่ราคาของ Dataflow Gen2
การอ้างอิงด่วน
จับคู่ปริมาณงานของคุณกับความสามารถ Dataflow Gen2 ที่เหมาะสม สําหรับตัวอย่างเกณฑ์มาตรฐานของแต่ละรายการ โปรดดูสถานการณ์ที่เชื่อมโยง
| ความสามารถ | ใช้เมื่อ... | ประโยชน์หลัก | เกณฑ์มาตรฐาน |
|---|---|---|---|
| คัดลอกอย่างรวดเร็ว | คุณต้องมีสําเนาโดยตรงที่มีปริมาณงานสูงจากแหล่งที่มาที่รองรับโดยไม่มีการแปลง | นําเข้าได้เร็วขึ้นด้วยต้นทุนการประมวลผลที่ต่ําลง | สถานการณ์สมมติที่ 1: คัดลอกข้อมูล |
| ผู้ประเมินที่ทันสมัย | คุณกําลังสร้างรูปร่างข้อมูลจากตัวเชื่อมต่อที่ไม่สามารถพับได้หรือพับได้บางส่วน (ตัวกรอง การสืบทอด การทําความสะอาด) | การดําเนินการที่เร็วขึ้นโดยไม่ต้องเปลี่ยนตรรกะ | สถานการณ์ที่ 2: การสร้างข้อมูลจํานวนมาก |
| คัดลอกที่ปรับแต่งไปยัง Lakehouse | คุณเปิดใช้งานการ staging บนคําสั่งค้นหาที่เขียนไปยังปลายทาง lakehouse | เพิ่มอัตราการส่งข้อมูลสูงสุดเมื่อเขียนข้อมูลแบบ staged ไปยัง lakehouse | สถานการณ์ที่ 3: คัดลอกไปยัง Lakehouse ที่ปรับแต่งให้เหมาะสม |
| การประมวลผลแบบแบ่งพาร์ติชัน (ตัวอย่าง) | คุณกําลังแปลงชุดข้อมูลขนาดใหญ่ แบ่งพาร์ติชัน หรือหลายไฟล์ที่สามารถทํางานแบบขนานได้ ใช้ร่วมกับ Modern Evaluator เมื่อรองรับ | การดําเนินการแบบขนานข้ามพาร์ติชัน | สถานการณ์ที่ 4: รวมไฟล์ |
หมายเหตุ
สําหรับข้อมูลเบื้องหลังเกี่ยวกับการประเมินคิวรีและการพับคิวรี โปรดดู พื้นฐานการพับคิวรี
สรุปผลเกณฑ์มาตรฐาน
สถานการณ์ส่วนใหญ่ในบทความนี้ใช้ชุดข้อมูลการเดินทางของ New York City Taxi & Limousine Commission (TLC) – ชุดข้อมูลบันทึกการเดินทาง TLC : บันทึกการเดินทางแท็กซี่นับพันล้านรายการที่เก็บเป็นไฟล์ Parquet ใน ADLS Gen2 ครอบคลุมปี 2021–2025 (จนถึงเดือนสิงหาคม) สถานการณ์ที่ 3 ใช้ตาราง Fabric lakehouse ที่มีบันทึกการเดินทางแท็กซี่ในนิวยอร์กประมาณ 113 ล้านรายการ ครอบคลุมตั้งแต่ปี 2017 ถึงกลางปี 2018 ปลายทางคือเลคเฮาส์หรือคลังสินค้าของ Fabric ขึ้นอยู่กับสถานการณ์
ตารางต่อไปนี้สรุปผลลัพธ์การเปรียบเทียบในทุกสถานการณ์ แต่ละสถานการณ์ยังมีพื้นฐานของกระแสข้อมูล Gen1 สําหรับการเปรียบเทียบ
| สถานการณ์สมมติ | การทำงานของมัน | เปิดใช้งานความสามารถ | เวลาดําเนินการ Gen2 | เร่งความเร็วเทียบกับพื้นฐาน Gen1 | Gen1 CU | Gen2 CU | การลด CU บน Gen2 |
|---|---|---|---|---|---|---|---|
| สถานการณ์สมมติที่ 1: คัดลอกข้อมูล | โหลดไฟล์ Parquet รวม 5 ไฟล์จาก ADLS Gen2 ลงในบ้านริมทะเลสาบโดยไม่ต้องแปลงไฟล์ | คัดลอกอย่างรวดเร็ว | 00:09:08 | เร็วขึ้น 11× | 84,411 | 14,593 | 83% |
| สถานการณ์ที่ 2: การสร้างข้อมูลจํานวนมาก | ใช้การแปลงที่ไม่สามารถพับได้ (ฟิลเตอร์ อนุพันธ์ การทําความสะอาด) กับไฟล์ Parquet ขนาดใหญ่ไฟล์เดียวที่โหลดลงในเลคเฮาส์ | ผู้ประเมินที่ทันสมัย | 00:46:29 | เร็วขึ้น 1.7× | 56,855 | 10,485 | 82% |
| สถานการณ์ที่ 3: คัดลอกไปยัง Lakehouse ที่ปรับแต่งให้เหมาะสม | เปลี่ยนโต๊ะแท็กซี่ NYC ที่มีแถว 113 ล้านแถวจากบ้านริมทะเลสาบ Fabric แล้วเขียนผลลัพธ์เป็นโต๊ะบ้านพักริมทะเลสาบบนเส้นทางคัดลอกที่เร่งความเร็ว การทดสอบนี้ใช้การคัดลอกที่ปรับแต่งแล้วไปยัง Lakehouse และ V-Order | คัดลอกที่ปรับแต่งไปยัง Lakehouse | 00:03:34 | เร็วขึ้น 15× | 50,788 | 2,391 | 95% |
| สถานการณ์ที่ 4: รวมไฟล์ | รวมและแปลงไฟล์ Parquet ที่แบ่งพาร์ติชัน 56 ไฟล์แบบขนานและโหลดลงในคลังสินค้า | การประมวลผลแบบแบ่งพาร์ติชัน (ตัวอย่าง) | 00:04:48 | เร็วขึ้น 21× | ไม่ได้วัด | ไม่ได้วัด | ไม่ได้วัด |
แผนภูมิต่อไปนี้เปรียบเทียบสถานการณ์เดียวกันโดยวัดการใช้ความจุแทนเวลาการดําเนินการ
สําหรับรายละเอียดทีละขั้นตอน การกําหนดค่าชุดข้อมูล และรูปแบบการออกแบบสําหรับแต่ละความสามารถ โปรดดูส่วนสถานการณ์ที่ตามมา
หมายเหตุ
ทุกสถานการณ์ในบทความนี้เปิดใช้งาน Modern Evaluator และปิดใช้งาน V-Order เว้นแต่จะระบุไว้เป็นอย่างอื่น คอลัมน์ Gen1 CU และ Gen2 CU รายงานหน่วยความจุเป็นวินาที การ ลด CU บนคอลัมน์ Gen2 คือการลดลงเป็นวินาที CU จากค่าพื้นฐาน Dataflow Gen1 ไปยังการกําหนดค่า Dataflow Gen2 ที่ดีที่สุด ซึ่งคํานวณเป็น (Gen1 CU − Gen2 CU) ÷ Gen1 CU
วิธีที่เราวัดเกณฑ์เหล่านี้
แต่ละสถานการณ์จะรันสคริปต์ M เดียวกันสองครั้ง: ครั้งแรกบน Dataflow Gen1 เพื่อสร้าง baseline และอีกครั้งบน Dataflow Gen2 เมื่อเปิดใช้งานความสามารถที่ทดสอบ
ทุกการรันในบทความนี้มีเงื่อนไขการทดสอบเดียวกัน:
- ทุกสถานการณ์และทั้งสองเจเนอเรชันใช้ความจุ Fabric เดียวกัน ดังนั้นผลลัพธ์จึงไม่สะท้อนขนาดความจุหรือ SKU ที่แตกต่างกัน
- ไม่มีเกตเวย์ข้อมูล เข้ามาเกี่ยวข้อง ทุกการเชื่อมต่อจะส่งตรงจากบริการ Fabric ไปยังแหล่งข้อมูลคลาวด์
- แต่ละสถานการณ์ใช้ข้อมูลต้นทางเดียวกันและสคริปต์ M เดียวกันสําหรับทั้งรัน Dataflow Gen1 และ Dataflow Gen2
ตัวเลขที่รายงานมีดังนี้:
- เวลารันคือ ระยะเวลารีเฟรชทั้งหมดที่รายงานสําหรับการรันข้อมูลโฟลว์
- CU ที่ใช้คือหน่วยความจุที่รันเรียกเก็บเงินจากความจุนั้น อ่านจากแอป Microsoft Fabric Capacity Metrics เนื่องจาก Dataflow Gen2 จะคิดค่าบริการแต่ละเอนจินแยกกัน ผลรวมของแต่ละสถานการณ์คือผลรวมของทุกเอนจินที่ทํางานระหว่างการรีเฟรช และตัวเลข CU จะถูกปัดเศษเป็นวินาทีเต็มของ CU ที่ใกล้ที่สุด สําหรับโมเดลอัตราทั้งหมด ดูที่ราคาของ Dataflow Gen2
เมื่อคุณเปรียบเทียบสองเจเนอเรชันนี้ โปรดคํานึงถึงความแตกต่างทางสถาปัตยกรรมเหล่านี้:
- Dataflow Gen1 ใช้สถาปัตยกรรมที่แตกต่างจาก Dataflow Gen2 อย่างสิ้นเชิง และไม่รองรับฟีเจอร์อย่าง Fast Copy, Modern Evaluator, Optimized copy to Lakehouse หรือ Partitioned Compute
- Dataflow Gen1 สามารถโหลดข้อมูลได้เฉพาะในรูปแบบไฟล์ CSV เท่านั้น ในขณะที่ Dataflow Gen2 โหลดข้อมูลเป็นไฟล์ Parquet ในสถานการณ์เหล่านี้
หมายเหตุ
ตัวเลขเหล่านี้ถูกบันทึกในสภาพแวดล้อมทดสอบของเราเองในเดือนสิงหาคม 2026 และใช้ได้เฉพาะกับการวิ่งเหล่านี้เท่านั้น ผลลัพธ์ของคุณเองจะแตกต่างกันไปตามปริมาณข้อมูล ขนาดความจุ และการตั้งค่า หากต้องการวัดปริมาณงานของคุณเอง ดูที่ คํานวณต้นทุนโดยประมาณโดยใช้แอป Fabric Metrics และประวัติการรีเฟรชข้อมูล.
สถานการณ์สมมติที่ 1: คัดลอกข้อมูล
ทีมวิเคราะห์แท็กซี่นิวยอร์กต้องโหลดบันทึกการเดินทาง Parquet ดิบจาก ADLS Gen2 หลายล้านรายการลงในบ้านพักริมทะเลสาบของ Fabric ทีมงานไม่ต้องการการเปลี่ยนแปลงใดๆ มีเพียงสําเนาโดยตรงเพื่อรองรับการวิเคราะห์ดาวน์สตรีม
ชาเลนจ์
- ย้ายข้อมูล Parquet จํานวนมากเข้าสู่บ้านพักริมทะเลสาบได้อย่างรวดเร็ว
- ลดเวลาในการนําเข้าสําหรับการรีเฟรชรายวัน
- ลดต้นทุนการประมวลผลสําหรับปริมาณงานการแยกข้อมูล (EL) อย่างง่าย
ชุดข้อมูล
ปีที่ชาญฉลาดรวมไฟล์ NYC Yellow Taxi Parquet ห้าพาร์ติชันรวม (2021–ส.ค. 2025)
โซลูชัน
ทีมงานเปิดใช้งาน Fast Copy ใน Dataflow Gen2 Fast Copy ปรับเส้นทางการเคลื่อนย้ายข้อมูลให้เหมาะสมและเขียนแบบขนานสําหรับตัวเชื่อมต่อที่รองรับ
การออกแบบ
แบบสอบถามนี้รวมไฟล์ Parquet ห้าปีและโหลดผลลัพธ์ลงในเลคเฮาส์
ข้อควรพิจารณาเกี่ยวกับการคัดลอกอย่างรวดเร็ว
- รองรับรูปแบบไฟล์ .csv และ .parquet
- รองรับแถวสูงสุด 1M ต่อตารางต่อการเรียกใช้ สําหรับ Azure SQL Database
- เหมาะสําหรับเวิร์กโฟลว์การ ดึง-โหลด (EL) ก่อนการแปลง
ผลลัพธ์
เมื่อคุณเปิดใช้งาน Fast Copy, Dataflow Gen2 จะนําเข้าข้อมูลชุดนี้ เร็วกว่าค่าพื้นฐานของ Dataflow Gen1 ประมาณ 11× (00:09:08 เทียบกับ 01:38:59) พร้อมกับลดการใช้งานการประมวลผล ถ้าไม่มี Fast Copy, Dataflow Gen2 ก็เร็วกว่า Gen1 ประมาณ 2.8× เท่าในงานเดียวกัน
| การกําหนดค่า | เวลาดําเนินการ (hh:mm:ss) | เปรียบเทียบกับ Gen1 | CU ถูกใช้หมด |
|---|---|---|---|
| พื้นฐานของกระแสข้อมูล Gen1 | 01:38:59 | — | 84,411 |
| กระแสข้อมูล Gen2 โดยไม่ต้องคัดลอกอย่างรวดเร็ว | 00:35:25 | เร็วขึ้น 2.8× | ไม่ได้วัด |
| กระแสข้อมูล Gen2 พร้อมการคัดลอกอย่างรวดเร็ว | 00:09:08 | เร็วขึ้น 11× | 14,593 |
เมื่อคุณเปิดใช้งาน Fast Copy - การตั้งค่า Dataflow Gen2 ที่เหมาะสมที่สุดสําหรับสถานการณ์นี้ - การนําเข้าไฟล์ Parquet รวม 5 ไฟล์เข้าสู่บ้านพักทะเลสาบของ Fast Copy ในสถานการณ์ที่ 1 จะใช้เวลา 14,593 CU วินาที ตารางต่อไปนี้แบ่งยอดรวมตามการดําเนินการ:
| การดำเนินการ | เครื่องยนต์ (เมตร) | วินาที CU |
|---|---|---|
| การเคลื่อนไหวของข้อมูล | คัดลอกอย่างรวดเร็ว | 8,280 |
| เรียกใช้คิวรี | การคํานวณมาตรฐาน | 6,313 |
| ผลรวม | 14,593 |
การเคลื่อนย้ายข้อมูลแบบ Fast Copy จะคิดค่าบริการที่อัตรา 1.5 CU ต่อทุกวินาทีของกิจกรรมการคัดลอก ซึ่งวัดเป็นเวลารวมของคอร์ทั้งหมดที่การคัดลอกทํางานอยู่ Dataflow Gen2 จะปรับสมดุลจํานวนคอร์ที่ใช้ในแต่ละสถานการณ์ Fast Copy โดยอัตโนมัติ ดังนั้นสําเนาที่เสร็จเร็วในเวลา wall-clock ก็ยังสามารถครอบคลุมหลายคอร์-วินาทีได้ เวลาการสืบค้นที่เหลือจะถูกคิดค่าบริการบน Standard Compute (12 CU สําหรับทุกวินาทีถึง 10 นาที จากนั้น 1.5 CU สําหรับทุกวินาทีที่เพิ่มขึ้น) สําหรับโมเดลอัตราเต็ม ดูที่ราคาของ Dataflow Gen2
ประเด็นสําคัญ
- การเปิดใช้งาน Fast Copy ย่อการนําเข้าข้อมูลที่ใช้เวลา 99 นาทีให้เหลือเวลาประมาณเก้านาที ซึ่งเป็นการพัฒนาที่ดีกว่าชุดข้อมูลเดียวกันและสคริปต์ M หลายเท่า
- Dataflow Gen2 ยังใช้ความจุน้อยกว่า Dataflow Gen1 ถึง 83% สําหรับงานเดียวกัน (14,593 เทียบกับ 84,411 CU วินาที) ดังนั้นการเพิ่มความเร็วจึงไม่แลกมาด้วยการประมวลผลที่เพิ่มขึ้น
- การเร่งความเร็วนี้มาจากการเคลื่อนย้ายข้อมูลแบบขนานแบบเนทีฟที่ข้ามเอนจิน mashup ดังนั้นจึงใช้ได้เฉพาะกับขั้นตอนการดึงข้อมูลที่ตรงตาม ข้อกําหนดของ Fast Copy เท่านั้น การเปลี่ยนแปลงใด ๆ ที่ทําลายการพับจะกลับไปใช้เครื่องยนต์มาตรฐานและริบกําไร
- สําหรับแหล่งข้อมูลที่รองรับ ให้ถือว่า Fast Copy เป็นค่าเริ่มต้นสําหรับการนําเข้าและสํารองกลไกจัดการการแปลงที่หนักกว่า (ครอบคลุมในสถานการณ์ถัดไป) สําหรับขั้นตอนที่ปรับรูปร่างข้อมูลจริง
สถานการณ์ที่ 2: การสร้างข้อมูลจํานวนมาก
หลังจากการนําเข้าข้อมูล ทีมงานจะใช้การกรอง การแทนที่ศูนย์ และการแมปโค้ดก่อนโหลดข้อมูลเข้าสู่ lakehouse การเปลี่ยนแปลงเหล่านี้ไม่ได้พับกลับไปที่ Parquet อย่างเต็มที่และหน่วยความจําช้า
ชาเลนจ์
- ปรับปรุงความเร็วในการแปลงสําหรับคิวรีแบบกึ่งพับได้หรือไม่สามารถพับได้
- รักษาการเขียน Power Query แบบไม่ใช้โค้ด
- ลดเวลาและค่าใช้จ่ายในการรีเฟรชโดยรวม
ชุดข้อมูล
ไฟล์ Parquet ทั้งหมดสําหรับปี 2021–สิงหาคม 2025 ถูกรวมเป็นไฟล์รวมเดียว
โซลูชัน
ทีมงานเปิดใช้งาน Modern Evaluator ซึ่งเป็นกลไกการดําเนินการประสิทธิภาพสูงที่ออกแบบมาเพื่อการเปลี่ยนแปลงที่มีประสิทธิภาพ โดยเฉพาะอย่างยิ่งสําหรับตัวเชื่อมต่อ เช่น ADLS Gen2 และ SharePoint
การออกแบบ
คิวรีนี้จะนําเข้าข้อมูลจากไฟล์ Parquet ที่รวม กรอง trip_distance คอลัมน์ และ fare_amount เพื่อรักษาค่าที่สูงกว่า 0 แทนที่ null ด้วย passenger_count 1 และสร้างคอลัมน์ใหม่ payment_method โดยการแมปชนิดการชําระเงินก่อนที่จะโหลดข้อมูลลงในเลคเฮาส์
ข้อควรพิจารณาเกี่ยวกับ Modern Evaluator
- เวลารีเฟรชที่คาดไว้อาจ เร็วขึ้นอย่างมาก (แตกต่างกันไปตามชุดข้อมูลและการแปลง)
- ปรับให้เหมาะสมสําหรับปริมาณมาก (ล้านแถว)
- มีประโยชน์สําหรับคําถามที่ไม่สามารถพับได้
- เขียนงานไปยังจุดหมายปลายทางที่เร็วขึ้น เช่น บ้านพักริมทะเลสาบ
ผลลัพธ์
เมื่อคุณเปิดใช้งาน Modern Evaluator Dataflow Gen2 จะรันงาน shaping นี้เร็วกว่ามาตรฐาน Dataflow Gen1 ประมาณ 1.7× (00:46:29 เทียบกับ 01:19:56) ในขณะที่ยังคงรักษาประสบการณ์ no-code Power Query ไว้ ถ้าไม่มี Modern Evaluator ภาระงานเท่ากันจะเร็วกว่า Gen1 ประมาณ 1.2× (01:08:37 เทียบกับ 01:19:56)
| การกําหนดค่า | เวลาดําเนินการ (hh:mm:ss) | เปรียบเทียบกับ Gen1 | CU ถูกใช้หมด |
|---|---|---|---|
| พื้นฐานของกระแสข้อมูล Gen1 | 01:19:56 | — | 56,855 |
| กระแสข้อมูล Gen2 ที่ไม่มี Modern Evaluator | 01:08:37 | เร็วขึ้น 1.2× | ไม่ได้วัด |
| กระแสข้อมูล Gen2 พร้อม Modern Evaluator | 00:46:29 | เร็วขึ้น 1.7× | 10,485 |
เมื่อคุณเปิดใช้งาน Modern Evaluator - การตั้งค่า Dataflow Gen2 ที่เหมาะสมที่สุดสําหรับสถานการณ์นี้ - Scenario 2 การปรับแต่งไฟล์ Parquet ขนาดใหญ่เพียงไฟล์เดียวให้กลายเป็นบ้านริมทะเลสาบ จะใช้เวลา 10,485 CU วินาที ตารางต่อไปนี้แบ่งยอดรวมตามการดําเนินการ:
| การดำเนินการ | เครื่องยนต์ (เมตร) | วินาที CU |
|---|---|---|
| เรียกใช้คิวรี | การคํานวณมาตรฐาน | 10,485 |
| ผลรวม | 10,485 |
งานทั้งหมดทํางานบน Standard Compute ซึ่งคิดค่าบริการเป็นสองระดับ: 12 CU สําหรับทุกวินาทีจนถึง 10 นาที และ 1.5 CU สําหรับทุกวินาทีที่เพิ่มขึ้น ตารางต่อไปนี้แสดงวิธีการแบ่งระยะเวลาที่เรียกเก็บเงินและยอดรวม CU ในแต่ละระดับ:
| ระดับการเรียกเก็บเงิน | ระยะเวลาที่คิดค่าบริการ | อัตรา | วินาที CU |
|---|---|---|---|
| 10 นาทีแรก | 00:10:00 (600 วินาที) | 12 CU ต่อทุกวินาที | 7,200 |
| เกิน 10 นาที | 00:36:29 (2,189.8 วินาที) | 1.5 CU ต่อทุกวินาที | 3,284.7 |
| ผลรวม | 00:46:29 (2,789.8 วินาที) | 10,484.7 |
ตารางนี้แสดงผลรวมที่วัดได้เป็นทศนิยมหนึ่งตําแหน่ง ดังนั้นระดับต่าง ๆ จะรวมกันอย่างแม่นยํา; ส่วนที่เหลือของบทความปัดเศษเป็น 10,485 CU วินาที
การแบ่งเวลาแสดงให้เห็นว่าระดับแรกครองรายการมากแค่ไหน: 10 นาทีแรกมีเพียงประมาณ 22% ของการแสดง แต่คิดเป็นประมาณ 69% ของวินาที CU เพราะแต่ละวินาทีนั้นมีค่าใช้จ่ายมากกว่าวินาทีในระดับที่สองถึงแปดเท่า ทุกอย่างที่เกิน 10 นาที — ซึ่งเป็นส่วนใหญ่ของช่วงเวลาการปั้นยาว — จะถูกคิดค่าเฉลี่ยต่ํากว่า 1.5 CU Modern Evaluator ลดค่าใช้จ่ายลงอีกโดยการลดระยะเวลาการเรียกเก็บเงินเอง ไม่ใช่การเปลี่ยนอัตราค่าจ้าง สําหรับโมเดลอัตราเต็ม ดูที่ราคาของ Dataflow Gen2
ประเด็นสําคัญ
- หากไม่มี Modern Evaluator Dataflow Gen2 จะเร็วกว่าค่าพื้นฐานของ Dataflow Gen1 ในงาน shaping นี้เพียงประมาณ 1.2× เท่า การเปิดใช้งาน Modern Evaluator ช่วยเพิ่มประสิทธิภาพให้เร็วขึ้นประมาณ 1.7× เท่า Gen1 บนสคริปต์และชุดข้อมูล M ที่เหมือนกัน
- การประหยัดความจุมากกว่าการประหยัดเวลา: Dataflow Gen2 ทํางานเสร็จเร็วกว่า 1.7× ขณะใช้ความจุน้อยกว่า Dataflow Gen1 ถึง 82% (10,485 วินาที เทียบกับ 56,855 CU วินาที)
- ประสิทธิภาพที่เพิ่มขึ้นนี้มาจากเส้นทางการประมวลผลที่มีประสิทธิภาพมากขึ้นสําหรับคําสั่งที่ไม่สามารถพับได้และกึ่งพับได้ Power Query โดยปกติจะใช้เวลาส่วนใหญ่กับการค้นหาเหล่านี้ โดยเฉพาะเมื่อใช้ตัวเชื่อมต่ออย่าง ADLS Gen2 และ SharePoint เพิ่มสเกลด้วยปริมาตรของแถวและความซับซ้อนของรูปร่าง
- ใช้ Modern Evaluator เป็นค่าเริ่มต้นสําหรับโฟลว์ที่ต้องการการปรับแต่งเนื้อหา ซึ่งคําค้นไม่สามารถพับกลับไปยังแหล่งที่มาได้อย่างสมบูรณ์ ยิ่งชุดข้อมูลใหญ่ขึ้นและคุณใช้การแปลงในเอนจินมากเท่าไร คุณก็ควรคาดหวังผลกระทบมากขึ้นเท่านั้น
สถานการณ์ที่ 3: คัดลอกไปยัง Lakehouse ที่ปรับแต่งให้เหมาะสม
ทีมวิเคราะห์แท็กซี่นิวยอร์กจะเปลี่ยนตารางขนาดใหญ่และเขียนผลลัพธ์เป็นบ้านริมทะเลสาบ Fabric การเขียนโวลุ่มนั้นไปยังปลายทางเป็นส่วนที่ช้าที่สุดของการรีเฟรช ดังนั้นทีมงานจึงต้องการเร่งการเขียนโดยไม่เปลี่ยนตรรกะการแปลง
ชาเลนจ์
- เขียนผลลัพธ์แปลงขนาดใหญ่เป็นจุดหมายปลายทางของบ้านริมทะเลสาบได้อย่างรวดเร็ว
- ป้องกันไม่ให้การเขียนปลายทางกลายเป็นคอขวดในการรีเฟรช
- รักษาประสบการณ์ Power Query แบบไม่ต้องเขียนโค้ดและตรรกะการแปลงที่มีอยู่
ชุดข้อมูล
โต๊ะ Fabric lakehouse ที่มีบันทึกทริปแท็กซี่ในนิวยอร์กซิตี้ประมาณ 113 ล้านรายการ ตั้งแต่ปี 2017 ถึงกลางปี 2018
โซลูชัน
ทีมงานจะเปิดใช้งาน การเปิดใช้งานการจัดเตรียมและ เปิดใช้งาน การคัดลอกที่ปรับแต่งไปยัง Lakehouse ในคําสั่งเดียวที่เขียนไปยังปลายทางของ lakehouse การคัดลอกที่ปรับแต่งไปยัง Lakehouse จะย้ายผลลัพธ์ที่จัดฉากไปยัง lakehouse ในเส้นทางที่เร่งความเร็วขึ้น
การออกแบบ
dataflow แบบทดสอบจะใช้คําสั่งเดียวที่เปิดใช้งาน Enable staging และปลายทาง lakehouse ที่ใช้ V-Order คําค้นหานี้จะอ่านตารางแท็กซี่ NYC ที่มีแถวประมาณ 113 ล้านแถวจากบ้านริมทะเลสาบ Fabric จัดเรียงแถวตามวันที่และเวลารับ และเพิ่มคอลัมน์อนุพันธ์สองคอลัมน์ คือ เริ่มต้นเดือนรับ และยอดรวมของภาษีและค่าธรรมเนียมปรับปรุงของ MTA เนื่องจากเปิดใช้งานการจัดเตรียม การคัดลอกที่ปรับแต่งไปยัง Lakehouse จะเขียนผลลัพธ์ที่แปลงแล้วไปยังปลายทางของ lakehouse บนเส้นทางที่เร่งความเร็ว ซึ่งช่วยเร่งเวลาการทํางาน
ข้อควรพิจารณาในการคัดลอกไปยัง Lakehouse อย่างเหมาะสม
- ต้อง เปิดใช้งานการตั้งระยะ บนคําค้นหาและจุดหมายปลายทางของบ้านริมทะเลสาบ สําหรับข้อมูลเพิ่มเติม โปรดดู ตัวเลือกข้อมูลที่เป็นระยะสําหรับกระแสข้อมูล Gen2
- มันเร่งการเขียนไปยัง lakehouse โดยไม่เปลี่ยนตรรกะการแปลง
- รวมกับ V-Order บนปลายทางเพื่อเพิ่มประสิทธิภาพผลลัพธ์สําหรับการวิเคราะห์ในขั้นตอนถัดไป
ผลลัพธ์
เมื่อคุณเปิดใช้งาน Optimized copy to Lakehouse Dataflow Gen2 จะรีเฟรชนี้ เร็วกว่าค่าพื้นฐานของ Dataflow Gen1 ประมาณ 15× (00:03:34 เทียบกับ 00:53:20) โดยไม่เปลี่ยนแปลงตรรกะการแปลง ถ้าไม่มี Phased Dataflow เดียวกันจะเร็วกว่า Gen1 ประมาณ 3.6×
| การกําหนดค่า | เวลาดําเนินการ (hh:mm:ss) | เปรียบเทียบกับ Gen1 | CU ถูกใช้หมด |
|---|---|---|---|
| พื้นฐานของกระแสข้อมูล Gen1 | 00:53:20 | — | 50,788 |
| Dataflow Gen2 พร้อม staging + V-Order (ไม่มีการคัดลอก Optimized ไปยัง Lakehouse) | 00:14:45 | เร็วขึ้น 3.6× | ไม่ได้วัด |
| Dataflow Gen2 พร้อมการจัดเตรียม + คัดลอกไปยัง Lakehouse ที่ปรับแต่งให้เหมาะสม + V-Order | 00:03:34 | เร็วขึ้น 15× | 2,391 |
เมื่อคุณเปิดใช้งานการจัดเตรียม, การคัดลอกที่ปรับแต่งไปยัง Lakehouse และ V-Order - การตั้งค่า Dataflow Gen2 ที่เหมาะสมที่สุดสําหรับสถานการณ์นี้ - การรีเฟรชโต๊ะแท็กซี่ NYC ที่มีแถว 113 ล้านแถวเป็นโต๊ะ Lakehouse ในสถานการณ์ที่ 3 จะเสร็จสิ้นในเวลา 00:03:34 และใช้เวลา 2,391 CU วินาที ตารางต่อไปนี้แบ่งยอดรวมตามการดําเนินการ:
| การดำเนินการ | เครื่องยนต์ (เมตร) | วินาที CU |
|---|---|---|
| เรียกใช้คิวรี | การคํานวณมาตรฐาน | 2,391 |
| ผลรวม | 2,391 |
งานทั้งหมดคิดค่าบริการผ่าน Standard Compute (12 CU สําหรับทุกวินาทีถึง 10 นาที และ 1.5 CU สําหรับทุกวินาทีที่เพิ่มขึ้น) สําเนาที่ปรับแต่งไปยัง lakehouse จะวิ่งผ่าน mashup engine ดังนั้นไม่มีมิเตอร์แยกต่างหาก สําหรับโมเดลอัตราเต็ม ดูที่ราคาของ Dataflow Gen2
ประเด็นสําคัญ
- การคัดลอกที่ปรับแต่งไปยัง Lakehouse เร่งการเขียนผลลัพธ์ที่แปลงแล้วไปยังปลายทางของ Lakehouse ลดการรีเฟรชจาก 00:14:45 (โดยไม่รวม) เหลือ 00:03:34 - เร็วกว่าการไหลข้อมูลเดียวกันที่ไม่มี Lakehouse ประมาณ 4× และเร็วกว่าค่าพื้นฐานของ Dataflow Gen1 ประมาณ 15× (00:53:20)
- สถานการณ์นี้ประหยัดความจุได้มากที่สุดเมื่อเทียบกับ Dataflow Gen1 ในบทความนี้: Dataflow Gen2 ใช้ความจุน้อยกว่า Dataflow Gen1 ถึง 95% (2,391 วินาที เทียบกับ 50,788 CU วินาที)
- มันต้อง เปิดใช้งานการตั้งขั้นตอน บนคําค้นหาและปลายทาง lakehouse และไม่เปลี่ยนแปลงตรรกะการแปลงของคุณ
- สถานการณ์นี้ใช้ V-Order อย่างชัดเจนบนเอาต์พุตปลายทาง
- ใช้ Optimized copy to Lakehouse ทุกครั้งที่คุณเขียนข้อมูลแบบ staged ไปยังปลายทาง lakehouse และเวลาการเขียนจะครอบงําการรีบทวน
สถานการณ์ที่ 4: รวมไฟล์
หมายเหตุ
Partitioned Compute กําลังอยู่ในโหมด พรีวิว และมีให้ใช้งานเฉพาะใน Dataflow Gen2 ที่มี CI/CD เท่านั้น ความสามารถนี้ยังคงได้รับการปรับปรุง ดังนั้นพฤติกรรม การแปลงที่รองรับ และประสิทธิภาพอาจเปลี่ยนแปลงได้ก่อนที่พร้อมใช้งานทั่วไป ถือว่าผลลัพธ์ในสถานการณ์นี้เป็นภาพรวมจุดเวลาของตัวอย่าง
ตอนนี้ทีมต้องรวบรวมและเพิ่มข้อมูลการเดินทางในไฟล์ Parquet หลายร้อยไฟล์ (พาร์ติชันรายเดือน) การแปลงรวมถึงเปอร์เซ็นต์ทิปการคํานวณทั่วทั้งชุดข้อมูล
ชาเลนจ์
- คุณต้องประมวลผลไฟล์ขนาดใหญ่หลายร้อยไฟล์
- การแปลงจําเป็นต้องมีการจัดกลุ่ม การรวม และการเพิ่มความสมบูรณ์ในพาร์ติชันต่างๆ
- การดําเนินการตามลําดับกลายเป็นคอขวด
ชุดข้อมูล
ไฟล์ Parquet จํานวน 56 ไฟล์ (2021–สิงหาคม 2025)
โซลูชัน
ทีมงานเปิดใช้งาน Partitioned Compute (Preview) ซึ่งทําให้การประมวลผลแบบขนานข้ามพาร์ติชันและรวมผลลัพธ์ได้อย่างมีประสิทธิภาพ
การออกแบบ
คําสั่งนี้รวมไฟล์ Parquet จํานวน 56 ไฟล์และสร้างคอลัมน์ใหม่สําหรับเปอร์เซ็นต์ทิป "Tip Pctg" บน ไฟล์ Transform Sample ก่อนโหลดข้อมูลเข้าสู่คลังสินค้า
ข้อควรพิจารณาเกี่ยวกับการประมวลผลแบบแบ่งพาร์ติชัน
- ขณะนี้อยู่ใน โหมดพรีวิว และมีให้ใช้งานเฉพาะใน Dataflow Gen2 กับ CI/CD; ความสามารถนี้ยังคงได้รับการปรับปรุงอย่างต่อเนื่อง
- ใช้เมื่อแหล่งที่มาไม่รองรับการพับ
- ให้ประสิทธิภาพที่ดีที่สุดเมื่อโหลดข้อมูลไปยัง stag จิ้งหรือคลังสินค้า
- ใช้ ไฟล์แปลงตัวอย่าง จาก ไฟล์ Combine เพื่อให้ตรรกะการแปลงสอดคล้องกัน
- รองรับชุดย่อยของการเปลี่ยนแปลง ประสิทธิภาพแตกต่างกันไป
ผลลัพธ์
Partitioned Compute ให้ ประสิทธิภาพที่เร็วกว่ามาตรฐาน Dataflow Gen1 ประมาณ 21× (00:04:48 เทียบกับ 01:40:57) บนชุดข้อมูลขนาดใหญ่ที่แบ่งพาร์ติชันและมีหลายไฟล์
| การกําหนดค่า | เวลาดําเนินการ (hh:mm:ss) | เปรียบเทียบกับ Gen1 | CU ถูกใช้หมด |
|---|---|---|---|
| พื้นฐานของกระแสข้อมูล Gen1 | 01:40:57 | — | ไม่ได้วัด |
| กระแสข้อมูล Gen2 พร้อมการประมวลผลแบบแบ่งพาร์ติชัน | 00:04:48 | เร็วขึ้น 21× | ไม่ได้วัด |
Partitioned Compute มุ่งเป้าไปที่เวลานาฬิกาบนผนังมากกว่าต้นทุน มันรันพาร์ติชันแบบขนานเพื่อให้รีเฟรชเสร็จเร็วขึ้น แต่ความขนานนี้จะทําให้งานกระจายไปยังคอมพิวต์มากขึ้นแทนที่จะลด ดังนั้นต้นทุนจึงมักจะใกล้เคียงหรือสูงกว่าภาระงานเดียวกันที่ไม่มีฟีเจอร์นี้ การใช้ CU ไม่ได้ถูกวัดสําหรับสถานการณ์นี้ ดังนั้นบทความนี้จึงรายงานเฉพาะเวลารันเท่านั้น
ประเด็นสําคัญ
- การประมวลผลแบบแบ่งพาร์ติชันให้การเร่งความเร็ว 21× จากพื้นฐานของกระแสข้อมูล Gen1 และเสร็จสิ้นภายในเวลาไม่ถึงห้านาที เนื่องจากความสามารถนี้อยู่ในช่วงทดลองและยังคงได้รับการปรับปรุง คาดว่าตัวเลขเหล่านี้จะเปลี่ยนแปลงไป
- มองว่า Partitioned Compute เป็นวิธีทําให้เสร็จเร็วขึ้น ไม่ใช่ประหยัด การประมวลผลแบบขนานช่วยลดเวลาของนาฬิกาบนผนังโดยรันพาร์ติชันพร้อมกัน ดังนั้นต้นทุนจึงมักจะใกล้เคียงหรือสูงกว่าภาระงานเดียวกันที่ไม่มี Parallelism
- กําไรมาจากการประมวลผลแต่ละพาร์ติชันแบบขนานและการรวมผลลัพธ์ดังนั้นจึงมีประสิทธิภาพสูงสุดในแหล่งข้อมูลหลายไฟล์หรือพาร์ติชันที่ไม่สามารถใช้การพับได้และการประเมินตามลําดับเป็นคอขวด
- ใช้รูปแบบ ไฟล์แปลง ตัวอย่างจากไฟล์ Combine เพื่อให้ตรรกะการแปลงถูกนําไปใช้อย่างสม่ําเสมอต่อแต่ละพาร์ติชัน Partitioned Compute รองรับการแปลงบางส่วนในปัจจุบัน ดังนั้นควรตรวจสอบว่าขั้นตอนการขึ้นรูปของคุณเข้ากันได้ก่อนจะพึ่งพา และตรวจสอบใหม่เมื่อพรีวิวพัฒนาไป
- สําหรับการนําเข้าแบบแบ่งพาร์ติชันที่มีปริมาณมากไปยังการจัดเตรียมหรือคลังสินค้า ให้ทําให้การคํานวณแบบแบ่งพาร์ติชันเป็นค่าเริ่มต้นและรวมเข้ากับ Modern Evaluator เมื่อใดก็ตามที่เป็นไปได้ เนื่องจากยังอยู่ในขั้นตอนพรีวิว ให้ตรวจสอบกับงานของคุณเองก่อนนําไปใช้ในการรีเฟรชการผลิต
ต้นทุนตามเวลา (ในอดีตเทียบกับปัจจุบัน)
Dataflow Gen2 กลายเป็นเครื่องมือที่คุ้มค่ามากขึ้นเมื่อใช้งานไปเรื่อย ๆ ตรรกะเดียวกันนี้ใช้ข้อมูลเดิม ใช้ทรัพยากร CU น้อยกว่าที่เคยเป็นในอดีต โดยไม่ต้องเปลี่ยนแปลงคําสั่งค้นหา
ในการเปรียบเทียบนี้ หมายถึงปริมาณงานเท่าเดิมภายใต้ราคาและความสามารถที่มีอยู่ทั่วไปก่อนปี 2026 ตอนนี้ หมายถึงงานที่รันเหมือน เดิม ในปัจจุบัน พร้อมการตั้งค่าที่ดีที่สุดที่มีอยู่ทั่วไป (เช่น Modern Evaluator และ Fast Copy) ทั้งสองคอลัมน์ใช้รูปแบบที่ดีที่สุดที่มีอยู่โดยทั่วไปในยุคนั้น ตัวเลข ปัจจุบัน วัดจากเทเลเมทรีความจุ ตัวเลข เหล่านั้น เป็นการประมาณว่างานเดียวกันนั้นจะใช้ไปมากแค่ไหนในขณะนั้น เพราะสภาพการให้บริการเดิมไม่สามารถทําซ้ําได้ในปัจจุบัน
| สถานการณ์สมมติ | ความสามารถ | ค่าประมาณการก่อนปี 2026 (GA ที่ดีที่สุด) | CU Now (GA ที่ดีที่สุด) | การลดโดยประมาณ |
|---|---|---|---|---|
| สถานการณ์สมมติที่ 1: คัดลอกข้อมูล | คัดลอกอย่างรวดเร็ว | 17,055 | 14,593 | 14% |
| สถานการณ์ที่ 2: การสร้างข้อมูลจํานวนมาก | ผู้ประเมินที่ทันสมัย | 66,164 | 10,485 | 84% |
| สถานการณ์ที่ 3: คัดลอกไปยัง Lakehouse ที่ปรับแต่งให้เหมาะสม | คัดลอกที่ปรับแต่งไปยัง Lakehouse | 14,173 | 2,391 | 83% |
ตัวอย่างเช่น งาน heavy-shaping ในสถานการณ์ที่ 2 จะใช้ประมาณ 66,164 CU วินาทีก่อนปี 2026 และตอนนี้ใช้ 10,485 CU วินาที การเปลี่ยนแปลงนี้เป็นการลด 84% โดยใช้ตรรกะเหมือนเดิมและไม่ต้องเปลี่ยนแปลงอะไร มีการปรับปรุงสองอย่างที่รวมกันเพื่อสร้างมันขึ้นมา อันดับแรก ราคา Standard Compute กลายเป็นแบบแบ่งชั้น: แทนที่จะจ่าย 16 CU แบบคงที่ทุกวินาทีของการทํางานทั้งหมด แต่ 10 นาทีแรกคิดค่าบริการที่ 12 CU ต่อทุกวินาที และทุกวินาทีหลังจากนั้นคิดค่าบริการเพียง 1.5 CU ดังนั้นภาระงาน shaping ที่ยาวจึงมีต้นทุนลดลงมาก ประการที่สอง Modern Evaluator ซึ่งโดยทั่วไปมีให้ใช้ตั้งแต่เดือนเมษายน 2026 จะลดระยะเวลาการเรียกเก็บเงินเอง ทําให้มีเวลาคิดค่าบริการน้อยลงในแต่ละระดับ ระยะเวลาสั้นลงที่คิดค่าบริการเทียบกับอัตราระยะยาวที่ถูกกว่ามากคือเหตุผลที่การใช้ CU ลดลงอย่างรวดเร็ว และเป็นเหตุผลว่าทําไมการจับคู่ Modern Evaluator กับราคาแบบขั้นบันไดปัจจุบันจึงสําคัญมากสําหรับการกําหนดทิศทางข้อมูลที่เน้นการไหลเวียนข้อมูลหนัก
การรับข้อมูล Fast Copy ในสถานการณ์ที่ 1 จะใช้เวลาประมาณ 17,055 CU วินาทีก่อนปี 2026 และตอนนี้ใช้ไป 14,593 CU วินาที การเปลี่ยนแปลงนี้เป็นการลดลง 14% โดยอัตราการประมวลผลมาตรฐานลดลงจาก 16 CU ต่อวินาทีเป็น 12 CU ต่อทุกวินาทีจนถึง 10 นาที; ส่วนการเคลื่อนย้ายข้อมูลแบบ Fast Copy ยังคงเหมือนเดิม การรีเฟรช Optimized ไปยัง Lakehouse ในสถานการณ์ที่ 3 จะใช้เวลา 14,173 CU วินาทีก่อนปี 2026 และตอนนี้ใช้ไป 2,391 CU วินาที การเปลี่ยนแปลงนี้คือการลดลง 83% แต่ละการเปรียบเทียบใช้ภาระงานเดียวกัน พร้อมการตั้งค่าที่ดีที่สุดในยุคนั้น
หมายเหตุ
การเปรียบเทียบระหว่างอดีตกับปัจจุบันนี้ไม่รวม Partitioned Compute เพราะการใช้ CU ไม่ได้ถูกวัดสําหรับสถานการณ์นั้น และความสามารถยังอยู่ในช่วงทดลองใช้งาน
คำถามที่ถามบ่อย
Dataflow Gen2 เรียกเก็บเงินอย่างไร?
Dataflow Gen2 จะเรียกเก็บเงินแต่ละเอนจินแยกกันในหน่วยความจุ Fabric (CUs) Standard Compute (engine mashup) คิดค่าบริการ 12 CU สําหรับทุกวินาทีถึง 10 นาทีของแต่ละคําสั่ง จากนั้น 1.5 CU สําหรับทุกวินาทีที่เพิ่มขึ้น Fast Copy (การเคลื่อนย้ายข้อมูล) คิดค่าบริการ 1.5 CU สําหรับทุกวินาทีของกิจกรรมการคัดลอก วัดจากทุกคอร์ที่การคัดลอกทํางานอยู่ คุณจะถูกคิดค่าบริการเฉพาะสําหรับการประมวลผลที่แต่ละคิวรีใช้จริง โดยไม่มีค่าธรรมเนียมต่อการรีเฟรชคงที่และไม่คิดค่าบริการสําหรับเวลาว่าง สําหรับโมเดลอัตราทั้งหมด ดูที่ราคาของ Dataflow Gen2
ราคาของ Dataflow Gen2 ยืดหยุ่นได้หรือไม่?
ใช่ Dataflow Gen2 คิดค่าบริการเฉพาะสําหรับการคํานวณที่แต่ละคําสั่งใช้จริง โดยวัดเป็นหน่วยความจุ Fabric (CUs) ไม่มีค่าบริการคงที่ต่อการรีเฟรช ไม่มีค่าบริการสําหรับเวลาว่าง และไม่มีค่าธรรมเนียมโดยตรงระหว่างเวลาสร้างสําหรับฟังก์ชันเนทีฟ ในการทดสอบประสิทธิภาพในบทความนี้ การรีเฟรชเต็มรูปแบบใช้เวลา 14,593 CU วินาทีสําหรับการนําเข้า Fast Copy และ 10,485 CU วินาทีสําหรับงาน shaping ที่หนัก
ฉันจะประมาณต้นทุน Dataflow Gen2 ก่อนที่จะทํางานเต็มปริมาณได้อย่างไร?
ดําเนินการรีเฟรชขนาดเล็กที่เป็นตัวแทนและวัดปริมาณที่ใช้ไป แทนที่จะสร้างโซลูชันทั้งหมดแล้วค่อยดูต้นทุนทีหลัง เพื่อประมาณต้นทุนดังนี้:
- สร้าง dataflow กับตัวอย่างหรือพาร์ติชันเดียวของแหล่งที่มา แทนที่จะใช้ชุดข้อมูลทั้งหมด
- รีเฟรชครั้งหนึ่ง จากนั้นอ่านจํานวนวินาทีที่ใช้ CU ในแอป Microsoft Fabric Capacity Metrics
- ตรวจสอบ ประวัติการรีเฟรชข้อมูลเพื่อดู ว่าเอนจินใดทํางานอยู่ เพราะ Standard Compute และ Fast Copy จะถูกเรียกเก็บเงินแยกกัน
- หารวินาที CU ที่วัดได้ด้วยแถวหรือ GB ที่คุณประมวลผลเพื่อได้อัตราต่อหน่วย แล้วคูณด้วยปริมาณข้อมูลทั้งหมดของคุณ
หมายเหตุ
Dataflow Gen2 ถูกออกแบบมาให้เหมาะกับงานขนาดใหญ่ ดังนั้นประโยชน์ด้านประสิทธิภาพและประสิทธิภาพจึงเห็นได้ชัดที่สุดเมื่อใช้งานในชุดข้อมูลขนาดใหญ่ในโลกจริง ตัวอย่างขนาดเล็กหรือสังเคราะห์อาจไม่แสดงผลกําไรเต็มที่ และอัตราต่อหน่วยที่ประมาณจากตัวอย่างขนาดเล็กอาจประเมินต้นทุนของการผลิตเต็มครั้งเกินจริง ตรวจสอบความถูกต้องกับปริมาณข้อมูลที่เป็นตัวแทนเมื่อใดก็ตามที่ทําได้
สําหรับวิธีทั้งหมด ดูที่ คํานวณต้นทุนประมาณโดยใช้แอป Fabric Metrics และประวัติการรีเฟรชข้อมูลไหล
การรีเฟรช Dataflow Gen2 ใช้เวลานานเท่าไร?
มันขึ้นอยู่กับปริมาณข้อมูลและการแปลงที่คุณใช้ ในการทดสอบประสิทธิภาพในบทความนี้ การรีเฟรช Dataflow Gen2 มีตั้งแต่ 00:03:34 สําหรับการคัดลอกตารางที่มี 113 ล้านแถวให้เหมาะสมกับบ้านริมทะเลสาบ ไปจนถึง 00:46:29 สําหรับงาน shaping หนักบนไฟล์ Parquet ขนาดใหญ่ที่รวมกัน สําเนาไฟล์รวม Parquet จํานวนห้าไฟล์ที่เสร็จในเวลา 00:09:08 ด้วย Fast Copy และไฟล์พาร์ติชันรวม 56 ไฟล์ที่เสร็จในเวลา 00:04:48 ด้วย Partitioned Compute (Preview) สําหรับเวลาทั้งหมดต่อสถานการณ์ โปรดดูสรุปผลการทดสอบ
ความสามารถ Dataflow Gen2 ตัวไหนช่วยลดต้นทุนได้มากที่สุด?
ขึ้นอยู่กับภาระงาน เพราะแต่ละความสามารถจะมุ่งเป้าไปที่คอขวดที่แตกต่างกัน: Fast Copy สําหรับการนําเข้าข้อมูลโดยไม่ต้องแปลง, Modern Evaluator สําหรับการจัดรูปแบบข้อมูลที่ไม่สามารถพับได้, Optimized copy to Lakehouse สําหรับเร่งการเขียนไปยังปลายทาง lakehouse และ Partitioned Compute (Preview) สําหรับชุดข้อมูลขนาดใหญ่ที่มีหลายไฟล์ เมื่อวัดเทียบกับค่าพื้นฐานของ Dataflow Gen1 การคัดลอกที่ปรับแต่งไปยัง Lakehouse สามารถประหยัดค่าใช้จ่ายได้มากที่สุดในกลุ่มทดสอบเหล่านี้ โดยใช้เวลา CU ลดลง 95% วินาที เมื่อเทียบกับการรัน Dataflow Gen2 ที่เทียบเท่าก่อนปี 2026 Modern Evaluator ให้การลดที่ประมาณการมากที่สุด โดยลดลง 84% CU วินาทีบนภาระงาน shaping ที่หนัก หากต้องการจับคู่ความสามารถกับปริมาณงานของคุณ โปรดดูเอกสารอ้างอิงด่วน
ฉันจะทําให้ Dataflow Gen2 รีเฟรชเร็วขึ้นได้อย่างไร?
ปรับให้เหมาะสมกับคอขวด: เปิดใช้งาน Fast Copy สําหรับแหล่งดึงข้อมูลที่รองรับ, เปิดใช้งาน Modern Evaluator สําหรับการแปลงแบบไม่พับได้, เปิดใช้งาน Optimized copy to Lakehouse เมื่อเขียนข้อมูลแบบ staged ไปยังปลายทาง lakehouse และใช้ Partitioned Compute (Preview) สําหรับชุดข้อมูลขนาดใหญ่ที่แบ่งพาร์ติชันหรือหลายไฟล์ แต่ละความสามารถจะถูกทดสอบมาตรฐานในบทความนี้โดยระบุความเร็วที่ให้ได้เหนือ Dataflow Gen1 baseline
ฉันจําเป็นต้องเปลี่ยนคําค้นหาเพื่อให้ได้การปรับปรุงเหล่านี้หรือไม่?
ไม่ใช่ ทุกการทดสอบประสิทธิภาพในบทความนี้รันสคริปต์ M เดียวกันทั้งในทั้งสองเจเนอเรชันและทุกการตั้งค่า Fast Copy, Modern Evaluator และ Optimized copy to Lakehouse เป็นการตั้งค่าที่คุณเปิดใช้งาน และมันจะเปลี่ยนวิธีที่เอนจินประมวลผลคําค้นหาของคุณ แทนที่จะเป็นคําสั่งค้นหาเอง ข้อควรระวัง: Fast Copy ใช้ได้เฉพาะกับขั้นตอนที่ตรงตามข้อกําหนดเท่านั้น ดังนั้นการแปลงที่ขัดขวางการพับคําสั่งจะกลับไปที่เอนจินมาตรฐานและสูญเสียกําไร สําหรับข้อกําหนดเหล่านั้น ดูที่ Fast copy ใน Dataflow Gen2
Dataflow Gen2 เร็วกว่าและถูกกว่า Dataflow Gen1 หรือไม่?
สําหรับงานที่มีปริมาณมากเช่นที่กล่าวถึงในบทความนี้ ใช่ทั้งสองข้อ Dataflow Gen2 ทํางานเร็วกว่าค่าพื้นฐานของ Dataflow Gen1 ระหว่าง 1.7× ถึง 21× บนข้อมูลเดียวกันและสคริปต์ M เดียวกัน และใช้ความจุน้อยกว่า 82% ถึง 95% ในสถานการณ์ที่วัดทั้งสองรุ่น ตัวอย่างเช่น การคัดลอกจํานวนมากที่ใช้เวลา 01:38:59 ใน Dataflow Gen1 เสร็จที่ 00:09:08 ใน Dataflow Gen2 พร้อม Fast Copy - เร็วขึ้นประมาณ 11× ความแตกต่างจะน้อยกว่าสําหรับการไหลข้อมูลที่ทํางานระยะสั้น เพราะคําสั่งที่เสร็จสิ้นภายใน 10 นาทีแรกจะไม่ถึงระดับ 1.5 CU ที่ถูกกว่า ดังนั้นผลประโยชน์จะเพิ่มขึ้นตามปริมาณข้อมูลและเวลาทํางาน สําหรับการเปรียบเทียบต่อสถานการณ์ทั้งหมด โปรดดูสรุปผลการทดสอบ
Dataflow Gen1 ใช้ความจุมากแค่ไหนเมื่อเทียบกับ Dataflow Gen2?
ในสถานการณ์ที่วัดทั้งสองเจเนอเรชัน Dataflow Gen1 ใช้ความจุมากกว่าหลายเท่าเมื่อเทียบกับ Dataflow Gen2 สําหรับงานที่มีปริมาณมากเท่ากัน การรับข้อมูลแบบ Fast Copy ใช้เวลา 84,411 CU วินาทีบน Dataflow Gen1 เทียบกับ 14,593 CU วินาทีใน Dataflow Gen2 ลดลง 83% ภาระงาน data shapeping ที่หนักหน่วงใช้เวลา 56,855 CU วินาทีใน Dataflow Gen1 เทียบกับ 10,485 CU วินาทีใน Dataflow Gen2 ลดลง 82% งาน Optimized copy to Lakehouse ใช้เวลา 50,788 CU วินาทีบน Dataflow Gen1 เทียบกับ 2,391 CU วินาทีใน Dataflow Gen2 ลดลง 95% ทั้งสามรีเฟรชนี้ใช้เวลานานเกิน 10 นาที ดังนั้นระยะเวลาส่วนใหญ่ของ Dataflow Gen2 จึงอยู่ที่อัตราต่ํากว่า 1.5 CU สําหรับตัวเลขต่อสถานการณ์ ดูสรุปผลการทดสอบมาตรฐาน
ฉันควรย้ายข้อมูลการไหลของ Dataflow Gen1 ไปยัง Dataflow Gen2 หรือไม่?
ใช่ Dataflow Gen2 เป็นรุ่นปัจจุบันของ dataflow ใน Microsoft Fabric ดังนั้นวางแผนย้าย dataflow Gen1 ใด ๆ ไปยัง Dataflow Gen2 ในการทดสอบประสิทธิภาพในบทความนี้ Dataflow Gen2 ทําสคริปต์ M เดียวกันได้เร็วกว่า 1.7× ถึง 21× ขณะใช้ความจุ 82% ถึง 9% 5 หน่วยน้อยกว่า Dataflow Gen1 — ตรรกะเดียวกัน ทํางานเร็วกว่าและใช้ความจุน้อยกว่า ความสามารถที่ให้ผลลัพธ์เหล่านั้น เช่น Fast Copy, Modern Evaluator, Optimized copy to Lakehouse และ Partitioned Compute มีให้เฉพาะใน Dataflow Gen2 ดังนั้นช่องว่างจึงขยายกว้างขึ้นเมื่อความสามารถเหล่านั้นพัฒนาขึ้น คาดว่าจะได้กําไรสูงสุดจากการรีเฟรชที่มีปริมาณมากและยาวนาน ขณะที่คุณย้ายข้อมูล ให้ทดสอบภาระงานตัวแทนเพื่อยืนยันการเพิ่มผลประโยชน์จากข้อมูลและความจุของคุณเอง เริ่มต้นใช้งาน ดูภาพรวมของ Dataflow Gen2
Dataflow Gen2 ได้กลายเป็นระบบที่คุ้มค่ามากขึ้นหรือไม่?
ใช่ ภาระงาน heavy-shaping ใน Scenario 2 จะใช้ประมาณ 66,164 CU วินาทีก่อนปี 2026 และตอนนี้ใช้ 10,485 CU วินาทีด้วยความสามารถที่มีอยู่ทั่วไปในปัจจุบัน ลดลงประมาณ 84% ด้วยตรรกะเดียวกันและไม่ต้องเปลี่ยนแปลง สําหรับตัวเลขต่อสถานการณ์ ดูที่ ต้นทุนตามเวลา (ในอดีตเทียบกับปัจจุบัน)
ตัวเลขต้นทุนและประสิทธิภาพของ Dataflow Gen2 รุ่นเก่ายังคงแม่นยําอยู่หรือไม่?
ไม่จำเป็น ตัวเลขในบทความนี้สะท้อนโมเดลราคาปัจจุบันของ Dataflow Gen2 - 12 CU สําหรับทุกวินาทีจนถึง 10 นาทีของ Standard Compute จากนั้น 1.5 CU สําหรับทุกวินาทีเพิ่มเติม - พร้อมกับความสามารถปัจจุบัน เช่น Fast Copy และ Modern Evaluator เนื่องจาก Dataflow Gen2 มีความเร็วและคุ้มค่ามากขึ้นเมื่อเวลาผ่านไป ตัวเลขมาตรฐานหรือประมาณการต้นทุนที่เผยแพร่ก่อนปี 2026 อาจประเมินต้นทุนปัจจุบันสูงเกินจริงหรือประเมินประสิทธิภาพปัจจุบันต่ําเกินไป ตรวจสอบความถูกต้องของงานของคุณเองกับแอป Microsoft Fabric Capacity Metrics