Przewodnik inżyniera danych dotyczący nietradycyjnych sposobów przechowywania danych

Inżynieria danych

Wraz z rozwojem Big Data i data science, wiele ról inżynierskich jest kwestionowanych i rozszerzanych. Jedną z nowych ról jest inżynieria danych .

Pierwotnie celem inżynierii danych było ładowanie zewnętrznych źródeł danych oraz projektowanie baz danych (projektowanie i rozwijanie potoków do zbierania, manipulowania, przechowywania i analizy danych).

Od tego czasu rozwinął się, aby obsługiwać objętość i złożoność dużych zbiorów danych. Tak więc inżynieria danych obejmuje teraz szeroki zakres umiejętności, od indeksowania sieci, czyszczenia danych, przetwarzania rozproszonego oraz przechowywania i wyszukiwania danych.

Dla inżynierii danych i inżynierów danych przechowywanie i pobieranie danych jest krytycznym elementem potoku, wraz z tym, jak dane mogą być wykorzystywane i analizowane.

W ostatnim czasie pojawiło się wiele nowych i różnych technologii przechowywania danych. Jednak który z nich najlepiej nadaje się i ma najbardziej odpowiednie funkcje do inżynierii danych?

Większość inżynierów zna bazy danych SQL, takie jak PostgreSQL, MSSQL i MySQL, które są ustrukturyzowane w relacyjne tabele danych z pamięcią masową zorientowaną na wiersze.

Biorąc pod uwagę, jak wszechobecne są te bazy danych, nie będziemy ich dzisiaj omawiać. Zamiast tego badamy trzy rodzaje alternatywnych magazynów danych, które zyskują na popularności i które wprowadziły różne podejścia do radzenia sobie z danymi.

W kontekście inżynierii danych technologie te to wyszukiwarki, magazyny dokumentów i magazyny kolumnowe.

• Wyszukiwarki przodują w zapytaniach tekstowych. W porównaniu do dopasowań tekstowych w bazach danych SQL, takich jak LIKE , wyszukiwarki oferują większe możliwości zapytań i lepszą wydajność od razu po zainstalowaniu.
• Magazyny dokumentów zapewniają lepszą adaptację schematu danych niż tradycyjne bazy danych. Dzięki przechowywaniu danych jako pojedynczych obiektów dokumentów, często reprezentowanych jako JSON, nie wymagają one wstępnego definiowania schematu.
• Sklepy kolumnowe specjalizują się w zapytaniach jednokolumnowych i agregacjach wartości. Operacje SQL, takie jak SUM i AVG , są znacznie szybsze w magazynach kolumnowych, ponieważ dane z tej samej kolumny są przechowywane bliżej siebie na dysku twardym.

W tym artykule omówimy wszystkie trzy technologie: Elasticsearch jako wyszukiwarkę, MongoDB jako magazyn dokumentów oraz Amazon Redshift jako magazyn kolumnowy.

Rozumiejąc alternatywne przechowywanie danych, możemy wybrać najbardziej odpowiedni dla każdej sytuacji.

Aby porównać te technologie, zbadamy, jak indeksują, fragmentują i agregują dane.

Każda strategia indeksowania danych poprawia niektóre zapytania, jednocześnie utrudniając inne.

Wiedza o tym, które zapytania są używane najczęściej, może mieć wpływ na wybór magazynu danych.

Sharding, metodologia, według której bazy danych dzielą swoje dane na porcje, określa, w jaki sposób infrastruktura będzie się rozwijać w miarę przyjmowania większej ilości danych.

Wybór takiego, który pasuje do naszego planu rozwoju i budżetu, ma kluczowe znaczenie i dotyczy to każdej firmy zajmującej się analizą danych, niezależnie od jej wielkości.

Wreszcie, każda z tych technologii agreguje dane w bardzo różny sposób.

Kiedy mamy do czynienia z gigabajtami i terabajtami danych, niewłaściwa strategia agregacji może ograniczyć rodzaje i wydajność generowanych przez nas raportów.

Jako inżynierowie danych musimy wziąć pod uwagę wszystkie trzy aspekty podczas oceny różnych miejsc przechowywania danych.

Konkurenci

Wyszukiwarka: Elasticsearch

Elasticsearch szybko zyskał popularność wśród swoich rówieśników ze względu na skalowalność i łatwość integracji. Zbudowany na bazie Apache Lucene, oferuje zaawansowaną, niestandardową funkcjonalność wyszukiwania tekstu i indeksowania. Oprócz tradycyjnych zadań wyszukiwarek, wyszukiwania tekstowego i zapytań o dokładne wartości, Elasticsearch oferuje również możliwości agregacji warstwowej.

Magazyn dokumentów: MongoDB

W tym momencie MongoDB można uznać za bazę danych NoSQL. Łatwość obsługi i elastyczność szybko zyskały popularność. MongoDB obsługuje rozbudowane i elastyczne zapytania w celu zagłębiania się w złożone dokumenty. Pola, do których często wysyłane są zapytania, można przyspieszyć dzięki indeksowaniu, a podczas agregowania dużej ilości danych MongoDB oferuje wieloetapowy potok.

