Czy Hurtowania Danych w Chmurze ma Sens? (Na przykładzie Amazon Redshift)

Petabajtowa baza danych… tak AWS reklamuje jedną ze swoich usług, którą klasyfikuje jako tzw. hurtownię danych.

Czy aby na pewno jest to właściwe określenie? Moje doświadczenia z Amazon Redshift, poza kilkoma szczegółami, nie różnią się zbytnio od korzystania z pospolitej bazy danych.

No właśnie, szczegóły…

Co Ma Redshift Pod Maską?

Amazon złapał w swoje zdolne łapki kod PostgreSQL i zrobił w nim czary-mary.

Kropka, nic więcej nie wiemy.

Coś dodali, część funkcjonalności usunęli, resztę zmodyfikowali. Rezultat jest taki, że prawie dowolnym klientem psql możemy połączyć się z usługą i korzystać jak ze standardowej wersji Postgresa.

Na czym więc polega różnica?

Głównie chodzi o ilość informacji, jakie możemy przechowywać w usłudze. AWS chwali się, że można tam zmieścić więcej niż jeden petabajt, domyślne maksimum może wynieść 2 petabajty (2048 TB) – czyli prawie tyle, ile jeden Hipokamp u dorosłego człowieka!

Okej, to nie wszystko.

Skoro mamy psql, to mamy również typowy dla tej bazy danych interface rozumiejący SQL. Mało tego, bardziej rozbudowany SQL, dzięki któremu możemy w bardzo łatwy sposób importować dane z innych usług AWS, takich jak S3 czy nawet bezpośrednio z instancji przez chociażby SSH. Na pewno nie jest aż tak kolorowo – pomyślicie. Racja, przy relatywnie mniejszych konfiguracjach ręczne zarządzanie wpychaniem danych do RS może się udać, jednak gdy dataset urośnie, może okazać się, że operacja importu zacznie się przytykać od natłoku danych. Co wtedy?

Optymalizacja

Optymalizacja, owszem ale to wystarczy tylko na chwilę. AWS DataPipeline – podobno są tacy, co próbowali, i działa. Ja stwierdziłem, że mój dataflow jest banalnie prosty i postanowiłem wykorzystać AWS Kinesis Firehose zaraz po tym, jak zostało udostępnione do użytku. Pierwszą zaletą Firehose jest to, że nie martwimy się o limity na Redshifcie. Amazon przygotował to tak, aby działało w odpowiednim tempie, nie zabiło klastra i wpychało dane z najwyższą wydajnością.

Backup i Export

Wiemy jak łatwo i przyjemnie importować dane – teraz czas na backup/export.

Mamy snapshoty lub manualne zrzucanie danych np. do S3, a potem można je zGlacierować, aby nie płacić za dużo. Snapshoty są w porządku – do czasu, gdy są w miarę malutkie. Gdy urosną, czas dostępu do nich znacznie się wydłuża, ponieważ aby dostać się do danych, musimy postawić nowy klaster, który kosztuje dodatkowe dolary i którego uruchomienie może zająć kilka lub kilkadziesiąt godzin. Podobnie sytuacja wygląda, jeżeli chodzi o kopie danych w postaci plików TSV utworzonych poprzez operację UNLOAD. Pomijając czas potrzebny na wyciągnięcie danych z Glaciera, to ogromną zaletą tego rozwiązania jest możliwość selektywnego przywracania rekordów z poszczególnych plików.

Co zatem wybrać?

Obie metody na raz! Snapshot co jakiś czas – wykona się automatycznie po skonfigurowaniu w konsoli AWS – plus skrypt do zrzucania danych do formy plików na S3 poprzez UNLOAD.

Skalowanie

Mamy nasz Data Warehouse, po czasie jednak zaczyna pękać w szwach i potrzebujemy go skalować w górę, najlepiej bez przerwy w działaniu usługi. Na ten temat powinien powstać osobny artykuł. Na razie w skrócie napiszę, że chodzi o postawienie drugiej, już większej instancji i symultaniczne wysyłanie do niej tych samych informacji, a po odpowiednim czasie przepięcie na nią produkcji. Brzmi prosto? Oj, nie 🙂

Czy Hurtownia Danych w Chmurze Ma Sens?

Jaka jest odpowiedź na pytanie w tytule artykułu? Tak, ma sens i warto. Należy – tylko – wiedzieć jak z niego poprawnie korzystać, a doświadczenie przychodzi z czasem. To, co zostało opisane powyżej, jest zaledwie czubkiem góry lodowej.