Korzyści z wykorzystania bazy danych podczas projektowania hurtowni danych

ETL = Extract, Transform and Load. Staging bazy danych pomoc Z bit Transform. Osobiście zawsze dołączam staging DB i ETL step.

Baza Danych Staging pomaga uzyskać dane źródłowe w strukturach równoważnych z miejscami docelowymi hurtowni danych FACT I DIMENSION. Oddziela również procesy magazynowe i magazynowe ETL od danych źródłowych.

Jeśli tabele docelowe hurtowni danych w zasadzie odwzorowują tabele dB produkcji z tylko niektórymi dodatkowe pola wymiaru wtedy mogłoby ujść na sucho ignorując bazę danych Staging. Pozwoli to zaoszczędzić trochę czasu na rozwój. Nie polecam tego jak ty:

1. zakończy się powiązaniem rozwiązania hurtowni danych bezpośrednio z Twoim baza danych źródłowych
2. najprawdopodobniej zakończy się bardzo skomplikowanym krokiem ETL
3. może skończyć się z warunkami wyścigu/zapisami osieroconymi z powodu zmiany w źródłowej bazie danych podczas procesu ETL
4. Hurtownia Danych ludzie mogą wydawać na Ciebie dźwięki typu "hrumph"

Najprawdopodobniej będziesz wykonywać jakąś manipulację danymi (konwertowanie dat na klucze DATE_DIM, agregowanie wartości) w takim przypadku przechowalnia danych pomoże Ci oddzielić logikę transformacji i obliczenia od operacji hurtowni danych (wymiarowanie danych).

Możesz również natknąć się na tego rodzaju wzór:

[PROD DB] -(ETL)->  [RAW DB] -(ETL)-> [STAGING DB] -(ETL)-> [DW DB]  -(ETL)-> [DM DB]

Które, jeśli względy wydajności są ważne, możesz chcieć przyjrzeć się. W Twoim przypadku RAW_DB może być dokładną kopią 1: 1 Twojej produkcyjnej bazy danych, a krok ETL, który ją tworzy, może być odtworzeniem DB z najnowszej nocnej kopii zapasowej. (Tradycyjnie RAW_DB był używany do pobierania danych z różnych zewnętrznych źródeł z każdym polem jako czystym tekstem, pola te były następnie konwertowane na ich oczekiwany typ danych z wyjątkami obsługiwanymi jako napotkane. To nie jest tak duży problem, gdy masz jedno źródło i jego ładne mocno wpisane znormalizowane baza danych)

Z tego pliku RAW_DB następny proces ETL będzie obcinał i wypełniał staging tak, że staging DB zawiera wszystkie nowe / zaktualizowane rekordy, które trafiają do magazynu.

Kolejną dodatkową zaletą tych wszystkich kroków jest to, że naprawdę pomaga w debugowaniu dziwnych danych, ponieważ dla każdego uruchomienia można zobaczyć wartości rekordów w każdej z baz danych różnic i określić, który proces ETL wprowadza smutek.

Istnieje kilka potencjalnych zalet korzystania z pośredniczącej bazy danych, które mogą lub nie mają zastosowania do twojej sytuacji. Nie ma idealnego, uniwersalnego rozwiązania. Niektóre z potencjalnych zalet obejmują:

