Migracja z usługi Azure Data Explorer (ADX) do rozwiązania Fabric Real-Time Intelligence (Eventhouse)

W tym artykule pokazano, jak stopniowo migrować obciążenia analityczne z usługi Azure Data Explorer do usługi Eventhouse w usłudze Real-Time Intelligence w Microsoft Fabric bez przestojów. Zacznij od używania sieci szkieletowej jako warstwy zapytania , podczas gdy usługa ADX kontynuuje pozyskiwanie danych w celu eksplorowania funkcji sieci szkieletowej. Gdy będziesz gotowy, całkowicie przejdź do usługi Fabric, przenosząc do niej schemat i pozyskiwanie danych.

Jeśli nie możesz poczekać na starzenie się danych w usłudze ADX i musisz skopiować je do usługi Eventhouse, rozważ open source narzędzie Kusto Copy.

Korzystanie z danych ADX w usłudze Fabric

Zachowaj usługę ADX tylko do pozyskiwania i przenieś zapytanie do sieci szkieletowej przy użyciu jednej z tych dwóch metod, aby używać danych ADX z sieci szkieletowej bez duplikowania danych.

• Skrót do bazy danych Fabric (obserwator)

  Utwórz skrót do bazy danych w usłudze Azure Data Explorer i wykonuj zapytania bez konieczności migrowania danych do Fabric. Skrót bazy danych w obciążeniu Real-Time Intelligence w usłudze Fabric to osadzone odwołanie w bazie danych Kusto Query Language (KQL) do źródłowej bazy danych w usłudze Azure Data Explorer. Zachowanie skrótu do bazy danych jest podobne do bazy danych podążającej. Jest tylko do odczytu, synchronizuje nowe dane z niewielkim opóźnieniem (od kilku sekund do kilku minut) i umożliwia wszystkim elementom Fabric wyświetlanie danych ADX i wykonywanie na nich zapytań bez konieczności ich ponownego ładowania.

• Dołączanie klastra ADX jako źródła z możliwością wykonywania zapytań

  W usłudze Fabric upewnij się, że masz połączenie z klastrem ADX. Dodaj źródło usługi Azure Data Explorer w zbiorze zapytań KQL, co umożliwia niektórym elementom Fabric, takim jak zbiór zapytań i pulpity nawigacyjne w czasie rzeczywistym, wykonywanie zapytań względem danych ADX. Aby uzyskać więcej informacji, zobacz Wykonywanie zapytań do danych w zestawie zapytań KQL — Microsoft Fabric.

  Wypróbuj możliwości platformy Fabric, takie jak generowanie zapytań wspomagane przez Copilot, Notesniki, Activator i raporty Power BI na danych ADX. Uruchamiaj wszystkie pulpity i zapytania w usłudze Fabric, podczas gdy pozyskiwanie danych nadal odbywa się w usłudze ADX. Gdy wszystko będzie gotowe do pełnej migracji, wykonaj następne kroki.

Kroki migracji na wysokim poziomie

Wykonaj następujące kroki, aby przeprowadzić migrację z ADX do Fabric:

1. Utwórz nową bazę danych KQL w usłudze Fabric przy użyciu schematu ADX
2. Utwórz widok z operatorem union, uzyskujący dostęp do obu tabel w bazie danych KQL i bazie danych ADX
3. Przekierowywanie punktów końcowych zapytań do bazy danych KQL w usłudze Fabric Eventhouse
4. Przełącz pozyskiwanie danych do Fabric
5. Wycofywanie klastra ADX

W poniższych sekcjach znajdują się szczegółowe informacje o poszczególnych krokach.

Utwórz bazę danych KQL w usłudze Fabric przy użyciu schematu ADX

1. Utwórz pustą bazę danych KQL w usłudze Fabric Eventhouse, która docelowo zastąpi bazę danych ADX. Musi mieć ten sam schemat tabel i funkcji co baza danych ADX. Instrukcje znajdują się w artykule Tworzenie magazynu zdarzeń i bazy danych KQL.

