เวิร์กโฟลว์ที่แนะนําสําหรับการโยกย้ายข้อมูลที่ซับซ้อน

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

• วิธีทางเทคนิค: ครอบคลุมขั้นตอนการโยกย้ายข้อมูลที่สําคัญ—แยก แปลง และโหลดข้อมูลลงใน Dataverse—ในขณะที่สร้างความสมบูรณ์ รักษาความสัมพันธ์ และปรับประสิทธิภาพให้เหมาะสมผ่านการตรวจสอบความถูกต้องและการจัดการข้อผิดพลาด
• วิธีการใช้งาน: ครอบคลุมงานการโยกย้ายข้อมูลที่ทํางาน เช่น การแบ่งเซกเมนต์ข้อมูลและการเก็บถาวร และเน้นความจําเป็นที่เกี่ยวข้องกับผู้เกี่ยวข้องทางธุรกิจเพื่อให้แน่ใจว่าข้อมูลตรงกับความต้องการของพวกเขา

วิธีทางเทคนิคสําหรับการโยกย้ายข้อมูล

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

แยกข้อมูลจากแหล่งข้อมูลไปยังฐานข้อมูลการจัดเตรียม

สําหรับการโยกย้ายข้อมูลที่ซับซ้อน เราขอแนะนําให้จัดเตรียมข้อมูลในฐานข้อมูลแยกต่างหาก (ตัวอย่างเช่น SQL Server) พื้นที่จัดเตรียมนี้จับภาพสแนปช็อตของระบบต้นทางโดยไม่รบกวนการดําเนินธุรกิจอย่างต่อเนื่อง

ข้อควรพิจารณาที่สําคัญ:

• การโหลดแบบเต็ม vs. การโหลดแบบเดลต้า: จัดระเบียบข้อมูลเป็นโหลดแบบเต็มหรือแบบค่อยๆ เพิ่ม (delta) ใช้ประทับเวลาที่สร้างขึ้นโดยอัตโนมัติเพื่อติดตามการมาถึงข้อมูลและระบุการเปลี่ยนแปลงสําหรับการโหลดในอนาคต
• การจัดการการเฟลโอเวอร์: ออกแบบกระบวนการเพื่อข้ามเรกคอร์ดที่ล้มเหลว (ตัวอย่างเช่น เนื่องจากความยาวของเขตข้อมูล การค้นหาที่ไม่ถูกต้อง) โดยไม่หยุดการโยกย้าย บันทึกและแก้ไขปัญหาก่อนประมวลผลอีกครั้ง
• การแมปเขตข้อมูล: แปลงค่าแหล่งข้อมูลเพื่อให้ตรงกับรูปแบบเป้าหมายในเลเยอร์การจัดเตรียมและช่วงค่าในฐานข้อมูลการจัดเตรียมก่อนที่จะโยกย้ายข้อมูลไปยัง Dataverse เพื่อปรับปรุงประสิทธิภาพ
• การตรวจสอบข้อมูล: เรียกใช้การตรวจสอบความสมบูรณ์เพื่อตรวจจับปัญหา เช่น การอ้างอิงหายไป เนื่องจากการสกัดข้อมูลอาจครอบคลุมหลายชั่วโมงหรือวันให้ใช้เลเยอร์สเตจเพื่อกรองบันทึกที่ไม่สมบูรณ์และรับประกันความสอดคล้อง
• การแสดงภาพข้อมูล: ใช้ฐานข้อมูลการกําหนดขั้นเพื่อตรวจสอบและวิเคราะห์ข้อมูล —ตัวอย่างเช่น นับจํานวนระเบียนหรือผลรวมเขตข้อมูลทางการเงินก่อนการโยกย้ายขั้นสุดท้าย

แปลงข้อมูลลงในฐานข้อมูลการกําหนดระยะเป้าหมาย

หลังจากที่คุณแยกข้อมูลจากระบบต้นทางแล้ว ให้แปลงเป็นฐานข้อมูลการกําหนดระยะเป้าหมายที่สะท้อน Schema Dataverse และมีค่าที่พร้อมสําหรับการแทรกหรืออัปเดตโดยตรง

ขั้นตอนการแปลงข้อมูลหลัก:

• การแมปเขตข้อมูล: แมปคอลัมน์ต้นทางไปยังเป้าหมายคอลัมน์ Dataverse ใช้สคริปต์เพื่อรวมและผสานตารางเมื่อจําเป็น

