Rozważania dotyczące hurtowni danych: Kiedy i dlaczego?

1. Głównym celem DW jest przyspieszenie (uproszczenie) raportowania i analizy. Umożliwia krojenie i krojenie danych w dowolny sposób, jaki Użytkownik biznesowy może sobie wyobrazić.

2. Na pierwszy krok DW, można po prostu zaimplementować schemat Kimball star i uruchomić zapytania SQL przeciwko nim. Jeśli okaże się to nadal zbyt wolne, zacznij myśleć o wstępnie obliczonych agregacjach (kostkach).

3. Krojenie i krojenie informacji na DW jest o wiele prostsze, niż na znormalizowany DB. Replikowany serwer raportów poprawi wydajność, ale nie uprości krojenia i kostkowania. Należy również pamiętać, że DW należy do użytkowników biznesowych, więc to do nich należy wymyślić różne pomysły na plasterki/kości w dowolnym momencie-ludzie powinni po prostu zapewnić środowisko, w którym coś takiego jest możliwe.

4. Jeśli od czasu do czasu uruchamiasz kilka raportów w swoim systemie operacyjnym i jesteś zadowolony z wydajności, nie ma potrzeby DW.

5. Całe moje doświadczenie dotyczy systemów, w których użytkownicy biznesowi bez końca narzekają na powolne raporty i niezdolność do pisania "skomplikowanych zapytań", podczas gdy ludzie produkcyjni narzekają, że baza danych grzęźnie z powodu raportowania. We wszystkich przypadkach wystarczy prosta Gwiazda Kimball i serwer raportów z pamięcią podręczną i migawkami.

1. Należy rozważyć zbudowanie hurtowni danych, gdy dwa z następujących kryteriów pasują do siebie:

   • ogromna ilość danych
   • wiele złożonych selekcji (prawdopodobnie w porównaniu z kilkoma wstawkami, aktualizacjami i usunięciami), których wykonanie zajmuje zbyt dużo czasu (i są skomplikowane do napisania)
   • Dane z różnych systemów muszą zostać połączone

2. To naprawdę pytanie, co uważasz za hurtownię danych. W wielu przypadkach można przejść stopniowo od Systemy OLTPs z niektórymi raportami do hurtowni danych, o ile można trzymać się relacyjnego systemu zarządzania bazami danych. Najpierw można zbudować pierwszą tabelę faktów i nadal używać tabel znormalizowanych dla wymiaru. Następnie dodajemy do gry więcej faktów, więcej tabel faktów lub dedykowanych tabel wymiarów. Najpierw w tej samej bazie danych (lub jednej z baz danych zaangażowanych systemów), ewentualnie przeniesienie do osobnej bazy danych później.

3. Pełna hurtownia danych (osobna baza danych, star schema) oferuje najlepsze opcje strojenia instrukcji select, poza przechodzeniem do specjalistycznego systemu. Jest również całkowicie oddzielony od systemu (- ów) OLTP. Pomyśl projekt schematu, ale także zasoby takie jak procesor, I / o i pamięć i organizacyjne, takie jak planowanie nowych wydań. Oczywiście jest to dużo pracy, której prawdopodobnie nie potrzebujesz.

4. To w odpowiedziach powyżej: to, że masz garść złożonych zapytań, nie oznacza, że powinieneś zbudować DWH, to samo dotyczy inne kryteria, jeśli pochodzą one w izolacji.

5. Niewiele tu mogę zaoferować, ale Rada: go agile. Wymagania dotyczące DWH zależą bardzo od możliwości, jakie widzą użytkownicy. Tam wymagania mogą ulec zmianie. Automatyzacja testów z bazami danych to ból, ale wygłupianie się w systemie produkcyjnym bez odpowiednich testów jest gorsze.

W jakim momencie warto rozważyć budowę hurtowni danych? Innymi słowy, na jakie wskaźniki, metryki lub inne kryteria powinienem zwrócić uwagę, które mogą wskazywać, że standardowe środowisko transakcyjne nie jest już wystarczające?

Polecam hurtownię danych, gdy zauważyłeś, że wykonywanie raportów i analiz w magazynie danych transakcyjnych jest szkodliwe dla obu.