2. Replikowanie schematu

   Użyj Sync Kusto lub wyeksportuj schemat bazy danych ADX, aby odtworzyć go w bazie danych KQL w usłudze Fabric. SyncKusto to dedykowane narzędzie, które synchronizuje schematy bazy danych Kusto (tabele, funkcje itp.) między środowiskami.

   Alternatywnie można uruchomić polecenie KQL: .show database schema as csl script w usłudze ADX, który generuje skrypt wszystkich definicji tabeli, funkcji i zasad, a następnie uruchomić wygenerowany skrypt w bazie danych KQL w Fabric przy użyciu polecenia .execute database script.

3. Weryfikowanie schematu

   Upewnij się, że wszystkie tabele, kolumny, typy danych i odpowiednie zasady (przechowywanie, buforowanie itp.) w bazie danych KQL są zgodne z tymi w bazie danych ADX. W tym momencie baza danych KQL sieci szkieletowej jest pusta, ale gotowa do odbierania danych i nadal można wysyłać zapytania do usługi ADX przy użyciu metod z sekcji Eksploruj dane ADX w sieci szkieletowej .

Tworzenie widoków unii na potrzeby bezproblemowego dostępu do danych

Aby uniknąć przerw w migracji danych, utwórz widoki KQL w sieci szkieletowej, które łączą dane zarówno ze starej bazy danych ADX, jak i nowej bazy danych KQL sieci szkieletowej. Takie podejście umożliwia zapytaniom zwracanie kompletnego zestawu danych podczas przejścia:

1. Zdefiniuj widoki unii

   Dla każdej tabeli utwórz w usłudze Fabric funkcję składowaną (z elementem .create function with (view=true)), która łączy za pomocą operatora UNION tabelę Fabric z odpowiednią tabelą ADX. Nadaj funkcji nazwę dokładnie taką samą jak tabela, aby jawnie ją zastąpić. Na przykład w przypadku tabeli MyTableutwórz funkcję przy użyciu następującego polecenia:

   .create function with (view=true) MyTable() {
       MyTable 
       | union cluster("YourADXCluster").database("YourDatabase").MyTable
   }
   

   Ten widok zwraca sumę zbiorów lokalnej tabeli MyTable w bazie danych Fabric KQL, która jest obecnie pusta lub do której napływają nowe dane, oraz zdalnej tabeli MyTable w bazie danych ADX.

   Ponieważ nazwa widoku to MyTable, każde zapytanie lub raport używający tej nazwy tabeli automatycznie wysyła zapytania do obu źródeł.

   Fabric i ADX mogą znajdować się w różnych klastrach lub tenantach. Jeśli polecenie tworzenia zgłasza błąd dotyczący odwołania zewnętrznego, użyj opcji skipvalidation=true podczas tworzenia funkcji, która jest czasami wymagana w przypadku funkcji międzyklastrowych.

2. Testowanie widoku

   Uruchom zapytanie zliczające lub przykładowe zapytanie na widoku (na przykład MyTable | count), aby upewnić się, że zwraca dane z ADX. Baza danych KQL w usłudze Fabric jest nadal pusta, ale gdy w następnym kroku przeprowadzisz migrację pozyskiwania danych, widok zacznie zwracać zarówno stare, jak i nowe rekordy.

Przekierowywanie punktów końcowych zapytań do bazy danych KQL w usłudze Fabric Eventhouse

Teraz zaktualizuj narzędzia i aplikacje, aby kierować zapytania do nowej bazy danych KQL w Fabric zamiast do bazy danych ADX:

1. Aktualizowanie parametrów połączenia

   Zmienianie aplikacji analitycznych, zapytań KQL lub raportów usługi Power BI w celu używania punktu końcowego bazy danych KQL (identyfikatora URI zapytania) zamiast klastra ADX. Zapytania pozostają takie same, ponieważ nazwy tabel i KQL nie uległy zmianie, ale są teraz uruchamiane w usłudze Fabric. Ze względu na widok unii utworzony w poprzednim kroku użytkownicy, którzy wysyłają zapytania do bazy danych KQL sieci szkieletowej, nadal pobierają wszystkie dane historyczne z usługi ADX za pośrednictwem widoku oraz wszelkie nowe dane pozyskane do sieci szkieletowej.

