under de senaste åren har jag haft många samtal med vänner och kollegor frustrerade över hur otroligt komplicerat datainfrastrukturens ekosystem är. Även om det inte är så illa som front-end-världen, förändras saker tillräckligt snabbt för att skapa en buzzword-soppa.

som nybörjare är det super utmanande att bestämma vilka verktyg som passar dig. Apache Foundation listar 38 projekt i avsnittet ”Big Data”, och dessa verktyg har massor av överlappning på de problem de hävdar att ta itu med. Flink, Samza, Storm och Spark Streaming är till exempel ”distribuerade strömbehandlingsmotorer”, Apex och Beam ”förena ström och batchbehandling”.

i det här inlägget hoppas jag ge lite hjälp med att navigera i alternativen när du bestämmer dig för att bygga datainfrastruktur. Det här är ungefär de steg jag skulle följa idag, baserat på mina erfarenheter under det senaste decenniet och på samtal med kollegor som arbetar i detta utrymme.

i början av ditt projekt ställer du förmodligen ut med inget annat än ett mål om ”få insikter från mina data” i handen. Att kartlägga detta till en specifik uppsättning tekniker är extremt skrämmande. Du har förmodligen inte en bra känsla för vilka verktyg som är populära, vad ”stream” eller ”batch” betyder, eller om du ens behöver datainfrastruktur alls.

i det här inlägget hoppas jag ge lite vägledning för att hjälpa dig att komma igång snabbt och extrahera värde från dina data. Jag tror starkt på att hålla saker enkla så länge som möjligt, introducera komplexitet endast när det behövs för skalbarhet. Detta inlägg följer den bågen över tre steg. På många sätt återvänder det stegen för att bygga datainfrastruktur som jag har följt under de senaste åren.

Observera att det inte finns något rätt sätt att arkitekt datainfrastruktur. För de experter som läser detta kan du ha föredragit alternativ till de lösningar som föreslås här. Det är fantastiskt och belyser mångfalden av fantastiska verktyg vi har idag. Vi har kommit en mycket lång väg från när Hadoop MapReduce var allt vi hade.

så här är saken: du har förmodligen inte ”big data” än. Nästan 4 år senare är Chris Stucchios 2013-artikel Don ’ t use Hadoop fortfarande på punkt. Om du har mindre än 5 TB data, börja små. Detta kommer att spara operativa huvudvärk med att upprätthålla system som du inte behöver ännu. Men hej, om du älskar 3am-brandövningar från jobbfel, hoppa gärna över det här avsnittet…

annars, håll dig borta från alla buzzword-teknologier i början och fokusera på två saker: (1) Gör dina data frågbara i SQL och (2) välja ett BI-verktyg. Dessa kommer att vara ”Hej, värld” ryggraden för all din framtida datainfrastruktur.

allt i SQL

detta är verkligen viktigt, eftersom det låser upp data för hela organisationen. Med sällsynta undantag för de mest otrygga marknadsföringsfolken kommer du aldrig att övertyga dina icke-tekniska kollegor att lära sig Kibana, grep några loggar eller att använda den obskyra syntaxen i din NoSQL datastore.

genom att tillhandahålla SQL-åtkomst kan hela företaget bli självbetjäningsanalytiker och få ditt redan utsträckta ingenjörsteam ur den kritiska vägen. Det gör också alla till ett gratis QA-team för dina data. ”Hej, dessa siffror ser lite konstiga ut…” är ovärderligt för att hitta buggar i dina data och även i din produkt.

om din primära datalager är en relationsdatabas som PostgreSQL eller MySQL, är detta verkligen enkelt. Du kan bara ställa in en läst replika, tillhandahållande tillgång, och du är redo.

med en NoSQL-databas som ElasticSearch, MongoDB eller DynamoDB måste du göra mer arbete för att konvertera dina data och lägga den i en SQL-databas. Om du är ny i datavärlden kallar vi detta en ETL-pipeline. Undvik att bygga detta själv om möjligt, som ledningar upp en off-the-shelf lösning kommer att bli mycket billigare med små datavolymer. Beroende på din befintliga infrastruktur kan det finnas en moln-ETL-leverantör som Segment som du kan utnyttja.

om du upptäcker att du behöver bygga dina egna datapipelines, håll dem extremt enkla först. Skriv ett skript för att regelbundet dumpa uppdateringar från din databas och skriva dem någonstans fråga med SQL.

