Udostępnij za pośrednictwem

Planowanie migracji magazynu danych

  • Artykuł

Migracja magazynu danych jest wyzwaniem dla każdej firmy. Aby dobrze go wykonać i uniknąć wszelkich niepożądanych niespodzianek i nieplanowanych kosztów, musisz dokładnie zbadać wyzwanie, zmniejszyć ryzyko i zaplanować migrację, aby upewnić się, że jesteś tak gotowy, jak to możliwe. Na wysokim poziomie plan powinien obejmować podstawowe kroki procesu migracji magazynu danych i wszystkie zadania w ramach nich. Główne kroki procesu to:

  • Przygotowanie przed migracją
  • Strategia migracji i wykonywanie
  • Po migracji

Na przykład przygotowanie obejmuje takie rzeczy, jak przygotowanie zespołu ds. migracji magazynu danych pod względem umiejętności szkolenia i znajomości technologii. Obejmuje to również skonfigurowanie laboratorium weryfikacji koncepcji, zrozumienie sposobu zarządzania środowiskami testowymi i produkcyjnymi, uzyskanie odpowiedniego rozliczenia w celu przeprowadzenia migracji danych i systemu produkcyjnego poza zaporą firmową oraz skonfigurowanie oprogramowania migracji w centrum danych w celu umożliwienia przeprowadzenia migracji.

Aby migracja magazynu danych przebiegała bezproblemowo, plan powinien jasno zrozumieć:

  • Twój przypadek biznesowy, w tym jego czynniki, korzyści biznesowe i czynniki ryzyka.
  • Role i obowiązki zespołu ds. migracji.
  • Zestaw umiejętności i szkolenie wymagane do umożliwienia pomyślnej migracji.
  • Przydzielony budżet na pełną migrację.
  • Strategia migracji.
  • Jak uniknąć ryzyka w projekcie migracji, aby uniknąć opóźnień lub przepracowania.
  • Istniejący system magazynu danych, jego architektura, schemat, woluminy danych, przepływy danych, zabezpieczenia i zależności operacyjne.
  • Różnice między istniejącym lokalnym magazynem danych DBMS i Azure Synapse, takie jak typy danych, funkcje SQL, logika i inne zagadnienia.
  • Co należy migrować i priorytety.
  • Zadania migracji, podejścia, kolejność i terminy ostateczne.
  • Jak będziesz kontrolować migrację.
  • Jak zapobiec przerwom w działaniu użytkownika podczas migracji.
  • Co należy zrobić lokalnie, aby uniknąć opóźnień i włączyć migrację.
  • Narzędzia umożliwiające bezpieczną migrację schematów, danych i przetwarzania ETL na platformę Azure.
  • Zmiany projektu modelu danych, które są wymagane podczas i po migracji.
  • Wszelkie zmiany technologii przed migracją lub po migracji oraz sposób minimalizowania zmian.
  • Wycofanie technologii po migracji.
  • Sposób implementacji testowania i zapewnienia jakości w celu udowodnienia sukcesu.
  • Punkty kontrolne umożliwiające ocenę postępu i podejmowanie decyzji.
  • Twój plan awaryjny i punkty wycofania w przypadku wystąpienia problemów.

Aby osiągnąć to zrozumienie, musimy przygotować i rozpocząć określone działania przed rozpoczęciem migracji. Przyjrzyjmy się temu, co wiąże się z bardziej szczegółowymi informacjami.

Przygotowanie przed migracją

Przed rozpoczęciem migracji magazynu danych należy rozwiązać kilka kwestii.

Kluczowe role w zespole ds. migracji magazynu danych

Kluczowe role w projekcie migracji obejmują:

  • Właściciel firmy
  • Menedżer projektu (z doświadczeniem metodologii agile, takim jak Scrum)
  • Koordynator projektu
  • Inżynier chmury
  • Administrator bazy danych (istniejący system DBMS magazynu danych i Azure Synapse)
  • Osoby modelające dane
  • Deweloperzy ETL
  • Specjalista ds. wirtualizacji danych (prawdopodobnie administrator bazy danych)
  • Inżynier testowania
  • Analitycy biznesowi (aby ułatwić testowanie zapytań, raportów i analiz narzędzi analizy biznesowej)

