หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
Microsoft Fabric มีหลายวิธีในการนําข้อมูลเข้าสู่แพลตฟอร์ม คู่มือนี้จะให้คําแนะนําที่ชัดเจนสําหรับสถานการณ์ที่พบบ่อยที่สุด จากนั้นจะให้ การเปรียบเทียบคุณสมบัติโดยละเอียด เมื่อคุณต้องการเจาะลึกลงไป
คําแนะนําด่วน: ฉันควรใช้ตัวเลือกการย้ายข้อมูลแบบใด
ใช้สถาปัตยกรรมเหรียญเป็นแนวทางของคุณ:
ข้อมูลทองคํา (การรายงานและการวิเคราะห์ข้อมูลที่ประมวลผล) - ใช้การมิเรอร์ หากคุณมีการประมวลผล ETL ที่อื่นอยู่แล้ว และส่วนใหญ่จําเป็นต้องนําข้อมูลที่รวบรวมไว้ใน Fabric เพื่อการรายงาน การมิเรอร์เป็นตัวเลือกที่ง่ายที่สุดและคุ้มค่าที่สุด ไม่ต้องตั้งค่าเพียงเล็กน้อย และทําซ้ําข้อมูลของคุณไปยัง OneLake อย่างต่อเนื่อง
ข้อมูลบรอนซ์ (การนําเข้าดิบ) - เริ่มต้นด้วยงานคัดลอก เมื่อคุณนําเข้าข้อมูลดิบ คุณจะต้องมีการแปลง การแม็ป Schema การควบคุมการจัดกําหนดการ และการโหลดที่เพิ่มขึ้นอย่างรวดเร็ว งานคัดลอกให้ความสามารถเหล่านี้แก่คุณโดยกําเนิดโดยไม่ต้องสร้างไปป์ไลน์ที่ซับซ้อน
ข้อมูลการสตรีมแบบเรียลไทม์ - ใช้ Eventstreams สําหรับการนําเข้าและการประมวลผลที่ขับเคลื่อนด้วยเหตุการณ์ที่มีเวลาแฝงต่ํา Eventstreams มีไปป์ไลน์แบบเรียลไทม์พร้อมการแปลงแบบไม่ใช้โค้ดและการกําหนดเส้นทางไปยังปลายทางหลายแห่ง
การประสานที่ซับซ้อน - ไปป์ไลน์จะให้ความยืดหยุ่นในการประสานที่คุณต้องการ และกิจกรรมการคัดลอกในไปป์ไลน์จะนําเสนอการกําหนดพารามิเตอร์ออบเจ็กต์ข้อมูล และการนําเข้าข้อมูลที่ขับเคลื่อนด้วยข้อมูลเมตา มิฉะนั้น กิจกรรมงานคัดลอกและกิจกรรมการคัดลอกจะเท่าเทียมกันในไปป์ไลน์
สําหรับรายละเอียดความสามารถและคุณสมบัติที่รองรับแบบเคียงข้างกันทั้งหมด โปรดดู การเปรียบเทียบคุณลักษณะโดยละเอียด
แนวคิดหลัก
การมิเรอร์ ช่วยให้คุณมีวิธี ที่ง่ายและฟรี ในการสะท้อนข้อมูลการดําเนินงานไปยัง Fabric เพื่อการวิเคราะห์ ได้รับการปรับให้เหมาะสมเพื่อความสะดวกในการใช้งานด้วยการตั้งค่าเพียงเล็กน้อย และเขียนไปยังปลายทางแบบอ่านอย่างเดียวใน OneLake
กิจกรรมการคัดลอกในไปป์ไลน์สร้างขึ้นสําหรับผู้ใช้ที่ต้องการเวิร์กโฟลว์การนําเข้าข้อมูลตามไปป์ไลน์ที่ประสานกัน คุณสามารถปรับแต่งได้อย่างกว้างขวางและเพิ่มตรรกะการแปลง แต่คุณต้องกําหนดและจัดการส่วนประกอบไปป์ไลน์ด้วยตัวเอง รวมถึงการติดตามสถานะของการเรียกใช้ครั้งล่าสุดสําหรับสําเนาส่วนเพิ่ม
Copy Job ทําให้การนําเข้าข้อมูลง่ายขึ้นด้วย การสนับสนุนแบบเนทีฟสําหรับรูปแบบการส่งที่หลากหลาย รวมถึงการคัดลอกจํานวนมาก การคัดลอกส่วนเพิ่ม และการจําลองแบบการบันทึกข้อมูลการเปลี่ยนแปลง (CDC) และคุณไม่จําเป็นต้องสร้างไปป์ไลน์ ในขณะที่ยังคงให้คุณเข้าถึงตัวเลือกขั้นสูงมากมาย รองรับแหล่งที่มาและปลายทางมากมาย และทํางานได้ดีเมื่อคุณต้องการควบคุมมากกว่าการมิเรอร์ แต่มีความซับซ้อนน้อยกว่าการจัดการไปป์ไลน์ด้วยกิจกรรมการคัดลอก
Eventstreams: ออกแบบมาสําหรับการนําเข้า การแปลง และการประมวลผลข้อมูลสตรีมแบบเรียลไทม์ รองรับไปป์ไลน์ที่มีเวลาแฝงต่ํา การจัดการสคีมา และการกําหนดเส้นทางไปยังปลายทาง เช่น รองรับ Eventhouse, Lakehouse, Activator และ Custom Endpoints (ตําแหน่งข้อมูล AMQP, Kafka และ HTTP)
การเปรียบเทียบคุณสมบัติโดยละเอียด
ตารางต่อไปนี้เปรียบเทียบความสามารถทั้งหมดของตัวเลือกการย้ายข้อมูลแต่ละรายการ ใช้ส่วนนี้เมื่อคุณต้องการประเมินคุณลักษณะเฉพาะสําหรับสถานการณ์ของคุณ
| เรอร์ | คัดลอกงาน | กิจกรรมการคัดลอก (ไปป์ไลน์) | สตรีมเหตุการณ์ | |
|---|---|---|---|---|
| แหล่ง | ฐานข้อมูล + การรวมบุคคลที่สามเข้ากับ Open Mirroring | แหล่งข้อมูลและรูปแบบที่รองรับทั้งหมด | แหล่งข้อมูลและรูปแบบที่รองรับทั้งหมด | 25+ แหล่งที่มาและทุกรูปแบบ |
| จุดหมาย ปลาย ทาง | รูปแบบตารางใน Fabric OneLake (อ่านอย่างเดียว) | ปลายทางและรูปแบบที่รองรับทั้งหมด | ปลายทางและรูปแบบที่รองรับทั้งหมด | 4+ จุดหมายปลายทาง |
| ความยืดหยุ่น | การตั้งค่าที่ง่ายด้วยพฤติกรรมคงที่ | ใช้งานง่าย + ตัวเลือกขั้นสูง | ตัวเลือกขั้นสูงและปรับแต่งได้อย่างเต็มที่ | ตัวเลือกที่เรียบง่ายและปรับแต่งได้ |
| สมรรถนะ | เรอร์ | คัดลอกงาน | กิจกรรมการคัดลอก (ไปป์ไลน์) | สตรีมเหตุการณ์ |
|---|---|---|---|---|
| การตั้งเวลาแบบกําหนดเอง | ใช่ | ใช่ | ต่อเนื่อง | |
| การจัดการตารางและคอลัมน์ | ใช่ | ใช่ | ใช่ (Schema การจัดการเหตุการณ์และฟิลด์) | |
| ลักษณะการคัดลอก: ผนวก เพิ่ม แทนที่ | ใช่ | ใช่ | ผนวก | |
| ความสามารถในการสังเกตขั้นสูง + การตรวจสอบ | ใช่ | ใช่ | ||
| โหมดการทําสําเนา | ||||
| การจําลองแบบต่อเนื่องตาม CDC | ใช่ | ใช่ | ใช่ | |
| การคัดลอกเป็นชุดหรือจํานวนมาก | ใช่ | ใช่ | ใช่ (การจําลองสแนปช็อตเริ่มต้นของ CDC) | |
| การสนับสนุนแบบเนทีฟสําหรับการคัดลอกแบบเพิ่มหน่วย (ตามลายน้ํา) | ใช่ | |||
| คัดลอกโดยใช้แบบสอบถามที่ผู้ใช้กําหนดเอง | ใช่ | ใช่ | ||
| กรณีการใช้งาน | ||||
| การจําลองแบบต่อเนื่องสําหรับการวิเคราะห์และการรายงาน | ใช่ | ใช่ | ใช่ | |
| ELT/ETL ที่ขับเคลื่อนด้วยข้อมูลเมตาสําหรับคลังข้อมูล | ใช่ | ใช่ | ||
| การรวมข้อมูล | ใช่ | ใช่ | ใช่ | |
| การโยกย้ายข้อมูล / การสํารองข้อมูล / การแบ่งปันข้อมูล | ใช่ | ใช่ | ใช่ | |
| ไม่มีค่าใช้จ่าย | ใช่ | |||
| ประสิทธิภาพที่คาดการณ์ได้ | ใช่ | ใช่ | ใช่ |
สถานการณ์
ตรวจสอบสถานการณ์เหล่านี้เพื่อช่วยคุณเลือกกลยุทธ์การเคลื่อนย้ายข้อมูลที่เหมาะกับความต้องการของคุณมากที่สุด
สถานการณ์สมมติที่ 1
เจมส์เป็นผู้จัดการฝ่ายการเงินของบริษัทประกันภัยแห่งหนึ่ง ทีมของเขาใช้ Azure SQL Database เพื่อติดตามข้อมูลนโยบาย การอ้างสิทธิ์ และข้อมูลลูกค้าในหน่วยธุรกิจหลายแห่ง ทีมผู้บริหารต้องการสร้างแดชบอร์ดแบบเรียลไทม์สําหรับการตรวจสอบประสิทธิภาพทางธุรกิจ แต่เจมส์ไม่สามารถอนุญาตให้การสืบค้นการวิเคราะห์ทําให้ระบบปฏิบัติการที่ประมวลผลธุรกรรมหลายพันรายการต่อวันช้าลง
James มีการประมวลผล ETL อยู่แล้ว และทีมของเขาต้องการข้อมูลระดับทองที่ประมวลผลแล้วที่มีอยู่ใน Fabric สําหรับการรายงานของผู้บริหาร เขาไม่ต้องการจัดการการจัดตารางเวลากําหนดค่าการโหลดที่เพิ่มขึ้นหรือกังวลเกี่ยวกับการเลือกตารางเขาต้องการให้ทุกอย่างสะท้อนโดยอัตโนมัติ การมีข้อมูลในรูปแบบอ่านอย่างเดียวใน OneLake จึงทํางานได้อย่างสมบูรณ์แบบ โซลูชันนี้ยังต้องคุ้มค่าเนื่องจากมาจากงบประมาณแผนกของเขา
เจมส์เลือกมิเรอร์ การมิเรอร์ให้การจําลองแบบต่อเนื่องตาม CDC ที่เขาต้องการ โดยจัดการตารางทั้งหมดโดยอัตโนมัติโดยไม่ต้องกําหนดค่าใดๆ การตั้งค่าที่เรียบง่ายหมายความว่าเขาไม่ต้องการความเชี่ยวชาญด้านเทคนิค และค่าใช้จ่ายฟรีก็เหมาะกับงบประมาณของเขา รูปแบบตารางแบบอ่านอย่างเดียวใน OneLake ช่วยให้ทีมของเขาสามารถเข้าถึงการวิเคราะห์ที่พวกเขาต้องการโดยไม่ส่งผลกระทบต่อประสิทธิภาพการดําเนินงาน
สถานการณ์สมมติที่ 2
ลิซ่าเป็นนักวิเคราะห์ธุรกิจที่บริษัทโลจิสติกส์ เธอจําเป็นต้องนําเข้าข้อมูลการจัดส่งดิบจากฐานข้อมูล Snowflake หลายฐานข้อมูลลงในตาราง Fabric Lakehouse สําหรับการวิเคราะห์ห่วงโซ่อุปทาน ข้อมูลประกอบด้วยทั้งบันทึกย้อนหลังสําหรับการโหลดเริ่มต้นและการจัดส่งใหม่ที่มาถึงตลอดทั้งวัน ลิซ่าต้องการเรียกใช้กระบวนการนี้ตามกําหนดเวลาที่กําหนดเอง - ทุกๆ 4 ชั่วโมงในช่วงเวลาทําการ
เนื่องจาก Lisa กําลังนําข้อมูลดิบระดับบรอนซ์เข้ามา เธอจึงรู้ว่าเธอจะต้องมีการแปลง การแมปสคีมา และการควบคุมการจัดกําหนดการอย่างรวดเร็ว เธอจําเป็นต้องเลือกตารางเฉพาะจากอินสแตนซ์ Snowflake แต่ละอินสแตนซ์ แมปคอลัมน์กับชื่อมาตรฐาน และใช้พฤติกรรม upsert เพื่อจัดการการอัปเดตเรกคอร์ดการจัดส่งที่มีอยู่ เธอยังต้องการการตรวจสอบขั้นสูงเพื่อติดตามคุณภาพของข้อมูลและประสิทธิภาพการประมวลผล
ลิซ่าเลือก "งานคัดลอก" งานคัดลอกให้การจัดกําหนดการแบบกําหนดเองที่เธอต้องการ สนับสนุนแหล่งข้อมูลทั้งหมด รวมถึง Snowflake และนําเสนอความสามารถในการจัดการตารางและคอลัมน์สําหรับการตั้งค่าหลายภูมิภาคของเธอ การสนับสนุนดั้งเดิมสําหรับการคัดลอกที่เพิ่มขึ้นด้วยการตรวจจับตามลายน้ําและพฤติกรรมการอัปเซิร์ตช่วยให้เธอจัดการกับข้อกําหนดเหล่านี้ได้โดยไม่ต้องสร้างไปป์ไลน์
สถานการณ์สมมติที่ 3
เดวิดเป็นวิศวกรข้อมูลอาวุโสของบริษัทโทรคมนาคมแห่งหนึ่ง เขากําลังสร้างเวิร์กโฟลว์การนําเข้าข้อมูลที่ซับซ้อนซึ่งจําเป็นต้องดึงข้อมูลการใช้งานของลูกค้าจาก Oracle โดยใช้การสืบค้น SQL แบบกําหนดเอง ใช้การแปลงทางธุรกิจ และโหลดไปยังปลายทางหลายแห่ง รวมถึงทั้ง Fabric Warehouse และระบบภายนอก เวิร์กโฟลว์ยังต้องประสานงานกับกิจกรรมไปป์ไลน์อื่นๆ เช่น การตรวจสอบความถูกต้องของข้อมูลและขั้นตอนการแจ้งเตือน
David ต้องการการควบคุมกระบวนการคัดลอกอย่างเต็มที่ รวมถึงความสามารถในการใช้คิวรีที่ผู้ใช้กําหนดเพื่อรวมตารางและกรองข้อมูลที่ต้นทาง เขาต้องการตัวเลือกการกําหนดค่าขั้นสูงและปรับแต่งได้อย่างเต็มที่ประสิทธิภาพที่คาดการณ์ได้สําหรับปริมาณข้อมูลขนาดใหญ่และความสามารถในการรวมกระบวนการคัดลอกเข้ากับเวิร์กโฟลว์การประสานไปป์ไลน์ที่กว้างขึ้นด้วยการพึ่งพาและการจัดการข้อผิดพลาด
David ตรวจสอบตัวเลือกที่พร้อมใช้งานและเลือกคัดลอกกิจกรรมในไปป์ไลน์ วิธีการนี้ช่วยให้เขามีการกําหนดค่าขั้นสูงและปรับแต่งได้อย่างเต็มที่ที่เขาต้องการรองรับการสืบค้นที่ผู้ใช้กําหนดสําหรับการแยกข้อมูลที่ซับซ้อนและให้การประสานตามไปป์ไลน์ที่จําเป็นสําหรับเวิร์กโฟลว์ของเขา ความสามารถในการตรวจสอบและตรวจสอบขั้นสูงช่วยให้เขาติดตามกระบวนการที่ซับซ้อน ในขณะที่เฟรมเวิร์กไปป์ไลน์ช่วยให้เขาประสานงานกิจกรรมการคัดลอกกับขั้นตอนการประมวลผลข้อมูลอื่นๆ
สถานการณ์สมมติที่ 4
Ash เป็นผู้จัดการผลิตภัณฑ์ของบริษัทโทรคมนาคมแห่งหนึ่ง ทีมของเธอจําเป็นต้องตรวจสอบตัวชี้วัดการสนับสนุนลูกค้า เช่น ปริมาณการโทร เวลารอ และประสิทธิภาพของเจ้าหน้าที่แบบเรียลไทม์ เพื่อให้แน่ใจว่าเป็นไปตาม SLA และปรับปรุงความพึงพอใจของลูกค้า ข้อมูลมาจากระบบปฏิบัติการที่หลากหลาย รวมถึงแพลตฟอร์ม CRM บันทึกคอลเซ็นเตอร์ และฐานข้อมูลการมอบหมายตัวแทน และมาถึงความถี่สูงตลอดทั้งวัน
Ash ใช้ Fabric Eventstreams เพื่อนําเข้าและแปลงข้อมูลนี้ในการเคลื่อนไหว เธอกําหนดค่าตัวเชื่อมต่อการสตรีมเพื่อดึงข้อมูลจากแหล่งต่างๆ ใช้การแปลงโดยใช้ประสบการณ์แบบไม่ใช้โค้ด และกําหนดเส้นทางเหตุการณ์ที่ประมวลผลไปยัง Eventhouse สําหรับการวิเคราะห์แบบเรียลไทม์ เธอผสานรวม Data Activator เพื่อทริกเกอร์การแจ้งเตือนและเวิร์กโฟลว์อัตโนมัติเมื่อมีการละเมิดเกณฑ์ SLA เพื่อให้เธอสามารถส่งการแจ้งเตือนไปยังหัวหน้างานหรือปรับระดับพนักงานแบบไดนามิกได้
ผลลัพธ์ที่ได้คือแดชบอร์ดแบบเรียลไทม์ที่อัปเดตภายในไม่กี่วินาที ทําให้ทีมของ Ash มองเห็นตัวชี้วัดประสิทธิภาพแบบสด และช่วยให้สามารถตัดสินใจได้อย่างรวดเร็วและขับเคลื่อนด้วยข้อมูล สถาปัตยกรรมการสตรีมนี้ช่วยลดเวลาแฝงของไปป์ไลน์แบบแบตช์และช่วยให้ธุรกิจสามารถตอบสนองความต้องการของลูกค้าได้ทันที
Get started
เมื่อคุณมีแนวคิดเกี่ยวกับกลยุทธ์การเคลื่อนย้ายข้อมูลที่จะใช้แล้ว คุณสามารถเริ่มต้นด้วยแหล่งข้อมูลเหล่านี้ได้: