แนวทางปฏิบัติที่ดีที่สุดสําหรับการมิเรอร์แบบเปิดใน Microsoft Fabric

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

เผยแพร่ไฟล์แบบอะตอม

สําหรับรูปแบบการเผยแพร่ที่ง่าย ให้อัปโหลดไฟล์เดียวในโฟลเดอร์ตารางของไฟล์นั้นโดยใช้ชื่อชั่วคราวที่ขีดล่างนําหน้า เช่น _00000000000000000042.parquet. หลังจากอัปโหลดเสร็จสิ้น ให้ใช้คําสั่งเปลี่ยนชื่อ Azure Data Lake Storage รุ่น2 เพื่อเปลี่ยนชื่อแบบอะตอมเป็นชื่อสุดท้าย เช่น 00000000000000000042.parquet.

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

ก่อนเปลี่ยนชื่อ ให้ตรวจสอบว่าไฟล์ Parquet หรือ CSV สมบูรณ์และถูกต้อง อย่าเผยแพร่ไฟล์ที่ไม่สมบูรณ์ เสียหาย หรือไฟล์ขนาดศูนย์ไบต์ ถือว่าเส้นทางสุดท้ายของโซนลงจอดทุกเส้นทางเป็นสิ่งที่เปลี่ยนแปลงไม่ได้:

• ห้ามเพิ่มหรือเขียนทับไฟล์ที่เผยแพร่
• อย่านําเส้นทางสุดท้ายกลับมาใช้ซ้ําสําหรับเนื้อหาอื่น

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

เลือกกลยุทธ์การตรวจจับไฟล์

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

สําหรับ SequentialFileName, อย่าข้าม ใช้ซ้ํา หรือถดถอยดัชนี ใช้รูปแบบการกู้คืนแบบตรวจสอบก่อนลองใหม่จาก ไฟล์ Publish แบบอะตอม ก่อนดําเนินการลําดับที่ทนทาน

LastUpdateTimeFileDetection ไม่ได้รับประกันว่าไฟล์จะถูกประมวลผลตามลําดับที่ผู้ผลิตคาดหวัง มันประมวลผลแต่ละชุดที่มองเห็นได้และยังไม่ได้ประมวลผลตามลําดับการจัดเก็บ LastModified ไม่ใช่ลําดับการผลิตหรือเวลาเหตุการณ์ เวลาประทับเท่ากันไม่มีการตัดสินแบบ tye-break แบบ producer-order ที่กําหนดไว้ ไฟล์ที่ล่าช้าสามารถประมวลผลหลังจากชุดไฟล์ใหม่ได้ และการเขียนทับเส้นทางที่ประมวลผลแล้วจะไม่ทําให้เส้นทางนั้นสามารถอ่านซ้ําได้ ทําให้ทุกเส้นทางไม่ซ้ํากันและไม่เปลี่ยนแปลง และอย่าใช้กลยุทธ์นี้เพื่อสรุปว่าทุกชุดข้อมูลต้นทางตรรกะมาถึงแล้ว

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

เก็บปุ่มรวมให้แคบ

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

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

การอัปเดตและการลบไม่ได้อัปเดตแถวข้อมูลก่อนหน้าที่มีอยู่จริง:

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

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

ปรับแต่งไฟล์ที่แทรกเท่านั้น

คอลัมน์จะ __rowMarker__ ระบุแต่ละแถวว่าเป็นการแทรก อัปเดต ลบ หรืออัพเซิร์ต สําหรับสตรีม Parquet แบบแทรกเท่านั้น ให้ละเว้น __rowMarker__ เมื่อสัญญามิเรอร์เปิดและกลยุทธ์การตรวจจับไฟล์ที่เลือกอนุญาต ไฟล์ Parquet ที่เข้าเกณฑ์โดยไม่มีปากกาสามารถใช้ direct staging ได้ ไฟล์ที่มีเครื่องหมายจะใช้เส้นทางการประมวลผลแบบแถว แม้ว่าทุกเครื่องหมายจะหมายถึงการแทรก

