de afgelopen jaren heb ik veel gesprekken gehad met vrienden en collega ‘ s die gefrustreerd waren over hoe ondoorgrondelijk complex het ecosysteem van de data-infrastructuur is. Hoewel niet zo erg als de front-end wereld, dingen veranderen snel genoeg om een modewoord soep te creëren.

als beginner is het super uitdagend om te beslissen welke tools geschikt zijn voor jou. De Apache Foundation noemt 38 projecten in de “Big Data” sectie, en deze tools hebben tonnen overlap op de problemen die ze beweren aan te pakken. Bijvoorbeeld, Flink, Samza, Storm, en Spark Streaming zijn “distributed stream processing engines”, Apex en Beam”unify stream and batch processing”.

in dit bericht hoop ik u wat hulp te bieden bij het navigeren door de opties terwijl u bezig bent met het bouwen van data-infrastructuur. Dit zijn grofweg de stappen die ik vandaag zou volgen, gebaseerd op mijn ervaringen van de afgelopen tien jaar en op gesprekken met collega ‘ s die in deze ruimte werken.

aan het begin van uw project, bent u waarschijnlijk met niets meer dan een doel van “Get insights from my data” in de hand. Het in kaart brengen van dit aan specifieke set van technologieën is uiterst ontmoedigend. Je hebt waarschijnlijk geen goed gevoel voor welke tools populair zijn, wat “stream” of “batch” betekent, of dat je zelfs data-infrastructuur nodig hebt.

in dit bericht hoop ik u te helpen snel van de grond te komen en waarde uit uw gegevens te halen. Ik geloof er sterk in om de zaken zo lang mogelijk eenvoudig te houden en complexiteit alleen te introduceren als het nodig is voor schaalbaarheid. Deze post volgt die boog in drie fasen. In veel opzichten, het beschrijft de stappen van het bouwen van data-infrastructuur die ik heb gevolgd in de afgelopen jaren.

merk op dat er niemand juiste manier is om data-infrastructuur te architecteren. Voor de deskundigen het lezen van dit, u misschien liever alternatieven voor de oplossingen die hier worden voorgesteld. Dat is fantastisch en benadrukt de diversiteit aan geweldige tools die we tegenwoordig hebben. We zijn erg ver gekomen van toen Hadoop MapReduce alles was wat we hadden.

het zit zo: je hebt waarschijnlijk nog geen “big data”. Bijna 4 jaar later, Chris Stucchio ’s 2013 artikel Don’ t use Hadoop is nog steeds op punt. Als je minder dan 5 TB aan gegevens hebt, begin dan klein. Dit bespaart u operationele hoofdpijn met het onderhoud van systemen die u nog niet nodig hebt. Maar hey, als je houdt van 3am brandoefeningen van baan mislukkingen, voel je vrij om deze sectie over te slaan…

anders, blijf weg van alle buzzword technologieën aan het begin, en focus op twee dingen: (1) het maken van uw gegevens queryable in SQL, en (2) het kiezen van een BI-Tool. Dit zal de “Hello, World” backbone zijn voor al uw toekomstige data-infrastructuur.

alles in SQL

dit is echt belangrijk, omdat het data ontsluit voor de hele organisatie. Met zeldzame uitzonderingen voor de meest onverschrokken marketing mensen, zult u nooit uw niet-technische collega ‘ s te overtuigen om Kibana te leren, grep sommige logs, of om de obscure syntaxis van uw NoSQL datastore gebruiken.

het bieden van SQL-toegang stelt het hele bedrijf in staat om zelfbedieningsanalisten te worden, waardoor uw reeds uitgerekte engineeringteam uit het kritieke pad komt. Het verandert ook iedereen in een gratis QA-team voor uw gegevens. De “hey, deze nummers zien er een beetje raar …” is van onschatbare waarde voor het vinden van bugs in uw gegevens en zelfs in uw product.

als uw primaire datastore een relationele database is zoals PostgreSQL of MySQL, is dit heel eenvoudig. Je kunt gewoon een leesreplica opzetten, toegang verschaffen, en je bent helemaal klaar.

met een NoSQL-database zoals ElasticSearch, MongoDB of DynamoDB moet u meer werk doen om uw gegevens te converteren en in een SQL-database te plaatsen. Als je nieuw bent in de data wereld, noemen we dit een ETL pijplijn. Vermijd het bouwen van deze zelf indien mogelijk, als het bedraden van een off-the-shelf oplossing zal veel minder duur met kleine data volumes. Afhankelijk van uw bestaande infrastructuur, kan er een cloud ETL-provider zoals Segment dat u kunt benutten.

als u vindt dat u uw eigen datapijpleidingen moet bouwen, houd ze dan in het begin uiterst eenvoudig. Schrijf een script om periodiek dump updates uit uw database en schrijf ze ergens queryable met SQL.