• การแปลงชุดตัวเลือก: แปลงค่าชุดตัวเลือกแบบยึดข้อความเป็นจํานวนเต็มผกผันโดยใช้ตารางการแมป (ตัวอย่างเช่น OptionSetMapping) และคิวรีการอัปเดตจํานวนมาก สร้างตารางเพื่อกําหนดมาตรฐานและทําให้การแปลงค่าชุดตัวเลือกจากต้นทางเป็นระบบเป้าหมายเป็นไปโดยอัตโนมัติ

  ตาราง: OptionSetMapping

  ชื่อคอลัมน์	ชนิดข้อมูล
  ชื่อตารางต้นทาง	สตริง
  ชื่อตารางเป้าหมาย	สตริง
  ข้อความต้นทาง	สตริง
  ข้อความเป้าหมาย	สตริง
  ค่าเป้าหมาย	สตริง

  ใช้ตาราง OptionSetMapping เพื่อแปลงและอัปเดตค่าชุดตัวเลือกเป็นกลุ่มได้อย่างมีประสิทธิภาพ ตัวอย่างเช่น เมื่อต้องการอัปเดตค่าชุดตัวเลือกทั้งหมดในตารางผู้ติดต่อตามค่าข้อความที่ตรงกัน:

  Update C.\<OptionsetValue\> = M.\<TargetValue\> 
  FROM Contact C 
  JOIN OptionsetMapping M 
    ON C.OptionsetText = M.TargetText 
    AND M.TargetTableName = 'Contact'
  

• หลีกเลี่ยง GUID แบบกําหนดเอง: ให้ Dataverse สร้าง GUID เพื่อป้องกันปัญหาการกระจัดกระจายและประสิทธิภาพการทํางาน

• การตรวจสอบความยาวสตริง: ตรวจสอบให้แน่ใจว่าค่าสตริงพอดีกับขีดจํากัด Dataverse ตัดแต่งหรือปรับตามความจําเป็น

• เขตข้อมูลที่คํานวณ: เพิ่มเขตข้อมูลที่ได้รับมา (ตัวอย่างเช่น ชื่อสําหรับการค้นหา) ถ้าขาดหายไปในแหล่งข้อมูล

• ข้อควรพิจารณาอื่น ๆ: เมื่อออกแบบตารางให้ตรงกับ Schema Dataverse ให้พิจารณาคอลัมน์คีย์ต่อไปนี้และตารางที่สนับสนุน

  • DataMigration_CreatedDateTime: ประทับเวลาอัตโนมัติสําหรับการติดตามชุดการโหลดข้อมูล
  • ค่าสถานะการดําเนินการ: ระบุว่าแทรก (I), อัปเดต (U) หรือลบ (D)
  • ค่าสถานะการประมวลผล: ติดตามสถานะ—ประมวลผล (P), ยังไม่ได้ประมวลผล (U), ข้อผิดพลาด, หรือสําเร็จ (S)
  • คอลัมน์ที่ไม่ซ้ํากัน: ใช้ ID เฉพาะ (ตัวอย่างเช่น ID เฉพาะจากระบบต้นทาง) เพื่อแมปเรกคอร์ด
  • ตารางความสําเร็จ/ข้อผิดพลาด: รักษาตารางแยกต่างหาก (ตัวอย่างเช่น Contact_Success, Contact_Error) เพื่อบันทึกผลลัพธ์และสนับสนุนการลองใหม่

ตารางลําดับและการค้นหาข้อมูลล่วงหน้า

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

• แสดงตารางทั้งหมดที่มีสิทธิสําหรับการโยกย้าย
• นับจํานวนการค้นหาที่ไม่ซ้ํากันต่อตาราง (ละเว้นเขตข้อมูลนอกกรอบ เช่น Created By และการค้นหาตารางอื่น ๆ ถ้าไม่โยกย้าย)
• เรียงลําดับตารางจากน้อยไปหามากตามจํานวนการค้นหา
• รวมตารางความสัมพันธ์แบบ N:N โดยนับจํานวนการค้นหาทั้งสองรายการ
• ไม่รวมการค้นหาแบบหลายตาราง (ตัวอย่างเช่น เขตข้อมูล "ที่เกี่ยวข้อง")

วิธีการนี้จะกําหนดลําดับของการโหลดการโยกย้ายข้อมูลและทํางานได้ดีในสถานการณ์ส่วนใหญ่ สําหรับกรณีที่ซับซ้อนมากขึ้น:

