หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
ข้อจํากัดปัจจุบันในฐานข้อมูลมิเรอร์ Microsoft Fabric จาก Snowflake แสดงอยู่ในหน้านี้ หน้านี้อาจเปลี่ยนแปลงได้
ข้อจํากัดในการเชื่อมต่อและการรับรองความถูกต้อง
- ตารางต่อไปนี้แสดงรายการวิธีการรับรองความถูกต้องที่รองรับการมิเรอร์สําหรับ Snowflake:
| วิธีการรับรองความถูกต้อง | ได้รับการสนับสนุน | หมายเหตุ |
|---|---|---|
| ชื่อผู้ใช้และรหัสผ่าน | ใช่ | การรับรองความถูกต้องแบบเนทีฟของ Snowflake |
| Microsoft Entra ID (SSO) | ใช่ | การลงชื่อเพียงครั้งเดียวผ่าน Entra ID |
| การรับรองความถูกต้องของคู่คีย์ | ใช่ | คู่คีย์ RSA สําหรับสถานการณ์บัญชีบริการ |
| ข้อมูลประจําตัวของพื้นที่ทํางาน | ไม่ใช่ | ขณะนี้ยังไม่รองรับ Snowflake |
ขณะนี้ข้อมูลประจําตัวของพื้นที่ทํางานไม่ได้รับการสนับสนุนสําหรับการสะท้อนเกล็ดหิมะ พร้อมใช้งานสําหรับแหล่งข้อมูลที่เลือก เช่น SharePoint
การเชื่อมต่อ Private Link ระหว่างพื้นที่ทํางาน Fabric และ Snowflake ยังไม่พร้อมใช้งาน ใช้เกตเวย์ข้อมูลเครือข่ายเสมือนหรือเกตเวย์ข้อมูลภายในองค์กรสําหรับการเชื่อมต่อส่วนตัวในระหว่างนี้
คุณต้องเพิ่มผู้รับการแชร์ไปยังพื้นที่ทํางาน เมื่อต้องการแชร์ชุดข้อมูลหรือรายงาน ก่อนอื่นให้เพิ่ม access ไปยังพื้นที่ทํางานด้วยบทบาทของผู้ดูแลระบบ สมาชิก ผู้อ่าน หรือผู้สนับสนุน
การคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่: ตัวระบุ Snowflake ทั้งหมด รวมถึงชื่อคลังสินค้า ชื่อฐานข้อมูล ชื่อสคีมา ชื่อตาราง และชื่อมุมมอง จะคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เมื่อกําหนดค่าการเชื่อมต่อการมิเรอร์และเมื่อใช้ REST API การมิเรอร์ ตัวพิมพ์ใหญ่ที่คุณป้อนใน Fabric ต้องตรงกับสิ่งที่กําหนดค่าไว้ใน Snowflake ทุกประการ ตัวพิมพ์ใหญ่ที่ไม่ตรงกันอาจทําให้เกิดความล้มเหลวในการเชื่อมต่อหรือตารางไม่ปรากฏขึ้นสําหรับการจําลองแบบ ซึ่งมักจะไม่มีข้อความแสดงข้อผิดพลาดที่อธิบาย ตัวอย่างเช่น ถ้าคลังสินค้า Snowflake ของคุณมีชื่อว่า ANALYTICS_WH คุณต้องป้อน ANALYTICS_WH ในการเชื่อมต่อ Fabric ไม่ใช่ analytics_wh
ชนิดวัตถุที่รองรับ
- ตารางต่อไปนี้แสดงรายการประเภทออบเจ็กต์ Snowflake ที่รองรับการมิเรอร์:
| ชนิดของวัตถุ | ได้รับการสนับสนุน | หมายเหตุ |
|---|---|---|
| ตารางที่มีการจัดการ | ใช่ | รองรับการจําลองแบบอย่างเต็มที่ |
| ตารางภูเขาน้ําแข็ง | ใช่ | ต้องมีการเชื่อมต่อที่เก็บข้อมูลกับที่เก็บข้อมูลตาราง Iceberg ที่อยู่ด้านล่าง เฉพาะตาราง Iceberg ที่สามารถเข้าถึงได้ผ่านการเชื่อมต่อที่เก็บข้อมูลเดียวกันเท่านั้นที่สามารถมิเรอร์เข้าด้วยกันได้ |
| Views | ใช่ | รองรับการซิงค์ทุกๆ 12 ชั่วโมง |
| มุมมองที่เป็นเนื้อหา | ใช่ | รองรับการซิงค์ทุกๆ 12 ชั่วโมง |
| ตารางภายนอก | ไม่ใช่ | ไม่รองรับ |
| ตารางชั่วคราว | ไม่ใช่ | ไม่รองรับ |
| ตารางชั่วคราว | ไม่ใช่ | ไม่รองรับ |
| ตารางแบบไดนามิก | ไม่ใช่ | ไม่รองรับ |
การจําลองแบบและข้อจํากัดของข้อมูล
- หากไม่มีการอัปเดตในตารางต้นทาง กลไก replicator จะเริ่มถอยหลังด้วยระยะเวลาที่เพิ่มขึ้นแบบทวีคูณสําหรับตารางนั้น สูงสุดหนึ่งชั่วโมง สิ่งเดียวกันนี้อาจเกิดขึ้นได้หากมีข้อผิดพลาดชั่วคราว ซึ่งขัดขวางการรีเฟรชข้อมูล กลไก replicator จะกลับมาสํารวจตามปกติโดยอัตโนมัติหลังจากตรวจพบข้อมูลที่อัปเดต
- ลําดับชั้น Schema ต้นทางถูกจําลองแบบไปยังฐานข้อมูลที่มิเรอร์ สําหรับฐานข้อมูลมิเรอร์ที่สร้างขึ้นก่อนเปิดใช้งานคุณลักษณะนี้ สคีมาต้นทางจะถูกลดรูปแบบ และชื่อ Schema ถูกเข้ารหัสลับเป็นชื่อตาราง ถ้าคุณต้องการจัดระเบียบตารางด้วย Schema ใหม่ ให้สร้างฐานข้อมูลแบบมิเรอร์ของคุณใหม่ เรียนรู้เพิ่มเติมจากลําดับชั้น Schema ต้นทางที่จําลองแบบ
- การทําสําเนาสนับสนุนการจําลองแบบคอลัมน์ที่มีช่องว่างหรืออักขระพิเศษในชื่อ (เช่น
,;{}()\n\t=) สําหรับตารางภายใต้การจําลองแบบก่อนเปิดใช้งานคุณลักษณะนี้ คุณจําเป็นต้องอัปเดตการตั้งค่าฐานข้อมูลแบบมิเรอร์หรือรีสตาร์ทการมิเรอร์เพื่อรวมคอลัมน์เหล่านั้น เรียนรู้เพิ่มเติมจากการสนับสนุนการแมปคอลัมน์ Delta - จํานวนโต๊ะสูงสุดที่สามารถสะท้อนไปยัง Fabric ได้คือ 1,000 โต๊ะ ตารางใดๆ ที่สูงกว่าขีดจํากัด 1000 ไม่สามารถทําซ้ําได้ในขณะนี้
- ถ้าคุณเลือก มิเรอร์ข้อมูลทั้งหมด เมื่อกําหนดค่ามิเรอร์ ตารางที่จะมิเรอร์จะถูกกําหนดโดยการนําตาราง 1,000 ตารางแรกเมื่อตารางทั้งหมดถูกเรียงลําดับตามตัวอักษรตามชื่อ Schema และชื่อตาราง ชุดตารางที่เหลือที่ด้านล่างของรายการตามตัวอักษรจะไม่ถูกสะท้อนทับ
- ถ้าคุณยกเลิกการเลือก มิเรอร์ข้อมูลทั้งหมด และเลือกแต่ละตาราง คุณจะถูกป้องกันไม่ให้เลือกตารางมากกว่า 1,000 ตาราง
- คอลัมน์จากการคํานวณและตารางจากการคํานวณ: ฐานข้อมูลที่มิเรอร์เป็นแบบอ่านอย่างเดียว คุณไม่สามารถสร้างคอลัมน์จากการคํานวณหรือตารางจากการคํานวณได้โดยตรงบนฐานข้อมูลที่มิเรอร์ หากต้องการเพิ่มคอลัมน์จากการคํานวณ ให้สร้าง Lakehouse และใช้ทางลัดเพื่ออ้างอิงข้อมูลที่มิเรอร์ จากนั้นสร้างคอลัมน์จากการคํานวณของคุณใน Lakehouse โดยใช้สมุดบันทึกหรือ SQL
ข้อจํากัดด้านประสิทธิภาพ
- ถ้าคุณกําลังเปลี่ยนแปลงข้อมูลส่วนใหญ่ในตารางขนาดใหญ่ การหยุดและเริ่มการสะท้อนใหม่จะมีประสิทธิภาพมากกว่า การแทรกหรืออัปเดตระเบียนหลายพันล้านระเบียนอาจใช้เวลานาน
- การเปลี่ยนแปลง Schema บางอย่างจะไม่แสดงให้เห็นในทันที การเปลี่ยนแปลง Schema บางอย่างจําเป็นต้องมีการเปลี่ยนแปลงข้อมูล (แทรก อัปเดต หรือลบ) ก่อนที่การเปลี่ยนแปลง Schema จะถูกจําลองแบบไปยัง Fabric
- ข้อควรพิจารณาข้ามรีเจี้ยน: หากอินสแตนซ์ Snowflake และความจุ Fabric ของคุณอยู่ในรีเจี้ยนระบบคลาวด์ที่แตกต่างกัน คุณอาจพบเวลาแฝงในการจําลองแบบและค่าบริการขาออกของข้อมูลที่สูงขึ้น เพื่อประสิทธิภาพสูงสุดและเพื่อหลีกเลี่ยงค่าใช้จ่ายขาออกข้ามรีเจี้ยน ให้ปรับใช้ความจุ Fabric ของคุณในรีเจี้ยนระบบคลาวด์เดียวกันกับอินสแตนซ์ Snowflake ของคุณ หากไม่สามารถหลีกเลี่ยงการปรับใช้ข้ามภูมิภาคได้ ให้คํานึงถึงค่าธรรมเนียมขาออกเพิ่มเติมจาก Snowflake และ/หรือ Azure ดูรายละเอียดในเอกสารประกอบทางออกของ Snowflake
- เมื่อมิเรอร์ข้อมูลจาก Snowflake ไปยัง OneLake ของลูกค้า โดยปกติกระบวนการจะจัดเตรียมข้อมูลผ่าน URL แบบอินไลน์เพื่อปรับปรุงประสิทธิภาพ ถ้าพารามิเตอร์ระดับบัญชี Snowflake PREVENT_UNLOAD_TO_INLINE_URL ถูกตั้งค่าเป็นจริง ลักษณะการทํางานต่อไปนี้จะมีผลบังคับใช้:
| วิธีการเชื่อมต่อ | ผลกระทบเมื่อ PREVENT_UNLOAD_TO_INLINE_URL = จริง |
|---|---|
| โดยตรง (ปลายทางสาธารณะ) | การสะท้อนกลับไปอ่านโดยตรงจาก Snowflake การสํารองนี้ส่งผลให้เวลาในการจําลองแบบช้าลงและเพิ่มความเสี่ยงของการหมดเวลาการเชื่อมต่อ โดยเฉพาะอย่างยิ่งสําหรับชุดข้อมูลขนาดใหญ่ |
| เกตเวย์ข้อมูล เครือข่ายเสมือน (VNet) | การสะท้อนถูกบล็อกโดยสิ้นเชิง สถานการณ์เกตเวย์ VNet ไม่สามารถใช้การอ่านโดยตรง และต้องการเส้นทางการจัดเตรียม URL แบบอินไลน์ |
| เกตเวย์ข้อมูลภายในองค์กร (OPDG) | การสะท้อนถูกบล็อกโดยสิ้นเชิง สถานการณ์ OPDG ไม่สามารถใช้การอ่านโดยตรงและต้องใช้เส้นทางการจัดเตรียม URL แบบอินไลน์ |
การแก้ปัญหาที่วางแผนไว้: การสนับสนุนการรวมที่เก็บข้อมูลอยู่ระหว่างการพัฒนา และจะจัดเตรียมเส้นทางการแสดงละครทางเลือกที่ใช้งานได้เมื่อตั้งค่า PREVENT_UNLOAD_TO_INLINE_URL เป็นจริง โซลูชันนี้ปลดบล็อกสถานการณ์ VNet และ OPDG ตรวจสอบหน้านี้เพื่อดูข้อมูลอัปเดตเกี่ยวกับความพร้อมให้บริการ
-
พฤติกรรมการเพาะเมล็ดใหม่: การป้อนข้อมูลใหม่คือการโหลดข้อมูลใหม่ทั้งหมดของทั้งตาราง ซึ่งแตกต่างจากการซิงค์แบบเพิ่มหน่วย (ซึ่งประมวลผลเฉพาะแถวที่เปลี่ยนแปลง) การ reseed จะอ่านซ้ําและเขียนข้อมูลทั้งหมดในตารางอีกครั้ง การเพาะเมล็ดใหม่อาจมีต้นทุนการคํานวณเกล็ดหิมะจํานวนมาก โดยเฉพาะอย่างยิ่งสําหรับโต๊ะขนาดใหญ่
- สิ่งที่กระตุ้นให้เกิดการเพาะเมล็ดใหม่:
| ทริกเกอร์ | คำอธิบาย |
|---|---|
| การเปลี่ยนแปลง DDL | การเปลี่ยนแปลง DDL ใดๆ ที่แก้ไขการประทับเวลา DDL ของตารางจะทริกเกอร์การ reseed ทริกเกอร์นี้รวมถึงคําสั่ง ALTER TABLE ที่เพิ่ม วาง หรือเปลี่ยนชื่อคอลัมน์ เปลี่ยนชนิดข้อมูล หรือปรับเปลี่ยนคุณสมบัติของตาราง |
| เครื่องมือแก้ไขสคีมา (เช่น DBT) | หากเครื่องมือเช่น DBT แก้ไขคําจํากัดความของตารางตามกําหนดการที่เกิดซ้ํา (ตัวอย่างเช่น ผ่านการเรียกใช้ dbt ซึ่งดรอปและสร้างตารางใหม่) การเรียกใช้เครื่องมือเหล่านี้บ่อยๆ (ตัวอย่างเช่น ทุกๆ สองสามนาที) อาจทําให้เกิดการวนซ้ําการเพาะซ้ําอย่างต่อเนื่อง |
| การหยุดและเริ่มการสะท้อนใหม่ | ทุกครั้งที่คุณหยุดและเริ่มการสะท้อนใหม่ทั้งตารางจะถูกดึงข้อมูลอีกครั้งตั้งแต่เริ่มต้น |
| ขยายการหยุดความจุชั่วคราว | หากความจุของ Fabric หยุดชั่วคราวเป็นระยะเวลานาน การมิเรอร์อาจเกิดขึ้นใหม่ตั้งแต่ต้นเมื่อกลับมาทํางานต่อ ดูการเปลี่ยนแปลงความจุของ Fabric |
- แนวทางปฏิบัติที่ดีที่สุดในการหลีกเลี่ยงการเพาะเมล็ดใหม่ที่ไม่จําเป็น:
- กําหนดเวลาการเปลี่ยนแปลง Schema นอกการมิเรอร์ที่ใช้งานอยู่ หากคุณใช้ DBT หรือเครื่องมือการจัดการ Schema อื่นๆ ให้กําหนดเวลาระหว่างกรอบเวลาการบํารุงรักษาหรือหยุดการมิเรอร์ชั่วคราวก่อนที่จะเรียกใช้การเปลี่ยนแปลง Schema
- หลีกเลี่ยงการดัดแปลง DDL บ่อยครั้ง รวมการเปลี่ยนแปลง Schema เป็นชุดงานที่น้อยลงและใหญ่ขึ้นแทนที่จะทําการเปลี่ยนแปลงที่เพิ่มขึ้นตลอดทั้งวัน
- ตรวจสอบการเพาะเมล็ดใหม่ที่ไม่คาดคิด บน หน้า สถานะการสะท้อน ให้ดูตารางที่แสดงลักษณะการคัดลอกเริ่มต้นซ้ําๆ หากตารางขนาดใหญ่มีการเพาะเมล็ดใหม่ทุกๆ สองสามนาที ให้ตรวจสอบการเปลี่ยนแปลง DDL อัปสตรีม
- ระวังผลกระทบด้านต้นทุน การ reseed ของตาราง 226 ล้านแถว (~26.5 GB) ใช้เวลาในการคํานวณอย่างมาก คูณต้นทุนนี้ด้วยความถี่ของการเปลี่ยนแปลง Schema เพื่อประเมินผลกระทบด้านต้นทุน
ข้อจํากัดด้านความปลอดภัย
- Fabric ไม่ได้จําลองนโยบาย Snowflake Row-Level Security (RLS) และ Column-Level Security (CLS) คุณต้องกําหนดค่านโยบายความปลอดภัยที่เทียบเท่าใน Fabric ใหม่ด้วยตนเอง
- ต้องเพิ่มผู้รับการแชร์ลงในพื้นที่ทํางาน เมื่อต้องการแชร์ชุดข้อมูลหรือรายงาน ก่อนอื่นให้เพิ่ม access ไปยังพื้นที่ทํางานด้วยบทบาทของผู้ดูแลระบบ สมาชิก ผู้อ่าน หรือผู้สนับสนุน
ข้อควรพิจารณาเกี่ยวกับค่าใช้จ่ายและการเรียกเก็บเงิน
เพื่อลดต้นทุนการประมวลผลของ Snowflake จากการมิเรอร์ ให้พิจารณาแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้:
- นําคลังสินค้าที่มีอยู่กลับมาใช้ใหม่ แทนที่จะสร้างคลังสินค้าเฉพาะสําหรับการมิเรอร์ ให้กําหนดค่าการมิเรอร์เพื่อใช้คลังสินค้าเดียวกันกับที่แอปพลิเคชันของคุณใช้อยู่แล้วเพื่ออัปเดตตารางต้นทาง วิธีนี้ช่วยหลีกเลี่ยงการปลุกคลังสินค้าโดยไม่จําเป็นและรอบการระงับอัตโนมัติ เมื่อแอปพลิเคชันของคุณอัปเดตตาราง ตัวจําลองการมิเรอร์จะรับการเปลี่ยนแปลงเกือบจะในทันทีในขณะที่คลังสินค้ายังคงทํางานอยู่ บางองค์กรอาจต้องการคลังสินค้าเฉพาะสําหรับการแยกงบประมาณ ตัวเลือกนี้เป็นการแลกเปลี่ยนระหว่างการประหยัดต้นทุนและความละเอียดของงบประมาณ
- สะท้อนเฉพาะตารางที่คุณต้องการ การมิเรอร์ฐานข้อมูลทั้งหมดอาจทําให้การใช้ Snowflake สูงโดยไม่คาดคิดและความจุของ Fabric พุ่งสูงขึ้น เริ่มต้นด้วยการเลือกเฉพาะตารางที่จําเป็นสําหรับสถานการณ์การวิเคราะห์ของคุณ คุณสามารถเพิ่มตารางในภายหลังได้ตามต้องการ
- ตรวจสอบการเพาะเมล็ดใหม่ที่ไม่คาดคิด การ reseed (การโหลดข้อมูลใหม่ทั้งหมด) จะประมวลผลทั้งตารางและก่อให้เกิดต้นทุนการประมวลผลตามสัดส่วนของขนาดตาราง การเปลี่ยนแปลงสคีมา รวมถึงการเปลี่ยนแปลงที่ทริกเกอร์โดยเครื่องมือเช่น DBT อาจทําให้เกิดการเพาะเมล็ดใหม่อย่างต่อเนื่อง ตรวจสอบหน้า สถานะการมิเรอร์ สําหรับตารางที่แสดงลักษณะการทํางานของการคัดลอกครั้งแรกซ้ําๆ และตรวจสอบส่วน การ Reseeding สําหรับทริกเกอร์และคําแนะนําในการแก้ไขปัญหา
- โปรดทราบว่าการสะท้อนจะทํางานอย่างต่อเนื่อง การสะท้อนภาพไม่สนับสนุนหน้าต่างการจัดกําหนดการหรือการจําลองแบบในขณะนี้ ตัวจําลองจะสํารวจการเปลี่ยนแปลงอย่างต่อเนื่อง ซึ่งสร้างการใช้งานการประมวลผล Snowflake อย่างต่อเนื่อง วางแผนงบประมาณ Snowflake ของคุณให้เหมาะสม
ภูมิภาคที่รองรับ
การมิเรอร์ฐานข้อมูลและการมิเรอร์แบบเปิดจะพร้อมใช้งานในภูมิภาค Microsoft Fabric ทั้งหมด สําหรับข้อมูลเพิ่มเติม ดู ความพร้อมใช้งานของภูมิภาค Fabric