🥇Przegląd zwinnych metodologii projektowania DWH

Tworzenie składowiska to długotrwały i poważny proces.

Wiele w życiu projektu zależy od tego, jak dobrze zaplanowany jest model obiektowy i struktura bazy na początku.

Powszechnie stosowanym podejściem były i pozostają różne warianty połączenia schematu 'gwiazdy' z trzecią normalną formą. Zasada jest zazwyczaj taka: dane źródłowe — 3NF, hurtownie — gwiazda. To podejście, sprawdzone w czasie i potwierdzone wieloma badaniami — to pierwsze (a czasem i jedyne), co przychodzi do głowy doświadczonemu specjalistowi DWH, kiedy myśli o tym, jak powinno wyglądać analityczne składowisko.

Z drugiej strony — biznes ogólnie i wymagania klienta szczególnie, mają tendencję do szybkiej zmiany, a dane — do rozwoju zarówno 'w głąb', jak i 'na szerokość'. I tutaj objawia się główny brak gwiazdy — ograniczona elastyczność.

I jeśli w Twoim cichym i przytulnym życiu dewelopera DWH nagle:

pojawia się zadanie 'zrób szybko cokolwiek, a potem zobaczymy';
występuje szybko rozwijający się projekt, z podłączeniem nowych źródeł i przeróbką modelu biznesowego co najmniej raz w tygodniu;
pojawia się klient, który nie wyobraża sobie, jak ma wyglądać system i jakie funkcje ma spełniać w końcu, ale jest gotów na eksperymenty i stopniowe doprecyzowanie pożądanego wyniku z cyklicznym zbliżaniem się do niego;
ukazał się menedżer projektu z radosną nowiną: 'A teraz mamy Agile!'.

Lub jeśli po prostu chcesz się dowiedzieć, jak jeszcze można budować składowiska — zapraszamy poniżej!

Co oznacza 'elastyczność'

Na początek ustalmy, jakie cechy powinna mieć system, aby można go było nazwać 'elastycznym'.

Osobno należy zaznaczyć, że opisane cechy powinny odnosić się właśnie do systemu, a nie do procesu jego rozwoju. Dlatego jeśli chciałeś przeczytać o Agile jako metodologii rozwoju, lepiej zapoznać się z innymi artykułami. Na przykład, na Habrze znajduje się mnóstwo interesujących materiałów (zarówno przeglądowych i praktycznych, jak i problemowych).

To nie oznacza, że proces tworzenia i struktura hurtowni danych w żaden sposób nie są ze sobą powiązane. Ogólnie rzecz biorąc, rozwijanie hurtowni z elastyczną architekturą w podejściu Agile powinno być znacznie łatwiejsze. W praktyce jednak częściej spotykamy przypadki związane z klasycznym DWH według Kimbala oraz Data Vault — w metodyce kaskadowej, niż szczęśliwe zbiegi okoliczności w elastyczności w obu jej formach w jednym projekcie.

A więc, jakie cechy powinno mieć elastyczne hurtownia danych? Można wyróżnić trzy punkty:

Wczesna dostawa i szybka modyfikacja — to oznacza, że idealnie pierwszy wynik biznesowy (na przykład pierwsze działające raporty) powinien być uzyskany jak najszybciej, czyli jeszcze przed pełnym zaprojektowaniem i wdrożeniem całego systemu. Przy tym każda kolejna modyfikacja również powinna zajmować jak najmniej czasu.
Iteracyjna modyfikacja — to oznacza, że każda kolejna modyfikacja nie powinna w idealnym przypadku wpływać na już działające funkcje. Ten moment często staje się największym koszmarem w dużych projektach - prędzej czy później poszczególne obiekty zaczynają gromadzić tak wiele zależności, że łatwiej jest całkowicie powielić logikę w obok, niż dodać pole do istniejącej tabeli. A jeśli zastanawiasz się, dlaczego analiza wpływu modyfikacji na istniejące obiekty może zajmować więcej czasu niż sama modyfikacja — prawdopodobnie jeszcze nie pracowałeś z dużymi hurtowniami danych w bankowości lub telekomunikacji.
Ciągła adaptacja do zmieniających się wymagań biznesowych — ogólna struktura obiektów powinna być zaprojektowana nie tylko z myślą o możliwym rozszerzeniu, ale z założeniem, że kierunek tego kolejnego rozszerzenia mógłby nie przyjść Ci nawet do głowy na etapie projektowania.

