De afgelopen jaren zijn door grote internetbedrijven en binnen de opensource-community technieken ontwikkeld, die het mogelijk maken om grote hoeveelheden data te verwerken. Dit wordt Web-scale IT genoemd en parallellisatie is hierbij een belangrijke term. In deze sessie bespreken we de technologie die bedrijven als Google, Twitter, Netflix en Facebook toepassen om grote hoeveelheden data te verwerken. We bespreken technieken als Hadoop Storm en HDFS, Akka Reactive Streams, HBase, Redis, Cassandra, Memcached en Apache Thrift. Verder laten we een aantal belangrijke strategieën zien zoals sharding, load balancing, caching, CQRS en NoSQL. Vervolgens bespreken we een aanpak om Web-scale technieken toe te passen binnen een bestaande IT architectuur. Hoe kun jij de Web-scale technieken toepassen binnen je huidige klus?
3. Quintor
Load balancing
Requests
verspreiden over
meerdere
servers/nodes/data
centers.
Op basis van:
- Round Robin
- Geo locatie
- Least connection
HAProxy
Nginx
Amazon
ELB
HAProxy beschikt
over de meeste
mogelijkheden (SSL
support in
onwikkeling)
Nginx erg geschikt
voor high load en
biedt SSL support
Amazon ELB, goede
keuze bij gebruik van
AWS
4. Quintor
Caching
Ontlasten van
backend systemen
en versnellen van
applicatie.
Is een goede
aanvulling op
nagenoeg elke
applicatie
Memcached
Redis
Memcached erg
eenvoudig in gebruik en
beheer.
Redis bevat meer
datatypes en complexe
methodes die het
bruikbaar maken voor
meedere doeleinden.
Top 10 lijsten,
publish/subscribe etc.
Vb:
Twitter bewaart
timelines alleen in
Redis
5. Quintor
Content delivery network
Verlagen van
netwerk latency bij
het serveren van
Statische content
(HTML/CSS/foto's/
video's)
Veel CDN
aanbieders
beschikbaar:
Amazon
Cloudfront
Microsoft
Azure
Gebruikt servers
verspreid over
groot gebied zodat
klanten met hoge
availability en
snelheid diensten
kunnen gebruiken.
7. Quintor
No SQL
Gedistribueerde
database gebaseerd op
HDFS. Gebaseerd op
BIGTABLE.
Gedistribueerde
database over
gelijkwaardige nodes.
Meerwaarde bij
miljarden records en
minimaal 5 nodes.
CQL3 interface heeft veel
overeenkomsten met
“SQL”
JDBC driver beschikbaar
Zeer geschikt voor
datasets die veel
wijzigen. Volledig in
memory.
In-memory database
met disk persistence
HBase
Cassandra
Redis
9. Quintor
Sharding
Horizontaal partitioneren
van database,
verschillende rijen in
verschillende databases
met zelfde schema.
Noodzakelijk wanneer
een database node niet
meer toereikend is.
WebscaleSQL/Gizzard
Custom sharding
Backend met sharding
features bv MongoDB,
Hbase.
WebscaleSQL is
gebasseerd op MySQL.
Sharding vindt vaak
plaats op basis van
geografische locatie.
Bestaande relationeel
model blijft bruikbaar.
17. Quintor
HDFS
• Namenode: HDFS master. Bewaart complete directory tree van het file system. Bepaalt waar
blokken data worden opgeslagen en gerepliceerd. Slaat zelf geen inhoudelijke data op (alleen
verwijzingen)
• Datanode: Slaat data op in het hadoop filesystem. Wordt gestuurd door de namenode welke
data hij op moet slaan.
• Clients: vragen aan de Namenode locatie van de data, en brengen/halen de data naar/van de
Datanode
19. Quintor
YARN / Map Reduce Architecture
• Resource manager: Het proces dat de resources in het cluster verdeeld over de diverse nodes
• Node Manager: Het proces dat de status van de node monitored (CPU, memory, disk,
netwerk) en dit communiceert met de resource manager
• Application Master: Per map reduce job is er 1 Application master die het werk verdeeld over
de diverse nodes, en dit afstemt met de resource manager
21. Quintor
HBase
• HMaster:
– Coördinatie
– monitoring van het cluster
– verdeelt regions
– load balacing en failover
• HRegionServer
– opslag van region
– distributie van regions
– verwerken van lees-/schrijfacties
– communicatie met clients
24. Quintor
MapReduce
Map
Verdeel de data in kleinere brokken
Shuffle
Verzamel de brokken op basis van
sleutel
Reduce
Filter de relevante data
25. Quintor
public class Map extends MapReduceBase
implements Mapper<LongWritable, Text, Text, IntWritable> {
private final static IntWritable one = new IntWritable(1);
private Text word = new Text();
public void map(LongWritable key, Text value,
OutputCollector<Text, IntWritable> output, Reporter reporter)
throws IOException {
String line = value.toString();
StringTokenizer tokenizer = new StringTokenizer(line);
while (tokenizer.hasMoreTokens()) {
word.set(tokenizer.nextToken());
output.collect(word, one);
}
}
}
26. Quintor
public class Reduce extends MapReduceBase
implements Reducer<Text, IntWritable, Text, IntWritable> {
public void reduce(Text key, Iterator<IntWritable> values,
OutputCollector<Text, IntWritable> output, Reporter reporter)
throws IOException {
int sum = 0;
while (values.hasNext()) {
sum += values.next().get();
}
output.collect(key, new IntWritable(sum));
}
}
29. Quintor
Ambari
• Provisioning van Hadoop Services op kale linux machines
• Prerequisited
– FQDN
– DNS en reverse DNS
– NTP
– SSL public key van Ambari in authorized_keys
33. Quintor
Storm
• Nimbus: daemon voor de master node (vergelijkbaar met de application manager in
MapReduce)
• Supervisor: daemon voor de worker node. Luistert naar taken dat is toegewezen aan zijn
machine door de master node (nimbus). De supervisor start processen om deze taken uit te
voeren.
• Zookeeper: bewaart de state van de communicatie tussen de nimbus en de supervisor(s),
zodat deze alleen de processen uitvoeren, en dus stateless blijven
Bij toename van aantal request willen we de load verdelen er van uitgaande dat je applicatie stateless is en ook schaalbaar is.
Verschillende opties, Bv AWS ELB (elastic load balancer), Nginx (engine-x) en HAProxy. Als je host in AWS dan is ELB een voor de hand liggende keuze. Algorithm Options
HAProxy has the most options in this arena, support Round-Robin, Least Connection, Weighted and more.
Nginx supports Round-Robin and Least connected (active connections) en ip-hashed .
AWS ELB only supports Round-Robin.
- See more at: http://mervine.net/comparing-load-balancing#sthash.JrFuLKnC.dpuf
Monitoring voor HAProxy en Nginx: Scout
Goede toevoeging voor elke webapplicatie. Als we writes acties meerdere keren willen lezen is het verstandig deze gegevens te cachen. Memcached is een goed voorbeeld een eenvoudige cahce mechanisme (verwijzing presentatie Aschwin) waamee je een roundtrip en daarmee belasting op backend eenvoudig kunt verminderen (nog maar 10%). Redis is nog iets geavaceerder waarmee het ook mogelijk wordt om iets complexere structuren te cachen waamee ook latest comments en tweet timelines volledig en eenvoudig uit cache te achterhalen zijn.
Na sharding komen de NoSQL oplossing als praten over grote hoeveelheden gegevens dan is sharding op termijn ook geen haalbare oplossing meer en betere BigData oplossingen zoals Hadoop en Google BigTable zijn er goede oplossingen beschikbaar. Bijvoorbeedl HBase een database gebasseerd op het BiGTable principe en goed bruikbaar wordt bij erg grote datasets denk aan honderden of biljoenen records.
HBase
Automatic sharding van tables in regions (automatische split en re-distrubution)
Hadoop/HDFS integration standaard
Java client API
Thrift/REST api
Wanneer toepasbaar:
Is goed toepasbaar bij veel data “Big Data”, Dus bij honderden miljoenen of biljoenen records. Bij een paar duizend/miljoen rijnen dan is RDBMS waarschijnlijk een beter keuze.
Accumulo is ook nog een BigTable clone met cell based security afkomstig vanuit NSA
Cassandra is ook geavanceerde gedistribueerde database over vergelijkbare nodes waarvan elke node de coordinatie voor zijn rekening kan nemen. De interface zal veel mensen herkenbaar zijn. Namelijk “SQL like” op joins na welliswaar.
Availability
- Je data is ten alle tijden beschikbaar en hier mag niet van afgeweken worden
Partition tolerance
- Je data blijft (oneindig) groeien en hier moet je mee om kunnen gaan
Consistency
- Iedereen ziet ten alle tijde dezelfde data, eventualy consistent is not an option
Op het moment dat de hoeveel gegevens van je RDBM niet meer op een node te hosting valt (niet meer te schalen) of te kostbaar is het mogelijkheid om de relationeel model op de delen in kleinere delen “Shards”. Zie voorbeeld Twitter en het gebruik van Gizzard.
Sharding vindt ook plaats maar dan onderdeel van BigData oplossing zoals Hbase, MangoDB etc…
CQRS is een eenvoudig pattern: scheiden van verantwoordelijkheden in een deel dat wijzigingen doorvoert (het Command-gedeelte) en een deel dat data ophaalt (het Query-gedeelte)
“achieve scalability, manage complexity, and manage changing business rules”
Optionele slide.
In veel systemen is er een duidelijk verschil tussen het aantal reads en writes.
Toch behandelen we deze mechanismen vaak op grotendeels dezelfde manier; met een business-laag, een ORM, etc.
Daarnaast zijn databases meestal geoptimalizeerd voor het wijzigen van de gegevens (3NF).
CQRS stelt dat deze 2 kanten van een system verschillend zijn; en waarom deze dan niet optimalizeren voor hun taak.
CQRS schrijft niet voor hoe deze 2 kanten geïmplementeerd moeten worden.
dit kan met één database, maar b.v. verschillende data-access implementaties
of, zoals in dit voorbeeld, met b.v. 2 verschillende databases; waarbij het database-schema gelijk kan zijn, maar ook verschillend
zo zijn er veel meer mogelijkheden om beide kanten te optimalizeren voor hun rol in het system
Event Sourcing = de historie van de state van een applicatie opslaan, waarmee de huidige state bepaalt kan worden
Voorbeeld:
zonder ES: totaal beschikbare aantal van artikelen, b.v. een boek, opslaan en wijzigen bij inkoop en verkoop.
met ES: alle events, dus iedere inkoop- en verkoop-actie, opslaan; beschikbare aantal bepalen door al deze events ‘af te spelen’.
Elke actie op het systeem (event) heeft context. Als een wijziging is doorgevoerd in een traditioneel systeem, is deze context vaak verdwenen. Bij ES is deze context altijd beschikbaar.
Met ES worden alle wijzigingen als een command uitgevoerd.
De commands resulteren in events. Alle events worden opgeslagen.
De events kunnen worden gebruikt om de state van de applicatie te bepalen.
De events worden ook afgehandeld door event-adapters. Deze adapters werken de data-stores bij aan de query-kant.
De adapters kunnen een relationele database bijwerken, met een schema dat is geoptimaliseerd voor het lezen van data.
Maar de adapters kunnen ook de resultaten klaarzetten zoals deze door de service-interface worden opgeleverd; b.v. kant-en-klare HTML-fragmenten en JSON-documenten.
Met CQRS en event sourcing is het mogelijk om bestaande legacy-systemen te ontlasten en de overall performance te verbeteren.
Word count
Meerdere MapReduce processen achtereenvolgens
Word count
Meerdere MapReduce processen achtereenvolgens
Word count
Meerdere MapReduce processen achtereenvolgens
