Предложен работен поток за сложна миграция на данни

Тази статия предлага стъпка по стъпка процес за мигриране на големи количества данни. Когато прехвърляте данни от мощен базиран на облак CRM, е важно да планирате внимателно поради сложната му настройка – като персонализирани обекти, връзки между данни и уникални идентификатори на записи. Трябва да обмислите както техническите стъпки, така и как миграцията работи на практика.

  • Технически подход: Обхваща ключови стъпки за миграция – извличане, трансформиране и зареждане на данни в Dataverse – като същевременно гарантира цялост, запазва взаимоотношенията и оптимизира производителността чрез валидиране и обработка на грешки.
  • Функционален подход: Обхваща задачи за функционална миграция като сегментиране и архивиране на данни и подчертава необходимостта от включване на заинтересованите страни в бизнеса, за да се гарантира, че данните отговарят на техните нужди.

Технически подход за миграция на данни

Осигурете плавна миграция, като следвате структуриран подход – извличайте, трансформирайте и зареждайте данни, като същевременно запазвате целостта и минимизирате прекъсванията.

Диаграма, илюстрираща работен поток за миграция на данни с шест взаимосвързани кръга като стъпки.

Извличане на данни от изходна към етапна база данни

За сложни миграции на данни препоръчваме да поставите данни в отделна база данни (например SQL Server). Тази етапна зона заснема моментна снимка на изходната система, без да нарушава текущите бизнес операции.

Основни съображения:

  • Пълно срещу делта натоварване: Организирайте данните като пълни или настъпкови (делта) натоварвания. Използвайте автоматично генерирани времеви маркери, за да проследявате пристигането на данни и да идентифицирате промените за бъдещи товари.
  • Обработка при отказ: Проектирайте процеса така, че да пропуска неуспешни записи (например поради дължина на полето, невалидни търсения), без да спирате миграцията. Регистрирайте и разрешете проблемите преди повторна обработка.
  • Съпоставяне на полета: Конвертирайте изходните стойности, за да съответстват на целевите формати в етапния слой и диапазоните на стойностите в индексната база данни, преди да мигрирате данните към Dataverse, за да подобрите ефективността.
  • Валидиране на данни: Изпълнете проверки за целост, за да откриете проблеми като липсващи препратки. Тъй като извличането на данни може да продължи часове или дни, използвайте етапния слой, за да филтрирате непълните записи и да осигурите последователност.
  • Визуализация на данни: Използвайте етапната база данни за одит и анализ на данни – например броене на записи или сумиране на финансови полета – преди окончателната миграция.

Трансформиране на данни в целева база данни

След като извлечете данни от изходната система, трансформирайте я в целева етапна база данни, която отразява схемата на Dataverse и съдържа стойности, готови за директно вмъкване или актуализиране.

Ключови стъпки за трансформация:

  • Картографиране на полето: Съпоставяне на изходните колони с насочване към колони на 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. Изрежете или коригирайте, ако е необходимо.

  • Изчисляеми полета: Добавете производни полета (например Име за справки), ако липсват в източника.

  • Друго съображение: Когато проектирате таблици, които да съответстват на схемата на Dataverse, вземете предвид следните ключови колони и поддържащи таблици.

    • DataMigration_CreatedDateTime: Автоматично попълнен времеви печат за проследяване на партидите за зареждане на данни.
    • Флаг за действие: Показва Вмъкване (I), Актуализиране (U) или Изтриване (D).
    • Флаг за обработка: Състояние на проследяване – Обработено (P), Необработено (U), Грешка (E) или Успешно (S).
    • Уникална графа: Използвайте уникален идентификатор (например уникалния идентификатор от изходната система), за да картографирате записи.
    • Таблици за успех/грешка: Поддържайте отделни таблици (например Contact_Success, Contact_Error), за да регистрирате резултатите и да поддържате повторни версии.

Таблици за последователност и търсения за предварително зареждане

След статични трансформации подредете таблиците си, за да намалите цикличните зависимости – случаи, в които таблиците препращат една към друга, което прави изолираното импортиране невъзможно. Използвайте този подход:

  • Избройте всички таблици, отговарящи на условията за мигриране.
  • Пребройте уникалните справки на таблица (игнорирайте готовите полета като Created By и други справки за таблица, ако не мигрирате).
  • Сортирайте таблиците във възходящ ред по брой справки.
  • Включете таблици за релации N:N, като отчитате и двете справки.
  • Изключете справките с множество таблици (например полета "относно").

Този подход определя последователността на натоварването на миграцията на данни и работи добре в повечето сценарии. За по-сложни случаи:

  • Използвайте уникален идентификатор (например importsequencenumber), за да съпоставите записите между staging и Dataverse, когато GUID се генерират по време на вмъкване.
  • Разделете регистрационните файлове за успех и грешки, за да избегнете проблеми със заключването и да подобрите производителността.
  • Предварително заредете справочни GUID от вече мигрирани таблици, за да разрешите препратки по време на вмъкване.
  • Работете с цикличните зависимости чрез:
    • Вмъкване на записи без зависими справки.
    • Актуализиране на тези справки след зареждане на свързани записи.

Зареждане на данни в Dataverse

Следващата стъпка е да определите и приложите вашия подход за зареждане на данни в Dataverse.

  1. Инструменти: Изберете инструмент въз основа на размера и сложността на данните:

    • Инструмент за мигриране на конфигурация на SDK
    • Azure Data Factory
    • КингсуейСофт
    • Писар
    • Транспортьорът на данни на XrmToolBox

  2. Ключови съображения (независими от инструментите):

    • Работете с циклични зависимости: Зареждайте таблицата на последователността, за да сведете до минимум кръговите търсения. Вмъквайте записи без зависими справки, след което ги актуализирайте по-късно.

    • ИД на записи на записи: Уловете GUID на Dataverse в таблица за успех, след което актуализирайте основната таблица с помощта на уникален идентификатор (например importsequencenumber).

    • Оптимизиране на размера на партидата и броя на нишките: Прегледайте указанията за оптимизиране на производителността за групови операции. Приложението, което използвате, трябва да управлява грешките в защитата на услугите, които възникват, когато извънреден брой заявки се изпращат до Dataverse. Ако напишете свой собствен код и използвате уеб API на Dataverse, не забравяйте да опитате отново 429 грешки, както е описано в Ограничения на API за защита на услугите. Ако използвате Dataverse SDK, той управлява тези грешки вместо вас.

      За да постигнете оптимална производителност, настройте размера на партидата и броя на резбите въз основа на сложността на таблицата:

      • Готови (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. Обработка на грешки: Не пренебрегвайте грешките – отстранете ги, за да предотвратите каскадни повреди. Използвайте настройки по подразбиране (например празни справки, стойности на набор от опции по подразбиране), за да вмъкнете записи на контейнери и да заснемате GUID.

  5. Актуализации на състоянието: Задайте активното състояние само по време на първоначалното вмъкване на записа. За неактивни записи или персонализирани кодове за състояние/състояние ги актуализирайте след проверка на данните. За повечето персонализирани таблици актуализациите на състоянието могат да следват веднага след вмъкването. Въпреки това, за специални таблици като "Случай", "Възможност" или "Потенциален клиент", отложете актуализациите на състоянието до края на миграцията. След като тези записи бъдат затворени, те не могат да бъдат променени, освен ако не бъдат отворени отново – отнемащ време процес, който застрашава целостта на данните.

  6. Собственост и сигурност: Задайте правилния собственик на записа по време на вмъкване на данни, тъй като защитата както на ниво потребител, така и на бизнес единицата в Dataverse са обвързани с бизнес единицата на собственика. Задайте правилната бизнес единица при създаването – актуализирането му след това премахва всички права за достъп.

    • Използвайте потребители на мъничета:
      • Dataverse поддържа потребители на мъничета (нелицензирани), които са полезни за големи или исторически миграции. На потребителите на мъниче автоматично се присвоява права за достъп на продавач – не преименувайте и не променяйте тази роля. Потребителите на мъничета могат да притежават записи, ако имат достъп за четене на ниво потребител до съответните таблици.
    • Препоръки:
      • Създайте всички нелицензирани потребители по време на миграцията с правилната бизнес единица, зададена по време на вмъкване.
      • Не променяйте бизнес единицата след създаването – това премахва всички роли, включително Salesman.
      • Уверете се, че ролята на продавач има достъп за четене до всички таблици, отговарящи на условията за миграция.
      • Дори потребители, деактивирани в средата на Dataverse с тази роля, могат да притежават записи.

  7. Обработка на валута: Задайте обменни курсове по време на вмъкване, като използвате плъгин за предварително потвърждение, тъй като Dataverse не поддържа исторически курсове.

Публикуване на зареждане на данни в Dataverse

След като заредите данни в Dataverse, следвайте тези стъпки, за да осигурите целостта на данните и да сведете до минимум проблемите надолу по веригата:

  1. Актуализирайте основната таблица с GUID:

    • След успешно зареждане копирайте GUID на записа на Dataverse от таблицата за успех в основната таблица, като използвате уникален идентификатор, като importsequencenumberнапример .
    • Актуализирайте флага за обработка, за да маркирате записите като:
      • P – Обработен
      • Д – Допусната грешка
      • U – Необработено Тази стратегия позволява ефективно повторение чрез пропускане на вече обработени записи и поддържа разрешаване на търсене при следващи зареждания.

  2. Опитайте отново неуспешни записи: За да намалите преработката и да поддържате целостта на препратките, помислете за следните действия:

    • Изрежете стойностите на низовете, ако надвишават разрешените дължини.
    • Приложете стойности на набора от опции по подразбиране, когато липсват съпоставяния.
    • Задайте резервен собственик, ако първоначалният собственик не е наличен (дори като потребител на мъниче).
    • Използвайте празни стойности или стойности по подразбиране за неразрешени справки.
    • Дори записите за контейнери могат да помогнат за генерирането на GUID, необходими за справки в свързани таблици.

Използване на еластични таблици за миграция на данни

Еластичните таблици са проектирани да обработват големи обеми данни в реално време. С еластичните таблици можете да импортирате, съхранявате и анализирате големи обеми данни без проблеми с мащабируемостта, латентността или производителността.

Еластичните таблици предлагат уникални възможности за гъвкава схема, хоризонтално мащабиране и автоматично премахване на данни след определен период от време.

Еластичните таблици се съхраняват в Azure Cosmos DB и поддържат:

  • Данни без схема чрез JSON колони
  • Автоматично хоризонтално мащабиране
  • Time-to-live (TTL) за автоматично изтриване на остарели данни
  • Разделяне за оптимизиране на производителността

Еластичните маси са най-подходящи за внос на едро с променлива схема.

Еластичните таблици са идеални за специфични типове данни.

Тип данни Описание
Необработени данни за поглъщане Извличайте регистрационни файлове, сензорни емисии или групов експорт от наследени системи. Например регистрационни файлове за взаимодействие с клиенти от наследен ERP, стари имейл нишки и билети за поддръжка от предишната система.
Полуструктурирани записи Данни с незадължителни или развиващи се полета, които не отговарят на твърда схема. Например формуляри за обратна връзка от клиенти с незадължителни полета или формуляри за регистрация на събития с персонализирани бележки или етикети.
Индексни данни за валидиране Временна зона за задържане преди синхронизиране на данни с релационни таблици. Например импортирани данни за потенциални клиенти, които чакат дедупликация и валидация, преди да бъдат добавени към основната таблица Потенциални клиенти.
Чувствителни към времето данни или изтичащи Използвайте TTL (Time-to-Live) за автоматично изтриване на временни CRM записи. Например промоционални кодове за отстъпка, свързани с кампания, връзки за еднократен достъп за клиентски проучвания или портали за въвеждане и временни отговори на анкети.
Разделени масивни данни Разделяйте данните по идентификатор или категория, за да подобрите производителността и мащабируемостта. Например разделяне по ИД на профил или регион по време на групово мигриране на данни или сегментиране на регистрационните файлове на активността на клиентите по ИД на кампанията за анализи.

Типове данни, неподходящи за еластични таблици

Еластичните таблици са оптимизирани за гъвкави сценарии с голям мащаб, но не всеки тип данни се вписва. Този раздел подчертава често срещани модели на CRM данни, които се съхраняват по-добре другаде, за да се гарантира производителност, рентабилност и поддръжка. Научете повече за функциите, които понастоящем не се поддържат с еластични таблици

Тип данни Причина
Силно релационни данни Еластичните таблици не поддържат съединения или търсения
Критични за бизнеса записи Няма цялост на транзакциите или поддръжка на плъгини
Данни, изискващи сложно валидиране По-добре се обработва в стандартни таблици с бизнес правила

Функционално сегментиране на данни и архивна рамка

Ефективното техническо планиране включва избор на правилните инструменти и инфраструктура, съгласуване на изходните и целевите обеми данни и настройка на процеси на одит и съгласуване. Много миграции стават сложни поради липса на предварителен анализ, особено за това какви данни трябва да се преместят и къде им е мястото. Този раздел очертава основните принципи на анализа на данни в подкрепа на успешната миграция.

Сегментиране на данни

Сегментирането на данни е ключова стъпка в мигрирането от една CRM система към Dataverse. Организирайте таблици с данни по бизнес функции – като продажби, обслужване или маркетинг – за да опростите планирането и изпълнението на миграцията.

Сегментиране на таблици

Започнете, като изброите всички таблици, отговарящи на условията за мигриране, групирани по бизнес област (например продажби, маркетинг, услуги). Тогава:

  • Документирайте схемата в Excel или подобен инструмент.
  • Изпълнете основни заявки в изходната система, за да проверите използването на колоните.
  • Маркирайте колони с ниска употреба. Ако по-малко от 5% записи съдържат стойности, консултирайте се със заинтересованите страни в бизнеса, за да решите дали да ги запазите или изхвърлите.

Този прост анализ може значително да намали обхвата на миграцията. В дългосрочните CRM системи е обичайно да се елиминират 30–40% колони и до 20% таблици, рационализирайки процеса и подобрявайки производителността.

Уместност на колоните

Някои изходни системни колони се съпоставят директно с Dataverse, докато други стават изчисляеми полета. Разделете тези графи и се консултирайте със заинтересованите страни в бизнеса, за да решите дали са необходими работни места в областта на миграцията.

Игнорирайте графите, които са подходящи само в системата източник или нямат смисъл в целта. Това включва много готови полета, като например "Създадено от", "Модифицирано от" или "Номер на версията на ред", освен ако не служат за конкретна цел във вашата миграция.

Данни за типове на файла

Ако вашата изходна система включва данни от файлов тип, маркирайте тези полета по-рано и планирайте отделна стратегия за миграция. Помислете за следните типове файлове:

  • Документи на Office (например Word, Excel, PowerPoint): За до 20 000 файла мигрирайте към платформа за сътрудничество като SharePoint, за да разрешите многопотребителски достъп.
  • Мултимедийни файлове (например изображения, видеоклипове): Изберете платформа, която поддържа възпроизвеждане. Опциите включват SharePoint, стрийминг услуги или други удобни за медии решения за съхранение.
  • Големи томове или размери на файлове: Ако разходите за съхранение са проблем, използвайте Azure Blob Storage или основната колона на файлове в Dataverse, която използва Azure BLOB зад кулисите.
  • Защита от злонамерен софтуер: Стартирайте файлове чрез инструмент за откриване на злонамерен софтуер (например Azure Advanced Threat Protection) преди миграцията, за да осигурите защита.

След като прегледате релевантността на файла, често откривате, че общият обем на данните спада значително – особено в дългосрочните CRM системи – което прави миграцията по-ефективна.

Стратегии за архивиране на данни

Някои данни – като стари имейли, затворени случаи или дисквалифицирани потенциални клиенти – остават важни, но рядко се достъпват. За да намалите обема на миграцията, без да нарушавате бизнес операциите, разработете интелигентна стратегия за архивиране.

Стъпка 1: Идентифицирайте архивируеми данни

Често срещаните кандидати включват:

  • Имейли на възраст над три години
  • Приключени дела
  • Пропуснати възможности
  • Дисквалифицирани потенциални клиенти
  • Маркетингови имейли, публикации и регистрационни файлове за одит

Прегледайте системата си, за да намерите други таблици, които можете да архивирате.

Стъпка 2: Изберете архивен подход

  • Съхранявайте данните в системата източник. Запазете няколко администраторски лиценза за достъп, докато деактивирате други, за да намалите разходите.
  • Преминете към външно хранилище. Използвайте локални бази данни, място за съхранение на BLOB в Azure или таблици на Azure, за да съхранявате архивирани записи. Този подход намалява разходите за съхранение и миграция, но изисква отделна стратегия за миграция.
  • Използвайте отделна среда на Dataverse. Тази опция е по-рядко срещана, но е полезна, ако искате да изолирате архивирани данни. Можете да оттеглите тази среда по-късно, за да опростите планирането на прекъсването.

За да осигурите бърза и надеждна миграция на данни в Dataverse:

  • Използвайте виртуална машина (VM) в същия регион като вашата среда на Dataverse, за да намалите латентността и да подобрите скоростта на миграция.
  • Изберете високопроизводителна виртуална машина. Използвайте най-малко D4 VM с осем ядра, 28 GB RAM и 500 GB памет, за да обработвате ефективно големи обеми данни.
  • Предпочитайте локална база данни на виртуалната машина. Избягвайте отдалечени връзки по време на миграцията. Ако използвате Azure Data Factory, разположите я в същия регион като вашата среда на Dataverse за оптимална производителност.

Следваща стъпка

Следвайте Power Platform Well-Architected за архитектурно съвършенство

  • Last updated on