Migracja danych, etL i ładowanie migracji Netezza

Ten artykuł jest drugą częścią siedmioczęściowej serii, która zawiera wskazówki dotyczące migracji z platformy Netezza do usługi Azure Synapse Analytics. Celem tego artykułu są najlepsze rozwiązania dotyczące migracji ETL i ładowania.

Zagadnienia dotyczące migracji danych

Wstępne decyzje dotyczące migracji danych z Netezza

Podczas migracji magazynu danych Netezza należy zadać kilka podstawowych pytań związanych z danymi. Przykład:

• Czy nieużywane struktury tabel powinny być migrowane?

• Jakie jest najlepsze podejście do migracji w celu zminimalizowania ryzyka i wpływu użytkowników?

• Podczas migrowania składnic danych: pozostać fizycznym lub wirtualnym?

W następnych sekcjach omówiono te punkty w kontekście migracji z Netezza.

Czy przeprowadzić migrację nieużywanych tabel?

Porada

W starszych systemach nie jest niczym niezwykłym, aby tabele stały się nadmiarowe w czasie — w większości przypadków nie trzeba ich migrować.

Warto migrować tylko tabele, które są używane w istniejącym systemie. Tabele, które nie są aktywne, można zarchiwizować, a nie zmigrować, aby dane są dostępne w razie potrzeby w przyszłości. Najlepiej użyć systemowych metadanych i plików dziennika, a nie dokumentacji, aby określić, które tabele są używane, ponieważ dokumentacja może być nieaktualna.

Jeśli ta opcja jest włączona, tabele historii zapytań Netezza zawierają informacje, które mogą określić, kiedy dana tabela została ostatnio użyta do podjęcia decyzji o tym, czy tabela jest kandydatem do migracji.

Oto przykładowe zapytanie, które wyszukuje użycie określonej tabeli w danym przedziale czasu:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

To zapytanie używa funkcji FORMAT_TABLE_ACCESS pomocnika i cyfry na końcu $v_hist_table_access_3 widoku, aby dopasować zainstalowaną wersję historii zapytań.

Jakie jest najlepsze podejście do migracji w celu zminimalizowania ryzyka i wpływu na użytkowników?

To pytanie pojawia się często, ponieważ firmy mogą chcieć zmniejszyć wpływ zmian w modelu danych magazynu danych w celu zwiększenia elastyczności. Firmy często widzą możliwość dalszej modernizacji lub przekształcania danych podczas migracji ETL. Takie podejście niesie ze sobą większe ryzyko, ponieważ zmienia jednocześnie wiele czynników, co utrudnia porównywanie wyników starego systemu z nowym. Wprowadzanie tutaj zmian w modelu danych może również mieć wpływ na zadania ETL nadrzędne lub podrzędne w innych systemach. Ze względu na to ryzyko lepiej jest przeprojektować tę skalę po migracji magazynu danych.

Nawet jeśli model danych został celowo zmieniony w ramach ogólnej migracji, dobrym rozwiązaniem jest migrowanie istniejącego modelu zgodnie z założeniami do Azure Synapse, zamiast ponownego inżynierii na nowej platformie. Takie podejście minimalizuje wpływ na istniejące systemy produkcyjne, a jednocześnie korzysta z wydajności i elastycznej skalowalności platformy Azure w przypadku jednorazowych zadań ponownej inżynierii.

Podczas migracji z platformy Netezza często istniejący model danych jest już odpowiedni do migracji do Azure Synapse.

Porada

Najpierw przeprowadź migrację istniejącego modelu, nawet jeśli w przyszłości zaplanowano zmianę modelu danych.

Migrowanie składnic danych: pobyt fizyczny lub wirtualny?

Porada

Wirtualizacja składnic danych może zaoszczędzić na magazynie i przetwarzaniu zasobów.

W starszych środowiskach magazynu danych Netezza powszechną praktyką jest utworzenie kilku składnic danych, które mają strukturę zapewniającą dobrą wydajność dla zapytań samoobsługowych ad hoc i raportów dla danego działu lub funkcji biznesowej w organizacji. W związku z tym składninica danych zwykle składa się z podzbioru magazynu danych i zawiera zagregowane wersje danych w postaci, która umożliwia użytkownikom łatwe wykonywanie zapytań o te dane z szybkim czasem odpowiedzi za pomocą przyjaznych dla użytkownika narzędzi do zapytań, takich jak Microsoft Power BI, Tableau lub MicroStrategy. Ten formularz jest zazwyczaj modelem danych wymiarowych. Jednym z zastosowań składnic danych jest uwidocznienie danych w formie użytecznej, nawet jeśli bazowy model danych magazynu jest czymś innym, takim jak magazyn danych.

Można użyć oddzielnych składnic danych dla poszczególnych jednostek biznesowych w organizacji, aby zaimplementować niezawodne systemy zabezpieczeń danych, zezwalając tylko użytkownikom na dostęp do określonych składnic danych, które są dla nich istotne, oraz eliminując, zaciemniając lub anonimizując poufne dane.

Jeśli te składnice danych są implementowane jako tabele fizyczne, będą wymagały dodatkowych zasobów magazynu do ich przechowywania oraz dodatkowego przetwarzania w celu ich regularnego kompilowania i odświeżania. Ponadto dane w składnicy będą aktualne tylko jako ostatnia operacja odświeżania i dlatego mogą być nieodpowiednie dla wysoce niestabilnych pulpitów nawigacyjnych danych.

Porada

Wydajność i skalowalność Azure Synapse umożliwia wirtualizację bez poświęcania wydajności.

Wraz z pojawieniem się stosunkowo tanich skalowalnych architektur MPP, takich jak Azure Synapse, i charakterystycznych cech wydajności takich architektur, może być to, że można zapewnić funkcjonalność składnicy danych bez konieczności tworzenia wystąpienia składnicy jako zestawu tabel fizycznych. Jest to osiągane przez efektywne wirtualizację składnic danych za pośrednictwem widoków SQL w głównym magazynie danych lub za pośrednictwem warstwy wirtualizacji przy użyciu funkcji, takich jak widoki na platformie Azure lub produkty wizualizacji partnerów firmy Microsoft. Takie podejście upraszcza lub eliminuje konieczność dodatkowego przetwarzania magazynu i agregacji oraz zmniejsza ogólną liczbę obiektów bazy danych do zmigrowania.

Istnieje kolejna potencjalna korzyść z tego podejścia. Implementując logikę agregacji i sprzężenia w warstwie wirtualizacji oraz przedstawiając zewnętrzne narzędzia raportowania za pośrednictwem zwirtualizowanego widoku, przetwarzanie wymagane do utworzenia tych widoków jest "wypychane" do magazynu danych, co jest na ogół najlepszym miejscem do uruchamiania sprzężeń, agregacji i innych powiązanych operacji na dużych woluminach danych.

Podstawowymi sterownikami do wybierania implementacji wirtualnej składnic danych w przypadku składnic danych fizycznych są:

• Większa elastyczność: wirtualna składninica danych jest łatwiejsza do zmiany niż tabele fizyczne i skojarzone procesy ETL.

• Niższy całkowity koszt posiadania: zwirtualizowana implementacja wymaga mniejszej liczby magazynów danych i kopii danych.

• Eliminacja zadań ETL w celu migracji i uproszczenia architektury magazynu danych w środowisku zwirtualizowanym.

• Wydajność: chociaż fizyczne składnice danych były historycznie bardziej wydajne, produkty wirtualizacji wdrażają teraz inteligentne techniki buforowania w celu ograniczenia ryzyka.

Migracja danych z platformy Netezza

Informacje o danych