2. Testowanie raportów i aplikacji

   Upewnij się, że panele i skrypty zwracają oczekiwane wyniki z bazy danych KQL w usłudze Fabric. Wydajność może się nieco różnić. Fabric może buforować niektóre dane ADX, jeśli użyto skrótu. Ten krok faktycznie przenosi punkty końcowe zapytań do Fabric. Od tej chwili wszystkie operacje odczytu i zapytań odbywają się w Fabric.

Przełącz pozyskiwanie danych do usługi Fabric

Teraz, gdy zapytania są obsługiwane przez usługę Fabric, kieruj przychodzące strumienie danych do usługi Fabric:

1. Przekieruj potoki pozyskiwania danych

   Zmień wszystkich producentów danych, takich jak urządzenia IoT, zadania ETL (wyodrębniania, przekształcania i ładowania danych), połączenia usługi Event Hubs i inne, które wcześniej zapisywały dane do bazy danych ADX, tak aby zapisywały je do bazy danych KQL w usłudze Fabric. Ten krok może obejmować zmianę adresów URL klastra, ustawień uwierzytelniania lub aktualizację parametrów połączenia w usłudze Azure Data Factory, Stream Analytics lub aplikacjach niestandardowych w celu używania bazy danych KQL z punktem końcowym pozyskiwania danych lub identyfikatorem URI.

2. Weryfikowanie nowego przepływu danych

   Sprawdź, czy nowe rekordy wylądowały w tabelach w bazie danych KQL. Baza danych KQL w Fabric zaczyna gromadzić dane. Ponieważ używasz widoków łączonych, w usłudze Fabric zapytania nadal pokazują ujednolicony zestaw danych. W miarę upływu czasu dane w usłudze ADX stają się nieaktualne, ponieważ żadne nowe dane nie są pozyskiwane do usługi ADX po tym przełączniku.

Wycofywanie klastra ADX

Jeśli masz pewność, że wszystkie wymagane dane są dostępne w usłudze Fabric, zlikwidowaj stare zasoby ADX:

1. Usuwanie odwołań do unii

   Zmień lub usuń widoki UNION, aby zapytania nie pobierały danych z klastra ADX. Na przykład zaktualizuj definicję funkcji tak, aby MyTable { MyTable } używała tylko danych lokalnych, lub upuść funkcję, jeśli tabela fizyczna w usłudze Fabric zawiera wszystkie dane. Sprawdź, czy zapytania i pulpity nawigacyjne działają zgodnie z oczekiwaniami przy użyciu danych wyłącznie z Fabric.

2. Archiwizowanie lub przesyłanie danych historycznych (w razie potrzeby)

   Jeśli w ADX nadal znajdują się dane historyczne, które nie zostały przeniesione (na przykład jeśli nie poczekano, aż wygasną), rozważ wyeksportowanie tych danych do Fabric przed wyłączeniem. W przeciwnym razie kontynuuj, jeśli dane w usłudze ADX wykraczają poza wymagania dotyczące przechowywania.

3. Likwidowanie usługi ADX

   Gdy Fabric obsługuje zarówno zapytania, jak i pozyskiwanie danych, wyłącz lub usuń klaster ADX, aby obniżyć koszty. Wszyscy użytkownicy powinni teraz połączyć się z Fabric.

Podsumowanie

Wykonując kroki opisane w tym artykule, przeprowadzisz migrację z usługi ADX do sieci szkieletowej z minimalnymi zakłóceniami. Zacznij od przeniesienia warstwy konsumpcji do Fabric, co zapewni dostęp do funkcji takich jak Copilot, Power BI, Notebooks i Activator, a następnie stopniowo przenoś warstwę zaplecza do Fabric. Teraz analiza danych w czasie rzeczywistym (Eventhouse) na platformie Fabric obsługuje zarówno pozyskiwanie, jak i wykonywanie zapytań względem Twoich danych, a usługa ADX nie jest używana.