historien för ETLing-data från 3: e parts källor är liknande som med NoSQL-databaser. Använd en ETL-as-a-service provider eller skriv ett enkelt skript och sätt bara in dina data i en SQL-queryable-databas.

Ställ in en maskin för att köra ditt ETL-skript som en daglig cron, och du är ute till tävlingarna.

BI-verktyg

ett bra BI-verktyg är en viktig del av att förstå dina data. Några bra verktyg att tänka på är Chartio, Mode Analytics och Periscope Data — någon av dessa bör fungera bra för att få din analys från marken. I de flesta fall kan du peka dessa verktyg direkt på din SQL-databas med en snabb konfiguration och dyka rakt in i att skapa instrumentpaneler.

dra allt detta tillsammans, här är” Hej världen ” av datainfrastruktur:

Steg 1:” Hej, värld ”liten datapipeline

steg 2: Låt oss kalla det” medium ” data

vid denna tidpunkt har du mer än några terabyte som flyter runt, och ditt cron+script ETL håller inte riktigt på. Kanske har du spridit datalager och har en heterogen blandning av SQL-och NoSQL-backends. Du kan också nu ha en handfull tredje parter som du samlar in data från. Slutligen kan du börja ha flera steg i dina ETL-rörledningar med vissa beroenden mellan steg.

arbetsflödeshantering& Automation

ditt första steg i denna fas bör ställa in luftflöde för att hantera dina ETL-rörledningar. Luftflöde gör att du kan schemalägga jobb med jämna mellanrum och uttrycka både tidsmässiga och logiska beroenden mellan jobb. Det är också ett bra ställe i din infrastruktur för att lägga till jobbförsök, övervakning & varning för uppgiftsfel. Det är ett löpande skämt att varje start över en viss storlek skriver sin egen arbetsflödeshanterare / jobbschemaläggare. Bland annat skrev Spotify Luigi och Pinterest skrev Pinball. Dessa har dock mindre fart i samhället och saknar vissa funktioner med avseende på luftflöde.

bygga ETL-rörledningar

när ditt företag växer kommer dina ETL-rörledningskrav att förändras avsevärt. Du måste börja bygga mer skalbar infrastruktur eftersom ett enda skript inte kommer att klippa det längre. Dina mål kommer sannolikt också att expandera från att helt enkelt aktivera SQL-åtkomst till att omfatta stöd för andra nedströmsjobb som behandlar samma data.

så småningom kommer enkla pipelines inte att skala

för att hantera dessa förändrade krav vill du konvertera dina ETL-skript för att köra som ett distribuerat jobb i ett kluster. Antalet möjliga lösningar här är helt överväldigande. Jag rekommenderar starkt att du börjar med Apache Spark. Spark har en enorm, mycket aktiv gemenskap, skalor väl, och är ganska lätt att komma igång snabbt. På AWS kan du köra Spark med EMR; för GCP, med Cloud Dataproc. Om du tar in data från en relationsdatabas är Apache Sqoop ganska mycket standarden.

vid denna tidpunkt kommer din ETL-Infrastruktur att se ut som pipelined stadier av jobb som implementerar de tre ETL-verben: extrahera data från källor, omvandla data till standardiserade format på beständig lagring och ladda den till en SQL-frågebar datastore.

Data Warehouse

i detta skede kommer att få alla dina data till SQL förbli en prioritet, men det är den tid då du vill börja bygga ut en ”riktig” data warehouse.

för dem som just börjat rekommenderar jag att du använder BigQuery. BigQuery är lätt att installera (Du kan bara ladda poster som JSON), stöder kapslade/komplexa datatyper och är helt hanterad/serverlös så att du inte har mer Infrastruktur att underhålla. Som med många av rekommendationerna här finns alternativ till BigQuery tillgängliga: på AWS, Redshift och on-prem, Presto. Jag har en stark preferens för BigQuery framför Redshift på grund av dess serverlösa design, enkelhet att konfigurera korrekt säkerhet/revision och stöd för komplexa typer. Presto är värt att överväga om du har ett hårt krav på on-prem.

när du funderar på att konfigurera ditt datalager är ett bekvämt mönster att anta en 2-stegsmodell, där obearbetade data landas direkt i en uppsättning tabeller och ett andra jobb efterbehandlar dessa data i ”renare” tabeller.

