Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule przedstawiono szczegółowy proces migracji dużych ilości danych. Podczas przesyłania danych z zaawansowanego systemu CRM opartego na chmurze ważne jest dokładne zaplanowanie ze względu na jego złożoną konfigurację — na przykład obiekty niestandardowe, linki między danymi i unikatowymi identyfikatorami rekordów. Należy przemyśleć zarówno kroki techniczne, jak i sposób działania migracji w praktyce.
- Podejście techniczne: obejmuje kluczowe kroki migracji — wyodrębnianie, przekształcanie i ładowanie danych do usługi Dataverse — przy jednoczesnym zapewnieniu integralności, zachowaniu relacji i optymalizacji wydajności dzięki walidacji i obsłudze błędów.
- Podejście funkcjonalne: Obejmuje funkcjonalne zadania migracji, takie jak segmentacja danych i archiwizowanie, oraz podkreśla potrzebę zaangażowania uczestników projektu biznesowego w celu zapewnienia, że dane spełniają ich potrzeby.
Podejście techniczne do migracji danych
Zapewnij bezproblemową migrację, postępując zgodnie ze strukturą — wyodrębnianie, przekształcanie i ładowanie danych przy jednoczesnym zachowaniu integralności i zminimalizowaniu zakłóceń.
Ekstrakcja danych ze źródła do przejściowej bazy danych
W przypadku złożonych migracji danych zalecamy przemieszczanie danych w oddzielnej bazie danych (na przykład programu SQL Server). Ten obszar przejściowy przechwytuje migawkę systemu źródłowego bez zakłócania bieżących operacji biznesowych.
Kluczowe kwestie:
- Pełne a obciążenie różnicowe: organizowanie danych jako pełnych lub przyrostowych (różnicowych) obciążeń. Użyj automatycznie wygenerowanych sygnatur czasowych, aby śledzić przybycie danych i identyfikować zmiany dla przyszłych obciążeń.
- Obsługa przełączania awaryjnego: zaprojektuj proces pomijania rekordów, które zakończyły się niepowodzeniem (na przykład z powodu długości pola, nieprawidłowych odwołań) bez zatrzymywania migracji. Rejestruj i rozwiąż problemy przed ponownym przetworzeniem.
- Mapowanie pól: Przekonwertuj wartości źródłowe na formaty docelowe w warstwie przejściowej oraz zakresy wartości w przejściowej bazie danych przed migracją danych do usługi Dataverse, aby poprawić efektywność.
- Walidacje danych: uruchom kontrole integralności, aby przechwycić problemy, takie jak brakujące odwołania. Ponieważ wyodrębnianie danych może obejmować wiele godzin lub dni, użyj warstwy przejściowej, aby filtrować niekompletne rekordy i zapewnić spójność.
- Wizualizacja danych: użyj przejściowej bazy danych do przeprowadzania inspekcji i analizowania danych — na przykład zliczanie rekordów lub sumowanie pól finansowych — przed ostateczną migracją.
Przekształcanie danych w docelową tymczasową bazę danych
Po wyodrębnieniu danych z systemu źródłowego przekształć je w docelową tymczasową bazę danych, która dubluje schemat Dataverse i zawiera wartości gotowe do bezpośredniego wstawiania lub aktualizowania.
Kluczowe kroki przekształcania:
Mapowanie pól: Przyporządkuj kolumny źródłowe do kolumn docelowych Dataverse. Użyj skryptów, aby sprzężć i scalić tabele w razie potrzeby.
Konwersja zestawu opcji: Konwertowanie wartości zestawu opcji opartych na tekście na liczby całkowite usługi Dataverse przy użyciu tabeli mapowania (na przykład OptionSetMapping) i zapytań aktualizacji zbiorczych. Utwórz tabelę w celu standaryzacji i zautomatyzowania przekształcania wartości zestawu opcji ze źródła do systemów docelowych.
Tabela: OptionSetMapping
Nazwa kolumny Typ danych Nazwa tabeli źródłowej ciąg Nazwa tabeli docelowej ciąg Tekst źródeł ciąg Tekst docelowy ciąg Wartość docelowa ciąg Użyj tabeli OptionSetMapping, aby efektywnie przekształcać i aktualizować wartości zestawu opcji zbiorczo. Aby na przykład zaktualizować wszystkie wartości zestawu opcji w tabeli Kontakt na podstawie pasujących wartości tekstowych:
Update C.\<OptionsetValue\> = M.\<TargetValue\> FROM Contact C JOIN OptionsetMapping M ON C.OptionsetText = M.TargetText AND M.TargetTableName = 'Contact'Unikaj niestandardowych identyfikatorów GUID: Niech usługa Dataverse generuje identyfikatory GUID, aby zapobiec problemom z fragmentacją i wydajnością.
Sprawdzanie długości ciągu: Upewnij się, że wartości ciągów pasują do limitów usługi Dataverse. Przycinanie lub dostosowywanie zgodnie z potrzebami.
Pola obliczeniowe: W przypadku braku w źródle dodaj pola pochodne (na przykład Nazwa dla odnośników).
Inne kwestie: podczas projektowania tabel w celu dopasowania do schematu usługi Dataverse należy wziąć pod uwagę następujące kluczowe kolumny i tabele pomocnicze.
- DataMigration_CreatedDateTime: automatycznie wypełniony znacznik czasu do śledzenia partii ładowania danych.
- Flaga akcji: wskazuje wstawianie (I), aktualizację (U) lub usuwanie (D).
- Flaga przetwarzania: Śledzi status—Przetworzone (P), Nieprzetworzone (U), Błąd (E) lub Sukces (S).
- Unikatowa kolumna: użyj unikatowego identyfikatora (na przykład unikatowego identyfikatora z systemu źródłowego) do mapowania rekordów.
- Tabele powodzenia/błędu: Obsługa oddzielnych tabel (na przykład Contact_Success, Contact_Error) w celu rejestrowania wyników i obsługi ponownych prób.
Tabele sekwencji i tabele wyszukiwania wstępnego ładowania
Po przekształceniach statycznych porządkuj tabele, aby zmniejszyć cykliczne zależności — przypadki, w których tabele odwołują się do siebie nawzajem, co uniemożliwia izolowane importowanie. Użyj tego podejścia:
- Sporządź listę wszystkich tabel kwalifikujących się do migracji.
- Zlicz unikatowe wyszukiwania na tabelę (ignoruj gotowe pola, takie jak
Created Byoraz inne wyszukiwania w tabelach, jeśli nie są migrowane). - Sortuj tabele w kolejności rosnącej według liczby wyszukiwań.
- Uwzględnij tabele relacji N:N, zliczając oba wyszukiwania.
- Wyklucz wyszukiwania w wielu tabelach (np. pola "dotyczy").
To podejście definiuje sekwencję obciążenia migracji danych i działa dobrze w większości scenariuszy. W przypadku bardziej złożonych przypadków:
- Użyj unikatowego identyfikatora (na przykład importsequencenumber), aby dopasować rekordy między obszarem roboczym a usługą Dataverse, gdy identyfikatory GUID są generowane podczas wstawiania.
- Oddzielaj dzienniki powodzenia i błędów, aby uniknąć problemów z blokowaniem i poprawiać wydajność.
- Wstępne ładowanie identyfikatorów GUID używanych do wyszukiwania z już zmigrowanych tabel, aby rozwiązać odwołania podczas wstawiania.
- Obsługa zależności cyklicznych poprzez:
- Wstawianie rekordów bez zależnościowych wyszukiwań.
- Aktualizowanie tych wyszukań po załadowaniu powiązanych rekordów.
Ładowanie danych do usługi Dataverse
Następnym krokiem jest określenie i zaimplementowanie podejścia do ładowania danych do usługi Dataverse.
Narzędzia: wybierz narzędzie na podstawie rozmiaru i złożoności danych:
- Narzędzie do migracji konfiguracji zestawu SDK
- Azure Data Factory
- KingswaySoft
- Skryba
- Transporter danych XrmToolBox
Kluczowe zagadnienia (niezależne od narzędzi):
Obsługa zależności cyklicznych: sekwencyjne ładowanie tabeli w celu zminimalizowania zapętleń. Wstaw rekordy bez zależnych odnośników, a następnie zaktualizuj je później.
Identyfikatory rekordów śledzenia: zapisz identyfikatory GUID platformy Dataverse w tabeli rezultatów, a następnie zaktualizuj tabelę główną przy użyciu unikatowego identyfikatora (na przykład importsequencenumber).
Optymalizuj rozmiar partii i liczbę wątków: zapoznaj się ze wskazówkami dotyczącymi optymalizacji wydajności przy operacjach zbiorczych. Używana aplikacja musi zarządzać błędami ochrony usługi, które występują, gdy do usługi Dataverse są wysyłane niezwykłe liczby żądań. Jeśli napiszesz własny kod i użyjesz internetowego interfejsu API usługi Dataverse, pamiętaj, aby ponowić próbę błędów 429 zgodnie z opisem w temacie Limity interfejsu API ochrony usługi. Jeśli używasz Dataverse SDK, zarządza błędami za Ciebie.
Aby uzyskać optymalną wydajność, dostosuj rozmiar partii i liczbę wątków w oparciu o złożoność tabeli:
- Tabele dostępne od ręki (OOB) (na przykład Contact, Account, Lead): Te tabele działają wolniej z powodu wbudowanych wtyczek i zadań. Zalecane: Rozmiar partii 200 – 300, do 30 wątków (jeśli ≤10 wyszukiwań i 50 – 70 kolumn).
- Proste tabele (kilka lub brak wyszukiwań): Zalecenie: rozmiar partii ≤10, maksymalnie 50 wątków.
- Umiarkowanie złożone tabele niestandardowe (niektóre wyszukiwania): Zalecane: rozmiar partii ≤100, maksymalnie 30 wątków.
- Duże/złożone tabele (>100 kolumn, >20 odnośników): Zalecane: Rozmiar partii 10–20, maksymalnie 10–20 wątków, aby zmniejszyć liczbę błędów.
Porady dotyczące infrastruktury: Aby zmaksymalizować wydajność migracji danych, uruchom migrację z maszyny wirtualnej znajdującej się w tym samym regionie co środowisko usługi Dataverse. Takie podejście znacznie zmniejsza opóźnienie i przyspiesza cały proces. Dowiedz się, jak określić region środowiska Dataverse.
Obsługa błędów: nie ignoruj błędów — rozwiąż je, aby zapobiec awariom kaskadowymi. Użyj wartości domyślnych (na przykład pustych odnośników, domyślnych wartości zestawu opcji), aby wstawić rekordy zastępcze i pozyskać identyfikatory GUID.
Aktualizacje stanu: ustaw tylko stan aktywny podczas początkowego wstawiania rekordu. W przypadku nieaktywnych rekordów lub niestandardowych kodów stanu/stanu zaktualizuj je po weryfikacji danych. W przypadku większości tabel niestandardowych aktualizacje stanu mogą następować natychmiast po wstawieniu. Jednak w przypadku tabel specjalnych, takich jak Case, Opportunity lub Lead, opóźnij aktualizacje stanu do końca migracji. Po zamknięciu tych rekordów nie można ich modyfikować, chyba że zostaną ponownie otwarte — czasochłonny proces, który ryzykuje integralność danych.
Własność i zabezpieczenia: ustanów prawidłowego właściciela rekordu podczas wstawiania danych, ponieważ zarówno zabezpieczenia na poziomie użytkownika, jak i jednostki biznesowej w usłudze Dataverse są powiązane z jednostką biznesową właściciela. Przypisz odpowiednią jednostkę biznesową podczas tworzenia — jej późniejsza aktualizacja spowoduje usunięcie wszystkich ról bezpieczeństwa.
-
Użyj użytkowników stuba:
- Usługa Dataverse obsługuje użytkowników tymczasowych (nielicencjonowanych), którzy są przydatni w przypadku migracji dużych lub historycznych. Użytkownicy tymczasowi są automatycznie przypisywani do roli zabezpieczeń Przedstawiciela Handlowego i nie należy zmieniać ani modyfikować tej roli. Użytkownicy stuba mogą posiadać rekordy, jeśli mają dostęp do odczytu na poziomie użytkownika do tych tabel.
-
Zalecenia:
- Utwórz wszystkich użytkowników bez licencji podczas migracji z poprawnie ustawioną jednostką biznesową w czasie wstawiania.
- Nie zmieniaj jednostki biznesowej po utworzeniu — powoduje to usunięcie wszystkich ról, w tym sprzedawcy.
- Upewnij się, że rola Salesperson ma dostęp do odczytu do wszystkich tabel kwalifikujących się do migracji.
- Nawet użytkownicy wyłączeni w środowisku Dataverse z tą rolą mogą być właścicielami rekordów.
-
Użyj użytkowników stuba:
Obsługa walut: Ustaw kursy wymiany podczas wstawiania danych przy użyciu wtyczki prewalidacyjnej, ponieważ Dataverse nie obsługuje historycznych kursów.
Ładowanie danych do usługi Dataverse
Po załadowaniu danych do usługi Dataverse wykonaj następujące kroki, aby zapewnić integralność danych i zminimalizować problemy podrzędne:
Zaktualizuj tabelę główną z użyciem identyfikatorów GUID:
- Po pomyślnym załadowaniu skopiuj identyfikatory GUID rekordów Dataverse z Tabeli sukcesu do Tabeli głównej, używając unikatowego identyfikatora, takiego jak
importsequencenumber. - Zaktualizuj flagę przetwarzania, aby oznaczyć rekordy jako:
- P — przetworzone
- E — błąd
- U — nieprzetworzona ta strategia umożliwia wydajne ponowne uruchamianie przez pomijanie już przetworzonych rekordów i obsługuje rozpoznawanie odnośników w kolejnych obciążeniach.
- Po pomyślnym załadowaniu skopiuj identyfikatory GUID rekordów Dataverse z Tabeli sukcesu do Tabeli głównej, używając unikatowego identyfikatora, takiego jak
Ponawianie nieudanych rekordów: Aby zmniejszyć konieczność powtórnej pracy i zachować spójność odniesień, rozważ następujące działania:
- Przycinaj ciągi, jeśli przekraczają dozwolone długości.
- Zastosuj domyślne wartości zestawu opcji, gdy brakuje mapowań.
- Przypisz właściciela rezerwowego, jeśli pierwotny właściciel nie jest dostępny (nawet jako użytkownik tymczasowy).
- Użyj pustych lub domyślnych wartości dla nierozwiązanych wyszukiwań.
- Nawet rekordy zastępcze mogą pomóc w generowaniu identyfikatorów GUID potrzebnych do wyszukiwania w powiązanych tabelach.
Używanie tabel elastycznych na potrzeby migracji danych
Elastyczne tabele są przeznaczone do obsługi dużych ilości danych w czasie rzeczywistym. Dzięki tabelom elastycznym można importować, zapisywać i analizować duże ilości danych bez problemów ze skalowalnością, opóźnieniami lub wydajnością.
Tabele elastyczne oferują unikatowe możliwości elastycznego schematu, skalowania w poziomie i automatycznego usuwania danych po określonym przedziale czasu.
Tabele elastyczne są przechowywane w usłudze Azure Cosmos DB i obsługują:
- Dane bez schematu za pośrednictwem kolumn JSON
- Automatyczne skalowanie w poziomie
- Czas życia (TTL) danych do automatycznego usuwania nieaktualnych danych
- Partycjonowanie na potrzeby optymalizacji wydajności
Tabele elastyczne najlepiej nadają się do importowania zbiorczego ze schematem zmiennych.
Zalecane typy danych dla tabel elastycznych podczas migracji danych
Elastyczne tabele są idealne dla określonych typów danych.
| Typ danych | Description |
|---|---|
| Pozyskiwanie surowych danych | Dzienniki źródłowe, źródła danych z czujników lub eksporty masowe ze starszych systemów. Na przykład dzienniki interakcji klienta ze starszej wersji ERP, ze starych wątków poczty e-mail oraz zgłoszenia wsparcia technicznego z poprzedniego systemu ERP. |
| Częściowo ustrukturyzowane rekordy | Dane z opcjonalnymi lub ewoluującymi polami, które nie pasują do sztywnego schematu. Na przykład formularze opinii klientów z opcjonalnymi polami lub formularzami rejestracji zdarzeń z niestandardowymi notatkami lub tagami. |
| Dane przejściowe na potrzeby walidacji | Tymczasowa strefa przechowywania przed zsynchronizowaniem danych z tabelami relacyjnymi. Na przykład zaimportowane dane potencjalnych klientów oczekujące na deduplikację i walidację przed dodaniu ich do głównej tabeli Potencjalnych klientów. |
| Dane wrażliwe na czas lub wygasające | Użyj TTL (czas życia) do automatycznego usuwania tymczasowych rekordów CRM. Na przykład kody rabatowe promocyjne powiązane z kampanią, jednorazowe linki dostępu do ankiet klientów lub portali onboardingowych oraz tymczasowe odpowiedzi na ankiety. |
| Partycjonowane dane zbiorcze | Partycjonowanie danych według identyfikatora lub kategorii w celu zwiększenia wydajności i skalowalności. Na przykład podziel partycję według identyfikatora konta lub identyfikatora regionu podczas migracji zbiorczej danych lub segmentuj dzienniki aktywności klientów według identyfikatora kampanii na potrzeby analizy. |
Typy danych nieodpowiednie dla tabel elastycznych
Elastyczne tabele są zoptymalizowane pod kątem elastycznych scenariuszy o dużej skali, ale nie każdy typ danych pasuje. W tej sekcji omówiono typowe wzorce danych CRM, które są lepiej przechowywane gdzie indziej, aby zapewnić wydajność, koszty i łatwość konserwacji. Dowiedz się więcej o funkcjach, które nie są obecnie obsługiwane w przypadku tabel elastycznych
| Typ danych | Przyczyna |
|---|---|
| Wysoce relacyjne dane | Tabele elastyczne nie obsługują sprzężeń ani odwołań |
| Rekordy krytyczne dla działania firmy | Brak wsparcia dla integralności transakcyjnej i obsługi wtyczek |
| Dane wymagające złożonej weryfikacji | Lepiej obsługiwane w standardowych tabelach z regułami biznesowymi |
Funkcjonalna struktura segmentacji i archiwizacji danych
Efektywne planowanie techniczne obejmuje wybieranie odpowiednich narzędzi i infrastruktury, dopasowywanie woluminów danych źródłowych i docelowych oraz konfigurowanie procesów inspekcji i uzgodnień. Wiele migracji staje się złożonych ze względu na brak analizy z góry, zwłaszcza wokół tego, jakie dane muszą zostać przeniesione i gdzie należy. W tej sekcji opisano podstawowe zasady analizy danych w celu obsługi pomyślnej migracji.
Segmentacja danych
Segmentacja danych to kluczowy krok migracji z jednego systemu CRM do usługi Dataverse. Organizowanie tabel danych według funkcji biznesowych, takich jak sprzedaż, usługa lub marketing, aby uprościć planowanie i wykonywanie migracji.
Segmentacja tabel
Zacznij od wyświetlania listy wszystkich tabel kwalifikujących się do migracji pogrupowanych według obszaru biznesowego (na przykład sprzedaży, marketingu, usługi). Następnie:
- Dokumentowanie schematu w programie Excel lub podobnym narzędziu.
- Uruchom podstawowe zapytania w systemie źródłowym, aby sprawdzić użycie kolumn.
- Oznacz kolumny o niskim użyciu. Jeśli mniej niż 5% rekordów zawiera wartości, skontaktuj się z zainteresowanymi stronami biznesowymi, aby zdecydować, czy je zachować, czy odrzucić.
Ta prosta analiza może znacznie zmniejszyć zakres migracji. W długotrwałych systemach CRM często eliminuje się 30–40% kolumn i maksymalnie 20% tabel, usprawniając proces i zwiększając wydajność.
Trafność kolumn
Niektóre kolumny systemu źródłowego są mapowane bezpośrednio na kolumny Dataverse, podczas gdy inne stają się polami obliczeniowymi. Rozdziel te kolumny i skonsultuj się z biznesowymi interesariuszami, aby zdecydować, czy potrzebne są zadania migracyjne.
Ignoruj kolumny, które są istotne tylko w systemie źródłowym lub nie mają znaczenia w obiekcie docelowym. Obejmuje to wiele wbudowanych pól, takich jak Utworzone przez, Zmodyfikowany przez lub Numer wersji wiersza, chyba że służą one określonemu celowi w migracji.
Dane typu pliku
Jeśli system źródłowy zawiera dane typu plików, oznacz te pola na wczesnym etapie i zaplanuj oddzielną strategię migracji. Rozważ następujące typy plików:
- Dokumenty pakietu Office (na przykład Word, Excel, PowerPoint): w przypadku maksymalnie 20 000 plików należy przeprowadzić migrację do platformy współpracy, takiej jak SharePoint, aby umożliwić dostęp wielu użytkowników.
- Pliki multimedialne (na przykład obrazy, filmy wideo): wybierz platformę, która obsługuje odtwarzanie. Opcje obejmują SharePoint, usługi przesyłania strumieniowego lub inne rozwiązania magazynowania przyjazne dla mediów.
- Duże woluminy lub rozmiary plików: jeśli koszt magazynu jest problemem, użyj usługi Azure Blob Storage lub natywnej kolumny plików w usłudze Dataverse, która używa usługi Azure Blob w tle.
- Ochrona przed złośliwym oprogramowaniem: przed migracją uruchom pliki za pomocą narzędzia do wykrywania złośliwego oprogramowania (na przykład usługi Azure Advanced Threat Protection), aby zapewnić bezpieczeństwo.
Po przejrzeniu istotności pliku często zdarza się, że łączna ilość danych znacznie spada — szczególnie w długotrwałych systemach CRM — co sprawia, że migracja będzie wydajniejsza.
Strategie archiwizowania danych
Niektóre dane — takie jak stare wiadomości e-mail, zamknięte sprawy lub zdyskwalifikowani potencjalni klienci — pozostają ważne, ale rzadko są dostępne. Aby zmniejszyć ilość migracji bez zakłócania operacji biznesowych, opracuj inteligentną strategię archiwizacji.
Krok 1. Identyfikowanie danych z możliwością archiwizacji
Wśród typowych kandydatów są:
- Wiadomości e-mail starsze niż trzy lata
- Zamknięte przypadki
- Utracone możliwości
- Zdyskwalifikowani potencjalni klienci
- Marketingowe wiadomości e-mail, wpisy i dzienniki inspekcji
Przejrzyj system, aby zidentyfikować inne tabele, które można zarchiwizować.
Krok 2. Wybieranie podejścia archiwalnego
- Zachowaj dane w systemie źródłowym. Zachowaj kilka licencji administratora na potrzeby dostępu podczas dezaktywowania innych, aby zmniejszyć koszty.
- Przejdź do magazynu zewnętrznego. Użyj lokalnych baz danych, usługi Azure Blob Storage lub tabel platformy Azure do przechowywania zarchiwizowanych rekordów. Takie podejście zmniejsza koszty magazynowania i migracji, ale wymaga oddzielnej strategii migracji.
- Użyj oddzielnego środowiska usługi Dataverse. Ta opcja jest mniej powszechna, ale jest przydatna, jeśli chcesz odizolować zarchiwizowane dane. Później możesz wycofać to środowisko, aby uprościć planowanie jednorazowe.
Zalecana infrastruktura migracji danych
Aby zapewnić szybką i niezawodną migrację danych do usługi Dataverse:
- Użyj maszyny wirtualnej w tym samym regionie co środowisko usługi Dataverse, aby zmniejszyć opóźnienia i zwiększyć szybkość migracji.
- Wybierz maszynę wirtualną o wysokiej wydajności. Co najmniej użyj maszyny wirtualnej D4 z ośmioma rdzeniami, 28 GB pamięci RAM i 500 GB miejsca do wydajnego obsługi dużych ilości danych.
- Preferuj lokalną bazę danych na maszynie wirtualnej. Unikaj połączeń zdalnych podczas migracji. Jeśli używasz usługi Azure Data Factory, wdróż ją w tym samym regionie co środowisko usługi Dataverse w celu uzyskania optymalnej wydajności.