I løpet av de siste årene har jeg hatt mange samtaler med venner og kolleger frustrert over hvor inscrutably komplisert datainfrastrukturøkosystemet er. Selv om ikke fullt så ille som front-end verden, ting endrer seg raskt nok til å skape et buzzword suppe.

som nybegynner er det super utfordrende å bestemme hvilke verktøy som passer for deg. Apache Foundation lister 38 prosjekter i» Big Data » – delen, og disse verktøyene har tonnevis av overlapping på problemene de hevder å adressere. For eksempel Er Flink, Samza, Storm og Spark Streaming «distribuerte strømbehandlingsmotorer», Apex og Beam «forene strøm og batchbehandling».

i dette innlegget håper jeg å gi litt hjelp til å navigere alternativene som du satte ut for å bygge datainfrastruktur. Dette er omtrent trinnene jeg vil følge i dag, basert på mine erfaringer det siste tiåret og på samtaler med kolleger som arbeider i dette rommet.

I starten av prosjektet, du sannsynligvis setter ut med noe mer enn et mål om «få innsikt fra mine data» i hånden. Kartlegging av dette til bestemte sett med teknologier er ekstremt skremmende. Du har sannsynligvis ikke en god følelse for hvilke verktøy som er populære, hva» stream «eller» batch » betyr, eller om du selv trenger datainfrastruktur i det hele tatt.

i dette innlegget håper jeg å gi litt veiledning for å hjelpe deg med å komme raskt fra bakken og trekke ut verdi fra dataene dine. Jeg tror sterkt på å holde ting enkelt så lenge som mulig, og introduserer kompleksitet bare når det er nødvendig for skalerbarhet. Dette innlegget følger den buen over tre stadier. På mange måter går det tilbake til trinnene med å bygge datainfrastruktur som jeg har fulgt de siste årene.

Merk at det ikke er noen riktig måte å arkitekt data infrastruktur. For ekspertene som leser dette, kan du ha foretrukne alternativer til løsningene som foreslås her. Det er fantastisk, og fremhever mangfoldet av fantastiske verktøy vi har i disse dager. Vi har kommet veldig langt fra Da Hadoop MapReduce var alt vi hadde.

så her er tingen: du har sannsynligvis ikke «store data» ennå. Nesten 4 år senere, Chris Stucchio ‘ s 2013 artikkel Ikke Bruk Hadoop er fortsatt på punkt. Hvis du har mindre enn 5 TB med data, start små. Dette vil spare deg operasjonelle hodepine med å opprettholde systemer du ikke trenger ennå. Men hei, hvis du elsker 3am brannøvelser fra jobbfeil, vær så snill å hoppe over denne delen…

ellers, hold deg unna alle buzzword-teknologiene i starten, og fokuser på to ting: (1) gjør dataene dine spørrende i SQL, og (2) velg ET BI-Verktøy. Disse vil være «Hei, Verden» ryggraden for all din fremtidige datainfrastruktur.

Alt I SQL

Dette er veldig viktig, Fordi det låser opp data for hele organisasjonen. Med sjeldne unntak for de mest modige markedsføringsfolkene, vil du aldri overbevise dine ikke-tekniske kolleger om å lære Kibana, gripe noen logger eller bruke den obskure syntaksen til NoSQL datastore.

Å Gi SQL-tilgang gjør at hele selskapet kan bli selvbetjente analytikere, og få ditt allerede strakte ingeniørteam ut av den kritiske banen. Det gjør også alle til et gratis QA-team for dataene dine. «Hei, disse tallene ser litt rart ut…» er uvurderlig for å finne feil i dataene dine og til og med i produktet ditt.

hvis din primære datalager er en relasjonsdatabase Som PostgreSQL eller MySQL, er dette veldig enkelt. Du kan bare sette opp en lesekopi, provisjonstilgang, og du er klar.

med En nosql-database som ElasticSearch, MongoDB eller DynamoDB, må du gjøre mer arbeid for å konvertere dataene dine og sette den i EN SQL-database. Hvis du er ny i dataverdenen, kaller vi dette en ETL-rørledning. Unngå å bygge dette selv hvis mulig, som kabling opp en off-the-sokkel løsning vil være mye billigere med små datamengder. Avhengig av din eksisterende infrastruktur, kan det være en sky ETL-leverandør Som Segment som du kan utnytte.

hvis du finner ut at du trenger å bygge dine egne datasamlebånd, må du først holde dem svært enkle. Skriv et skript for å jevne dumpe oppdateringer fra databasen og skrive dem et sted spørres MED SQL.

