Free Press

Modelowanie wymiarowe (DM) jest częścią metodologii Business Dimensional Lifecycle opracowanej przez Ralpha Kimballa, która obejmuje zestaw metod, technik i koncepcji do wykorzystania w projektowaniu hurtowni danych. Podejście to koncentruje się na identyfikacji kluczowych procesów biznesowych w przedsiębiorstwie oraz modelowaniu i wdrażaniu tych procesów w pierwszej kolejności przed dodaniem dodatkowych procesów biznesowych, czyli na podejściu bottom-up.

Jakie są cele modelowania hurtowni danych?

Cele, określone przez Rossa i Kimballa, są proste:

• uczynić informację łatwo dostępną
• prezentować informację konsekwentnie
• adaptowalną i otwartą na zmiany
• prezentować informację w odpowiednim czasie
• ochronić aktywa informacyjne

.

• służyć jako autorytatywny i godny zaufania fundament dla ulepszonego podejmowania decyzji (pojedyncze źródło prawdy w języku Data Engineering)
• VIP-y muszą zaakceptować twój system

Jeśli pracowałeś lub używałeś systemu ETL, zauważyłbyś, że spójność informacji jest osiągana przez zgodne środki, terminowość zapewniana przez cykle ETL i adaptacyjność również zależy w dużej mierze od projektu ETL.

Why Modeling?

Jako inżynier danych, znasz bardzo dobrze SQL i prawdopodobnie możesz pisać zapytania SQL przez cały dzień. Ale nie możesz zakładać, że typowy użytkownik końcowy będzie ekspertem w pisaniu zapytań SQL. Tak więc, naszym celem jest zbudowanie DW tak łatwego dla analityków, aby mogli pisać zapytania analityczne szybko i efektywnie.

Rzeczy, których nie chciałbyś, aby twoi analitycy robili:

• Kwerendy oparte na ID
• Kaskadowe złączenia zewnętrzne (nawet ty nie chciałbyś tego robić)
• Pogrupowane lub połączone wielokrotne podzapytania
• rekursywne podzapytania (odwiedź Hackerrank SQL, a zrozumiesz ten ból)
• Korelacja podzapytań: pobieranie danych przez wiele kolumn w różnych podzapytaniach
• Joins bez PK/FK: nawet dla mnie(1.5 lat doświadczenia w DE), jest to trudne do zwizualizowania.

Rzeczy, których mógłbyś i powinieneś oczekiwać od swoich analityków:

• simple joins
• kolumny z nazwami i obszernym tekstem
• simple aggregation
• analityczne funkcje okienkowe
• DISTINCT

Uwaga, powyższe punkty nie są łatwe i że twój system powinien być wystarczająco skalowalny dla wszystkich tych rodzajów zapytań.

Bazy danych OLTP są przekształcane w fakty i wymiary ze względu na wyżej wymienione cele.

Przejście od transakcyjnych baz danych do faktów

Większość przedsiębiorstw mierzy swój sukces i wydajność poprzez pomiar pewnych typów danych. Dane te odzwierciedlają rzeczywistą działalność biznesową i postęp. Dane te nazywane są faktami.

Bazy danych zorientowane na OLTP rejestrują transakcje w czasie, coś w rodzaju strumieniowania zdarzeń, ale scentralizowanego wokół transakcji. DW jest inny. DW nie musi rejestrować szczegółów na poziomie transakcyjnym. DW musi zawierać fakty dotyczące różnych kryteriów biznesowych. DW musi agregować (lub pozwolić analitykom agregować) informacje wymagane do usprawnienia biznesu. I tak, redundancja jest niewybaczalnym grzechem w DW.

Czym są miary i dlaczego powinieneś wypełnić nimi swoje tabele faktów?

W hurtowni danych, miara jest właściwością, na której można wykonywać obliczenia.

Fakty, które pozyskujemy z operacyjnych magazynów danych, zawierają pewne dodatkowe dane, które są zazwyczaj sumowane w naszej analizie. Są to aspekty faktu, które pozwalają analitykowi, lub osobie zarządzającej przeglądającej analizę, dostrzec wartość w fakcie.

Dlaczego musisz utrzymywać spójne ziarno?

Aby zapewnić, że twój system może legalnie korelować i agregować fakty.

Ale nie zawsze jest możliwe posiadanie danych na poziomie atomowym. Tak więc, aby wypełnić tę lukę, istnieją dwie metody:

• Periodic Snapshot Fact Tables
• Accumulating Snapshot Fact Tables

Periodic Snapshot Fact Tables

Jak sama nazwa wskazuje, są one zbierane w regularnych odstępach czasu. Zużycie gazu, audyt i inspekcje są niektórymi przypadkami zbierania danych, które mają włączone okresowe migawki dla nich.

Accumulating Snapshot Fact Tables

Gdy wskaźnik wydajności biznesowej jest wskaźnikiem ukończenia wieloetapowego procesu biznesowego, możesz chcieć uchwycić ziarno całego procesu i nagrać początek, zakończenie i kroki pomiędzy. To może być transakcja-grained, ale ma wiele środków pomiędzy. Tak więc, używasz tabel faktów z migawkami, aby odpowiedzieć na złożone pytania w wywiadzie biznesowym, gdzie występuje upływ czasu pomiędzy faktami. Dobrym przykładem może być wiersz tabeli faktów dotyczący zamówienia kanapki z kurczakiem i wiersz tabeli faktów dotyczący podania torby przez okno samochodu w McDonald’s drive-thru.

