Przenieś starsze dane bez ich wkręcania

Migracja starszych danych jest trudna.

Wiele organizacji ma stare i złożone lokalne biznesowe systemy CRM. Obecnie istnieje wiele alternatyw SaaS w chmurze, które niosą ze sobą wiele korzyści; płać na bieżąco i płacić tylko za to, z czego korzystasz. Dlatego decydują się na przejście na nowe systemy.

Nikt nie chce zostawiać cennych danych o klientach w starym systemie i zaczynać od pustego nowego systemu, więc musimy przenieść te dane. Niestety migracja danych nie jest łatwym zadaniem, ponieważ około 50 procent prac związanych z wdrożeniem pochłaniają działania związane z migracją danych. Według Gartnera Salesforce jest liderem rozwiązań CRM w chmurze. Dlatego migracja danych jest głównym tematem wdrażania Salesforce.

Jak więc możemy zapewnić pomyślne przejście starszych danych do nowego, lśniącego systemu i zapewnić, że zachowamy całą jego historię? W tym artykule przedstawiam 10 wskazówek dotyczących udanej migracji danych. Pierwsze pięć wskazówek dotyczy każdej migracji danych, niezależnie od zastosowanej technologii.

Migracja danych w ogóle

1. Uczyń migrację oddzielnym projektem

Na liście kontrolnej wdrażania oprogramowania migracja danych nie jest elementem „eksportu i importu” obsługiwanym przez sprytne narzędzie do migracji danych „naciśnij jeden przycisk”, które ma predefiniowane mapowanie dla systemów docelowych.

Migracja danych to złożona czynność, zasługująca na osobny projekt, plan, podejście, budżet i zespół. Zakres i plan na poziomie podmiotu należy stworzyć na początku projektu, tak aby nie było niespodzianek typu „Och, zapomnieliśmy wczytać raporty z wizyt tych klientów, kto to zrobi?” dwa tygodnie przed terminem.

Podejście do migracji danych określa, czy będziemy ładować dane za jednym razem (znane również jako big bang ), czy też będziemy ładować małe partie co tydzień.

Nie jest to jednak łatwa decyzja. Podejście musi zostać uzgodnione i przekazane wszystkim interesariuszom biznesowym i technicznym, aby wszyscy byli świadomi, kiedy i jakie dane pojawią się w nowym systemie. Dotyczy to również awarii systemu.

2. Oszacuj realistycznie

Nie lekceważ złożoności migracji danych. Procesowi temu towarzyszy wiele czasochłonnych zadań, które mogą być niewidoczne na początku projektu.

Na przykład ładowanie określonych zestawów danych do celów szkoleniowych z dużą ilością realistycznych danych, ale z zaciemnionymi elementami wrażliwymi, tak aby działania szkoleniowe nie generowały powiadomień e-mail do klientów.

Podstawowym czynnikiem estymacji jest liczba pól, które mają zostać przeniesione z systemu źródłowego do systemu docelowego.

Na różnych etapach projektu dla każdego pola potrzeba trochę czasu, w tym zrozumienie pola, mapowanie pola źródłowego na zmienną docelową, konfigurowanie lub budowanie przekształceń, wykonywanie testów, mierzenie jakości danych dla pola i tak dalej.

Używanie sprytnych narzędzi, takich jak Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas i tym podobne, może skrócić ten czas, szczególnie w fazie budowania.

W szczególności zrozumienie danych źródłowych – najważniejszego zadania w każdym projekcie migracji – nie może być zautomatyzowane przez narzędzia, ale wymaga od analityków czasu na przejrzenie listy pól jeden po drugim.

Najprostszym oszacowaniem całkowitego nakładu pracy jest jeden osobodzień dla każdego pola przeniesionego ze starszego systemu.

Wyjątkiem jest replikacja danych między tym samym schematem źródłowym i docelowym bez dalszej transformacji – czasami nazywana migracją 1:1 – gdzie możemy oprzeć oszacowanie na liczbie tabel do skopiowania.

