Wizualizacja i raportowanie migracji oracle

Ten artykuł jest częścią czwartej z siedmiu części serii, która zawiera wskazówki dotyczące migracji z bazy danych Oracle do usługi Azure Synapse Analytics. W tym artykule opisano najlepsze rozwiązania dotyczące wizualizacji i raportowania.

Uzyskiwanie dostępu do usługi Azure Synapse Analytics przy użyciu narzędzi firmy Microsoft i analizy biznesowej innych firm

Organizacje uzyskują dostęp do magazynów danych i magazynów danych przy użyciu różnych narzędzi i aplikacji analizy biznesowej. Oto kilka przykładów produktów analizy biznesowej:

• Narzędzia usługi Microsoft BI, takie jak Power BI.

• Aplikacje pakietu Office, takie jak arkusze kalkulacyjne programu Microsoft Excel.

• Narzędzia analizy biznesowej innych firm od innych dostawców.

• Niestandardowe aplikacje analityczne z osadzoną funkcją narzędzia analizy biznesowej.

• Aplikacje operacyjne, które obsługują analizę bi na żądanie, uruchamiając zapytania i raporty na platformie analizy biznesowej, które z kolei wysyłają zapytania do danych w magazynie danych lub w magazynie danych.

• Interaktywne narzędzia programistyczne do nauki o danych, takie jak Azure Synapse Notesy Spark, Azure Machine Learning, RStudio i Notesy Jupyter.

W przypadku migracji wizualizacji i raportowania w ramach migracji magazynu danych wszystkie istniejące zapytania, raporty i pulpity nawigacyjne generowane przez produkty analizy biznesowej muszą być uruchamiane w nowym środowisku. Produkty analizy biznesowej muszą przynieść te same wyniki, Azure Synapse jak w starszym środowisku magazynu danych.

Aby uzyskać spójne wyniki po migracji, wszystkie narzędzia analizy biznesowej i zależności aplikacji muszą działać po przeprowadzeniu migracji schematu i danych magazynu danych do Azure Synapse. Zależności obejmują mniej widoczne aspekty, takie jak dostęp i zabezpieczenia. Podczas rozwiązywania problemów z dostępem i zabezpieczeniami upewnij się, że przeprowadzono migrację:

• Uwierzytelnianie, dzięki czemu użytkownicy mogą logować się do magazynu danych i baz danych mart w Azure Synapse.

• Wszyscy użytkownicy Azure Synapse.

• Wszystkie grupy użytkowników do Azure Synapse.

• Wszystkie role do Azure Synapse.

• Wszystkie uprawnienia autoryzacji kontrolujące kontrolę dostępu do Azure Synapse.

• Przypisania użytkowników, ról i uprawnień w celu odzwierciedlenia tego, co było w istniejącym magazynie danych przed migracją. Przykład:

  • Uprawnienia obiektu bazy danych przypisane do ról
  • Role przypisane do grup użytkowników
  • Użytkownicy przypisani do grup użytkowników i/lub ról

Dostęp i zabezpieczenia są ważnymi zagadnieniami dotyczącymi dostępu do danych w migrowanym systemie i zostały szczegółowo omówione w temacie Zabezpieczenia, dostęp i operacje migracji Oracle.

Porada

Istniejący użytkownicy, grupy użytkowników, role i przypisania uprawnień zabezpieczeń dostępu muszą zostać zmigrowane najpierw w celu pomyślnej migracji raportów i wizualizacji.

Przeprowadź migrację wszystkich wymaganych danych, aby upewnić się, że raporty i pulpity nawigacyjne, które wysyłają zapytania do danych w starszym środowisku, generują te same wyniki w Azure Synapse.

Użytkownicy biznesowi będą oczekiwać bezproblemowej migracji, bez niespodzianek, które zniszczą zaufanie do zmigrowanego systemu na Azure Synapse. Zadbaj o złagodzenie obaw, że użytkownicy mogą mieć dobrą komunikację. Użytkownicy będą oczekiwać, że:

• Struktura tabeli pozostaje taka sama, gdy bezpośrednio odnosi się do zapytań.

• Nazwy tabel i kolumn pozostają takie same, gdy są bezpośrednio określane w zapytaniach. Na przykład pola obliczeniowe zdefiniowane na kolumnach w narzędziach analizy biznesowej nie powinny zakończyć się niepowodzeniem po utworzeniu zagregowanych raportów.

• Analiza historyczna pozostaje taka sama.