Jakie są alternatywy dla pełna hurtownia danych? Denormalizacja w bazie danych transakcyjnych i standardowym replikowanym "serwerze raportów" to dwa, które przychodzą na myśl; czy są jakieś inne, które powinienem zbadać przed przystąpieniem do DW?

Dlaczego hurtownia danych lepsze niż wspomniane alternatywy? Jeśli odpowiedź brzmi: "to zależy", to od czego to zależy?

Kiedy nie powinienem budować hurtowni danych? Jestem sceptyczny wobec wszystkiego, co uznane jest za "najlepszą praktykę", niezależnie od kontekstu. Na pewno muszą być jakieś scenariusze, w których DW jest złym wyborem-czym one są?

Powiedziałbym, że jeśli nie trzeba zachować długą historię, nie robią intensywnej analizy danych, a Twój potrzeby raportowania są ograniczone do doraźnego zapytania od czasu do czasu, wtedy być może hurtownia danych nie jest konieczna.

Czy są jakieś praktyczne przykłady systemów, które zostały ulepszone poprzez wprowadzenie hurtowni danych? Coś, co wyjaśniałoby mi, od końca do końca, do jakich decyzji lub analiz potrzebowali magazynu, w jaki sposób zdecydowali, co w nim umieścić i w jaki sposób magazyn dopasował się do większego środowiska? Nie chcę wymyślonego "let' s zrób kostkę z bazy danych AdventureWorks " - realizacja jest dla mnie nieistotna, interesują mnie specyfikacje i projekty oraz ogólny proces myślenia, który był zaangażowany.

Moi pracodawcy korzystali z hurtowni danych przez wiele lat przed moim przybyciem, więc nie mogę mówić, jak było przed moim przybyciem.

Z mojego doświadczenia wynika, że pierwszym sygnałem do rozpoczęcia myślenia o hurtowni danych jest to, gdy masz (lub rozwijasz) bazę danych transakcyjnych, a użytkownicy zaczynają dodawać wiele wymagań dotyczących raportowania i historii danych. Czyli prawie zawsze. Zawsze łatwiej jest mieć oddzielną hurtownię danych lub bazę danych raportowania niż próbować zaprojektować system transakcyjny, który obsługuje potrzeby raportowania, które zawsze mają użytkownicy końcowi. Przechowywanie historii (dla podmiotów gospodarczych) w transakcjach system zwiększa złożoność i rozbudowuje bazę danych, która powinna być jak najbardziej responsywna.

Z drugiej strony, byłem w dużych firmach, w których wiele grup tworzyło hurtownie danych, ponieważ interesujące dane były rozłożone na wiele systemów i dlatego były trudne do wyszukania. Problem polegał na tym, że każda grupa stworzyła własną hurtownię danych, ponieważ wszystkie istniejące magazyny w firmie nie miały odpowiedniego podzbioru informacji lub miały model danych, który został uznany za nieoptymalny albo źle. To pogorszyło sytuację, tworząc jeszcze bardziej rozbieżne systemy danych, które były trudne do porównania.

DW można rozważyć, jeśli, jeden jest za pomocą "systemu transakcyjnego" od dłuższego czasu. Później zdają sobie sprawę, że muszą wykonać eksplorację danych, aby określić różne wzorce danych w firmie. I wreszcie, za pomocą ustalonych wzorców danych, chce się pomóc Najwyższemu zarządowi w podejmowaniu dalszych decyzji z korzyścią dla firmy.

Należy podjąć następujące kroki w celu zbudowania magazynu danych:

1. Platforma I baza danych ETL trzeba zdecydować się na bazę danych.
2. Narzędzie do raportowania, takie jak SSRS, Tableau itp. musi być wybrany do wizualizacji.
3. można wybrać analityczny język danych, taki jak R, do dalszego wykorzystania.
4. wreszcie, wszystko to pomoże w rozwoju domu danych ware i narzędzia raportowania. 

" myślę, że dlaczego niektóre projekty zawodzą?"

Istnieje pięć podstawowych powodów:

Brak współpracy pomiędzy działem IT a użytkownikami biznesowymi;]}
• nieprawidłowa Architektura hurtowni danych;
• za mało doświadczonych ludzi;
• niewłaściwe planowanie, takie jak niestosowanie sprawdzonej metodologii i planu w celu zapewnienia, że żadne szczegóły nie zostaną pominięte;
I w zależności od najnowocześniejszej technologii.