w ciągu ostatnich kilku lat odbyłem wiele rozmów z przyjaciółmi i współpracownikami sfrustrowanymi tym, jak niezwykle złożony jest ekosystem infrastruktury danych. Chociaż nie tak źle jak świat front-end, rzeczy zmieniają się wystarczająco szybko, aby stworzyć zupę buzzword.

jako początkujący, bardzo trudno jest zdecydować, które narzędzia są odpowiednie dla Ciebie. Fundacja Apache wymienia 38 projektów w sekcji” Big Data”, A narzędzia te nakładają się na problemy, które rzekomo rozwiązują. Na przykład Flink, Samza, Storm i Spark Streaming to „silniki przetwarzania strumienia rozproszonego”, Apex i Beam „unify stream and batch processing”.

w tym poście mam nadzieję pomóc w poruszaniu się po opcjach podczas budowania infrastruktury danych. Są to mniej więcej kroki, które chciałbym dzisiaj wykonać, w oparciu o moje doświadczenia z ostatniej dekady i rozmowy z kolegami pracującymi w tej przestrzeni.

na początku swojego projektu, prawdopodobnie wyruszasz z niczym więcej niż celem „get insights from my data” w ręku. Przypisanie tego do określonego zestawu technologii jest niezwykle trudne. Prawdopodobnie nie masz wielkiego wyczucia, jakie narzędzia są popularne, co oznacza „stream” lub „batch” lub czy w ogóle potrzebujesz infrastruktury danych.

w tym poście mam nadzieję dostarczyć kilka wskazówek, które pomogą Ci szybko rozpocząć pracę i wydobyć wartość z danych. Mocno wierzę w to, aby wszystko było proste tak długo, jak to możliwe, wprowadzając złożoność tylko wtedy, gdy jest potrzebna do skalowalności. Ten post podąża za tym łukiem w trzech etapach. Pod wieloma względami przypomina etapy budowania infrastruktury danych, które śledziłem w ciągu ostatnich kilku lat.

zauważ, że nie ma jednego właściwego sposobu na architekturę infrastruktury danych. Dla ekspertów, którzy to czytają, być może korzystałeś z alternatywnych rozwiązań sugerowanych tutaj. To fantastyczne i podkreśla różnorodność niesamowitych narzędzi, które mamy w dzisiejszych czasach. Przeszliśmy bardzo długą drogę od kiedy Hadoop MapReduce był wszystkim co mieliśmy.

więc chodzi o to: prawdopodobnie nie masz jeszcze „big data”. Prawie 4 lata później artykuł Chrisa Stucchio z 2013 roku Don ’ t use Hadoop jest nadal aktualny. Jeśli masz mniej niż 5 TB danych, zacznij od małych. Pozwoli to zaoszczędzić operacyjnych bólów głowy z utrzymaniem systemów, których jeszcze nie potrzebujesz. Ale hej, jeśli kochasz 3am ćwiczenia ognia od niepowodzeń pracy, prosimy pominąć tę sekcję …

w przeciwnym razie, trzymaj się z dala od wszystkich technologii buzzword na początku i skup się na dwóch rzeczach: (1) dokonywanie zapytań danych w SQL i (2) Wybór narzędzia BI. Będzie to szkielet „Witaj, świecie” dla całej przyszłej infrastruktury danych.

wszystko w SQL

jest to naprawdę ważne, ponieważ odblokowuje dane dla całej organizacji. Z rzadkimi wyjątkami dla najbardziej nieustraszonych ludzi marketingu, nigdy nie przekonasz swoich nietechnicznych kolegów do nauki Kibany, przeglądania logów lub używania niejasnej składni magazynu danych NoSQL.

zapewnienie dostępu do SQL pozwala całej firmie stać się samodzielnymi analitykami, usuwając twój już rozciągnięty zespół inżynierów ze ścieżki krytycznej. To również zamienia wszystkich w bezpłatny zespół QA dla Twoich danych. „Hej, te liczby wyglądają trochę dziwnie…” jest nieoceniona do znajdowania błędów w danych, a nawet w produkcie.

