Jak podejść do misji ETL?

Niektóre ogólne wskazówki dotyczące ETL

1. Rozważ zorganizowanie go według miejsca docelowego (na przykład cały kod tworzący wymiar klienta znajduje się w tym samym module, niezależnie od źródła). Ułatwia to znajdowanie rzeczy i zwiększa łatwość utrzymania kodu.

2. Jeśli baza danych SQL2000 jest bałaganem, prawdopodobnie okaże się, że przepływy danych SSIS są niezdarnym sposobem radzenia sobie z danymi. Z reguły narzędzia ETL słabo skalują się ze złożonością; mniej więcej połowa wszystkich projektów hurtowni danych w firmach finansowych jest wykonywana przy użyciu kodu procedury przechowywanej jako jawnej decyzji architektonicznej - właśnie z tego powodu. Jeśli musisz umieścić dużą ilość instrukcji, rozważ umieszczenie wszystkich kodu w spocs.
   
   W przypadku systemu obejmującego wiele skomplikowanych operacji czyszczenia lub przekształceń podejście 100% sproc jest znacznie łatwiejsze w utrzymaniu, ponieważ jest to jedyny możliwy sposób na umieszczenie wszystkich przekształceń i logiki biznesowej w jednym miejscu. W przypadku mieszanych systemów ETL/sproc musisz szukać w wielu miejscach, aby śledzić, rozwiązywać problemy, debugować lub zmieniać całą transformację.

3. Najlepszą stroną narzędzi ETL są systemy, w których masz większą liczbę źródeł danych ze stosunkowo prostymi przekształceniami.

4. Spraw, aby kod był testowalny, dzięki czemu możesz oddzielić komponenty i izolację testową. Kod, który można wykonać tylko w środku złożonego przepływu danych w narzędziu ETL, jest znacznie trudniejszy do przetestowania.

5. Spraw, aby wyodrębnianie danych stało się niemądre dzięki logice nobusiness i skopiuj je do obszaru gromadzenia danych. Jeśli masz logikę biznesową rozłożoną na warstwy wyodrębniania i przekształcania, będziesz mieć transformacje, których nie można przetestować w izolacji, co utrudni wykrywanie błędów. Jeśli transformacja jest wykonywana z obszaru pomostowego, zmniejsz twardą zależność od systemu źródłowego, ponownie zwiększając testowalność. Jest to szczególna wygrana na architekturach opartych na spoc, ponieważ pozwala na prawie całkowicie jednorodną bazę kodu.

6. Zbuduj ogólny program do obsługi powoli zmieniających się wymiarów lub użyj jednego z półek, jeśli jest dostępny. Ułatwia to jednostkowe testowanie tej funkcjonalności. Jeśli można to przetestować jednostkowo, testowanie systemu nie musi sprawdzać wszystkich przypadków narożnych, a jedynie sprawdzać, czy przedstawione dane są poprawne. To nie jest tak skomplikowane, jak się wydaje - ostatnia, którą napisałem, to około 600 lub 700 linii kodu T-SQL. To samo dotyczy wszystkich ogólnych funkcji szorowania.

7. Jeśli to możliwe, ładuj przyrostowo.

8. Instrumentacja kodu — niech tworzy wpisy w dzienniku, prawdopodobnie rejestrując dane diagnostyczne, takie jak sumy kontrolne lub liczniki. Bez tego rozwiązywanie problemów jest prawie niemożliwe. Ponadto sprawdzanie asercji jest dobrym sposobem myślenia o obsłudze błędów (czy liczba wierszy jest równa liczbie wierszy w b, to relacja A:B tak naprawdę 1:1).

9. Użyj klawiszy syntetycznych. Korzystanie z kluczy naturalnych z systemów źródłowych wiąże system ze źródłami danych i utrudnia dodawanie dodatkowych źródeł. Klucze i relacje w systemie powinny zawsze być zgodne - bez wartości null. W przypadku błędów „niezarejestrowane” wprowadź określone wpisy „błąd” lub „niezarejestrowane” w tabeli wymiarów i dopasuj je.

10. Jeśli budujesz operacyjny magazyn danych (przedmiot wielu wojen religijnych), nie poddawaj recyklingowi kluczy ODS w schematach gwiezdnych. Za wszelką cenę połącz klucze ODS, aby skonstruować wymiary, ale dopasuj kluczem naturalnym. Pozwala to na arbitralne upuszczenie i odtworzenie ODS - prawdopodobnie zmieniając jego strukturę - bez naruszania schematów gwiezdnych. Posiadanie tej możliwości to prawdziwa wygrana w konserwacji, ponieważ w dowolnym momencie można zmienić strukturę ODS lub przeprowadzić ponowne wdrożenie ODS metodą brute-force.

Punkty 1-2 i 4-5 oznaczają, że możesz zbudować system, w którym wszystkie kodu dla dowolnego podsystemu (np. pojedynczego wymiaru lub tabeli faktów) znajduje się w jednym i tylko jednym miejscu w systemie. Ten typ architektury jest również lepszy w przypadku większej liczby źródeł danych.

Punkt 3 jest kontrapunktem do punktu 2. Zasadniczo wybór między oprzyrządowaniem SQL a ETL jest funkcją złożoności transformacji i liczby systemów źródłowych. Im prostsze dane i większa liczba źródeł danych, tym silniejsza argumentacja za podejściem opartym na narzędziach. Im bardziej złożone dane, tym silniejsza argumentacja za przejściem na architekturę opartą na procedurach składowanych. Generalnie lepiej jest używać wyłącznie lub prawie wyłącznie jednego lub drugiego, ale nie obu.

Punkt 6 ułatwia testowanie systemu. Testowanie SCD lub jakiejkolwiek funkcjonalności opartej na zmianach jest kłopotliwe, ponieważ musisz być w stanie przedstawić systemowi więcej niż jedną wersję danych źródłowych. Jeśli przeniesiesz funkcję zarządzania zmianami do kodu infrastruktury, możesz ją przetestować w izolacji za pomocą testowych zestawów danych. To zwycięstwo w testowaniu, ponieważ zmniejsza złożoność wymagań testowania systemu.

Punkt 7 to ogólna wskazówka dotycząca wydajności, której należy przestrzegać w przypadku dużych ilości danych. Zauważ, że dla niektórych części systemu może być potrzebne tylko ładowanie przyrostowe; w przypadku mniejszych tabel referencyjnych i wymiarów możesz ich nie potrzebować.

Punkt 8 dotyczy każdego bezgłowego procesu. Jeśli w nocy zacznie się kręcić, chcesz mieć szansę na walkę, aby zobaczyć, co poszło nie tak następnego dnia. Jeśli kod nie rejestruje poprawnie tego, co się dzieje, i nie wyłapuje błędów, będziesz miał o wiele trudniejszą pracę, aby go rozwiązać.

W punkcie 9 hurtownia danych żyje własnym życiem. Możesz łatwo dodawać i usuwać systemy źródłowe, gdy magazyn ma własne klucze. Klucze magazynowe są również niezbędne do wdrożenia wolno zmieniających się wymiarów.

Punkt 10 to wygrana w zakresie konserwacji i wdrożenia, ponieważ ODS można zmienić, jeśli trzeba dodać nowe systemy lub zmienić liczność rekordu. Oznacza to również, że wymiar można załadować z więcej niż jednego miejsca w ODS (pomyśl:dodanie ręcznych korekt księgowych) bez zależności od kluczy ODS.