การพลาด __rowMarker__ เพียงอย่างเดียวไม่ได้หมายความว่าสตรีมนั้นเป็นแบบ append เท่านั้น การกําหนดค่าสามารถกําหนดการดําเนินการเริ่มต้น เช่น upsert เพื่อให้สัญญาที่เลือกกําหนดความหมายของข้อมูล อย่าลบมาร์กเกอร์ออกจากไฟล์ CSV หรือสตรีมที่สามารถอัปเดตหรือลบแถวได้

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

วางแผนการฟื้นฟู

หากไฟล์ขนาด 0 ไบต์ เสียหาย หรือไม่ถูกต้องไม่สามารถนําเข้าได้ ให้ลบไฟล์นั้นออกจาก OneLake และอัปโหลดไฟล์ทดแทนที่สมบูรณ์และถูกต้องโดยใช้ชื่อไฟล์เดียวกันทุกประการ สําหรับการตั้งชื่อแบบลําดับ ไฟล์ในภายหลังจะถูกบล็อกจนกว่าหมายเลขลําดับที่หายไปจะถูกกู้คืน ขั้นตอนนี้จะซ่อมแซมไฟล์ที่ล้มเหลว;จะไม่เล่นซ้ําไฟล์ที่ถูกประมวลผลไปแล้ว ไฟล์ Parquet ที่ถูกต้องซึ่งมีแถวศูนย์ไม่ใช่ไฟล์ศูนย์ไบต์และไม่จําเป็นต้องซ่อมแซม

วิธีเริ่มต้นตารางหนึ่งใหม่จากจุดเริ่มต้น:

1. ลบโฟลเดอร์โซนลงจอดทั้งหมดของตาราง
2. รอจนกว่าตารางจะหายไปจากฐานข้อมูลที่สะท้อน
3. สร้างโฟลเดอร์เดิมขึ้นมาใหม่ และอัปโหลดการตั้งค่าที่จําเป็นพร้อมโหลดเริ่มต้นที่ถูกต้องและสมบูรณ์
4. ดําเนินการเผยแพร่การเปลี่ยนแปลงแบบเพิ่มทีละน้อยต่อหลังจากที่ตารางปรากฏขึ้นอีกครั้ง

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

การเปลี่ยนแปลงสคีมาต้นทางพิกัด

ก่อนที่คุณจะเผยแพร่ข้อมูลหลังจากมีการเปลี่ยนแปลงภาษานิยามข้อมูลต้นทาง (DDL) ให้ตรวจสอบว่าสคีมาของไฟล์ต้นทางและไฟล์ลงจอดใหม่เข้ากันได้กับตารางปลายทางที่มีอยู่ การเปลี่ยนแปลงส่วนใหญ่จะดําเนินต่อไปตามกระบวนการเผยแพร่ปกติ เฉพาะการเปลี่ยนแปลงที่เสียหายเท่านั้นที่ต้องสร้างและโหลดตารางที่ได้รับผลกระทบใหม่

คอลัมน์คีย์จะถูกกําหนดหลังจากที่เมตาดาต้าในตารางประกาศแล้ว ดังนั้นควรวางแผนสร้างใหม่หากต้องเปลี่ยนคีย์ สําหรับข้อความที่มีการคั่น การกําหนดสคีมาที่ประกาศจะไม่รองรับการพัฒนาสคีมา

ในการสร้างตารางใหม่ ให้ทําตามขั้นตอนการเริ่มต้นใหม่ใน แผนการกู้คืน ใช้ Fabric REST API สําหรับฐานข้อมูลแบบมิเรอร์และระบบอัตโนมัติที่ใช้ PySpark เมื่อเหมาะสมเพื่อประสานงานการสร้างใหม่และตรวจสอบตารางปลายทางก่อนจะกลับมาเผยแพร่อีกครั้ง

ปฏิบัติตามข้อกําหนดเฉพาะของผู้ผลิต