behandla dessa renare tabeller som en möjlighet att skapa en kurerad vy i ditt företag. För var och en av de viktigaste enheterna i ditt företag bör du skapa och sammanställa en tabell med alla mätvärden/KPI: er och dimensioner som du ofta använder för att analysera den enheten. En tabell med ”användare” kan till exempel innehålla mätvärden som registreringstid, antal inköp och dimensioner som geografisk plats eller förvärvskanal.

i slutet av allt detta bör din Infrastruktur se ut så här:

steg 2:” medium ” data pipeline

🚀 steg 3: Going big

med rätt fundament behöver ytterligare tillväxt inte vara smärtsam. Du kan ofta göra helt enkelt genom att kasta hårdvara på problemet med att hantera ökade datavolymer.

de mest utmanande problemen under denna period är ofta inte bara råskala utan växande krav. Till exempel kanske du behöver stödja A/B-testning, träna maskininlärningsmodeller eller rörtransformerade data till ett ElasticSearch-kluster.

några saker du kanske vill överväga i denna fas:

  • nära realtid: Du behöver förmodligen inte en distribuerad kö eller infrastruktur i närheten av realtid förrän mycket senare än du kanske tror. Det kommer med mycket extra komplexitet för att hantera alla möjliga fellägen, vilket inte är värt det tidigt. När ROI-kalkylen är meningsfull, prova Kafka eller Cloud Pub / Sub.
  • skalbarhet: med ett enda monolitiskt Gnistkluster kommer du nästan säkert att stöta på problem med resurskonflikt. När du gör det är helt elastiska Jobbspelade Gnistkluster värda att utforska.
  • Säkerhet & Revision: Vid någon tidpunkt kanske du vill tillämpa mer detaljerade åtkomstkontroller till dina datalagerdata. Om du använder BigQuery kan du tillhandahålla datauppsättningsåtkomst till Google-Grupper och programmässigt hantera den åtkomsten med hjälp av Deployment Manager. BigQuery ger också granskningsloggar för att förstå användarfrågor. Andra verktyg som Apache Knox och Apache Sentry är tillgängliga för on-prem säkerhetslösningar.
  • A/B-testning: för att bygga in-house A/B-testning och stödja experiment finns det tyvärr inte många lösningar utanför hyllan. Att bygga en pipeline av Gnistjobb som fyller tabeller i ditt datalager är förmodligen din bästa insats.
  • maskininlärning: för extraktion av funktioner kan du bygga ytterligare datapipelines i Spark. För modellerna själva bör du börja små igen. Dina bearbetade funktioner är sannolikt små nog att passa på en maskin, så att du kan träna modeller med scikit-learn eller TensorFlow. När en maskin är inte längre tillräckligt, du kan använda Spark MLlib eller distribuerad TensorFlow.

framtiden

det är spännande att se hur mycket datainfrastrukturens ekosystem har förbättrats under det senaste decenniet. Vi har kommit långt från Barnvakt Hadoop kluster och gymnastik att tvinga vår databehandling logik i kartor och minskar i obekväma Java. Då kändes byggnadsdatainfrastruktur som att försöka bygga en skyskrapa med en leksakshammare.

idag har vi en fantastisk mångfald av verktyg. Spark har tydligt dominerat som jack-of-all-trades ersättning till Hadoop MapReduce; detsamma börjar hända med TensorFlow som en maskininlärningsplattform. Med mycket få undantag behöver du inte bygga infrastruktur eller verktyg från grunden internt idag, och du behöver förmodligen inte hantera fysiska servrar. Skyskrapan är redan där, du behöver bara välja dina färgfärger.

den serverlösa framtiden-det kommer helt att vara så här

framöver förväntar jag mig att datainfrastruktur och verktyg fortsätter att röra sig mot helt serverlösa plattformar — DataBricks tillkännagav just ett sådant erbjudande för Spark. Serverlös Infrastruktur möjliggör en elegant separation av problem: molnleverantörerna kan oroa sig för hårdvara, devops och verktyg, vilket gör det möjligt för ingenjörer att fokusera på de problem som är unika för (och anpassade till) sina företag. Framtiden är en utan hårdvarufel, ZooKeeper freakouts eller problem med GARNRESURSKONFLIKT, och det är riktigt coolt.

redigera: lägga till länkar till några tidigare inlägg jag skrev om Thumbtacks datainfrastruktur:

Lämna ett svar

Din e-postadress kommer inte publiceras.

lg