• Typy danych pozostają takie same, jeśli to możliwe.

• Zachowanie zapytania pozostaje takie samo.

• Sterowniki ODBC/JDBC są testowane, aby upewnić się, że zachowanie zapytań pozostaje takie samo.

Porada

Zaangażowanie użytkowników biznesowych w komunikację ma kluczowe znaczenie dla sukcesu.

Jeśli narzędzia analizy biznesowej wysyłają zapytania do widoków w bazowym magazynie danych lub bazie danych mart, czy te widoki będą nadal działać po migracji? Niektóre widoki mogą nie działać, jeśli istnieją zastrzeżone rozszerzenia SQL specyficzne dla starszej wersji systemu DBMS magazynu danych, które nie mają odpowiednika w Azure Synapse. Jeśli tak, musisz wiedzieć o tych niezgodnościach i znaleźć sposób ich rozwiązania.

Porada

Widoki i zapytania SQL korzystające z zastrzeżonych rozszerzeń zapytań SQL mogą powodować niezgodności wpływające na raporty i pulpity nawigacyjne analizy biznesowej.

Inne problemy, takie jak zachowanie NULL wartości lub odmian typów danych na platformach DBMS, należy przetestować, aby zapewnić, że nawet niewielkie różnice nie istnieją w wynikach obliczeń. Zminimalizuj te problemy i wykonaj wszystkie niezbędne kroki, aby chronić użytkowników biznesowych przed ich wpływem. W zależności od starszego środowiska magazynu danych narzędzia innych firm , które mogą pomóc ukryć różnice między starszymi i nowymi środowiskami, aby narzędzia analizy biznesowej i aplikacje działały bez zmian.

Testowanie ma kluczowe znaczenie dla wizualizacji i migracji raportów. Potrzebujesz zestawu testów i uzgodnionych danych testowych do uruchamiania i ponownego uruchamiania testów w obu środowiskach. Komrzęd testowy jest również przydatny, a kilka z nich zostało wymienionych w tym przewodniku. Ponadto ważne jest, aby zaangażować użytkowników biznesowych w aspekt testowy migracji, aby utrzymać pewność siebie i utrzymać ich zaangażowanie i część projektu.

Porada

Użyj powtarzalnych testów, aby zapewnić pomyślne migrowanie raportów, pulpitów nawigacyjnych i innych wizualizacji.

Możesz myśleć o przełączaniu narzędzi analizy biznesowej, na przykład w celu przeprowadzenia migracji do usługi Power BI. Pokusą jest wprowadzenie takich zmian w tym samym czasie, w którym migrujesz schemat, dane, przetwarzanie ETL i nie tylko. Jednak aby zminimalizować ryzyko, lepiej jest przeprowadzić migrację do Azure Synapse najpierw i uzyskać wszystko, co działa przed podjęciem dalszej modernizacji.

Jeśli istniejące narzędzia analizy biznesowej działają lokalnie, upewnij się, że mogą łączyć się z Azure Synapse za pośrednictwem zapory, aby można było uruchamiać porównania w obu środowiskach. Alternatywnie, jeśli dostawca istniejących narzędzi analizy biznesowej oferuje swój produkt na platformie Azure, możesz wypróbować go tam. Dotyczy to aplikacji działających lokalnie, które osadzają usługę BI lub nazywają serwer analizy biznesowej na żądanie, na przykład żądając "raportu bezgłowego" z danymi XML lub JSON.

Jest wiele do przemyślenia tutaj, więc przyjrzyjmy się bliżej.

Używanie wirtualizacji danych w celu zminimalizowania wpływu migracji na narzędzia i raporty analizy biznesowej

Podczas migracji można spełnić długoterminowe wymagania, takie jak otwieranie żądań biznesowych, dodawanie brakujących danych lub implementowanie nowych funkcji. Jednak takie zmiany mogą mieć wpływ na dostęp narzędzia analizy biznesowej do magazynu danych, zwłaszcza jeśli zmiana obejmuje zmiany strukturalne w modelu danych. Jeśli chcesz wdrożyć technikę modelowania danych agile lub wdrożyć zmiany strukturalne, zrób to po migracji.

Jednym ze sposobów zminimalizowania wpływu zmian schematu lub innych zmian strukturalnych w narzędziach analizy biznesowej jest wprowadzenie wirtualizacji danych między narzędziami analizy biznesowej a magazynem danych i magazynem danych. Na poniższym diagramie pokazano, jak wirtualizacja danych może ukryć migrację od użytkowników.