historien for ETLing-data fra 3. partskilder er lik Som Med NoSQL-databaser. Bruk en ETL-as-a-service provider eller skriv et enkelt skript og bare sett inn dataene dine i EN SQL-spørringsbar database.

Sett opp en maskin for å kjøre ETL-skriptet(e) som en daglig cron, og du er av til løpene.

BI Tool

et godt bi-verktøy er en viktig del av forståelsen av dataene dine. Noen gode verktøy å vurdere Er Chartio, Mode Analytics Og Periscope Data-noen av disse bør fungere bra for å få analysene dine fra bakken. I de fleste tilfeller kan du peke disse verktøyene direkte på SQL-databasen med en rask konfigurasjon og dykke rett inn i å lage dashbord.

Trekker alt sammen, her Er» Hei, Verden » av datainfrastruktur:

Stage 1:» Hello, World «small data pipeline

Stage 2: la oss kalle det» medium » data

På dette punktet har du mer enn noen få terabyte flyter rundt, og cron + script ETL holder ikke helt opp. Kanskje du har proliferated datastores og har en heterogen blanding AV SQL og NoSQL backends. Du kan også nå ha en håndfull tredjeparter du samler data fra. Til slutt kan du begynne å ha flere stadier i ETL-rørledningene dine med noen avhengigheter mellom trinnene.

Arbeidsflytbehandling & Automatisering

det første trinnet i denne fasen bør være å sette Opp Luftstrøm for å administrere ETL-rørledninger. Airflow vil gjøre deg i stand til å planlegge jobber med jevne mellomrom og uttrykke både timelige og logiske avhengigheter mellom jobbene. Det er også et flott sted i infrastrukturen for å legge til jobbforsøk, overvåking & varsling for oppgavefeil. Det er en løpende vits at hver oppstart over en viss størrelse skriver sin egen arbeidsflytleder / jobbplanlegger. Blant Annet Skrev Spotify Luigi, Og Pinterest skrev Pinball. Disse har imidlertid mindre fart i samfunnet og mangler noen funksjoner med Hensyn Til Luftstrøm.

Bygg ETL-Rørledninger

etter hvert som virksomheten din vokser, vil KRAVENE til ETL-rørledninger endres betydelig. Du må begynne å bygge mer skalerbar infrastruktur fordi et enkelt skript ikke vil kutte det lenger. Målene dine er også sannsynlig å utvide fra bare å aktivere SQL-tilgang til å omfatte støtte andre nedstrøms jobber som behandler de samme dataene.

til slutt vil enkle rørledninger ikke skalere

for å løse disse endrede kravene, vil du konvertere ETL-skriptene dine til å kjøre som en distribuert jobb på en klynge. Antallet mulige løsninger her er helt overveldende. Jeg vil sterkt anbefale å starte Med Apache Spark. Spark har et stort, veldig aktivt samfunn, skalerer godt,og er ganske enkelt å komme raskt i gang. PÅ AWS kan du kjøre Spark ved HJELP AV EPJ; FOR GCP, ved Hjelp Av Cloud Dataproc. Hvis du inntar data fra en relasjonsdatabase, Er Apache Sqoop ganske mye standarden.

PÅ dette tidspunktet vil ETL-infrastrukturen din begynne å se ut som pipelinede stadier av jobber som implementerer de tre ETL-verbene: trekk ut data fra kilder, forvandle dataene til standardiserte formater på vedvarende lagring, og last den inn i EN SQL-spørringsbar datastore.

Datavarehus

på dette stadiet vil alle dataene dine i SQL forbli en prioritet, men dette er tiden da du vil begynne å bygge ut et «ekte» datalager.

for de som nettopp har startet, vil jeg anbefale Å bruke BigQuery. BigQuery er enkelt å sette opp (du kan bare laste inn poster SOM JSON), støtter nestede / komplekse datatyper,og er fullstendig administrert / serverløs, slik at du ikke har mer infrastruktur å vedlikeholde. Som med mange av anbefalingene her, er alternativer Til BigQuery tilgjengelige: PÅ AWS, Redshift og on-prem, Presto. Jeg har en sterk preferanse For BigQuery over Redshift på grunn av sin serverløse design, enkel konfigurering av riktig sikkerhet/revisjon og støtte for komplekse typer. Presto er verdt å vurdere om du har et hardt krav til on-prem.

når du tenker på å sette opp datalageret ditt, er et praktisk mønster å vedta en 2-trinns modell, hvor ubehandlede data landes direkte i et sett med tabeller, og en annen jobb etterbehandler disse dataene i» renere » tabeller.

