Dremio: prostsza i szybsza analiza danych

Jacques Nadeau jest dyrektorem technicznym i współzałożycielem Dremio.

Teraz jest świetny czas, aby zostać programistą. W ciągu ostatniej dekady decyzje dotyczące technologii przeniosły się z zarządu do innowacyjnych deweloperów, którzy budują w oparciu o oprogramowanie open source i podejmują decyzje w oparciu o zalety projektu bazowego, a nie relacje handlowe zapewniane przez dostawcę. Pojawiły się nowe projekty, które koncentrują się na zwiększaniu produktywności deweloperów, łatwiejszych w zarządzaniu i skalowaniu. Dotyczy to praktycznie każdej warstwy stosu technologii. W rezultacie programiści mają dziś prawie nieograniczone możliwości odkrywania nowych technologii, nowych architektur i nowych modeli wdrażania.

Patrząc w szczególności na warstwę danych, systemy NoSQL, takie jak MongoDB, Elasticsearch i Cassandra, przesunęły granice pod względem sprawności, skalowalności i wydajności dla aplikacji operacyjnych, z których każdy ma inny model danych i podejście do schematu. Po drodze wiele zespołów programistycznych przeszło na model mikrousług, rozpowszechniając dane aplikacji w wielu różnych systemach bazowych.

Jeśli chodzi o analitykę, stare i nowe źródła danych znalazły miejsce w mieszance tradycyjnych hurtowni danych i jezior danych, niektóre na Hadoop, inne na Amazon S3. Powstanie platformy przesyłania strumieniowego danych Kafka stworzyło zupełnie inny sposób myślenia o ruchu danych i analizie danych w ruchu.

Przy danych w tak wielu różnych technologiach i bazowych formatach analiza nowoczesnych danych jest trudna. Narzędzia BI i narzędzia analityczne, takie jak Tableau, Power BI, R, Python i modele uczenia maszynowego, zostały zaprojektowane z myślą o świecie, w którym dane znajdują się w pojedynczej, wysokowydajnej relacyjnej bazie danych. Ponadto użytkownicy tych narzędzi - analitycy biznesowi, analitycy danych i modele uczenia maszynowego - chcą mieć możliwość samodzielnego uzyskiwania dostępu do danych, ich eksploracji i analizowania, bez uzależnienia od IT.

Przedstawiamy strukturę danych Dremio

Narzędzia BI, systemy analizy danych i modele uczenia maszynowego działają najlepiej, gdy dane znajdują się w pojedynczej, wydajnej relacyjnej bazie danych. Niestety, nie są to obecne dane. W rezultacie dział IT nie ma innego wyjścia, jak tylko wypełnić tę lukę poprzez połączenie niestandardowego oprogramowania ETL i własnych produktów. W wielu firmach stos analiz zawiera następujące warstwy:

  • Inscenizacja danych . Dane są przenoszone z różnych operacyjnych baz danych do jednego obszaru przejściowego, takiego jak klaster Hadoop lub usługa przechowywania w chmurze (np. Amazon S3).
  • Hurtownia danych . Chociaż możliwe jest wykonywanie zapytań SQL bezpośrednio na platformie Hadoop i pamięci masowej w chmurze, systemy te po prostu nie są zaprojektowane do zapewniania interaktywnej wydajności. Dlatego podzbiór danych jest zwykle ładowany do relacyjnej hurtowni danych lub bazy danych MPP.
  • Kostki, tabele agregacji i wyciągi BI . Aby zapewnić interaktywną wydajność na dużych zbiorach danych, dane muszą być wstępnie zagregowane i / lub zindeksowane poprzez zbudowanie kostek w systemie OLAP lub zmaterializowanych tabel agregacji w hurtowni danych.

Ta wielowarstwowa architektura stwarza wiele wyzwań. Jest złożony, kruchy i powolny oraz tworzy środowisko, w którym konsumenci danych są całkowicie zależni od IT.

