i løbet af de sidste par år har jeg haft mange samtaler med venner og kolleger frustreret over, hvor ubeskriveligt komplekst datainfrastrukturøkosystemet er. Selvom det ikke er så slemt som Frontend-verdenen, ændrer tingene sig hurtigt nok til at skabe en modordssuppe.

som nybegynder er det super udfordrende at beslutte, hvilke værktøjer der passer til dig. Apache Foundation lister 38 projekter i afsnittet” Big Data”, og disse værktøjer har masser af overlapning på de problemer, de hævder at løse. For eksempel er flink, Storm og Spark Streaming “distribuerede stream processing motorer”, spids og stråle “unify stream og batch processing”.

i dette indlæg håber jeg at give noget hjælp til at navigere i indstillingerne, som du satte ud for at opbygge datainfrastruktur. Dette er omtrent de trin, jeg ville følge i dag, baseret på mine erfaringer i det sidste årti og på samtaler med kolleger, der arbejder i dette rum.

i starten af dit projekt går du sandsynligvis ud med intet andet end et mål om “få indsigt fra mine data” i hånden. Kortlægning dette til specifikke sæt af teknologier er ekstremt skræmmende. Du har sandsynligvis ikke en god fornemmelse for, hvilke værktøjer der er populære, hvad “stream” eller “batch” betyder, eller om du overhovedet har brug for datainfrastruktur.

i dette indlæg håber jeg at give nogle vejledninger til at hjælpe dig med at komme hurtigt af jorden og udtrække værdi fra dine data. Jeg tror stærkt på at holde tingene enkle så længe som muligt og kun indføre kompleksitet, når det er nødvendigt for skalerbarhed. Dette indlæg følger denne bue på tværs af tre faser. På mange måder trækker det tilbage trinene til opbygning af datainfrastruktur, som jeg har fulgt i løbet af de sidste par år.

Bemærk, at der ikke er nogen rigtig måde at arkitekt datainfrastruktur på. For de eksperter, der læser dette, har du måske foretrukket alternativer til de løsninger, der foreslås her. Det er fantastisk, og fremhæver mangfoldigheden af fantastiske værktøjer, vi har i disse dage. Vi er kommet meget langt fra, Da Hadoop MapReduce var alt, hvad vi havde.

så her er sagen: du har sandsynligvis ikke “big data” endnu. Næsten 4 år senere, Chris Stucchios artikel fra 2013 brug ikke Hadoop er stadig på punkt. Hvis du har mindre end 5 TB data, skal du starte i det små. Dette vil spare dig operationelle hovedpine med vedligeholdelse af systemer, du ikke har brug for endnu. Men hej, hvis du elsker 3am brandøvelser fra jobfejl, er du velkommen til at springe dette afsnit over…

ellers skal du holde dig væk fra alle modordsteknologierne i starten og fokusere på to ting: (1) Gør dine data forespørgselsbare i KVM, og (2) vælge et BI-værktøj. Disse vil være” Hej, Verden ” rygraden for al din fremtidige datainfrastruktur.

alt i KVL

dette er virkelig vigtigt, fordi det låser op for data for hele organisationen. Med sjældne undtagelser for de mest frygtløse marketingfolk, vil du aldrig overbevise dine ikke-tekniske kolleger om at lære Kibana, grep nogle logfiler eller at bruge den uklare syntaks i din Noskl datastore.

ved at give os adgang, kan hele virksomheden blive selvbetjeningsanalytikere og få dit allerede strakte ingeniørteam ud af den kritiske vej. Det gør også alle til et gratis KVALITETSSIKRINGSTEAM til dine data. “Hej, disse tal ser lidt underlige ud…” er uvurderlig for at finde fejl i dine data og endda i dit produkt.

hvis din primære datalager er en relationsdatabase som f.eks. Du kan bare oprette en read replika, bestemmelse adgang, og du er alle indstillet.

med en Noskl-database som ElasticSearch, MongoDB eller DynamoDB skal du gøre mere arbejde for at konvertere dine data og sætte dem i en database. Hvis du er ny i dataverdenen, kalder vi dette en ETL-pipeline. Undgå at opbygge dette selv, hvis det er muligt, da det vil være meget billigere at tilslutte en off-the-shelf-løsning med små datamængder. Afhængigt af din eksisterende infrastruktur kan der være en cloud ETL-udbyder som Segment, som du kan udnytte.

hvis du finder ud af, at du har brug for at bygge dine egne datarørledninger, skal du først holde dem ekstremt enkle. Skriv et script for regelmæssigt at dumpe opdateringer fra din database og skriv dem et eller andet sted, der kan anmodes om.