I tak, zgodność ze wszystkimi tymi wymaganiami w jednym systemie jest możliwa (oczywiście w określonych przypadkach i z pewnymi zastrzeżeniami).

Poniżej omówię dwie najbardziej popularne metodologie elastycznego projektowania dla hurtowni danych — Model Anchor i Data Vault. W nawiasach pozostają takie wspaniałe techniki, jak na przykład EAV, 6NF (w czystej postaci) i wszystko, co dotyczy rozwiązań NoSQL — nie dlatego, że są one gorsze, ani nawet dlatego, że w tym przypadku artykuł mógłby zyskać objętość przeciętnej pracy dyplomowej. Po prostu wszystko to odnosi się do rozwiązań nieco innej klasy — albo do technik, które można zastosować w specyficznych przypadkach, niezależnie od ogólnej architektury projektu (jak EAV), albo do całkowicie innych paradygmatów przechowywania informacji (jak na przykład bazy danych grafowych i inne warianty NoSQL).

Problemy klasycznego podejścia i ich rozwiązania w elastycznych metodach

Przez klasyczne podejście rozumiem dobrą, starą gwiazdę (niezależnie od konkretnej implementacji dolnych warstw, niech mnie wybaczą zwolennicy Kimbola, Inmona i CDM).

1. Sztywna kardynalność relacji

W podstawie takiego modelu leży wyraźne rozdzielenie danych na wymiary (Dimension) i fakty (Fact). I to, kurczę, ma sens — bowiem analiza danych w przytłaczającej większości przypadków sprowadza się do analizy określonych wskaźników liczbowych (faktów) w określonych przekrojach (wymiarach).

Przy tym relacje między obiektami są zakładane w postaci powiązań między tabelami przez klucz obcy. Wygląda to całkiem naturalnie, ale od razu prowadzi do pierwszego ograniczenia elastyczności — sztywnego określenia kardynalności relacji.

Oznacza to, że na etapie projektowania tabel musisz dokładnie określić, czy każda para powiązanych obiektów może mieć relację wiele-do-wielu, czy tylko 1-do-wielu, i "w którą stronę". Od tego bezpośrednio zależy, w której z tabel będzie klucz podstawowy, a w której — zewnętrzny. Zmiana tej relacji przy uzyskiwaniu nowych wymagań z dużym prawdopodobieństwem doprowadzi do przeróbki bazy.

Na przykład, projektując obiekt "paragon", opierając się na przysięgłych zapewnieniach działu sprzedaży, założyłeś możliwość działania jednej promocji na kilka pozycji paragonu (ale nie odwrotnie):

A po pewnym czasie koledzy wprowadzili nową strategię marketingową, w której na tę samą pozycję mogą działać wiele promocji jednocześnie. I teraz musisz dostosować tabele, wydzielając relację w osobny obiekt.

(Wszystkie obiekty pochodne, w których odbywa się join check na promocji, teraz również wymagają poprawek).

Powiązania w Data Vault i Modelu Ankorowym

Uniknięcie takiej sytuacji okazało się dość proste: nie należy wierzyć działowi sprzedaży, wystarczy wszystkie powiązania przechowywać początkowo w oddzielnych tabelach i przetwarzać je jako wiele do wielu.

Takie podejście zostało zaproponowane przez Dana Linstedta jako część paradygmatu Data Vault i zostało całkowicie poparte przez Larsa Rönnbäcka do Modelu Ankorowego.

W efekcie otrzymujemy pierwszą charakterystyczną cechę elastycznych metodologii:

Powiązania między obiektami nie są przechowywane w atrybutach encji rodzicielskich, ale stanowią osobny typ obiektów.

W Data Vault takie tabele łączące nazywane są Link, a w Modelu Ankorowym — Tie. Na pierwszy rzut oka są one bardzo podobne, chociaż różnice w nazwach nie wyczerpują tej kwestii (o czym będzie mowa poniżej). W obu architekturach tabele łączące mogą łączyć dowolną liczbę encji (niekoniecznie 2).

