Big Data Beheer en NoSQL-oplossingen PDF

BEHEER VAN BIG DATA EN NO-SQL-OPLOSSINGEN NoSQL-databasesystemen zijn geen vervanging van conventionele databasesystemen maar worden complementair gebruikt. BIG DATA Niet-traditionele data: social mediadata, sensordata, klikgedrag,… Kunnen ook zeer waardevolle informatie, inzichten en kennis ople...

BEHEER VAN BIG DATA EN NO-SQL-OPLOSSINGEN NoSQL-databasesystemen zijn geen vervanging van conventionele databasesystemen maar worden complementair gebruikt. BIG DATA Niet-traditionele data: social mediadata, sensordata, klikgedrag,… Kunnen ook zeer waardevolle informatie, inzichten en kennis opleveren. DB- en DW-technieken volstaan niet. Big data: wanneer conventionele (database)systemen niet volstaan om een karakteristiek zeer grote datacollectie doeltreffend te beheren en te verwerken. Met als oorzaak de 4 V’s. DE VIER V’S VAN BIG DATA Volume § Gigantische datavolumes § Dit hoofdkenmerk is het meest voorkomende § Vandaar “big” data § Bijv.: Machine-gegenereerde data (IoT, sensordata,... bijv. vliegtuigmotor:10GB/s) Data afkomstig van smartphones (lokalisatie,...) Input van grote aantallen gebruikers (Facebook, Twitter, clickstreams,...) Omvangrijke data (multimedia...) Alle sterk groeiend in aantal Variëteit (Variety) zeer grote variëteit aan dataformaten: § data steeds weer anders of juist niet gestructureerd § zeer moeilijk, zo niet onmogelijk, om er een vast databaseschema voor op te stellen § “heterogene of gevarieerde data” § Typische voorbeelden : Vrije invoervelden Tekst in natuurlijke taal Het inzetten van verschillende soorten sensors Multimedia à Uitdaging groter dan de volumeproblematiek Snelheid (Velocity) Snelheidsvereisten bij de registratie van de data § Acquisitie-snelheid: hoog debiet aan data-input § Tijdigheid: de registratie van een gegeven moet snel genoeg verlopen (bepaalde real time toepassingen zijn slechts zinvol indien ze binnen een redelijke tijd kunnen gerealiseerd worden) Beperkingen op acquisitiesnelheid en tijdigheid van de data = fast data Vb. § trajectcontrolesysteem op een snelweg § analyse van datastromen van sociale media § het onmiddellijk detecteren van fraude bij creditcardgebruik 46 Waarheidsgetrouwheid ( Veracity) Gevoelig voor slechte datakwaliteit = bad data à Systeem zou aan de gebruiker op zijn minst meegegeven hoe betrouwbaar de data is § Kan niet met conventioneel databasesysteem worden gecontroleerd § Slechte datakwaliteit is vaak te wijten aan onnauwkeurigheid, vaagheid, onzekerheid, onvolledigheid of inconsistentie § hebben de neiging om een sneeuwbaleffect te veroorzaken § vb. Foutieve gebruikersinvoer Redundante gegevens Corrupte data à Misschien wel het moeilijkste probleem met 'big‘ data. UITDAGINGEN BIJ HET BEHEER VAN BIG DATA In een grote collectie van niet-traditionele data zit vermoedelijk nuttige informatie verborgen, maar... Uitdaging: § Doelstelling: een duidelijk beeld ontwikkelen van wat je met deze data wil bereiken § Identificatie van de data die daarvoor waardevol is Andere optie: Data lake Ga je toch data verzamelen zonder vooropgesteld doel, dan creëer je een “data lake”, waarin je data accumuleert om pas later te beslissen welke analyses je erop zal uitvoeren. De uitdaging bij big data is waardevolle data identificeren, extraheren en transformeren voor verdere analyse. Bv. Niet nodig om alle Twitter berichten op te slaan, men gaat filteren op woorden en concepten. Om big data te benutten ga je de IT-infrastructuur moeten aanpassen om de 4 V’s te kunnen behandelen OPLOSSINGEN VOOR HET BEHEER VAN BIG DATA Not only SQL-of NoSQL-databasesysteem is een databasesysteem dat minstens een oplossing biedt voor het volumeprobleem, variëteitsprobleem, snelheidsprobleem of waarheidsgetrouwheidsprobleem. OPLOSSINGEN VOOR HET VOLUMEPROBLEEM De opslagruimte van een dbms vergroten kan op 2 manieren: § verticaal schalen: traditionele manier voor grote volumes data meer secundair geheugen door bv. extra magneetschijven à feitelijk geen big dataprobleem § horizontaal schalen gedistribueerde dataopslag waarbij meerdere hardwareknopen met secundair geheugen via een netwerk ter beschikking worden gesteld. Hier voegt men extra, goedkopere knopen toe aan het netwerk. Het ontwerp van een NoSQL zorgt dat je gemakkelijk knopen kan toevoegen of verwijderen. 47 OPLOSSINGEN VOOR HET VARIËTEITSPROBLEEM Ongestructureerde of semi-gestructureerde data, ofwel veel databaserecords die een verschillende structuur hebben. Conventionele systemen: § Dwingen de data in vaste structuur (tabel, klasse,...) § Tijdrovende omzettingen NoSQL: schemaloze database § Data worden daarin opgeslagen zoals ze zijn, zonder enige voorafgaande omzetting: Acquisitie werkt veel sneller § Beperkte zoekfaciliteiten in dbms § dbms is compacter, applicatie is complexer § Verantwoordelijkheden verschoven van dbms naar applicatie: Complexe zoekinstructies Correcte interpretatie van data Data-integriteit § Dbms is afgestemd op het efficiënt uitvoeren van specifieke (zoek)operaties: leunt daarom aan bij het operationeel databasemodel (zoals hiërarchisch en netwerkmodel) OPLOSSINGEN VOOR HET SNELHEIDSPROBLEEM Conventionele database moet ACID-eigenschappen garanderen: § Atomair (Atomic) § Consistent (Consistent) § Geïsoleerd (Isolated) § Duurzaam (Durable) à tijdsverlies ACID § Atomair. Het dbms moet garanderen dat bewerkingen atomair worden uitgevoerd. Dit wil zeggen dat elke bewerking ofwel volledig wordt uitgevoerd, ofwel helemaal niet wordt uitgevoerd. Deze eigenschap noemen we de 'alles of niets-eigenschap'. (*) § Consistent. Het dbms moet de consistentie van de data waarborgen. Dat wil zeggen dat de data steeds in overeenstemming moeten zijn met de bedrijfsregels die van toepassing zijn. Als een bewerking de database wijzigt, moet ze de database omzetten van de ene consistente toestand naar een andere consistente toestand. Het dbms moet garanderen dat de uitvoering van instructies niet kan leiden tot inconsistentie. § Isolatie. Het dbms moet garanderen dat bewerkingen geïsoleerd van elkaar worden uitgevoerd. Wanneer meerdere bewerkingen terzelfdertijd worden uitgevoerd, mag de uitvoering van een bewerking geen verstoring of beïnvloeding geven voor de uitvoering van de andere bewerkingen. § Duurzaam. De resultaten van een succesvol uitgevoerde bewerking moeten permanent geregistreerd zijn in de database. Het dbms moet garanderen dat deze resultaten niet verloren kunnen gaan, ook bij een falen van het databasesysteem, zelfs al gebeurt dit falen onmiddellijk na het beëindigen van de bewerking. No-ACID-systemen § risico op inconsistente data, opgeofferd voor snellere uitvoeringstijden § verantwoordelijkheid voor integriteit verschoven van database naar applicatie § extra verwerkingstijd aan validatie in applicatie, maar wordt uitgesteld naar beter geschikt moment 48 CAP-Theorema § Consistentie: voor en na datamanipulatie moet data consistent zijn. § Availability: je kan steeds verder werken aan de database. Als een soft- of hardwarecomponent uitvalt, moet de dbms dat kunnen opvangen en voortwerken met replica’s. § Partitietolerantie: het dbms moet verder kunnen werken bij partitionering van het communicatienetwerk. Bv een tijdelijke toevoeging of verwijdering van een knoop voor onderhoud. CAP-theorema: een gedistribueerd databasesysteem kan maar ten hoogste twee van de drie eigenschappen consistentie, beschikbaarheid en partitietolerantie garanderen. De drie samen garanderen is dus onmogelijk. Bij een NoSQL-databasesysteem gaat men uit van gedistribueerde opslag. Men kan niet garanderen dat het netwerk niet faalt dus zal men voor partitietoleratie opteren. De resterende keuze zijn: § Consistentie/partitietolerantie (CP): ACID-eigenschappen zijn nodig à trager met foutboodschappen § Beschikbaarheid/partitietolerantie (AP): sneller, maar kan niet garanderen dat data actueel en correct zijn Bij AP worden BASE-eigenschappen toegedicht i.p.v. ACID-eigenschappen § Basic availability: de beschikbaarheid van de data weegt zwaarder dan consistentie § Soft-state: database zal niet altijd consistent zijn, validatie gebeurt pas later in de applicatie en door datadistributie kan het voorkomen dat de aanpassingen niet direct doorgevoerd worden en zichtbaar zijn in elke replica. § Eventual consistency: Na verloop van tijd zal de validatie plaatsvinden en aangepast worden in de replica’s. Theoretisch zal de database dus ergens in de toekomst consistent zijn. Snellere werking (want BASE is eenvoudiger dan ACID) Altijd beschikbaar, maar (kleine?) kans op niet-consistente respons (=”optimistische aanpak”) Voor foutgevoelige toepassingen: AP is niet geschikt; CP noodzakelijk OPLOSSINGEN VOOR HET WAARHEIDSGETROUWHEIDSPROBLEEM Moeilijkste om op te lossen Datakwaliteitsmodellering en datakwaliteitsverbetering Belangrijke aspecten: § Schatten en modelleren van datakwaliteit § Foutdetectie en foutbehandeling § Duplicaatdetectie en het samenvoegen van duplicaten TYPES VAN NOSQL-DATABASES 1. key-value-databases 2. documentdatabases 3. kolomgeoriënteerde databases 49 KEY-VALUE-DATABASES Structurele aspecten Eenvoudig key-value-database bestaat uit een dictionary die is opgebouwd uit een verzameling van records die een (sleutel, waarde)-structuur hebben. De waarde van het sleutelveld moet uniek zijn Kan samengesteld zijn uit meerdere velden Waardeveld moet ongeïnterpreteerde waarde bevatten die een willekeurige lengte en inhoud mag hebben. (waarde wordt niet geïnterpreteerd door dbms) Waarde heeft geen specifieke structuur Dumpen: deze database is bedoeld om zeer snel data weg te schrijven. De verantwoordelijkheid voor interpretatie ligt bij de applicatie. Geen faciliteiten om verwantschappen tussen records expliciet te modelleren. Als je dit wil doen moet dit via applicatiecode Gedragsaspecten De interactie gebeurt via een heel eenvoudige API (Application Program Interface) CRUD-operatoren (Creation, Retrieval, Update, Deletion) § get(sleutel): zoekfunctie geeft waarde terug. Sleutel wordt als parameter meegegeven § put(sleutel, waarde): toevoegfunctie, voegt een nieuw record met sleutel “sleutel” en waarde “waarde” toe aan de dictionary. § delete(sleutel): verwijderfunctie, verwijdert het record met sleutel “sleutel”. Er is geen functie voor UPDATE om de gegevens aan te passen à verwijder, put Bieden geen faciliteiten voor ad-hoc-opzoekingen en data-analyse. Werkt snel door het bijhouden van een index Voorbeeld samengestelde sleutel: bezoekersidentificatie ‘BID’ en tijdstipindicatie ‘tijdstip’ instructies: Get (B2, 15/1 : 14u02): wat voor bezoeker heeft deze locatie dan bezocht? Put (B3, 15/1 : 14u05, 'zaal 1, Wauw!') Delete (B1, 15/1 : 14u02) 50 Opslagaspecten Men verkiest beschikbaarheid boven consistentie à AP-ontwerp (Beschikbaarheid/Partitietolerantie). Om de beschikbaarheid te garanderen wordt er gewerkt met een gedistribueerde dataopslag. Elk record wordt een aantal keer gerepliceerd en op gebalanceerde wijze gedistribueerd over het secundair geheugen. Voorbeelden: Dynamo, Voldemort, Tokyo Cabinet, Redis, MemcachedDB, Scalaris DOCUMENTDATABASES Structurele aspecten § Opgebouwd uit documenten, bestaande uit componenten die elk een naam en waarde hebben. § Elk document heeft een sleutelcomponent met unieke waarde, uniek voor de volledige database. § Elke component heeft een unieke naam binnen het document. § De documenten hebben geen vaste structuur (dus geen vast databaseschema): § elk document kan een andere structuur hebben de structuur van een document kan gemakkelijk gewijzigd worden een component zonder waarde kan je gewoon weglaten (geen null- of defaultwaarden nodig) een document kan een complexe datastructuur hebben (kan ingebedde documenten bevatten en kan refereren aan (de sleutelwaarde van) andere documenten) § document worden gespecificeerd volgens een gestandaardiseerd gegevensformaat zoals JSON (JavaScript Object Notation) of XML (Extensible Markup Language). § Bij sommige systemen kunnen documenten gegroepeerd worden in benoemde documentcollecties. Bij sommige van die systemen kan een document tot meerdere documentcollecties behoren. Geen behoefte aan NULL waarden of defaultwaarden (bij ontbrekende info laat je het gewoon weg) Voorbeelden: CouchDB, MongoDB en RavenDB Voorbeeld Registratiesnelheid is niet het probleem nu, maar de grote variëteit aan datastructuren à bezoekersopinie registreren in een documentdatabase (JSON) 5 documenten: Links (2 doc’s): info over bezoekers Rechts (3 doc’s): opinieregistraties Elk document heeft een uniek sleutel: id In het bovenste links inbedded adresdocument § inbedded indien klein doc In he bovenste rechts een reference naar bezoekers § meerdere opiniedoc van dezelfde bezoeker kunnen zijn (onnodige duplicaten vermijden) 51 Gedragsaspecten Alle interacties moeten via API gebeuren. Operaties geavanceerder à CRUD § create: nieuw doc met insert-operator § retrieval: zoekoperatoren met find-operator § update: aanpassen met update-operator § deletion: remove-operator Opslagaspecten § meestal AP-ontwerp (Beschikbaarheid/Partitietolerantie). § beschikbaarheid wordt gerealiseerd d.m.v. gedistribueerde dataopslag: de data worden een aantal keer gerepliceerd. § Meestal 'meester-slaaf'-replicatie: Elk gegeven wordt naar één hardware-knoop, de 'meesterknoop' voor dat gegeven genoemd, weggeschreven. De meesterknoop is daarna verantwoordelijk voor het asynchroon (niet- gelijklopend) repliceren van het gegeven naar de slaafknopen. Het gegeven kan zowel gelezen worden vanaf de meesterknoop als vanaf een slaafknoop. Als je leest van een slaafknoop is consistentie niet gegarandeerd. § Gebalanceerde distributie: De hardware-knopen worden gegroepeerd in zogenaamde shards. Elke shard is verantwoordelijk voor het beheer van een deel van de documenten (met 'meester- slaaf'-replicatie). De documenten worden zodanig verdeeld over de shards dat elke shard een gelijke bezetting krijgt in verhouding tot zijn opslag- en verwerkingscapaciteit. (Sharding maakt de bevraging en het beheer van een database complexer.) § De documenten worden gewoonlijk gesorteerd opgeslagen op basis van de waarden van een geschikte component, voor efficiënte uitvoering van de belangrijkste (zoek)operaties. 52 KOLOMGEORIËNTEERDE DATABASES Structurele aspecten § Qua complexiteit kan je het databasemodel voor kolomgeoriënteerde databases plaatsen tussen het databasemodel voor key-value-databases en het databasemodel voor documentdatabases. § Net als bij het relationeel databasemodel worden de data gestructureerd in relaties die je kan voorstellen als tabellen. § Bij relationele databases: in de rijgeoriënteerde relatie stelt elke rij een entiteit voor. De relatie heeft een vast relatieschema die de attributen van alle entiteiten uit de relatie beschrijft. § Bij kolomgeoriënteerde databases: in de kolomgeoriënteerde relatie stelt elke rij slechts een component (attribuut) van een entiteit voor. § De entiteitscomponenten worden gewoonlijk gegroepeerd in kolomfamilies. De regel daarbij is dat je componenten samenbrengt in dezelfde kolomfamilie als die frequent samen worden opgevraagd of aangepast. § Elke kolomfamilie heeft een vaste structuur: een attribuut Rij_id die de rijsleutel (niet uniek!) genoemd wordt (om te zien welke rijen betrekking hebben op dezelfde entiteit) een attribuut Kolomnaam voor de naam van de component een attribuut Kolomwaarde voor de waarde van de component doorgaans ook een attribuut Versie voor versiebeheer (om de geschiedenis van aanpassingen bij te houden) § Er is geen vast databaseschema waarin vastgelegd is welke componenten moeten zijn opgenomen in een kolomfamilie. Als gegevens ontbreken, neem je de betreffende component niet op. § Heb je een meerwaardige component dan voeg je voor elke waarde een rij toe aan de kolomfamilie. (zie in voorbeeld: meerdere rijen voor 'naam' van 'B2' in kolomfamilie 'Bezoeker' en voor 'commentaar' van 'O2' in kolomfamilie 'Opinie‘) § Refereren is mogelijk door een rijsleutel als kolomwaarde mee te geven. (zie in voorbeeld: component 'bezoeker_id‘ in kolomfamilie 'Opinie‘) Dergelijke rijsleutelwaarden worden niet gecontroleerd of consistent gehouden door het dbms. § Versie: geschiedenis bijhouden Voorbeelden: MonetDB, Vertica, HBase, Hypertable, Cassandra en Druid Gedragsaspecten werken via API § Get (Kolomfamilie, Rij_id, Kolomnaam, Versie) : zoekfunctie geeft rijen terug uit kolomfamilie waarvoor rij_id § Insert (Kolomfamilie, Rij_id, Kolomnaam, Versie, waarde) : attribuutwaarde wordt meegegevn § Delete (Kolomfamilie, Rij_id, Kolomnaam, Versie, waarde): 53 SQL-based eenvoudige selects (Creation, Retrieval, Update, Deletion) § SELECT taal FROM Bezoeker WHERE naam = 'Yana': geef taal van bezoeker Yana § SELECT commentaar FROM Opinie WHERE score < 5: geef commentaren waarbij score < 5 § SELECT COUNT(*) FROM Opinie WHERE dag = '15/1/2016': geef aantal opinieregistraties op die datum § Zoekopdrachten worden versneld d.m.v. indexen: elke kolomfamilie is geïndexeerd met een samengestelde index over haar attributen 'Rij_id', 'Kolomnaam' en 'Versie'. Daarnaast kan een DBA zelf indexen aanmaken. Je hebt daarbij de mogelijkheid om een index te bouwen over een component (van een entiteit). Het dbms neemt dan in deze index enkel de rijen op die de component als 'Kolomnaam' hebben. Zo kan je bijvoorbeeld een index bouwen voor de 'plaats'-component van de kolomfamilie 'Opinie'. § Als je slechts informatie van een beperkt aantal componenten (attributen) nodig hebt, verloopt het zoeken in een kolomgeoriënteerde database veel efficiënter dan zoeken in een relationele database. Het dbms hoeft dan immers geen volledige tuples in te lezen en verwerken, maar kan zich beperken tot de data van de betreffende component. § Als er veel componenten (attributen) zijn waarvoor de data ontbreken, wat het geval is bij sterk gevarieerde dataformaten, is schrijven naar een kolomgeoriënteerde database efficiënter dan schrijven naar een relationele database. Opslagcapaciteiten § meestal AP-ontwerp (Beschikbaarheid/Partitietolerantie). § beschikbaarheid wordt gerealiseerd d.m.v. gedistribueerde dataopslag: § meestal één databestand per kolomfamilie § evt. worden de rijen uit de kolomfamilietabel alfabetisch- lexicografisch geordend opgeslagen, volgens de attributen Rij_id, Kolomnaam en Versie. § verder kan elk bestand via een soort van horizontale fragmentatie worden opgedeeld in tablets, die gerepliceerd en gedistribueerd worden over de hardware-knopen van het telecommunicatie- netwerk. Er kunnen duizenden hardware-knopen zijn. VERGELIJKING Prestatie hoe snel zijn schrijf- en leesoperaties?(velocity) Schaalbaarheid kan je het volume aan data gemakkelijk uitbreiden? (volume) Flexibiliteit kan de structuur van de data gemakkelijk worden aangepast? (variety) Complexiteit hoe complex is het databasemodel? Functionaliteit hoe uitgebreid zijn de datamanipulatie- en zoekfaciliteiten? 54 Keuze van databasetechnologie voor 'big' data: afhankelijk van de toepassing. Kiezen voor systeem met CP-strategie of AP-strategie? § Er bestaat veel variatie in de mate waarin consistentie (C) en beschikbaarheid (A) worden afgedwongen. § Algemeen geldt dat hoe groter de C is, hoe kleiner de A is en omgekeerd, maar een strikte opdeling in CP- of AP-systemen heeft praktisch gezien geen zin. Als consistentie belangrijk is: § Kies een NoSQL-systeem waarin AClD- transacties worden ondersteund § Dit zal wel gepaard gaan met tragere uitvoeringstijden. § Voorbeelden van dergelijk systemen zijn Oracle Berkeley DB en Aerospike. OVERIGE ASPECTEN VAN BIG DATA-OPLOSSINGEN Big data: § Grote datavolumes § Grote variëteit aan datastructuren § Snelle verwerkingstijden § Niet-gegarandeerde waarheidsgetrouwheid stelt ook uitdagingen op het vlak van volgende aspecten: § Dataverwerking § Datapresentatie § Juridische aspecten Dataverwerking: data-analyse, recommender systems, decision support systems,... Gedistribueerde dataverwerking: § Schaalbaar telecommunicatienetwerk waarbij de hardwareknopen tegelijkertijd elk een deel van de analysetaken op zich nemen. Door de schaalbaarheid kan je gemakkelijk nieuwe knopen en dus ook extra rekenkracht toevoegen. § Conventionele taken van een data-analyseopdracht zodanig te reorganiseren dat ze gemakkelijk kunnen worden opgesplitst in deeltaken, die dan elk aan een andere knoop kunnen worden aangeboden. Alle knopen verwerken parallel hun deeltaak, waarna de resultaten worden samengebracht. § Als een knoop faalt en zijn deeltaak niet kan uitvoeren, wordt deze deeltaak automatisch overgenomen door een andere knoop. Conventionele data-analysetaken moeten dus zodanig gereorganiseerd worden dat ze gemakkelijk kunnen worden opgesplitst in deeltaken. Voorbeeld: Google MapReduce Datapresentatie : § Vaak is tekstuele representatie ongeschikt § Visuele dataweergave (datavisualisatie, een specialiteit op zich) is vaak meer aangewezen. 55 juridische aspecten: § Bescherming van persoonlijke data (GDPR,…) § e-privacy (wat te doen met klikstroomdata en gps-data?), § Sectorspecifieke wetgeving (bijvoorbeeld de wetgeving voor de medische sector, telecommunicatiesector en energiesector), § Anti-discriminatie en ethische kwesties (het is bijvoorbeeld belangrijk dat de 'big' data- analyse geen personen discrimineert), § Concurrentieregelgeving (mogen 'big' data-analyses worden gebruikt om bepaalde klanten een voordeligere prijs voor hetzelfde product aan te bieden?) en § Eigendom van de data (wie is eigenaar van de inkomende data en de verwerkte data?) NEWSQL Dezelfde schaalbaarheid en lees-& schrijfprestaties als NoSQL-systemen, maar daarnaast toch ACID-compliance als SQL-systemen § Gebaseerd op het relationeel databasemodel § SQL-querytaal als primaire interface § Zeer veel, kortdurende, repetitieve acties die elk slechts een klein deel van de data aanspreken Voorbeelden: H-Store/VoltDB, Google Spanner, ClustrixDB, MemSQL, ScaleBase 56