het verhaal voor ETLing-gegevens uit bronnen van derden is vergelijkbaar met NoSQL-databases. Gebruik een ETL-as-a-service provider of schrijf een eenvoudig script en stort uw gegevens in een SQL-queryable database.

zet een machine op om je ETL script(s) als dagelijkse cron te draaien, en je bent op weg naar de races.

BI Tool

een goed BI tool is een belangrijk onderdeel van het begrijpen van uw gegevens. Enkele geweldige tools om te overwegen zijn Chartio, Mode Analytics, en Periscope Data-een van deze zou geweldig moeten werken om uw analytics van de grond te krijgen. In de meeste gevallen kunt u deze tools direct op uw SQL-database richten met een snelle configuratie en direct in het creëren van dashboards duiken.

als je dit alles samenvat, zie je de “Hello, World” van data-infrastructuur:

Fase 1: De” Hello, World ” kleine datapijplijn

Fase 2: Laten we het “medium” data

noemen op dit punt heb je meer dan een paar terabytes rondzweven, en je cron+script ETL houdt het niet helemaal bij. Misschien heb je datastores verspreid en heb je een heterogene mix van SQL en NoSQL backends. U kunt nu ook een handvol van derden die u het verzamelen van gegevens van. Tot slot kan het zijn dat je meerdere stadia begint te hebben in je ETL pijpleidingen met een aantal afhankelijkheden tussen de stappen.

Workflow Management & automatisering

uw eerste stap in deze fase zou het opzetten van luchtstroom moeten zijn om uw ETL-pijpleidingen te beheren. Met Airflow kunt u taken met regelmatige tussenpozen plannen en zowel tijdelijke als logische afhankelijkheden tussen taken uitdrukken. Het is ook een geweldige plek in uw infrastructuur om nieuwe taken toe te voegen, waarbij & wordt gemonitord voor fouten in taken. Het is een lopende grap dat elke startup boven een bepaalde grootte schrijft hun eigen workflow manager / job scheduler. Spotify schreef onder andere Luigi en Pinterest schreef Pinball. Deze hebben echter minder dynamiek in de Gemeenschap en missen een aantal kenmerken met betrekking tot de luchtstroom.

ETL-pijpleidingen bouwen

naarmate uw bedrijf groeit, zullen uw ETL-pijpleidingsvereisten aanzienlijk veranderen. Je moet beginnen met het bouwen van meer schaalbare infrastructuur omdat een enkel script het niet meer zal knippen. Uw doelen zullen waarschijnlijk ook uitbreiden van simpelweg SQL-toegang tot ondersteuning van andere downstreamtaken die dezelfde gegevens verwerken.

uiteindelijk schalen eenvoudige pijpleidingen niet

om aan deze veranderende vereisten te voldoen, wilt u uw ETL-scripts converteren naar een gedistribueerde taak op een cluster. Het aantal mogelijke oplossingen hier is absoluut overweldigend. Ik raad ten zeerste aan om te beginnen met Apache Spark. Spark heeft een enorme, zeer actieve gemeenschap, schaalt goed, en is vrij gemakkelijk om snel aan de slag te gaan. Op AWS, kunt u Spark uitvoeren met behulp van EMR; voor GCP, met behulp van Cloud Dataproc. Als je data van een relationele database binnenkrijgt, is Apache Sqoop zo ‘ n beetje de standaard.

op dit punt zal uw ETL-infrastructuur eruit gaan zien als pijplijn-fasen van taken die de drie ETL-werkwoorden implementeren: gegevens uit bronnen halen, die gegevens omzetten naar gestandaardiseerde formaten op permanente opslag, en deze laden in een SQL-queryable datastore.

datawarehouse

in dit stadium blijft het ophalen van al uw gegevens in SQL een prioriteit, maar dit is het moment waarop u een “echt” datawarehouse wilt opbouwen.

voor degenen die net beginnen, raad ik aan om BigQuery te gebruiken. BigQuery is eenvoudig in te stellen (u kunt gewoon records laden als JSON), ondersteunt geneste/complexe gegevenstypen, en is volledig beheerd/serverless, zodat u niet meer infrastructuur te onderhouden. Zoals met veel van de aanbevelingen hier, alternatieven voor BigQuery zijn beschikbaar: op AWS, Redshift, en op-prem, Presto. Ik heb een sterke voorkeur voor BigQuery boven Redshift vanwege het serverloze ontwerp, de eenvoud van het configureren van de juiste beveiliging / auditing, en ondersteuning voor complexe types. Presto is het overwegen waard als u een harde eis voor on-prem.

wanneer u denkt aan het opzetten van uw datawarehouse, is een handig patroon om een 2-traps model te gebruiken, waarbij onbewerkte gegevens direct in een reeks tabellen worden aangeland en een tweede job post-verwerkt deze gegevens in “schonere” tabellen.