Szczegółowe oszacowanie to sztuka sama w sobie.

3. Sprawdź jakość danych

Nie przeceniaj jakości danych źródłowych, nawet jeśli żadne problemy z jakością danych nie są zgłaszane ze starszych systemów.

Nowe systemy mają nowe zasady, które mogą zostać naruszone przez starsze dane. Oto prosty przykład. Kontaktowy adres e-mail może być obowiązkowy w nowym systemie, ale 20-letni starszy system może mieć inny punkt widzenia.

W danych historycznych mogą znajdować się miny, które nie były dotykane od dłuższego czasu, ale mogą aktywować się przy przejściu do nowego systemu. Na przykład stare dane wykorzystujące waluty europejskie, które już nie istnieją, muszą zostać przeliczone na euro, w przeciwnym razie waluty muszą zostać dodane do nowego systemu.

Jakość danych znacząco wpływa na wysiłek, a prosta zasada brzmi: im dalej w historii, tym większy bałagan odkryjemy. Dlatego ważne jest, aby wcześnie zadecydować, ile historii chcemy przenieść do nowego systemu.

4. Zaangażuj ludzi biznesu

Ludzie biznesu są jedynymi, którzy naprawdę rozumieją dane i dlatego mogą decydować, jakie dane można wyrzucić, a jakie zachować.

Ważne jest, aby ktoś z zespołu biznesowego był zaangażowany w ćwiczenie mapowania, a dla przyszłego śledzenia wstecznego przydatne jest rejestrowanie decyzji mapowania i ich przyczyn.

Ponieważ obraz jest wart więcej niż tysiąc słów, załaduj partię testową do nowego systemu i pozwól zespołowi biznesowemu się nim bawić.

Nawet jeśli mapowanie migracji danych zostanie sprawdzone i zatwierdzone przez zespół biznesowy, po pojawieniu się danych w interfejsie użytkownika nowego systemu mogą pojawić się niespodzianki.

„Och, teraz rozumiem, musimy to trochę zmienić”, staje się powszechną frazą.

Brak zaangażowania ekspertów w danej dziedzinie, którzy zwykle są bardzo zajętymi ludźmi, jest najczęstszą przyczyną problemów po uruchomieniu nowego systemu.

5. Celuj w zautomatyzowane rozwiązanie migracji

Migracja danych jest często postrzegana jako czynność jednorazowa, a programiści mają tendencję do uzyskiwania rozwiązań pełnych ręcznych działań w nadziei, że wykonają je tylko raz. Ale jest wiele powodów, aby unikać takiego podejścia.

• Jeśli migracja jest podzielona na wiele fal, musimy wielokrotnie powtarzać te same czynności.
• Zazwyczaj dla każdej fali są co najmniej trzy przebiegi migracji: przebieg próbny w celu przetestowania wydajności i funkcjonalności migracji danych, pełne obciążenie walidacji danych w celu przetestowania całego zestawu danych i przeprowadzenia testów biznesowych oraz oczywiście obciążenie produkcyjne. Liczba przebiegów wzrasta wraz ze słabą jakością danych. Poprawa jakości danych to proces iteracyjny, dlatego potrzebujemy kilku iteracji, aby osiągnąć pożądany wskaźnik sukcesu.

Dlatego nawet jeśli migracja jest z natury czynnością jednorazową, ręczne działania mogą znacznie spowolnić działanie.

Migracja danych Salesforce

Następnie omówimy pięć wskazówek dotyczących udanej migracji Salesforce. Pamiętaj, że te wskazówki prawdopodobnie mają zastosowanie również do innych rozwiązań chmurowych.

6. Przygotuj się na długie ładunki

Wydajność jest jednym z, jeśli nie największym, kompromisem przy przechodzeniu z rozwiązania lokalnego do rozwiązania w chmurze — nie wyklucza się Salesforce.