Wirtualizacja danych przerywa zależność między użytkownikami biznesowymi korzystającymi z narzędzi do analizy biznesowej samoobsługi oraz fizycznym schematem bazowego magazynu danych i magazynów danych, które są migrowane.

Porada

Wirtualizacja danych pozwala chronić użytkowników biznesowych przed zmianami strukturalnymi podczas migracji, dzięki czemu nie wiedzą o tych zmianach. Zmiany strukturalne obejmują zmiany schematu, które dostrajają model danych do Azure Synapse.

Dzięki wirtualizacji danych wszelkie zmiany schematu wprowadzone podczas migracji do Azure Synapse, na przykład w celu optymalizacji wydajności, mogą być ukryte przed użytkownikami biznesowymi, ponieważ mają dostęp tylko do tabel wirtualnych w warstwie wirtualizacji danych. Jeśli wprowadzisz zmiany strukturalne, musisz zaktualizować mapowania między magazynem danych lub tabelami wirtualnymi. Dzięki wirtualizacji danych użytkownicy nie wiedzą o zmianach strukturalnych. Partnerzy firmy Microsoft udostępniają oprogramowanie do wirtualizacji danych.

Identyfikowanie raportów o wysokim priorytcie w celu pierwszej migracji

Kluczowym pytaniem podczas migracji istniejących raportów i pulpitów nawigacyjnych do Azure Synapse jest to, które z nich należy najpierw przeprowadzić migrację. Kilka czynników może prowadzić do tej decyzji, na przykład:

• Użycie

• Wartość biznesowa

• Łatwość migracji

• Strategia migracji danych

W poniższych sekcjach omówiono te czynniki.

Niezależnie od decyzji, musi ona obejmować użytkowników biznesowych, ponieważ tworzą raporty, pulpity nawigacyjne i inne wizualizacje oraz podejmują decyzje biznesowe na podstawie szczegółowych informacji z tych elementów. Wszystkie korzyści, gdy można wykonywać następujące czynności:

• Bezproblemowe migrowanie raportów i pulpitów nawigacyjnych
• Migrowanie raportów i pulpitów nawigacyjnych przy minimalnym wysiłku i
• Wskaż narzędzia analizy biznesowej na Azure Synapse zamiast starszego systemu magazynu danych i uzyskaj podobne raporty, pulpity nawigacyjne i inne wizualizacje.

Migrowanie raportów na podstawie użycia

Użycie jest często wskaźnikiem wartości biznesowej. Nieużywane raporty i pulpity nawigacyjne wyraźnie nie przyczyniają się do decyzji biznesowych ani nie oferują bieżącej wartości. Jeśli nie masz sposobu, aby dowiedzieć się, które raporty i pulpity nawigacyjne są nieużywane, możesz użyć jednego z kilku narzędzi analizy biznesowej, które zapewniają statystyki użycia.

Jeśli starszy magazyn danych działa od lat, istnieje szansa, że masz setki, jeśli nie tysiące raportów istnieje. Warto skompilowanie spisu raportów i pulpitów nawigacyjnych oraz zidentyfikowanie ich celów biznesowych i statystyk użycia.

W przypadku nieużywanych raportów określ, czy należy je zlikwidować w celu zmniejszenia nakładu pracy w zakresie migracji. Kluczowym pytaniem podczas podejmowania decyzji o zlikwidowaniu nieużywanego raportu jest to, czy raport jest nieużywany, ponieważ ludzie nie wiedzą, że istnieje, ponieważ nie oferuje żadnej wartości biznesowej, czy też został zastąpiony przez inny raport.

Migrowanie raportów na podstawie wartości biznesowej

Samo użycie nie zawsze jest dobrym wskaźnikiem wartości biznesowej. Warto wziąć pod uwagę zakres, w jakim szczegółowe informacje raportu przyczyniają się do wartości biznesowej. Jednym ze sposobów, aby to zrobić, jest ocena rentowności każdej decyzji biznesowej, która opiera się na raporcie i zakresie polegania. Jednak te informacje są mało prawdopodobne, aby być łatwo dostępne w większości organizacji.