• ใช้ตัวระบุที่ไม่ซ้ํากัน (ตัวอย่างเช่น importsequencenumber) เพื่อจับคู่เรกคอร์ดระหว่างการจัดเตรียมและ Dataverse เมื่อมีการสร้าง GUID ในระหว่างการแทรก
• แยกบันทึกความสําเร็จและข้อผิดพลาดเพื่อหลีกเลี่ยงปัญหาการล็อคและปรับปรุงประสิทธิภาพการทํางาน
• โหลดล่วงหน้า GUID ที่ค้นหาจากตารางที่ได้ย้ายข้อมูลแล้วเพื่อแก้ไขการอ้างอิงในระหว่างการแทรก
• จัดการการอ้างอิงแบบวงจรโดย:
  • การแทรกเรกคอร์ดโดยไม่มีการค้นหาแบบพึ่งพา
  • การอัปเดตการค้นหาเหล่านั้นหลังจากโหลดเรกคอร์ดที่เกี่ยวข้องแล้ว

โหลดข้อมูลลงใน Dataverse

ขั้นตอนถัดไปคือการกําหนดและใช้วิธีการของคุณในการโหลดข้อมูลลงใน Dataverse

1. การใช้เครื่องมือ: เลือกเครื่องมือตามขนาดและความซับซ้อนของข้อมูล:

   • เครื่องมือการโยกย้ายการกําหนดค่า SDK
   • Azure Data Factory
   • KingswaySoft
   • เครื่องมือบันทึก
   • ตัวขนส่งข้อมูลของ XrmToolBox

2. ข้อควรพิจารณาหลัก (ไม่ยึดติดกับเครื่องมือเฉพาะใด):

   • จัดการการขึ้นต่อกันแบบวงจร: โหลดตารางลําดับเพื่อลดการค้นหาแบบวงกลม แทรกระเบียนโดยไม่มีการค้นหาที่ขึ้นกับกันก่อน แล้วค่อยอัปเดตในภายหลัง

   • ติดตาม ID ระเบียน: จับ GUID ของ Dataverse ในตารางความสําเร็จ จากนั้นอัปเดตตารางหลักโดยใช้ตัวระบุที่ไม่ซ้ํากัน (ตัวอย่างเช่น importsequencenumber)

   • ปรับขนาดของชุดงานและจํานวนเธรดให้เหมาะสม: ตรวจสอบคําแนะนําเพื่อปรับประสิทธิภาพให้เหมาะสมสําหรับการดําเนินการจํานวนมาก แอปพลิเคชันที่คุณใช้ต้องจัดการข้อผิดพลาดการป้องกันบริการที่เกิดขึ้นเมื่อมีการส่งคําขอจํานวนพิเศษไปยัง Dataverse หากคุณเขียนโค้ดของคุณเองและใช้ Dataverse Web API ตรวจสอบให้แน่ใจว่าคุณได้ลอง 429 ข้อผิดพลาดอีกครั้งตามที่อธิบายไว้ใน ขีดจํากัด API การป้องกันบริการ ถ้าคุณใช้ SDK Dataverse จะจัดการข้อผิดพลาดเหล่านี้ให้คุณ

     เพื่อให้ได้ประสิทธิภาพที่เหมาะสมที่สุด ให้ปรับแต่งขนาดของชุดงานและจํานวนเธรดตามความซับซ้อนของตาราง:

     • ตารางแบบนอกกรอบ (OOB) (ตัวอย่างเช่น Contact, Account, Lead): ตารางเหล่านี้ช้าลงเนื่องจากปลั๊กอินและงานที่มีอยู่ภายใน แนะนำ: ขนาดชุดงาน 200-300, แนะนำให้ใช้ไม่เกิน 30 เธรด (หากมีการค้นหาไม่เกิน 10 รายการ และ 50-70 คอลัมน์)
     • ตารางแบบง่าย (มีการค้นหาน้อยหรือไม่มีเลย): แนะนำ: ขนาดแบตช์ควร ≤10, เธรดสูงสุด 50 เธรด
     • ตารางแบบกําหนดเองที่มีความซับซ้อนปานกลาง (การค้นหา): แนะนํา: ขนาดของชุดงาน≤100, สูงสุด 30 เธรด
     • ตารางขนาดใหญ่/ซับซ้อน (>100 คอลัมน์, >การค้นหา 20 รายการ): แนะนํา: ขนาดชุดงาน 10-20, สูงสุด 10–20 เธรดเพื่อลดข้อผิดพลาด

