Modelowanie wymiarowe w rurociągach Lakeflow

Modelowanie wymiarowe to technika organizowania danych warstwy złotej w tabele faktów i wymiarów, tak aby analitycy i narzędzia business intelligence (BI) mogli efektywnie je zapytać. Ta strona wyjaśnia, jak zbudować taki model za pomocą rurociągów Lakeflow.

Overview

Modelowanie wymiarowe dzieli dane na dwa rodzaje tabel:

  • Tabele faktów zawierają zdarzenia lub miary, które są dla Ciebie ważne, takie jak zamówienia, kliknięcia czy sprzedaż. Każdy wiersz to jedno wystąpienie tego zdarzenia, opisane głównie przy użyciu kluczy i miar liczbowych.
  • Tabele wymiarowe zawierają kontekst opisowy wokół tych zdarzeń, taki jak klienci, produkty czy daty. Każdy wiersz to jeden podmiot gospodarczy.

Schemat gwiazdowy to kształt, który otrzymujesz, gdy umieszczasz jedną tabelę faktów na środku i łączysz ją z kilkoma tabelami wymiarowymi za pomocą ich kluczy. Układ jest łatwy do odpytywania przez analityków i narzędzia BI oraz łatwy do zrozumienia dla inżynierów, ponieważ każda tabela ma jedno, jasno określone zadanie.

W potokach Lakeflow schemat gwiaździsty naturalnie wpisuje się w złotą warstwę architektury medalionowej. Brązowe i srebrne zbiory danych obsługują ingestię i czyszczenie danych, a warstwa złota materializuje tabele faktów i wymiarów, dzięki czemu odbiorcy mogą kierować do nich zapytania bezpośrednio. Ponieważ potok przetwarzania utrzymuje te tabele na bieżąco poprzez aktualizacje przyrostowe, zyskujesz prostotę zapytań charakterystyczną dla schematu gwiazdy bez potrzeby stosowania osobnego etapu ekstrakcji, transformacji i ładowania (ETL) w warstwie BI.

Jak to działa

Budujesz wymiary i fakty jako zbiory danych w swoim potoku danych, wybierając typ zbioru danych, który odpowiada temu, jak każdy z nich się zmienia. Dla większości modeli z warstwą złota:

  • Buduj tabele wymiarowe jako zmaterializowane widoki (lub jako tabele strumieniowe z powoli zmieniającym się wymiarem (SCD) Typ 2, gdy potrzebujesz historii). Zmaterializowany widok efektywnie przetwarza dane z czystego srebra wraz ze zmianą danych wejściowych, dając jeden wiersz na podmiot biznesowy.
  • Buduj tabele faktów jako tabele strumieniowe, zasilane stopniowo ze srebra, tak aby agregaty warstw złota pozostawały blisko czasu rzeczywistego. Fakty odwołują się do wymiarów za pomocą klucza, zamiast powielać atrybuty opisowe.

Więcej informacji o tych dwóch typach zbiorów danych można znaleźć w Materialized views oraz Streaming tables. Aby śledzić historię dla wymiaru, zobacz Interfejsy API AUTO CDC: uproszczone przechwytywanie zmian danych za pomocą potoków.

Klucze i klucze zastępcze

Preferuj klucze naturalne (identyfikator już istniejący w danych źródłowych, taki jak numer zamówienia), gdzie klucz naturalny źródła jest stabilny i użyteczny, ponieważ dobrze się klastruje i łączy. Sięgnij po klucz zastępczy (identyfikator zastępczy generowany przez potok) tylko wtedy, gdy źródło ponownie używa lub zmienia ID.

Kiedy jednak potrzebujesz klucza zastępczego, unikaj zastępczego klucza opartego na funkcji skrótu, takiego jak sha2(natural_key). Skrót jest celowo losowy, co jest złe dla klastrowania płynnego i wydajności w rzędzie Z, ponieważ fizycznie sąsiadujące wiersze są rozproszone po plikach. Zamiast tego deterministycznie wyprowadzmy zastępcę zachowującego porządek z stabilnego klucza naturalnego, tak aby ten sam podmiot biznesowy zawsze przypisywał się temu samemu zastępcy. Klucz deterministyczny przetrwa pełne odświeżenie lub przebudowę wymiaru, co zachowuje istniejące połączenia fakt-wymiar.