Częścią planowania migracji jest szczegółowe zrozumienie ilości danych, które należy migrować, ponieważ może to mieć wpływ na decyzje dotyczące podejścia do migracji. Użyj metadanych systemowych, aby określić miejsce fizyczne zajęte przez "nieprzetworzone dane" w tabelach do zmigrowania. W tym kontekście "dane pierwotne" oznaczają ilość miejsca używanego przez wiersze danych w tabeli, z wyłączeniem narzutów, takich jak indeksy i kompresja. Jest to szczególnie istotne w przypadku największych tabel faktów, ponieważ zwykle będą one składać się z ponad 95% danych.

Możesz uzyskać dokładną liczbę danych do zmigrowania dla danej tabeli, wyodrębniając reprezentatywną próbkę danych — na przykład milion wierszy — do nieskompresowanego, płaskiego pliku danych ASCII. Następnie użyj rozmiaru tego pliku, aby uzyskać średni rozmiar danych pierwotnych na wiersz tej tabeli. Na koniec pomnóż ten średni rozmiar przez łączną liczbę wierszy w pełnej tabeli, aby nadać nieprzetworzonemu rozmiarowi danych dla tabeli. Użyj tego nieprzetworzonego rozmiaru danych w planowaniu.

Mapowanie typu danych Netezza

Porada

Oceń wpływ nieobsługiwanych typów danych w ramach fazy przygotowania.

Większość typów danych Netezza ma bezpośredni odpowiednik w Azure Synapse. W poniższej tabeli przedstawiono te typy danych wraz z zalecanym podejściem do ich mapowania.

Typ danych Netezza	Azure Synapse typ danych
BIGINT	BIGINT
BINARY VARYING(n)	Varbinary(n)
BOOLEAN	BITOWYCH
BYTEINT	TINYINT
RÓŻNE ZNAKI (n)	Varchar(n)
ZNAK(n)	CHAR(n)
DATE	DATE(date)
LICZBA DZIESIĘTNA(p,s)	LICZBA DZIESIĘTNA(p,s)
PODWÓJNA PRECYZJA	FLOAT
FLOAT(n)	FLOAT(n)
LICZBA CAŁKOWITA	INT
INTERWAŁ	Typy danych INTERVAL nie są obecnie obsługiwane bezpośrednio w usłudze Azure Synapse Analytics, ale można je obliczyć przy użyciu funkcji czasowych, takich jak DATEDIFF.
PIENIĄDZE	PIENIĄDZE
ZNAK NARODOWY RÓŻNI SIĘ (n)	Nvarchar(n)
ZNAK NARODOWY (n)	NCHAR(n)
NUMERIC(p,s)	NUMERIC(p,s)
LICZBA RZECZYWISTA	LICZBA RZECZYWISTA
SMALLINT	SMALLINT
ST_GEOMETRY(n)	Typy danych przestrzennych, takie jak ST_GEOMETRY, nie są obecnie obsługiwane w usłudze Azure Synapse Analytics, ale dane mogą być przechowywane jako VARCHAR lub VARBINARY.
CZAS	CZAS
CZAS ZE STREFĄ CZASOWĄ	DATETIMEOFFSET
TIMESTAMP	DATETIME

Użyj metadanych z tabel wykazu Netezza, aby określić, czy którykolwiek z tych typów danych musi zostać zmigrowany, i zezwól na to w planie migracji. Ważne widoki metadanych na platformie Netezza dla tego typu zapytania to:

• _V_USER: widok użytkownika zawiera informacje o użytkownikach w systemie Netezza.

• _V_TABLE: widok tabeli zawiera listę tabel utworzonych w systemie wydajności Netezza.

• _V_RELATION_COLUMN: widok katalogu systemu kolumny relacji zawiera kolumny dostępne w tabeli.

• _V_OBJECTS: widok obiektów zawiera listę różnych obiektów, takich jak tabele, widok, funkcje itd., które są dostępne w netezza.

