Téléchargé 60 fois
Téléchargé parAlexander DEJANOVSKI
Big Data Paris 2015 - Cassandra chez Chronopost
Chronopost utilise Cassandra pour gérer en temps réel 1,5 milliard d'événements par an, améliorant ainsi l'efficacité de ses livraisons à l'international. Le document décrit les avantages de Cassandra, notamment sa simplicité, tolérance aux pannes et scalabilité, ainsi que les résultats optimaux obtenus en production. Chronopost continue d'évoluer vers des solutions de stockage axées sur le temps réel et des analyses approfondies grâce à sa stack analytique.
Contenu connexe
![[Infographie #5] comment organiser votre équipe de marketing relationnel](https://cdn.slidesharecdn.com/ss_thumbnails/infographiecommentorganiservotrequipedemarketingrelationnel-130417105159-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Big Data Paris 2015 - Cassandra chez Chronopost
- 1. Cassandra chez Chronopost pourtraiter en temps réel 1,5 milliard d’événements par an
- 2. Alexander DEJANOVSKI Qui suis-je? • Ingénieur EAI • Depuis 15 ans chez Chronopost •@alexanderDeja
- 3. Leader de lalivraison express de colis jusqu’à 30 kg aux entreprises comme aux particuliers partout dans le monde, Chronopost s’appuie sur en France sur un réseau constitué de 75 sites opérationnels et 7 hubs. Chronopost dessert plus de 230 pays en Europe et dans le monde. Chronopost International Notre métier En 2014 : 3 500 salariés Plus de 60 000 entreprises clientes 4 500 tournées de livraison par jour 114,5 millions de colis livrés 230 pays desservis 33% des colis livrés en BtoC 25% de son CA à l’International
- 4.
- 5. • TIBCO BusinessWorks •750 000 échanges/j • 3M d’étapes/j Flux EAI chez Chronopost
- 6. Développement interne :FLUKS Base relationnelle Suivi des flux EAI
- 7.
- 8.
- 9.
- 10.
- 11. • Contentions • Latences •Statistiques Problèmes
- 12. • Portage • Scalabilité •Open Source Proposition d’un PoC NoSQL sur Fluks
- 13. Hadoop HBase Cassandra Hypertable Accumulo Cloudata Cloudera MonetDB HPCC Apache Flink Splice Machine MongoDB Lajungle « NoSQL/Big Data » #CassandraSummit Elasticsearch Couchbase CouchDB RethinkDB RavenDB MarkLogic Server Clusterpoint Server NeDB Terrastore AmisaDB JasDB RaptorDB djondb EJDB densodb SisoDB SDB ThruDB iBoxDB DynamoDB Riak Redis Aerospike FoundationDB LevelDB Berkeley DB Oracle NOSQL GenieDB BangDB Scalaris Scalien Voldemort Dynomite KAI MemcacheDB Spark …. http://nosql-database.org/ liste + de 150 bases NoSQL
- 14. • HBase • Cassandra •MongoDB Notre short list
- 15.
- 16. • Simplicité • Réplication •Tolérance aux pannes • CQL • JDBC • Scalabilité Pourquoi Cassandra ?
- 17. Partition et réplication ReplicationFactor = 3 3 répliques de chaque enregistrement
- 18.
- 19.
- 20. • Cré ationde table : – CREATE TABLE ma_table( id int, value text, PRIMARY INDEX(id) ); • Requêtage des donné es : – SELECT * FROM ma_table WHERE id=? CQL = Cassandra Query Language
- 21. • Pas derelations • Dénormalisation • Clauses WHERE limitées • Requêtes analytiques Il faut réapprendre certaines choses…
- 22.
- 23. • Driver JDBCCassandra (TIBCO/IHM) • Guava • 2 mois / 1 personne Portage de Fluks
- 24. • Serveurs décommissionnés •Août 2014 : 1ère infrastructure • Avril 2015 : évolution Passage en production
- 25. • Plus decontention • Stats temps réel • RDBMS : 100-120ms / message • Cassandra : 16-20ms / message Résultats en production
- 26. Comparatifs des tempsd’intégration
- 27. • Dans laversion relationnelle : – Batch – Recalculs à la demande • Avec la monté e en charge : – Durée++ – Perturbation insertions Des stats temps réel ?
- 28. • Type «counter »de Cassandra – Incré mentation/Dé cré mentation : UPDATE ma_table SET my_counter = my_counter + 10 WHERE ma_cle=1 • Le truc génial ? – UPDATE = INSERT – Enregistrement cré é s’il n’existe pas Des stats temps réel ?
- 29. Attention : – Cassandra< 2.1 = compteurs approximatifs • rejeux • OK pour des stats Des stats temps réel ?
- 30.
- 31. • Base Cassandraalimentée depuis notre Base Colis – Toutes les Informations colis – Tous les événements Vision
- 32. • 2 nouvellesoffres Chronopost à la rentré e • Stockage Cassandra • Accent fort sur le temps réel • Stockage en « time series » Vision
- 33.
- 34. • Apache Spark1.2 • Cassandra (via connecteur Spark Datastax) – Analyse sur profondeur réduite (opérationnel) • HDFS – Analyse sur profondeur étendue (archivage) • Dataiku Notre stack analytique « Big Data »
- 35.
- 36. • Non maintenu •Limité • Cassandra <= 1.2 • Datastax Java driver Le driver JDBC « legacy »
- 37. • Cassandra 2.0/2.1 •Load balancing • Disponible sur code.google.com • Google : « cassandra jdbc » • API Thrift Mise à jour du driver JDBC « legacy »
- 38. • Réécriture • IntégrationDriver Java Datastax • Disponible sur github.com/adejanovski Nouveau driver JDBC
- 39.
- 40. Load balancing policies: Token Aware Policy
- 41. Load balancing policies: DC Aware Policy
- 42. Load balancing policies: DC Aware Policy
- 43. • Datastax pour: – Son invitation aujourd’hui – Sa contribution au code source Cassandra (>80%) – Son animation de la communauté Cassandra • Vous pour : – M’avoir é couté jusqu’au bout Remerciements
- 44.