Θεωρία και πρακτική χρήσης του ClickHouse σε πραγματικές εφαρμογές. Alexander Zaitsev (2018)

Παρά το γεγονός ότι υπάρχουν πλέον πολλά δεδομένα σχεδόν παντού, οι αναλυτικές βάσεις δεδομένων εξακολουθούν να είναι αρκετά εξωτικές. Είναι ελάχιστα γνωστά και ακόμη χειρότερα μπορούν να τα χρησιμοποιήσουν αποτελεσματικά. Πολλοί συνεχίζουν να "τρώνε κάκτους" με MySQL ή PostgreSQL, που έχουν σχεδιαστεί για άλλα σενάρια, υποφέρουν από NoSQL ή πληρώνουν υπερβολικά για εμπορικές λύσεις. Το ClickHouse αλλάζει τους κανόνες του παιχνιδιού και μειώνει σημαντικά το όριο για την είσοδο στον κόσμο του αναλυτικού DBMS.

Αναφορά από το BackEnd Conf 2018 και δημοσιεύεται με την άδεια του ομιλητή.

Ποιος είμαι και γιατί μιλάω για το ClickHouse; Είμαι διευθυντής ανάπτυξης στη LifeStreet, η οποία χρησιμοποιεί το ClickHouse. Επίσης, είμαι ο ιδρυτής του Altinity. Είναι ένας συνεργάτης Yandex που προωθεί το ClickHouse και βοηθά το Yandex να κάνει το ClickHouse πιο επιτυχημένο. Επίσης έτοιμος να μοιραστεί γνώσεις σχετικά με το ClickHouse.

Και δεν είμαι ο αδερφός του Petya Zaitsev. Με ρωτούν συχνά για αυτό. Όχι, δεν είμαστε αδέρφια.

"Όλοι γνωρίζουν" ότι το ClickHouse:

• Πολύ γρήγορα,
• Πολύ άνετο
• Χρησιμοποιείται στο Yandex.

Λίγο λιγότερο είναι γνωστό σε ποιες εταιρείες και πώς χρησιμοποιείται.

Θα σας πω γιατί, πού και πώς χρησιμοποιείται το ClickHouse, εκτός από το Yandex.

Θα σας πω πώς επιλύονται συγκεκριμένες εργασίες με τη βοήθεια του ClickHouse σε διαφορετικές εταιρείες, ποια εργαλεία ClickHouse μπορείτε να χρησιμοποιήσετε για τις εργασίες σας και πώς χρησιμοποιήθηκαν σε διαφορετικές εταιρείες.

Διάλεξα τρία παραδείγματα που δείχνουν το ClickHouse από διαφορετικές οπτικές γωνίες. Νομίζω ότι θα έχει ενδιαφέρον.

Η πρώτη ερώτηση είναι: "Γιατί χρειαζόμαστε το ClickHouse;". Φαίνεται να είναι μια αρκετά προφανής ερώτηση, αλλά υπάρχουν περισσότερες από μία απαντήσεις σε αυτήν.

• Η πρώτη απάντηση είναι για απόδοση. Το ClickHouse είναι πολύ γρήγορο. Το Analytics στο ClickHouse είναι επίσης πολύ γρήγορο. Μπορεί συχνά να χρησιμοποιηθεί όταν κάτι άλλο είναι πολύ αργό ή πολύ κακό.
• Η δεύτερη απάντηση είναι το κόστος. Και πρώτα απ 'όλα, το κόστος της κλιμάκωσης. Για παράδειγμα, η Vertica είναι μια απολύτως εξαιρετική βάση δεδομένων. Λειτουργεί πολύ καλά εάν δεν έχετε πολλά terabyte δεδομένων. Αλλά όταν πρόκειται για εκατοντάδες terabyte ή petabyte, το κόστος μιας άδειας και της υποστήριξης πηγαίνει σε ένα αρκετά σημαντικό ποσό. Και είναι ακριβό. Και το ClickHouse είναι δωρεάν.
• Η τρίτη απάντηση είναι το λειτουργικό κόστος. Αυτή είναι μια ελαφρώς διαφορετική προσέγγιση. Το RedShift είναι ένα εξαιρετικό αναλογικό. Στο RedShift, μπορείτε να πάρετε μια απόφαση πολύ γρήγορα. Θα λειτουργεί καλά, αλλά ταυτόχρονα, κάθε ώρα, κάθε μέρα και κάθε μήνα, θα πληρώνετε πολύ ακριβά την Amazon, γιατί αυτή είναι μια πολύ ακριβή υπηρεσία. Google BigQuery επίσης. Εάν κάποιος το χρησιμοποίησε, τότε ξέρει ότι εκεί μπορείτε να εκτελέσετε πολλά αιτήματα και να πάρετε έναν λογαριασμό για εκατοντάδες δολάρια ξαφνικά.

Το ClickHouse δεν έχει αυτά τα προβλήματα.

Πού χρησιμοποιείται τώρα το ClickHouse; Εκτός από το Yandex, το ClickHouse χρησιμοποιείται σε πολλές διαφορετικές επιχειρήσεις και εταιρείες.

• Πρώτα απ 'όλα, πρόκειται για αναλυτικά στοιχεία εφαρμογών ιστού, δηλαδή πρόκειται για μια περίπτωση χρήσης που προήλθε από το Yandex.
• Πολλές εταιρείες AdTech χρησιμοποιούν το ClickHouse.
• Πολλές εταιρείες που πρέπει να αναλύσουν τα αρχεία καταγραφής συναλλαγών από διαφορετικές πηγές.
• Πολλές εταιρείες χρησιμοποιούν το ClickHouse για την παρακολούθηση αρχείων καταγραφής ασφαλείας. Τα ανεβάζουν στο ClickHouse, κάνουν αναφορές και παίρνουν τα αποτελέσματα που χρειάζονται.
• Οι εταιρείες αρχίζουν να το χρησιμοποιούν στη χρηματοοικονομική ανάλυση, δηλαδή σταδιακά οι μεγάλες επιχειρήσεις προσεγγίζουν επίσης το ClickHouse.
• συννεφιά. Αν κάποιος ακολουθεί το ClickHouse, τότε μάλλον έχει ακούσει το όνομα αυτής της εταιρείας. Αυτός είναι ένας από τους βασικούς συντελεστές από την κοινότητα. Και έχουν μια πολύ σοβαρή εγκατάσταση ClickHouse. Για παράδειγμα, έφτιαξαν το Kafka Engine για το ClickHouse.
• Οι εταιρείες τηλεπικοινωνιών άρχισαν να χρησιμοποιούν. Αρκετές εταιρείες χρησιμοποιούν το ClickHouse είτε ως proof on concept είτε ήδη σε παραγωγή.
• Μια εταιρεία χρησιμοποιεί το ClickHouse για να παρακολουθεί τις διαδικασίες παραγωγής. Δοκιμάζουν μικροκυκλώματα, διαγράφουν ένα σωρό παραμέτρους, υπάρχουν περίπου 2 χαρακτηριστικά. Και μετά αναλύουν αν το παιχνίδι είναι καλό ή κακό.
• Αναλύσεις Blockchain. Υπάρχει μια τέτοια ρωσική εταιρεία όπως η Bloxy.info. Αυτή είναι μια ανάλυση του δικτύου ethereum. Το έκαναν επίσης στο ClickHouse.

Και το μέγεθος δεν έχει σημασία. Υπάρχουν πολλές εταιρείες που χρησιμοποιούν έναν μικρό διακομιστή. Και τους επιτρέπει να λύσουν τα προβλήματά τους. Και ακόμη περισσότερες εταιρείες χρησιμοποιούν μεγάλα συμπλέγματα πολλών διακομιστών ή δεκάδες διακομιστές.

Και αν δείτε τα αρχεία, τότε:

• Yandex: 500+ διακομιστές, αποθηκεύουν 25 δισεκατομμύρια εγγραφές την ημέρα εκεί.
• LifeStreet: 60 διακομιστές, περίπου 75 δισεκατομμύρια εγγραφές την ημέρα. Υπάρχουν λιγότεροι διακομιστές, περισσότερες εγγραφές από ό,τι στο Yandex.
• CloudFlare: 36 διακομιστές, εξοικονομούν 200 δισεκατομμύρια εγγραφές την ημέρα. Έχουν ακόμη λιγότερους διακομιστές και αποθηκεύουν ακόμη περισσότερα δεδομένα.
• Bloomberg: 102 διακομιστές, περίπου ένα τρισεκατομμύριο καταχωρήσεις την ημέρα. Κάτοχος του ρεκόρ.