historien om ETLing-data fra 3.parts kilder er den samme som med Noskl-databaser. Brug en ETL-as-a-service-udbyder, eller skriv et simpelt script, og indsæt bare dine data i en database, der kan anmodes om.

Opsæt en maskine til at køre dit ETL script(er) som en daglig cron, og du er ude til løbene.

BI værktøj

et godt BI værktøj er en vigtig del af forståelsen af dine data. Nogle gode værktøjer at overveje er Chartio, Mode Analytics og Periscope Data — en af disse skal fungere godt for at få din analyse fra jorden. I de fleste tilfælde kan du pege disse værktøjer direkte på din database med en hurtig konfiguration og dykke lige ind i at oprette dashboards.

træk det hele sammen, her er” Hej, Verden ” af datainfrastruktur:

Trin 1: “Hej, Verden” lille data pipeline

Trin 2: Lad os kalde det “medium” data

på dette tidspunkt har du mere end et par terabyte, der flyder rundt, og din cron+script ETL holder ikke helt op. Måske har du spredt datastores og har en heterogen blanding af backends. Du kan også nu have en håndfuld tredjeparter, du indsamler data fra. Endelig begynder du muligvis at have flere faser i dine ETL-rørledninger med nogle afhængigheder mellem trin.

styring af arbejdsgange& automatisering

dit første skridt i denne fase skal være at indstille luftstrømmen til at styre dine ETL-rørledninger. Luftstrøm giver dig mulighed for at planlægge job med jævne mellemrum og udtrykke både tidsmæssige og logiske afhængigheder mellem job. Det er også et godt sted i din infrastruktur til at tilføje job forsøg, overvågning & advare for opgavefejl. Det er en løbende vittighed, at hver opstart over en vis størrelse skriver deres egen arbejdsgangsleder / jobplanlægger. Blandt andet skrev Spotify Luigi, og Pinterest skrev Pinball. Disse har dog mindre fart i samfundet og mangler nogle funktioner med hensyn til luftstrøm.

opbygning af ETL-rørledninger

efterhånden som din virksomhed vokser, vil dine ETL-rørledningskrav ændre sig markant. Du bliver nødt til at begynde at opbygge mere skalerbar infrastruktur, fordi et enkelt script ikke klipper det længere. Dine mål vil sandsynligvis også udvide sig fra blot at gøre det muligt for os at omfatte understøttelse af andre nedstrøms job, der behandler de samme data.

til sidst vil simple pipelines ikke skalere

for at løse disse skiftende krav skal du konvertere dine ETL-scripts til at køre som et distribueret job på en klynge. Antallet af mulige løsninger her er absolut overvældende. Jeg vil stærkt anbefale at starte med Apache Spark. Spark har en enorm, meget aktivt samfund, skalerer godt, og er ret let at komme i gang hurtigt. Du kan køre Spark ved hjælp af EMR; til GCP, ved hjælp af Cloud Dataproc. Hvis du indtager data fra en relationsdatabase, er Apache Scoop stort set standarden.

på dette tidspunkt vil din ETL-infrastruktur begynde at ligne pipelined faser af job, der implementerer de tre ETL verber: udtrække data fra kilder, omdanne disse data til standardiserede formater på vedvarende opbevaring, og indlæse den i en KVM-forespørgsel datalager.

datalager

på dette tidspunkt vil det fortsat være en prioritet at få alle dine data til at blive en prioritet, men det er det tidspunkt, hvor du vil begynde at opbygge et “rigtigt” datalager.

for dem, der lige er startet, vil jeg anbefale at bruge Storforespørgsel. Storforespørgsel er let at konfigurere (du kan bare indlæse poster som JSON), understøtter indlejrede/komplekse datatyper og er fuldt administreret/serverløs, så du ikke har mere infrastruktur at vedligeholde. Som med mange af anbefalingerne her, alternativer til Storforespørgsel er tilgængelige: på Ave, Redshift, og on-prem, Presto. Jeg har en stærk præference for Storforespørgsel over Redshift på grund af dets serverløse design, enkelhed ved at konfigurere korrekt sikkerhed/revision og støtte til komplekse typer. Presto er værd at overveje, hvis du har et hårdt krav til on-prem.

når du overvejer at oprette dit datalager, er et praktisk mønster at vedtage en 2-trins model, hvor uforarbejdede data landes direkte i et sæt tabeller, og et andet job efter-behandler disse data i “renere” tabeller.