Innym sposobem oceny wartości biznesowej jest przyjrzenie się dopasowaniu raportu ze strategią biznesową. Strategia biznesowa ustawiona przez kierownictwo zazwyczaj określa strategiczne cele biznesowe (SB), kluczowe wskaźniki wydajności (KPI), cele wskaźników KPI, które należy osiągnąć, i kto jest odpowiedzialny za ich osiągnięcie. Raport, za pomocą którego raport jest współtworzyny przez obiekty SBO, na przykład zmniejszenie oszustw, lepsze zaangażowanie klientów i zoptymalizowane operacje biznesowe. Następnie można określić priorytety migracji raportów i pulpitów nawigacyjnych skojarzonych z celami o wysokim priorytcie. W ten sposób początkowa migracja może dostarczyć wartość biznesową w obszarze strategicznym.

Innym sposobem oceny wartości biznesowej jest klasyfikowanie raportów i pulpitów nawigacyjnych jako operacyjnych, taktycznych lub strategicznych do identyfikowania, na jakim poziomie biznesowym są używane. SBOs wymagają współtworzenia na wszystkich tych poziomach. Wiedząc, które raporty i pulpity nawigacyjne są używane, na jakim poziomie i z jakimi celami są skojarzone, możesz skupić się na początkowej migracji na wartość biznesową o wysokim priorycie. Poniższa tabela celów strategii biznesowej umożliwia ocenę raportów i pulpitów nawigacyjnych.

Poziom	Nazwa raportu/pulpitu nawigacyjnego	Cel biznesowy	Używany przez dział	Częstotliwość użycia	Priorytet biznesowy
Strategiczne
Taktyczne
Operacyjne

Narzędzia do odnajdywania metadanych, takie jak Azure Data Catalog, umożliwiają użytkownikom biznesowym tagowanie i ocenianie źródeł danych w celu wzbogacania metadanych dla tych źródeł danych w celu ułatwienia ich odnajdywania i klasyfikacji. Możesz użyć metadanych raportu lub pulpitu nawigacyjnego, aby ułatwić zrozumienie jego wartości biznesowej. Bez takich narzędzi zrozumienie współtworzenia raportów i pulpitów nawigacyjnych do wartości biznesowej może być czasochłonnym zadaniem niezależnie od tego, czy przeprowadzasz migrację, czy nie.

Migrowanie raportów na podstawie strategii migracji danych

Jeśli strategia migracji opiera się najpierw na migrowaniu składnic danych, kolejność migracji składnicy danych wpłynie na to, które raporty i pulpity nawigacyjne są najpierw migrowane. Jeśli strategia jest oparta na wartości biznesowej, kolejność migracji składnic danych do Azure Synapse będzie odzwierciedlać priorytety biznesowe. Narzędzia do odnajdywania metadanych mogą pomóc w zaimplementowaniu strategii, pokazując, które tabele składnicy danych dostarczają dane, dla których raportów.

Porada

Strategia migracji danych ma wpływ na to, które raporty i wizualizacje są najpierw migrowane.

Problemy z niezgodnością migracji, które mogą mieć wpływ na raporty i wizualizacje

Narzędzia analizy biznesowej tworzą raporty, pulpity nawigacyjne i inne wizualizacje, wydając zapytania SQL, które uzyskują dostęp do tabel fizycznych i/lub widoków w magazynie danych lub składnicy danych. Podczas migracji starszego magazynu danych do Azure Synapse kilka czynników może mieć wpływ na łatwość migracji raportów, pulpitów nawigacyjnych i innych wizualizacji. Czynniki te obejmują:

• Niezgodność schematu między środowiskami.

• Niezgodności SQL między środowiskami.

Niezgodności schematu

Podczas migracji niezgodności schematu w tabelach magazynu danych lub składnicy danych, które dostarczają dane dla raportów, pulpitów nawigacyjnych i innych wizualizacji, mogą być następujące:

• Niestandardowe typy tabel w starszym magazynie danych DBMS, które nie mają odpowiednika w Azure Synapse.

• Typy danych w starszych systemach DBMS magazynu danych, które nie mają odpowiedników w Azure Synapse.

W większości przypadków istnieje obejście niezgodności. Na przykład można migrować dane w nieobsługiwanym typie tabeli do standardowej tabeli z odpowiednimi typami danych i indeksowane lub partycjonowane w kolumnie daty/godziny. Podobnie może być możliwe reprezentowanie nieobsługiwanych typów danych w innym typie kolumny i wykonywanie obliczeń w Azure Synapse w celu uzyskania tych samych wyników.

Porada

Niezgodności schematu obejmują starsze typy tabel DBMS magazynu i typy danych, które nie są obsługiwane w Azure Synapse.