Systemy lokalne zwykle pozwalają na bezpośrednie ładowanie danych do bazowej bazy danych, a przy dobrym sprzęcie możemy z łatwością dotrzeć do milionów rekordów na godzinę.

Ale nie w chmurze. W chmurze jesteśmy mocno ograniczeni kilkoma czynnikami.

• Opóźnienie sieci — dane są przesyłane przez Internet.
• Warstwa aplikacji Salesforce — dane są przenoszone przez grubą warstwę wielodostępności interfejsu API, dopóki nie trafią do baz danych Oracle.
• Niestandardowy kod w Salesforce — niestandardowe walidacje, wyzwalacze, przepływy pracy, reguły wykrywania duplikatów itd. — wiele z nich wyłącza ładowanie równoległe lub zbiorcze.

W rezultacie wydajność ładowania może wynosić tysiące kont na godzinę.

Może być mniej lub więcej, w zależności od rzeczy, takich jak liczba pól, walidacji i wyzwalaczy. Ale jest o kilka stopni wolniejszy niż bezpośrednie ładowanie bazy danych.

Należy również wziąć pod uwagę pogorszenie wydajności, które zależy od ilości danych w Salesforce.

Jest to spowodowane przez indeksy w bazowym RDBMS (Oracle) używane do sprawdzania kluczy obcych, unikalnych pól i oceny reguł duplikacji. Podstawowa formuła to około 50% spowolnienie dla każdego stopnia 10, spowodowane przez O(logN) część złożoności czasowej w operacjach sortowania i B-drzewa.

Ponadto Salesforce ma wiele limitów wykorzystania zasobów.

Jednym z nich jest limit Bulk API ustawiony na 5000 partii w 24-godzinnych oknach ruchomych, z maksymalnie 10 000 rekordów w każdej partii.

Tak więc teoretyczne maksimum to 50 milionów rekordów załadowanych w ciągu 24 godzin.

W prawdziwym projekcie maksymalna wartość jest znacznie niższa ze względu na ograniczoną wielkość partii podczas korzystania na przykład z wyzwalaczy niestandardowych.

Ma to silny wpływ na podejście do migracji danych.

Nawet w przypadku zestawów danych o średniej wielkości (od 100 000 do 1 miliona kont) podejście Wielkiego Wybuchu nie wchodzi w rachubę, więc musimy podzielić dane na mniejsze fale migracji.

To oczywiście wpływa na cały proces wdrażania i zwiększa złożoność migracji, ponieważ będziemy dodawać przyrosty danych do systemu już zapełnionego poprzednimi migracjami i danymi wprowadzonymi przez użytkowników.

Musimy również uwzględnić te istniejące dane w przekształceniach i walidacjach migracji.

Co więcej, długie obciążenia mogą oznaczać, że nie możemy przeprowadzać migracji podczas awarii systemu.

Jeśli wszyscy użytkownicy znajdują się w jednym kraju, możemy wykorzystać ośmiogodzinną awarię w nocy.

Ale dla firmy takiej jak Coca-Cola, działającej na całym świecie, nie jest to możliwe. Gdy mamy w systemie USA, Japonię i Europę, obejmujemy wszystkie strefy czasowe, więc sobota jest jedyną opcją przestoju, która nie ma wpływu na użytkowników.

A to może nie wystarczyć, więc musimy ładować się w trybie online , gdy użytkownicy pracują z systemem.

7. Szanuj potrzeby migracji podczas tworzenia aplikacji

Komponenty aplikacji, takie jak walidacje i wyzwalacze, powinny być w stanie obsłużyć działania związane z migracją danych. Twarde wyłączenie walidacji w momencie obciążenia migracyjnego nie jest opcją, jeśli system musi być w trybie online. Zamiast tego musimy zaimplementować inną logikę w walidacjach zmian dokonywanych przez użytkownika migracji danych.