Ponadto zespół musi obsługiwać lokalny zespół infrastruktury.

Umiejętności i szkolenia w celu przygotowania zespołu do migracji

W odniesieniu do umiejętności wiedza jest ważna podczas migracji magazynu danych. W związku z tym upewnij się, że odpowiedni członkowie zespołu migracji są przeszkoleni w podstawach chmury platformy Azure, usłudze Azure Blob Storage, Azure Data Lake Storage, Azure Data Box, ExpressRoute, zarządzaniu tożsamościami platformy Azure, Azure Data Factory i Azure Synapse. Twoi modelowanie danych najprawdopodobniej będą musieli dostosować modele danych firmy Microsoft Azure Synapse po zakończeniu migracji z istniejącego magazynu danych.

Ocenianie istniejącego magazynu danych

Kolejną częścią przygotowania do migracji jest potrzeba pełnej oceny istniejącego magazynu danych, aby w pełni zrozumieć architekturę, magazyny danych, schemat, logikę biznesową, przepływy danych, używane funkcje systemu DBMS, operacje magazynu i zależności. Lepsze jest lepsze zrozumienie tego tematu. Szczegółowa wiedza na temat działania systemu pomaga komunikować się i obejmować wszystkie bazy.

Celem oceny jest nie tylko zapewnienie szczegółowego zrozumienia bieżącej konfiguracji w zespole ds. migracji, ale także zrozumienie mocnych i słabych stron w bieżącej konfiguracji. Wynik oceny bieżącego magazynu danych może zatem mieć wpływ na strategię migracji pod względem migracji metodą "lift and shift" w porównaniu z czymś szerszym. Jeśli na przykład wynikiem oceny jest to, że magazyn danych jest na koniec życia, oczywiście strategia będzie bardziej migracją danych do nowo zaprojektowanego magazynu danych w Azure Synapse w porównaniu z metodą "lift-and-shift".

Lokalne przygotowanie do migracji danych

Oprócz przygotowania i przygotowania zespołu ds. migracji do środowiska docelowego i oceny bieżącej konfiguracji równie ważne jest również ustawienie elementów w środowisku lokalnym, ponieważ produkcyjne magazyny danych są w dużym stopniu kontrolowane przez procedury IT i procesy zatwierdzania. Aby uniknąć opóźnień, upewnij się, że zespoły ds. infrastruktury i operacji centrum danych są gotowe do migracji danych, schematu, zadań ETL itd. do chmury platformy Azure. Migracja danych może wystąpić za pośrednictwem:

  • Narzędzie AzCopy do usługi Azure Blob Storage.
  • Usługa Microsoft Azure ExpressRoute do transferu skompresowanych danych bezpośrednio na platformę Azure.
  • Eksportowanie plików na urządzenie Azure Data Box.

Główne czynniki wpływające na wybór tych opcji to rozmiar woluminu danych (w terabajtach) i szybkość sieci (w Mb/s). Potrzebne jest obliczenie w celu określenia, jak długo trwałoby migrowanie danych za pośrednictwem sieci, biorąc pod uwagę, że dane mogą być kompresowane w magazynie danych i nieskompresowane podczas eksportowania. Taka sytuacja może spowolnić transfer danych. Rekompresuj dane za pośrednictwem narzędzia Gzip podczas przenoszenia danych przy użyciu dowolnej z powyższych metod. Technologia PolyBase może przetwarzać dane Gzipped bezpośrednio. Duże woluminy danych prawdopodobnie zostaną zmigrowane za pośrednictwem urządzenia Azure Data Box, jeśli przeniesienie danych będzie trwać zbyt długo.

Ponadto aby Azure Data Factory kontrolować wykonywanie eksportów istniejących danych magazynu danych z platformy Azure, w centrum danych musi być zainstalowane własne oprogramowanie uruchomieniowe integracji, aby umożliwić kontynuowanie migracji. Biorąc pod uwagę te wymagania, jeśli konieczne jest formalne zatwierdzenie w celu umożliwienia tego możliwego, rozpoczęcie odpowiednich procesów zatwierdzania na wczesnym etapie, aby to umożliwić, pomoże uniknąć opóźnień w dół linii.