Dremio wprowadza nowy poziom analizy danych, który nazywamy samoobsługową strukturą danych. Dremio to projekt typu open source, który umożliwia analitykom biznesowym i analitykom danych eksplorację i analizę dowolnych danych w dowolnym momencie, niezależnie od ich lokalizacji, rozmiaru czy struktury. Dremio łączy architekturę skalowalną w poziomie z wykonywaniem kolumnowym i przyspieszeniem, aby osiągnąć interaktywną wydajność na dowolnym wolumenie danych, jednocześnie umożliwiając IT, naukowcom zajmującym się danymi i analitykom biznesowym płynne kształtowanie danych zgodnie z potrzebami biznesowymi.

Zbudowany na bazie Apache Arrow, Apache Parquet i Apache Calcite

Dremio wykorzystuje wysokowydajne kolumnowe przechowywanie i wykonywanie, obsługiwane przez Apache Arrow (kolumna w pamięci) i Apache Parquet (kolumna na dysku). Dremio używa również Apache Calcite do analizowania SQL i optymalizacji zapytań, opierając się na tych samych bibliotekach, co wiele innych silników opartych na SQL, takich jak Apache Hive.

Apache Arrow to projekt typu open source, który umożliwia przetwarzanie i wymianę danych kolumnowych w pamięci. Arrow został stworzony przez Dremio i obejmuje inicjatorów z różnych firm, w tym Cloudera, Databricks, Hortonworks, Intel, MapR i Two Sigma.

Dremio to pierwszy silnik wykonawczy zbudowany od podstaw na platformie Apache Arrow. Wewnętrznie dane w pamięci są utrzymywane poza stertą w formacie Arrow, a wkrótce pojawi się interfejs API, który zwraca wyniki zapytań jako bufory pamięci Arrow.

Wiele innych projektów objęło również Arrow. Python (Pandas) i R należą do tych projektów, umożliwiając analitykom danych wydajniejszą pracę z danymi. Na przykład Wes McKinney, twórca popularnej biblioteki Pandas, niedawno zademonstrował, w jaki sposób Arrow umożliwia użytkownikom Pythona odczytywanie danych w Pandach z prędkością ponad 10 GB / s.

Jak Dremio udostępnia dane samoobsługowe

Oprócz możliwości interaktywnej pracy ze swoimi zbiorami danych, inżynierowie danych, analitycy biznesowi i naukowcy zajmujący się danymi potrzebują także sposobu na dobór danych tak, aby odpowiadały potrzebom konkretnego projektu. Jest to fundamentalna zmiana w stosunku do modelu zorientowanego na IT, w którym konsumenci danych inicjują żądanie zbioru danych i czekają, aż dział IT zrealizuje żądanie tygodnie lub miesiące później. Dremio umożliwia model samoobsługi, w którym konsumenci danych korzystają z możliwości ich przechowywania w celu wspólnego odkrywania, nadzorowania, przyspieszania i udostępniania danych bez polegania na IT.

Wszystkie te możliwości są dostępne za pośrednictwem nowoczesnego, intuicyjnego interfejsu internetowego:

  • Odkryj . Dremio zawiera ujednolicony katalog danych, w którym użytkownicy mogą odkrywać i przeglądać fizyczne i wirtualne zestawy danych. Katalog danych jest automatycznie aktualizowany po dodaniu nowych źródeł danych oraz w miarę ewolucji źródeł danych i wirtualnych zestawów danych. Wszystkie metadane są indeksowane w wysokowydajnym indeksie z możliwością wyszukiwania i udostępniane użytkownikom za pośrednictwem interfejsu Dremio.
  • Kurator . Dremio umożliwia użytkownikom zarządzanie danymi poprzez tworzenie wirtualnych zestawów danych. Obsługiwanych jest wiele transformacji typu „wskaż i kliknij”, a zaawansowani użytkownicy mogą używać składni SQL do definiowania bardziej złożonych transformacji. W miarę wykonywania zapytań w systemie Dremio uczy się o danych, umożliwiając mu rekomendowanie różnych przekształceń, takich jak łączenie i konwersje typów danych.
  • Dremio jest w stanie przyspieszyć zbiory danych nawet 1000 razy w porównaniu z wydajnością systemu źródłowego. Użytkownicy mogą głosować na zbiory danych, które ich zdaniem powinny być szybsze, a heurystyka Dremio uwzględni te głosy podczas określania, które zbiory danych mają przyspieszyć. Opcjonalnie administratorzy systemu mogą ręcznie określić, które zestawy danych należy przyspieszyć.
  • Dremio umożliwia użytkownikom bezpieczne udostępnianie danych innym użytkownikom i grupom. W tym modelu grupa użytkowników może współpracować nad wirtualnym zestawem danych, który zostanie wykorzystany do określonego zadania analitycznego. Alternatywnie użytkownicy mogą przesyłać własne dane, takie jak arkusze kalkulacyjne programu Excel, w celu dołączenia do innych zestawów danych z katalogu przedsiębiorstwa. Twórcy wirtualnych zbiorów danych mogą określić, którzy użytkownicy mogą wyszukiwać lub edytować ich wirtualne zbiory danych. To jak Dokumenty Google dla Twoich danych.

