Architektura zestawu danych w Qlik Open Lakehouse

Źródła strumieniowe mają własną architekturę w Qlik Open Lakehouse, ponieważ nie wymagają Data Movement gateway do ładowania danych do zasobnika umieszczania, ale są obsługiwane przez klaster lakehouse.

Gdy pobierasz dane z plików, które zawierają wzorzec danych w nazwie pliku, umożliwia to klastrowi lakehouse wykonywanie ukierunkowanych operacji na listach w S3, co znacznie przyspiesza czas odczytu listy plików. Ponadto Qlik Open Lakehouse może przewidywać przychodzące pliki na podstawie wzorca daty. Zadanie umieszczania strumieniowego nie musi za każdym razem wyświetlać całego zasobnika, ale zamiast tego może żądać plików z S3 w określonym zakresie dat. Posiadanie mniejszej listy plików prowadzi do lepszej wydajności. Opcjonalne ustawienie Usuń po załadowaniu może być użyte do utrzymania małej liczby plików. Nie jest wykonywane pełne ładowanie, pierwsze rekordy są traktowane jako wstawione zmiany.

W Qlik Open Lakehouse zadanie Streaming Transform zastępuje zadanie przechowywania. To zadanie służy do przekształcania i przechowywania umieszczonych danych jako tabel Iceberg. Zadanie Streaming Transform można dodać tylko po zadaniu umieszczania strumieniowego. Zadanie Streaming Transform obsługuje dwa tryby aktualizacji rekordów:

• Tylko dołączaj: Dodaje nowe rekordy bez modyfikowania istniejących danych, a ograniczenia klucza nie są egzekwowane, jeśli pojawią się zduplikowane rekordy.

• Zastosuj zmiany (Scal): Aktualizuje istniejące rekordy i wstawia nowe rekordy na podstawie pól klucza. Ten tryb daje możliwość użycia miękkiego usuwania lub zachowania danych historycznych (Typ 2).

Zadanie Streaming Transform to zadanie oparte na celu, które mapuje między źródłem a celem i obejmuje możliwości ewolucji schematu. Zapewnia rozszerzone możliwości przekształcania, w tym odzagnieżdżanie zagnieżdżonych struktur i spłaszczanie tablic. Aby uzyskać więcej informacji na temat funkcji, których można użyć w zadaniu Streaming Transform, zobacz Funkcje transformacji.

Podczas pobierania ze źródła strumieniowego masz możliwość skonfigurowania partycjonowania Iceberg, zarządzania retencją, kolumn sortowania, wygasania migawek w celu kontrolowania kosztów przechowywania i optymalizacji pod kątem wydajności zapytań.

Tabele umieszczania

Następujące pola nagłówka są dodawane do tabel umieszczania. Te pola zawsze istnieją w danych umieszczania, ale domyślnie nie w przekształceniu podrzędnym. Możesz dodać pola do przekształcenia za pomocą wyrażenia.

Schematy

Artefakty są generowane w schemacie wewnętrznym i schemacie zadania danych.

• Schemat wewnętrzny zawiera fizyczną tabelę z wieloma partycjami.

• Schemat zadania danych zawiera widoki, których można użyć do konsumpcji danych.

  Gdy schemat jest powiązany z więcej niż jednym zadaniem danych, każde zadanie danych musi używać unikalnego prefiksu dla tabel i widoków. Prefiks można ustawić w ustawieniach zadania danych.

Tylko schematy wewnętrzne są sprawdzane pod kątem konfliktów nazw. W przypadku innych schematów musisz upewnić się, że nie ma konfliktów nazw w nazwach tabel. Najlepszą praktyką jest nadanie schematowi wewnętrznemu takiej samej nazwy jak schemat zadania danych z dodanym _internal. Zapewnia to, że każda kombinacja schematu i prefiksu jest unikalna.

Tabele

Dla każdej tabeli źródłowej w schemacie wewnętrznym tworzona jest tabela z sufiksem _internal, przy użyciu formatu:

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Ta tabela zawiera pięć partycji w trybie Zastosuj zmiany (Scal), z których każda służy odrębnemu celowi w sposobie przetwarzania i przechowywania danych. Każda partycja wykorzystuje podzbiór kolumn tabeli w oparciu o jej rolę w cyklu życia danych. W trybie Tylko dołączaj tabela nie ma partycji i zachowuje się jak partycja Current (ODS).

Wewnętrzny zestaw danych ma strukturę umożliwiającą wydajne zarządzanie danymi przychodzącymi z systemu źródłowego, obsługując pozyskiwanie w czasie rzeczywistym i śledzenie historyczne. Przepływ danych jest zarządzany przez kilka wyspecjalizowanych partycji, z których każda została opisana poniżej:

• Partycja Changes – Pozyskiwanie w czasie rzeczywistym

  Wszystkie zmiany z systemu źródłowego — wstawienia, aktualizacje i usunięcia — są najpierw dołączane do partycji Changes.

  • Działając jako surowy dziennik zmian, partycja zapewnia kompletny kanał aktywności źródła przed wystąpieniem jakichkolwiek przekształceń.

  • Każda zmiana jest oznaczona typem (I, U lub D), wskazującym, jak jest przetwarzana.

  • Zdarzenia są przechwytywane ze źródła w miarę ich występowania. Partycja jest aktualizowana w czasie zbliżonym do rzeczywistego.

  • Partycja Changes jest dostępna, gdy w zadaniu danych umieszczania w jeziorze zastosowane są następujące ustawienia.

    • Na karcie Ogólne, Metoda aktualizacji jest ustawiona na CDC.

    • Pełne ładowanie jest włączone.

• Partycja Asset_state - Śledzenie postępu

  W miarę pozyskiwania zmian partycja Asset_state rejestruje dwa kluczowe znaczniki czasu:

  • Kiedy zmiany zostały ostatnio dołączone do partycji Changes.

  • Kiedy zmiany zostały ostatnio zastosowane do partycji Current.

  Zapewnia to pełną widoczność potoku synchronizacji i pomaga w monitorowaniu lub rozwiązywaniu problemów z opóźnieniami.

• Partycja Current (ODS) – Najnowsza replika źródła

  Zmiany z partycji Changes są okresowo stosowane do partycji Current, aby utrzymać aktualną, zoptymalizowaną pod kątem zapytań kopię danych źródłowych.

  • Zadanie w tle uruchamia się automatycznie, aby zastosować te aktualizacje. Opiera się to na ilości nagromadzonych zmian, a nie na stałym harmonogramie.

  • Początkowe pełne ładowanie jest zapisywane bezpośrednio na partycji Current.

  • Ta partycja odzwierciedla bieżący stan danych i jest przeznaczona do wydajnego wykonywania zapytań.

• Partycja Prior (HDS) – Dane historyczne

  Gdy rekord zostanie zaktualizowany lub usunięty na partycji Current, kopia poprzedniej wersji jest zapisywana na partycji Prior. 

  • Rekordy zawierają metadane, w tym historię zmian i zakres dat, w którym dane są ważne.

  • Obsługuje to wolno zmieniający się wymiar typu 2 (SCD2).

  • Partycja Prior jest dostępna, gdy opcja Zachowaj rekordy historyczne i archiwum rekordów zmian jest włączona na karcie Ogólne w ustawieniach zadania danych przechowywania.

  • Gdy zaktualizowana wersja rekordu wchodzi na partycję Current, poprzedni rekord jest przenoszony na partycję Prior w celu śledzenia historycznego.

• Partycja Reload

  Partycja Reload działa jako tymczasowy obszar przejściowy podczas ręcznych lub zaplanowanych pełnych przeładowań:

  • Nowe dane są najpierw zapisywane na partycji Reload.

  • Regularne zadania konserwacyjne czyszczą wszelkie oczekujące zmiany przed ich wstrzymaniem.

  • Dane są porównywane z partycją Current, a tylko różnice są przenoszone na partycję Current.

  • Partycja Reload jest czyszczona po zakończeniu operacji.

  Ten proces zapewnia minimalne zakłócenia w głównym zestawie danych podczas operacji pełnego przeładowania.

Partycja Current

Partycja Prior

Partycja Changes

Partycja Asset_state

Partycja Reload

Kolumny używane przez partycję Reload są identyczne z partycją Current.

Widoki

Wszystkie utworzone widoki są aktualizowane w czasie zbliżonym do rzeczywistego. Dostępne są następujące widoki, które upraszczają wykonywanie zapytań i raportowanie:

Bieżący

Widok Bieżący odzwierciedla najnowszy stan danych. Ten widok reprezentuje replikę tabeli źródłowej, aktualizowaną w czasie zbliżonym do rzeczywistego. Scala dane z partycji Current i Changes.

Nazwa: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

Do struktury tabeli nie są dodawane żadne kolumny nagłówka.

Historia

Widok Historia jest generowany w schemacie zasobu danych dla każdej wybranej tabeli źródłowej, gdy opcja Historia jest włączona w ustawieniach zadania danych. Widok Historia scala dane z partycji Prior i Changes. Zapewnia kompletną oś czasu zmian, idealną do audytu lub analizy historycznej.

Nazwa: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

Do widoku Historia dodawane są następujące pola nagłówka: