Migracja projektu do Lakehouse v2
Projekty możesz przenosić z Lakehouse v1 do Lakehouse v2 pojedynczo. Pozostałe projekty w tym samym obszarze roboczym nadal działają na v1, dopóki ich również nie zmigrujesz, więc możesz zmigrować jeden projekt i nie ruszać reszty.
Migracja obejmuje tabele projektu i wszystko, co na nich zbudowano: zapytania, wyrażenia, widoki, zbiory danych Superset, kolumny obliczane, metryki i reguły dostępu do wierszy.
Zanim zaczniesz
Dział zatytułowany „Zanim zaczniesz”- Pozycja Migruj projekt do Lakehouse v2… pojawia się w menu Narzędzia dla członków, którzy mogą edytować projekty. Projekt może zmigrować tylko jego Architekt: rozpoczęcie, zaplanowanie, anulowanie i cofnięcie migracji wymagają dostępu Architekta do projektu.
- Potrzebujesz dostępu Architekta do projektu, a projekt musi być odblokowany.
- Twój plan musi mieć miejsce na kopię. Zobacz Sprawdzenie miejsca w magazynie.
- Sprawdzenie gotowości może uruchomić każdy, kto może otworzyć projekt.
- Najpierw uruchom sprawdzenie gotowości i rozwiąż wszystko, co zostanie odrzucone. Migracja rozpoczęta w projekcie, którego nie potrafi przekształcić, zatrzymuje się w połowie.
- Zaplanuj niedostępność projektu na czas trwania uruchomienia, ponieważ zapisy wykonane w trakcie uruchomienia są tracone.
- Jeśli inne projekty odczytują tabele tego projektu przez udostępnienie danych, najpierw zmigruj te projekty albo usuń udostępnienie. Projekt, który inni odczytują przez udostępnienie danych, jest migrowany po nich.
Sprawdzenie gotowości do migracji
Dział zatytułowany „Sprawdzenie gotowości do migracji”Sprawdzenie gotowości informuje, co stanie się z projektem, zanim cokolwiek zatwierdzisz. Niczego nie zmienia.
-
Otwórz menu Narzędzia.
-
Wybierz Sprawdź gotowość do migracji….
-
Wybierz projekt.
Jeśli projekt jest już w Lakehouse v2, sprawdzenie informuje o tym i o tym, że nie ma czego migrować.
Raport wymienia każdy obszar jako jeden z następujących:
| Status | Znaczenie |
|---|---|
| Bez uwag | PlaidCloud przeskanował obszar i niczego nie znalazł. |
| Wymaga przeglądu | Coś ulegnie zmianie i musisz to potwierdzić przed uruchomieniem. |
| Zablokowane | Migracji nie można rozpocząć, dopóki problem nie zostanie rozwiązany. |
| Sprawdzane podczas migracji | Obszar jest sprawdzany w trakcie migracji, więc wcześniej nigdy nie jest pokazywany jako bez uwag. |
Obszary to tabele, widoki, kroki, pulpity, udostępnienia danych i pojemność. Każde ustalenie zawiera wyjaśnienie w zrozumiałym języku, a tam, gdzie istnieje, także sugerowane przepisanie.
Co odrzuca sprawdzenie gotowości
Dział zatytułowany „Co odrzuca sprawdzenie gotowości”| Odrzucenie | Powód |
|---|---|
| Kolumna typu, który nie ma odpowiednika w Lakehouse v2 | Migracja odrzuca ją, zamiast po cichu zamieniać kolumnę w tekst. Zmień typ kolumny w projekcie, a następnie uruchom sprawdzenie ponownie. |
| Nie można ustalić docelowej hurtowni Lakehouse v2 | Lakehouse v2 obszaru roboczego nie jest widoczny dla usługi wykonującej migrację. To problem administracyjny, którego nie rozwiążesz w projekcie. |
| Nie można potwierdzić ochrony przed usunięciem w zasobniku magazynu | Od niej zależy okres umożliwiający cofnięcie, więc bez niej migracja się nie rozpocznie. |
Kolumny JSON są migrowane. Wcześniejsze wydania je odrzucały; teraz są obsługiwane.
Sprawdzenie miejsca w magazynie
Dział zatytułowany „Sprawdzenie miejsca w magazynie”Przed rozpoczęciem uruchomienia PlaidCloud sprawdza, czy Twój plan ma miejsce na kopię.
- W planie z limitem magazynu uruchomienie jest odrzucane, jeśli zmigrowana kopia by się nie zmieściła. Inne trwające migracje wliczają się do limitu.
- W planie rozliczanym za dodatkowy magazyn uruchomienie rozpoczyna się z ostrzeżeniem o spodziewanym przekroczeniu.
Wypróbuj na v2
Dział zatytułowany „Wypróbuj na v2”Wypróbuj na v2… tworzy prywatną kopię próbną projektu w Lakehouse v2, abyś mógł sprawdzić wyniki przed migracją właściwego projektu. W kopii próbnej harmonogramy i czujniki są wyłączone, a księgowanie w ERP działa w trybie symulacji. Kroki, które zapisują poza PlaidCloud, takie jak SFTP, poczta e-mail i wywołania POST REST, są wymienione w ostrzeżeniu przed potwierdzeniem. Rozpocznij wersję próbną tworzy kopię. Projekt, który ma już wersję próbną, oferuje Otwórz istniejącą wersję próbną i Zastąp wersję próbną….
Uruchomienie migracji
Dział zatytułowany „Uruchomienie migracji”-
Otwórz menu Narzędzia.
-
Wybierz Migruj projekt do Lakehouse v2…. Okno wyświetla uruchomienia migracji dla obszaru roboczego.
-
Rozpocznij nowe uruchomienie i wybierz projekt.
-
Przeczytaj raport gotowości wyświetlony w oknie i potwierdź każde wymienione ustalenie. Zaakceptowanie ustalenia dotyczy tylko tego konkretnego elementu.
-
Wybierz Rozpocznij migrację albo zaznacz Rozpocznij o zaplanowanej godzinie, ustaw godzinę i wybierz Zaplanuj migrację. Zaplanowana migracja wyświetla w projekcie baner i możesz ją anulować przed rozpoczęciem. Gdy się rozpocznie, PlaidCloud ponownie sprawdza gotowość, zgodność, pojemność i Twoje uprawnienia.
-
Rozpocznij uruchomienie. Okno postępu pokazuje każdą tabelę w trakcie kopiowania i sprawdzania. Włączone harmonogramy przepływów pracy projektu są wstrzymywane na czas uruchomienia. Możesz zamknąć okno i ponownie otworzyć je z listy uruchomień; uruchomienie trwa w obu przypadkach.
Gdy uruchomienie przełącza projekt na Lakehouse v2, nie można go zatrzymać. Jeśli samo przełączenie zakończy się niepowodzeniem w połowie, uruchomienie zamiast Wznów pokazuje Contact support. Don’t retry. Skontaktuj się z pomocą techniczną i pozostaw uruchomienie bez zmian.
Po zakończeniu uruchomienia projekt jest powiązany z Lakehouse v2, zapytania zaczynają z niego korzystać, a wstrzymane harmonogramy są przywracane. Harmonogram, który edytowano lub usunięto podczas migracji, pozostaje w stanie, w jakim go zostawiono, i jest wymieniony w raporcie. Oryginalna kopia Lakehouse v1 jest przechowywana, niedostępna dla projektu, przez okres umożliwiający cofnięcie. Gdy migracja się zakończy lub nie powiedzie, otrzymasz powiadomienie wiadomością i e-mailem.
Nieudana migracja
Dział zatytułowany „Nieudana migracja”Nieudana migracja pokazuje, dlaczego się nie powiodła, oraz czas, po którym zapisy do źródła zostaną utracone. Wybierz Wznów, aby ją kontynuować. Widoki, które nie mogą działać w Lakehouse v2, są pomijane i wymieniane, zamiast zatrzymywać uruchomienie.
Co się zmieniło
Dział zatytułowany „Co się zmieniło”Po migracji otwórz Co się zmieniło… dla danego uruchomienia. Wyświetla ono każdą tabelę jako skopiowaną, skopiowaną z wymienioną luką, pominiętą lub zakończoną niepowodzeniem, wraz z liczbą wierszy i przyczynami, pominięte widoki, tabele utworzone lub usunięte w źródle podczas uruchomienia oraz harmonogramy, które wstrzymano i przywrócono.
Grupowanie tygodniowe przesuwa się o jeden dzień
Dział zatytułowany „Grupowanie tygodniowe przesuwa się o jeden dzień”Lakehouse v2 rozpoczyna tygodnie w Niedzielę. Lakehouse v1 rozpoczynał je w Poniedziałek.
Wszystko, co jest grupowane według tygodnia, zmienia się odpowiednio, bez błędu i bez ostrzeżenia. Wiersz z datą niedziela 14 czerwca należał w v1 do tygodnia rozpoczynającego się w poniedziałek 8 czerwca. W v2 należy do tygodnia rozpoczynającego się w niedzielę 14 czerwca.
Sumy po obu stronach tej granicy się przesuwają. Wykres tygodniowy, tabela podsumowania tygodniowego i raport grupowany według tygodni nadal działają i wszystkie pokazują inne liczby niż wcześniej. Po migracji sprawdź każdą wartość tygodniową, na której polegasz, i spodziewaj się przesunięcia o jeden dzień, a nie błędu.
Co nie jest przenoszone
Dział zatytułowany „Co nie jest przenoszone”Twoje dane są migrowane. Niektóre elementy zbudowane na starym silniku oraz niektóre szczegóły deklaracji kolumn nie są.
| Element | Co się dzieje |
|---|---|
| Historia migawek, podróże w czasie i powrót w czasie (flashback) | Nie jest przenoszona. Zmigrowane tabele zaczynają z nową historią, więc nie można wykonać zapytania o stan projektu z czasu sprzed migracji. |
| Gałęzie i tagi tabel | Istniejące gałęzie i tagi nie są przenoszone. |
Ograniczenia długości VARCHAR(n) |
Ograniczenie długości jest usuwane. Kolumny tekstowe stają się tekstem bez ograniczeń; istniejące wartości pozostają bez zmian. |
| Wąskie szerokości liczb całkowitych | Małe typy całkowite stają się 32-bitowymi liczbami całkowitymi. Wartości pozostają bez zmian. |
| Precyzja ułamków sekund w znacznikach czasu | Zadeklarowana precyzja jest usuwana. |
| Kolumny przestrzenne, geometryczne i bitmapowe | Są migrowane, ale wyłączone z automatycznego porównywania wartości — sprawdź je samodzielnie. |
| Kolumny binarne, tablicowe i mapowe | Są migrowane, ale wyłączone z automatycznego porównywania wartości — sprawdź je samodzielnie. |
| Kolumny JSON | Są migrowane z zachowaniem typów. Liczba wewnątrz JSON zbyt duża do dokładnego zapisu jest przechowywana z podwójną precyzją i zgłaszana. |
Cofanie migracji
Dział zatytułowany „Cofanie migracji”Przez okres umożliwiający cofnięcie po zakończeniu uruchomienia oryginalne dane Lakehouse v1 są zachowywane w nienaruszonym stanie, ale odłączone od projektu. Cofnij migrację… przywraca w tym okresie projekt do Lakehouse v1. Potrzebujesz dostępu Architekta do projektu.
Cofnięcie prosi o wpisanie nazwy projektu w celu potwierdzenia. Wszystkie zmiany wprowadzone w projekcie od przełączenia na Lakehouse v2 zostaną utracone. W trakcie cofania wyświetlany jest postęp. Jeśli cofnięcie zostanie odrzucone, podana jest przyczyna, na przykład że okres umożliwiający cofnięcie minął.
Użyj go, jeśli wyniki po migracji wyglądają nieprawidłowo — z wyjątkiem wartości tygodniowych, które mają się przesunąć.
Po upływie okresu umożliwiającego cofnięcie oryginalne dane są usuwane, a migracja jest ostateczna.
Po migracji
Dział zatytułowany „Po migracji”Sesje, które były już otwarte, nadal odczytują kopię, z którą zaczęły, do czasu zakończenia. Zwłaszcza długotrwała sesja aplikacji Panel nadal obsługuje stare dane, dopóki nie zostanie uruchomiona ponownie. Po migracji uruchom ponownie długotrwałe sesje, aby korzystały z Lakehouse v2.