Γεωγραφικά, είναι επίσης πολλά. Αυτός ο χάρτης εδώ δείχνει έναν θερμικό χάρτη του σημείου που χρησιμοποιείται το ClickHouse στον κόσμο. Εδώ ξεχωρίζουν ξεκάθαρα η Ρωσία, η Κίνα, η Αμερική. Υπάρχουν λίγες ευρωπαϊκές χώρες. Και υπάρχουν 4 συστάδες.

Αυτή είναι μια συγκριτική ανάλυση, δεν χρειάζεται να ψάξουμε για απόλυτα μεγέθη. Αυτή είναι μια ανάλυση επισκεπτών που διαβάζουν αγγλόφωνο υλικό στον ιστότοπο Altinity, επειδή δεν υπάρχουν ρωσόφωνοι εκεί. Και η Ρωσία, η Ουκρανία, η Λευκορωσία, δηλαδή το ρωσόφωνο τμήμα της κοινότητας, αυτοί είναι οι πιο πολυάριθμοι χρήστες. Μετά έρχονται οι ΗΠΑ και ο Καναδάς. Η Κίνα προλαβαίνει πολύ. Δεν υπήρχε σχεδόν καμία Κίνα εκεί πριν από έξι μήνες, τώρα η Κίνα έχει ήδη ξεπεράσει την Ευρώπη και συνεχίζει να αναπτύσσεται. Η παλιά Ευρώπη δεν είναι επίσης πολύ πίσω, και ο ηγέτης στη χρήση του ClickHouse είναι, παραδόξως, η Γαλλία.

Γιατί τα λέω όλα αυτά; Για να δείξουμε ότι το ClickHouse γίνεται μια τυπική λύση για ανάλυση μεγάλων δεδομένων και χρησιμοποιείται ήδη σε πολλά μέρη. Αν το χρησιμοποιείς, είσαι στη σωστή τάση. Εάν δεν το χρησιμοποιείτε ακόμα, τότε δεν μπορείτε να φοβάστε ότι θα μείνετε μόνοι και κανείς δεν θα σας βοηθήσει, γιατί πολλοί το κάνουν ήδη αυτό.

Αυτά είναι παραδείγματα πραγματικής χρήσης του ClickHouse σε διάφορες εταιρείες.

• Το πρώτο παράδειγμα είναι ένα δίκτυο διαφημίσεων: μετεγκατάσταση από την Vertica στο ClickHouse. Και γνωρίζω μερικές εταιρείες που έχουν περάσει από τη Vertica ή βρίσκονται σε διαδικασία μετάβασης.
• Το δεύτερο παράδειγμα είναι ο χώρος αποθήκευσης συναλλαγών στο ClickHouse. Αυτό είναι ένα παράδειγμα που βασίζεται σε αντιπρότυπα. Όλα όσα δεν πρέπει να γίνονται στο ClickHouse κατόπιν συμβουλής προγραμματιστών γίνονται εδώ. Και γίνεται τόσο αποτελεσματικά που λειτουργεί. Και λειτουργεί πολύ καλύτερα από την τυπική λύση συναλλαγών.
• Το τρίτο παράδειγμα είναι κατανεμημένος υπολογισμός στο ClickHouse. Υπήρχε μια ερώτηση σχετικά με το πώς το ClickHouse μπορεί να ενσωματωθεί στο οικοσύστημα Hadoop. Θα δείξω ένα παράδειγμα του πώς μια εταιρεία έκανε κάτι παρόμοιο με ένα κοντέινερ μείωσης χάρτη στο ClickHouse, παρακολουθώντας την τοπική προσαρμογή δεδομένων κ.λπ., για να υπολογίσει μια πολύ μη τετριμμένη εργασία.

• Η LifeStreet είναι μια εταιρεία Ad Tech που διαθέτει όλη την τεχνολογία που συνοδεύει ένα δίκτυο διαφημίσεων.
• Ασχολείται με τη βελτιστοποίηση διαφημίσεων, την υποβολή προσφορών μέσω προγραμματισμού.
• Πολλά δεδομένα: περίπου 10 δισεκατομμύρια συμβάντα την ημέρα. Ταυτόχρονα, τα γεγονότα εκεί μπορούν να χωριστούν σε πολλά υπογεγονότα.
• Υπάρχουν πολλοί πελάτες αυτών των δεδομένων, και αυτοί δεν είναι μόνο άνθρωποι, πολύ περισσότεροι - αυτοί είναι διάφοροι αλγόριθμοι που ασχολούνται με την υποβολή προσφορών μέσω προγραμματισμού.

Η εταιρεία έχει διανύσει έναν μακρύ και ακανθώδες δρόμο. Και μίλησα για αυτό στο HighLoad. Πρώτα, το LifeStreet μετακόμισε από τη MySQL (με μια σύντομη στάση στο Oracle) στη Vertica. Και μπορείτε να βρείτε μια ιστορία για αυτό.

Και όλα ήταν πολύ καλά, αλλά γρήγορα έγινε σαφές ότι τα δεδομένα αυξάνονται και η Vertica είναι ακριβή. Ως εκ τούτου, αναζητήθηκαν διάφορες εναλλακτικές λύσεις. Μερικά από αυτά παρατίθενται εδώ. Και μάλιστα, κάναμε proof of concept ή μερικές φορές δοκιμές απόδοσης σχεδόν όλων των βάσεων δεδομένων που ήταν διαθέσιμες στην αγορά από το 13ο έως το 16ο έτος και ήταν κατά προσέγγιση κατάλληλες από άποψη λειτουργικότητας. Και μίλησα επίσης για μερικά από αυτά στο HighLoad.

Το καθήκον ήταν να μεταναστεύσουμε από την Vertica στην πρώτη θέση, επειδή τα δεδομένα αυξήθηκαν. Και αυξήθηκαν εκθετικά με τα χρόνια. Μετά πήγαν στο ράφι, αλλά παρόλα αυτά. Και προβλέποντας αυτή την ανάπτυξη, τις επιχειρηματικές απαιτήσεις για τον όγκο των δεδομένων για τα οποία έπρεπε να γίνει κάποιο είδος ανάλυσης, ήταν σαφές ότι τα petabytes θα συζητούνταν σύντομα. Και η πληρωμή για petabytes είναι ήδη πολύ ακριβή, οπότε ψάχναμε για μια εναλλακτική λύση που να πάμε.

Πού να πάτε? Και για πολύ καιρό δεν ήταν καθόλου σαφές πού να πάει, γιατί αφενός υπάρχουν εμπορικές βάσεις δεδομένων, φαίνεται να λειτουργούν καλά. Κάποια λειτουργούν σχεδόν εξίσου καλά με το Vertica, άλλα χειρότερα. Αλλά είναι όλα ακριβά, τίποτα φθηνότερο και καλύτερο δεν θα μπορούσε να βρεθεί.

Από την άλλη, υπάρχουν λύσεις ανοιχτού κώδικα, οι οποίες δεν είναι πολύ πολλές, δηλαδή για τα αναλυτικά, μπορούν να μετρηθούν στα δάχτυλα. Και είναι δωρεάν ή φθηνά, αλλά αργά. Και συχνά τους λείπει η απαραίτητη και χρήσιμη λειτουργικότητα.

Και δεν υπήρχε τίποτα που να συνδυάζει το καλό που υπάρχει στις εμπορικές βάσεις δεδομένων και όλα τα δωρεάν που είναι σε ανοιχτό κώδικα.

Δεν υπήρχε τίποτα μέχρι που, απροσδόκητα, η Yandex έβγαλε το ClickHouse, σαν μάγος από καπέλο, σαν κουνέλι. Και ήταν μια απροσδόκητη απόφαση, εξακολουθούν να κάνουν την ερώτηση: «Γιατί;», αλλά παρόλα αυτά.

Και αμέσως το καλοκαίρι του 2016, αρχίσαμε να εξετάζουμε τι είναι το ClickHouse. Και αποδείχθηκε ότι μερικές φορές μπορεί να είναι πιο γρήγορο από το Vertica. Δοκιμάσαμε διαφορετικά σενάρια σε διαφορετικά ερωτήματα. Και αν το ερώτημα χρησιμοποιούσε μόνο έναν πίνακα, δηλαδή χωρίς συνδέσεις (join), τότε το ClickHouse ήταν δύο φορές πιο γρήγορο από το Vertica.

Δεν ήμουν πολύ τεμπέλης και κοίταξα τις δοκιμές Yandex την άλλη μέρα. Είναι το ίδιο και εκεί: το ClickHouse είναι δύο φορές πιο γρήγορο από το Vertica, επομένως συχνά μιλούν γι' αυτό.

Αλλά αν υπάρχουν ενώσεις στα ερωτήματα, τότε όλα αποδεικνύονται όχι πολύ ξεκάθαρα. Και το ClickHouse μπορεί να είναι δύο φορές πιο αργό από το Vertica. Και αν διορθώσετε ελαφρώς το αίτημα και το ξαναγράψετε, τότε είναι περίπου ίσα. Δεν είναι κακό. Και δωρεάν.

Και έχοντας λάβει τα αποτελέσματα των δοκιμών και κοιτάζοντας το από διαφορετικές οπτικές γωνίες, το LifeStreet πήγε στο ClickHouse.

Φέτος είναι η 16η χρονιά, σας θυμίζω. Ήταν σαν ένα αστείο για ποντίκια που έκλαιγαν και τρυπούσαν τον εαυτό τους, αλλά συνέχισαν να τρώνε τον κάκτο. Και αυτό περιγράφηκε λεπτομερώς, υπάρχει ένα βίντεο για αυτό κ.λπ.

Επομένως, δεν θα μιλήσω αναλυτικά, θα μιλήσω μόνο για τα αποτελέσματα και μερικά ενδιαφέροντα πράγματα για τα οποία δεν μίλησα τότε.

Τα αποτελέσματα είναι:

• Επιτυχής μετανάστευση και περισσότερο από ένα χρόνο το σύστημα λειτουργεί ήδη στην παραγωγή.
• Η παραγωγικότητα και η ευελιξία έχουν αυξηθεί. Από τα 10 δισεκατομμύρια δίσκους που μπορούσαμε να αντέξουμε οικονομικά να αποθηκεύουμε την ημέρα και στη συνέχεια για μικρό χρονικό διάστημα, το LifeStreet αποθηκεύει τώρα 75 δισεκατομμύρια δίσκους την ημέρα και μπορεί να το κάνει αυτό για 3 μήνες ή περισσότερο. Εάν μετράτε στην κορυφή, τότε αυτό είναι έως και ένα εκατομμύριο συμβάντα ανά δευτερόλεπτο. Περισσότερα από ένα εκατομμύριο ερωτήματα SQL την ημέρα φτάνουν σε αυτό το σύστημα, κυρίως από διαφορετικά ρομπότ.
• Παρά το γεγονός ότι χρησιμοποιήθηκαν περισσότεροι διακομιστές για το ClickHouse παρά για την Vertica, εξοικονομήθηκαν επίσης σε υλικό, επειδή χρησιμοποιήθηκαν αρκετά ακριβοί δίσκοι SAS στο Vertica. Το ClickHouse χρησιμοποιούσε SATA. Και γιατί? Επειδή στο Vertica το ένθετο είναι σύγχρονο. Και ο συγχρονισμός απαιτεί οι δίσκοι να μην επιβραδύνουν πολύ, και επίσης να μην επιβραδύνει πολύ το δίκτυο, δηλαδή μια αρκετά ακριβή λειτουργία. Και στο ClickHouse η εισαγωγή είναι ασύγχρονη. Επιπλέον, μπορείτε πάντα να γράψετε τα πάντα τοπικά, δεν υπάρχει πρόσθετο κόστος για αυτό, επομένως τα δεδομένα μπορούν να εισαχθούν στο ClickHouse πολύ πιο γρήγορα από ό,τι στο Vertika, ακόμη και σε πιο αργούς δίσκους. Και το διάβασμα είναι περίπου το ίδιο. Διαβάζοντας σε SATA, εάν είναι σε RAID, τότε όλα αυτά είναι αρκετά γρήγορα.
• Δεν περιορίζεται από άδεια, δηλαδή 3 petabytes δεδομένων σε 60 διακομιστές (20 διακομιστές είναι ένα αντίγραφο) και 6 τρισεκατομμύρια εγγραφές σε γεγονότα και συγκεντρώσεις. Τίποτα τέτοιο δεν μπορούσε να αντέξει οικονομικά στη Vertica.

Έρχομαι τώρα σε πρακτικά πράγματα σε αυτό το παράδειγμα.

• Το πρώτο είναι ένα αποτελεσματικό σύστημα. Πολλά εξαρτώνται από το σχήμα.
• Το δεύτερο είναι η αποτελεσματική παραγωγή SQL.

Ένα τυπικό ερώτημα OLAP είναι μια επιλογή. Μερικές από τις στήλες πηγαίνουν σε ομαδοποίηση κατά, μερικές από τις στήλες πηγαίνουν σε συναρτήσεις συγκεντρωτικών. Υπάρχει πού, το οποίο μπορεί να αναπαρασταθεί ως μια φέτα ενός κύβου. Ολόκληρη η ομάδα από μπορεί να θεωρηθεί ως προβολή. Και γι' αυτό ονομάζεται πολυπαραγοντική ανάλυση δεδομένων.

Και συχνά αυτό διαμορφώνεται με τη μορφή ενός σχήματος αστεριών, όταν υπάρχει ένα κεντρικό γεγονός και χαρακτηριστικά αυτού του γεγονότος κατά μήκος των πλευρών, κατά μήκος των ακτίνων.

Και όσον αφορά τον φυσικό σχεδιασμό, το πώς ταιριάζει στο τραπέζι, συνήθως κάνουν μια κανονικοποιημένη αναπαράσταση. Μπορείτε να αποσυναρμολογήσετε, αλλά είναι ακριβό στο δίσκο και δεν είναι πολύ αποτελεσματικό σε ερωτήματα. Επομένως, συνήθως κάνουν μια κανονικοποιημένη αναπαράσταση, δηλαδή έναν πίνακα γεγονότων και πολλούς, πολλούς πίνακες διαστάσεων.

Αλλά δεν λειτουργεί καλά στο ClickHouse. Υπάρχουν δύο λόγοι:

• Το πρώτο είναι επειδή το ClickHouse δεν έχει πολύ καλές συνδέσεις, δηλαδή υπάρχουν συνδέσεις, αλλά είναι κακές. Ενώ κακό.
• Το δεύτερο είναι ότι οι πίνακες δεν ενημερώνονται. Συνήθως σε αυτές τις πλάκες, που βρίσκονται γύρω από το κύκλωμα του αστεριού, κάτι πρέπει να αλλάξει. Για παράδειγμα, όνομα πελάτη, όνομα εταιρείας κ.λπ. Και δεν λειτουργεί.

Και υπάρχει διέξοδος από αυτό στο ClickHouse. ακόμη και δύο:

• Το πρώτο είναι η χρήση λεξικών. Τα εξωτερικά λεξικά είναι αυτό που βοηθά κατά 99% να λύσει το πρόβλημα με το αστέρι-σχήμα, με ενημερώσεις και ούτω καθεξής.
• Το δεύτερο είναι η χρήση πινάκων. Οι συστοιχίες βοηθούν επίσης να απαλλαγούμε από συνδέσεις και προβλήματα με την κανονικοποίηση.

• Δεν απαιτείται συμμετοχή.
• Αναβαθμίσιμο. Από τον Μάρτιο του 2018, εμφανίστηκε μια μη τεκμηριωμένη ευκαιρία (δεν θα το βρείτε στην τεκμηρίωση) για μερική ενημέρωση των λεξικών, δηλαδή εκείνων των εγγραφών που έχουν αλλάξει. Πρακτικά είναι σαν τραπέζι.
• Πάντα στη μνήμη, επομένως οι ενώσεις με ένα λεξικό λειτουργούν πιο γρήγορα από ό,τι αν ήταν ένας πίνακας που βρίσκεται στο δίσκο και δεν είναι ακόμα γεγονός ότι βρίσκεται στην κρυφή μνήμη, πιθανότατα όχι.

• Δεν χρειάζεσαι ούτε ενώσεις.
• Αυτή είναι μια συμπαγής αναπαράσταση 1-προς-πολλά.
• Και κατά τη γνώμη μου, οι πίνακες είναι φτιαγμένοι για geeks. Αυτές είναι συναρτήσεις λάμδα και ούτω καθεξής.

Αυτό δεν είναι για κόκκινες λέξεις. Αυτή είναι μια πολύ ισχυρή λειτουργία που σας επιτρέπει να κάνετε πολλά πράγματα με πολύ απλό και κομψό τρόπο.

Τυπικά παραδείγματα που βοηθούν στην επίλυση πινάκων. Αυτά τα παραδείγματα είναι απλά και αρκετά ξεκάθαρα:

• Αναζήτηση ανά ετικέτες. Εάν έχετε hashtag εκεί και θέλετε να βρείτε μερικές αναρτήσεις ανά hashtag.
• Αναζήτηση ανά ζεύγη κλειδιών-τιμών. Υπάρχουν επίσης ορισμένα χαρακτηριστικά με μια τιμή.
• Αποθήκευση λιστών κλειδιών που πρέπει να μεταφράσετε σε κάτι άλλο.

Όλες αυτές οι εργασίες μπορούν να επιλυθούν χωρίς πίνακες. Οι ετικέτες μπορούν να τοποθετηθούν σε κάποια γραμμή και να επιλεγούν με μια τυπική έκφραση ή σε έναν ξεχωριστό πίνακα, αλλά στη συνέχεια πρέπει να κάνετε συνδέσεις.

Και στο ClickHouse, δεν χρειάζεται να κάνετε τίποτα, αρκεί να περιγράψετε τη διάταξη συμβολοσειρών για hashtags ή να δημιουργήσετε μια ένθετη δομή για συστήματα κλειδιών-τιμών.

Η ένθετη δομή μπορεί να μην είναι το καλύτερο όνομα. Πρόκειται για δύο πίνακες που έχουν κοινό μέρος στο όνομα και ορισμένα σχετικά χαρακτηριστικά.

Και είναι πολύ εύκολο να κάνετε αναζήτηση ανά ετικέτα. Να έχετε μια λειτουργία has, το οποίο ελέγχει ότι ο πίνακας περιέχει ένα στοιχείο. Όλοι βρήκαμε όλες τις συμμετοχές που σχετίζονται με το συνέδριό μας.

Η αναζήτηση κατά subid είναι λίγο πιο περίπλοκη. Πρέπει πρώτα να βρούμε το ευρετήριο του κλειδιού και μετά να πάρουμε το στοιχείο με αυτό το ευρετήριο και να ελέγξουμε ότι αυτή η τιμή είναι αυτό που χρειαζόμαστε. Ωστόσο, είναι πολύ απλό και συμπαγές.

Η κανονική έκφραση που θα θέλατε να γράψετε αν τα κρατούσατε όλα σε μια γραμμή, θα ήταν, πρώτον, αδέξια. Και, δεύτερον, λειτούργησε πολύ περισσότερο από δύο συστοιχίες.

Ενα άλλο παράδειγμα. Έχετε έναν πίνακα όπου αποθηκεύετε το αναγνωριστικό. Και μπορείτε να τα μεταφράσετε σε ονόματα. Λειτουργία arrayMap. Αυτή είναι μια τυπική συνάρτηση λάμδα. Εκεί περνάς εκφράσεις λάμδα. Και βγάζει την τιμή του ονόματος για κάθε αναγνωριστικό από το λεξικό.

Η αναζήτηση μπορεί να γίνει με τον ίδιο τρόπο. Διαβιβάζεται μια συνάρτηση κατηγορήματος που ελέγχει τι ταιριάζουν τα στοιχεία.

Αυτά τα πράγματα απλοποιούν πολύ το κύκλωμα και λύνουν ένα σωρό προβλήματα.

Αλλά το επόμενο πρόβλημα που αντιμετωπίζουμε, και το οποίο θα ήθελα να αναφέρω, είναι τα αποτελεσματικά ερωτήματα.

• Το ClickHouse δεν διαθέτει πρόγραμμα σχεδιασμού ερωτημάτων. Με τίποτα.
• Ωστόσο, σύνθετα ερωτήματα πρέπει ακόμη να σχεδιαστούν. Σε ποιες περιπτώσεις;
• Εάν υπάρχουν πολλές συνδέσεις στο ερώτημα, τις τυλίγετε σε υποεπιλογές. Και η σειρά με την οποία εκτελούνται έχει σημασία.
• Και το δεύτερο - εάν το αίτημα διανεμηθεί. Επειδή σε ένα κατανεμημένο ερώτημα, μόνο η πιο εσωτερική υποεπιλογή εκτελείται κατανεμημένη και οτιδήποτε άλλο μεταβιβάζεται σε έναν διακομιστή στον οποίο συνδεθήκατε και εκτελέσατε εκεί. Επομένως, εάν έχετε διανείμει ερωτήματα με πολλές συνδέσεις (join), τότε πρέπει να επιλέξετε τη σειρά.

Και ακόμη και σε απλούστερες περιπτώσεις, μερικές φορές είναι επίσης απαραίτητο να κάνετε τη δουλειά του προγραμματιστή και να ξαναγράψετε λίγο τα ερωτήματα.

Εδώ είναι ένα παράδειγμα. Στην αριστερή πλευρά υπάρχει ένα ερώτημα που δείχνει τις 5 κορυφαίες χώρες. Και παίρνει 2,5 δευτερόλεπτα, κατά τη γνώμη μου. Και στη δεξιά πλευρά, το ίδιο ερώτημα, αλλά ελαφρώς ξαναγραμμένο. Αντί να ομαδοποιούμε με συμβολοσειρά, αρχίσαμε να ομαδοποιούμε με κλειδί (int). Και είναι πιο γρήγορο. Και μετά συνδέσαμε ένα λεξικό με το αποτέλεσμα. Αντί για 2,5 δευτερόλεπτα, το αίτημα διαρκεί 1,5 δευτερόλεπτο. Αυτό είναι καλό.

Παρόμοιο παράδειγμα με φίλτρα επανεγγραφής. Εδώ είναι ένα αίτημα για τη Ρωσία. Λειτουργεί για 5 δευτερόλεπτα. Εάν το ξαναγράψουμε με τέτοιο τρόπο ώστε να συγκρίνουμε ξανά όχι μια συμβολοσειρά, αλλά αριθμούς με κάποιο σύνολο από αυτά τα κλειδιά που σχετίζονται με τη Ρωσία, τότε θα είναι πολύ πιο γρήγορο.

Υπάρχουν πολλά τέτοια κόλπα. Και σας επιτρέπουν να επιταχύνετε σημαντικά τα ερωτήματα που πιστεύετε ότι εκτελούνται ήδη γρήγορα ή, αντίθετα, εκτελούνται αργά. Μπορούν να γίνουν ακόμα πιο γρήγορα.

• Μέγιστη εργασία σε κατανεμημένη λειτουργία.
• Ταξινόμηση κατά ελάχιστους τύπους, όπως έκανα κατά ints.
• Εάν υπάρχουν συνδέσεις (συμμετοχή), λεξικά, τότε είναι καλύτερα να τις κάνετε ως τελευταία λύση, όταν έχετε ήδη δεδομένα τουλάχιστον μερικώς ομαδοποιημένα, τότε η λειτουργία σύνδεσης ή η κλήση λεξικού θα καλείται λιγότερες φορές και θα είναι πιο γρήγορη .
• Αντικατάσταση φίλτρων.

Υπάρχουν και άλλες τεχνικές, και όχι μόνο αυτές που έχω δείξει. Και όλα αυτά μερικές φορές μπορούν να επιταχύνουν σημαντικά την εκτέλεση των ερωτημάτων.

Ας προχωρήσουμε στο επόμενο παράδειγμα. Εταιρεία Χ από τις ΗΠΑ. Τι κάνει?

Υπήρχε μια εργασία:

• Offline σύνδεση διαφημιστικών συναλλαγών.
• Μοντελοποίηση διαφορετικών μοντέλων δεσίματος.

Ποιο είναι το σενάριο;

Ένας απλός επισκέπτης έρχεται στον ιστότοπο, για παράδειγμα, 20 φορές το μήνα από διαφορετικές διαφημίσεις, ή κάπως έτσι μερικές φορές έρχεται χωρίς διαφημίσεις, επειδή θυμάται αυτόν τον ιστότοπο. Κοιτάζει κάποια προϊόντα, τα βάζει στο καλάθι, τα βγάζει από το καλάθι. Και, στο τέλος, κάτι αγοράζει.

Εύλογες ερωτήσεις: "Ποιος πρέπει να πληρώσει για τη διαφήμιση, εάν είναι απαραίτητο;" και «Ποια διαφήμιση τον επηρέασε, αν υπάρχει;». Δηλαδή, γιατί αγόρασε και πώς να κάνει ανθρώπους σαν αυτό το άτομο να αγοράσουν και αυτοί;

Για να λύσετε αυτό το πρόβλημα, πρέπει να συνδέσετε τα συμβάντα που συμβαίνουν στον ιστότοπο με τον σωστό τρόπο, δηλαδή να δημιουργήσετε με κάποιο τρόπο μια σύνδεση μεταξύ τους. Στη συνέχεια αποστέλλονται για ανάλυση στο DWH. Και με βάση αυτήν την ανάλυση, δημιουργήστε μοντέλα για το ποιοι και ποιες διαφημίσεις θα εμφανίζονται.

Μια συναλλαγή διαφήμισης είναι ένα σύνολο σχετικών συμβάντων χρήστη που ξεκινούν από την εμφάνιση μιας διαφήμισης, μετά συμβαίνει κάτι, μετά ίσως μια αγορά και, στη συνέχεια, μπορεί να υπάρχουν αγορές εντός μιας αγοράς. Για παράδειγμα, εάν πρόκειται για μια εφαρμογή για κινητά ή για ένα παιχνίδι για κινητά, τότε συνήθως η εγκατάσταση της εφαρμογής πραγματοποιείται δωρεάν και αν γίνει κάτι εκεί, τότε μπορεί να απαιτηθούν χρήματα για αυτό. Και όσο περισσότερα ξοδεύει ένα άτομο στην εφαρμογή, τόσο πιο πολύτιμη είναι. Αλλά για αυτό πρέπει να συνδέσετε τα πάντα.

Υπάρχουν πολλά δεσμευτικά μοντέλα.

Τα πιο δημοφιλή είναι:

• Τελευταία αλληλεπίδραση, όπου η αλληλεπίδραση είναι είτε ένα κλικ είτε μια εμφάνιση.
• First Interaction, δηλαδή το πρώτο πράγμα που έφερε ένα άτομο στον ιστότοπο.
• Γραμμικός συνδυασμός - όλα εξίσου.
• Απόσβεση.
• Και ούτω καθεξής.

Και πώς λειτούργησαν όλα εξαρχής; Υπήρχε το Runtime και η Κασσάνδρα. Η Κασσάνδρα χρησιμοποιήθηκε ως αποθήκευση συναλλαγών, δηλαδή όλες οι σχετικές συναλλαγές αποθηκεύονταν σε αυτήν. Και όταν κάποιο συμβάν έρχεται στο Runtime, για παράδειγμα, δείχνει κάποια σελίδα ή κάτι άλλο, τότε έγινε αίτημα στην Κασσάνδρα - υπάρχει τέτοιο άτομο ή όχι. Στη συνέχεια αποκτήθηκαν οι συναλλαγές που την αφορούν. Και η σύνδεση έγινε.

Και αν είναι τυχερό που το αίτημα έχει αναγνωριστικό συναλλαγής, τότε είναι εύκολο. Αλλά συνήθως δεν υπάρχει τύχη. Επομένως, ήταν απαραίτητο να βρεθεί η τελευταία συναλλαγή ή η συναλλαγή με το τελευταίο κλικ κ.λπ.

Και όλα δούλεψαν πολύ καλά όσο το δέσιμο ήταν μέχρι το τελευταίο κλικ. Γιατί υπάρχουν, ας πούμε, 10 εκατομμύρια κλικ την ημέρα, 300 εκατομμύρια το μήνα, αν ορίσουμε ένα παράθυρο για ένα μήνα. Και επειδή στην Κασσάνδρα πρέπει να είναι όλα στη μνήμη για να τρέχει γρήγορα, επειδή το Runtime πρέπει να ανταποκρίνεται γρήγορα, χρειάστηκαν περίπου 10-15 διακομιστές.

Και όταν ήθελαν να συνδέσουν μια συναλλαγή με την οθόνη, αμέσως αποδείχθηκε ότι δεν ήταν τόσο διασκεδαστικό. Και γιατί? Μπορεί να φανεί ότι χρειάζεται να αποθηκευτούν 30 φορές περισσότερα συμβάντα. Και, κατά συνέπεια, χρειάζεστε 30 φορές περισσότερους διακομιστές. Και αποδεικνύεται ότι αυτό είναι κάποιο είδος αστρονομικής φιγούρας. Για να διατηρήσετε έως και 500 διακομιστές για να κάνετε τη σύνδεση, παρά το γεγονός ότι υπάρχουν σημαντικά λιγότεροι διακομιστές στο Runtime, τότε αυτό είναι κάποιου είδους λάθος αριθμός. Και άρχισαν να σκέφτονται τι να κάνουν.

Και πήγαμε στο ClickHouse. Και πώς να το κάνετε στο ClickHouse; Με την πρώτη ματιά, φαίνεται ότι πρόκειται για ένα σύνολο αντι-μοτίβων.

• Η συναλλαγή μεγαλώνει, συνδέουμε όλο και περισσότερα συμβάντα σε αυτήν, δηλαδή είναι μεταβλητή και το ClickHouse δεν λειτουργεί πολύ καλά με μεταβλητά αντικείμενα.
• Όταν ένας επισκέπτης έρχεται σε εμάς, πρέπει να βγάλουμε τις συναλλαγές του με κλειδί, με το αναγνωριστικό επίσκεψής του. Αυτό είναι επίσης ένα ερώτημα σημείου, δεν το κάνουν αυτό στο ClickHouse. Συνήθως το ClickHouse έχει μεγάλες ...σαρώσεις, αλλά εδώ πρέπει να λάβουμε κάποιες εγγραφές. Επίσης ένα antipattern.
• Επιπλέον, η συναλλαγή ήταν σε json, αλλά δεν ήθελαν να την ξαναγράψουν, έτσι ήθελαν να αποθηκεύσουν το json με μη δομημένο τρόπο και, αν χρειαστεί, να βγάλουν κάτι από αυτό. Και αυτό είναι επίσης ένα αντίτυπο.

Δηλαδή ένα σύνολο από αντιπρότυπα.

Ωστόσο, αποδείχθηκε ότι έφτιαξε ένα σύστημα που λειτούργησε πολύ καλά.

Τι έγινε; Εμφανίστηκε το ClickHouse, στο οποίο πετάχτηκαν αρχεία καταγραφής, χωρισμένα σε εγγραφές. Εμφανίστηκε μια αποδοθείσα υπηρεσία που έλαβε αρχεία καταγραφής από το ClickHouse. Μετά από αυτό, για κάθε καταχώριση, με αναγνωριστικό επίσκεψης, λάμβανα συναλλαγές που μπορεί να μην έχουν υποστεί ακόμη επεξεργασία και συν στιγμιότυπα, δηλαδή συναλλαγές που έχουν ήδη συνδεθεί, δηλαδή το αποτέλεσμα προηγούμενης εργασίας. Έκανα ήδη λογική από αυτά, επέλεξα τη σωστή συναλλαγή, συνέδεσα νέα γεγονότα. Εγγράφηκε ξανά. Το αρχείο καταγραφής επέστρεψε στο ClickHouse, δηλαδή είναι ένα συνεχώς κυκλικό σύστημα. Και εξάλλου πήγα στο DWH να το αναλύσω εκεί.

Σε αυτή τη μορφή δεν λειτούργησε πολύ καλά. Και για να διευκολύνουν το ClickHouse, όταν υπήρχε αίτημα ανά αναγνωριστικό επίσκεψης, ομαδοποιούσαν αυτά τα αιτήματα σε μπλοκ 1-000 αναγνωριστικών επισκέψεων και απέσυραν όλες τις συναλλαγές για 2-000 άτομα. Και τότε όλα λειτούργησαν.

Αν κοιτάξετε μέσα στο ClickHouse, τότε υπάρχουν μόνο 3 κύριοι πίνακες που εξυπηρετούν όλα αυτά.

Ο πρώτος πίνακας στον οποίο ανεβαίνουν τα αρχεία καταγραφής και τα αρχεία καταγραφής μεταφορτώνονται σχεδόν χωρίς επεξεργασία.

Δεύτερο τραπέζι. Μέσω της υλοποιημένης προβολής, από αυτά τα αρχεία καταγραφής, τσιμπήθηκαν γεγονότα που δεν έχουν ακόμη αποδοθεί, δηλαδή άσχετα. Και μέσω της υλοποιημένης προβολής, οι συναλλαγές αφαιρέθηκαν από αυτά τα αρχεία καταγραφής για να δημιουργηθεί ένα στιγμιότυπο. Δηλαδή, μια ειδική υλοποιημένη προβολή δημιούργησε ένα στιγμιότυπο, δηλαδή την τελευταία συσσωρευμένη κατάσταση της συναλλαγής.

Εδώ είναι το κείμενο γραμμένο σε SQL. Θα ήθελα να σχολιάσω μερικά σημαντικά πράγματα σε αυτό.

Το πρώτο σημαντικό πράγμα είναι η δυνατότητα εξαγωγής στηλών και πεδίων από το json στο ClickHouse. Δηλαδή, το ClickHouse έχει κάποιες μεθόδους για εργασία με json. Είναι πολύ, πολύ πρωτόγονοι.

Το visitParamExtractInt σάς επιτρέπει να εξαγάγετε χαρακτηριστικά από το json, δηλαδή το πρώτο χτύπημα λειτουργεί. Και με αυτόν τον τρόπο μπορείτε να βγάλετε το αναγνωριστικό συναλλαγής ή να επισκεφθείτε το αναγνωριστικό. Αυτή τη φορά.

Δεύτερον, εδώ χρησιμοποιείται ένα δύσκολο υλοποιημένο πεδίο. Τι σημαίνει? Αυτό σημαίνει ότι δεν μπορείτε να το εισαγάγετε στον πίνακα, δηλαδή δεν εισάγεται, υπολογίζεται και αποθηκεύεται κατά την εισαγωγή. Κατά την επικόλληση, το ClickHouse κάνει τη δουλειά για εσάς. Και αυτό που χρειάζεστε αργότερα έχει ήδη αφαιρεθεί από το json.

Σε αυτήν την περίπτωση, η υλοποιημένη προβολή είναι για μη επεξεργασμένες σειρές. Και ο πρώτος πίνακας με σχεδόν ακατέργαστους κορμούς μόλις χρησιμοποιείται. Και τι κάνει; Πρώτον, αλλάζει την ταξινόμηση, δηλαδή η ταξινόμηση γίνεται πλέον με αναγνωριστικό επίσκεψης, επειδή πρέπει να αποσύρουμε γρήγορα τη συναλλαγή του για ένα συγκεκριμένο άτομο.

Το δεύτερο σημαντικό πράγμα είναι το index_granularity. Αν έχετε δει MergeTree, είναι συνήθως 8 από προεπιλογή index_granularity. Τι είναι? Αυτή είναι η παράμετρος αραιότητας του δείκτη. Στο ClickHouse το ευρετήριο είναι αραιό, δεν ευρετηριάζει ποτέ κάθε καταχώρηση. Αυτό το κάνει κάθε 192. Και αυτό είναι καλό όταν απαιτούνται πολλά δεδομένα για υπολογισμό, αλλά κακό όταν είναι λίγα, επειδή υπάρχει μεγάλο κόστος. Και αν μειώσουμε την ευαισθησία του δείκτη, τότε μειώνουμε τα γενικά έξοδα. Δεν μπορεί να μειωθεί σε ένα, γιατί μπορεί να μην υπάρχει αρκετή μνήμη. Το ευρετήριο αποθηκεύεται πάντα στη μνήμη.

Το Snapshot χρησιμοποιεί επίσης κάποιες άλλες ενδιαφέρουσες λειτουργίες του ClickHouse.

Πρώτον, είναι το AggregatingMergeTree. Και το AggregatingMergeTree αποθηκεύει το argMax, δηλαδή αυτή είναι η κατάσταση της συναλλαγής που αντιστοιχεί στην τελευταία χρονική σήμανση. Οι συναλλαγές δημιουργούνται συνεχώς για έναν δεδομένο επισκέπτη. Και στην τελευταία κατάσταση αυτής της συναλλαγής, προσθέσαμε ένα συμβάν και έχουμε μια νέα κατάσταση. Χτύπησε ξανά το ClickHouse. Και μέσω του argMax σε αυτήν την υλοποιημένη προβολή, μπορούμε πάντα να έχουμε την τρέχουσα κατάσταση.

• Το δέσιμο είναι «αποσυνδεδεμένο» από το Runtime.
• Αποθηκεύονται και υποβάλλονται σε επεξεργασία έως και 3 δισεκατομμύρια συναλλαγές το μήνα. Αυτή είναι μια τάξη μεγέθους μεγαλύτερη από ό,τι ήταν στην Κασσάνδρα, δηλαδή σε ένα τυπικό σύστημα συναλλαγών.
• Σύμπλεγμα διακομιστών ClickHouse 2x5. 5 διακομιστές και κάθε διακομιστής έχει ένα αντίγραφο. Αυτό είναι ακόμη μικρότερο από ό,τι στην Κασσάνδρα για να γίνει απόδοση βάσει κλικ και εδώ έχουμε βάσει εντυπώσεων. Δηλαδή, αντί να αυξήσουν τον αριθμό των διακομιστών κατά 30 φορές, κατάφεραν να τους μειώσουν.

Και το τελευταίο παράδειγμα είναι η χρηματοοικονομική εταιρεία Y, η οποία ανέλυσε τους συσχετισμούς των μεταβολών στις τιμές των μετοχών.

Και η αποστολή ήταν:

• Υπάρχουν περίπου 5 μετοχές.
• Τα εισαγωγικά κάθε 100 χιλιοστά του δευτερολέπτου είναι γνωστά.
• Τα δεδομένα έχουν συσσωρευτεί για 10 χρόνια. Προφανώς, για κάποιες εταιρείες περισσότερο, για κάποιες λιγότερο.
• Υπάρχουν περίπου 100 δισεκατομμύρια σειρές συνολικά.

Και ήταν απαραίτητο να υπολογιστεί η συσχέτιση των αλλαγών.

Εδώ είναι δύο μετοχές και οι τιμές τους. Αν το ένα ανεβαίνει και το άλλο ανεβαίνει, τότε αυτή είναι μια θετική συσχέτιση, δηλαδή το ένα ανεβαίνει και το άλλο ανεβαίνει. Αν το ένα ανεβαίνει, όπως στο τέλος του γραφήματος, και το άλλο κατεβαίνει, τότε αυτή είναι αρνητική συσχέτιση, δηλαδή όταν το ένα ανεβαίνει, το άλλο πέφτει.

Αναλύοντας αυτές τις αμοιβαίες αλλαγές, μπορεί κανείς να κάνει προβλέψεις στη χρηματοπιστωτική αγορά.

Όμως το έργο είναι δύσκολο. Τι γίνεται για αυτό; Έχουμε 100 δισεκατομμύρια δίσκους που έχουν: χρόνο, απόθεμα και τιμή. Πρέπει να υπολογίσουμε πρώτα 100 δισεκατομμύρια φορές την τρέχουσα διαφορά από τον αλγόριθμο τιμών. Το RunningDifference είναι μια συνάρτηση στο ClickHouse που υπολογίζει διαδοχικά τη διαφορά μεταξύ δύο συμβολοσειρών.

Και μετά από αυτό, πρέπει να υπολογίσετε τη συσχέτιση και η συσχέτιση πρέπει να υπολογιστεί για κάθε ζεύγος. Για 5 μετοχές, τα ζεύγη είναι 000 εκατομμύρια. Και αυτό είναι πολύ, δηλαδή 12,5 φορές είναι απαραίτητο να υπολογιστεί ακριβώς μια τέτοια συνάρτηση συσχέτισης.

Και αν κάποιος ξέχασε, τότε το ͞x και το ͞y είναι ματ. προσδοκία δειγματοληψίας. Δηλαδή, είναι απαραίτητο όχι μόνο να υπολογιστούν οι ρίζες και τα αθροίσματα, αλλά και ένα ακόμη αθροίσματα μέσα σε αυτά τα αθροίσματα. Ένα σωρό υπολογισμοί πρέπει να γίνουν 12,5 εκατομμύρια φορές, ακόμη και να ομαδοποιηθούν ανά ώρες. Έχουμε και πολλές ώρες. Και πρέπει να το κάνετε σε 60 δευτερόλεπτα. Είναι ένα αστείο.

Ήταν απαραίτητο να έχουμε χρόνο τουλάχιστον με κάποιο τρόπο, γιατί όλα αυτά λειτουργούσαν πολύ, πολύ αργά πριν έρθει το ClickHouse.

Προσπάθησαν να το υπολογίσουν στο Hadoop, στο Spark, στο Greenplum. Και όλα αυτά ήταν πολύ αργά ή ακριβά. Δηλαδή, ήταν δυνατό να υπολογιστεί με κάποιο τρόπο, αλλά τότε ήταν ακριβό.

Και μετά ήρθε το ClickHouse και τα πράγματα έγιναν πολύ καλύτερα.

Σας υπενθυμίζω ότι έχουμε πρόβλημα με την εντοπιότητα των δεδομένων, γιατί οι συσχετισμοί δεν μπορούν να εντοπιστούν. Δεν μπορούμε να βάλουμε κάποια από τα δεδομένα σε έναν διακομιστή, κάποια σε έναν άλλο και να υπολογίσουμε, πρέπει να έχουμε όλα τα δεδομένα παντού.

Τι έκαναν? Αρχικά, τα δεδομένα είναι εντοπισμένα. Κάθε διακομιστής αποθηκεύει δεδομένα σχετικά με την τιμολόγηση ενός συγκεκριμένου συνόλου μετοχών. Και δεν αλληλεπικαλύπτονται. Επομένως, είναι δυνατός ο υπολογισμός του logReturn παράλληλα και ανεξάρτητα, όλα αυτά συμβαίνουν μέχρι στιγμής παράλληλα και κατανεμημένα.

Στη συνέχεια αποφασίσαμε να μειώσουμε αυτά τα δεδομένα, χωρίς να χάσουμε την εκφραστικότητα. Μειώστε τη χρήση συστοιχιών, δηλαδή για κάθε χρονική περίοδο, δημιουργήστε μια σειρά αποθεμάτων και μια σειρά τιμών. Επομένως, καταλαμβάνει πολύ λιγότερο χώρο δεδομένων. Και είναι λίγο πιο εύκολο να δουλέψεις μαζί τους. Αυτές είναι σχεδόν παράλληλες πράξεις, δηλαδή διαβάζουμε εν μέρει παράλληλα και μετά γράφουμε στον διακομιστή.

Μετά από αυτό, μπορεί να αναπαραχθεί. Το γράμμα "r" σημαίνει ότι αντιγράψαμε αυτά τα δεδομένα. Δηλαδή, έχουμε τα ίδια δεδομένα και στους τρεις διακομιστές - αυτοί είναι οι πίνακες.

Και μετά με ένα ειδικό σενάριο από αυτό το σύνολο των 12,5 εκατομμυρίων συσχετισμών που πρέπει να υπολογιστούν, μπορείτε να φτιάξετε πακέτα. Δηλαδή 2 εργασίες με 500 ζεύγη συσχετισμών. Και αυτή η εργασία πρέπει να υπολογιστεί σε έναν συγκεκριμένο διακομιστή ClickHouse. Έχει όλα τα στοιχεία, γιατί τα στοιχεία είναι ίδια και μπορεί να τα υπολογίσει διαδοχικά.

Για άλλη μια φορά, έτσι φαίνεται. Πρώτον, έχουμε όλα τα δεδομένα σε αυτή τη δομή: χρόνο, μετοχές, τιμή. Στη συνέχεια υπολογίσαμε το logReturn, δηλαδή δεδομένα της ίδιας δομής, αλλά αντί για την τιμή έχουμε ήδη logReturn. Στη συνέχεια ανανεώθηκαν, δηλ. πήραμε το χρόνο και την groupArray για μετοχές και τιμές. Αντιγραφή. Και μετά από αυτό, δημιουργήσαμε ένα σωρό εργασίες και τις τροφοδοτήσαμε στο ClickHouse ώστε να τις μετρήσει. Και λειτουργεί.

Στην απόδειξη της ιδέας, η εργασία ήταν μια δευτερεύουσα εργασία, δηλαδή, λήφθηκαν λιγότερα δεδομένα. Και μόνο τρεις διακομιστές.

Τα δύο πρώτα στάδια: ο υπολογισμός του Log_return και η αναδίπλωση σε πίνακες χρειάστηκαν περίπου μία ώρα.

Και ο υπολογισμός της συσχέτισης είναι περίπου 50 ώρες. Αλλά 50 ώρες δεν είναι αρκετές, γιατί δούλευαν για εβδομάδες. Ήταν μεγάλη επιτυχία. Και αν μετρήσετε, τότε 70 φορές το δευτερόλεπτο όλα μετρήθηκαν σε αυτό το σύμπλεγμα.

Αλλά το πιο σημαντικό είναι ότι αυτό το σύστημα είναι πρακτικά χωρίς εμπόδια, δηλαδή κλιμακώνεται σχεδόν γραμμικά. Και το έλεγξαν. Κλιμάκωσε με επιτυχία.

• Το σωστό σχέδιο είναι η μισή μάχη. Και το σωστό σχέδιο είναι η χρήση όλων των απαραίτητων τεχνολογιών ClickHouse.
• Τα Summing/AggregatingMergeTrees είναι τεχνολογίες που σας επιτρέπουν να συγκεντρώνετε ή να εξετάζετε ένα στιγμιότυπο κατάστασης ως ειδική περίπτωση. Και απλοποιεί πάρα πολλά πράγματα.
• Οι υλοποιημένες προβολές σάς επιτρέπουν να παρακάμψετε το όριο ενός ευρετηρίου. Ίσως δεν το είπα πολύ καθαρά, αλλά όταν φορτώσαμε τα αρχεία καταγραφής, τα μη επεξεργασμένα αρχεία καταγραφής ήταν στον πίνακα με ένα ευρετήριο και τα αρχεία καταγραφής χαρακτηριστικών ήταν στον πίνακα, δηλαδή τα ίδια δεδομένα, μόνο φιλτραρισμένα, αλλά το ευρετήριο ήταν εντελώς οι υπολοιποι. Φαίνεται να είναι τα ίδια δεδομένα, αλλά διαφορετική ταξινόμηση. Και το Materialized Views σάς επιτρέπει, εάν το χρειάζεστε, να παρακάμψετε έναν τέτοιο περιορισμό ClickHouse.
• Μειώστε τη λεπτομέρεια ευρετηρίου για ερωτήματα σημείου.
• Και διανείμετε τα δεδομένα έξυπνα, προσπαθήστε να εντοπίζετε τα δεδομένα εντός του διακομιστή όσο το δυνατόν περισσότερο. Και προσπαθήστε να διασφαλίσετε ότι τα αιτήματα χρησιμοποιούν επίσης τοπική προσαρμογή, όπου είναι δυνατόν, όσο το δυνατόν περισσότερο.

Και συνοψίζοντας αυτή τη σύντομη ομιλία, μπορούμε να πούμε ότι το ClickHouse έχει πλέον σταθερά καταλάβει την περιοχή τόσο των εμπορικών βάσεων δεδομένων όσο και των βάσεων δεδομένων ανοιχτού κώδικα, δηλαδή ειδικά για την ανάλυση. Ταιριάζει απόλυτα σε αυτό το τοπίο. Και επιπλέον, αρχίζει σιγά σιγά να παραγκωνίζει τους άλλους, γιατί όταν έχετε ClickHouse, δεν χρειάζεστε το InfiniDB. Η Vertika μπορεί να μην χρειαστεί σύντομα, εάν παρέχουν κανονική υποστήριξη SQL. Απολαμβάνω!

-Ευχαριστώ για την αναφορά! Πολύ ενδιαφέρον! Υπήρχαν συγκρίσεις με το Apache Phoenix;

Όχι, δεν άκουσα κανέναν να συγκρίνει. Εμείς και η Yandex προσπαθούμε να παρακολουθούμε όλες τις συγκρίσεις του ClickHouse με διαφορετικές βάσεις δεδομένων. Γιατί αν ξαφνικά κάτι αποδειχθεί πιο γρήγορο από το ClickHouse, τότε η Lesha Milovidov δεν μπορεί να κοιμηθεί τη νύχτα και αρχίζει να το επιταχύνει γρήγορα. Δεν έχω ακούσει για τέτοια σύγκριση.

• (Aleksey Milovidov) Το Apache Phoenix είναι ένας κινητήρας SQL που τροφοδοτείται από την Hbase. Το Hbase είναι κυρίως για σενάριο εργασίας βασικής αξίας. Εκεί, σε κάθε γραμμή, μπορεί να υπάρχει ένας αυθαίρετος αριθμός στηλών με αυθαίρετα ονόματα. Αυτό μπορεί να ειπωθεί για συστήματα όπως το Hbase, η Cassandra. Και είναι ακριβώς τα βαριά αναλυτικά ερωτήματα που δεν θα λειτουργήσουν κανονικά για αυτούς. Ή μπορεί να πιστεύετε ότι λειτουργούν καλά, αν δεν είχατε εμπειρία με το ClickHouse.

• σας ευχαριστώ

  • Καλό απόγευμα Με ενδιαφέρει ήδη αρκετά αυτό το θέμα, γιατί έχω ένα αναλυτικό υποσύστημα. Αλλά όταν κοιτάζω το ClickHouse, έχω την αίσθηση ότι το ClickHouse είναι πολύ κατάλληλο για ανάλυση συμβάντων, μεταβλητό. Και αν χρειαστεί να αναλύσω πολλά επιχειρηματικά δεδομένα με ένα σωρό μεγάλους πίνακες, τότε το ClickHouse, από όσο καταλαβαίνω, δεν είναι πολύ κατάλληλο για μένα; Ειδικά αν αλλάξουν. Είναι σωστό αυτό ή υπάρχουν παραδείγματα που μπορούν να το διαψεύσουν;

  • Αυτό είναι σωστό. Και αυτό ισχύει για τις περισσότερες εξειδικευμένες αναλυτικές βάσεις δεδομένων. Είναι προσαρμοσμένα για το γεγονός ότι υπάρχουν ένα ή περισσότερα μεγάλα τραπέζια που είναι μεταβλητά και για πολλά μικρά που αλλάζουν αργά. Δηλαδή, το ClickHouse δεν είναι σαν την Oracle, όπου μπορείτε να βάλετε τα πάντα και να δημιουργήσετε μερικά πολύ περίπλοκα ερωτήματα. Για να χρησιμοποιήσετε αποτελεσματικά το ClickHouse, πρέπει να δημιουργήσετε ένα σχήμα με τρόπο που να λειτουργεί καλά στο ClickHouse. Δηλαδή, αποφύγετε την υπερβολική κανονικοποίηση, χρησιμοποιήστε λεξικά, προσπαθήστε να κάνετε λιγότερους μακροσκελούς συνδέσμους. Και αν το σχήμα έχει κατασκευαστεί με αυτόν τον τρόπο, τότε παρόμοιες επιχειρηματικές εργασίες μπορούν να επιλυθούν στο ClickHouse πολύ πιο αποτελεσματικά από ό,τι σε μια παραδοσιακή σχεσιακή βάση δεδομένων.

Ευχαριστώ για την αναφορά! Έχω μια ερώτηση για την τελευταία οικονομική υπόθεση. Είχαν αναλυτικά στοιχεία. Ήταν απαραίτητο να συγκρίνουμε πώς ανεβαίνουν και κατεβαίνουν. Και καταλαβαίνω ότι φτιάξατε το σύστημα ειδικά για αυτά τα αναλυτικά στοιχεία; Εάν αύριο, για παράδειγμα, χρειαστούν κάποια άλλη αναφορά για αυτά τα δεδομένα, χρειάζεται να ξαναχτίσουν το σχήμα και να ανεβάσουν τα δεδομένα; Δηλαδή να κάνω κάποιου είδους προεπεξεργασία για να πάρει το αίτημα;

Φυσικά, αυτή είναι η χρήση του ClickHouse για μια πολύ συγκεκριμένη εργασία. Θα μπορούσε πιο παραδοσιακά να λυθεί μέσα στο Hadoop. Για τον Hadoop, αυτό είναι ένα ιδανικό έργο. Αλλά στο Hadoop είναι πολύ αργό. Και ο στόχος μου είναι να δείξω ότι το ClickHouse μπορεί να λύσει εργασίες που συνήθως επιλύονται με εντελώς διαφορετικά μέσα, αλλά ταυτόχρονα να το κάνει πολύ πιο αποτελεσματικά. Είναι προσαρμοσμένο για μια συγκεκριμένη εργασία. Είναι σαφές ότι αν υπάρχει πρόβλημα με κάτι παρόμοιο, τότε μπορεί να λυθεί με παρόμοιο τρόπο.

Είναι σαφές. Είπατε ότι επεξεργάστηκαν 50 ώρες. Είναι από την αρχή, πότε φορτώσατε τα δεδομένα ή λάβατε τα αποτελέσματα;

Ναι ναι.

Εντάξει, σας ευχαριστώ πολύ.

Αυτό είναι σε ένα σύμπλεγμα διακομιστών 3.

Χαιρετίσματα! Ευχαριστώ για την αναφορά! Όλα είναι πολύ ενδιαφέροντα. Δεν θα ρωτήσω λίγο για τη λειτουργικότητα, αλλά για τη χρήση του ClickHouse από άποψη σταθερότητας. Δηλαδή είχες κανένα, έπρεπε να κάνεις restore; Πώς συμπεριφέρεται το ClickHouse σε αυτήν την περίπτωση; Και έτυχε να έχεις και αντίγραφο; Για παράδειγμα, αντιμετωπίσαμε πρόβλημα με το ClickHouse όταν εξακολουθεί να ξεφεύγει από το όριο του και να πέφτει.

Φυσικά, δεν υπάρχουν ιδανικά συστήματα. Και το ClickHouse έχει επίσης τα δικά του προβλήματα. Έχετε ακούσει όμως ότι το Yandex.Metrica δεν λειτουργεί για μεγάλο χρονικό διάστημα; Πιθανώς όχι. Λειτουργεί αξιόπιστα από το 2012-2013 στο ClickHouse. Μπορώ να πω το ίδιο για την εμπειρία μου. Ποτέ δεν είχαμε ολοκληρωτικές αποτυχίες. Μερικά επιμέρους πράγματα θα μπορούσαν να συμβούν, αλλά ποτέ δεν ήταν αρκετά κρίσιμα ώστε να επηρεάσουν σοβαρά την επιχείρηση. Δεν έγινε ποτέ. Το ClickHouse είναι αρκετά αξιόπιστο και δεν κολλάει τυχαία. Δεν χρειάζεται να ανησυχείτε για αυτό. Δεν είναι ακατέργαστο πράγμα. Αυτό έχει αποδειχθεί από πολλές εταιρείες.

Γειά σου! Είπατε ότι πρέπει να σκεφτείτε αμέσως το σχήμα δεδομένων. Κι αν συνέβαινε; Τα δεδομένα μου χύνονται και χύνονται. Περνούν έξι μήνες και καταλαβαίνω ότι είναι αδύνατο να ζεις έτσι, πρέπει να ανεβάσω ξανά τα δεδομένα και να κάνω κάτι με αυτά.

Αυτό εξαρτάται φυσικά από το σύστημά σας. Υπάρχουν διάφοροι τρόποι για να το κάνετε αυτό χωρίς σχεδόν καμία διακοπή. Για παράδειγμα, μπορείτε να δημιουργήσετε μια Υλοποιημένη προβολή στην οποία να δημιουργήσετε μια διαφορετική δομή δεδομένων, εάν μπορεί να αντιστοιχιστεί μοναδικά. Δηλαδή, εάν επιτρέπει την αντιστοίχιση με χρήση του ClickHouse, δηλαδή την εξαγωγή κάποιων πραγμάτων, την αλλαγή του πρωτεύοντος κλειδιού, την αλλαγή διαμερισμάτων, τότε μπορείτε να κάνετε μια Υλοποιημένη προβολή. Αντικαταστήστε τα παλιά σας δεδομένα εκεί, τα νέα θα γραφτούν αυτόματα. Και μετά απλώς μεταβείτε στη χρήση της Υλοποιημένης προβολής, μετά αλλάξτε την εγγραφή και σκοτώστε τον παλιό πίνακα. Αυτή είναι γενικά μια μη σταματημένη μέθοδος.

Σας ευχαριστώ.

Πηγή: www.habr.com