Architektura zestawu danych w Qlik Open Lakehouse
Podczas generowania rekordów danych w Qlik Open Lakehouse, w Qlik Talend Data Integration są automatycznie generowane tabele pamięci masowej, tabele zmian i widoki. Widoki te można przeszukiwać w celu uzyskania dostępu do bieżących i historycznych danych przechowywanych w otwartym formacie tabeli Iceberg.
Intuicyjny interfejs użytkownika pomaga budować, modelować i wykonywać potoki danych. Użytkownik może automatycznie generować schematy dla magazynów danych operacyjnych (ODS) i magazynów danych historycznych (HDS) bez konieczności ręcznego kodowania.
Architektura dla potoku danych Qlik Open Lakehouse z wykorzystaniem Brama danych Qlik — ruch danych. Dane umieszczane są w S3 i przechowywane w Open Lakehouse Iceberg. Opcjonalnie, jak pokazano poniżej, tabele mogą być odzwierciedlane w hurtowni danych.

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óre można wykorzystać do korzystania z danych.
Gdy schemat jest powiązany z więcej niż jednym zadaniem danych, każde zadanie danych musi używać unikatowego 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 sprawdzić, czy w nazwach tabel nie występują konflikty nazw. Najlepsza praktyka polega na nadawaniu schematowi wewnętrznemu takiej samej nazwy jak schematowi zadania danych z dodanym elementem _internal. To skutecznie zapewni, że każda kombinacja schematu i prefiksu będzie unikatowa.
Tabele
Dla każdej tabeli źródłowej tworzona jest tabela w schemacie wewnętrznym z przyrostkiem _internal, przy użyciu formatu:
<INTERNAL_SCHEMA>.<TABLE_NAME>_internal
Tabela ta zawiera pięć partycji, z których każda służy odrębnemu celowi w zakresie przetwarzania i przechowywania danych. Każda partycja wykorzystuje podzbiór kolumn tabeli na podstawie jej roli w cyklu życia danych.
Wewnętrzny zbiór danych ma strukturę umożliwiającą efektywne zarządzanie danymi przychodzącymi z systemu źródłowego, wspierając pozyskiwanie danych w czasie rzeczywistym i śledzenie danych historycznych. Przepływ danych jest zarządzany przez kilka wyspecjalizowanych partycji, z których każda została opisana poniżej:
-
Partycja zmian – pozyskiwanie w czasie rzeczywistym
Wszystkie zmiany z systemu źródłowego – wpisy, aktualizacje i usunięcia – są najpierw dołączane do Partycji zmian.
-
Działając jako surowy dziennik zmian, partycja zapewnia pełną informację o aktywności źródła przed wystąpieniem jakichkolwiek przekształceń.
-
Każda zmiana jest oznaczona typem (I, U lub D), wskazującym sposób jej przetwarzania.
-
Zdarzenia są przechwytywane ze źródła w momencie ich wystąpienia. Partycja jest aktualizowana niemal w czasie rzeczywistym.
-
Partycja zmian jest dostępna po zastosowaniu następujących ustawień w zadaniu umieszczania danych w jeziorze.
-
W zakładce Ogólne opcja Metoda aktualizacji jest ustawiona na CDC.
-
Pełne ładowanie jest włączone.
-
-
-
Partycja asset_state – śledzenie postępu
Po wprowadzeniu zmian partycja Asset_state rejestruje dwa znaczniki czasu:
-
Kiedy zmiany zostały ostatnio dodane do partycji Changes.
-
Kiedy zmiany zostały ostatnio zastosowane do partycji Changes.
Zapewnia to pełny wgląd w potok synchronizacji i pomaga w monitorowaniu lub rozwiązywaniu problemów z opóźnieniami.
-
-
Bieżąca partycja (ODS) – najnowsza replika źródła
Zmiany z partycji Changes są okresowo stosowane do partycji Current w celu utrzymania aktualnej, zoptymalizowanej pod kątem zapytań kopii źródła danych.
-
Zadanie w tle działa automatycznie, aby zastosować te aktualizacje. Jest to oparte na ilości skumulowanych zmian, a nie na ustalonym harmonogramie.
-
Początkowe pełne ładowanie jest zapisywane bezpośrednio w partycji Current.
-
Partycja ta odzwierciedla aktualny stan danych i została zaprojektowana z myślą o wydajnym wyszukiwaniu.
-
-
Wcześniejsza partycja (HDS) – dane historyczne
Gdy rekord jest aktualizowany lub usuwany w partycji Current, kopia poprzedniej wersji jest zapisywana w partycji Prior.
-
Rekordy zawierają metadane, w tym historię zmian i zakres dat, kiedy dane są ważne.
-
Obsługiwane są powoli zmieniające się wymiary typu 2 (SCD2).
-
Partycja Prior jest dostępna, gdy opcja Zachowaj rekordy historyczne i archiwizuj rekordy zmian jest włączona na karcie Ogólne w ustawieniach zadania przechowywania danych.
-
Gdy zaktualizowana wersja rekordu wchodzi do partycji Current, poprzedni rekord jest przenoszony do partycji Prior w celu śledzenia historycznego.
-
-
Partycja przeładowania
Przeładowanie partycji działa jako tymczasowy obszar przejściowy podczas ręcznego lub zaplanowanego pełnego przeładowania:
-
Nowe dane są najpierw zapisywane w partycji Reload.
-
Regularne zadania konserwacyjne czyszczą wszelkie oczekujące zmiany przed ich wstrzymaniem.
-
Dane są porównywane z partycją Current i tylko różnice są przenoszone do partycji Current.
-
Partycja Reload jest czyszczona po zakończeniu operacji.
Proces ten zapewnia minimalne zakłócenia głównego zbioru danych podczas operacji pełnego przeładowania.
-
Bieżąca partycja
| Pole | Typ | Opis |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Skrót wszystkich kluczy podstawowych rekordów. Format skrótu to SHA1. Kolumny są oddzielone znakiem cofania. |
| hdr__from_timestamp | TIMESTAMP |
Znacznik czasu w UTC:
|
| hdr__operation | VARCHAR (1) |
Ostatnia operacja tego rekordu.
|
| hdr__inserted_timestamp | TIMESTAMP | Znacznik czasowy UTC pierwszego dodania klucza. W przypadku korzystania z pełnego ładowania, czas rozpoczęcia pełnego ładowania. |
| hdr__modified_timestamp | TIMESTAMP | Znacznik czasu UTC określający, kiedy została zastosowana ostatnia aktualizacja. |
Partycja Prior
| Pole | Typ | Opis |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Skrót wszystkich kluczy podstawowych rekordów. |
| hdr__from_timestamp | TIMESTAMP | Znacznik czasu w UTC. |
| hdr__to_timestamp | TIMESTAMP | Znacznik czasu w UTC. |
| hdr__operation | ŁAŃCUCH (1) |
Ostatnia operacja tego rekordu.
|
| hdr__był_aktualny_od_znacznika_czasu | TIMESTAMP | Znacznik czasu w UTC dla pierwszego razu, kiedy rekord był aktualny. |
| hdr__był_aktualny_do_znacznika_czasu | TIMESTAMP | Znacznik czasu w UTC dla ostatniego razu, kiedy rekord był aktualny. |
Partycja zmian
| Pole | Typ | Opis |
|---|---|---|
| hdr__change_identifier | VARCHAR (50) |
Identyfikator zmiany to ciąg znaków składający się z dwóch części:
|
| hdr__operation | VARCHAR (1) |
Ostatnia operacja tego rekordu.
|
| hdr__timestamp | TIMESTAMP | Znacznik czasu w UTC. |
| hdr__key_hash | BINARNY (20) | Skrót wszystkich kluczy podstawowych rekordów. |
| hdr__inserted_timestamp | ZNACZNIK CZASU | Znacznik czasu UTC, w którym zmiana została przetworzona przez Qlik. |
Partycja Asset_state
| Pole | Typ | Opis |
|---|---|---|
| Zastosuj identyfikator zmiany | VARCHAR (50) | Identyfikator ostatniej zmiany zastosowanej do bieżącej partycji. |
| Kopiuj identyfikator zmiany | VARCHAR (50) | Identyfikator ostatniej zmiany zastosowanej do partycji zmian. |
Partycja przeładowania
Kolumny używane przez partycję przeładowania są takie same, jak w partycji Current.
Widoki
Wszystkie utworzone widoki są aktualizowane niemal w czasie rzeczywistym. W celu uproszczenia zapytań i raportowania dostępne są następujące widoki:
Bieżący
Widok bieżący odzwierciedla najnowszy stan danych. Widok ten 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 kolumny nagłówka.
Historia
Widok historii jest generowany w schemacie zasobu danych dla każdej wybranej tabeli źródłowej, jeśli w ustawieniach zadania danych włączona jest opcja Historia. Widok historii scala dane z partycji Prior i Changes. Zapewnia pełną 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.
| Pole | Typ | Opis |
|---|---|---|
| hdr__key_hash | BINARNY (20) | Skrót wszystkich kluczy podstawowych rekordów. |
| hdr__from_timestamp | TIMESTAMP | Znacznik czasu wystąpienia zmiany w systemie źródłowym. Odzwierciedla to, kiedy użytkownik pierwotnie dokonał zmiany. |
| hdr__to_timestamp | TIMESTAMP | Znacznik czasu wystąpienia zmiany lub aktualizacji w systemie źródłowym. |
| hdr__store | VARCHAR (10) |
Oznacza miejsce, w którym znajduje się rekord:
|
| hdr__operation | ŁAŃCUCH (1) |
Ostatnia operacja tego rekordu.
|
| hdr__deleted | BIT | Wskazuje, czy rekord jest miękko usuwany, na podstawie tego, czy hdr__operation to D lub d. |
| hdr__was _current_from_timestamp | ZNACZNIK CZASU | Czas (UTC), kiedy ten wiersz wszedł do partycji bieżącej.Zazwyczaj jest to wtedy, gdy zadanie przechowywania zostało uruchomione i zmiana została zastosowana. |
| hdr__was _current_to_timestamp | TIMESTAMP | Czas (UTC), kiedy wiersz został usunięty z tabeli Current, na przykład z powodu pojawienia się nowszej wersji. |