Aby zidentyfikować raporty, których dotyczą niezgodności schematu, uruchom zapytania względem wykazu systemu starszego magazynu danych, aby zidentyfikować tabele z nieobsługiwanymi typami danych. Następnie możesz użyć metadanych z narzędzia do analizy biznesowej, aby zidentyfikować raporty, które uzyskują dostęp do danych w tych tabelach. Aby uzyskać więcej informacji na temat identyfikowania niezgodności typów obiektów, zobacz Nieobsługiwane typy obiektów bazy danych Oracle.

Porada

Wykonaj zapytanie względem katalogu systemu starszej wersji systemu DBMS magazynu, aby zidentyfikować niezgodności schematu z Azure Synapse.

Wpływ niezgodności schematu na raporty, pulpity nawigacyjne i inne wizualizacje może być mniejszy niż sądzisz, ponieważ wiele narzędzi analizy biznesowej nie obsługuje mniej ogólnych typów danych. W związku z tym starszy magazyn danych może już mieć widoki, które CAST nieobsługiwane typy danych mają bardziej ogólne typy.

Niezgodności SQL

Podczas migracji niezgodności SQL mogą mieć wpływ na dowolny raport, pulpit nawigacyjny lub inną wizualizację w aplikacji lub narzędziu, które:

• Uzyskuje dostęp do starszych widoków systemu DBMS magazynu danych, które zawierają zastrzeżone funkcje SQL, które nie mają odpowiedników w Azure Synapse.

• Problemy z zapytaniami SQL, które obejmują zastrzeżone funkcje SQL, specyficzne dla dialektu SQL starszego środowiska, które nie mają odpowiedników w Azure Synapse.

Ocenianie wpływu niezgodności sql na portfolio raportowania

Portfolio raportów może obejmować osadzone usługi zapytań, raporty, pulpity nawigacyjne i inne wizualizacje. Nie należy polegać na dokumentacji skojarzonej z tymi elementami, aby ocenić wpływ niezgodności SQL na migrację portfela raportowania do Azure Synapse. Należy użyć bardziej precyzyjnego sposobu oceny wpływu niezgodności sql.

Znajdowanie niezgodności sql za pomocą instrukcji EXPLAIN

Niezgodności SQL można znaleźć, przeglądając dzienniki ostatnich działań SQL w starszym magazynie danych Oracle. Użyj skryptu, aby wyodrębnić reprezentatywny zestaw instrukcji SQL do pliku. Następnie należy prefiksować każdą instrukcję SQL za pomocą EXPLAIN instrukcji i uruchomić te EXPLAIN instrukcje w Azure Synapse. Wszystkie instrukcje SQL zawierające zastrzeżone nieobsługiwane rozszerzenia SQL zostaną odrzucone przez Azure Synapse podczas EXPLAIN wykonywania instrukcji. Takie podejście umożliwia ocenę zakresu niezgodności sql.

Metadane ze starszego magazynu danych DBMS mogą również ułatwić identyfikowanie niezgodnych widoków. Tak jak poprzednio, przechwyć reprezentatywny zestaw instrukcji SQL z odpowiednich dzienników, prefiksuj każdą instrukcję SQL za pomocą instrukcji i uruchom te EXPLAIN instrukcje w Azure Synapse, aby zidentyfikować widoki z niezgodnym językiem EXPLAIN SQL.

Porada

Zmierz wpływ niezgodności SQL, zbierając pliki dziennika DBMS i uruchamiając EXPLAIN instrukcje.

Testowanie migracji raportów i pulpitów nawigacyjnych do usługi Azure Synapse Analytics

Kluczowym elementem migracji magazynu danych jest testowanie raportów i pulpitów nawigacyjnych w Azure Synapse w celu sprawdzenia, czy migracja działała. Zdefiniuj serię testów i zestaw wymaganych wyników dla każdego testu, który zostanie uruchomiony w celu zweryfikowania powodzenia. Testowanie i porównywanie raportów i pulpitów nawigacyjnych w istniejących i zmigrowanych systemach magazynu danych do następujących elementów:

• Określ, czy jakiekolwiek zmiany schematu wprowadzone podczas migracji miały wpływ na możliwość uruchamiania raportów, raportów wyników lub odpowiednich wizualizacji raportu. Przykładem zmiany schematu jest mapowanie niezgodnego typu danych na równoważny typ danych obsługiwany w Azure Synapse.