Behandle disse ryddingstabellene som en mulighet til å lage en kuratert visning i virksomheten din. For hver av de viktigste enhetene i bedriften, bør du opprette og kuratere en tabell med alle beregninger/Kpier og dimensjoner som du ofte bruker til å analysere denne enheten. En «brukere» – tabell kan for eksempel inneholde beregninger som registreringstid, antall kjøp og dimensjoner som geografisk plassering eller oppkjøpskanal.

på slutten av alt dette bør infrastrukturen din se slik ut:

Trinn 2:» medium » data pipeline

🚀 Trinn 3: Å gå stort

med de riktige fundamentene, trenger ikke videre vekst å være smertefullt. Du kan ofte gjøre bare ved å kaste maskinvare på problemet med å håndtere økte datamengder.

de mest utfordrende problemene i denne perioden er ofte ikke bare rå skala, men utvide krav. For eksempel, kanskje du trenger å støtte A / B-testing, trene maskinlæringsmodeller eller rørtransformerte data til En ElasticSearch-klynge.

Noen ting du kanskje vil vurdere i denne fasen:

  • Nær-Realtime: Du trenger sannsynligvis ikke en distribuert kø eller nær sanntid infrastruktur til mye senere enn du kanskje tror. Den leveres med mye ekstra kompleksitet for å håndtere alle mulige feilmoduser, noe som ikke er verdt det tidlig. NÅR ROI kalkulus er fornuftig, prøv Kafka eller Cloud Pub / Sub.
  • Skalerbarhet: med en enkelt monolitisk Gnistklynge vil du nesten helt sikkert få problemer med ressurskonflikt. Når du gjør det, er fullt elastiske jobb-scoped Gnistklynger verdt å utforske.
  • Sikkerhet & Overvåking: På et tidspunkt vil du kanskje håndheve mer granulære tilgangskontroller til datalagerdataene dine. Hvis Du bruker BigQuery, kan Du klargjøre datasetttilgang Til Google Grupper, og programmatisk administrere denne tilgangen ved Hjelp Av Deployment Manager. BigQuery gir også revisjonslogger for å forstå brukerforespørsler. Andre verktøy som Apache Knox og Apache Sentry er tilgjengelig for on-prem sikkerhetsløsninger.
  • A / B-Testing: for å bygge In-house a / B-testing og støtte eksperimentering, er det dessverre ikke mange hyllevare løsninger. Å bygge En rørledning Av Gnistjobber som fyller tabeller i datalageret ditt, er sannsynligvis det beste alternativet.
  • Maskinlæring: for funksjonsutvinning kan du bygge flere datasamlebånd i Spark. For modellene selv, bør du igjen starte små. Dine behandlede funksjoner er sannsynligvis små nok til å passe på en maskin, slik at du kan trene modeller ved hjelp av scikit-learn eller TensorFlow. Nar en maskin ikke lenger er nok, kan du bruke Spark MLlib eller distribuert TensorFlow.

fremtiden

det er spennende å se hvor mye datainfrastrukturens økosystem har forbedret seg det siste tiåret. Vi har kommet langt fra barnevakt Hadoop klynger og gymnastikk for å tvinge vår databehandling logikk i kart og reduserer i klosset Java. På den tiden føltes det som å bygge datainfrastruktur som å prøve å bygge en skyskraper ved hjelp av en lekehammer.

I Dag har vi et utrolig mangfold av verktøy. Spark har klart dominert som jack-of-all-trades erstatning Til Hadoop MapReduce; Det samme begynner å skje Med TensorFlow som en maskinlæringsplattform. Med svært få unntak trenger du ikke å bygge infrastruktur eller verktøy fra bunnen av internt i disse dager, og du trenger sannsynligvis ikke å administrere fysiske servere. Skyskraperen er allerede der, du trenger bare å velge maling farger.

den serverløse fremtiden — Det vil helt være som dette

Ser fremover, jeg forventer at datainfrastruktur og verktøy fortsetter å bevege seg mot helt serverløse plattformer-DataBricks annonserte nettopp et slikt tilbud For Spark. Serverløs infrastruktur tillater en elegant adskillelse av bekymringer: skyleverandørene kan bekymre seg for maskinvare, devops og verktøy, slik at ingeniører kan fokusere på problemene som er unike for (og tilpasset) deres virksomheter. Fremtiden er en uten maskinvarefeil, ZooKeeper freakouts, eller problemer MED GARN ressurs påstand, og det er veldig kult.

Rediger: legge til lenker til noen tidligere innlegg jeg skrev om Thumbtacks datainfrastruktur:

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.

lg