Sklep kolumnowy: Amazon Redshift

Wraz ze wzrostem popularności NoSQL, kolumnowe bazy danych również wzbudziły zainteresowanie, zwłaszcza w zakresie analizy danych. Dzięki przechowywaniu danych w kolumnach zamiast zwykłych wierszy, operacje agregacji mogą być wykonywane bezpośrednio z dysku, co znacznie zwiększa wydajność. Kilka lat temu Amazon wprowadził usługę hostowaną dla sklepu kolumnowego o nazwie Redshift.

Indeksowanie

Możliwość indeksowania Elasticsearch

Pod wieloma względami wyszukiwarki to magazyny danych, które specjalizują się w indeksowaniu tekstów.

Podczas gdy inne magazyny danych tworzą indeksy na podstawie dokładnych wartości pola, wyszukiwarki umożliwiają pobieranie tylko fragmentu pola (zwykle tekstowego).

Domyślnie to pobieranie odbywa się automatycznie dla każdego pola przez analizatory.

Analizator to moduł, który tworzy wiele kluczy indeksowych, oceniając wartości pól i dzieląc je na mniejsze wartości.

Na przykład podstawowy analizator może przeanalizować „szybki brązowy lis przeskoczył nad leniwym psem” za pomocą słów, takich jak „ten”, „szybki”, „brązowy”, „lis” i tak dalej.

Ta metoda umożliwia użytkownikom znajdowanie danych poprzez wyszukiwanie fragmentów w wynikach, uszeregowanych według liczby fragmentów zgodnych z tymi samymi danymi dokumentu.

Bardziej wyrafinowany analizator mógłby wykorzystywać odległości edycji, n-gramy i filtrować według odrzuconych słów, aby zbudować kompleksowy indeks wyszukiwania.

Możliwość indeksowania MongoDB

Jako ogólny magazyn danych MongoDB ma dużą elastyczność w indeksowaniu danych.

W przeciwieństwie do Elasticsearch, domyślnie indeksuje tylko pole _id i musimy ręcznie utworzyć indeksy dla często odpytywanych pól.

W porównaniu do Elasticsearch, analizator tekstu MongoDB nie jest tak potężny. Zapewnia jednak dużą elastyczność w zakresie metod indeksowania, od złożonych i geoprzestrzennych w celu optymalizacji zapytań po TTL i rzadki w celu zmniejszenia ilości pamięci.

Możliwość indeksowania Redshift

W przeciwieństwie do Elasticsearch, MongoDB, czy nawet tradycyjnych baz danych, w tym PostgreSQL, Amazon Redshift nie obsługuje metody indeksowania.

Zamiast tego skraca czas zapytania, utrzymując spójne sortowanie na dysku.

Jako użytkownicy możemy skonfigurować uporządkowany zestaw wartości kolumn jako klucz sortowania tabeli. Dzięki sortowaniu danych na dysku Redshift może pominąć cały blok podczas pobierania, jeśli jego wartość wykracza poza zakres zapytania, znacznie zwiększając wydajność.

Fragmentacja

Możliwość shardingu Elasticsearch

Elasticsearch został zbudowany na bazie Lucene, aby skalować w poziomie i być gotowym do produkcji.

Skalowanie odbywa się poprzez tworzenie wielu instancji Lucene (odłamków) i dystrybuowanie ich na wiele węzłów (serwerów) w ramach klastra.

Domyślnie każdy dokument jest kierowany do odpowiedniego fragmentu przez jego pole _id .

Podczas pobierania węzeł główny wysyła każdemu fragmentowi kopię zapytania przed ostatecznym zagregowaniem i uszeregowaniem ich pod kątem danych wyjściowych.

Możliwości shardingu MongoDB

W klastrze MongoDB istnieją trzy typy serwerów: router, konfiguracja i fragment.

Dzięki skalowaniu routera serwery mogą akceptować więcej żądań, ale duże obciążenie ma miejsce na serwerach odłamków.

Podobnie jak w przypadku Elasticsearch, dokumenty MongoDB są kierowane (domyślnie) przez _id do odpowiednich fragmentów. W czasie zapytania serwer konfiguracyjny powiadamia router, który dzieli zapytanie na fragmenty, a następnie dystrybuuje zapytanie i agreguje wyniki.

Zdolność odłamywania Redshift

Klaster Amazon Redshift składa się z jednego węzła wiodącego i kilku węzłów obliczeniowych.

Węzeł lider obsługuje kompilację i dystrybucję zapytań oraz agregację wyników pośrednich.

W przeciwieństwie do serwerów routerów MongoDB, węzeł lidera jest spójny i nie można go skalować w poziomie.

Chociaż tworzy to wąskie gardło, umożliwia również wydajne buforowanie skompilowanych planów wykonania dla popularnych zapytań.

Agregacja

Możliwość agregacji Elasticsearch

