Plumber : collaboratief, serverless beheer voor streamverwerking op Kubernetes.

Gerealiseerd door: Bert Verstraete
Interne promotor: prof. dr. ir. Filip De Turck
prof. dr. Bruno Volckaert
Academiejaar: 2021-2022
Prijzen: voorgedragen voor de TomTom-prijs 2022

Elke dag hebben organisaties te maken met een toenemende hoeveelheid real-time data. Naarmate het volume van de gegevens toeneemt, neemt ook de behoefte toe om deze gegevens te distilleren in steeds grotere hoeveelheden nuttige informatie. Streamverwerkings frameworks zijn in staat gebleken om de niche van het omgaan met deze toenemende real-time verwerkingsbehoeften te vullen. Het bouwen van streamverwerkings topologieën voor zowel ETL taken als data analyse vereist vaak een nauwe samenwerking tussen data engineers en data scientists. Data scientists willen misschien hun methodes voor analytics iteratief veranderen, willen mogelijks stappen toevoegen of verwijderen in de topologie, echter vereist dit expertise die de data engineer bezit. De huidige state-of-the-art biedt echter geen cohesieve voorzieningen voor samenwerking: bestaande technologieën bieden ofwel geen transparante technieken voor wijzigingsbeheer, ofwel geen methoden voor het gezamenlijk modelleren en bouwen van topologieën. Dit onderzoek stelt een methode voor om asynchrone samenwerking mogelijk te maken bij zowel het modelleren als het wijzigingsbeheer van staatloze streamverwerkings topologieën. De geïntroduceerde concepten worden geïllustreerd aan de hand van de ontwikkeling van Plumber: een Kubernetes-native raamwerk dat de iteratieve ontwikkeling en het beheer van verwerkings topologieën op een serverless manier mogelijk maakt. Evaluatie van het transparante update mechanisme tonen aan dat de voorgestelde methode in alle gevallen correct is, d.w.z. dat er geen data verloren gaat of gedupliceerd wordt. Bij de implementatie van dit werk werden verscheidene courante technologiën gebruikt. Zo werd ondermeer Kubernetes gekozen als de grondlaag om op te ontwikkelen, zo kan Plumber en zijn (delen van) topologiën mee geinterageerd worden zoals eender andere resource binnen Kubernetes - volledig declaratief. Verder werd de keuze gemaakt om Kafka te gebruiken als communicatielaag binnen Plumber, met fout-resistentie en hoge performantie als gevolg van de integratie. Om de werkende Topologien en hun delen te laten schalen werd geopteerd voor KEDA (Kubernetes Event Driven Autoscaler) die de Topologiën transparant doet schalen op basis van het werk die nog geleverd moet worden.