• Sprawdź, czy wszyscy użytkownicy są migrowane.

• Sprawdź, czy wszystkie role są migrowane, a użytkownicy są przypisani do tych ról.

• Sprawdź, czy wszystkie uprawnienia zabezpieczeń dostępu do danych są migrowane w celu zapewnienia migracji listy kontroli dostępu (ACL).

• Zapewnij spójne wyniki dla wszystkich znanych zapytań, raportów i pulpitów nawigacyjnych.

• Upewnij się, że dane i migracja ETL są kompletne i wolne od błędów.

• Upewnij się, że prywatność danych jest podtrzymana.

• Testowanie wydajności i skalowalności.

• Testowanie funkcji analitycznych.

Porada

Testowanie i dostrajanie wydajności w celu zminimalizowania kosztów obliczeniowych.

Aby uzyskać informacje na temat migrowania użytkowników, grup użytkowników, ról i uprawnień, zobacz Zabezpieczenia, dostęp i operacje migracji oracle.

Automatyzowanie testowania jak najwięcej, aby każdy test był powtarzalny i obsługiwał spójne podejście do oceny wyników testów. Automatyzacja działa dobrze w przypadku znanych zwykłych raportów i może być zarządzana za pośrednictwem potoków Azure Synapse lub aranżacji Azure Data Factory. Jeśli masz już zestaw zapytań testowych na potrzeby testowania regresji, możesz użyć istniejących narzędzi do testowania po migracji.

Porada

Najlepszym rozwiązaniem jest utworzenie zestawu testów automatycznych w celu powtarzania testów.

Analiza ad hoc i raportowanie są trudniejsze i wymagają kompilacji zestawu testów w celu sprawdzenia, czy te same raporty i pulpity nawigacyjne przed i po migracji są spójne. Jeśli znajdziesz niespójności, możliwość porównywania pochodzenia metadanych w oryginalnych i migrowanych systemach podczas testowania migracji staje się kluczowa. To porównanie może wyróżniać różnice i wskazywać, skąd pochodzą niespójności, gdy wykrywanie za pomocą innych środków jest trudne.

Porada

Skorzystaj z narzędzi, które porównują pochodzenie metadanych, aby zweryfikować wyniki.

Analizowanie pochodzenia danych w celu zrozumienia zależności między raportami, pulpitami nawigacyjnymi i danymi

Zrozumienie pochodzenia danych jest krytycznym czynnikiem w pomyślnej migracji raportów i pulpitów nawigacyjnych. Pochodzenie to metadane przedstawiające podróż zmigrowanych danych, dzięki czemu można śledzić jego ścieżkę z raportu lub pulpitu nawigacyjnego do źródła danych. Pochodzenie danych pokazuje, jak dane są przesyłane od punktu do punktu, jego lokalizacji w magazynie danych i/lub składce danych oraz z których raportów i pulpitów nawigacyjnych są używane. Pochodzenie danych może pomóc zrozumieć, co dzieje się z danymi podczas przechodzenia przez różne magazyny danych, takie jak pliki i bazy danych, różne potoki ETL i raporty. Gdy użytkownicy biznesowi mają dostęp do pochodzenia danych, zwiększa zaufanie, zaszczepia zaufanie i obsługuje świadome decyzje biznesowe.

Porada

Możliwość uzyskiwania dostępu do metadanych i pochodzenia danych z raportów do źródła danych ma kluczowe znaczenie dla sprawdzenia, czy zmigrowane raporty działają prawidłowo.

W środowiskach magazynu danych z wieloma dostawcami analitycy biznesowi w zespołach analizy biznesowej mogą mapować pochodzenie danych. Jeśli na przykład używasz różnych dostawców na potrzeby procesu ETL, magazynu danych i raportowania, a każdy dostawca ma własne repozytorium metadanych, ustalenie, skąd pochodzi określony element danych w raporcie, może być trudne i czasochłonne.

Porada

Narzędzia, które automatyzują zbieranie metadanych i pokazują kompleksową pochodzenie danych w środowisku wielu dostawców, są przydatne podczas migracji.

