Ο χρόνος για την υποβολή αναφορών στο Excel εξαφανίζεται γρήγορα - η τάση προς εύχρηστα εργαλεία για την παρουσίαση και την ανάλυση πληροφοριών είναι ορατή σε όλους τους τομείς. Συζητάμε εσωτερικά την ψηφιοποίηση των αναφορών εδώ και πολύ καιρό και επιλέξαμε το σύστημα ανάλυσης οπτικοποίησης και αυτοεξυπηρέτησης Tableau. Ο Alexander Bezugly, επικεφαλής του τμήματος αναλυτικών λύσεων και αναφοράς του Ομίλου M.Video-Eldorado, μίλησε για την εμπειρία και τα αποτελέσματα της κατασκευής ενός ταμπλό μάχης.
Θα πω αμέσως ότι δεν υλοποιήθηκαν όλα όσα είχαν προγραμματιστεί, αλλά η εμπειρία ήταν ενδιαφέρουσα, ελπίζω να είναι χρήσιμη και σε εσάς. Και αν κάποιος έχει κάποιες ιδέες για το πώς θα μπορούσε να γίνει καλύτερα, θα ήμουν πολύ ευγνώμων για τις συμβουλές και τις ιδέες σας.
Κάτω από την περικοπή αναφέρεται τι συναντήσαμε και τι μάθαμε.
Από πού ξεκινήσαμε;
Το M.Video-Eldorado διαθέτει ένα καλά ανεπτυγμένο μοντέλο δεδομένων: δομημένες πληροφορίες με το απαιτούμενο βάθος αποθήκευσης και τεράστιο αριθμό αναφορών σταθερής μορφής (δείτε περισσότερες λεπτομέρειες ). Από αυτά, οι αναλυτές δημιουργούν είτε συγκεντρωτικούς πίνακες είτε μορφοποιημένα ενημερωτικά δελτία στο Excel ή όμορφες παρουσιάσεις PowerPoint για τελικούς χρήστες.
Πριν από περίπου δύο χρόνια, αντί για αναφορές σταθερής μορφής, αρχίσαμε να δημιουργούμε αναλυτικές αναφορές στο SAP Analysis (ένα πρόσθετο Excel, ουσιαστικά ένας συγκεντρωτικός πίνακας πάνω από τη μηχανή OLAP). Αλλά αυτό το εργαλείο δεν ήταν σε θέση να καλύψει τις ανάγκες όλων των χρηστών· η πλειοψηφία συνέχισε να χρησιμοποιεί πληροφορίες που επεξεργάζονταν επιπρόσθετα οι αναλυτές.
Οι τελικοί χρήστες μας χωρίζονται σε τρεις κατηγορίες:
Ανώτατη διοίκηση. Ζητάει πληροφορίες με τρόπο καλά παρουσιασμένο και σαφώς κατανοητό.
Μέση διοίκηση, προηγμένους χρήστες. Ενδιαφέρεστε για την εξερεύνηση δεδομένων και είναι σε θέση να δημιουργεί ανεξάρτητα αναφορές εάν υπάρχουν διαθέσιμα εργαλεία. Έγιναν οι βασικοί χρήστες των αναλυτικών αναφορών στο SAP Analysis.
Μαζικοί χρήστες. Δεν ενδιαφέρονται να αναλύουν ανεξάρτητα δεδομένα· χρησιμοποιούν αναφορές με περιορισμένο βαθμό ελευθερίας, σε μορφή ενημερωτικών δελτίων και συγκεντρωτικών πινάκων στο Excel.
Η ιδέα μας ήταν να καλύψουμε τις ανάγκες όλων των χρηστών και να τους δώσουμε ένα ενιαίο, βολικό εργαλείο. Αποφασίσαμε να ξεκινήσουμε με την ανώτατη διοίκηση. Χρειάζονταν εύχρηστους πίνακες εργαλείων για την ανάλυση των βασικών επιχειρηματικών αποτελεσμάτων. Έτσι, ξεκινήσαμε με το Tableau και πρώτα επιλέξαμε δύο κατευθύνσεις: δείκτες λιανικής και διαδικτυακών πωλήσεων με περιορισμένο βάθος και εύρος ανάλυσης, που θα κάλυπταν περίπου το 80% των δεδομένων που ζητούσε η ανώτατη διοίκηση.
Δεδομένου ότι οι χρήστες των πινάκων εργαλείων ήταν ανώτατα στελέχη, εμφανίστηκε άλλος ένας επιπλέον KPI του προϊόντος - η ταχύτητα απόκρισης. Κανείς δεν θα περιμένει 20-30 δευτερόλεπτα για να ενημερωθούν τα δεδομένα. Η πλοήγηση θα έπρεπε να είχε γίνει μέσα σε 4-5 δευτερόλεπτα, ή καλύτερα, να γίνει αμέσως. Κι αυτό, δυστυχώς, δεν το καταφέραμε.
Έτσι φαινόταν η διάταξη του κύριου ταμπλό μας:
Η βασική ιδέα είναι να συνδυαστούν οι κύριοι οδηγοί KPI, από τους οποίους ήταν 19 συνολικά, στα αριστερά και να παρουσιαστεί η δυναμική και η κατανομή τους κατά κύρια χαρακτηριστικά στα δεξιά. Το έργο φαίνεται απλό, η οπτικοποίηση είναι λογική και κατανοητή, μέχρι να βουτήξετε στις λεπτομέρειες.
Λεπτομέρεια 1. Όγκος δεδομένων
Ο κύριος πίνακας μας για ετήσιες πωλήσεις καταλαμβάνει περίπου 300 εκατομμύρια σειρές. Δεδομένου ότι είναι απαραίτητο να αντικατοπτρίζεται η δυναμική για το περασμένο έτος και το προηγούμενο έτος, ο όγκος των δεδομένων μόνο για τις πραγματικές πωλήσεις είναι περίπου 1 δισεκατομμύριο γραμμές. Οι πληροφορίες για τα προγραμματισμένα δεδομένα και το μπλοκ διαδικτυακών πωλήσεων αποθηκεύονται επίσης χωριστά. Επομένως, παρόλο που χρησιμοποιήσαμε τη στήλη στη μνήμη DB SAP HANA, η ταχύτητα του ερωτήματος με την επιλογή όλων των δεικτών για μία εβδομάδα από την τρέχουσα αποθήκευση εν κινήσει ήταν περίπου 15-20 δευτερόλεπτα. Η λύση σε αυτό το πρόβλημα προτείνεται από μόνη της - πρόσθετη υλοποίηση δεδομένων. Έχει όμως και παγίδες, περισσότερα για αυτές παρακάτω.
Λεπτομέρεια 2. Μη προσθετικοί δείκτες
Πολλοί από τους KPI μας συνδέονται με τον αριθμό των αποδείξεων. Και αυτός ο δείκτης αντιπροσωπεύει COUNT DISTINCT του αριθμού των σειρών (επικεφαλίδες ελέγχου) και εμφανίζει διαφορετικά ποσά ανάλογα με τα επιλεγμένα χαρακτηριστικά. Για παράδειγμα, πώς πρέπει να υπολογιστεί αυτός ο δείκτης και η παράγωγός του:
Για να κάνετε τους υπολογισμούς σας σωστούς, μπορείτε:
- Υπολογίστε τέτοιους δείκτες εν κινήσει στο χώρο αποθήκευσης.
- Εκτελέστε υπολογισμούς για ολόκληρο τον όγκο δεδομένων στο Tableau, π.χ. κατόπιν αιτήματος στο Tableau, παρέχετε όλα τα δεδομένα σύμφωνα με επιλεγμένα φίλτρα στην ευαισθησία της θέσης παραλαβής.
- Δημιουργήστε μια υλοποιημένη βιτρίνα στην οποία θα υπολογίζονται όλοι οι δείκτες σε όλες τις επιλογές δειγμάτων που δίνουν διαφορετικά μη πρόσθετα αποτελέσματα.
Είναι σαφές ότι στο παράδειγμα UTE1 και UTE2 είναι χαρακτηριστικά υλικού που αντιπροσωπεύουν την ιεραρχία του προϊόντος. Αυτό δεν είναι κάτι στατικό· η διαχείριση εντός της εταιρείας γίνεται μέσω αυτού, γιατί Διαφορετικοί διαχειριστές είναι υπεύθυνοι για διαφορετικές ομάδες προϊόντων. Είχαμε πολλές παγκόσμιες αναθεωρήσεις αυτής της ιεραρχίας, όταν άλλαξαν όλα τα επίπεδα, όταν αναθεωρήθηκαν οι σχέσεις και αλλαγές σταθερών σημείων, όταν μια ομάδα μετακινήθηκε από τον έναν κόμβο στον άλλο. Στη συμβατική αναφορά, όλα αυτά υπολογίζονται εν κινήσει από τα χαρακτηριστικά του υλικού· στην περίπτωση υλοποίησης αυτών των δεδομένων, είναι απαραίτητο να αναπτυχθεί ένας μηχανισμός για την παρακολούθηση τέτοιων αλλαγών και την αυτόματη επαναφόρτωση ιστορικών δεδομένων. Ένα πολύ μη τετριμμένο έργο.
Λεπτομέρεια 3. Σύγκριση δεδομένων
Αυτό το σημείο είναι παρόμοιο με το προηγούμενο. Το συμπέρασμα είναι ότι κατά την ανάλυση μιας εταιρείας, είναι συνηθισμένο να σχηματίζονται διάφορα επίπεδα σύγκρισης με την προηγούμενη περίοδο:
Σύγκριση με την προηγούμενη περίοδο (μέρα με μέρα, εβδομάδα σε εβδομάδα, μήνα σε μήνα)
Σε αυτή τη σύγκριση, υποτίθεται ότι ανάλογα με την περίοδο που έχει επιλέξει ο χρήστης (για παράδειγμα, η 33η εβδομάδα του έτους), θα πρέπει να δείξουμε τη δυναμική μέχρι την 32η εβδομάδα, εάν επιλέξαμε δεδομένα για έναν μήνα, για παράδειγμα, Μάιο , τότε αυτή η σύγκριση θα έδειχνε τη δυναμική μέχρι τον Απρίλιο.
Σύγκριση με πέρυσι
Η κύρια απόχρωση εδώ είναι ότι όταν συγκρίνετε ανά ημέρα και κατά εβδομάδα, δεν παίρνετε την ίδια ημέρα του περασμένου έτους, δηλ. δεν μπορείτε απλά να βάλετε το τρέχον έτος μείον ένα. Πρέπει να κοιτάξετε την ημέρα της εβδομάδας που συγκρίνετε. Όταν συγκρίνετε μήνες, αντίθετα, πρέπει να πάρετε ακριβώς την ίδια ημερολογιακή ημέρα του περασμένου έτους. Υπάρχουν επίσης αποχρώσεις με δίσεκτα έτη. Στα αρχικά αποθετήρια, όλες οι πληροφορίες διανέμονται ανά ημέρα· δεν υπάρχουν ξεχωριστά πεδία με εβδομάδες, μήνες ή χρόνια. Επομένως, για να αποκτήσετε μια πλήρη αναλυτική διατομή στον πίνακα, πρέπει να μετρήσετε όχι μία περίοδο, για παράδειγμα μια εβδομάδα, αλλά 4 εβδομάδες, και στη συνέχεια να συγκρίνετε αυτά τα δεδομένα, να αντικατοπτρίσετε τη δυναμική, τις αποκλίσεις. Κατά συνέπεια, αυτή η λογική για τη δημιουργία συγκρίσεων στη δυναμική μπορεί επίσης να εφαρμοστεί είτε στο Tableau είτε στην πλευρά της βιτρίνας. Ναι, και φυσικά γνωρίζαμε και σκεφτήκαμε αυτές τις λεπτομέρειες στο στάδιο του σχεδιασμού, αλλά ήταν δύσκολο να προβλεφθεί ο αντίκτυπός τους στην απόδοση του τελικού ταμπλό.
Κατά την υλοποίηση του ταμπλό, ακολουθήσαμε τη μεγάλη διαδρομή Agile. Καθήκον μας ήταν να παρέχουμε ένα εργαλείο εργασίας με τα απαραίτητα δεδομένα για δοκιμές όσο το δυνατόν γρηγορότερα. Ως εκ τούτου, προχωρήσαμε σε σπριντ και αρχίσαμε να ελαχιστοποιούμε τις εργασίες στο πλάι της τρέχουσας αποθήκευσης.
Μέρος 1: Πίστη στο Ταμπλό
Για να απλοποιήσουμε την υποστήριξη IT και να εφαρμόσουμε γρήγορα τις αλλαγές, αποφασίσαμε να κάνουμε τη λογική για τον υπολογισμό μη πρόσθετων δεικτών και τη σύγκριση προηγούμενων περιόδων στο Tableau.
Στάδιο 1. Όλα είναι ζωντανά, χωρίς τροποποιήσεις παραθύρου.
Σε αυτό το στάδιο, συνδέσαμε το Tableau με τις τρέχουσες βιτρίνες και αποφασίσαμε να δούμε πώς θα υπολογιστεί ο αριθμός των αποδείξεων για ένα έτος.
Το αποτέλεσμα:
Η απάντηση ήταν καταθλιπτική - 20 λεπτά. Μεταφορά δεδομένων μέσω δικτύου, υψηλό φορτίο στο Tableau. Συνειδητοποιήσαμε ότι η λογική με μη πρόσθετους δείκτες πρέπει να εφαρμοστεί στο HANA. Αυτό δεν μας τρόμαξε πολύ, είχαμε ήδη παρόμοια εμπειρία με το BO και το Analysis και ξέραμε πώς να φτιάχνουμε γρήγορες βιτρίνες στο HANA που παράγουν σωστά υπολογισμένους μη πρόσθετους δείκτες. Τώρα το μόνο που έμενε ήταν να τα προσαρμόσω στο Tableau.
Στάδιο 2. Συντονίζουμε τις προθήκες, χωρίς υλοποίηση, όλα εν κινήσει.
Δημιουργήσαμε μια ξεχωριστή νέα βιτρίνα που παρήγαγε τα απαιτούμενα δεδομένα για το TABLEAU on the fly. Γενικά, είχαμε ένα καλό αποτέλεσμα· μειώσαμε τον χρόνο δημιουργίας όλων των δεικτών σε μία εβδομάδα σε 9-10 δευτερόλεπτα. Και ειλικρινά περιμέναμε ότι στο Tableau ο χρόνος απόκρισης του ταμπλό θα ήταν 20-30 δευτερόλεπτα στο πρώτο άνοιγμα και μετά λόγω της cache από 10 έως 12, που σε γενικές γραμμές θα μας ταίριαζε.
Το αποτέλεσμα:
Πρώτο ανοιχτό ταμπλό: 4-5 λεπτά
Οποιοδήποτε κλικ: 3-4 λεπτά
Κανείς δεν περίμενε τέτοια επιπλέον αύξηση στη δουλειά της βιτρίνας.
Μέρος 2. Βουτήξτε στο Tableau
Στάδιο 1. Ανάλυση απόδοσης πίνακα και γρήγορος συντονισμός
Αρχίσαμε να αναλύουμε πού ξοδεύει το Tableau τον περισσότερο χρόνο του. Και υπάρχουν αρκετά καλά εργαλεία για αυτό, το οποίο, φυσικά, είναι ένα συν του Tableau. Το κύριο πρόβλημα που εντοπίσαμε ήταν τα πολύ περίπλοκα ερωτήματα SQL που δημιουργούσε το Tableau. Συνδέθηκαν κυρίως με:
- Μεταφορά δεδομένων. Δεδομένου ότι το Tableau δεν διαθέτει εργαλεία για τη μεταφορά συνόλων δεδομένων, για να δημιουργήσουμε την αριστερή πλευρά του πίνακα εργαλείων με μια λεπτομερή αναπαράσταση όλων των KPI, έπρεπε να δημιουργήσουμε έναν πίνακα χρησιμοποιώντας μια περίπτωση. Το μέγεθος των ερωτημάτων SQL στη βάση δεδομένων έφτασε τους 120 χαρακτήρες.
- επιλογή χρονικής περιόδου. Ένα τέτοιο ερώτημα σε επίπεδο βάσης δεδομένων χρειάστηκε περισσότερο χρόνο για τη μεταγλώττιση παρά για την εκτέλεση:
Εκείνοι. επεξεργασία αιτήματος 12 δευτερόλεπτα + 5 δευτερόλεπτα εκτέλεση.
Αποφασίσαμε να απλοποιήσουμε τη λογική υπολογισμού στην πλευρά του Tableau και να μετακινήσουμε ένα άλλο μέρος των υπολογισμών στο επίπεδο της βιτρίνας και της βάσης δεδομένων. Αυτό έφερε καλά αποτελέσματα.
Πρώτα, κάναμε τη μεταφορά εν κινήσει, το κάναμε μέσω μιας πλήρους εξωτερικής ένωσης στο τελικό στάδιο του υπολογισμού VIEW, σύμφωνα με αυτήν την προσέγγιση που περιγράφεται στο wiki и .
Δηλαδή, φτιάξαμε έναν πίνακα ρυθμίσεων - έναν πίνακα μεταφοράς (21x21) και λάβαμε όλους τους δείκτες σε ανάλυση σειρά προς σειρά.
Ήταν:
Εγινε:
Σχεδόν δεν δαπανάται χρόνος για τη μεταφορά της ίδιας της βάσης δεδομένων. Το αίτημα για όλους τους δείκτες για την εβδομάδα συνέχισε να υποβάλλεται σε επεξεργασία σε περίπου 10 δευτερόλεπτα. Αλλά από την άλλη, έχει χαθεί η ευελιξία όσον αφορά την κατασκευή ενός ταμπλό με βάση έναν συγκεκριμένο δείκτη, δηλ. για τη δεξιά πλευρά του ταμπλό όπου παρουσιάζεται η δυναμική και η λεπτομερής ανάλυση μιας συγκεκριμένης ένδειξης, προηγουμένως η βιτρίνα λειτουργούσε σε 1-3 δευτερόλεπτα, επειδή το αίτημα βασίστηκε σε έναν δείκτη και τώρα η βάση δεδομένων επέλεγε πάντα όλους τους δείκτες και φιλτράρει το αποτέλεσμα πριν επιστρέψει το αποτέλεσμα στο Tableau.
Ως αποτέλεσμα, η ταχύτητα του ταμπλό μειώθηκε σχεδόν 3 φορές.
Το αποτέλεσμα:
- 5 δευτερόλεπτα – ανάλυση πινάκων εργαλείων, απεικονίσεις
- 15-20 δευτερόλεπτα - προετοιμασία για τη σύνταξη ερωτημάτων με την εκτέλεση προ-υπολογισμών στο Tableau
- 35-45 sec - συλλογή ερωτημάτων SQL και παράλληλη διαδοχική εκτέλεσή τους στο Hana
- 5 δευτερόλεπτα – επεξεργασία αποτελεσμάτων, ταξινόμηση, επανυπολογισμός απεικονίσεων στο Tableau
- Φυσικά, τέτοια αποτελέσματα δεν ταίριαζαν στην επιχείρηση και συνεχίσαμε τη βελτιστοποίηση.
Στάδιο 2. Ελάχιστη λογική στο Tableau, πλήρης υλοποίηση
Καταλάβαμε ότι ήταν αδύνατο να δημιουργηθεί ένας πίνακας εργαλείων με χρόνο απόκρισης πολλών δευτερολέπτων σε μια βιτρίνα που λειτουργεί για 10 δευτερόλεπτα και εξετάσαμε επιλογές για την υλοποίηση δεδομένων από την πλευρά της βάσης δεδομένων ειδικά για τον απαιτούμενο πίνακα εργαλείων. Αλλά αντιμετωπίσαμε ένα παγκόσμιο πρόβλημα που περιγράφεται παραπάνω - μη πρόσθετους δείκτες. Δεν μπορέσαμε να βεβαιωθούμε ότι κατά την αλλαγή των φίλτρων ή των λεπτομερειών, το Tableau άλλαζε με ευελιξία διαφορετικές βιτρίνες και επίπεδα προσχεδιασμένα για διαφορετικές ιεραρχίες προϊόντων (στο παράδειγμα, τρία ερωτήματα χωρίς UTE, με UTE1 και UTE2 παράγουν διαφορετικά αποτελέσματα). Επομένως, αποφασίσαμε να απλοποιήσουμε τον πίνακα εργαλείων, να εγκαταλείψουμε την ιεραρχία προϊόντων στον πίνακα εργαλείων και να δούμε πόσο γρήγορο θα μπορούσε να είναι σε μια απλοποιημένη έκδοση.
Έτσι, σε αυτό το τελευταίο στάδιο, συγκεντρώσαμε ένα ξεχωριστό αποθετήριο στο οποίο προσθέσαμε όλα τα KPI σε μεταφερόμενη μορφή. Από την πλευρά της βάσης δεδομένων, κάθε αίτημα για μια τέτοια αποθήκευση υποβάλλεται σε επεξεργασία σε 0,1 - 0,3 δευτερόλεπτα. Στον πίνακα ελέγχου λάβαμε τα ακόλουθα αποτελέσματα:
Πρώτο άνοιγμα: 8-10 δευτερόλεπτα
Οποιοδήποτε κλικ: 6-7 δευτερόλεπτα
Ο χρόνος που αφιερώνει το Tableau αποτελείται από:
- 0,3 δευτ. — ανάλυση πίνακα εργαλείων και συλλογή ερωτημάτων SQL
- 1,5-3 δευτερόλεπτα. — εκτέλεση ερωτημάτων SQL στο Hana για κύριες απεικονίσεις (εκτελείται παράλληλα με το βήμα 1)
- 1,5-2 δευτ. — απόδοση, επανυπολογισμός οπτικοποιήσεων
- 1,3sec. — εκτέλεση πρόσθετων ερωτημάτων SQL για τη λήψη σχετικών τιμών φίλτρου (επωνυμία, τμήμα, πόλη, κατάστημα), ανάλυση αποτελεσμάτων
Για να το συνοψίσουμε σύντομα
Μας άρεσε το εργαλείο Tableau από οπτική γωνία. Στο στάδιο του πρωτοτύπου, εξετάσαμε διάφορα στοιχεία οπτικοποίησης και τα βρήκαμε όλα σε βιβλιοθήκες, συμπεριλαμβανομένης της σύνθετης τμηματοποίησης πολλαπλών επιπέδων και του καταρράκτη πολλαπλών οδηγών.
Κατά την εφαρμογή πινάκων εργαλείων με βασικούς δείκτες πωλήσεων, αντιμετωπίσαμε δυσκολίες απόδοσης που δεν μπορέσαμε ακόμη να ξεπεράσουμε. Περάσαμε περισσότερους από δύο μήνες και λάβαμε ένα λειτουργικά ημιτελές ταμπλό, η ταχύτητα απόκρισης του οποίου είναι στα όρια της αποδεκτής. Και βγάλαμε μόνοι μας συμπεράσματα:
- Το Tableau δεν μπορεί να λειτουργήσει με μεγάλες ποσότητες δεδομένων. Εάν στο αρχικό μοντέλο δεδομένων έχετε περισσότερα από 10 GB δεδομένων (περίπου 200 εκατομμύρια X 50 σειρές), τότε ο πίνακας εργαλείων θα επιβραδυνθεί σοβαρά - από 10 δευτερόλεπτα σε αρκετά λεπτά για κάθε κλικ. Πειραματιστήκαμε τόσο με ζωντανή σύνδεση όσο και με εξαγωγή. Η ταχύτητα λειτουργίας είναι συγκρίσιμη.
- Περιορισμός κατά τη χρήση πολλαπλών αποθηκευτικών χώρων (σύνολα δεδομένων). Δεν υπάρχει τρόπος να υποδειχθεί η σχέση μεταξύ των συνόλων δεδομένων χρησιμοποιώντας τυπικά μέσα. Εάν χρησιμοποιείτε λύσεις για τη σύνδεση συνόλων δεδομένων, αυτό θα επηρεάσει σημαντικά την απόδοση. Στην περίπτωσή μας, εξετάσαμε την επιλογή να υλοποιήσουμε δεδομένα σε κάθε απαιτούμενη ενότητα προβολής και να κάνουμε διακόπτες σε αυτά τα υλοποιημένα σύνολα δεδομένων διατηρώντας τα προηγουμένως επιλεγμένα φίλτρα - αυτό αποδείχθηκε ότι ήταν αδύνατο να γίνει στο Tableau.
- Δεν είναι δυνατή η δημιουργία δυναμικών παραμέτρων στο Tableau. Δεν μπορείτε να συμπληρώσετε μια παράμετρο που χρησιμοποιείται για το φιλτράρισμα ενός συνόλου δεδομένων σε ένα απόσπασμα ή κατά τη διάρκεια μιας ζωντανής σύνδεσης με το αποτέλεσμα άλλης επιλογής από το σύνολο δεδομένων ή το αποτέλεσμα άλλου ερωτήματος SQL, μόνο με είσοδο εγγενούς χρήστη ή μια σταθερά.
- Περιορισμοί που σχετίζονται με τη δημιουργία ενός πίνακα εργαλείων με στοιχεία OLAP|PivotTable.
Στο MSTR, SAP SAC, SAP Analysis, εάν προσθέσετε ένα σύνολο δεδομένων σε μια αναφορά, τότε όλα τα αντικείμενα σε αυτό σχετίζονται μεταξύ τους από προεπιλογή. Το Tableau δεν διαθέτει αυτό, η σύνδεση πρέπει να ρυθμιστεί χειροκίνητα. Αυτό είναι πιθανώς πιο ευέλικτο, αλλά για όλους τους πίνακες εργαλείων μας αυτό είναι μια υποχρεωτική απαίτηση για στοιχεία - επομένως αυτό είναι πρόσθετο κόστος εργασίας. Επιπλέον, εάν κάνετε σχετικά φίλτρα έτσι ώστε, για παράδειγμα, όταν φιλτράρετε μια περιοχή, η λίστα των πόλεων να περιορίζεται μόνο στις πόλεις αυτής της περιοχής, καταλήγετε αμέσως με διαδοχικά ερωτήματα στη βάση δεδομένων ή στο Extract, το οποίο επιβραδύνει αισθητά το ταμπλό. - Περιορισμοί στις λειτουργίες. Οι μετασχηματισμοί μάζας δεν μπορούν να γίνουν ούτε στο εκχύλισμα ούτε, ειδικά, στο σύνολο δεδομένων από το Live-Connecta. Αυτό μπορεί να γίνει μέσω του Tableau Prep, αλλά είναι πρόσθετη εργασία και ένα άλλο εργαλείο για να μάθει και να διατηρηθεί. Για παράδειγμα, δεν μπορείτε να μεταφέρετε δεδομένα ή να το ενώσετε με τον εαυτό του. Αυτό που κλείνει μέσω μετασχηματισμών σε μεμονωμένες στήλες ή πεδία, τα οποία πρέπει να επιλεγούν μέσω πεζών-κεφαλαίων ή εάν, και αυτό δημιουργεί πολύ σύνθετα ερωτήματα SQL, στα οποία η βάση δεδομένων αφιερώνει τον περισσότερο χρόνο της για τη μεταγλώττιση του κειμένου ερωτήματος. Αυτή η ανελαστικότητα του εργαλείου έπρεπε να επιλυθεί σε επίπεδο βιτρίνας, γεγονός που οδηγεί σε πιο περίπλοκη αποθήκευση, πρόσθετες λήψεις και μετασχηματισμούς.
Δεν έχουμε εγκαταλείψει το Tableau. Ωστόσο, δεν θεωρούμε το Tableau ως εργαλείο ικανό να κατασκευάζει βιομηχανικούς πίνακες εργαλείων και ένα εργαλείο με το οποίο αντικαθιστά και ψηφιοποιεί ολόκληρο το σύστημα εταιρικών αναφορών μιας εταιρείας.
Τώρα αναπτύσσουμε ενεργά έναν παρόμοιο πίνακα εργαλείων σε ένα άλλο εργαλείο και, ταυτόχρονα, προσπαθούμε να αναθεωρήσουμε την αρχιτεκτονική του πίνακα εργαλείων στο Tableau, προκειμένου να την απλοποιήσουμε ακόμη περισσότερο. Εάν η κοινότητα ενδιαφέρεται, θα σας ενημερώσουμε για τα αποτελέσματα.
Περιμένουμε επίσης τις ιδέες ή τις συμβουλές σας για το πώς στο Tabeau μπορείτε να δημιουργήσετε γρήγορους πίνακες ελέγχου σε τόσο μεγάλους όγκους δεδομένων, επειδή έχουμε έναν ιστότοπο όπου υπάρχουν πολύ περισσότερα δεδομένα από ό,τι στο λιανικό εμπόριο.
Πηγή: www.habr.com