Na przykład to zapytanie Netezza SQL pokazuje kolumny i typy kolumn:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

Kwerendę można zmodyfikować, aby wyszukiwać wszystkie tabele pod kątem wystąpień nieobsługiwanych typów danych.

Azure Data Factory można użyć do przenoszenia danych ze starszego środowiska Netezza. Aby uzyskać więcej informacji, zobacz ŁĄCZNIK IBM Netezza.

Zewnętrzni dostawcy oferują narzędzia i usługi do automatyzacji migracji, w tym mapowanie typów danych zgodnie z wcześniejszym opisem. Ponadto narzędzia ETL innych firm, takie jak Informatica lub Talend, już używane w środowisku Netezza, mogą implementować wszystkie wymagane przekształcenia danych. W następnej sekcji omówiono migrację istniejących procesów ETL innych firm.

Zagadnienia dotyczące migracji ETL

Wstępne decyzje dotyczące migracji netezza ETL

Porada

Zaplanuj z wyprzedzeniem podejście do migracji ETL i korzystaj z obiektów platformy Azure tam, gdzie jest to konieczne.

W przypadku przetwarzania ETL/ELT starsze magazyny danych Netezza mogą używać niestandardowych skryptów za pomocą narzędzi Netezza, takich jak nzsql i nzload, lub narzędzi ETL innych firm, takich jak Informatica lub Ab Initio. Czasami magazyny danych Netezza używają kombinacji metod ETL i ELT, które ewoluowały w czasie. Podczas planowania migracji do Azure Synapse należy określić najlepszy sposób wdrożenia wymaganego przetwarzania ETL/ELT w nowym środowisku przy jednoczesnym zminimalizowaniu kosztów i ryzyka. Aby dowiedzieć się więcej na temat przetwarzania ETL i ELT, zobacz Podejście projektowe ELT i ETL.

W poniższych sekcjach omówiono opcje migracji i przedstawiono zalecenia dotyczące różnych przypadków użycia. Ten schemat blokowy zawiera podsumowanie jednego podejścia:

Pierwszym krokiem jest zawsze utworzenie spisu procesów ETL/ELT, które należy zmigrować. Podobnie jak w przypadku innych kroków, istnieje możliwość, że standardowe funkcje platformy Azure "wbudowane" sprawiają, że migracja niektórych istniejących procesów jest niepotrzebna. W celach związanych z planowaniem ważne jest zrozumienie skali migracji do wykonania.

W poprzednim schemacie blokowym decyzja 1 odnosi się do decyzji wysokiego poziomu o tym, czy przeprowadzić migrację do całkowicie natywnego środowiska platformy Azure. Jeśli przenosisz się do całkowicie natywnego środowiska platformy Azure, zalecamy ponowne zaprojektowanie przetwarzania ETL przy użyciu potoków i działań w usłudze Azure Data Factory lub Azure Synapse Pipelines. Jeśli nie przenosisz się do całkowicie natywnego środowiska platformy Azure, decyzja 2 dotyczy tego, czy istniejące narzędzie ETL innej firmy jest już używane.

Porada

Wykorzystanie inwestycji w istniejące narzędzia innych firm w celu zmniejszenia kosztów i ryzyka.

Jeśli narzędzie ETL innej firmy jest już używane, a zwłaszcza jeśli istnieje duża inwestycja w umiejętności lub kilka istniejących przepływów pracy i harmonogramów używa tego narzędzia, decyzja 3 polega na tym, czy narzędzie może efektywnie obsługiwać Azure Synapse jako środowisko docelowe. W idealnym przypadku narzędzie będzie zawierać "natywne" łączniki, które mogą korzystać z obiektów platformy Azure, takich jak PolyBase lub COPY INTO, w celu najbardziej wydajnego ładowania danych. Istnieje sposób wywoływania procesu zewnętrznego, takiego jak PolyBase lub COPY INTO, i przekazywania odpowiednich parametrów. W takim przypadku skorzystaj z istniejących umiejętności i przepływów pracy, Azure Synapse jako nowe środowisko docelowe.