behandel deze cleaner tables als een mogelijkheid om een samengesteld overzicht in uw bedrijf te creëren. Voor elk van de belangrijkste entiteiten in uw bedrijf moet u een tabel maken en samenstellen met alle metrics/KPI ‘ s en dimensies die u vaak gebruikt om die entiteit te analyseren. Een tabel met “gebruikers” kan bijvoorbeeld statistieken bevatten zoals aanmeldingstijd, aantal aankopen en dimensies zoals geografische locatie of acquisitiekanaal.

aan het einde van dit alles zou uw infrastructuur er ongeveer zo uit moeten zien:

Fase 2: De” medium ” datapijplijn

🚀 Fase 3: Als je groot wordt

met de juiste fundering, hoeft verdere groei niet pijnlijk te zijn. U kunt vaak doen gewoon door het gooien van hardware op het probleem van het omgaan met verhoogde data volumes.

de meest uitdagende problemen in deze periode zijn vaak niet alleen ruwe schaal, maar ook toenemende behoeften. Bijvoorbeeld, misschien moet u ondersteuning A/B testen, trein machine learning modellen, of pijp getransformeerde gegevens in een ElasticSearch cluster.

enkele dingen die u in deze fase wilt overwegen:

  • bijna-Realtime: Je hebt waarschijnlijk geen gedistribueerde wachtrij of near-realtime infrastructuur nodig tot veel later dan je zou denken. Het wordt geleverd met veel extra complexiteit om alle mogelijke foutmodi te behandelen, wat het niet in een vroeg stadium waard is. Zodra de ROI calculus zinvol is, probeer Kafka of Cloud Pub / Sub.
  • schaalbaarheid: met een enkele monolithische Spark cluster, zult u vrijwel zeker problemen tegenkomen met Resource contention. Als je dat doet, zijn volledig elastische Baan-scoped Spark clusters de moeite waard om te verkennen.
  • Beveiliging & Audit: Op een gegeven moment wilt u misschien meer gedetailleerde toegangscontroles afdwingen om uw data warehouse gegevens. Als u BigQuery gebruikt, kunt u datasettoegang verlenen aan Google-Groepen en die toegang programmatisch beheren met Deployment Manager. BigQuery biedt ook audit logs om gebruikersvragen te begrijpen. Andere tools zoals Apache Knox en Apache Sentry zijn beschikbaar voor on-prem beveiligingsoplossingen.
  • A / B testen: voor het bouwen van interne A/B testen en het ondersteunen van experimenten, zijn er helaas niet veel kant-en-klare oplossingen. Het bouwen van een pijplijn van Vonk banen die tabellen bevolken in uw data warehouse is waarschijnlijk uw beste weddenschap.
  • Machine Learning: voor extractie van functies kunt u extra gegevenspijpleidingen bouwen in Spark. Voor de modellen zelf moet je weer klein beginnen. Uw verwerkte functies zijn waarschijnlijk klein genoeg om op één machine te passen, zodat u modellen kunt trainen met behulp van scikit-learn of TensorFlow. Wanneer één machine niet meer genoeg is, kunt u Spark MLlib of distributed TensorFlow gebruiken.

de toekomst

het is spannend om te zien hoezeer het ecosysteem van de gegevensinfrastructuur de afgelopen tien jaar is verbeterd. We hebben een lange weg van babysitting Hadoop clusters en gymnastiek te dwingen onze Data processing logica in kaarten en vermindert in onhandig Java. Toen voelde het bouwen van data-infrastructuur als het bouwen van een wolkenkrabber met een speelgoedhamer.

vandaag de dag hebben we een verbazingwekkende diversiteit aan tools. Spark heeft duidelijk gedomineerd als de jack-of-all-trades vervanging van Hadoop MapReduce; hetzelfde begint te gebeuren met TensorFlow als een machine learning platform. Op een paar uitzonderingen na hoef je tegenwoordig geen infrastructuur of tools vanuit het niets in eigen huis te bouwen en hoef je waarschijnlijk geen fysieke servers te beheren. De wolkenkrabber is er al, je hoeft alleen maar je verfkleuren te kiezen.

de serverloze toekomst-het zal helemaal zo zijn

vooruitkijkend verwacht ik dat data — infrastructuur en tools blijven evolueren naar volledig serverloze platforms-DataBricks heeft zojuist een dergelijk aanbod voor Spark aangekondigd. Serverloze infrastructuur maakt een elegante scheiding van zorgen mogelijk: de cloud providers kunnen zich zorgen maken over de hardware, devops en tooling, waardoor ingenieurs zich kunnen concentreren op de problemen die uniek zijn voor (en afgestemd zijn op) hun bedrijven. De toekomst is een zonder hardware storingen, ZooKeeper freakouts, of problemen met garen resource contention, en dat is echt cool.

bewerken: links toevoegen naar eerdere berichten die ik schreef over Thumbtack ‘ s data-infrastructuur:

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.

lg