Big Data System Design

Architecturen en ADD

Roelant Ossewaarde en Jos van Reenen, B 2019-2020

1 Architectural Design

Het boek van Kazman (Link naar ebook) gaat over een strategie om architecturen te ontwerpen.

kazman_fig_2_1.jpg

Figure 1: Architecture Design (Kazman, fig. 2.1)

1.1 Technology family tree voor Big Data

kazman_fig_2_10.jpg

Figure 2: Technology family tree for Big Data (Kazman, fig. 2.10)

"Architectural design is, therefore, a key step to achieving your product and project goals. Some of these goals are technical (e.g., achieving low and predictable latency in a video game or an e-commerce website), and some are nontechnical (e.g., keeping the workforce employed, entering a new market, meeting a deadline)."

2 Bepalen van requirements

Gebaseerd op hoofdstuk 5 van "Designing Software Architectures" (Cervantes & Kazman 2016).

Business case: Een Internet bedrijf bedient veel klanten dmv. online-content (vgl. reddit). Al hun systemen maken logs aan met gegevens over de systemen, gedrag van gebruikers, etc. Deze logs worden gebruikt om bedrijfsprocessen bij te sturen.

De infrastructuur groeit hard; er is behoefte aan een nieuw systeem waarmee de verschillende stakeholders inzicht kunnen krijgen in de gelogde gegevens.

2.1 Marketecture

kazman_fig_5_1.jpg

2.2 Use case model

  1. UC-1: Monitor online services

    Mensen van operations moeten de huidige staat van de diensten en infrastructuur kunnen monitoren (zoals web load, aantal gebruikers, etc) op een real-time dashboard.

  2. UC-2: Troubleshoot online service issues

    Als er problemen zijn, moeten systeembeheerders snel door recente logs kunnen zoeken naar relevante berichten over het systeem.

  3. UC-3: Provide management reports

    Voor managementrapportages moeten er over een lange termijn logs opgevraagd kunnen worden over bijvoorbeeld het gebruik van de infrastructuur en knelpunten.

  4. UC-4: Support data analytics
  5. UC-5: Anomaly detection
  6. UC-6: Provide security reports

2.3 Quality attribute scenarios

  1. QA-1 Performance

    Het systeem moet 15000 events per seconde van ongeveer 300 web servers kunnen afhandelen.

  2. QA-2 Performance

    Het systeem zal het dashboard updaten met maximaal 1 minuut vertraging (latency).

  3. QA-3 Performance

    Het systeem zal real-time queries ondersteunen voor troubleshooting met een maximum query tijd van 10 seconden over data van 2 weken terug in het verleden.

  4. QA-6 Schaalbaarheid

    Het systeem zal ruwe data voor de laatste 2 weken apart beschikbaar stellen voor full-text searches.

  5. QA-7 Schaalbaarheid

    Het systeem zal ruwe data opslaan voor de afgelopen 60 dagen (1 Tb ruwe data per dag, 60 Tb ruwe data totaal).

2.4 Constraints

  1. CON-1 Gebruik open source

    Vanwege kostenoverwegingen zal het systeem primair gebruik maken van Open Source software.

  2. CON-2 Gebruik visualizatie

    Het systeem zal gebruik maken van een corporate BI-tool met een SQL-interface voor het visualizeren van informatie.

  3. CON-3 Deployment

    Het systeem zal zowel in een private cloud als in een publieke cloud geïntegreerd kunnen worden. Architectuurbeslissingen moeten zo min mogelijk vendor-specifiek (Google, Amazon) zijn.

3 Design proces:

kazman_fig_3_1.jpg

Figure 4: Steps and artifacts of ADD (Kazman, fig. 3.1)

3.1 Stappen in Iteratie #1

  1. Review Inputs

    Bepaal welke use cases significant zijn.

  2. Bepaal het doel van de iteratie op basis van de drivers

    De drivers zijn de kwaliteitsattributen en constraints die van belang zijn voor de significante use cases (uit stap 1).

  3. Kies elementen van het systeem om over te besluiten

    In een eerste iteratie is dat het hele systeem.

  4. Kies design concepten voor de gekozen drivers uit stap 2.

    Geef ook een reden waarom je voor andere mogelijke design concepten niet hebt gekozen. Relevante designkeuzes voor databasetechniek: Reference architectures for Data Analytics.

  5. Bepaal verantwoordelijkheden en interfaces

    In een eerste iteratie nog niet relevant.

  6. Schets architectuur en documenteer beslissingen.
  7. Review

4 Referentiestructuren

Er zijn verschillende keuzes te maken over met name data opslag en analyse bij het opstellen van een architectuur:

reference-architecture.png

NB terminologie:

  • Extract Transform Load
  • MPP: Massively Parallel Processing: problemen waar verschillende CPU's tegelijk aan kunnen werken.

5 Pure Relational

reference-architecture-pure-relational.png

Bekende technologie: MySQL, PostgreSQL, MSQL.

De ETL en messaging vinden plaats in het RDBMS. Als er een voorbewerking van de data plaats vindt buiten het database-systeem (bijvoorbeeld door scripts), dan is het een 7.

5.1 Relationele data model

Gebaseerd op set theorie:

  • Selectie (welke rijen)
  • Projectie (welke kolommen)
  • JOIN (cartesisch product)
  • Klassieke set-operaties

relationalmodel1.png

5.2 Data integriteit slechts gegarandeerd door design (normalizatie)

Data anomalies worden voorkomen door redundantie te verminderen.

Daardoor een grotere hoeveelheid tabellen (want tabellen vaker opgesplitst).

5.3 Transaction lifecycle

transaction_lifecycle.png

5.4 Concurrency Issues - Dirty reads

Verschillende transacties tegelijk kunnen leiden tot 'dirty reads'.

concurrency_1.png

Figure 9: Concurrency issue: interleaving

De eerste transactie vraagt iets ('status') van de database, is VALID op dat moment. Binnen die transactie wordt de status op INVALID gezet. De transactie wordt niet afgemaakt, en dus wordt de status weer op VALID gezet.

De tweede transactie leest halverwege de eerste transactie dat de status INVALID is.

5.5 Concurrency Issues - Non-repeatable read.

concurrency_nonrepeatableread.png

Figure 10: Concurrency issue: nonrepeatable read.

De eerste transactie en de tweede transactie lezen allebei dezelfde variabele in. Binnen de eerste transactie wordt dezelfde variabele daarna nogmaals uitgelezen, maar misschien is die variabele inmiddels veranderd.

5.6 Concurrency Issues - phantom read

concurrency_phantomread.png

Figure 11: Concurrency issue: phantom read

Speciaal geval van non-repeatable read: de eerste transactie leest iets, en terwijl die transactie nog niet is afgelopen, verandert transactie 2 de database. Transactie 1 en transactie 2 hebben nu een verschillend beeld van de inhoud van de database.

5.7 Verschillende niveaus van isolation maken database consistenter

Isolation level Dirty reads Non-repeatable reads Phantom reads
serializable ✘ ✘ ✘
Repeatable reads ✘ ✘ ✓
Read committed ✘ ✓ ✓
Read uncommitted ✓ ✓ ✓

Voorbeeld: als de database transacties isoleert op het niveau van read uncommitted (het laagste niveau) dan kunnen er dirty reads, non-repeatable reads en phantom reads plaatsvinden. Op het hoogste niveau van transactie isolatie (serializable) kan dat niet.

Maar: hoe hoger het niveau van isolatie, hoe moeilijker de database schaalbaar wordt.

5.8 Schaalbare systemen

scalability_vertical.png

Vertical Scaling:

  • Add resources to a node
  • Increase capacity
  • Load unaffected
  • System complexity unaffected
  • AKA Scale-Up

scalability_horizontal.png

Horizontal Scaling

  • Add nodes to a cluster
  • Capacity unaffected
  • Decreased Load
  • Availability and throughput with increased complexity
  • AKA Scale-Out

5.9 Hoe kan een RDBMS horizontaal schalen?

scaling_horizontal1.png

Replication

  • Auto-backup
  • Master = SPoF+ bottleneck
  • Synchronization?

Sharding

scaling_horizontal2.png

  • Horizontal partitioning
  • Split rows over nodes
  • Cross-shard joins difficult
  • Optimal sharding?
  • Locality of reference
  • Concurrency is complex
  • Requires coordination

5.10 ACID en Distributed gaan niet goed samen

Want hoe kun je horizontaal schalen en tegelijkertijd database concurrency over verschillende systemen implementeren?

6 Extended Relational

reference-architecture-extended-relational.png

Vooral geschikt voor CPU-intensieve problemen ("Massively Parallel Processing") waarbij het volume data minder ver opschaalt.

Variatie in vorm van queries mogelijk (snel antwoord), maar bottleneck: geen on-disk persistentie.

7 Data refinery

reference-architecture-data-refinery.png

Voorbewerking vindt plaats buiten relationele database. Dat maakt in-memory relationele database mogelijk.

Real-time analyse is beperkt (want er is een voorbewerking), volume is beperkt tot geheugengrenzen, maar wel grote varieteit aan data mogelijk doordat er een uitgebreide voorbewerking mogelijk is.

8 Pure Non-relational

reference-architecture-pure-nonrelational.png

Vooral geschikt als de vorm van queries al vaststaat en het schaalprobleem vooral het volume van de data betreft.

8.1 CAP theorem

cap1.png

8.2 CAP theorem

cap2.png

8.3 NoSQL

Vier belangrijke categorieën:

  • Key-Value stores (Dynamo, Cassandra, Riak, Redis)
  • Document stores (CouchDB, MongoDB, ElasticSearch)
  • Wide column stores (HBase, Cassandra, BigTable)
  • Graph databases (Neo4J, OrientDB)
  • Streaming databases (Spark, Flink)

Vereenvoudigingen:

  1. Geen relationeel model.
  2. In plaats van ACID-properties, BASE:
    1. *B*asically *A*vailable. (data mag verouderd zijn)
    2. *S*oft state (het systeem kan veranderen, heb geen vertrouwen)
    3. *E*ventually consistent. (het duurt soms voordat de database consistent is).

9 Lambda architecture

lambda-architecture.png

Kan alles, schaalt ongelimiteerd. Maar duur in onderhoud, want verschillende databases/codebases/etc.

10 Kappa architecture

kappa-architecture.png

11 Vooruitblik

De hele keten van ontwerp naar implementatie vereist gedegen kennis van de technische mogelijkheden.

In de workshops op vrijdagen gaan we spelen met de verschillende referentiearchitecturen zodat je aan het eind van de cursus een beeld hebt van hoe ze werken.