Przygotowywanie platformy Azure do migracji schematu i danych

Jeśli chodzi o przygotowanie po stronie platformy Azure, importowanie danych musi być zarządzane za pośrednictwem usługi Microsoft Azure ExpressRoute lub Microsoft Azure Data Box. Azure Data Factory potoki to idealny sposób ładowania danych do usługi Azure Blob Storage, a następnie ładowania ich do Azure Synapse przy użyciu technologii PolyBase. Dlatego przygotowanie jest potrzebne po stronie platformy Azure do opracowania takiego potoku.

Alternatywą jest użycie istniejącego narzędzia ETL na platformie Azure, jeśli obsługuje Azure Synapse, co oznacza skonfigurowanie narzędzia na platformie Azure z Azure Marketplace i przygotowanie potoku do zaimportowania danych i załadowania ich do usługi Azure Blob Storage.

Definiowanie strategii migracji

Cele migracji

W każdej strategii musi istnieć zestaw celów lub celów, które powinny być zdefiniowane w celu wskazania sukcesu. Cele można następnie ustawić w celu osiągnięcia tych celów i osób, które ponoszą odpowiedzialność za ich osiągnięcie. Przykłady celów migracji i odpowiednich metryk w celu ustawienia celów w projekcie migracji magazynu danych w chmurze przedstawiono w poniższej tabeli:

Typy celów i przykładów metryk:

Zwiększanie ogólnej wydajności

  • Wydajność migracji danych
  • Wydajność ELT
  • Wydajność ładowania danych
  • Złożona wydajność zapytań
  • Liczba równoczesnych użytkowników

Uruchamianie przy niższych kosztach

  • Koszt obliczeń według obciążenia, na przykład liczba godzin obliczeniowych x koszt na godzinę dla:
    • Raportowanie standardowe
    • Zapytania ad hoc
    • Przetwarzanie ELT wsadowe
  • Koszt magazynowania (przejściowe, tabele produkcyjne, indeksy, miejsce tymczasowe)

Obsługa z lepszą dostępnością i poziomami usług

  • Umowy dotyczące poziomu usług
  • Wysoka dostępność

Zwiększanie produktywności

  • Zadania zautomatyzowane, zmniejszona liczba pracowników administracyjnych

Pomyślna migracja magazynu danych może zatem być interpretowana jako magazyn danych, który działa tak szybko lub szybciej, jak i przy niższych kosztach niż starszy system, z którego przeprowadzono migrację. Przypisywanie właścicieli tych celów powoduje odpowiedzialność za ich dotarcie. Gwarantuje również, że testowanie w laboratorium weryfikacji koncepcji (zgodnie z definicją w sekcji de-risking w tym przewodniku) zostanie uznane za pomyślne, jeśli testy identyfikują sposoby osiągnięcia celów.

Podejście do migracji

Istnieje kilka opcji strategicznych migracji istniejącego magazynu danych do Azure Synapse:

  • Podnieś i przesuń istniejący magazyn danych zgodnie z rzeczywistymi ustawieniami.
  • Uprość istniejący magazyn danych, a następnie zmigruj go.
  • Całkowicie przeprojektuj magazyn danych na Azure Synapse i zmigruj dane.

Wyniki oceny istniejącego magazynu danych powinny znacząco wpływać na twoją strategię. Dobry wynik oceny może zalecić strategię "lift and shift". Przeciętny wynik ze względu na niską ocenę elastyczności może wskazywać, że uproszczenie jest potrzebne przed migracją. Słaby wynik może wskazywać na pełną zmianę projektu.

Lift and shift pozostawia architekturę w miarę działania, starając się zminimalizować pracę w przeniesieniu istniejącego systemu. Jeśli istniejące narzędzie ETL obsługuje już Azure Synapse, możesz zmienić cel przy minimalnym wysiłku. Niemniej jednak istnieją różnice w typach tabel, typach danych, funkcjach SQL, widokach, logice biznesowej procedury składowanej itp. Te różnice i sposoby ich obejścia są szczegółowo opisane w dokumentach niższego poziomu w tej serii migracji.

