Przeskocz do zawartości głównej Przejdź do treści uzupełniającej

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.

InformacjaWszystkimi tabelami i widokami zarządza Qlik Talend Data Integration. Nie zmieniaj danych przy użyciu innych narzędzi.

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.

InformacjaTabele w schemacie wewnętrznym mogą ulec zmianie bez powiadomienia. Tam, gdzie to możliwe, należy przede wszystkim używać widoków do korzystania z 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:

  • W przypadku danych pobranych z pełnego ładowania, jest to czas rozpoczęcia pełnego ładowania.

  • W przypadku zmiany pochodzącej z partycji Zmian, jest to pole znacznika czasu rekordu.

hdr__operation VARCHAR (1)

Ostatnia operacja tego rekordu.

  • D – usunięte z partycji zmian.

  • U – zaktualizowane z partycji zmian.

  • I - wstawione z partycji zmian.

  • L — wstawiono przez zadanie pełnego ładowania.

  • d - usunięte z funkcji porównaj i zastosuj.

  • u - zaktualizowane z funkcji porównaj i zastosuj.

  • i – wstawione z funkcji porównania i zastosowania.

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.

  • D – usunięte z partycji zmian.

  • U – zaktualizowane z partycji zmian.

  • I - wstawione z partycji zmian.

  • L — wstawiono przez zadanie pełnego ładowania.

  • d - usunięte z funkcji porównaj i zastosuj.

  • u - zaktualizowane z funkcji porównaj i zastosuj.

  • i – wstawione z funkcji porównania i zastosowania.

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:

  • Znacznik czasu rozpoczęcia uruchomienia partii w milisekundach od 01.01.1970 r. (ciąg 10 cyfr).

  • Sekwencja zmian z bramy replikacji (35 znaków).

hdr__operation VARCHAR (1)

Ostatnia operacja tego rekordu.

  • D – usunięte z partycji zmian.

  • U – zaktualizowane z partycji zmian.

  • I - wstawione z partycji zmian.

  • L — wstawiono przez zadanie pełnego ładowania.

  • d - usunięte z funkcji porównaj i zastosuj.

  • u - zaktualizowane z funkcji porównaj i zastosuj.

  • i – wstawione z funkcji porównania i zastosowania.

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:

  • CURRENT — jeśli rekord znajduje się w bieżącej partycji.

  • PRIOR — jeśli rekord znajduje się w poprzedniej partycji z danymi historycznymi.

hdr__operation ŁAŃCUCH (1)

Ostatnia operacja tego rekordu.

  • D – usunięte z partycji zmian.

  • U – zaktualizowane z partycji zmian.

  • I - wstawione z partycji zmian.

  • L — wstawiono przez zadanie pełnego ładowania.

  • d - usunięte z funkcji porównaj i zastosuj.

  • u - zaktualizowane z funkcji porównaj i zastosuj.

  • i – wstawione z funkcji porównania i zastosowania.

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.

InformacjaWidoki Bieżący i Historia opierają się na partycji Zmiany i zawsze działają w czasie zbliżonym do rzeczywistego. Jeśli jednak wydajność zapytań jest niska, może to być spowodowane dużą liczbą zmian, które nie zostały jeszcze zastosowane w partycjach Current lub Prior. Niescalone delty wymagają więcej przetwarzania w czasie zapytania, co spowalnia dostęp.

Czy ta strona była pomocna?

Jeżeli natkniesz się na problemy z tą stroną lub jej zawartością — literówkę, brakujący krok lub błąd techniczny — daj nam znać!