3. เคล็ดลับโครงสร้างพื้นฐาน: หากต้องการเพิ่มประสิทธิภาพการโยกย้ายข้อมูลให้สูงสุด ให้เรียกใช้การโยกย้ายของคุณจากเครื่องเสมือน (VM) ซึ่งอยู่ในภูมิภาคเดียวกันกับสภาพแวดล้อม Dataverse ของคุณ วิธีนี้ช่วยลดเวลาแฝงและเพิ่มความเร็วของกระบวนการทั้งหมดได้อย่างมาก เรียนรู้วิธีการกําหนดภูมิภาคของสภาพแวดล้อม Dataverse ของคุณ

4. การจัดการข้อผิดพลาด: อย่าเพิกเฉยต่อข้อผิดพลาด - แก้ไขปัญหาเพื่อป้องกันความล้มเหลวที่เกี่ยวข้อง ใช้ค่าเริ่มต้น (ตัวอย่างเช่น การค้นหาที่ว่างเปล่า ค่าชุดตัวเลือกเริ่มต้น) เพื่อแทรกเรกคอร์ดตัวแทน (placeholder) และเก็บรักษา GUID

5. การอัปเดตสถานะ: ตั้งค่าสถานะที่ใช้งานอยู่ในระหว่างการแทรกเรกคอร์ดเริ่มต้นเท่านั้น สําหรับเรกคอร์ดที่ไม่ได้ใช้งานหรือรหัสสถานะ/สถานะแบบกําหนดเอง ให้อัปเดตหลังจากการตรวจสอบข้อมูล สําหรับตารางแบบกําหนดเองส่วนใหญ่ การอัปเดตสถานะสามารถติดตามได้ทันทีหลังจากแทรก อย่างไรก็ตาม สําหรับตารางพิเศษ เช่น Case, Opportunity หรือ Lead การอัปเดตสถานะการหน่วงเวลาจนถึงจุดสิ้นสุดของการโยกย้าย เมื่อปิดระเบียนเหล่านี้แล้ว จะไม่สามารถแก้ไขเว้นแต่จะเปิดใหม่อีกครั้ง ซึ่งเป็นกระบวนการที่ใช้เวลานานซึ่งมีความเสี่ยงต่อความสมบูรณ์ของข้อมูล

6. ความเป็นเจ้าของและความปลอดภัย: ตั้งค่าเจ้าของเรกคอร์ดที่ถูกต้องในระหว่างการแทรกข้อมูล เนื่องจากทั้งระดับผู้ใช้และความปลอดภัยของหน่วยธุรกิจใน Dataverse จะผูกกับหน่วยธุรกิจของเจ้าของ กำหนดหน่วยธุรกิจที่ถูกต้องในขณะสร้าง—ถ้ามีการอัปเดตหลังจากนั้นจะลบบทบาทความปลอดภัยทั้งหมดออก

   • ใช้ ผู้ใช้ที่เป็นตัวแทน:
     • Dataverse สนับสนุนผู้ใช้ stub (ไม่มีสิทธิ์การใช้งาน) ซึ่งมีประโยชน์สําหรับการโยกย้ายข้อมูลขนาดใหญ่หรือในอดีต ผู้ใช้ Stub จะได้รับบทบาทความปลอดภัยของพนักงานขายโดยอัตโนมัติ ไม่ต้องเปลี่ยนชื่อหรือปรับเปลี่ยนบทบาทนี้ ผู้ใช้ Stub สามารถเป็นเจ้าของเรกคอร์ดได้ถ้าพวกเขามีการเข้าถึงแบบอ่านระดับผู้ใช้ในตารางที่เกี่ยวข้อง
   • คําแนะนํา:
     • สร้างผู้ใช้ที่ไม่มีใบอนุญาตทั้งหมดในระหว่างการโยกย้ายโดยกำหนดชุดหน่วยธุรกิจที่ถูกต้องในขณะทำการแทรก
     • อย่าเปลี่ยนหน่วยธุรกิจหลังจากสร้าง เนื่องจากการทำเช่นนั้นจะเป็นการลบบทบาททั้งหมด รวมถึงบทบาทของพนักงานขายด้วย
     • ตรวจสอบให้แน่ใจว่าบทบาทพนักงานขายได้อ่านการเข้าถึงตารางที่มีสิทธิ์ในการโยกย้ายทั้งหมดแล้ว
     • แม้แต่ผู้ใช้ที่ถูกปิดใช้งานในสภาพแวดล้อม Dataverse ที่มีบทบาทนี้สามารถเป็นเจ้าของระเบียนได้