Uproszczenie istniejącego magazynu danych przed migracją polega na zmniejszeniu złożoności w celu ułatwienia migracji. Może to obejmować:

  • Usuwanie lub archiwizowanie nieużywanych tabel przed migracją w celu uniknięcia migracji danych, które nie są używane.
  • Konwertowanie fizycznych martów danych na wirtualne magazyny danych przy użyciu oprogramowania do wirtualizacji danych w celu zmniejszenia liczby migrowanych danych. Konwersja zwiększa również elastyczność i zmniejsza całkowity koszt posiadania, dzięki czemu można ją uznać za modernizację podczas migracji.

Można również uprościć najpierw, a następnie podnieść i przesunąć to, co pozostaje.

Zakres migracji

Niezależnie od wybranej strategii, należy jasno zdefiniować zakres migracji, to, co zostanie zmigrowane i czy migracja przyrostowa, czy cała. Jednym z przykładów migracji przyrostowej jest najpierw migrowanie marty danych, a następnie magazyn danych. Takie podejście pozwala skupić się na obszarach biznesowych o wysokim priorytecie, umożliwiając zespołowi przyrostowe tworzenie wiedzy, ponieważ każda marty jest indywidualnie migrowana, przed migracją samego magazynu danych.

Definiowanie, co należy zmigrować

Utwórz spis wszystkich elementów, które należy zmigrować. Obejmuje to schemat, dane, procesy ETL (potoki), uprawnienia autoryzacji, użytkowników, warstwy dostępu semantycznego narzędzia analizy biznesowej i aplikacje analityczne. Szczegółowe informacje o tym, co jest związane z migracją spisu, są dostępne w każdym z artykułów migracji niższego poziomu w tej serii. Poniżej przedstawiono linki do tych linków.

  • Zagadnienia dotyczące migracji schematu, projektowania i wydajności.
  • Migracja danych, przetwarzanie ETL i ładowanie.
  • Uzyskiwanie dostępu do operacji zabezpieczeń i magazynu danych.
  • Migracja wizualizacji i raportów.
  • Minimalizacja wpływu problemów z programem SQL.
  • Narzędzia innych firm ułatwiające migrację magazynu danych.

Jeśli nie masz pewności co do najlepszego podejścia, przeprowadź testy w laboratorium weryfikacji koncepcji, aby zidentyfikować optymalne techniki. Aby uzyskać więcej informacji, zobacz sekcję dotyczącą usuwania ryzyka dotyczącego projektu migracji magazynu danych.

Kontrola migracji

Migracja magazynu danych do Azure Synapse obejmuje zadania, które należy przeprowadzić:

  • Lokalne, takie jak eksportowanie danych.
  • W sieci, na przykład transfer danych.
  • W chmurze platformy Azure, na przykład przekształcanie danych, integracja i ładowanie.

Problem polega na tym, że zarządzanie tymi zadaniami może być skomplikowane, jeśli skrypty i narzędzia są opracowywane, testowane i uruchamiane niezależnie w środowiskach lokalnych i platformy Azure. Zwiększa złożoność, zwłaszcza jeśli kontrola wersji, zarządzanie testami i wykonywanie migracji nie są koordynowane.

Należy unikać tych złożoności i kontrolować je ze wspólnego miejsca za pośrednictwem repozytorium kontroli źródła w celu zarządzania zmianami od programowania do testowania i produkcji. Wykonanie migracji będzie obejmować zadania, które muszą być wykonywane lokalnie, w sieci i na platformie Azure. Ponieważ Azure Synapse jest środowiskiem docelowym, kontrolowanie wykonywania migracji z platformy Azure upraszcza zarządzanie. Użyj Azure Data Factory, aby utworzyć potok kontroli migracji, aby kontrolować wykonywanie zarówno lokalnie, jak i na platformie Azure. Wprowadza to automatyzację i minimalizuje błędy. Usługa Data Factory staje się narzędziem do orkiestracji migracji, a nie tylko narzędziem do integracji danych przedsiębiorstwa.