Open mirroring กําหนดสัญญา landing zone ไม่ใช่วิธีที่ผู้ผลิตของคุณสร้างไฟล์ นักเขียนบุคคลที่สามจะเพิ่มข้อกําหนดเบื้องต้นของตนเอง ซึ่งโปรดิวเซอร์เป็นเจ้าของและจัดทําเอกสาร ตรวจสอบเอกสารสําหรับผู้ผลิตของคุณและระบบนิเวศของพันธมิตรมิเรอร์แบบเปิด

ยืนยันการตั้งค่าโซนลงจอดเหล่านี้สําหรับผู้ผลิตรายใดก็ได้:

• keyColumns: ประกาศคีย์สําหรับการอัปเดตและลบการสนับสนุน ละเว้นเฉพาะตารางที่แทรกเท่านั้น
• fileDetectionStrategy: เก็บค่าเริ่มต้นแบบลําดับเมื่อลําดับมีความสําคัญ ตั้งค่า LastUpdateTimeFileDetection เฉพาะชื่อไฟล์ที่ไม่เรียงลําดับเท่านั้น
• isUpsertDefaultRowMarker: ตั้งค่าเป็น true เมื่อแถวที่ไม่มีเครื่องหมายควรถูกมองว่าเป็น upsert แทน inserts
• _partnerEvents.json: เผยแพร่ไฟล์นี้ในระดับฐานข้อมูลมิเรอร์เพื่อระบุผู้ผลิตและประเภทต้นทาง

ตัวอย่างต่อไปนี้แสดงให้เห็นถึงสภาพแวดล้อมฝั่งโปรดิวเซอร์ที่นักเขียนเหล่านี้เปิดเผย เป็นของโปรดิวเซอร์ ดังนั้นควรยืนยันในเอกสารของโปรดิวเซอร์เองเสมอ

ออราเคิล โกลเด้นเกต 23ai

เอกสารของ Oracle จะถูกทําสําเนาเป็นฐานข้อมูลมิเรอร์ผ่าน GoldenGate สําหรับแอปพลิเคชันและการวิเคราะห์แบบกระจาย เพิ่ม Classic Replicat ตั้งค่าเป้าหมายเป็น Mirrored Database ใน Microsoft Fabric และเลือกการเชื่อมต่อ Fabric Mirror เป็นนามแฝง ปล่อยให้ตัวเลือกที่จัดการและพารามิเตอร์การจําลองข้อมูลเป็นค่าเริ่มต้น และตั้งค่าคุณสมบัติ gg.eventhandler.onelake.workspace ตัวจัดการเหตุการณ์ OneLake และ gg.eventhandler.onelake.mirror ชื่อพื้นที่ทํางานเป้าหมายและชื่อมิเรอร์ของคุณ

แผนที่ MongoDB

เอกสารของ MongoDB รันแอปพลิเคชันมิเรอร์บน Azure App Service หรือเครื่องเสมือน ดังนั้นโฮสต์จึงเป็นเงื่อนไขเบื้องต้นที่คุณต้องจัดเตรียม ยืนยันตัวตนกับ service principal ที่มีสิทธิ์ผู้ดูแลระบบในพื้นที่ทํางาน Fabric และให้ข้อมูล URI การเชื่อมต่อ Atlas, ชื่อฐานข้อมูล และรายการคอลเลกชันหรือคอลเลกชันทั้งหมดอย่างชัดเจน เพิ่มเครื่องหมายทับท้ายลงใน URL ของโซนลงจอดเมื่อคุณส่งไปยังแอปพลิเคชัน เนื่องจากแอปพลิเคชันจะทําการซิงโครไนซ์เริ่มต้นต่อคอลเลกชันก่อนที่จะติดตามการเปลี่ยนแปลง ให้กําหนดขนาดโฮสต์สําหรับโหลดเริ่มต้น;การทดสอบประสิทธิภาพระดับสูงของ MongoDB เองแนะนําให้ติดตามอัตราการส่งข้อมูลและ CPU เกินกว่าคอลเลกชันขนาดใหญ่ประมาณห้าชุด

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

รายการตรวจสอบการเผยแพร่และการกู้คืน