Lokalizacja faktów za pomocą wymiarów

Ty i Twoi analitycy musicie wiedzieć, jak odpytywać i filtrować fakty, aby uzyskać z nich informacje biznesowe. Temu celowi służą wymiary.

Wyciąganie wymiarów z danych referencyjnych i Raw-Meta

Wymiary są prawie zawsze tworzone z kluczem zastępczym; klucz zastępczy, naturalnie, jest przywoływany przez klucz obcy (lub klucze) w tabeli faktów. Przeszukujemy tabelę przeszukując wymiary, które nas interesują. Wszystkie inne dane opisujące nasze fakty, takie jak znaczniki czasu, agenci klienta, lokalizacja sklepu, produkt i klient są tym, co zamieniamy w wymiary.

Piękno modelowania wymiarowego polega na tym, że fakty nie są definiowane przez klucze główne lub jakikolwiek rodzaj unikalnego identyfikatora, zamiast tego są one definiowane przez kombinację wymiarów. To daje początek Star Schema.

Bardzo ważne jest, abyśmy mieli unikalność w naszych wymiarach. Kiedy dostaniemy się do zapytań przez fakty, duplikaty wśród kombinacji wymiarów zamienią się w katastrofę. Jeśli nie możesz, to dodaj lub agreguj wymiary, aby uczynić je unikalnymi.

Hierarchia w wymiarach

Rozważ następujące dwa obrazy.

Analityk będzie miał łatwe życie, jeśli skonfigurujesz dla niego/niej tabelę drugiego wymiaru.

Więc, mając drugą tabelę, masz następującą hierarchię:

Istnieją wszystkie rodzaje hierarchii – hierarchie wielokrotne, hierarchie pojedyncze itp. Nie zajmuję się nimi w tym wpisie na blogu.

Jedną rzeczą, na którą chciałbym zwrócić uwagę, jest to, że wymiar czasu jest prawdziwym bólem w szyi. Trzeba dbać o magiczne dni, kalendarz fiskalny, strefy czasowe, cykle (typu zysk na kwartał). I nie bądź marny lub zbyt pewny siebie w tym, nawet bazy danych serii czasowych nie pomogą ci w hierarchiach, jeśli twój ETL jest zepsuty. Możesz chcieć rzucić okiem na wymiary Outrigger. Istnieją również przypadki, w których jeden wymiar jest naturalnie zależny od drugiego. W takim przypadku projektanci mogą umieścić klucz obcy z jednego do drugiego. To właśnie stanowi „wymiar nadrzędny” (outrigger dimension). W wymiarach kalendarzowych jest to bardzo częste.

Nie można używać daty w innym ziarnie w wymiarze wyjściowym niż daty, których używasz w tabeli faktów. Nie możesz pozwolić na agregację nad wymiarami outrigger. Jeśli to konieczne, maskuj wartości numeryczne w agregatorze za pomocą tekstowych prefiksów lub sufiksów, aby to uniemożliwić.

Powolna zmiana wymiarów

Tak bardzo, jak chciałbym o tym napisać, nadal uważam, że lepiej dla moich czytelników, aby dokładnie zrozumieli tę koncepcję stąd.

Nie omawiam wymiarów Snowflake, ale tylko dla zaznaczenia, są one nadal używane w bazach danych OLAP.

Integrate your Big Data Into Your ETL System

Będziesz traktował swoje tabelaryczne Big Data jako pozyskane poprzez jedną z twoich standardowych faz Extract. Dlatego zastosujesz do nich te same kroki, które wykonałeś w transformacji:

1. Czyszczenie danych
2. Konformowanie jednostek i formatów
3. De-duplikacja
4. Restrukturyzacja
5. Staging

Podsumowanie

Chciałem zrozumieć teoretyczne aspekty projektowania baz danych, co doprowadziło mnie do przeczytania książki Rossa i Kimballa. Następnie zaciekawiły mnie różnice i analogie w ich metodach i dzisiejszych wiodących firm opartych na danych, takich jak Netflix, Airbnb, Uber, itp.

W tym poszukiwaniu mogę uczciwie powiedzieć, że ustrukturyzowany format modelowania wymiarowego jest preferowany w stosunku do hardkorowego ETL. Ponieważ w ten sposób usuwasz zależność od ciebie, twój zespół BI nie dzwoni do ciebie na Slack, aby utworzyć nowy DAG dla każdego innego wglądu, zamiast tego, dzięki poprawnemu modelowaniu, umożliwiasz im swobodne działanie i eksplorację bez twojej potrzeby.

Proszę o pozostawienie informacji zwrotnej, jak mógłbym się poprawić, jestem pewien, że nie była to Twoja najlepsza lektura. Dziękuję za poświęcony czas.

Przypisy

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross i Kimball, rozdz. 2 i rozdz. 18

Kimball/Ross pp103-109

.