Aby bezproblemowo przeprowadzić migrację ze starszego magazynu danych do Azure Synapse, użyj kompleksowej linii danych, aby udowodnić migrację podobną do podobnych podczas porównywania raportów i pulpitów nawigacyjnych generowanych przez poszczególne środowiska. Aby pokazać kompleksową podróż do danych, należy przechwycić i zintegrować metadane z kilku narzędzi. Posiadanie dostępu do narzędzi, które obsługują automatyczne odnajdywanie metadanych i pochodzenie danych, pomaga identyfikować zduplikowane raporty lub procesy ETL oraz znajdować raporty, które opierają się na przestarzałych, wątpliwych lub nieistniejących źródłach danych. Te informacje umożliwiają zmniejszenie liczby migrowanych raportów i procesów ETL.

Możesz również porównać kompleksową pochodzenie raportu w Azure Synapse do kompleksowego pochodzenia tego samego raportu w starszym środowisku, aby sprawdzić różnice, które mogły przypadkowo wystąpić podczas migracji. Ten typ porównania jest wyjątkowo przydatny, gdy trzeba przetestować i zweryfikować powodzenie migracji.

Wizualizacja pochodzenia danych nie tylko skraca czas, nakład pracy i błąd w procesie migracji, ale także umożliwia szybszą migrację.

Korzystając z narzędzi automatycznego odnajdywania metadanych i pochodzenia danych, które porównują pochodzenie danych, możesz sprawdzić, czy raport w Azure Synapse utworzony na podstawie zmigrowanych danych jest generowany w taki sam sposób w starszym środowisku. Ta funkcja pomaga również określić:

• Jakie dane należy zmigrować, aby zapewnić pomyślne wykonanie raportu i pulpitu nawigacyjnego w Azure Synapse.

• Jakie przekształcenia zostały wykonane, aby zapewnić pomyślne wykonanie w Azure Synapse.

• Jak zmniejszyć duplikowanie raportów.

Zautomatyzowane odnajdywanie metadanych i narzędzia pochodzenia danych znacznie upraszczają proces migracji, ponieważ pomagają firmom lepiej znać swoje zasoby danych i wiedzieć, co należy zmigrować do Azure Synapse w celu osiągnięcia solidnego środowiska raportowania.

Kilka narzędzi ETL zapewnia kompleksową możliwość pochodzenia, dlatego sprawdź, czy istniejące narzędzie ETL ma tę możliwość, jeśli planujesz używać go z Azure Synapse. Azure Synapse potoki lub usługa Data Factory obsługują możliwość wyświetlania pochodzenia w przepływach mapowania. Partnerzy firmy Microsoft udostępniają również zautomatyzowane odnajdywanie metadanych, pochodzenie danych i narzędzia do porównywania pochodzenia danych.

Migrowanie warstw semantycznych narzędzi analizy biznesowej do usługi Azure Synapse Analytics

Niektóre narzędzia analizy biznesowej mają to, co jest nazywane semantyczną warstwą metadanych. Ta warstwa upraszcza użytkownikom biznesowym dostęp do bazowych fizycznych struktur danych w magazynie danych lub bazie danych składnicy danych. Warstwa metadanych semantycznych upraszcza dostęp, udostępniając obiekty wysokiego poziomu, takie jak wymiary, miary, hierarchie, metryki obliczeniowe i sprzężenia. Obiekty wysokiego poziomu używają terminów biznesowych znanych analitykom biznesowym i mapują je na fizyczne struktury danych w magazynie danych lub składnicy danych.

Porada

Niektóre narzędzia analizy biznesowej mają warstwy semantyczne, które upraszczają użytkownikom biznesowym dostęp do fizycznych struktur danych w magazynie danych lub składnicy danych.

W przypadku migracji magazynu danych można wymusić zmianę nazw kolumn lub tabel. Na przykład oracle zezwala na # znak w nazwach tabel, ale Azure Synapse zezwala # tylko jako prefiks nazwy tabeli na wskazanie tabeli tymczasowej. W programie Oracle tabele TYMCZASOWE nie muszą mieć nazwy "#", ale w usłudze Synapse muszą. W takich przypadkach może być konieczne przerobienie zmian mapowań tabeli.

Aby osiągnąć spójność w wielu narzędziach analizy biznesowej, utwórz uniwersalną warstwę semantyczną przy użyciu serwera wirtualizacji danych, który znajduje się między narzędziami analizy biznesowej i aplikacjami i Azure Synapse. Na serwerze wirtualizacji danych należy używać typowych nazw danych dla obiektów wysokiego poziomu, takich jak wymiary, miary, hierarchie i sprzężenia. Dzięki temu można skonfigurować wszystko, w tym pola obliczeniowe, sprzężenia i mapowania, tylko raz, a nie w każdym narzędziu. Następnie wskaż wszystkie narzędzia analizy biznesowej na serwerze wirtualizacji danych.