jeśli twoim podstawowym magazynem danych jest relacyjna baza danych, taka jak PostgreSQL lub MySQL, jest to naprawdę proste. Możesz po prostu skonfigurować replikę odczytu, dostęp do prowiantu i wszystko gotowe.

z bazą danych NoSQL, taką jak ElasticSearch, MongoDB lub DynamoDB, będziesz musiał wykonać więcej pracy, aby przekonwertować Dane i umieścić je w bazie danych SQL. Jeśli jesteś nowy w świecie danych, nazywamy to rurociągiem ETL. Jeśli to możliwe, nie buduj tego samodzielnie, ponieważ podłączenie gotowego rozwiązania będzie znacznie tańsze przy niewielkich ilościach danych. W zależności od istniejącej infrastruktury może istnieć dostawca usług ETL w chmurze, taki jak Segment, który można wykorzystać.

Jeśli stwierdzisz, że musisz zbudować własne potoki danych, na początku zachowaj je niezwykle proste. Napisz skrypt, aby okresowo zrzucać aktualizacje z bazy danych i zapisywać je gdzieś, gdzie można uzyskać zapytania SQL.

historia dla danych ETLing ze źródeł zewnętrznych jest podobna jak w przypadku baz danych NoSQL. Skorzystaj z usługi ETL-as-a-service provider lub napisz prosty skrypt i po prostu Zdeponuj swoje dane w bazie danych z funkcją zapytań SQL.

Skonfiguruj maszynę, aby uruchamiała Skrypty ETL jako codzienny cron, i wyruszasz na wyścigi.

narzędzie BI

dobre narzędzie BI jest ważną częścią zrozumienia danych. Niektóre świetne narzędzia do rozważenia to Chartio, Analiza trybów i dane Peryskopowe — każde z nich powinno działać świetnie, aby rozpocząć analizę. W większości przypadków możesz skierować te narzędzia bezpośrednio do bazy danych SQL za pomocą szybkiej konfiguracji i zanurzyć się w tworzeniu pulpitów nawigacyjnych.

Oto „Witaj, świecie” infrastruktury danych:

Etap 1: mały potok danych „Witaj, świecie”

Etap 2: nazwijmy to „średnimi” danymi

w tym momencie masz więcej niż kilka terabajtów, a Twój skrypt cron+ETL nie nadąża. Być może masz proliferację magazynów danych i masz heterogeniczną mieszankę backendów sql i NoSQL. Możesz również mieć kilka stron trzecich, od których zbierasz dane. Wreszcie, być może zaczynasz mieć wiele etapów w potokach ETL z pewnymi zależnościami między krokami.

zarządzanie przepływem pracy & Automatyzacja

pierwszym krokiem w tej fazie powinno być skonfigurowanie Przepływu Powietrza do zarządzania rurociągami ETL. Airflow pozwoli ci zaplanować zadania w regularnych odstępach czasu i wyrazić zarówno czasowe, jak i logiczne zależności między zadaniami. Jest to również świetne miejsce w Twojej infrastrukturze do dodawania powtórzeń zadań, monitorowania & ostrzegania o niepowodzeniach zadań. To żart, że każdy startup powyżej określonego rozmiaru pisze własnego Menedżera przepływu pracy / harmonogramu zadań. Między innymi Spotify napisał Luigi, a Pinterest napisał Pinball. Mają one jednak mniejszą dynamikę w społeczności i nie mają pewnych cech w odniesieniu do przepływu powietrza.

budowa rurociągów ETL

wraz z rozwojem firmy wymagania dotyczące rurociągów ETL znacznie się zmienią. Będziesz musiał zacząć budować bardziej skalowalną infrastrukturę, ponieważ jeden skrypt już jej nie przeciął. Twoje cele mogą również rozszerzyć się od zwykłego umożliwienia dostępu do SQL do obsługi innych zadań niższego szczebla, które przetwarzają te same dane.