• jeśli jest to właściwe, możesz zrobić migawkę produkcyjnej bazy danych (możesz mieć już codzienną kopię zapasową lub migawkę hot-site), a następnie wykonać ETL z przywróconej kopii zapasowej lub migawki. Może to zaoszczędzić obciążenie produkcji baza danych.
• możesz potrzebować skomplikowanego przetwarzania dla swojego ETL, który wymaga wielu tabel pośrednich, które nie mają zastosowania z wyjątkiem procesu ETL. Możesz nie chcieć zaśmiecać swojej hurtowni danych tymi tabelami pośrednimi.
• twoje nieprzetworzone dane mogą nie być dostępne na raz i musisz je gdzieś zgromadzić przed rozpoczęciem procesu ETL, aby zbudować hurtownię danych.
• Twoja hurtownia danych może mieć wymagania dotyczące okien produkcyjnych, które nie mogą być spełnione przez twój ETL i tak musisz ustawić swoje "wyjście" (tj. nowe rekordy dla hurtowni danych) zamiast lub jako uzupełnienie produkcyjnej bazy danych.
• system produkcyjny może znajdować się w wysoce bezpiecznym środowisku i z jakiegokolwiek powodu mogła zostać podjęta decyzja, aby nie umożliwić procesowi ETL pełnego dostępu do surowych danych produkcyjnych. Grupa kontrolująca bazę danych produkcji może chcieć wyodrębnić tylko niezbędne dane do bazy danych staging, aby proces ETL mógł zobaczyć tylko to, czego potrzebuje. Widziałem to, gdy system produkcyjny i proces ETL są zarządzane przez różnych dostawców zewnętrznych.
• możliwe, że twój proces ETL tworzy duże tabele pośrednie. Czasami zarządzanie przestrzenią jest łatwiejsze, jeśli zaczynasz od pustej bazy danych modelu dla obszaru postojowego ETL, a następnie "wyrzucasz ją" każdego dnia, zamiast próbować odzyskać przestrzeń w bardziej chirurgiczny sposób, jak można to zrobić w przypadku bazy danych produkcyjnej lub raportowej.

Są też możliwe wady, co może, ale nie musi mieć dla ciebie znaczenia. Głównym z nich jest konieczność posiadania innego serwera bazy danych. Wiele zalet może być bez znaczenia, jeśli używasz tego samego serwera do hostowania baz danych produkcyjnych i / lub hurtowni danych.

Naprawdę miejsce postoju nie jest konieczne, jeśli możemy sobie z tym poradzić w locie. Ale możemy? Oto kilka powodów, dla których nie można uniknąć miejsca postoju: 1. Systemy źródłowe są dostępne tylko do ekstrakcji podczas określonego przedział czasowy, który jest zwykle mniejszy niż ogólne ładowanie danych czas. To dobry pomysł, aby wyodrębnić i zachować rzeczy na końcu przed stracisz połączenie z systemami źródłowymi. 2. Chcesz wyodrębnić dane na podstawie pewnych warunków, które wymagają dołączenia dwóch lub więcej różne systemy razem. Np. chcesz wyodrębnić tylko tych klientów, którzy również istnieją w innym systemie. Nie będzie można wykonać zapytania SQL łączącego dwie tabele z dwóch fizycznie różnych baz danych. 3. Różne systemy źródłowe mają różne przydzielone terminy ekstrakcji danych. 4. Częstotliwość ładowania danych w hurtowni danych nie pasuje do częstotliwości odświeżania systemów źródłowych 5. Pozyskane dane z tego samego zestawu systemów źródłowych będą wykorzystywane w wielu miejscach (Ładowanie hurtowni danych, ładowanie ODS, aplikacje innych firm itp.) 6. Proces ETL obejmuje złożone przekształcenia danych, które wymagają dodatkowej przestrzeni do tymczasowego stage danych 7. Istnieje specyficzny wymóg uzgadniania / debugowania danych, który gwarantuje wykorzystanie obszaru postojowego do walidacji danych przed, podczas lub po załadowaniu

Wyraźnie staging area daje dużą elastyczność podczas ładowania danych. Nie powinniśmy mieć zawsze oddzielnego miejsca postoju? Czy jest jakiś wpływ posiadania etapu obszar? Tak, jest ich kilka. 1. Obszar postoju zwiększa opóźnienia – czyli czas potrzebny na zmianę w systemie źródłowym, która ma wejść w życie w hurtowni danych. W wielu aplikacjach w czasie rzeczywistym / prawie w czasie rzeczywistym, miejsce postojowe raczej unika się Danych w miejscu postoju zajmuje dodatkową przestrzeń 2. Dla mnie, we wszystkich praktycznych aspektach, korzyść z posiadania miejsca postoju przewyższa jego problemy. dlatego ogólnie zaproponuję wyznaczenie konkretnego miejsca postoju w hurtowni danych projekty.