Ta na pierwszy rzut oka nadmiarowość zapewnia znaczną elastyczność podczas poprawek. Taka struktura staje się tolerancyjna nie tylko na zmiany kardynalności istniejących powiązań, ale także na dodawanie nowych — jeśli teraz pozycja paragonu zyska dodatkowe odniesienie do sprzedawcy, powstanie takiego połączenia będzie po prostu nadbudową nad istniejącymi tabelami bez wpływu na jakiekolwiek istniejące obiekty i procesy.

2. Duplikacja danych

Drugi problem rozwiązywany przez elastyczne architektury jest mniej oczywisty i dotyczy przede wszystkim miar typu SCD2 (powoli zmieniające się miary drugiego typu), choć nie tylko ich.

W klasycznym składowisku, miara zazwyczaj przedstawia tabelę, która zawiera klucz zastępczy (jako PK) oraz zestaw kluczy biznesowych i atrybutów w oddzielnych kolumnach.

Jeśli miara obsługuje wersjonowanie, do standardowego zestawu pól dodawane są granice czasowe obowiązywania wersji, a w źródle pojawia się kilka wersji w składowisku (po jednej na każdą zmianę atrybutów wersji).

Jeśli miara zawiera przynajmniej jeden często zmieniający się atrybut wersji, liczba wersji tej miary będzie ogromna (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ąć w postępie geometrycznym w zależności od ich liczby. Taka miara może zajmować znaczną ilość miejsca na dysku, chociaż większość przechowywanych w niej danych to po prostu duplikaty wartości niezmiennych atrybutów z innych wierszy.

W tym kontekście bardzo często stosuje się również denormalizację — część atrybutów jest celowo przechowywana w postaci wartości, a nie odniesienia do słownika lub innej miary. Takie podejście przyspiesza dostęp do danych, zmniejszając liczbę joinów przy odwoływaniu się do miary.

Zwykle prowadzi to do tego, że ta sama informacja jest przechowywana jednocześnie w kilku miejscach. Na przykład, informacje o regionie zamieszkania i przynależności do kategorii klienta mogą być jednocześnie przechowywane w miarach „Klient” oraz w faktach „Zakup”, „Dostawa” i „Zgłoszenia do call center”, a także w tabeli powiązań „Klient — Menedżer klienta”.

Ogólnie opisane powyżej odnosi się również do zwykłych (nie wersjonowanych) miar, ale w przypadku wersjowanych mogą mieć inny zasięg: wprowadzenie nowej wersji obiektu (szczególnie z datą wsteczną) prowadzi nie tylko do aktualizacji wszystkich powiązanych tabel, ale do kaskadowego tworzenia nowych wersji powiązanych obiektów — kiedy Tabela 1 jest używana do budowania Tabeli 2, a Tabela 2 — do budowania Tabeli 3 itd. Nawet jeśli żaden atrybut Tabeli 1 nie bierze udziału w budowaniu Tabeli 3 (a biorą udział inne atrybuty Tabeli 2, uzyskane z innych źródeł), wersjonowa aktualizacja tej konstrukcji co najmniej skutkuje dodatkowymi kosztami, a maksymalnie — zbędnymi wersjami w Tabeli 3, która tu w ogóle „nie ma nic do rzeczy” i dalej w łańcuchu.

3. Nieliniowa złożoność rozwoju

W tym przypadku każda nowa witryna, budowana na podstawie innej, zwiększa liczbę miejsc, w których dane mogą „rozjechać się” przy wprowadzaniu zmian w ETL. Prowadzi to z kolei do wzrostu złożoności (i czasu) każdego kolejnego rozwoju.

Jeśli powyższe dotyczy systemów z rzadko aktualizowanymi procesami ETL, można żyć w tej paradygmacie — wystarczy pilnować, aby nowe modyfikacje były prawidłowo wprowadzane do wszystkich powiązanych obiektów. Jeśli jednak modyfikacje zachodzą często, prawdopodobieństwo przypadkowego 'przeoczenia' kilku powiązań znacząco wzrasta.

Jeśli dodatkowo weźmiemy pod uwagę, że 'wersjonowany' ETL jest znacznie bardziej skomplikowany niż 'niewersjonowany', unikanie błędów podczas częstych modyfikacji całego tego systemu staje się dość trudne.

Przechowywanie obiektów i atrybutów w Data Vault i modelu Anchor

Podejście proponowane przez autorów elastycznych architektur można sformułować w ten sposób:

Należy oddzielić to, co się zmienia, od tego, co pozostaje niezmienne. To znaczy przechowywać klucze oddzielnie od atrybutów.

Przy tym nie należy mylić niewersjonowego atrybutu z niezmiennym: pierwszy nie przechowuje historii swoich zmian, ale może się zmieniać (na przykład przy poprawie błędu wprowadzania lub uzyskaniu nowych danych), drugi — nigdy się nie zmienia.

Opinie na temat tego, co dokładnie można uznać za niezmienne w Data Vault i modelu Ankorowym, są podzielone.

Z punktu widzenia architektury Data Vault, niezmienne można uznać za cały zbiór kluczy — naturalne (NIP organizacji, kod towaru w systemie źródłowym itp.) oraz surrogatowe. Przy tym pozostałe atrybuty można podzielić na grupy według źródła i/lub częstotliwości zmian i dla każdej grupy prowadzić osobną tabelę z niezależnym zestawem wersji.

W paradygmacie modelu Anchor niezmiennym uważa się tylko surrogatowy klucz encję. Wszystko inne (w tym naturalne klucze) — to tylko szczególny przypadek jego atrybutów. Przy tym wszystkie atrybuty domyślnie są niezależne od siebie, dlatego dla każdego atrybutu powinna być stworzona oddzielna tabela.

W Data Vault tabele, które zawierają klucze encji, nazywane są Hubami (Hub). Huby zawsze zawierają stały zestaw pól:

Naturalne klucze encji
Surrogatowy klucz
Odnośnik do źródła
Czas dodania rekordu

Rekordy w Hubach nigdy się nie zmieniają i nie mają wersji.. Zewnętrzne huby są bardzo podobne do tabel typu ID-map, stosowanych w niektórych systemach do generowania surrogatów, jednak w przypadku surrogatów w Data Vault zaleca się stosowanie nie całkowitoliczbowego sekwencera, a hasha z zestawu kluczy biznesowych. Takie podejście upraszcza ładowanie relacji i atrybutów z źródeł (nie trzeba łączyć z hubem w celu uzyskania surrogatu, wystarczy po prostu obliczyć hash z klucza naturalnego), ale może powodować inne problemy (związane na przykład z kolizjami, wielkością liter i znakami niewydrukowanymi w kluczach tekstowych itp.), dlatego nie jest powszechnie akceptowane.

Wszystkie pozostałe atrybuty encji są przechowywane w specjalnych tabelach, zwanych Satelitami (Satellit). Jeden hub może mieć kilka satelitów, przechowujących różne zestawy atrybutów.

Rozdzielanie atrybutów pomiędzy satelity odbywa się na zasadzie wspólnej zmiany — w jednym satelicie mogą być przechowywane atrybuty niewersjonowane (na przykład, data urodzenia i SNILS dla fizycznej osoby), w innym — rzadko zmieniające się wersjonowane (na przykład, 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ę na poziomie poszczególnych satelitów, a nie encji jako całości, dlatego rozdzielanie atrybutów warto przeprowadzać tak, aby przecięcie wersji w jednym satelicie było minimalne (co zmniejsza łączną liczbę przechowywanych wersji).

Dodatkowo, w celu optymalizacji procesu ładowania danych, do osobnych satelitów często przenoszone są atrybuty pozyskiwane z różnych źródeł.

Satelity łączą się z hubem poprzez klucz obcy (co odpowiada kardynalności 1-do-wielu). Oznacza to, że wiele wartości atrybutów (na przykład kilka numerów telefonów kontaktowych dla jednego klienta) jest wspierane przez tę architekturę „domyślnie”.

W Model zakotwiczony (Anchor Model) tabele, które przechowują klucze, nazywane są Kotwicami (Anchor). I przechowują one:

Tylko surrogatowe klucze
Odnośnik do źródła
Czas dodania rekordu

Naturalne klucze z punktu widzenia Modelu Zakotwiczonego są uważane za zwykłe atrybuty. Taka opcja może wydawać się bardziej skomplikowana do zrozumienia, ale daje znacznie większe możliwości identyfikacji obiektu.

Na przykład, gdy dane o tym samym bycie mogą pochodzić z różnych systemów, w których używane są różne klucze naturalne. W Data Vault może to prowadzić do dość złożonych konstrukcji z kilku hubów (po jednym na źródło + łącząca wersja mistrzowska), w modelu Y Anchor klucz naturalny każdego źródła trafia do swojego atrybutu i może być używany przy załadunku niezależnie od wszystkich pozostałych.

Jednak ukryty jest tutaj jeden podstępny moment: jeśli w jednej encji łączone są atrybuty z różnych systemów, najprawdopodobniej istnieją pewne zasady „łączenia”, według których system powinien rozumieć, że rekordy z różnych źródeł odpowiadają jednemu egzemplarzowi encji.

W Data Vault te zasady najprawdopodobniej będą określać tworzenie „surrogatnego hubu” encji głównej i nie będą miały wpływu na Huby, które przechowują naturalne klucze źródeł i ich pierwotne atrybuty. Jeśli w pewnym momencie zasady łączenia się zmienią (lub nadejdzie aktualizacja atrybutów, według których jest to przeprowadzane), wystarczy przekształcić surrogatne huby.

W Model Y Anchor taka encja najprawdopodobniej będzie przechowywana w jednym jedynym kotwicy. Oznacza to, że wszystkie atrybuty, niezależnie od tego, z jakiego źródła pochodzą, będą przypisane do jednego i tego samego surrogatu. Rozdzielenie fałszywie połączonych rekordów i ogólne śledzenie aktualności łączenia w takim systemie może okazać się znacznie trudniejsze, zwłaszcza gdy zasady są dostatecznie skomplikowane i często się zmieniają, a ten sam atrybut może pochodzić z różnych źródeł (choć jest to z pewnością możliwe, ponieważ każda wersja atrybutu zachowuje odnośnik do swojego źródła).

W każdym razie, jeśli w Twoim systemie przewiduje się realizację funkcji deduplikacji, łączenia rekordów i innych elementów MDM, warto szczególnie uważnie zapoznać się z aspektami przechowywania naturalnych kluczy w elastycznych metodologiach. Możliwe, że bardziej złożona konstrukcja Data Vault nagle okaże się bardziej bezpieczna z punktu widzenia błędów łączenia.

Model Y Anchor zakłada także dodatkowy typ obiektu, zwany Węzłem (Knot) w zasadzie jest to specjalny degeneracyjny rodzaj kotwicy, który może zawierać tylko jeden atrybut. Węzły mają być używane do przechowywania płaskich słowników (np. płeć, sytuacja rodzinna, kategoria obsługi klienta itp.). W przeciwieństwie do Kotwicy, Węzeł nie ma tabel związanych z atrybutami, a jego jedyny atrybut (nazwa) zawsze przechowywany jest w jednej tabeli z kluczem. Węzły łączą się z Kotwicami za pomocą tabel powiązań (Tie) w taki sam sposób, w jaki kotwice łączą się ze sobą.

Nie ma jednoznacznej opinii na temat użycia Węzłów. Na przykład, Nikołaj Gołow, który aktywnie promuje zastosowanie modelu Kotwicy w Rosji, uważa (nie bez podstaw), że dla żadnego słownika nie można jednoznacznie stwierdzić, że zawsze będzie statyczny i jednowarstwowy, dlatego dla wszystkich obiektów lepiej od razu użyć pełnoprawnej Kotwicy.

Jeszcze jedna istotna różnica między Data Vault a modelem Kotwicy polega na obecności atrybutów przy powiązaniach:

W Data Vault Powiązania są takimi samymi pełnoprawnymi obiektami jak Hubs i mogą mieć własne atrybuty. W Model Y Anchor Powiązania używane są tylko do łączenia Kotwic i nie mogą mieć własnych atrybutów. Ta różnica prowadzi do znacznie różnych podejść do modelowania faktów, o czym będzie mowa dalej.

Przechowywanie faktów

Do tej pory mówiliśmy głównie o modelowaniu wymiarów. Sprawy z faktami są nieco mniej jednoznaczne.

W Data Vault Typowym obiektem do przechowywania faktów jest Powiązanie (Link), w Satellitach których gromadzone są wskaźniki rzeczywiste.

Takie podejście wydaje się intuicyjnie zrozumiałe. Daje prosty dostęp do analizowanych wskaźników i w ogóle przypomina tradycyjną tabelę faktów (tylko, że wskaźniki przechowywane są nie w samej tabeli, a w 'sąsiedniej'). Ale są też ukryte pułapki: jedno z typowych rozszerzeń modelu — rozszerzenie klucza faktu — wymaga dodania nowego klucza obcego w Link. A to z kolei 'łama' modularność i potencjalnie wywołuje potrzebę modyfikacji innych obiektów.

W Model Y Anchor Powiązanie nie może mieć własnych atrybutów, więc takie podejście się nie sprawdzi — absolutnie wszystkie atrybuty i wskaźniki muszą mieć powiązanie z jednym konkretnym kotwicą. Wniosek z tego prosty — dla każdego faktu także potrzebna jest własna kotwica.. To, co przyjmujemy za pewne fakty, może wydawać się naturalne — na przykład fakt zakupu w piękny sposób odnosi się do obiektu „zamówienie” lub „paragon”, odwiedziny na stronie — do sesji itd. Ale są także fakty, dla których znalezienie naturalnego „obiektu nośnika” nie jest takie proste — na przykład zapasy towarów w magazynach na początku każdego dnia.

W związku z tym nie ma problemów z modułowością podczas rozszerzania klucza faktu w modelu Ancor (wystarczy dodać nowe Powiązanie do odpowiedniego Ancor), ale projektowanie modelu do wyświetlania faktów jest mniej jednoznaczne, mogą pojawiać się „sztuczne” Ancor, które nieoczywiście odzwierciedlają obiektowy model biznesu.

Jak osiągnąć elastyczność

Uzyskana konstrukcja w obu przypadkach zawiera znacząco więcej tabel, niż tradycyjne miary. Ale może zajmować znacząco mniej miejsca na dysku przy tej samej liczbie atrybutów wersyjnych, co tradycyjne miary. Nie ma tu żadnej magii — wszystko sprowadza się do normalizacji. Rozdzielając atrybuty na Satelity (w Data Vault) lub oddzielne tabele (model Ancor), zmniejszamy (lub całkowicie eliminujemy) powielanie wartości niektórych atrybutów przy zmianie innych.

Dla Data Vault zysk będzie zależał od rozdziału atrybutów na Satelity, a dla Model Y Anchor — praktycznie proporcjonalnie do średniej liczby wersji obiektu miary.

Jednak zysk z zajmowanej przestrzeni — to ważna, ale nie główna zaleta oddzielnego przechowywania atrybutów. Razem z oddzielnym przechowywaniem powiązań, takie podejście czyni magazyn modularną konstrukcją. Oznacza to, że dodanie zarówno oddzielnych atrybutów, jak i zupełnie nowych dziedzin w takim modelu wygląda jak nadbudowa nad istniejący zbiór obiektów bez ich zmiany. I to właśnie sprawia, że opisane metodologie są elastyczne.

To także przypomina przejście od produkcji jednostkowej do masowej — jeśli w tradycyjnym podejściu każda tabela modelu jest unikalna i wymaga indywidualnej uwagi, to w elastycznych metodologiach — są to już zestawy typowych „części”. Z jednej strony, tabel jest więcej, procesy ładowania i pobierania danych powinny wyglądać na bardziej skomplikowane. Z drugiej strony — stają się typowe. A to oznacza, że mogą być są zautomatyzowane i zarządzane danymi meta. Pytanie “jak będziemy układać?”, na które odpowiedź mogła zajmować znaczną część prac projektowych związanych z modyfikacjami, teraz po prostu nie istnieje (jak również pytanie o wpływ zmiany modelu na działające procesy).

To nie znaczy, że analitycy w takim systemie są całkowicie niepotrzebni — ktoś wciąż musi opracować zestaw obiektów z atrybutami i dowiedzieć się, skąd i jak to wszystko ładować. Jednak zakres prac, a także prawdopodobieństwo i koszt błędu są znacząco zmniejszone. Zarówno na etapie analizy, jak i przy tworzeniu ETL, które w znacznym stopniu może ograniczyć się do edytowania metadanych.

Ciemna strona

Wszystko powyższe sprawia, że oba podejścia są naprawdę elastyczne, technologiczne i nadające się do iteracyjnej modyfikacji. Oczywiście jest też ‘wielka łyżka dziegciu’, o której, sądzę, już się domyślasz.

Dekompozycja danych, leżąca u podstaw modułowości elastycznych architektur, prowadzi do zwiększenia liczby tabel i, odpowiednio, kosztów przy dołączaniu podczas zapytań. Aby po prostu uzyskać wszystkie atrybuty miary, w klasycznym magazynie wystarczy jeden select, a elastyczna architektura wymaga całego szeregu dołączeń. Przy tym, jeśli dla raportów wszystkie te dołączenia można napisać z wyprzedzeniem, to analitycy, przyzwyczajeni do pisania SQL ręcznie, będą cierpieć podwójnie.

Istnieje kilka faktów, które ułatwiają taką sytuację:

Przy pracy z dużymi miarami rzadko korzysta się jednocześnie ze wszystkich jej atrybutów. Oznacza to, że może być mniej dołączeń, niż wydaje się na pierwszy rzut oka na model. W Data Vault można również uwzględnić zakładaną częstotliwość współdzielenia przy rozdzielaniu atrybutów po satelitach. Przy tym same Haby lub Kotwice są potrzebne głównie do generowania i mapowania substytutów na etapie ładowania i rzadko używane są w zapytaniach (szczególnie dotyczy to Kotwic).

Wszystkie dołączenia — po kluczu. Ponadto bardziej "skompresowany" sposób przechowywania danych zmniejsza koszty skanowania tabel tam, gdzie jest to konieczne (np. przy filtrowaniu według wartości atrybutu). Może to prowadzić do sytuacji, że zapytanie z znormalizowanej bazy z wieloma złączeniami będzie nawet szybsze niż skanowanie jednego ciężkiego wymiaru z dużą liczbą wersji w wierszu.

Na przykład, w tego tym artykule znajduje się szczegółowy test porównawczy wydajności modelu Wołków z próbką z jednej tabeli.

Wiele zależy od silnika. Wiele nowoczesnych platform ma wewnętrzne mechanizmy optymalizacji złączeń. Na przykład, MS SQL i Oracle potrafią "ominię złącza" do tabel, jeśli ich dane nie są używane nigdzie indziej, oprócz innych złączeń i nie wpływają na ostateczny wynik (eliminacja tabeli/złączenia), a MPP Vertica według doświadczeń kolegów z Avito, okazała się doskonałym silnikiem dla modelu Wołków z uwzględnieniem pewnej ręcznej optymalizacji planu zapytania. Z drugiej strony, przechowywanie modelu Wołków, na przykład, w Click House, mającym ograniczone wsparcie dla złączeń, na chwilę obecną nie wygląda na najlepszy pomysł.

Ponadto, dla obu architektur istnieją specjalne techniki, które ułatwiają dostęp do danych (zarówno z punktu widzenia wydajności zapytań, jak i dla końcowych użytkowników). Na przykład, tabele Point-In-Time w Data Vault lub specjalne funkcje tabelowe w modelu Wołków.

Podsumowując

Główna istota rozważanych elastycznych architektur polega na modułowości ich "budowy".

Właśnie ta cecha pozwala:

Po pewnej wstępnej przygotowaniu związanym z wdrożeniem metadanych i pisaniem podstawowych algorytmów ETL, szybko dostarczyć klientowi pierwszy rezultat w postaci paru raportów, zawierających dane zaledwie kilku źródeł obiektów. Kompleksowe przemyślenie (nawet na wysokim poziomie) całej modelu obiektowego nie jest w tym przypadku konieczne.
Model danych może zacząć działać (i przynosić korzyści) zaledwie z 2-3 obiektami, a następnie stopniowo rosnąć (w odniesieniu do modelu Wołków, Nikolaj zastosował piękne porównanie do grzybni).
Większość poprawek, w tym rozszerzenie tematyki oraz dodawanie nowych źródeł nie wpływa na istniejącą funkcjonalność i nie stwarza ryzyka uszkodzenia już działających elementów..
Dzięki dekompozycji na standardowe elementy, procesy ETL w takich systemach wyglądają jednolicie, ich pisanie poddaje się algorytmizacji i w końcu, automatyzacji.

Ceną tej elastyczności jest wydajność. To nie znaczy, że osiągnięcie akceptowalnej wydajności w takich modelach jest niemożliwe. Często może być potrzebne więcej wysiłku i uwagi na szczegóły, aby osiągnąć wymagane metryki.