Wizualizacja i raportowanie migracji teradata

Ten artykuł jest drugą częścią siedmioczęściowej serii, która zawiera wskazówki dotyczące migracji z usługi Teradata do usługi Azure Synapse Analytics. Celem tego artykułu są 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 innych firm do analizy biznesowej

Organizacje uzyskują dostęp do magazynów danych i składnic danych przy użyciu różnych narzędzi i aplikacji do 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 do analizy biznesowej innych firm od innych dostawców.

• Aplikacje analizy niestandardowej 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óra z kolei wykonuje zapytania dotyczące danych w magazynie danych lub składnic danych.

• Interaktywne narzędzia programistyczne do nauki o danych, takie jak notesy platformy Azure Synapse Spark, usługa Azure Machine Learning, program 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ą zwracać te same wyniki na Azure Synapse jak w starszym środowisku magazynu danych.

Aby zapewnić spójne wyniki po migracji, wszystkie narzędzia analizy biznesowej i zależności aplikacji muszą działać po przeprowadzeniu migracji schematu magazynu danych i 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 bazy danych magazynu danych i składnic danych w Azure Synapse.

• Wszyscy użytkownicy Azure Synapse.

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

• Wszystkie role do Azure Synapse.

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

• Przypisania użytkowników, ról i uprawnień w celu zdublowania elementów z istniejącego magazynu 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 zmigrowanym systemie i zostały omówione bardziej szczegółowo w temacie Zabezpieczenia, dostęp i operacje migracji teradata.

Porada

Aby migracja raportów i wizualizacji zakończyła się pomyślnie, należy najpierw przeprowadzić migrację istniejących użytkowników, grup użytkowników, ról i przypisań uprawnień zabezpieczeń dostępu.

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

Użytkownicy biznesowi będą oczekiwać bezproblemowej migracji bez niespodzianek, które nie spowodują zniszczenia zaufania do zmigrowanego systemu na Azure Synapse. Należy zachować ostrożność przed wszelkimi obawami, że użytkownicy mogą mieć dobrą komunikację. Użytkownicy będą oczekiwać, że:

• Struktura tabeli pozostaje taka sama, gdy jest bezpośrednio określona w zapytaniach.

• Nazwy tabel i kolumn pozostają takie same, gdy są bezpośrednio określane w zapytaniach. Na przykład pola obliczeniowe zdefiniowane w kolumnach w narzędziach analizy biznesowej nie powinny wieść się 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 w celu zapewnienia, że zachowanie zapytań pozostaje takie samo.

Porada

Komunikacja i zaangażowanie użytkowników biznesowych mają kluczowe znaczenie dla sukcesu.

Jeśli narzędzia analizy biznesowej wysyłają zapytania do widoków w bazowym magazynie danych lub bazie danych składnic danych, 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ą odpowiedników 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ą spowodować niezgodności, które mają wpływ na raporty i pulpity nawigacyjne analizy biznesowej.

Inne problemy, takie jak zachowanie NULL wartości lub odmian typu danych na platformach DBMS, należy przetestować, aby mieć pewność, że nawet niewielkie różnice nie istnieją w wynikach obliczeń. Zminimalizuj te problemy i podejmij 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 migracji wizualizacji i raportów. Potrzebujesz zestawu testów i uzgodnionych danych testowych do uruchamiania i ponownego uruchamiania testów w obu środowiskach. Wykorzystanie testowe jest również przydatne, a kilka z nich zostało wymienionych w tym przewodniku. Ponadto ważne jest, aby zaangażować użytkowników biznesowych w aspekt testowania migracji, aby zachować pewność siebie i utrzymać ich zaangażowanie i część projektu.

Porada

Użyj powtarzalnych testów, aby zapewnić pomyślną migrację raportów, pulpitów nawigacyjnych i innych wizualizacji.

Możesz myśleć o przełączeniu 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 móc uruchamiać porównania w obu środowiskach. Alternatywnie, jeśli dostawca istniejących narzędzi do analizy biznesowej oferuje swój produkt na platformie Azure, możesz spróbować go tam. Dotyczy to również aplikacji działających lokalnie, które osadzają usługę BI lub wywołujeją serwer analizy biznesowej na żądanie, na przykład żądając "raportu bezgłowego" z danymi XML lub JSON.

Jest tu wiele do przemyślenia, 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że być kuszące spełnienie długoterminowych wymagań, takich 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 zastosować technikę elastycznego modelowania danych 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 składnicami danych. Na poniższym diagramie pokazano, jak wirtualizacja danych może ukryć migrację przed użytkownikami.

Wirtualizacja danych przerywa zależność między użytkownikami biznesowymi korzystającymi z narzędzi do analizy biznesowej samoobsługi i fizycznym schematem bazowego magazynu danych i składnic 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. A jeśli wprowadzisz zmiany strukturalne, wystarczy zaktualizować mapowania między magazynem danych lub składnicami danych a wszystkimi tabelami wirtualnymi. Dzięki wirtualizacji danych użytkownicy pozostają nieświadomi zmian strukturalnych. Partnerzy firmy Microsoft udostępniają oprogramowanie do wirtualizacji danych.

Identyfikowanie raportów o wysokim priorytcie, które mają być najpierw migrowane