Inne opcje kontrolowania migracji dostępnej od partnerów firmy Microsoft działających na platformie Azure obejmują narzędzia automatyzacji magazynu danych, aby spróbować zautomatyzować migrację. Na przykład dostawcy, tacy jak WhereScape i Attunity. Większość tych narzędzi automatyzacji ma na celu podejście "lift-and-shift" do migracji. Nawet wtedy mogą istnieć pewne rzeczy, które mogą nie być obsługiwane przez takie narzędzia, na przykład procedury składowane. Te produkty i kilka innych są szczegółowo opisane w osobnym przewodniku poświęconym narzędziom innych firm, które ułatwiają migrację do Azure Synapse.

Testowanie migracji

Pierwszą rzeczą, której potrzebujesz do testowania, jest zdefiniowanie serii testów i zestaw wymaganych wyników dla każdego testu, który należy uruchomić, aby zweryfikować i wskazać powodzenie. Ważne jest, aby upewnić się, że wszystkie aspekty są testowane i porównywane w istniejących i migrowanych systemach, w tym:

  • Schemat
  • Typy danych konwertowane w razie potrzeby
  • Użyj schematu zdefiniowanego przez użytkownika w Azure Synapse, aby odróżnić tabele magazynu danych i składnic danych
  • Użytkownicy
  • Role i przypisania użytkowników do tych ról
  • Uprawnienia zabezpieczeń dostępu do danych
  • Prywatność i zgodność danych
  • Uprawnienia, które zarządzają możliwościami administrowania
  • Jakość i integralność danych
  • Przetwarzanie ETL, które wypełnia Azure Synapse zarówno do magazynu danych, jak i z magazynu danych do dowolnych mart, w tym do testowania
  • Wszystkie wiersze są poprawne we wszystkich tabelach, w tym w historii
  • Powolne zmienianie przetwarzania wymiarów
  • Zmienianie przetwarzania przechwytywania danych
  • Obliczenia i agregacje korzystające z funkcji, które mogą się różnić w różnych systemach
  • Wyniki wszystkich znanych zapytań, raportów i pulpitów nawigacyjnych
  • Wydajność i skalowalność
  • Funkcje analityczne
  • Koszty w nowym środowisku płatności zgodnie z rzeczywistym użyciem

Automatyzowanie testowania jak najwięcej, co umożliwia powtarzanie każdego testu i zapewnienie spójnego podejścia do oceny wyników. Jeśli raporty i pulpity nawigacyjne są niespójne, wówczas możliwość porównywania pochodzenia metadanych w oryginalnych i migrowanych systemach jest cenna podczas testowania migracji, ponieważ może wyróżniać różnice i wskazać, gdzie wystąpiły, gdy nie są one łatwe do wykrycia.

Najlepszym sposobem na to jest bezpieczne tworzenie ról, przypisywanie uprawnień dostępu do ról, a następnie dołączanie użytkowników do ról. Aby uzyskać dostęp do nowo zmigrowanego magazynu danych, skonfiguruj zautomatyzowany proces tworzenia nowych użytkowników i przypisywania ról. Wykonaj to samo, aby usunąć użytkowników z ról.

Przekaż przecięcie wszystkim użytkownikom, aby wiedzieli, co się zmienia i czego się spodziewać.

Usuwanie ryzyka związanego z projektem migracji magazynu danych

Innym krytycznym czynnikiem migracji magazynu danych jest usunięcie ryzyka projektu w celu zmaksymalizowania prawdopodobieństwa powodzenia. Istnieje kilka rzeczy, które można zrobić, aby usunąć ryzyko migracji magazynu danych. Obejmują one:

  • Utworzenie laboratorium weryfikacji koncepcji umożliwiające zespołowi wypróbowanie rzeczy, przeprowadzenie testów, zrozumienie wszelkich problemów oraz zidentyfikowanie poprawek i optymalizacji, które pomagają zweryfikować podejścia do migracji, poprawić wydajność i obniżyć koszty. Ułatwia również ustanawianie sposobów automatyzowania zadań, używania wbudowanych narzędzi i szablonów kompilacji w celu przechwytywania najlepszych rozwiązań, uczenia się z doświadczenia i śledzenia lekcji. Jest to bezcenny sposób na ograniczenie ryzyka i zwiększenie szans na sukces. Ponadto można przypisać właścicieli do testów, którzy są odpowiedzialny za osiągnięcie celów i celów migracji zgodnie z definicją w strategii migracji.
  • Wprowadzenie wirtualizacji danych między narzędziami analizy biznesowej a magazynem danych i magazynami danych. Wprowadzenie przejrzystości użytkownika przy użyciu wirtualizacji danych w celu zmniejszenia ryzyka migracji magazynu danych i ukrycie migracji od użytkowników przy użyciu narzędzi do analizy biznesowej wirtualizacji danych, jak pokazano na poniższym diagramie.

Diagram migracji magazynu danych

W tym celu należy przerwać zależność między użytkownikami biznesowymi przy użyciu narzędzi do samoobsługi analizy biznesowej oraz fizycznego schematu bazowego magazynu danych i magazynów danych, które są migrowane. Wprowadzając wirtualizację danych, wszelkie zmiany schematu wykonane podczas migracji magazynu danych i martu danych do Azure Synapse (na przykład w celu optymalizacji wydajności) mogą być ukryte przed użytkownikami biznesowymi, ponieważ uzyskują dostęp tylko do tabel wirtualnych w warstwie wirtualizacji danych. Jeśli konieczna jest zmiana strukturalna, należy zmienić tylko mapowania między magazynem danych lub składnicami danych a wszystkimi tabelami wirtualnymi, aby użytkownicy nie byli świadomi tych zmian i nie wiedzieli o migracji.

  • Należy zarchiwizować wszystkie istniejące tabele zidentyfikowane jako nigdy nieużytowane przed migracją magazynu danych, ponieważ nie ma sensu migrować tabel, które nie są używane. Jednym z możliwych sposobów jest zarchiwizować nieużywane dane w usłudze Azure Blob Storage lub Azure Data Lake Storage i utworzyć tabele zewnętrzne w Azure Synapse do tych danych, aby były nadal w trybie online.
  • Rozważ możliwość wprowadzenia maszyny wirtualnej na platformie Azure z wersją programową (zwykle bezpłatną) istniejącego starszego systemu DBMS magazynu danych uruchomionego na tej maszynie wirtualnej. Dzięki temu można szybko przenieść istniejący schemat magazynu danych na maszynę wirtualną i przenieść go do Azure Synapse podczas pracy całkowicie w chmurze platformy Azure.
  • Definiowanie kolejności i zależności migracji.
  • Upewnij się, że zespoły ds. infrastruktury i operacji są gotowe do migracji danych tak szybko, jak to możliwe do projektu migracji.
  • Zidentyfikuj różnice w funkcjach systemu DBMS i tam, gdzie może stać się problemem zastrzeżona logika biznesowa. Na przykład użycie procedur składowanych do przetwarzania ELT jest mało prawdopodobne, aby łatwo przeprowadzić migrację i nie będzie zawierać żadnego pochodzenia metadanych, ponieważ przekształcenia są pochowane w kodzie.
  • Biorąc pod uwagę strategię migracji składnic danych, a następnie magazyn danych, który jest źródłem do składnic danych. Jest to spowodowane tym, że umożliwia migrację przyrostową, ułatwia zarządzanie i istnieje możliwość nadania priorytetów migracji na podstawie potrzeb biznesowych.
  • Biorąc pod uwagę możliwość korzystania z wirtualizacji danych w celu uproszczenia bieżącej architektury magazynu danych przed migracją, na przykład w celu zastąpienia składnic danych wirtualnymi składnicami danych, aby można było wyeliminować fizyczne magazyny danych i zadania ETL dla składnic danych bez utraty funkcji przed migracją. Dzięki temu można zmniejszyć liczbę magazynów danych do migracji, zmniejszyć liczbę kopii danych, zmniejszyć całkowity koszt posiadania i zwiększyć elastyczność. Wymaga to przełączenia z fizycznych do wirtualnych składnic danych przed migracją magazynu danych. Na wiele sposobów można rozważyć ten krok modernizacji magazynu danych przed migracją.

Następne kroki

Aby uzyskać więcej informacji na temat migracji magazynu danych, weź udział w warsztatach dotyczących modernizacji magazynu danych w chmurze wirtualnej na platformie Azure z witryny Informatica.