Jeśli zdecydujesz się zachować istniejące narzędzie ETL innej firmy, mogą istnieć korzyści wynikające z uruchamiania tego narzędzia w środowisku platformy Azure (zamiast na istniejącym lokalnym serwerze ETL) i Azure Data Factory obsługiwać ogólną aranżację istniejących przepływów pracy. Jedną z zalet jest to, że mniej danych należy pobrać z platformy Azure, przetworzyć, a następnie przekazać z powrotem na platformę Azure. Dlatego decyzja 4 polega na tym, czy pozostawić istniejące narzędzie uruchomione zgodnie z rzeczywistym działaniem, czy przenieść je do środowiska platformy Azure, aby uzyskać korzyści związane z kosztami, wydajnością i skalowalnością.

Re-engineer existing Netezza-specific scripts (Ponowne inżynieryj istniejące skrypty specyficzne dla platformy Netezza)

Jeśli niektóre lub wszystkie istniejące przetwarzanie ETL/ELT magazynu Netezza są obsługiwane przez niestandardowe skrypty korzystające z narzędzi specyficznych dla netezza, takich jak nzsql lub nzload, te skrypty muszą zostać ponownie zakodowane dla nowego środowiska Azure Synapse. Podobnie, jeśli procesy ETL zostały zaimplementowane przy użyciu procedur składowanych w Netezza, należy je również ponownie zakodować.

Porada

Spis zadań ETL do zmigrowania powinien zawierać skrypty i procedury składowane.

Niektóre elementy procesu ETL są łatwe do zmigrowania, na przykład przez proste zbiorcze ładowanie danych do tabeli przejściowej z pliku zewnętrznego. Może być nawet możliwe zautomatyzowanie tych części procesu, na przykład przy użyciu technologii PolyBase zamiast nzload. Inne części procesu, które zawierają dowolne złożone procedury SQL i/lub składowane, zajmie więcej czasu, aby ponownie wykonać inżyniera.

Jednym ze sposobów testowania usługi Netezza SQL pod kątem zgodności z Azure Synapse jest przechwycenie kilku reprezentatywnych instrukcji SQL z historii zapytań Netezza, a następnie prefiks tych zapytań za pomocą EXPLAINpolecenia , a następnie — przy założeniu, że model danych podobnie jak w przypadku migrowanych danych w Azure Synapse — uruchom te EXPLAIN instrukcje w Azure Synapse. Każdy niezgodny program SQL wygeneruje błąd, a informacje o błędzie mogą określić skalę zadania odzyskiwania.

Partnerzy firmy Microsoft oferują narzędzia i usługi do migrowania programu Netezza SQL i procedur składowanych do Azure Synapse.

Korzystanie z narzędzi ETL innych firm

Jak opisano w poprzedniej sekcji, w wielu przypadkach istniejący starszy system magazynu danych zostanie już wypełniony i utrzymywany przez produkty ETL innych firm. Aby uzyskać listę partnerów integracji danych firmy Microsoft dla Azure Synapse, zobacz Partnerzy integracji danych.

Ładowanie danych z netezza

Opcje dostępne podczas ładowania danych z netezza

Porada

Narzędzia innych firm mogą uprościć i zautomatyzować proces migracji, a tym samym zmniejszyć ryzyko.

Jeśli chodzi o migrację danych z magazynu danych Netezza, istnieją pewne podstawowe pytania związane z ładowaniem danych, które należy rozwiązać. Musisz zdecydować, w jaki sposób dane zostaną fizycznie przeniesione z istniejącego lokalnego środowiska Netezza do Azure Synapse w chmurze i które narzędzia będą używane do przenoszenia i ładowania. Rozważ następujące pytania, które zostały omówione w następnych sekcjach.