Kluczowym pytaniem podczas migracji istniejących raportów i pulpitów nawigacyjnych do Azure Synapse jest to, które z nich należy najpierw migrować. Taka decyzja może mieć kilka czynników, takich jak:

• 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. Wszyscy użytkownicy mogą wykonywać następujące korzyści:

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

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 prawdopodobieństwo, że istnieją setki, jeśli nie tysiące, istniejących raportów. Warto skompilowanie spisu raportów i pulpitów nawigacyjnych oraz zidentyfikowanie ich celu biznesowego 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 Teradata.

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 Teradata. 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 na potrzeby migracji teradata.

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 jest kluczowym czynnikiem w pomyślnej migracji raportów i pulpitów nawigacyjnych. Pochodzenie to metadane, które pokazują podróż zmigrowanych danych, dzięki czemu można śledzić jego ścieżkę z raportu lub pulpitu nawigacyjnego po powrocie do źródła danych. Pochodzenie pokazuje, w jaki sposób dane podróżowane z punktu do punktu, jego lokalizacji w magazynie danych i/lub składce danych oraz z których raportów i pulpitów nawigacyjnych korzystają. Pochodzenie 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, instilluje zaufanie i obsługuje świadome decyzje biznesowe.

Porada

Możliwość uzyskiwania dostępu do metadanych i pochodzenia danych z raportów z powrotem 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 do celów 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 w środowisku wielu dostawców, są cenne podczas migracji.

Aby bezproblemowo przeprowadzić migrację ze starszego magazynu danych do Azure Synapse, użyj kompleksowej linii danych, aby udowodnić migrację podobną do podobnej podczas porównywania raportów i pulpitów nawigacyjnych generowanych przez każde środowisko. Aby pokazać kompleksową podróż do danych, musisz przechwycić i zintegrować metadane z kilku narzędzi. Mając dostęp do narzędzi obsługujących automatyczne odnajdywanie metadanych i pochodzenie danych, ułatwia identyfikowanie zduplikowanych raportów lub procesów ETL oraz znajdowanie raportów, 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, możesz sprawdzić, czy raport w Azure Synapse utworzony na podstawie migrowanych danych jest generowany w taki sam sposób w starszym środowisku. Ta funkcja ułatwia również określenie:

• Jakie dane należy migrować, 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ć zasoby danych i wiedzieć, co należy migrować 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 go używać z Azure Synapse. potoki Azure Synapse lub 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 znane jako semantyczna warstwa metadanych. Ta warstwa upraszcza użytkownikom biznesowym dostęp do podstawowych fizycznych struktur danych w magazynie danych lub bazie danych mart. 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, które są znane analitykom biznesowym i mapują na fizyczne struktury danych w magazynie danych lub w magazynie danych.

Porada

Niektóre narzędzia analizy biznesowej mają warstwy semantyczne, które upraszczają dostęp użytkowników biznesowych do fizycznych struktur danych w magazynie danych lub w magazynie danych.

W przypadku migracji magazynu danych zmiany nazw kolumn lub nazw tabel mogą zostać wymuszone. Na przykład w usłudze Teradata nazwy tabel mogą mieć wartość "#". W Azure Synapse wyrażenie "#" jest dozwolone tylko jako prefiks nazwy tabeli w celu wskazania tabeli tymczasowej. W usłudze Teradata tabele TYMCZASOWE nie muszą mieć znaku "#" w nazwie, ale w usłudze Synapse muszą. W takich przypadkach może być konieczne przerobienie zmian mapowań tabeli.

Aby uzyskać 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 a 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

Wirtualizacja danych umożliwia utworzenie wspólnej warstwy semantycznej w celu zagwarantowania spójności 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 i aplikacjami analizy biznesowej a 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 typowe 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żna stwierdzić, że dane w starszym magazynie danych lub tabelach składnic danych są przechowywane w nieobsługiwanych typach danych. Możesz też znaleźć starsze widoki magazynu danych, które zawierają zastrzeżony język SQL bez odpowiedników w Azure Synapse. Jeśli tak, musisz rozwiązać te problemy, aby zapewnić pomyślną migrację do Azure Synapse.

Nie polegaj na dokumentacji obsługiwanej przez użytkownika, aby zidentyfikować, gdzie znajdują się problemy. Zamiast tego należy używać EXPLAIN instrukcji, ponieważ są to szybki, pragmatyczny sposób identyfikowania niezgodności SQL. Przerobij 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, aby sprawdzić, czy raporty działające w starszym środowisku magazynu danych są tworzone identycznie w Azure Synapse.

Nie migruj raportów, których już nie używasz. Dane użycia narzędzia analizy biznesowej mogą pomóc określić, 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 napędzania strategii migracji raportów, skojarz raporty ze strategicznymi celami biznesowymi i priorytetami, aby pomóc zidentyfikować wkład szczegółowych informacji raportu 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 marty danych mają być migrowane jako pierwsze.

Porada

Zidentyfikuj niezgodności na wczesnym etapie, aby ocenić zakres nakładu pracy związanych z migracją. Migrowanie użytkowników, ról grupy 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, aby chronić narzędzia i aplikacje analizy biznesowej przed zmianami strukturalnymi. Wirtualizacja danych umożliwia zdefiniowanie wspólnej warstwy semantycznej przy użyciu wspólnego słownictwa. 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: Minimalizacja problemów z bazą danych SQL na potrzeby migracji teradata.