DRYING UP THE DATA SWAMP - Uni Stuttgart · •SchwerpunkteBig Data und Cloud Architekturen...

DRYINGUPTHEDATASWAMPVernetzungvonDatenmittelsiQser GINServer

FlorianPfleiderer

Dryingupthedataswamp 2

• SolutionEngineerbei dibuco• Schwerpunkte BigDataundCloudArchitekturen• Erfahrungen inderProduktentwicklung

• Berater für Entwicklung einer BigDataMiddleware• Produkt GINServer(=GlobalInformationNetwork)

Agenda


1 Warumeigentlich„DataSwamp“?

2 GINServerals Lösung

3 Herausforderung Big DataEntwicklung

4 LessonsLearned

Warumeigentlich„DataSwamp“?DieIdeedesDataLakestelltUnternehmeninderPraxisvorgroßeHerausforderungen.OftmalsverkommternachundnachzumDataSwamp.

DegenerationdesDataLake• HeterogeneDatenauszahllosenQuellenkönnennichtverstandenwerden• Datenqualitätistnichtbekannt• OhnegemeinsamesSchemaistesoftschwierig,Anfragenzustellen• GängigeTechnologienbietennichtimmerguteLösungen• FirmenglaubenzuUnrecht,siehättenihreDatenunterKontrolle


Daten,Daten,Daten...


GINServeralsLösung

Daten,Daten,Daten...Verknüpfungen?


GINServer• RepräsentationderQuelldatenals„Content“imGINServer• DatenwerdenanderQuelleinpassendesFormatgebracht• SimplesFormat:Herkunft,(Meta-)Attribute,Volltext

• Verknüpfungen(Statements)zwischenContentssind• gerichtet• begründet• gewichtet


GINServer• VerknüpfungunterschiedlicherDatenaufBasisvon• TextMiningVerfahren• StatistischenAnalysen• NLP• ...

• ExtraktionderThemenvonDokumenten

• ErstellungundHarmonisierungeinesMetamodells


GINServer


Diesel

Feinstaub

Motor

Contract- date- title

Content-Graph KonzeptgraphUIMGraph

Customer- customerID- name

GINServer

Value

Information

Data

• VonDatenzuInformationen• automatischeVerknüpfungdurchAlgorithmeninGINServer• vollautomatischeUnterstützung

• GewinnvonValue(=Wissen?)ausInformation• Queries undkontextbezogeneSuchenindenverknüpftenDaten


Drying up the data swamp

13

HerausforderungenBigData– BigComplexity

EntwicklungderArchitektur• Vor„BigData“• MonolithischeArchitektur,relationaleDatenbank• keineSkalierbarkeit• UnzähligeJoins

• DererstegroßeSchritt• Microservice-Architektur• Batch-Processing(hadoop)• GraphDatenbank(TitanDB)• =>SehrvielgrößereDatenmengenbeherrschbar


EntwicklungderArchitektur:ErkannteProbleme• StreamingProblemstellung– BatchLösung🌩

• OptimierungenüberwiegendamBatchImport,VernachlässigungdesrestlichenSystems• BatchesalsLösungfürjedesProblem• LangeWartezeitenbisDatenänderungenimSystemsind

• AusführungsdauervonBatcheswirdzunehmendlänger• TeilweiseSystemstillstandnotwendigfürBatchläufe

• Hadoop alsTechnologieerfordertspezielleKenntnissevonDev undOps


EntwicklungderArchitektur:ErkannteProbleme

• ImVorausberechneteStatementswerdenalleabgespeichert• EnormeAnzahlanVerknüpfungenverbrauchtvielFestplattenspeicher• Datenbankabfragenwerdenzunehmendlangsamer• SuperknotenkönnendasSystemlahmlegen


EntwicklungderArchitektur:ErkannteProbleme

• GroßeSünde:GemeinsamePersistenzderServices• erzeugtdortimmenseLast• unsereigenerkleinerDataSwamp• Serviceskönnensichnichtunabhängigentwickeln

• KomplexitätfürDeployment undKonfigurationwächstexponentiell• KomplexitätverhindertabeinemgewissenPunktweitereSkalierung• WartungfürdasDeployment wirdimmerteurer


Lessons Learned

EntwicklungderArchitektur:Lessons learned


Verarbeitung im Batch Verarbeitung imStream

Verknüpfungen speichern Verknüpfungen berechnen

Gemeinsame Persistenz Unabhängige Services

Betrieb aufdem HostSystem Betrieb imContainer

EntwicklungderArchitektur– StatusQuo• EineStreaming-LösungfüreinStreaming-Problem💡

• (Vor-)verarbeitung derDatenimStream• UmsetzungdesDatenimportsmitApacheStorm• KontinuierlicheVerarbeitungmachtErgebnisseschnellerabfragbar

• DasSystemkanndurchgehendlaufen• BeiBedarfkönnenzuStoßzeitenleichtweitereRessourcenhinzugenommenwerden

• StormalsTechnologieauchananderenStellenalsnurbeimImport


EntwicklungderArchitektur– StatusQuo• Ad-hocBerechnungderVerknüpfungen• Speicherplatzproblem:gelöst• NurnochSpeicherungvonstatistischenInformationen• BerechnungsdauerfürVerknüpfungengeringeralsDB-Abfragezeiten

• KeineAngstvorRedundanz!


EntwicklungderArchitektur– StatusQuo• WeitererAusbauderMicroservice Archtitektur• ermöglichtbessereSkalierung• unabhängigeWeiterentwicklungderServiceswirdmöglich• LastaufdiePersistenz(en!)verteiltsichsehrvielbesser

• Containerisierung• Deployment umeinvielfacheseinfacherundbeherrschbarer• ZentralesManagementmachtKonfigurationwesentlichsimpler• GroßeHilfefürSkalierbarkeit


EntwicklungderArchitektur– Fazit• TechnologienmüssenpassendzudenProblemenausgewähltwerden• VieleProblemesindStreamingProbleme

• VieleneueTechnologienimMarkt,dievieleserleichtern

• Aber:DieseLösungenkommenmiteigenenFallstricken


VIELEN DANKFÜR IHREAUFMERKSAMKEIT

Franz-SchubertStraße [email protected]

Quellen• MicrosoftOfficeProdukt-Logos:WikimediaCommons (Rezonansowy,©Microsoft)• AdobePDFLogo:AdobeWebsite(©Adobe)• Hadoop Logo:@hadoop onTwitter(https://twitter.com/hadoop)• StormLogo:@ApacheStorm onTwitter(https://twitter.com/ApacheStorm)• TitanDataModel:TitanDokumentation(http://s3.thinkaurelius.com/docs/titan/current/data-model.html)


DRYING UP THE DATA SWAMP - Uni Stuttgart · •SchwerpunkteBig Data und Cloud Architekturen...

Documents

Transcript of DRYING UP THE DATA SWAMP - Uni Stuttgart · •SchwerpunkteBig Data und Cloud Architekturen...