Architektura zestawu danych w Qlik Open Lakehouse

Podczas generowania zestawów danych w Qlik Open Lakehouse tabele przechowywania, tabele zmian i widoki są generowane automatycznie przez Qlik Talend Data Integration. Można wysyłać zapytania do tych widoków, aby uzyskać dostęp do bieżących i historycznych danych przechowywanych w otwartym formacie tabeli Iceberg.

Intuicyjny interfejs użytkownika z przewodnikiem pomaga budować, modelować i wykonywać potoki danych. Można automatycznie generować schematy dla operacyjnych magazynów danych (ODS) i historycznych magazynów danych (HDS) bez ręcznego kodowania.

Schematy

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

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

• Schemat zadania danych zawiera widoki, których można użyć do korzystania z 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 należy upewnić się, że nie ma konfliktów 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, z których każda służy do określonego celu w sposobie przetwarzania i przechowywania danych. Każda partycja wykorzystuje podzbiór kolumn tabeli w oparciu o jej rolę w cyklu życia danych.

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 za pośrednictwem kilku 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łowej przed wystąpieniem jakichkolwiek transformacji.

  • Każda zmiana jest oznaczona typem (I, U lub D), wskazującym sposób jej przetwarzania.

  • 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 opcja Metoda aktualizacji jest ustawiona na CDC.

    • Włączone jest pełne ładowanie.

• 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 jest uruchamiane automatycznie w celu zastosowania tych aktualizacji. 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 wysyłania zapytań.

• Partycja Prior (HDS) – dane historyczne

  Gdy rekord zostanie zaktualizowany lub usunięty w 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 do partycji Current, poprzedni rekord jest przenoszony do partycji 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 do partycji Current.

  • Partycja Reload jest czyszczona po zakończeniu operacji.

  Proces ten 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 upraszczające wysyłanie zapytań i raportowanie:

Current

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

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

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

Historia

Widok historii 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 historii łączy dane z partycji Prior i Changes. Zapewnia on kompletną oś czasu zmian, idealną do audytu lub analizy historycznej.

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

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