In de vorige twee blogposts van deze serie zijn het onderzoek en het maken van een ETL-pipeline met behulp van Singer aan bod gekomen. In dit derde en laatste deel, richten we ons op hoe we de pijplijn meer cloud-native kunnen maken.

Pipeline

We kwamen de naam Pipelinewise al tegen tijdensons onderzoek toen we op zoek waren naar Singer taps en targets. Tijdens die zoektocht vonden we de Pipelinewise Transform Field stapen de Pipelinewise Target S3 CSV target, die worden gebruikt in onze op Singer gebaseerde pipeline-oplossing.

Op de website van Pipelinewise staat het volgende
PipelineWise is een Data Pipeline Framework dat gebruik maakt van de Singer.io specificatie om data op te nemen en te repliceren van verschillende bronnen naar verschillende bestemmingen.

Gebouwd met ELT in gedachten: PipelineWise past in het ELT landschap en is geen traditionele ETL tool. PipelineWise streeft ernaar de gegevens van de bron naar een Analytics-Data-Store te reproduceren in een formaat dat zo dicht mogelijk bij het oorspronkelijke ligt. Sommige kleine laadtijd transformaties worden ondersteund, maar complexe mapping en joins moeten worden gedaan in de Analytics-Data-Store om betekenis te extraheren.

PipelineWise is een Data Pipeline Framework dat gebruikmaakt van de Singer.io-specificatie om gegevens van verschillende bronnen op te nemen en te repliceren naar verschillende bestemmingen.

Gebouwd met ELT in gedachten: PipelineWise past in het ELT landschap en is geen traditionele ETL tool. PipelineWise streeft ernaar de gegevens van de bron naar een Analytics-Data-Store te reproduceren in een formaat dat zo dicht mogelijk bij het oorspronkelijke ligt. Sommige kleine laadtijd transformaties worden ondersteund, maar complexe mapping en joins moeten worden gedaan in de Analytics-Data-Store om er betekenis uit te halen.

Pipelinewise breidt Singer in principe uit van een EL-product naar een ELT-product. De transformatiemogelijkheden zijn beperkt, maar meer dan genoeg voor onze use case. Wat ook meteen opvalt, is de sectie Running in Docker in hun documentatie.

Als we onze Singer-gebaseerde pijplijn kunnen repliceren in Pipelinewise, stelt deze extra Docker-functionaliteit ons in staat om onze volledige oplossing eenvoudig op een cloud native manier uit te voeren. Dat betekent dat we geen moeite hoeven te doen om een of meer aangepaste Docker-containers te bouwen rond onze bestaande tap/transform/target oplossing.

Onze Singer-pijplijn repliceren in Pipelinewise

Zoals waarschijnlijk het geval is voor veel ontwikkelaars deze dagen, was Docker al geïnstalleerd op mijn systeem. Als dat niet het geval is voor jou, volg dan gewoon de installatie-instructies ophun site om het te installeren. Als je eenmaal Docker hebt, is het werken met Pipelinewise zo eenvoudig als het klonen van hun Github repository enhet bouwen van een Docker image. Dit image bevat de benodigde taps & targets.

Om de Singer-pijplijn uit de vorige blogpost te repliceren, hebben we tap-oracle,target-s3-csv entransform-field nodig. De eerste is eigenlijk een Pipelinewise-versie van de Singer tap-oracle. Vreemd genoeg heeft het betere documentatie over de configuratie dan het origineel. Door deze tap te specificeren als een Pipelinewise connector tijdens de docker build, wordt ook automatisch de benodigdeOracle Instant Client geïnstalleerd.

Dit duurt even voordat het klaar is (ongeveer 6 minuten op mijn machine), waarna we de eigenlijke pijplijn kunnen maken. Je kunt je image ook een andere naam geven of een andere versie dan de nieuwste gebruiken. Verander in dat geval de waarden in het bestand bin/pipelinewise-docker. Dit zorgt ervoor dat de alias jouw waarden gebruikt.

