Budowa obiektu magazynowego jest przedsięwzięciem długim i poważnym.
Wiele w życiu projektu zależy od tego, jak dobrze przemyślany zostanie model obiektu i struktura bazowa na początku.
Ogólnie przyjętym podejściem były i pozostają różne opcje łączenia schematu gwiazdy z trzecią postacią normalną. Z reguły zgodnie z zasadą: dane początkowe - 3NF, gabloty - gwiazda. Takie podejście, sprawdzone w czasie i poparte dużą ilością badań, jest pierwszą (a czasem jedyną) rzeczą, która przychodzi do głowy doświadczonemu specjaliście DWH, gdy myśli o tym, jak powinno wyglądać repozytorium analityczne.
Z drugiej strony biznes w ogóle, a wymagania klientów w szczególności mają tendencję do szybkich zmian, a dane mają tendencję do powiększania się zarówno „w głąb”, jak i „wszerz”. I tu pojawia się główna wada gwiazdy - ograniczona elastyczność.
A jeśli w swoim spokojnym i przytulnym życiu programisty DWH nagle:
- powstało zadanie „zrobić przynajmniej coś szybko, a potem zobaczymy”;
- pojawił się prężnie rozwijający się projekt, obejmujący podłączenie nowych źródeł i przeróbkę modelu biznesowego przynajmniej raz w tygodniu;
- pojawił się klient, który nie ma pojęcia, jak system powinien wyglądać i jakie funkcje docelowo powinien pełnić, ale jest gotowy eksperymentować i konsekwentnie udoskonalać pożądany efekt, jednocześnie konsekwentnie się do niego zbliżając;
- Kierownik projektu wpadł do nas z dobrą wiadomością: „A teraz mamy Agile!”
Lub jeśli po prostu chcesz dowiedzieć się, jak jeszcze możesz zbudować obiekty magazynowe - zapraszamy do cięcia!
Co oznacza „elastyczność”?
Najpierw zdefiniujmy, jakie właściwości musi posiadać system, aby można go było nazwać „elastycznym”.
Osobno warto wspomnieć, że opisane właściwości powinny konkretnie dotyczyć system, nie proces jego rozwój. Dlatego jeśli chcesz przeczytać o Agile jako metodologii rozwoju, lepiej przeczytać inne artykuły. Na przykład właśnie tam, na Habré, znajduje się wiele ciekawych materiałów (np и I ).
Nie oznacza to jednak, że proces rozwoju i struktura hurtowni danych są całkowicie niezależne. Ogólnie rzecz biorąc, opracowanie repozytorium Agile dla zwinnej architektury powinno być znacznie łatwiejsze. Jednak w praktyce częściej pojawiają się opcje zwinnego rozwoju klasycznego DWH według Kimbala i DataVault - zdaniem Waterfall, niż szczęśliwe zbiegi okoliczności elastyczności w dwóch jej formach w jednym projekcie.
Jakie zatem możliwości powinna mieć elastyczna pamięć masowa? Są tu trzy punkty:
- Wczesna dostawa i szybka realizacja - oznacza to, że w idealnym przypadku pierwszy wynik biznesowy (np. pierwsze raporty robocze) powinien zostać uzyskany możliwie najwcześniej, czyli jeszcze zanim cały system zostanie w pełni zaprojektowany i wdrożony. Co więcej, każda kolejna rewizja również powinna zająć jak najmniej czasu.
- Iteracyjne udoskonalanie - oznacza to, że w idealnym przypadku każde kolejne ulepszenie nie powinno wpływać na funkcjonalność, która już działa. To właśnie ten moment często staje się największą koszmarem przy dużych projektach – prędzej czy później poszczególne obiekty zaczynają nabywać tak wiele połączeń, że łatwiej jest całkowicie powtórzyć logikę w kopii obok, niż dodać pole do istniejącej tabeli. A jeśli dziwisz się, że analiza wpływu ulepszeń na istniejące obiekty może zająć więcej czasu niż same ulepszenia, to najprawdopodobniej nie miałeś jeszcze do czynienia z dużymi hurtowniami danych w bankowości czy telekomunikacji.
- Ciągłe dostosowywanie się do zmieniających się wymagań biznesowych - ogólną konstrukcję obiektu należy projektować nie tylko z uwzględnieniem możliwej rozbudowy, ale z założeniem, że na etapie projektowania nie można było nawet marzyć o kierunku tej kolejnej rozbudowy.
I tak, spełnienie wszystkich tych wymagań w jednym systemie jest możliwe (oczywiście w określonych przypadkach i z pewnymi zastrzeżeniami).
Poniżej rozważę dwie najpopularniejsze metodologie zwinnego projektowania hurtowni danych - Model kotwicy и Magazyn danych. W nawiasie pominięto tak doskonałe techniki jak np. EAV, 6NF (w czystej postaci) i wszystko, co związane z rozwiązaniami NoSQL - nie dlatego, że są w jakiś sposób gorsze, ani nawet dlatego, że w tym przypadku artykuł groziłby przejęciem objętość przeciętnego dissera. Tyle, że to wszystko odnosi się do rozwiązań nieco innej klasy – albo do technik, które można zastosować w konkretnych przypadkach, niezależnie od ogólnej architektury Twojego projektu (jak EAV), albo do innych globalnie paradygmatów przechowywania informacji (jak np. grafowe bazy danych i inne opcje NoSQL).
Problemy podejścia „klasycznego” i ich rozwiązania w metodykach elastycznych
Przez podejście „klasyczne” mam na myśli starą, dobrą gwiazdę (niezależnie od konkretnej implementacji leżących u jej podstaw warstw, niech mi wybaczą zwolennicy Kimballa, Inmona i CDM).
1. Sztywna liczność połączeń
Model ten opiera się na przejrzystym podziale danych na Wymiar и fakty. I to, do cholery, jest logiczne - wszak analiza danych w przeważającej większości przypadków sprowadza się do analizy pewnych wskaźników liczbowych (faktów) w określonych przekrojach (wymiarach).
W tym przypadku połączenia między obiektami ustanawiane są w formie relacji między tabelami przy użyciu klucza obcego. Wygląda to całkiem naturalnie, ale od razu prowadzi do pierwszego ograniczenia elastyczności – ścisła definicja liczności połączeń.
Oznacza to, że na etapie projektowania tabeli należy dokładnie określić dla każdej pary powiązanych obiektów, czy mogą one odnosić się tyle do wielu, czy tylko 1 do wielu oraz „w jakim kierunku”. To bezpośrednio określa, która tabela będzie miała klucz podstawowy, a która będzie miała klucz obcy. Zmiana tego podejścia w przypadku pojawienia się nowych wymagań najprawdopodobniej doprowadzi do przeróbki bazy.
Na przykład projektując obiekt „paragon gotówkowy”, opierając się na przysięgach działu sprzedaży, określiłeś możliwość działania jedna promocja na kilka stanowisk kontrolnych (ale nie odwrotnie):
A po pewnym czasie koledzy wprowadzili nową strategię marketingową, w której mogą działać na tym samym stanowisku kilka promocji jednocześnie. A teraz musisz zmodyfikować tabele, oddzielając relację od osobnego obiektu.
(Wszystkie obiekty pochodne, w których połączona jest kontrola awansu, również wymagają poprawy).
Relacje w magazynie danych i modelu zakotwiczenia
Uniknięcie tej sytuacji okazało się dość proste: nie musisz ufać działowi sprzedaży, aby to zrobić. wszystkie połączenia są początkowo przechowywane w oddzielnych tabelach i przetwarzaj go jako wiele do wielu.
Zaproponowano takie podejście Dana Linstedta jako część paradygmatu Magazyn danych i w pełni obsługiwane Larsa Rönnbäcka в Model kotwicy.
W rezultacie otrzymujemy pierwszą charakterystyczną cechę elastycznych metodologii:
Relacje między obiektami nie są przechowywane w atrybutach encji nadrzędnych, ale stanowią odrębny typ obiektów.
В Magazyn danych takie tabele łączące nazywane są Połączyća w Model kotwicy - Tie. Na pierwszy rzut oka są bardzo podobne, choć różnice nie kończą się na nazwie (o czym będzie mowa poniżej). W obu architekturach tabele łączy mogą być łączone dowolną liczbę podmiotów (niekoniecznie 2).
Ta redundancja na pierwszy rzut oka zapewnia znaczną elastyczność modyfikacji. Taka struktura staje się tolerancyjna nie tylko na zmiany w liczebności istniejących powiązań, ale także na dodawanie nowych – jeśli teraz pozycja czekowa ma także powiązanie z kasjerem, który się przez nią przebił, pojawienie się takiego powiązania będzie po prostu stać się dodatkiem do istniejących tabel bez wpływu na istniejące obiekty i procesy.
2. Powielanie danych
Drugi problem rozwiązywany przez elastyczne architektury jest mniej oczywisty i przede wszystkim jest nieodłączny. Pomiary typu SCD2 (powoli zmieniające się wymiary drugiego typu), choć nie tylko one.
W klasycznym magazynie wymiarem jest zazwyczaj tabela zawierająca klucz zastępczy (jako PK) oraz zestaw kluczy biznesowych i atrybutów w oddzielnych kolumnach.
Jeśli wymiar obsługuje wersjonowanie, do standardowego zestawu pól dodawane są granice ważności wersji, a w repozytorium pojawia się kilka wersji dla jednego wiersza w źródle (po jednej dla każdej zmiany wersjonowanych atrybutów).
Jeśli wymiar zawiera przynajmniej jeden często zmieniający się wersjonowany atrybut, liczba wersji takiego wymiaru będzie imponująca (nawet jeśli pozostałe atrybuty nie są wersjonowane lub nigdy się nie zmieniają), a jeśli takich atrybutów jest kilka, liczba wersji może rosną wykładniczo od ich liczby. Wymiar ten może zajmować znaczną ilość miejsca na dysku, chociaż większość przechowywanych w nim danych to po prostu duplikaty niezmiennych wartości atrybutów z innych wierszy.
Jednocześnie jest również bardzo często używany denormalizacja — niektóre atrybuty są celowo przechowywane jako wartość, a nie jako link do podręcznika lub innego wymiaru. Takie podejście przyspiesza dostęp do danych, zmniejszając liczbę złączeń podczas uzyskiwania dostępu do wymiaru.
Zwykle prowadzi to do te same informacje są przechowywane jednocześnie w kilku miejscach. Przykładowo, informacje o regionie zamieszkania i kategorii klienta mogą być jednocześnie przechowywane w wymiarach „Klient” oraz faktach „Zakup”, „Dostawa” i „Połączenia z Call Center”, a także w zakładce „Klient – Menadżer Klienta”. ”tabela linków.
Ogólnie rzecz biorąc, powyższe dotyczy wymiarów zwykłych (niewersjonowanych), jednak w wersjonowanych mogą one mieć inną skalę: pojawienie się nowej wersji obiektu (szczególnie z perspektywy czasu) prowadzi nie tylko do aktualizacji wszystkich powiązanych tabele, ale do kaskadowego pojawiania się nowych wersji powiązanych obiektów - gdy Tabela 1 jest używana do budowania Tabeli 2, a Tabela 2 służy do budowania Tabeli 3 itd. Nawet jeśli w konstrukcji Tabeli 1 nie bierze się pod uwagę ani jednego atrybutu Tabeli 3 (a inne atrybuty Tabeli 2 uzyskane z innych źródeł są zaangażowane), wersjonowanie tej konstrukcji doprowadzi co najmniej do dodatkowych kosztów, a maksymalnie do dodatkowych wersje w Tabeli 3, która w ogóle nie ma z tym nic wspólnego, i na dalszych etapach łańcucha.
3. Nieliniowa złożoność przeróbek
Jednocześnie każda nowa witryna sklepowa zbudowana na bazie innej zwiększa liczbę miejsc, w których dane mogą się „odbiegać” w przypadku wprowadzenia zmian w ETL. To z kolei prowadzi do wzrostu złożoności (i czasu trwania) każdej kolejnej rewizji.
Jeśli powyższe opisuje systemy z rzadko modyfikowanymi procesami ETL, to można żyć w takim paradygmacie - wystarczy tylko zadbać o to, aby nowe modyfikacje zostały poprawnie wykonane we wszystkich powiązanych obiektach. Jeśli poprawki pojawiają się często, prawdopodobieństwo przypadkowego „pominięcia” kilku połączeń znacznie wzrasta.
Jeśli dodatkowo weźmiemy pod uwagę, że „wersjonowany” ETL jest znacznie bardziej skomplikowany niż „niewersjonowany”, dość trudno jest uniknąć błędów przy częstej aktualizacji całego tego obiektu.
Przechowywanie obiektów i atrybutów w Data Vault i Anchor Model
Podejście zaproponowane przez autorów architektur elastycznych można sformułować następująco:
Konieczne jest oddzielenie tego, co się zmienia, od tego, co pozostaje takie samo. Oznacza to, że przechowuj klucze oddzielnie od atrybutów.
Nie należy jednak mylić nie wersjonowany atrybut z niezmienione: pierwszy nie przechowuje historii swoich zmian, ale może ulec zmianie (na przykład podczas poprawiania błędu wejściowego lub otrzymania nowych danych); drugi nigdy się nie zmienia.
Punkty widzenia różnią się w kwestii tego, co dokładnie można uznać za niezmienne w magazynie danych i modelu kotwicy.
Z architektonicznego punktu widzenia Magazyn danych, można uznać za niezmienione cały komplet kluczy - naturalny (NIP organizacji, kod produktu w systemie źródłowym itp.) i zastępczy. W tym przypadku pozostałe atrybuty można podzielić na grupy ze względu na źródło i/lub częstotliwość zmian Dla każdej grupy utwórz oddzielną tabelę z niezależnym zestawem wersji.
W paradygmacie Model kotwicy uznane za niezmienione tylko klucz zastępczy istota. Wszystko inne (w tym klucze naturalne) to tylko szczególny przypadek jego atrybutów. W której wszystkie atrybuty są domyślnie od siebie niezależne, więc dla każdego atrybutu a oddzielny stół.
В Magazyn danych wywoływane są tabele zawierające klucze jednostek Hubami. Huby zawsze zawierają stały zestaw pól:
- Klucze jednostek naturalnych
- Klucz zastępczy
- Link do źródła
- Rejestruj czas dodawania
Posty w Hubach nigdy się nie zmieniają i nie mają wersji. Zewnętrznie koncentratory są bardzo podobne do tabel typu ID-map używanych w niektórych systemach do generowania surogatów, jednak zaleca się użycie skrótu z zestawu kluczy biznesowych jako surogatów w Data Vault. Takie podejście upraszcza ładowanie relacji i atrybutów ze źródeł (nie trzeba dołączać do koncentratora, aby uzyskać surogat, wystarczy obliczyć skrót klucza naturalnego), ale może powodować inne problemy (związane na przykład z kolizjami, wielkością liter i niedrukowalnymi znaki w kluczach łańcuchowych itp.), dlatego nie jest to ogólnie akceptowane.
Wszystkie pozostałe atrybuty encji przechowywane są w specjalnych tabelach tzw Satelity. Jeden koncentrator może mieć kilka satelitów przechowujących różne zestawy atrybutów.
Podział atrybutów pomiędzy satelitami odbywa się zgodnie z zasadą wspólna zmiana — w jednym satelicie można przechowywać atrybuty niewersjonowane (np. data urodzenia i SNILS dla danej osoby), w innym – wersjonowane rzadko zmieniające się (np. nazwisko i numer paszportu), w trzecim – często zmieniające się (na przykład adres dostawy, kategoria, data ostatniego zamówienia itp.). Wersjonowanie odbywa się w tym przypadku na poziomie poszczególnych satelitów, a nie całości, dlatego wskazane jest takie rozłożenie atrybutów, aby przecięcie wersji w obrębie jednego satelity było jak najmniejsze (co zmniejsza łączną liczbę przechowywanych wersji ).
Ponadto, aby zoptymalizować proces ładowania danych, często w poszczególnych satelitach uwzględniane są atrybuty uzyskane z różnych źródeł.
Satelity komunikują się z Hubem poprzez klucz obcy (co odpowiada liczności 1 do wielu). Oznacza to, że wiele wartości atrybutów (na przykład wiele numerów telefonów kontaktowych dla jednego klienta) jest obsługiwanych przez tę „domyślną” architekturę.
В Model kotwicy nazywane są tabele przechowujące klucze Kotwice. I zachowują:
- Tylko klucze zastępcze
- Link do źródła
- Rejestruj czas dodawania
Rozważane są klucze naturalne z punktu widzenia Modelu Kotwicy zwykłe atrybuty. Ta opcja może wydawać się trudniejsza do zrozumienia, ale daje znacznie większe możliwości identyfikacji obiektu.
Na przykład, jeśli dane dotyczące tej samej jednostki mogą pochodzić z różnych systemów, z których każdy używa własnego klucza naturalnego. W Data Vault może to prowadzić do dość uciążliwych struktur składających się z kilku koncentratorów (po jednym na źródło + ujednolicająca wersja główna), podczas gdy w modelu Anchor naturalny klucz każdego źródła przypisany jest do jego własnego atrybutu i może być używany podczas ładowania niezależnie od wszyscy inni.
Ale jest tu też jeden podstępny punkt: jeśli atrybuty z różnych systemów zostaną połączone w jedną całość, najprawdopodobniej istnieją pewne zasady „sklejania”, zgodnie z którym system musi zrozumieć, że rekordy z różnych źródeł odpowiadają jednej instancji jednostki.
В Magazyn danych te zasady najprawdopodobniej określą formację „centrum zastępcze” jednostki nadrzędnej i w żaden sposób nie wpływać na Huby przechowujące naturalne klucze źródłowe i ich oryginalne atrybuty. Jeśli w pewnym momencie zasady łączenia ulegną zmianie (lub atrybuty, według których jest ono wykonywane, zostaną zaktualizowane), wystarczy sformatować koncentratory zastępcze.
В Model kotwicy taki podmiot najprawdopodobniej będzie przechowywany w jedyna kotwica. Oznacza to, że wszystkie atrybuty, niezależnie od źródła, z którego pochodzą, będą powiązane z tym samym surogatem. Oddzielenie błędnie scalonych rekordów i w ogóle monitorowanie zasadności łączenia w takim systemie może być znacznie trudniejsze, szczególnie jeśli zasady są dość złożone i często się zmieniają, a ten sam atrybut można uzyskać z różnych źródeł (choć z pewnością jest to możliwe, ponieważ każda wersja atrybutu zachowuje łącze do swojego źródła).
W każdym razie, jeśli Twój system ma implementować tę funkcjonalność deduplikacja, łączenie rekordów i inne elementy MDM, warto zwrócić szczególną uwagę na aspekty przechowywania kluczy naturalnych w metodykach zwinnych. Jest prawdopodobne, że bardziej masywny projekt magazynu danych nagle stanie się bezpieczniejszy pod względem błędów scalania.
Model kotwicy udostępnia również dodatkowy typ obiektu o nazwie Węzeł jest zasadniczo wyjątkowy zdegenerowany typ kotwicy, który może zawierać tylko jeden atrybut. Węzły mają służyć do przechowywania katalogów płaskich (np. płeć, stan cywilny, kategoria obsługi klienta itp.). W przeciwieństwie do Kotwicy, Węzeł nie ma powiązanych tabel atrybutów, a jego jedyny atrybut (nazwa) jest zawsze przechowywany w tej samej tabeli co klucz. Węzły są połączone z Anchorami za pomocą tabel powiązań (Tie) w taki sam sposób, w jaki Anchors są połączone ze sobą.
Nie ma jednoznacznej opinii na temat stosowania Nodesów. Na przykład, , który aktywnie promuje stosowanie Modelu Kotwicy w Rosji, uważa (co nie jest bezpodstawne), że w przypadku ani jednego podręcznika nie można z całą pewnością stwierdzić, że jest to zawsze będzie statyczny i jednopoziomowy, dlatego lepiej od razu użyć pełnoprawnej Kotwicy dla wszystkich obiektów.
Kolejną ważną różnicą pomiędzy Data Vault a modelem Anchor jest dostępność atrybuty połączeń:
В Magazyn danych Łącza są tymi samymi pełnoprawnymi obiektami co Huby i mogą je posiadać własne atrybuty, Model kotwicy Linki służą wyłącznie do łączenia Anchorów i nie mogą mieć własnych atrybutów. Ta różnica skutkuje znacząco odmiennymi podejściami do modelowania fakty, co zostanie omówione dalej.
Przechowywanie faktów
Wcześniej mówiliśmy głównie o modelowaniu pomiarów. Fakty są trochę mniej jasne.
В Magazyn danych typowym obiektem do przechowywania faktów jest Połączyć, w których satelitach dodawane są rzeczywiste wskaźniki.
To podejście wydaje się intuicyjne. Zapewnia łatwy dostęp do analizowanych wskaźników i zasadniczo przypomina tradycyjną tabelę faktów (tylko że wskaźniki przechowywane są nie w samej tabeli, a w „sąsiedniej” tabeli). Ale są też pułapki: jedna z typowych modyfikacji modelu – rozszerzenie klucza faktów – wymaga dodanie nowego klucza obcego do Link. A to z kolei „łamie” modułowość i potencjalnie powoduje konieczność modyfikacji innych obiektów.
В Model kotwicy Połączenie nie może mieć własnych atrybutów, więc to podejście nie będzie działać - absolutnie wszystkie atrybuty i wskaźniki muszą być powiązane z jedną konkretną kotwicą. Wniosek z tego jest prosty – Każdy fakt potrzebuje także własnej kotwicy. W przypadku niektórych z tego, co zwykliśmy postrzegać jako fakty, może to wyglądać naturalnie – na przykład fakt zakupu można doskonale sprowadzić do obiektu „zamówienie” lub „odbiór”, odwiedzenie witryny do sesji itp. Ale są też fakty, dla których nie jest łatwo znaleźć taki naturalny „obiekt nośnika” – na przykład resztki towaru w magazynach na początku każdego dnia.
W związku z tym nie pojawiają się problemy z modułowością przy rozwijaniu klucza faktów w modelu Anchor (wystarczy po prostu dodać nową Relację do odpowiedniej Anchor), ale zaprojektowanie modelu tak, aby wyświetlał fakty jest mniej jednoznaczne; mogą pojawić się „sztuczne” Kotwice które w niejasny sposób przedstawiają model obiektu biznesowego.
Jak osiąga się elastyczność
Powstała konstrukcja w obu przypadkach zawiera znacznie więcej stołówniż tradycyjny pomiar. Ale to może zająć znacznie mniej miejsca na dysku z tym samym zestawem wersjonowanych atrybutów, co wymiar tradycyjny. Oczywiście nie ma tu żadnej magii - chodzi o normalizację. Dystrybuując atrybuty pomiędzy satelitami (w magazynie danych) lub pojedynczymi tabelami (model kotwicy), zmniejszamy (lub całkowicie eliminujemy) powielanie wartości niektórych atrybutów przy zmianie innych.
dla Magazyn danych wygrana będzie zależała od podziału atrybutów pomiędzy satelitami i od Model kotwicy — jest niemal wprost proporcjonalna do średniej liczby wersji na obiekt pomiarowy.
Jednakże oszczędność miejsca jest ważną, ale nie główną zaletą oddzielnego przechowywania atrybutów. Razem z oddzielnym przechowywaniem relacji, takie podejście tworzy sklep konstrukcja modułowa. Oznacza to, że w takim modelu wygląda dodawanie zarówno pojedynczych atrybutów, jak i całych nowych obszarów tematycznych nadbudowa nad istniejącym zestawem obiektów bez ich zmiany. I to właśnie sprawia, że opisane metodyki są elastyczne.
Przypomina to też przejście od produkcji jednostkowej do masowej – jeśli w podejściu tradycyjnym każdy stół modelu jest niepowtarzalny i wymaga szczególnej uwagi, to w metodykach elastycznych jest to już zbiór standardowych „części”. Z jednej strony tabel jest więcej, a procesy ładowania i odzyskiwania danych powinny wyglądać na bardziej skomplikowane. Z drugiej strony stają się typowy. Co oznacza, że może istnieć zautomatyzowane i oparte na metadanych. Pytanie „jak to ułożymy?”, na które odpowiedź mogłaby zająć znaczną część pracy nad projektowaniem ulepszeń, jest teraz po prostu nie tego warte (podobnie jak pytanie o wpływ zmiany modelu na procesy robocze ).
Nie oznacza to jednak, że analitycy nie są w ogóle potrzebni w takim systemie – ktoś jeszcze musi przepracować zbiór obiektów z atrybutami i dowiedzieć się, gdzie i jak to wszystko załadować. Jednak ilość pracy, a także prawdopodobieństwo i koszt błędu są znacznie zmniejszone. Zarówno na etapie analizy, jak i podczas tworzenia ETL, które w znacznej części można sprowadzić do edycji metadanych.
Ciemna strona
Wszystko to sprawia, że oba podejścia są naprawdę elastyczne, zaawansowane technologicznie i nadają się do iteracyjnego doskonalenia. Oczywiście jest też „beczka w maści”, o czym myślę, że już się domyślacie.
Dekompozycja danych, która leży u podstaw modułowości elastycznych architektur, prowadzi do wzrostu liczby tabel i, co za tym idzie, nad głową do łączenia podczas próbkowania. Aby po prostu uzyskać wszystkie atrybuty wymiaru, w klasycznym sklepie wystarczy jeden wybór, ale elastyczna architektura będzie wymagała całej serii złączeń. Co więcej, jeśli wszystkie te łączenia raportów można napisać z wyprzedzeniem, analitycy przyzwyczajeni do ręcznego pisania SQL ucierpią podwójnie.
Jest kilka faktów, które ułatwiają tę sytuację:
Podczas pracy z dużymi wymiarami wszystkie jego atrybuty prawie nigdy nie są używane jednocześnie. Oznacza to, że złączeń może być mniej, niż mogłoby się wydawać na pierwszy rzut oka na modelu. Data Vault może także uwzględniać oczekiwaną częstotliwość udostępniania podczas przydzielania atrybutów satelitom. Jednocześnie same Huby lub Anchors są potrzebne przede wszystkim do generowania i mapowania surogatów na etapie ładowania i rzadko są używane w zapytaniach (dotyczy to szczególnie Anchorów).
Wszystkie połączenia są realizowane według klucza. Ponadto bardziej „skompresowany” sposób przechowywania danych zmniejsza obciążenie tabel skanowania tam, gdzie jest to potrzebne (na przykład podczas filtrowania według wartości atrybutu). Może to prowadzić do tego, że próbkowanie ze znormalizowanej bazy danych z dużą liczbą złączeń będzie nawet szybsze niż skanowanie jednego dużego wymiaru z wieloma wersjami w wierszu.
Na przykład tutaj, w W artykule dokonano szczegółowego testu porównawczego działania modelu Anchor z próbą z jednej tabeli.
Wiele zależy od silnika. Wiele nowoczesnych platform ma wewnętrzne mechanizmy optymalizacji łączenia. Na przykład MS SQL i Oracle mogą „pominąć” złączenia do tabel, jeśli ich dane nie są używane nigdzie poza innymi złączeniami i nie ma to wpływu na ostateczny wybór (eliminacja tabeli/złączenia), a MPP Vertica , okazał się doskonałym silnikiem dla modelu Anchor, biorąc pod uwagę ręczną optymalizację planu zapytań. Z drugiej strony przechowywanie modelu Anchor na przykład w Click House, który ma ograniczoną obsługę złączeń, nie wygląda jeszcze na zbyt dobry pomysł.
Ponadto dla obu architektur istnieją specjalne ruchy, ułatwiając dostęp do danych (zarówno z punktu widzenia wydajności zapytań, jak i dla użytkowników końcowych). Na przykład, Tabele punktów w czasie w Magazynie Danych lub specjalne funkcje tabeli w modelu Anchor.
Razem
Główną istotą rozważanych elastycznych architektur jest modułowość ich „konstrukcji”.
To właśnie ta właściwość pozwala na:
- Po wstępnych przygotowaniach związanych z wdrażaniem metadanych i napisaniem podstawowych algorytmów ETL, szybko dostarczyć klientowi pierwszy efekt w formie kilku raportów zawierających dane z zaledwie kilku obiektów źródłowych. Nie jest konieczne dokładne przemyślenie (nawet na najwyższym poziomie) całego modelu obiektowego.
- Model danych może zacząć działać (i być użyteczny) już z 2-3 obiektami, a potem rosnąć stopniowo (dotyczy modelu Anchor Nikolai niezłe porównanie z grzybnią).
- Większość usprawnień, m.in. poszerzenie obszaru tematycznego i dodanie nowych źródeł nie wpływa na istniejącą funkcjonalność i nie stwarza ryzyka zniszczenia czegoś, co już działa.
- Dzięki dekompozycji na elementy standardowe procesy ETL w takich systemach wyglądają tak samo, ich zapis poddaje się algorytmizacji i w efekcie automatyzacja.
Cena tej elastyczności jest taka wydajność. Nie oznacza to, że w takich modelach niemożliwe jest osiągnięcie akceptowalnej wydajności. W większości przypadków osiągnięcie pożądanych wskaźników może wymagać po prostu więcej wysiłku i skupienia uwagi na szczegółach.
aplikacje
Typy jednostek Magazyn danych
Więcej informacji o Magazynie Danych:
Typy jednostek Model kotwicy
Więcej szczegółów na temat modelu kotwicy:
Tabela podsumowująca z cechami wspólnymi i różnicami rozważanych podejść:
Źródło: www.habr.com