• Czy wyodrębnisz dane do plików, czy przeniesiesz je bezpośrednio za pośrednictwem połączenia sieciowego?

• Czy będziesz organizować proces z systemu źródłowego, czy ze środowiska docelowego platformy Azure?

• Jakich narzędzi użyjesz do automatyzacji procesu i zarządzania nim?

Transfer danych za pośrednictwem plików lub połączenia sieciowego?

Porada

Zapoznaj się z woluminami danych, które mają zostać zmigrowane, i dostępną przepustowością sieci, ponieważ te czynniki wpływają na decyzję dotyczącą podejścia do migracji.

Po utworzeniu tabel baz danych do zmigrowania w Azure Synapse można przenieść dane, aby wypełnić te tabele ze starszego systemu Netezza i do nowego środowiska. Istnieją dwa podstawowe podejścia:

• Wyodrębnianie pliku: wyodrębnianie danych z tabel Netezza do plików prostych, zwykle w formacie CSV, za pośrednictwem narzędzia nzsql z opcją -o lub za pomocą instrukcji CREATE EXTERNAL TABLE . Jeśli jest to możliwe, użyj tabeli zewnętrznej, ponieważ jest to najbardziej wydajne pod względem przepływności danych. Poniższy przykład sql tworzy plik CSV za pośrednictwem tabeli zewnętrznej:

  CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
  AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
  

  Użyj tabeli zewnętrznej, jeśli eksportujesz dane do zainstalowanego systemu plików na lokalnym hoście Netezza. Jeśli eksportujesz dane do maszyny zdalnej, na której zainstalowano protokół JDBC, ODBC lub OLEDB, opcja "remotesource odbc" jest klauzulą USING .

  Takie podejście wymaga miejsca, aby wylądować wyodrębnione pliki danych. Miejsce może być lokalne dla źródłowej bazy danych Netezza (jeśli jest dostępna wystarczająca ilość miejsca) lub zdalne w Azure Blob Storage. Najlepszą wydajność jest osiągana, gdy plik jest zapisywany lokalnie, ponieważ pozwala to uniknąć narzutów sieciowych.

  Aby zminimalizować wymagania dotyczące magazynu i transferu sieciowego, dobrym rozwiązaniem jest kompresowanie wyodrębnionych plików danych przy użyciu narzędzia takiego jak gzip.

  Po wyodrębnieniu pliki proste można przenieść do Azure Blob Storage (pogrupowane z docelowym wystąpieniem Azure Synapse) lub załadować bezpośrednio do Azure Synapse przy użyciu technologii PolyBase lub COPY INTO. Metoda fizycznego przenoszenia danych z lokalnego magazynu do środowiska chmury platformy Azure zależy od ilości danych i dostępnej przepustowości sieci.

  Firma Microsoft udostępnia różne opcje przenoszenia dużych ilości danych, w tym narzędzie AzCopy do przenoszenia plików między siecią do usługi Azure Storage, usługi Azure ExpressRoute na potrzeby przenoszenia danych zbiorczych za pośrednictwem połączenia z siecią prywatną oraz usługi Azure Data Box dla plików przenoszonych do fizycznego urządzenia magazynu, które następnie jest wysyłane do centrum danych platformy Azure na potrzeby ładowania. Aby uzyskać więcej informacji, zobacz Transfer danych.

• Bezpośrednie wyodrębnianie i ładowanie między sieciami: docelowe środowisko platformy Azure wysyła żądanie wyodrębniania danych, zwykle za pomocą polecenia SQL, do starszego systemu Netezza w celu wyodrębnienia danych. Wyniki są wysyłane przez sieć i ładowane bezpośrednio do Azure Synapse, bez konieczności rozmieszczania danych do plików pośrednich. Czynnikiem ograniczającym w tym scenariuszu jest zwykle przepustowość połączenia sieciowego między bazą danych Netezza a środowiskiem platformy Azure. W przypadku bardzo dużych ilości danych takie podejście może nie być praktyczne.

