în ultimii ani, am avut multe conversații cu prietenii și colegii frustrați de cât de incredibil de complex este ecosistemul infrastructurii de date. Deși nu este la fel de rău ca lumea front-end, lucrurile se schimbă suficient de repede pentru a crea o supă buzzword.

ca începător, este foarte dificil să decideți ce instrumente sunt potrivite pentru dvs. Fundația Apache listează 38 de proiecte în secțiunea” Big Data”, iar aceste instrumente au o mulțime de suprapuneri asupra problemelor pe care pretind că le abordează. De exemplu, Flink, Samza, Storm și Spark Streaming sunt „motoare de procesare a fluxului distribuit”, Apex și Beam „unifică fluxul și procesarea lotului”.

în această postare, sper să vă ofer ajutor în navigarea opțiunilor pe măsură ce v-ați propus să construiți infrastructura de date. Acestea sunt aproximativ pașii pe care i-aș urma astăzi, pe baza experiențelor mele din ultimul deceniu și a conversațiilor cu colegii care lucrează în acest spațiu.

la începutul proiectului dvs., probabil că vă stabiliți cu nimic mai mult decât un obiectiv de „obțineți informații din datele mele” în mână. Maparea acestui set specific de tehnologii este extrem de descurajantă. Probabil că nu aveți un mare simț pentru ce instrumente sunt populare, ce înseamnă „flux” sau „lot” sau dacă aveți nevoie chiar de infrastructură de date.

în acest post, sper să ofere unele îndrumări pentru a vă ajuta să obțineți de la sol rapid și extrage valoarea din datele dumneavoastră. Cred cu tărie în menținerea lucrurilor simple cât mai mult timp posibil, introducând complexitatea numai atunci când este nevoie pentru scalabilitate. Acest post urmează că arc peste trei etape. În multe privințe, acesta reia pașii de construire a infrastructurii de date pe care I-am urmat în ultimii ani.

rețineți că nu există o modalitate corectă de a arhitect infrastructura de date. Pentru experții care citesc acest lucru, este posibil să fi preferat alternative la soluțiile sugerate aici. Este fantastic și evidențiază diversitatea instrumentelor uimitoare pe care le avem în aceste zile. Am parcurs un drum foarte lung de când Hadoop MapReduce a fost tot ce am avut.

deci, iată chestia: probabil că nu aveți încă „date mari”. Aproape 4 ani mai târziu, articolul lui Chris Stucchio din 2013 nu folosiți Hadoop este încă la punct. Dacă aveți mai puțin de 5 TB de date, începeți mic. Acest lucru vă va salva durerile de cap operaționale cu menținerea sistemelor de care nu aveți nevoie încă. Dar hei, dacă vă place 3am exerciții de foc de eșecuri de locuri de muncă, nu ezitați să săriți peste această secțiune…

în caz contrar, stai departe de toate tehnologiile buzzword la început, și să se concentreze pe două lucruri: (1) a face datele interogabil în SQL, și (2) Alegerea unui instrument de BI. Acestea vor fi coloana vertebrală” Bună ziua, lume ” pentru toată infrastructura de date viitoare.

totul în SQL

acest lucru este foarte important, deoarece deblochează date pentru întreaga organizație. Cu excepții rare pentru cei mai îndrăzneți oameni de marketing, nu veți convinge niciodată colegii dvs. non-tehnici să învețe Kibana, să grepeze câteva jurnale sau să utilizeze sintaxa obscură a magazinului dvs. de date NoSQL.

furnizarea accesului SQL permite întregii companii să devină analiști de auto-servire, scoțând echipa dvs. de inginerie deja întinsă din calea critică. De asemenea, transformă toată lumea într-o echipă QA gratuită pentru datele dvs. „Hei, aceste numere arată cam ciudat …” este de neprețuit pentru a găsi erori în datele dvs. și chiar în produsul dvs.

dacă magazinul dvs. de date primar este o bază de date relațională, cum ar fi PostgreSQL sau MySQL, acest lucru este foarte simplu. Puteți configura doar o replică de citire, acces la dispoziție și sunteți gata.

cu o bază de date NoSQL ca ElasticSearch, MongoDB, sau DynamoDB, va trebui să facă mai mult de lucru pentru a converti datele și pune-l într-o bază de date SQL. Dacă sunteți nou în lumea datelor, numim aceasta o conductă ETL. Evitați să construiți singur acest lucru, dacă este posibil, deoarece cablarea unei soluții off-the-shelf va fi mult mai puțin costisitoare cu volume mici de date. În funcție de infrastructura existentă, poate exista un furnizor de cloud ETL ca Segment pe care îl puteți utiliza.

dacă descoperiți că aveți nevoie pentru a construi propriile conducte de date, păstrați-le extrem de simplu la început. Scrieți un script pentru a descărca periodic actualizări din Baza de date și scrieți-le undeva interogabil cu SQL.

povestea pentru ETLing date din surse 3rd party este similar cu bazele de date NoSQL. Utilizați un furnizor ETL-as-a-service sau scrie un script simplu și doar depune datele într-o bază de date SQL-queryable.

Configurarea o mașină pentru a rula script-UL ETL(e) ca un cron de zi cu zi, și sunteți pe la curse.

instrument BI

un instrument BI bun este o parte importantă a înțelegerii datelor dvs. Unele instrumente excelente de luat în considerare sunt Chartio, Mode Analytics și Periscope Data — oricare dintre acestea ar trebui să funcționeze excelent pentru a vă scoate analizele. În cele mai multe cazuri, puteți indica aceste instrumente direct la baza de date SQL cu o configurație rapidă și se arunca cu capul chiar în crearea de tablouri de bord.

trăgând toate acestea împreună, iată” Bună ziua, lumea ” infrastructurii de date:

Etapa 1:” Bună ziua, lume „conducta de date mici

Etapa 2: să-l numim” mediu ” de date

în acest moment, le-ați luat mai mult de câteva terabytes plutesc în jurul, și cron+script ETL nu este destul de ține pasul. Poate că ați proliferat datastores și au un amestec eterogen de backend SQL și NoSQL. De asemenea, este posibil să aveți acum o mână de terțe părți de la care colectați date. În cele din urmă, este posibil să începeți să aveți mai multe etape în conductele ETL cu unele dependențe între pași.

managementul fluxului de lucru& automatizare

primul pas în această fază ar trebui să fie configurarea fluxului de aer pentru a gestiona conductele ETL. Airflow vă va permite să programați lucrări la intervale regulate și să exprimați atât dependențe temporale, cât și logice între lucrări. Este, de asemenea, un loc minunat în infrastructura dvs. pentru a adăuga reîncercări de locuri de muncă, monitorizând & alertarea pentru eșecurile sarcinilor. Este o glumă care rulează că fiecare pornire peste o anumită dimensiune își scrie propriul manager de flux de lucru / planificator de locuri de muncă. Printre altele, Spotify a scris Luigi, iar Pinterest a scris Pinball. Cu toate acestea, acestea au un impuls mai mic în comunitate și nu au unele caracteristici în ceea ce privește fluxul de aer.

construirea conductelor ETL

pe măsură ce afacerea dvs. crește, cerințele dvs. de conducte ETL se vor schimba semnificativ. Va trebui să începeți să construiți o infrastructură mai scalabilă, deoarece un singur script nu o va mai tăia. Obiectivele dvs. sunt, de asemenea, susceptibile de a se extinde de la simpla activare a accesului SQL pentru a include sprijinirea altor locuri de muncă din aval care procesează aceleași date.

în cele din urmă, conductele simple nu vor scala

pentru a aborda aceste cerințe în schimbare, veți dori să convertiți scripturile ETL pentru a rula ca o lucrare distribuită pe un cluster. Numărul de soluții posibile aici este absolut copleșitor. Aș recomanda cu tărie să începeți cu Apache Spark. Spark are o comunitate uriașă, foarte activă, se scalează bine și este destul de ușor să te ridici și să alergi rapid. Pe AWS, puteți rula Spark folosind EMR; pentru GCP, folosind Cloud Dataproc. Dacă ingerați date dintr-o bază de date relațională, Apache sqoop este destul de mult standardul.

în acest moment, infrastructura ETL va începe să arate ca etape pipeline de locuri de muncă care să pună în aplicare cele trei verbe ETL: extrage date din surse, transforma aceste date în formate standardizate pe stocare persistente, și încărcați-l într-un SQL-queryable datastore.

Data Warehouse

în această etapă, obținerea tuturor datelor în SQL va rămâne o prioritate, dar acesta este momentul în care veți dori să începeți să construiți un depozit de date „real”.

pentru cei care abia încep, aș recomanda utilizarea BigQuery. BigQuery este ușor de configurat (puteți încărca doar înregistrări ca JSON), acceptă tipuri de date imbricate/complexe și este complet gestionat/fără server, astfel încât să nu aveți mai multă infrastructură de întreținut. Ca și în cazul multor recomandări de aici, sunt disponibile alternative la BigQuery: pe AWS, Redshift și on-prem, Presto. Am o preferință puternică pentru BigQuery față de Redshift datorită designului său fără server, simplității configurării securității/auditului adecvat și suportului pentru tipuri complexe. Presto merită luat în considerare dacă aveți o cerință grea pentru on-prem.

când vă gândiți să vă configurați depozitul de date, un model convenabil este să adoptați un model în 2 etape, în care datele neprelucrate sunt aterizate direct într-un set de tabele, iar un al doilea loc de muncă post-procesează aceste date în tabele „mai curate”.

tratați aceste tabele mai curate ca o oportunitate de a crea o vizualizare curată în afacerea dvs. Pentru fiecare dintre entitățile cheie din afacerea dvs., ar trebui să creați și să organizați un tabel cu toate valorile/indicatorii KPI și parametrii pe care îi utilizați frecvent pentru a analiza entitatea respectivă. De exemplu, un tabel „utilizatori” poate conține valori precum timpul de înscriere, numărul de achiziții și parametri precum locația geografică sau canalul de achiziție.

la sfârșitul tuturor acestor lucruri, infrastructura dvs. ar trebui să arate cam așa:

Etapa 2: conducta de date „medie”

🚀 Etapa 3: Mergând mare

cu fundamentele potrivite, creșterea ulterioară nu trebuie să fie dureroasă. Puteți face de multe ori face pur și simplu prin aruncarea hardware la problema de manipulare a crescut volumele de date.

problemele cele mai dificile în această perioadă sunt de multe ori nu doar la scară brută, dar extinderea cerințelor. De exemplu, poate că trebuie să susțineți testarea A/B, să instruiți modele de învățare automată sau să transformați datele într-un cluster ElasticSearch.

unele lucruri pe care poate doriți să ia în considerare în această fază:

  • aproape în timp real: Probabil că nu veți avea nevoie de o coadă distribuită sau de o infrastructură aproape în timp real decât mult mai târziu decât ați putea crede. Acesta vine cu o mulțime de complexitate adăugată pentru a gestiona toate modurile posibile de eșec, ceea ce nu merită din timp. Odată ce calculul ROI are sens, încercați Kafka sau Cloud Pub/Sub.
  • scalabilitate: cu un singur cluster monolit Spark, aproape sigur veți întâmpina probleme cu disputa resurselor. Când faceți acest lucru, grupurile de scântei complet elastice cu scop de lucru merită explorate.
  • Securitate & Audit: La un moment dat, poate doriți să impuneți controale de acces mai granulare la datele din depozitul de date. Dacă utilizați BigQuery, puteți furniza acces la setul de date la Grupurile Google și puteți gestiona programatic acel acces utilizând Deployment Manager. BigQuery oferă, de asemenea, jurnalele de audit pentru a înțelege interogările utilizatorilor. Alte instrumente precum Apache Knox și Apache Sentry sunt disponibile pentru soluții de securitate on-prem.
  • testarea A/B: pentru construirea testelor A/B interne și sprijinirea experimentării, din păcate, nu există multe soluții disponibile. Construirea unei conducte de locuri de muncă Spark care populează tabele în depozitul dvs. de date este probabil cel mai bun pariu.
  • Machine Learning: pentru extragerea caracteristicilor, puteți construi conducte de date suplimentare în Spark. Pentru modelele în sine, ar trebui să începeți din nou mici. Caracteristicile dvs. procesate sunt probabil suficient de mici pentru a se potrivi pe o singură mașină, astfel încât să puteți antrena modele folosind scikit-learn sau TensorFlow. Când o mașină nu mai este suficientă, puteți utiliza Spark MLlib sau TensorFlow distribuit.

viitorul

este interesant să vedem cât de mult s-a îmbunătățit ecosistemul infrastructurii de date în ultimul deceniu. Am parcurs un drum lung de la babysitting clustere Hadoop și gimnastică pentru a constrânge logica noastră de prelucrare a datelor în Hărți și reduce în Java incomode. Pe atunci, construirea infrastructurii de date părea să încerce să construiască un zgârie-nori folosind un ciocan de jucărie.

astăzi, avem o diversitate uimitoare de instrumente. Spark a dominat în mod clar ca înlocuitor jack-of-all-trades pentru Hadoop MapReduce; același lucru începe să se întâmple cu TensorFlow ca platformă de învățare automată. Cu foarte puține excepții, nu este nevoie să construiți infrastructură sau instrumente de la zero în aceste zile și probabil că nu trebuie să gestionați serverele fizice. Zgârie-nori este deja acolo, trebuie doar să alegeți culorile vopselei.

viitorul fără server — va fi în totalitate așa

privind în perspectivă, mă aștept ca infrastructura și instrumentele de date să continue să se îndrepte către platforme complet fără server — DataBricks tocmai a anunțat o astfel de ofertă pentru Spark. Infrastructura fără server permite o separare elegantă a preocupărilor: furnizorii de cloud se pot îngrijora de hardware, devops și scule, permițând inginerilor să se concentreze asupra problemelor unice (și aliniate cu) afacerile lor. Viitorul este unul fără defecțiuni hardware, freakouts ZooKeeper sau probleme cu disputa resurselor de fire, și asta este foarte cool.

Edit: adăugarea de link-uri la unele posturi anterioare am scris despre infrastructura de date Thumbtack lui:

Lasă un răspuns

Adresa ta de email nu va fi publicată.

lg