• Nie należy porównywać pól daty z rzeczywistą datą systemową, ponieważ uniemożliwiłoby to ładowanie danych historycznych. Na przykład walidacja musi umożliwiać wprowadzenie przeszłej daty rozpoczęcia konta dla migrowanych danych.
• Pola obowiązkowe, które nie mogą być wypełnione danymi historycznymi, muszą być zaimplementowane jako nieobowiązkowe, ale z walidacją wrażliwą na użytkownika, tym samym dopuszczając puste wartości dla danych pochodzących z migracji, ale odrzucając puste wartości pochodzące od zwykłych użytkowników poprzez GUI .
• Wyzwalacze, zwłaszcza te wysyłające nowe rekordy do integracji, muszą mieć możliwość włączenia/wyłączenia dla użytkownika migracji danych, aby zapobiec zalaniu integracji migrowanymi danymi.

Inną sztuczką jest użycie pola Legacy ID lub Migration ID w każdym migrowanym obiekcie. Są ku temu dwa powody. Pierwsza jest oczywista: zachować identyfikator ze starego systemu w celu cofnięcia; po tym, jak dane znajdą się w nowym systemie, ludzie mogą nadal chcieć przeszukiwać swoje konta przy użyciu starych identyfikatorów, znalezionych w miejscach takich jak e-maile, dokumenty i systemy śledzenia błędów. Zły nawyk? Być może. Ale użytkownicy będą Ci wdzięczni, jeśli zachowasz ich stare identyfikatory. Drugi powód ma charakter techniczny i wynika z faktu, że Salesforce nie akceptuje jawnie podanych identyfikatorów dla nowych rekordów (w przeciwieństwie do Microsoft Dynamics), ale generuje je podczas ładowania. Problem pojawia się, gdy chcemy wczytać obiekty potomne, ponieważ musimy nadać im identyfikatory obiektów nadrzędnych. Ponieważ poznamy te identyfikatory dopiero po załadowaniu, jest to daremne ćwiczenie.

Wykorzystajmy Konta i ich Kontakty, na przykład:

1. Generuj dane dla Kont.
2. Załaduj konta do Salesforce i otrzymuj wygenerowane identyfikatory.
3. Uwzględnij nowe identyfikatory kont w danych kontaktowych.
4. Generuj dane dla Kontaktów.
5. Załaduj kontakty w Salesforce.

Możemy to zrobić prościej, ładując Konta ich starszymi identyfikatorami przechowywanymi w specjalnym polu zewnętrznym. To pole może być używane jako odniesienie nadrzędne, więc podczas ładowania Kontaktów po prostu używamy Identyfikatora Legacy Konta jako wskaźnika do Konta nadrzędnego:

1. Generuj dane dla Kont, w tym Legacy ID.
2. Generuj dane dla Kontaktów, w tym Legacy ID Konta.
3. Załaduj konta do Salesforce.
4. Załaduj kontakty w Salesforce, używając starszego identyfikatora konta jako odniesienia nadrzędnego.

Fajną rzeczą jest to, że oddzieliliśmy fazę generowania i ładowania, co pozwala na lepszą równoległość, skrócenie czasu przestoju i tak dalej.

8. Bądź świadomy specyficznych funkcji Salesforce

Jak każdy system, Salesforce ma wiele podchwytliwych części, o których powinniśmy wiedzieć, aby uniknąć przykrych niespodzianek podczas migracji danych. Oto garść przykładów:

• Niektóre zmiany dotyczące aktywnych Użytkowników automatycznie generują powiadomienia e-mail na e-maile użytkowników. Tak więc, jeśli chcemy bawić się danymi użytkownika, musimy najpierw dezaktywować użytkowników i aktywować po wprowadzeniu zmian. W środowiskach testowych szyfrujemy wiadomości e-mail użytkowników, aby powiadomienia w ogóle nie były uruchamiane. Ponieważ aktywni użytkownicy zużywają kosztowne licencje, nie jesteśmy w stanie zapewnić aktywności wszystkich użytkowników we wszystkich środowiskach testowych. Musimy zarządzać podzbiorami aktywnych użytkowników, na przykład aktywować tylko tych w środowisku szkoleniowym.
• Nieaktywnych użytkowników, w przypadku niektórych standardowych obiektów, takich jak Konto lub Sprawa, można przypisywać dopiero po przyznaniu uprawnienia systemowego „Aktualizuj rekordy z nieaktywnymi właścicielami”, ale można ich przypisywać np. do kontaktów i wszystkich obiektów niestandardowych.
• Gdy Kontakt jest dezaktywowany, wszystkie pola rezygnacji są dyskretnie włączone.
• Podczas wczytywania duplikatu członka zespołu konta lub obiektu udziału konta, istniejący rekord jest dyskretnie nadpisywany. Jednak podczas ładowania zduplikowanego partnera możliwości, rekord jest po prostu dodawany, co skutkuje duplikatem.
• Pola systemowe, takie jak Created Date utworzenia , Created By ID , Last Modified Date , Last Modified By ID , mogą być jawnie zapisane tylko po przyznaniu nowego uprawnienia systemowego „Ustaw pola audytu podczas tworzenia rekordu”.
• W ogóle nie można migrować zmian wartości historii pola.
• Właścicieli artykułów merytorycznych nie można określić podczas ładowania, ale można je później zaktualizować.
• Trudną częścią jest przechowywanie treści (dokumentów, załączników) w Salesforce. Można to zrobić na wiele sposobów (za pomocą załączników, plików, załączników do kanałów, dokumentów), a każdy z nich ma swoje zalety i wady, w tym różne limity rozmiaru plików.
• Pola listy wyboru zmuszają użytkowników do wybrania jednej z dozwolonych wartości, na przykład typu konta. Ale podczas ładowania danych za pomocą Salesforce API (lub dowolnego narzędzia na nim zbudowanego, takiego jak Apex Data Loader lub Informatica Salesforce Connector), każda wartość zostanie przekazana.

Lista jest długa, ale najważniejsze jest to: zapoznaj się z systemem i dowiedz się, co potrafi, a czego nie, zanim przyjmiesz założenia. Nie zakładaj standardowego zachowania, zwłaszcza w przypadku obiektów podstawowych. Zawsze badaj i testuj.

9. Nie używaj Salesforce jako platformy do migracji danych

Bardzo kuszące jest wykorzystanie Salesforce jako platformy do budowy rozwiązania migracji danych, szczególnie dla programistów Salesforce. Jest to ta sama technologia dla rozwiązania migracji danych, co przy dostosowywaniu aplikacji Salesforce, ten sam GUI, ten sam język programowania Apex, ta sama infrastruktura. Salesforce ma obiekty, które mogą działać jako tabele, oraz rodzaj języka SQL, Salesforce Object Query Language (SOQL). Proszę jednak nie używać go; byłaby to fundamentalna wada architektoniczna.

Salesforce to doskonała aplikacja SaaS z wieloma fajnymi funkcjami, takimi jak zaawansowana współpraca i bogata personalizacja, ale masowe przetwarzanie danych nie należy do nich. Trzy najważniejsze powody to:

• Wydajność – Przetwarzanie danych w Salesforce jest kilka stopni wolniejsze niż w RDBMS.
• Brak funkcji analitycznych – Salesforce SOQL nie obsługuje skomplikowanych zapytań i funkcji analitycznych, które muszą być wspierane przez język Apex, co jeszcze bardziej pogorszyłoby wydajność.
• Architektura * – Umieszczenie platformy do migracji danych w określonym środowisku Salesforce nie jest zbyt wygodne. Zwykle dysponujemy wieloma środowiskami do określonych celów, często tworzonymi ad hoc, dzięki czemu możemy poświęcić dużo czasu na synchronizację kodu. Ponadto będziesz również polegać na łączności i dostępności tego konkretnego środowiska Salesforce.

Zamiast tego zbuduj rozwiązanie do migracji danych w oddzielnej instancji (może to być chmura lub lokalnie) przy użyciu platformy RDBMS lub ETL. Połącz go z systemami źródłowymi i wybierz żądane środowiska Salesforce, przenieś potrzebne dane do obszaru pomostowego i tam je przetwarzaj. Umożliwi to:

• Wykorzystaj pełną moc i możliwości języka SQL lub funkcji ETL.
• Miej cały kod i dane w jednym miejscu, dzięki czemu możesz przeprowadzać analizy we wszystkich systemach.
  • Na przykład możesz połączyć najnowszą konfigurację z najbardziej aktualnego środowiska testowego Salesforce z rzeczywistymi danymi ze środowiska produkcyjnego Salesforce.
• Nie jesteś tak bardzo zależny od technologii systemu źródłowego i docelowego i możesz ponownie wykorzystać swoje rozwiązanie w kolejnym projekcie.

10. Nadzór nad metadanymi Salesforce

Na początku projektu zwykle chwytamy listę pól Salesforce i rozpoczynamy ćwiczenie mapowania. W trakcie projektu często zdarza się, że nowe pola są dodawane przez zespół programistów aplikacji do Salesforce, lub że niektóre właściwości pól są zmieniane. Możemy poprosić zespół aplikacji o powiadomienie zespołu ds. migracji danych o każdej zmianie modelu danych, ale nie zawsze to działa. Aby być bezpiecznym, musimy nadzorować wszystkie zmiany modelu danych.

Typowym sposobem na to jest regularne pobieranie metadanych związanych z migracją z Salesforce do jakiegoś repozytorium metadanych. Gdy już to mamy, możemy nie tylko wykryć zmiany w modelu danych, ale także porównać modele danych dwóch środowisk Salesforce.

Jakie metadane pobrać:

• Lista obiektów wraz z ich etykietami i nazwami technicznymi oraz atrybutami, takimi jak creatable lub możliwość updatable .
• Lista pól z ich atrybutami (lepiej je wszystkie).
• Lista wartości listy wyboru dla pól listy wyboru. Będziemy ich potrzebować do mapowania lub sprawdzania poprawności danych wejściowych pod kątem poprawnych wartości.
• Lista walidacji, aby upewnić się, że nowe walidacje nie powodują problemów dla migrowanych danych.

Jak pobrać metadane z Salesforce? Cóż, nie ma standardowej metody metadanych, ale istnieje wiele opcji:

• Generuj Enterprise WSDL – W aplikacji sieciowej Salesforce przejdź do menu Setup / API i pobierz silnie wpisany Enterprise WSDL, który opisuje wszystkie obiekty i pola w Salesforce (ale nie wartości listy wyboru ani walidacje).
• Zadzwoń do Salesforce describeSObjects usługę sieciową SObjects, bezpośrednio lub za pomocą wrappera Java lub C# (skonsultuj się z Salesforce API). W ten sposób uzyskasz to, czego potrzebujesz, i jest to zalecany sposób eksportowania metadanych.
• Użyj dowolnego z wielu alternatywnych narzędzi dostępnych w Internecie.

Przygotuj się na następną migrację danych

Rozwiązania chmurowe, takie jak Salesforce, są gotowe od ręki. Jeśli jesteś zadowolony z wbudowanych funkcji, po prostu zaloguj się i korzystaj z niego. Jednak Salesforce, jak każde inne rozwiązanie CRM w chmurze, wiąże się z określonymi problemami w temacie migracji danych, o których należy pamiętać, w szczególności w zakresie limitów wydajności i zasobów.

Przenoszenie starszych danych do nowego systemu to zawsze podróż, czasem podróż do historii ukrytej w danych z minionych lat. W tym artykule, w oparciu o kilkanaście projektów migracji, przedstawiłem dziesięć wskazówek, jak migrować starsze dane i skutecznie unikać większości pułapek.

Kluczem jest zrozumienie, co ujawniają dane. Dlatego przed rozpoczęciem migracji danych upewnij się, że zespół programistów Salesforce jest dobrze przygotowany na potencjalne problemy, które mogą powodować Twoje dane.