Jak działa przyspieszenie danych Dremio

Dremio wykorzystuje wysoce zoptymalizowane fizyczne reprezentacje danych źródłowych zwane odbiciami danych. Sklep Reflection może działać w HDFS, MapR-FS, pamięci masowej w chmurze, takiej jak S3, lub pamięci masowej podłączonej bezpośrednio (DAS). Rozmiar magazynu odbicia może przekraczać rozmiar pamięci fizycznej. Ta architektura umożliwia Dremio przyspieszenie większej ilości danych przy niższych kosztach, co skutkuje znacznie wyższym współczynnikiem trafień w pamięci podręcznej w porównaniu z tradycyjnymi architekturami opartymi wyłącznie na pamięci. Odbicia danych są automatycznie wykorzystywane przez optymalizator kosztów w czasie zapytania.

Odbicia danych są niewidoczne dla użytkowników końcowych. W przeciwieństwie do kostek OLAP, tabel agregacji i wyciągów BI użytkownik nie łączy się jawnie z odbiciem danych. Zamiast tego użytkownicy wysyłają zapytania względem modelu logicznego, a optymalizator Dremio automatycznie przyspiesza zapytanie, korzystając z odbić danych, które są odpowiednie dla zapytania w oparciu o analizę kosztów optymalizatora.

Gdy optymalizator nie może przyspieszyć zapytania, Dremio wykorzystuje swój wysoce wydajny silnik wykonywania rozproszonych zadań, wykorzystując przetwarzanie kolumnowe w pamięci (za pośrednictwem Apache Arrow) i zaawansowane przekazywanie danych do bazowych źródeł danych (w przypadku źródeł RDBMS lub NoSQL).

Jak Dremio obsługuje zapytania SQL

Aplikacje klienckie wysyłają zapytania SQL do Dremio przez ODBC, JDBC lub REST. Zapytanie może obejmować jeden lub więcej zestawów danych, potencjalnie znajdujących się w różnych źródłach danych. Na przykład zapytanie może być połączeniem między tabelą Hive, Elasticsearch i kilkoma tabelami Oracle.

Dremio wykorzystuje dwie podstawowe techniki, aby zmniejszyć ilość przetwarzania wymaganego dla zapytania:

  • Przesuwa w dół do bazowego źródła danych . Optymalizator rozważy możliwości bazowego źródła danych i względne koszty. Następnie wygeneruje plan, który będzie wykonywał etapy zapytania w źródle lub w rozproszonym środowisku wykonawczym Dremio, aby uzyskać możliwie najbardziej wydajny plan ogólny.
  • Przyspieszenie dzięki odbiciom danych . Optymalizator użyje odbić danych dla części zapytania, gdy wygeneruje najbardziej wydajny plan ogólny. W wielu przypadkach całe zapytanie można obsłużyć z poziomu odbić danych, ponieważ mogą one być o rząd wielkości bardziej wydajne niż przetwarzanie zapytań w bazowym źródle danych.

Zapytanie o przesunięcia w dół

Dremio jest w stanie zepchnąć przetwarzanie na relacyjne i nierelacyjne źródła danych. Nierelacyjne źródła danych zazwyczaj nie obsługują języka SQL i mają ograniczone możliwości wykonywania. Na przykład system plików nie może stosować predykatów ani agregacji. Z drugiej strony MongoDB może stosować predykaty i agregacje, ale nie obsługuje wszystkich sprzężeń. Optymalizator Dremio rozumie możliwości każdego źródła danych. Gdy jest najbardziej wydajne, Dremio przesyła jak najwięcej zapytania do bazowego źródła, a resztę wykonuje we własnym rozproszonym silniku wykonawczym.