ostatecznie proste potoki nie będą skalowane

aby sprostać tym zmieniającym się wymaganiom, będziesz chciał przekonwertować Skrypty ETL, aby działały jako rozproszone zadanie w klastrze. Liczba możliwych rozwiązań tutaj jest absolutnie przytłaczająca. Zdecydowanie polecam zacząć od Apache Spark. Spark ma ogromną, bardzo aktywną społeczność, skaluje się dobrze i jest dość łatwy do szybkiego uruchomienia. Na AWS możesz uruchomić Spark używając EMR; dla GCP, używając Cloud Dataproc. Jeśli pobierasz dane z relacyjnej bazy danych, Apache Sqoop jest w zasadzie standardem.

w tym momencie Twoja Infrastruktura ETL zacznie wyglądać jak pipelinowane etapy zadań, które implementują trzy czasowniki ETL: wyodrębnij dane ze źródeł, przekształć je w znormalizowane formaty na trwałej pamięci masowej i załaduj je do magazynu danych z zapytaniami SQL.

Hurtownia danych

na tym etapie uzyskanie wszystkich danych do SQL pozostanie priorytetem, ale jest to czas, w którym będziesz chciał rozpocząć budowanie „prawdziwej” hurtowni danych.

dla tych, którzy dopiero zaczynają, polecam korzystanie z BigQuery. BigQuery jest łatwy w konfiguracji (możesz po prostu załadować rekordy jako JSON), obsługuje zagnieżdżone/złożone typy danych i jest w pełni zarządzany/bezserwerowy, więc nie masz więcej infrastruktury do utrzymania. Podobnie jak w przypadku wielu zaleceń tutaj, dostępne są alternatywy dla BigQuery: na AWS, Redshift i on-prem, Presto. Preferuję BigQuery zamiast Redshift ze względu na jego konstrukcję bezserwerową, prostotę konfigurowania odpowiednich zabezpieczeń/audytu i obsługę złożonych typów. Presto warto rozważyć, jeśli masz trudne wymagania dotyczące on-prem.

myśląc o skonfigurowaniu hurtowni danych, wygodnym wzorem jest przyjęcie dwuetapowego modelu, w którym nieprzetworzone dane są umieszczane bezpośrednio w zestawie tabel, a drugie zadanie przetwarza te dane w „czystsze” tabele.

potraktuj te czystsze tabele jako okazję do stworzenia wyselekcjonowanego widoku Twojej firmy. Dla każdego z kluczowych podmiotów w Firmie należy utworzyć i utworzyć tabelę ze wszystkimi metrykami / wskaźnikami KPI i wymiarami, których często używasz do analizy tego podmiotu. Na przykład tabela” użytkownicy ” może zawierać metryki, takie jak czas rejestracji, liczba zakupów i wymiary, takie jak lokalizacja geograficzna lub kanał pozyskiwania.

pod koniec tego wszystkiego twoja Infrastruktura powinna wyglądać mniej więcej tak:

Etap 2: potok danych „medium”

🚀 Etap 3: Rosnąc

z odpowiednimi fundamentami, dalszy wzrost nie musi być bolesny. Często można zrobić po prostu rzucając sprzęt na problem obsługi zwiększonej ilości danych.

najtrudniejszymi problemami w tym okresie są często nie tylko skala surowa, ale rosnące wymagania. Być może potrzebujesz na przykład obsługi testów A/B, trenowania modeli uczenia maszynowego lub przekształcania danych w klaster ElasticSearch.

kilka rzeczy, które warto rozważyć w tej fazie:

  • prawie w czasie rzeczywistym: Prawdopodobnie nie będziesz potrzebował rozproszonej kolejki lub infrastruktury w czasie zbliżonym do rzeczywistego, dopóki nie będzie to znacznie później, niż mogłoby się wydawać. Ma wiele dodatkowej złożoności, aby poradzić sobie ze wszystkimi możliwymi trybami awarii, co nie jest tego warte na początku. Gdy rachunek ROI ma sens, spróbuj Kafka lub Cloud pub / Sub.
  • skalowalność: w przypadku pojedynczego klastra monolitycznego Spark prawie na pewno napotkasz problemy z konkurencją zasobów. Kiedy to zrobisz, warto zbadać w pełni elastyczne klastry zapłonowe o zasięgu roboczym.
  • Bezpieczeństwo & Audyt: W pewnym momencie możesz chcieć wymusić bardziej szczegółową kontrolę dostępu do danych hurtowni danych. Jeśli korzystasz z BigQuery, możesz zapewnić dostęp do zestawu danych Google Groups i programowo zarządzać tym dostępem za pomocą Deployment Manager. BigQuery zapewnia również dzienniki audytu, aby zrozumieć zapytania użytkowników. Inne narzędzia, takie jak Apache Knox i Apache Sentry, są dostępne dla lokalnych rozwiązań bezpieczeństwa.
  • Testy A/B: W przypadku tworzenia wewnętrznych testów A/B i wspierania eksperymentów, niestety nie ma wielu gotowych rozwiązań. Zbudowanie potoku zadań Spark, które wypełniają tabele w magazynie danych, jest prawdopodobnie najlepszym rozwiązaniem.
  • Uczenie maszynowe: w programie Spark można tworzyć dodatkowe potoki danych w celu ekstrakcji funkcji. W przypadku samych modeli powinieneś ponownie zacząć od małych. Twoje przetworzone funkcje są prawdopodobnie wystarczająco małe, aby zmieścić się na jednej maszynie, więc możesz trenować modele za pomocą scikit-learn lub TensorFlow. Gdy jedna maszyna nie jest już wystarczająca, możesz użyć Spark MLlib lub distributed TensorFlow.

przyszłość

to ekscytujące zobaczyć, jak bardzo ekosystem infrastruktury danych poprawił się w ciągu ostatniej dekady. Przeszliśmy długą drogę od opieki nad klastrami Hadoop i gimnastyki, aby zmusić naszą logikę przetwarzania danych do map i redukcji w niezręcznej Javie. W tamtych czasach budowanie infrastruktury danych przypominało próbę zbudowania wieżowca za pomocą zabawkowego młotka.

Dzisiaj mamy niesamowitą różnorodność narzędzi. Spark wyraźnie dominuje jako zamiennik Hadoop MapReduce; to samo zaczyna się dziać z TensorFlow jako platformą uczenia maszynowego. Z nielicznymi wyjątkami w dzisiejszych czasach nie trzeba budować infrastruktury ani narzędzi od zera we własnym zakresie i prawdopodobnie nie trzeba zarządzać serwerami fizycznymi. Wieżowiec już tam jest, wystarczy wybrać kolory farb.

przyszłość bezserwerowa-będzie zupełnie tak

patrząc w przyszłość, oczekuję, że infrastruktura danych i narzędzia będą nadal podążać w kierunku platform całkowicie bezserwerowych-DataBricks właśnie ogłosił taką ofertę dla Spark. Infrastruktura bezserwerowa pozwala na eleganckie oddzielenie problemów: dostawcy chmury mogą martwić się o sprzęt, devops i narzędzia, umożliwiając inżynierom skupienie się na problemach, które są unikalne dla ich firm (i dostosowane do nich). Przyszłość jest taka bez awarii sprzętu, dziwactw ZooKeeper, czy problemów z kontentowaniem zasobów przędzy, a to jest naprawdę fajne.

Edit: dodawanie linków do niektórych poprzednich postów, które pisałem o infrastrukturze danych Thumbtacka:

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

lg