Alternatywnie możesz użyć kolumny IDENTITY, gdy tabela źródłowa służy wyłącznie do dopisywania i nigdy nie jest w pełni odświeżana. Ponieważ wartości IDENTITY są przypisywane podczas wstawiania wierszy, ponowne zbudowanie może przypisać tej samej encji inne identyfikatory i bez ostrzeżenia zerwać połączenia między tabelą faktów a tabelą wymiarów, które opierały się na starych wartościach.

Wymiary czasu

Zbuduj dim_date jako prosty widok zmaterializowany wygenerowany za pomocą sequence() i explode() w zakresie dat, zamiast pozyskiwać go ze źródła. To statyczne dane referencyjne, tanie w wyliczeniu, a także upraszczające łączenia oparte na dacie i operacje okienkowe w pozostałej części modelu.

Examples

Poniższe przykłady tworzą schemat małej gwiazdki z wymiarem klienta oraz tabelą faktów zamówień.

Tabela wymiarów

Tabela wymiarów to zazwyczaj zmaterializowany widok zbudowany z danych oczyszczonego srebra, z jednym wierszem na podmiot biznesowy, jak w następującym kodzie:

Python

from pyspark import pipelines as dp

@dp.materialized_view(name="dim_customer", comment="Customer dimension")
def dim_customer():
    return (
        spark.read.table("customers_silver")
        .select("customer_id", "customer_name", "region", "signup_date")
    )

SQL

CREATE OR REFRESH MATERIALIZED VIEW dim_customer
COMMENT "Customer dimension"
AS SELECT customer_id, customer_name, region, signup_date
FROM customers_silver;

Tabela faktów

Tabela faktów zawiera mierzalne zdarzenia, odwołując się do wymiarów za pomocą ich kluczy, zamiast powielać atrybuty opisowe. Utrzymuj fakty wąskie (głównie klucze i miary liczbowe) i używaj joinów do wprowadzania szczegółów opisowych podczas zapytania, jak w następującym kodzie:

Python

from pyspark import pipelines as dp

@dp.table(name="fact_orders", comment="One row per order line, keyed to dimensions")
def fact_orders():
    return (
        spark.readStream.table("orders_silver")
        .select(
            "order_id",
            "customer_id",       # foreign key to dim_customer
            "product_id",        # foreign key to dim_product
            "order_date",        # foreign key to dim_date
            "quantity",
            "amount",
        )
    )

SQL

CREATE OR REFRESH STREAMING TABLE fact_orders
COMMENT "One row per order line, keyed to dimensions"
AS SELECT
  order_id,
  customer_id,   -- foreign key to dim_customer
  product_id,    -- foreign key to dim_product
  order_date,    -- foreign key to dim_date
  quantity,
  amount
FROM STREAM(orders_silver);

Najlepsze rozwiązania

Istnieje kilka praktyk, które pomagają utrzymać schemat gwiaździsty w dobrej kondycji wraz z jego rozwojem:

  • Utrzymuj fakty jako tabele strumieniowe, a wymiary jako zmaterializowane widoki, chyba że potrzebujesz historii zmian — w takim przypadku użyj AUTO CDC z STORED AS SCD TYPE 2. Zobacz Interfejsy API AUTO CDC: upraszczają przechwytywanie zmian danych za pomocą potoków.
  • Używaj narzędzi BI w dalszej fazie, aby bezpośrednio zapytać o wyświetlenia zmaterializowane w złocie. Potoki Lakeflow na bieżąco je odświeżają, dzięki czemu otrzymujesz wyniki niemal w czasie rzeczywistym bez osobnego etapu ETL na potrzeby raportowania.
  • Modelowanie wymiarów i faktów jako oddzielnych przepływów do tej samej warstwy złotej, dzięki czemu każdy zbiór danych może być zaplanowany, punktowany kontrolny i odświeżany jako część jednego spójnego DAG. Zobacz Przyrostowe ładowanie i przetwarzanie danych za pomocą przepływów potoku Lakeflow.

Dodatkowe zasoby

  • Last updated on