behandl disse renere tabeller som en mulighed for at skabe en kurateret visning i din virksomhed. For hver af de vigtigste enheder i din virksomhed skal du oprette og kuratere en tabel med alle de metrics/KPI ‘ er og dimensioner, som du ofte bruger til at analysere den pågældende enhed. For eksempel kan en” brugere ” – tabel indeholde metrics som tilmeldingstid, antal køb og dimensioner som Geografisk placering eller anskaffelseskanal.

i slutningen af alt dette skal din infrastruktur se sådan ud:

Trin 2:” medium ” data pipeline

🚀 Trin 3: Går stort

med de rigtige fundamenter behøver yderligere vækst ikke at være smertefuld. Du kan ofte gøre gør blot ved at kaste isenkram på problemet med håndtering af øgede datamængder.

de mest udfordrende problemer i denne periode er ofte ikke kun rå skala, men ekspanderende krav. For eksempel skal du måske understøtte A/B-test, træne maskinindlæringsmodeller eller røromdannede data til en ElasticSearch-klynge.

nogle ting, du måske vil overveje i denne fase:

  • nær-Realtime: Du har sandsynligvis ikke brug for en distribueret kø eller næsten realtidsinfrastruktur før meget senere, end du måske tror. Det kommer med en masse ekstra kompleksitet til at håndtere alle mulige fejltilstande, hvilket ikke er det værd tidligt. Når ROI calculus giver mening, prøv Kafka eller Cloud Pub/Sub.
  • skalerbarhed: med en enkelt monolitisk Gnistklynge vil du næsten helt sikkert løbe ind i problemer med ressourcekonflikt. Når du gør det, er fuldt elastiske job-scoped Gnistklynger værd at udforske.
  • Sikkerhed & Revision: På et tidspunkt vil du måske håndhæve mere detaljerede adgangskontroller til dine datalagerdata. Hvis du bruger Storforespørgsel, kan du angive datasætadgang til Google-Grupper og programmatisk administrere denne Adgang ved hjælp af Deployment Manager. Bigforespørgsel giver også revisionslogfiler for at forstå brugerforespørgsler. Andre værktøjer som Apache Sentry og Apache Sentry er tilgængelige for on-prem sikkerhedsløsninger.
  • A/B-test: til opbygning af In-house A/B-test og understøttende eksperimenter er der desværre ikke mange off-the-shelf-løsninger. Opbygning af en pipeline af Gnistjob, der udfylder tabeller i dit datalager, er sandsynligvis din bedste indsats.
  • maskinindlæring: til funktionsekstraktion kan du bygge yderligere datarørledninger i Spark. For modellerne selv skal du igen starte små. Dine behandlede funktioner er sandsynligvis små nok til at passe på en maskine, så du kan træne Modeller ved hjælp af scikit-learn eller Tensorstrøm. Når en maskine ikke længere er nok, kan du bruge Spark MLlib eller distribueret Tensorstrøm.

fremtiden

det er spændende at se, hvor meget datainfrastrukturøkosystemet er forbedret i løbet af det sidste årti. Vi er kommet langt fra børnepasning af Hadoop-klynger og gymnastik for at tvinge vores databehandlingslogik til kort og reducerer i akavet Java. Dengang følte bygningsdatainfrastruktur sig som at forsøge at bygge en skyskraber ved hjælp af en legetøjshammer.

i dag har vi en fantastisk mangfoldighed af værktøjer. Spark har klart domineret som jack-of-all-trades erstatning til Hadoop MapReduce; det samme er begyndt at ske med Tensorstrøm som en machine learning platform. Med meget få undtagelser behøver du ikke at opbygge infrastruktur eller værktøjer fra bunden internt i disse dage, og du behøver sandsynligvis ikke at administrere fysiske servere. Skyskraberen er allerede der, du skal bare vælge dine malingsfarver.

den serverløse fremtid-det vil helt være sådan her

når jeg ser fremad, forventer jeg, at datainfrastruktur og værktøjer fortsætter med at bevæge sig mod helt serverløse platforme — DataBricks annoncerede netop et sådant tilbud til Spark. Serverløs infrastruktur tillader en elegant adskillelse af bekymringer: cloud-udbydere kan bekymre sig om udstyr, devops og værktøj, så ingeniører kan fokusere på de problemer, der er unikke for (og tilpasset) deres virksomheder. Fremtiden er en uden maskinfejl, dyrepasserfreakouts eller problemer med GARNRESSOURCEKONFLIKT, og det er virkelig sejt.

Rediger: tilføjelse af links til nogle tidligere indlæg Jeg skrev om thumbtacks data infrastructure:

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.

lg