Istnieje również podejście hybrydowe, które korzysta z obu metod. Na przykład można użyć metody wyodrębniania sieci bezpośredniej dla mniejszych tabel wymiarów i przykładów większych tabel faktów, aby szybko zapewnić środowisko testowe w Azure Synapse. W przypadku dużych tabel faktów historycznych można użyć metody wyodrębniania i transferu plików przy użyciu usługi Azure Data Box.

Orkiestracja z Platformy Netezza czy platformy Azure?

Zalecane podejście podczas przechodzenia do Azure Synapse polega na organizowaniu wyodrębniania i ładowania danych ze środowiska platformy Azure przy użyciu Azure Synapse Pipelines lub Azure Data Factory, a także skojarzonych narzędzi, takich jak PolyBase lub COPY INTO, w celu najbardziej wydajnego ładowania danych. To podejście wykorzystuje możliwości platformy Azure i zapewnia łatwą metodę tworzenia potoków ładowania danych wielokrotnego użytku.

Inne zalety tego podejścia obejmują ograniczony wpływ na system Netezza podczas procesu ładowania danych, ponieważ proces zarządzania i ładowania działa na platformie Azure oraz możliwość automatyzacji procesu przy użyciu potoków ładowania danych opartych na metadanych.

Jakich narzędzi można użyć?

Zadanie przekształcania i przenoszenia danych jest podstawową funkcją wszystkich produktów ETL. Jeśli jeden z tych produktów jest już używany w istniejącym środowisku Netezza, użycie istniejącego narzędzia ETL może uprościć migrację danych z Netezza do Azure Synapse. W tym podejściu przyjęto założenie, że narzędzie ETL obsługuje Azure Synapse jako środowisko docelowe. Aby uzyskać więcej informacji na temat narzędzi obsługujących Azure Synapse, zobacz Partnerzy integracji danych.

Jeśli używasz narzędzia ETL, rozważ uruchomienie tego narzędzia w środowisku platformy Azure, aby skorzystać z wydajności, skalowalności i kosztów chmury platformy Azure oraz zwolnienia zasobów w centrum danych Netezza. Kolejną korzyścią jest zmniejszenie przenoszenia danych między chmurą a środowiskami lokalnymi.

Podsumowanie

Podsumowując, nasze zalecenia dotyczące migrowania danych i skojarzonych procesów ETL z Netezza do Azure Synapse są następujące:

• Zaplanuj z wyprzedzeniem, aby zapewnić pomyślne ćwiczenie dotyczące migracji.

• Utwórz szczegółowy spis danych i procesów, które mają być migrowane tak szybko, jak to możliwe.

• Użyj systemowych metadanych i plików dziennika, aby uzyskać dokładne informacje na temat danych i użycia procesów. Nie polegaj na dokumentacji, ponieważ może być nieaktualna.

• Zapoznaj się z woluminami danych, które mają być migrowane, oraz przepustowość sieci między lokalnym centrum danych a środowiskami chmury platformy Azure.

• Korzystaj ze standardowych "wbudowanych" funkcji platformy Azure, aby zminimalizować obciążenie migracji.

• Identyfikowanie i zrozumienie najbardziej wydajnych narzędzi do wyodrębniania i ładowania danych zarówno w środowiskach Netezza, jak i na platformie Azure. Użyj odpowiednich narzędzi w każdej fazie procesu.

• Korzystanie z obiektów platformy Azure, takich jak Azure Synapse Pipelines lub Azure Data Factory, do organizowania i automatyzowania procesu migracji przy jednoczesnym zminimalizowaniu wpływu na system Netezza.

Następne kroki

Aby dowiedzieć się więcej na temat operacji dostępu do zabezpieczeń, zobacz następny artykuł w tej serii: Zabezpieczenia, dostęp i operacje migracji Netezza.