Odciążanie operacyjnych baz danych

Większość operacyjnych baz danych jest zaprojektowana pod kątem obciążeń zoptymalizowanych pod kątem zapisu. Ponadto wdrożenia te muszą uwzględniać rygorystyczne umowy SLA, ponieważ wszelkie przestoje lub obniżona wydajność mogą znacząco wpłynąć na działalność. W rezultacie systemy operacyjne są często odizolowane od przetwarzania zapytań analitycznych. W takich przypadkach Dremio może wykonywać zapytania analityczne przy użyciu funkcji Data Reflections, które zapewniają najbardziej wydajne przetwarzanie zapytań przy jednoczesnym zminimalizowaniu wpływu na system operacyjny. Odbicia danych są okresowo aktualizowane na podstawie zasad, które można konfigurować dla poszczególnych tabel.

Fazy ​​wykonywania zapytania

Życie kwerendy obejmuje następujące fazy:

  1. Klient przesyła zapytanie do koordynatora za pośrednictwem ODBC / JDBC / REST
  2. Planowanie
    1. Koordynator analizuje zapytanie do uniwersalnego modelu relacyjnego Dremio
    2. Koordynator bierze pod uwagę dostępne statystyki dotyczące źródeł danych w celu opracowania planu zapytań, a także możliwości funkcjonalne źródła
  3. Koordynator przepisuje plan zapytania do użycia
    1. dostępne odbicia danych, z uwzględnieniem kolejności, partycjonowania i dystrybucji odbić danych oraz
    2. dostępne możliwości źródła danych
  4. Wykonanie
  1. Wykonawcy odczytują dane do buforów Arrow równolegle ze źródeł
    1. Wykonawcy wykonują przepisany plan zapytań.
    2. Jeden executor łączy wyniki z jednego lub większej liczby wykonawców i przesyła wyniki końcowe do koordynatora
  1. Klient otrzymuje wyniki od koordynatora

Należy pamiętać, że dane mogą pochodzić z odbić danych lub bazowych źródeł danych. Podczas odczytu ze źródła danych moduł wykonujący przesyła natywne zapytania (np. MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) określone przez optymalizatora w fazie planowania.

Wszystkie operacje na danych są wykonywane w węźle wykonawczym, co umożliwia skalowanie systemu do wielu współbieżnych klientów przy użyciu tylko kilku węzłów koordynujących.

Przykładowe zapytanie przesuwające w dół

Aby zilustrować, jak Data Fabric pasuje do Twojej architektury danych, przyjrzyjmy się bliżej uruchamianiu zapytania SQL na źródle, które nie obsługuje SQL.

Jednym z bardziej popularnych współczesnych źródeł danych jest Elasticsearch. Elasticsearch ma wiele do polubienia, ale pod względem analitycznym nie obsługuje SQL (w tym sprzężeń SQL). Oznacza to, że narzędzi takich jak Tableau i Excel nie można używać do analizowania danych z aplikacji zbudowanych w tym magazynie danych. Istnieje projekt wizualizacji o nazwie Kibana, który jest popularny w Elasticsearch, ale Kibana jest przeznaczona dla programistów. To nie jest tak naprawdę dla użytkowników biznesowych.

Dremio ułatwia analizę danych w Elasticsearch za pomocą dowolnego narzędzia opartego na języku SQL, w tym Tableau. Weźmy na przykład następujące zapytanie SQL dotyczące danych biznesowych Yelp, które są przechowywane w formacie JSON:

Wybierz stan, miasto, nazwę, review_count

Z elast.yelp.business

GDZIE

  stan NIE W („TX”, „UT”, „NM”, „NJ”) AND

  review_count> 100

ZAMÓWIENIE PRZEZ review_count DESC, województwo, miasto

LIMIT 10

Dremio kompiluje zapytanie do wyrażenia, które może przetworzyć Elasticsearch: