Big Data AllWeb

Transcript

1. 1 BIG DATA BIG DATA Presentation by Papatheodorou Costas Today's Date Outline Sub Topic 1 Sub Topic 2 Sub Topic 3 Sub Topic 4 Sub Topic 5
2. 2 Today's Date Contents Sub Topic 1 Sub Topic 2 Sub Topic 3 Sub Topic 4 Sub Topic 5 Some jokes to start Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it... Data Scientist (n): A machine for turning data you don't have into infographics you don't care about. When choose database remember Cassandra good in write, HBase good in read, Mongo good in delete Client ask me for some options for keep data in #hadoop safe. I recommend for him several prayer book. hadoop philosophy: "Garbage In, Sorted Garbage Out"
3. 3 Τι ζεί εκει έξω με μια ματιά Today's Date Sub Topic 1 Sub Topic 1 Sub Topic 2 Sub Topic 3 Sub Topic 4 Sub Topic 5 Disclaimer : Not a single line of code written, neither a single shell command executed During this research. Consume responsibly
4. 4 Today's Date Sub Sub Topic DISTRIBUTED FILESYSTEMS Managed Gluster FS Hadoop HDFS Ceph Lustre Rest / Remote Amazon S3 Microsoft Azure Google Cloud Storage Lustre
5. 5 Today's Date Sub Sub Topic HADOOP FAMILY AND FRIENDS Tools Hadoop (Filestorage, batch MapReduce analytics) Spark (In memory data analytics, aggregations) Hive (Sql Like query lang for Hadoop) Pig (Script for data analytics over hadoop) Strorm (Real time data I/O analysis, Analyze before save, Hbase parser) Drill (Sql query language for hadoop, NoSql, Files. Unify any storage) Presto (Sql query language for HDFS, Cassandra, Data abstraction) Impala (Sql query language for hodoop, Hbase) Flume (Log collector, aggregator, store to hadoop) Mahout (Machine Learnign Java Lib. Recomendation) Kafka (Message Queue, Store to disk, Reuse)
6. 6 Today's Date NOSQL DATABASES NoSql Databases MongoDB (Nosql BSON Document Store) Cassandra (Nosql Culumnar DB) Couchbase (NoSql document store) Redis (Key, Val store, “memcached on disk”) ElasticSearch (Document store, Full text search engine) CoucheDB (Document store made for read) Hbase (Nosql Columnar DB for hadoop) InfluxDB (TimeSeries Database, sql like queries) OpenTSBD (TimeSeries Database for hadoop)
7. 7 Today's Date INGESTION AND STREAMING INGESTION AND STREAMING Flume (Log collector, aggregator, store to hadoop) Chukwa (Log collector, aggregator) Kafka (messaging system, OI performance optiomaze, persistand queues) Redis (Key, Val store, “memcached on disk”) Strorm (Real time data I/O analysis, Analyze before save) Logstash (Log collector, aggregator)
8. 8 Today's Date VISUALIZING VISUALIZING Grafana (Visualization for timeseries databases) Kibana (Visualizator for Elasticsearch) Presto (Sql query language for HDFS, Cassandra, Data abstraction) Tableau (Visualization dashboard with many inputs) Mode (Visualization for presto ) SlamData (Visualization for MongoDB )
9. 9 Use Cases FTW Today's Date Sub Topic 2 Sub Topic 1 Sub Topic 2 Sub Topic 3 Sub Topic 4 Sub Topic 5
10. 10 Today's Date Sub Sub Topic Facebook Messages Platform Tο πρόβλημα Μια καινούρια εφαρμογή ανταλαγής μηνυμάτων που θα πρέπει να εξυπηρετεί Κατ ελάχιστον 350 εκατομύρια χρήστες που στέλνουν 15 δισεκατομύρια Μυνήματα το μήνα Οι πιθανές λύσεις • MySQL ( αυτό που χρησημοποιούσαν μέχρι τώρα και ξέραν) • Cassandra ( αυτό που έιχαν οι ίδιοι δημιουργήσει και τρέχει το βασικό τους search ) • Hbase ( NoSQL database In Hadoop HDFS ) H τελική επιλογή HBase • MySQL - δεν μπορούσε απο θέμα αποδοσης να ανταπεξέλθει στο φόρτο εργασίας • Cassandra - δεν ήταν ανεκτό το μέγεθος ασυνέπειας στα αντιγραφα των δεδομένων • Hbase – Εύκολη επεκτασιμότητα, αυξημένη συνέπεια, καλή απόδοση, αυτοματος καταμερισμός φόρτου, compresion, οι προγραμματιστές ηταν ήδη γνώριμοι με λειτουργίες του HDFS.
11. 11 Today's Date Sub Sub Topic Tweeter Full Needs Tο πρόβλημα To tweeter ξεκίνησε με όλες τις λειτουργίες (tweets, relationships, users, search, Loging) βασισμένες στη MySQL. Ο ογκος των δεδομένων και των ερωτημάτων μεγαλωνε διαρκώς. Η MySQL Ανταποκρινόταν αργά, κλιμακονόταν δύσκολα και ακριβά. Οι πιθανές λύσεις • Haddop , NoSQL databases, Memcache/Redis H τελική επιλογή ΤΑ ΠΑΝΤΑ • MySQL(customized) – Για τους χρήστες εκει που η ασυνέπεια της cassandra δεν ήταν ανεκτη • Cassandra – Για τα tweets εκει που η ασυνέπεια είναι ανεκτή. Επιλέχθηκε σε σχεση με αλλες λύσεις (mongo, Hbase, HyperTable) για την ευκολία της στην κλιμακωση, για την διαθεσιμότητα της, την αξιοπιστία της και την ευκολία στην εγκατάσταση συντήριση • Scribe – Για την συλογή logs απο τους servers και την αποθήκευση τους στο HDFS • Hadoop / Pig – Για την επεξεργασία τον logs σε μή πραγματικό χρόνο και την δημιουργεία στατιστικών στο επιπεδο των χρηστων(ενδιαφέροντα ανα ηλικια, ανα περιοχή κλπ). Επιλέχθηκε το Pig γιατί η ευκολία στην συγγραφή ερωτημάτων ηταν βασικότερη προυπόθεση απο το χρόνο απόκρισης
12. 12 Today's Date Tweeter Full Needs • FlockDB – Για την αποθήκευση γράφων συσχετίσεων μεταξί χρηστών. Μια graph database που αναπτύχθηκε απο τους ίδιους • Lucence (customized) – Για την αναζήτηση σε πραγματικό χρόνο. Το lucence δίνει την δυνατότητα στο tweeter να κάνει index 500εκ tweets την ημέρα και να κάνει full text search σε όλα αυτά τα tweets σε λογικό χρόνο Extra... To tweeter εκανε release πριν λίγους μήνες το heron ενα storm fork αρα πλέον δεν αποθηκευει Logs σε hadoop για ανάλυση αργότερα αλλα χρησιμοποιεί ενα kafka η ανάλογο queue και το heron/storm για να αναλύει τα logs που μαζέυει σε πραγματικό χρόνο και να τα αποθηκευει ίσως απλα για μελοντική χρήση Επισης οπως ισχυρίζετε ενέπτυξε ενα δικό του DataBase (Manhatan Project) ετσι ωστε να ενοποιήσει όλες της δομές αποθήκευσης που χρησημοποιεί με εναν τροπο που καλυπτει απολυτα τις δικές του ανάγκες.
13. 13 Today's Date Sub Sub Topic Hekima Sub Sub Topic Tο πρόβλημα Ενα startup που συλέγει δεδομένα απο social media στη Βραζιλία και δίνει την Δυνατότητα στους πελατες του να κάνουν real time αναζητήσεις πάνω σε αυτά Αλλα και να πάρουν συγκεντροτικά δεδομένα σε περιπλοκες ερωτήσεις Οι πιθανές λύσεις • Hadoop • NoSQL databases • Spark H τελική επιλογή RabitMQ, MongoDB, Spark, AmazonS3 • RabitMQ – Μιας και το scraper της εταιρίας δημιουργεί δεδομένα με μεγαλύτερη ταχύτητα απ οτι το mongoDB μπορεί να καταναλώνει δεδομένα επιλέχθηκε να χρησημοποιηθεί μια ουρά η οποία ακομη βοηθάει να μην χαθούν δεδομένα απο την συλογή ακομη και αν το MongoDB ειναι εκτός λειτουργίας • MongoDB – Το mongoDB επιλέχθηκε σας βασική μονάδα αποθήκευσης για την εφαρμογή γιατι • Το ευέλικτο σχήμα των δεδομένων του μπορεί να αποθηκευσει δεδομένα απο διαφορετικές πηγές, να αλλάξει το σχήμα των δεδομένων χωρίς να επιρεάσει τα δεδομένα που ήδη είναι αποθηκευμένα.
14. 14 Today's Date Sub Sub Topic Hekima Sub Sub Topic • Η επεκτάσιμη γλώσσα ερωτημάτων του mongoDB και η ταχύτητα εκτέλεσης τους καλύπτει τις απαιτήσεις της εταιρίας για τις αναζητήσεις πραγματικού χρόνου στα δεδομένα της • Η ευκολία επέκτασης του mongoDB μπορεί να βοηθήσει την εταιρια για την αυξομίωση των δυνατοτήτων του cluster της ανάλογα με τις ανάγκες της. • Spark – Αν και το mongoDB είναι αποδοτικό για ερωτήσεις πραγματικού χρόνου για την δημιουργεία στατιστικών σε μεγαλο ευρως δεδομένων η εταιρία χρη- σημοποιεί το Spark. Ανα κάποιες ώρες εξάγει τα δεδομένα απο το mongoDB σε μια standar μορφή τα αποθηκέυει σε ενα hadoop cluster σε “ημερισια” και χρησημοποιεί το spark για να κανει custom στατιστικες ερωτήσεις πανω σε αυτά ομαδοποιώντας τα χρονικα
15. 15 Today's Date Sub Sub Topic EBAY/MOBILE.de DevOps Monitoring Sub Sub Topic Tο πρόβλημα To mobile.de χρησημοποιεί ενα cluster απο εκατοντάδες servers που τρέχουν Διάφορες εφαρμογές όπως mongoDB, RabitMQ, Elasticsearch, Squid. Χρειάζονταν ένα κεντρικό σημείο παρακολούθησης όλων αυτών για την σωστή Αναπτυξη του cluster αλλα και την ευρεση ανωμαλιών Οι πιθανές λύσεις • Monit • Nagios • monitis H τελική επιλογή TICK STACK • Nagios – Ειχε χρόνια στο χώρο και εχει φτάσει στο pick του, Δεν ξεχωρίζει της κατηγορίες των εγγραφών, no aggregations, scalability problems • TICK STACK – μπορει να πάρει δεδομένα απο οποιαδήποτε πηγή υπάρχει εκει έξω με ρυθμό 100,000/sec/instance, Taging/Fields on records, aggregations, Διαφορετικές μηχανές παραγωγής γραφιμάτων απο τα δεδομένα (graphana, chronograf, graphite), έξυπνος μηχανισμός ειδοποιήσεων με triggers, REST HTTP API for custom εφαρμογές, SQL LIKE QL, realtime response <100ms
16. 16 Today's Date EBAY/MOBILE.de DevOps Monitoring
17. 17 Sub Sub Topic MOVIELENS Sub Sub Topic Tο πρόβλημα Μια εφαρμογή για την πρόταση ταινιών στους χρήστες της. Καθε χρήστης μπορεί να βαθμολογίση μια ταινία που έχει δεί και σύμφωνα με τις βαθμολογίες που έχει δώσει σε διάφορες ταινίες η εφαρμογή θα του προτείνει ταινίες που δεν εχει δεί αλλα έχουν καλές κριτηκές απο χρήστες που αρεσαν ταινιές που άρεσαν και σε αυτόν Οι πιθανές λύσεις H τελική επιλογή Mahout • Mahout – Αρχικά η εφαρμογή χρησημοποιούσε δομημένα αρχεία κειμενου για την αποθήκευση των βαθμολογιών των χρηστών της (UserID::MovieID::Rating::Timestamp). Το mahout τρέχει πανω στο hadoop το οποίο είναι σχεδιασμένο για την αποθήκευση τέτοιων αρχείων κειμένο. Επισης το mahout έχει ένα ευκολο api για την δημιουργεία recomendations απο τέτοιου είδους δεδομενα και τέλος μπορεί να αποθηκέυει και τα ενδιά- μεσα στάδια των δεδομένων για μια επιπλεον ανάλυση αργότερα • Hadoop Mahout • Elasticsearch Taste
18. 18 Conclusion Today's Date Sub Topic 3
19. 19 Today's Date Πως το βλέπω Σίγουρα χρειάζεσαι Big Data solutions Στατιστικά απο 4.000.000 παιχνίδια σκάκι αναλύθηκαν για το αν κέρδισαν Τα λευκά η τα μάυρα... Το AWK τα κατάφερε • 175 φορές πιο γρήγορα απο το Storm • 250 φορές πιο γρήγορα απο το Hadoop Kibana Dash is Funcy!!! Χρειάζεσαι όμως κάτι παραπάνω απ οτι το Google Analytics σου δίνει για το site σου?
20. 20 Today's Date Sub Sub Topic Πως το βλέπω Big Data -> Web Dev Hadoop -> Php Spark etc -> Cake , Zend, CodeIgniter MongoDB/Elastic/Influx etc -> Drupal, Joomla, Wordpress etc Αυτοί που πραγματικά έχουν ανάγκη απο Big Data analytics θα το κάνουν σωστά in house όπως το κανουν τώρα με το web dev τους. Καποιοι πωλητές θα καταφέρνουν να πουλούν λύσεις που δεν μπορουν να υποστηρίξουν σε πελάτες που δεν τις χρειάζονται using buzz words Ακόμη και ο gates είπε οτι 640Κ θα ήταν αρκετά άρα δικαιούμε και εγώ Να κάνω μια λάθως εκτίμηση Αυτοί που έχουν common needs (log analysis, devops, recomendations, big sql storage) απο Big Data θα μπορούν να καλυφθούν απο καθετο- ποιημένες λύσεις (TICK Stack, ELK stack, MongoDB-SlamData etc) που θα γίνονται συνεχως ευκολες στην εγκατασταση λειτουργία τους τις οποίες είτε θα διαχειρίζονται μόνοι τους ειτε θα τις δίνουν σε κάποια εταιρία με εμπειρία για την εγκατάσταση παραμετρο-ποιηση τους (αυτό που γίνετε τώρα με το joomla/Drupal etc)
21. 21 Q&A Today's Date Sub Topic 4