Porada

Użyj wirtualizacji danych, aby utworzyć wspólną warstwę semantyczną, aby zagwarantować spójność we wszystkich narzędziach analizy biznesowej w środowisku Azure Synapse.

Dzięki wirtualizacji danych uzyskujesz spójność we wszystkich narzędziach analizy biznesowej i przerywasz zależność między narzędziami analizy biznesowej i aplikacjami oraz podstawowymi fizycznymi strukturami danych w Azure Synapse. Partnerzy firmy Microsoft mogą pomóc w osiągnięciu spójności na platformie Azure. Na poniższym diagramie pokazano, jak wspólne słownictwo na serwerze wirtualizacji danych pozwala wielu narzędziom analizy biznesowej zobaczyć wspólną warstwę semantyczną.

Wnioski

W przypadku migracji magazynu danych metodą "lift and shift" większość raportów, pulpitów nawigacyjnych i innych wizualizacji powinna być łatwo migrowana.

Podczas migracji ze starszego środowiska może się okazać, że dane w starszym magazynie danych lub tabelach składnic danych są przechowywane w nieobsługiwanych typach danych. Można też znaleźć starsze widoki magazynu danych, które zawierają zastrzeżony język SQL bez odpowiedników w Azure Synapse. Jeśli tak, należy rozwiązać te problemy, aby zapewnić pomyślną migrację do Azure Synapse.

Nie należy polegać na dokumentacji obsługiwanej przez użytkownika, aby zidentyfikować, gdzie znajdują się problemy. Zamiast tego należy używać EXPLAIN instrukcji, ponieważ są one szybkim, pragmatycznym sposobem identyfikowania niezgodności SQL. Przepracuj niezgodne instrukcje SQL, aby osiągnąć równoważną funkcjonalność w Azure Synapse. Ponadto użyj zautomatyzowanych narzędzi do odnajdywania metadanych i pochodzenia, aby zrozumieć zależności, znaleźć zduplikowane raporty i zidentyfikować nieprawidłowe raporty, które opierają się na przestarzałych, wątpliwych lub nieistniejących źródłach danych. Użyj narzędzi pochodzenia, aby porównać pochodzenie danych, aby sprawdzić, czy raporty działające w starszym środowisku magazynu danych są generowane identycznie w Azure Synapse.

Nie migruj raportów, których już nie używasz. Dane użycia narzędzia analizy biznesowej mogą pomóc w ustaleniu, które raporty nie są używane. W przypadku raportów, pulpitów nawigacyjnych i innych wizualizacji, które chcesz migrować, migrować wszystkich użytkowników, grupy użytkowników, role i uprawnienia. Jeśli używasz wartości biznesowej do kierowania strategią migracji raportów, skojarz raporty ze strategicznymi celami biznesowymi i priorytetami, aby ułatwić identyfikowanie wkładu szczegółowych informacji w raporcie do określonych celów. Jeśli migrujesz składnicę danych według składnicy danych, użyj metadanych, aby zidentyfikować, które raporty są zależne od tabel i widoków, dzięki czemu możesz podjąć świadomą decyzję o tym, które składnice danych mają najpierw migrować.

Porada

Zidentyfikuj niezgodności na wczesnym etapie, aby ocenić zakres nakładu pracy nad migracją. Migrowanie użytkowników, ról grup i przypisań uprawnień. Migrowanie raportów i wizualizacji, które są używane i przyczyniają się do wartości biznesowej.

Podczas migracji mogą wystąpić zmiany strukturalne w modelu danych magazynu danych lub składnicy danych. Rozważ użycie wirtualizacji danych do ochrony narzędzi i aplikacji analizy biznesowej przed zmianami strukturalnymi. Dzięki wirtualizacji danych można użyć wspólnego słownictwa do zdefiniowania wspólnej warstwy semantycznej. Wspólna warstwa semantyczna gwarantuje spójne wspólne nazwy danych, definicje, metryki, hierarchie i sprzężenia we wszystkich narzędziach i aplikacjach analizy biznesowej w nowym środowisku Azure Synapse.

Następne kroki

Aby dowiedzieć się więcej na temat minimalizowania problemów z bazą danych SQL, zobacz następny artykuł z tej serii: Minimalizowanie problemów z bazą danych SQL na potrzeby migracji bazy danych Oracle.