Het bovenstaande commando maakt een nieuwe map aan met de naam anonimization-pipeline in de pipelinewise mapdie is aangemaakt door het uitchecken van het archief. Er staan een aantal voorbeeldbestanden in deze map. Om onze Singer-pijplijn te repliceren, kunnen we ze gewoon allemaal verwijderen, behalve tap_oracle.yml.sample en target_s3_csv.yml.sample. Voor deze 2 bestanden moeten we de extensie.sample verwijderen.

Bewerk nu het tap_oracle.yml bestandzodat het de onderstaande inhoud heeft:

Een Pipelinewise tap dient 2 doelen tegelijk. Het is het extractiegedeelte, maar ook, door middel van de sectie transformaties voor een tabel, het transformatiegedeelte van de pijplijn. Bewerk vervolgens het bestand target_s3_csv.yml en geef het de onderstaande inhoud:

Importeer tot slot de pijplijn:

Dit importeert de pijplijn. Het doet ook de tap catalogus ontdekking die we handmatig deden in de vorige aflevering van deze blog post. Wanneer we het pipelinewise status commandouitvoeren, zou onze pijplijn correct geïmporteerd, ingeschakeld en klaar voor gebruik moeten zijn.

De pijplijn uitvoeren

Nu hoeven we alleen nog maar de eigenlijke pijplijn uit te voeren. Doe dit met de pipelinewiserun_tap opdracht:

De uitvoer laat zien dat onze pijplijn met succes is uitgevoerd. Er is een nieuw CSV-bestand toegevoegd aan onze emmer:

Bovendien bevat het bestand de juiste informatie:

Externe configuratie

Nu hebben we iets dat in staat is om onze pijplijn uit de vorige blogpost te repliceren, maar deze keer met behulp van een Docker-gebaseerde aanpak. Het is nu in staat om te draaien in alle contexten die Docker-images accepteren. Dit varieert van een eenvoudige fysieke server of een compute instance waar je Docker of Docker Compose zelf installeert en draait, tot een container as a service setup zoals Amazon ECS en tot een volledig Kubernetes cluster.

Het enige dat nog ontbreekt om ons cloud native scenario te voltooien, is een externe configuratie voor onze pipeline. We hebben dit nodig om alle waarden door te geven die verschillen tussen omgevingen in plaats van specifieke configuratiebestanden te moeten maken voor elke omgeving.

Gelukkig ondersteunt Pipelinewise dit ook. We hoeven alleen maar de env_var notatie te gebruiken voor elke waarde die we willen injecteren. Hier is een voorbeeld voor de S3-geheimen:

Als je Docker Compose gebruikt, werkt dit direct goed. Je kunt omgevingsvariabelen opgeven in je docker-compose.yml of in een .env bestandzoals je kunt zien in Sample Project for Docker Development Environment. Om dit lokaal te laten werken, moest ik echter mijn bin/pipelinewise-docker bestandiets wijzigen. Deze wijziging is nodig om omgevingsvariabelen door te geven aan het normale commando op een manier dat de docker die erin draait ze ook gebruikt:

Met de bovenstaande wijzigingen wordt de pipeline-wise import dan:

Conclusie

Deze post heeft laten zien dat de conversie van Singer naar Pipelinewise vrij eenvoudig is. Het geeft ons een Docker-gebaseerd systeem dat eenvoudig lokaal of in de cloud kan worden gebruikt met externe configuratie. Planning is geen onderdeel van Pipelinewise zelf, maaris eenvoudig te realiseren. Afhankelijk van je keuze van implementatie, kun je het doen met een eenvoudige cron of iets als Apache luchtstroom.

Voor mij was dit een interessante POC om te doen. Ik was aangenaam verrast dat ik een aantal eenvoudige tools vond die eenvoudig te gebruiken zijn en aan elkaar kunnen worden gekoppeld. Er waren wat kleine problemen onderweg, maar niets onoverkomelijks.

De enige opmerking die ik heb is dat hoewel Singer en Pipelinewise perfect werken en zullen blijven werken, ze tegenwoordig vooral lijken te worden gebruikt in andere (SaaS) producten. Dat betekent dat de vrije en open delen misschien niet meer zo actief worden ontwikkeld, dus dat is iets om in gedachten te houden.