Migrowanie z usługi Azure Data Explorer (ADX) do analizy Real-Time sieci szkieletowej (Eventhouse)

W tym artykule pokazano, jak stopniowo przenosić obciążenia analityczne z usługi Azure Data Explorer do usługi Eventhouse w usłudze Fabric Real-Time analizy 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 wszystko będzie gotowe, przeprowadź migrację w pełni , przenosząc schemat i pozyskiwanie do sieci szkieletowej.

Korzystanie z danych ADX w sieci szkieletowej

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 bazy danych sieci szkieletowej (kontynuacja)

  Utwórz skrót bazy danych do bazy danych usługi Azure Data Explorer i wykonaj zapytanie bez migrowania danych do sieci szkieletowej. Skrót do bazy danych w obciążeniu analizy Real-Time sieci szkieletowej to osadzone odwołanie w bazie danych Języka zapytań Kusto (KQL) do źródłowej bazy danych w usłudze Azure Data Explorer. Zachowanie skrótu bazy danych jest podobne do bazy danych obserwowanej. Jest to tylko do odczytu, synchronizuje nowe dane z niewielkim opóźnieniem (w sekundach do minut) i umożliwia wszystkim elementom sieci szkieletowej wyświetlanie i wykonywanie zapytań dotyczących danych ADX bez ich ponownego pozyskiwania.

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

  W sieci szkieletowej upewnij się, że masz połączenie z klastrem ADX. Dodaj źródło usługi Azure Data Explorer w zestawie zapytań KQL, dzięki czemu niektóre elementy sieci szkieletowej, takie jak zestaw zapytań i pulpity nawigacyjne w czasie rzeczywistym, wysyłają zapytania o dane ADX. Aby uzyskać więcej informacji, zobacz Query data in a KQL queryset - Microsoft Fabric (Wykonywanie zapytań w zestawie zapytań KQL — Microsoft Fabric).

  Funkcje usługi Try Fabric, takie jak generowanie zapytań wspomaganych przez copilot, notesy, aktywacja i raporty usługi Power BI na danych usługi ADX. Uruchamiaj wszystkie pulpity nawigacyjne i zapytania w usłudze Fabric, podczas gdy pozyskiwanie jest nadal wykonywane w usłudze ADX. Gdy wszystko będzie gotowe do pełnej migracji, wykonaj następne kroki.

Ogólne kroki migracji

Wykonaj następujące kroki, aby przeprowadzić migrację z usługi ADX do sieci szkieletowej:

1. Tworzenie nowej bazy danych KQL w sieci szkieletowej przy użyciu schematu ADX
2. Tworzenie widoku z operatorem unii, który uzyskuje dostęp do tabeli w bazie danych KQL i tabeli w bazie danych ADX
3. Przekierowywanie punktów końcowych zapytań do bazy danych KQL w usłudze Fabric Eventhouse
4. Przełączanie pozyskiwania danych do sieci szkieletowej
5. Wycofywanie klastra ADX

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

Tworzenie bazy danych KQL w sieci szkieletowej przy użyciu schematu ADX

1. Utwórz pustą bazę danych KQL w bazie zdarzeń sieci szkieletowej, która ostatecznie zastępuje bazę danych ADX. Musi mieć ten sam schemat tabel i funkcji co baza danych ADX. Aby uzyskać instrukcje, zobacz Tworzenie magazynu zdarzeń i bazy danych KQL.

2. Replikowanie schematu

   Użyj narzędzia Sync Kusto lub wyeksportuj schemat z bazy danych ADX, aby odtworzyć go w bazie danych KQL sieci szkieletowej. 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 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 sieci szkieletowej.

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. Definiowanie widoków unii

   Dla każdej tabeli utwórz funkcję przechowywaną w usłudze Fabric (z elementem .create function with (view=true)) zawierającą tabelę Sieć szkieletowa 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 unię lokalną MyTable w bazie danych KQL sieci szkieletowej, która jest obecnie pusta lub odbiera nowe dane oraz tabelę MyTable zdalną 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ł.

   Sieć szkieletowa i usługa ADX mogą znajdować się w różnych klastrach lub dzierżawach. Jeśli polecenie tworzenia skarży się na odwołanie zewnętrzne, użyj skipvalidation=true opcji w tworzeniu funkcji, która jest czasami wymagana w przypadku funkcji między klastrami.

2. Testowanie widoku

   Uruchom liczbę lub przykładowe zapytanie w widoku (na przykład ), aby upewnić się, MyTable | countże zwraca dane z usługi ADX. Baza danych KQL sieci szkieletowej jest teraz pusta, ale podczas migracji pozyskiwania w następnym kroku widok zaczyna 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 wykonywać zapytania dotyczące nowej bazy danych KQL sieci szkieletowej zamiast 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 język KQL nie uległ 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 pulpity nawigacyjne i skrypty uzyskują wyniki zgodnie z oczekiwaniami z bazy danych KQL sieci szkieletowej. Wydajność może się nieco różnić. Sieć szkieletowa może buforowania niektórych danych ADX, jeśli użyto skrótu. Ten krok skutecznie przenosi punkty końcowe zapytania do sieci szkieletowej. Od tego miejsca wszystkie operacje odczytu/zapytania są wykonywane w sieci szkieletowej.

Przełączanie pozyskiwania danych do sieci szkieletowej

Dzięki zapytaniom obsługiwanym przez usługę Fabric przekierowuj przychodzące strumienie danych do sieci szkieletowej:

1. Potoki pozyskiwania punktów

   Zmień wszystkich producentów danych, takich jak urządzenia IoT, zadania wyodrębniania i przekształcania obciążenia (ETL, extract-transform-load), połączenia usługi Event Hubs i inne, które wcześniej pozyskiwały do bazy danych ADX, aby pozyskiwać je do bazy danych KQL sieci szkieletowej. Ten krok może obejmować zmianę adresów URL klastra, uwierzytelniania lub zaktualizowanie parametrów połączenia w usłudze Azure Data Factory, usłudze Stream Analytics lub niestandardowych aplikacjach w celu używania punktu końcowego pozyskiwania lub identyfikatora URI bazy danych KQL.

2. Weryfikowanie nowego przepływu danych

   Sprawdź, czy nowe rekordy wylądowały w tabelach w bazie danych KQL. Baza danych KQL w sieci szkieletowej rozpoczyna zbieranie danych. Ponieważ używasz widoków unii, zapytania w usłudze Fabric 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 upuść widoki unii, aby zapytania nie ściągały 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 w przypadku danych tylko sieci szkieletowej.

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

   Jeśli w usłudze ADX nadal istnieją dane historyczne, które nie zostały przeniesione (na przykład jeśli nie czekasz na jej starzenie się), rozważ wyeksportowanie tych danych do sieci szkieletowej przed zamknięciem. W przeciwnym razie kontynuuj, jeśli dane w usłudze ADX wykraczają poza wymagania dotyczące przechowywania.

3. Likwidowanie usługi ADX

   Gdy sieć szkieletowa obsługuje zapytania i pozyskiwanie, zamknij lub usuń klaster ADX, aby obniżyć koszty. Wszyscy użytkownicy powinni teraz łączyć się z siecią szkieletową.

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 zużycia do sieci szkieletowej, która odblokuje funkcje, takie jak Copilot, Power BI, Notesy i Aktywacja, a następnie stopniowo przesuwa zaplecze do sieci szkieletowej. Teraz analiza w czasie rzeczywistym (Eventhouse) sieci Szkieletowej obsługuje pozyskiwanie i wykonywanie zapytań dotyczących danych, a usługa ADX nie jest używana.