Dokumenty w Elasticsearch mogą być grupowane według dokładnych, przedziałowych, a nawet czasowych i geolokalizacji wartości.

Te zasobniki można dalej grupować w celu uzyskania większej szczegółowości dzięki agregacji zagnieżdżonej.

Dla każdej warstwy można obliczyć metryki, w tym średnie i odchylenia standardowe, co zapewnia możliwość obliczenia hierarchii analiz w ramach pojedynczego zapytania.

Będąc magazynem opartym na dokumentach, ma ograniczenia związane z porównaniami pól wewnątrz dokumentu.

Na przykład, chociaż dobrze sprawdza się w filtrowaniu, jeśli liczba obserwujących w polu jest większa niż 10, nie możemy sprawdzić, czy liczba obserwujących jest większa niż w innym polu obserwującym .

Alternatywnie możemy wstrzykiwać skrypty jako predykaty niestandardowe. Ta funkcja jest świetna do jednorazowej analizy, ale wydajność spada podczas produkcji.

Zdolność agregacji MongoDB

Potok agregacji jest wydajny i szybki.

Jak sama nazwa wskazuje, operuje na zwróconych danych w sposób etapowy.

Każdy krok może filtrować, agregować i przekształcać dokumenty, wprowadzać nowe metryki lub usuwać wcześniej zagregowane grupy.

Ponieważ te operacje są wykonywane etapami, a także poprzez zapewnienie, że dokumenty i pola są redukowane tylko do filtrowania, można zminimalizować koszt pamięci. W porównaniu do Elasticsearch, a nawet Redshift, Aggregation Pipeline jest niezwykle elastycznym sposobem przeglądania danych.

Pomimo swoich zdolności adaptacyjnych, MongoDB cierpi na ten sam brak porównania pól wewnątrz dokumentu, co Elasticsearch.

Ponadto niektóre operacje, w tym $group , wymagają przekazania wyników do węzła głównego.

W ten sposób nie wykorzystują przetwarzania rozproszonego.

Ci, którzy nie są zaznajomieni z etapowym obliczaniem potoku, uznają niektóre zadania za nieintuicyjne. Na przykład zsumowanie liczby elementów w polu tablicowym wymagałoby dwóch kroków: najpierw operacji $unwind , a następnie operacji $group .

Zdolność agregacji Redshift

Korzyści z Amazon Redshift są nie do przecenienia.

Frustrująco powolne agregacje w MongoDB podczas analizy ruchu mobilnego są szybko rozwiązywane przez Amazon Redshift.

Obsługujący SQL, tradycyjni inżynierowie baz danych będą mieli łatwy czas na migrację swoich zapytań do Redshift.

Pomijając czas na wdrożenie, SQL jest sprawdzonym, skalowalnym i potężnym językiem zapytań, który z łatwością obsługuje porównania pól między dokumentami/wierszami. Amazon Redshift dodatkowo poprawia swoją wydajność, kompilując i buforując popularne zapytania wykonywane w węzłach obliczeniowych.

Jako relacyjna baza danych Amazon Redshift nie ma takiej elastyczności schematu, jak MongoDB i Elasticsearch. Zoptymalizowany pod kątem operacji odczytu, cierpi na spadki wydajności podczas aktualizacji i usuwania.

Aby zachować najlepszy czas odczytu, wiersze należy posortować, co wymaga dodatkowych działań operacyjnych.

Dostosowany do problemów o wielkości petabajtów, nie jest tani i prawdopodobnie nie jest warty inwestycji, chyba że występują problemy ze skalowaniem z innymi bazami danych.

Wybór zwycięzcy

W tym artykule przeanalizowaliśmy trzy różne technologie – Elasticsearch, MongoDB i Amazon Redshift – w kontekście inżynierii danych. Nie ma jednak wyraźnego zwycięzcy, ponieważ każda z tych technologii jest liderem w swojej kategorii typów pamięci masowej.

W przypadku inżynierii danych, w zależności od przypadku użycia, niektóre opcje są lepsze niż inne.

• MongoDB to fantastyczna baza danych dla początkujących. Zapewnia elastyczność, której potrzebujemy, gdy schemat danych nie został jeszcze określony. To powiedziawszy, MongoDB nie przewyższa konkretnych przypadków użycia, w których specjalizują się inne bazy danych.
• Chociaż Elasticsearch oferuje podobny schemat płynów do MongoDB, jest zoptymalizowany pod kątem wielu indeksów i zapytań tekstowych kosztem wydajności zapisu i rozmiaru pamięci. Dlatego powinniśmy rozważyć migrację do Elasticsearch, gdy okaże się, że utrzymujemy liczne indeksy w MongoDB.
• Redshift wymaga wstępnie zdefiniowanego schematu danych i brakuje mu możliwości adaptacji, które zapewnia MongoDB. W zamian deklasuje inne bazy danych w przypadku zapytań obejmujących tylko jedną (lub kilka) kolumn. Gdy pozwala na to budżet, Amazon Redshift jest świetną tajną bronią, gdy inni nie mogą sobie poradzić z ilością danych.