7. การจัดการสกุลเงิน: การตั้งค่าอัตราแลกเปลี่ยนในระหว่างการแทรกโดยใช้ปลั๊กอินการ prevalidation เนื่องจาก Dataverse ไม่สนับสนุนอัตราในอดีต

โพสต์โหลดข้อมูลลงใน Dataverse

หลังจากโหลดข้อมูลลงใน Dataverse แล้ว ให้ทําตามขั้นตอนเหล่านี้เพื่อให้แน่ใจว่าข้อมูลมีความสมบูรณ์และลดปัญหาสตรีม:

1. อัปเดตตารางหลักด้วย GUID:

   • หลังจากโหลดสําเร็จ ให้คัดลอก GUID ของระเบียน Dataverse จากตารางความสําเร็จลงในตารางหลักโดยใช้ตัวระบุที่ไม่ซ้ํากัน เช่นimportsequencenumber
   • ปรับปรุงค่าสถานะการประมวลผลเพื่อทําเครื่องหมายระเบียนเป็น:
     • P – ประมวลผลแล้ว
     • – เกิดข้อผิดพลาด
     • U – ยังไม่ได้ประมวลผล กลยุทธ์นี้จะทําให้สามารถเรียกใช้ซ้ําที่มีประสิทธิภาพได้ โดยข้ามระเบียนที่ประมวลผลแล้ว และสนับสนุนการแก้ปัญหาการค้นหาในการโหลดในภายหลัง

2. ลองอีกครั้งกับระเบียนที่ล้มเหลว: เพื่อลดการทําใหม่และรักษาความถูกต้องของการอ้างอิง ให้พิจารณาการดําเนินการเหล่านี้:

   • ตัดแต่งค่าสตริงหากเกินความยาวที่อนุญาต
   • ใช้ค่าชุดตัวเลือกค่าเริ่มต้นเมื่อการแมปหายไป
   • กำหนดตัวแทนเจ้าของในกรณีที่เจ้าของเดิมไม่พร้อมใช้งาน (แม้แต่ในรูปแบบผู้ใช้ชั่วคราว)
   • ใช้ค่าว่างหรือค่าเริ่มต้นสําหรับการค้นหาที่ยังไม่ได้แก้ไข
   • แม้แต่บันทึกข้อความตัวอย่างก็สามารถช่วยสร้าง GUID ที่จําเป็นสําหรับการค้นหาในตารางที่เกี่ยวข้องได้

การใช้ตารางแบบยืดหยุ่นสําหรับการโยกย้ายข้อมูล

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

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

ตารางแบบยืดหยุ่นจะถูกเก็บไว้ใน Azure Cosmos DB และการสนับสนุน:

• ข้อมูล Schema-less ในคอลัมน์ JSON
• การปรับมาตราส่วนแนวนอนอัตโนมัติ
• Time-to-live (TTL) สําหรับการลบข้อมูลเก่าโดยอัตโนมัติ
• การแบ่งพาร์ติชันสําหรับการปรับประสิทธิภาพให้เหมาะสม

ตารางแบบยืดหยุ่นเหมาะที่สุดสําหรับการนําเข้าจํานวนมากที่มี Schema ตัวแปร

ชนิดข้อมูลที่แนะนําสําหรับตารางแบบยืดหยุ่นในระหว่างการโยกย้ายข้อมูล

ตารางแบบยืดหยุ่นเหมาะสําหรับชนิดข้อมูลที่เฉพาะเจาะจง

ชนิดข้อมูลที่ไม่เหมาะสมสําหรับตารางแบบยืดหยุ่น

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

การแบ่งส่วนข้อมูลและเฟรมเวิร์กการเก็บถาวรที่ใช้งานได้

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

การแบ่งเซ็กเมนต์ข้อมูล

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

การแบ่งเซกเมนต์ตาราง

เริ่มต้นโดยการแสดงรายการตารางทั้งหมดที่มีคุณสมบัติเหมาะสมสําหรับการโยกย้าย ซึ่งจัดกลุ่มตามพื้นที่ธุรกิจ (ตัวอย่างเช่น การขาย การตลาด บริการ) จากนั้น:

• จัดทําเอกสาร Schema ใน Excel หรือเครื่องมือที่คล้ายกัน
• เรียกใช้คิวรีพื้นฐานในระบบต้นทางเพื่อตรวจสอบการใช้งานคอลัมน์
• ตั้งค่าสถานะคอลัมน์ที่มีการใช้งานน้อย ถ้าระเบียนน้อยกว่า 5% รายการมีค่า ให้ปรึกษาผู้เกี่ยวข้องทางธุรกิจเพื่อตัดสินใจว่าจะเก็บหรือละทิ้งเรกคอร์ดเหล่านั้น

การวิเคราะห์อย่างง่ายนี้สามารถลดขอบเขตการโยกย้ายได้อย่างมาก ในระบบ CRM ที่ใช้เวลานาน เป็นเรื่องปกติที่จะกําจัดคอลัมน์ 30-40% และตารางสูงสุด 20% ทําให้กระบวนการนี้มีประสิทธิภาพขึ้นและปรับปรุงประสิทธิภาพ

ความเกี่ยวข้องของคอลัมน์

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

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

ข้อมูลประเภทไฟล์

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

• เอกสาร Office (ตัวอย่างเช่น Word, Excel, PowerPoint): โยกย้ายข้อมูลไปยังแพลตฟอร์มการทํางานร่วมกันได้สูงสุด 20,000 ไฟล์ เช่น SharePoint เพื่อเปิดใช้งานการเข้าถึงแบบผู้ใช้หลายคน
• ไฟล์มัลติมีเดีย (ตัวอย่างเช่น รูปภาพ วิดีโอ): เลือกแพลตฟอร์มที่สนับสนุนการเล่น ตัวเลือกประกอบด้วย SharePoint บริการสตรีมมิ่ง หรือโซลูชันการจัดเก็บที่เป็นมิตรกับสื่ออื่น ๆ
• ปริมาณขนาดใหญ่หรือขนาดไฟล์: หากค่าใช้จ่ายในการจัดเก็บเป็นเรื่องที่ต้องคํานึงถึง ให้ใช้ Azure Blob Storage หรือคอลัมน์ไฟล์เนทีฟใน Dataverse ซึ่งใช้ Azure Blob อยู่เบื้องหลังฉาก
• การป้องกันมัลแวร์: เรียกใช้ไฟล์ผ่านเครื่องมือตรวจจับมัลแวร์ (ตัวอย่างเช่น การป้องกันภัยคุกคามขั้นสูงของ Azure) ก่อนการโยกย้ายเพื่อให้แน่ใจในเรื่องความปลอดภัย

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

กลยุทธ์การเก็บถาวรข้อมูล

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

ขั้นตอนที่ 1: ระบุข้อมูลแบบเก็บถาวร

ผู้สมัครทั่วไปประกอบด้วย:

• อีเมลที่เก่ากว่าสามปี
• กรณีที่ปิดแล้ว
• โอกาสที่พลาดไป
• ลูกค้าเป้าหมายที่ไม่เข้าเกณฑ์
• อีเมลทางการตลาด โพสต์ และบันทึกการตรวจสอบ

ตรวจสอบระบบของคุณเพื่อระบุตารางอื่นที่คุณสามารถเก็บถาวรได้

ขั้นตอนที่ 2: เลือกวิธีการเก็บถาวร

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

โครงสร้างพื้นฐานการโยกย้ายข้อมูลที่แนะนํา

เพื่อให้แน่ใจว่าการโยกย้ายข้อมูลที่รวดเร็วและเชื่อถือได้ลงใน Dataverse:

• ใช้เครื่องเสมือน (VM) ในภูมิภาคเดียวกันกับสภาพแวดล้อม Dataverse ของคุณเพื่อลดเวลาแฝงและปรับปรุงความเร็วในการโยกย้าย
• เลือกเครื่องเสมือนประสิทธิภาพสูง อย่างน้อยที่สุด ให้ใช้ D4 VM ที่มีแปดแกน RAM 28 GB และที่เก็บข้อมูล 500 GB เพื่อจัดการกับข้อมูลขนาดใหญ่ได้อย่างมีประสิทธิภาพ
• ต้องการฐานข้อมูลภายในเครื่องบน VM หลีกเลี่ยงการเชื่อมต่อระยะไกลระหว่างการโยกย้าย ถ้าคุณใช้ Azure Data Factory ให้ปรับใช้ในภูมิภาคเดียวกันกับสภาพแวดล้อม Dataverse ของคุณเพื่อประสิทธิภาพสูงสุด

ขั้นตอนถัดไป