Το 2024 τελείωσε και αναμφίβολα ήταν μια χρονιά ορόσημο για το AI, αλλά χωρίς δεδομένα ΑΙ δεν υπάρχει. Ενώ θα περίμενε κανείς τα δεδομένα που χρησιμοποιούνται για το ΑΙ να υπάρχουν σε ένα ενοποιημένο οικοσύστημα δεδομένων, η Gartner μέσα στο 2024 με έρευνα της έδειξε ότι οι οργανισμοί στην προσπάθεια του να υιοθετήσουν GenAI και για υλοποιήσουν αυτοματισμούς δημιούργησαν 7% περισσότερα σιλό δεδομένων σε σχέση με το 2023.

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

Από την δεκαετία του 1980 μιλάμε για την ενσωμάτωση δεδομένων σε ένα ενιαίο οικοσύστημα. Δύο ήταν (θεωρώ ότι ακόμα είναι) οι κυρίαρχες αρχιτεκτονικές, του Bill Inmon και του Ralph Kimball. Με αρκετούς οπαδούς η κάθε μία και με αρκετό μελάνι να έχει χυθεί για το ποια είναι/ήταν η καλύτερη. Αρκετοί μιλούσαν για το μεταξύ τους «πόλεμο», που όμως πραγματικά ποτέ δεν υπήρχε καθώς και οι δύο είχαν τον ίδιο στόχο που δεν ήταν άλλος από να αξιοποιήσουν τα δεδομένα που υπάρχουν στις διάφορες εφαρμογές.

O Kimball έχει αποσυρθεί, ο Inmon όμως είναι ακόμα στις επάλξεις. Σε ένα άρθρο του ο Inmon έδωσε, θεωρώ, ξεκάθαρες απαντήσεις στο «πόλεμο» Inmon Vs Kimball το οποίο μπορείτε να διαβάσετε στο LinkedIn του και έχει τίτλο KIMBALL VS INMON REDUX.

Από αυτό θα δανειστώ κάποια κομμάτια αυτολεξεί, που ο Inmon γράφει:

«The Kimball approach takes data from applications and quickly produces a data base structure – a dimensional, star schema structure. The result that Ralph described was good for analytical processing. If you want to rescue application data that is trapped and move it into a form that is suitable for analytics, the Kimball approach does exactly that. It is fast, efficient, and well defined.»

«The Inmon approach addresses the believability of data across the corporation, not the speed of building analytics. The Inmon approach says that you take data from many applications that have been designed and built in many different forms. Each application designer built their own application in their own way. The problem is that there are a lot of people in the corporation that need to see the application with a corporate wide view of the data, not an application view. You cannot achieve a corporate understanding of data when that data is scattered across many applications.»

«Kimball and Inmon were answering different questions. So, when you go to select your approach, you have to be clear about what you are asking for. If you want application data, use Kimball. If you want corporate data, use Inmon.»

Είναι ξεκάθαρο ότι και οι δύο μιλάνε για την μεταφορά των δεδομένων από τις εφαρμογές σε κάποιο ενιαίο οικοσύστημα για την πραγματική αξιοποίηση τους και είναι τόσο σύγχρονες όσο όταν διατυπώθηκαν αρχικά. Κατά την άποψη μου όλα αυτά για τα οποία μιλάμε σήμερα (Data Lakes, Data Lakehouses, Data Warehouses, Data Mesh, Real-time Data, Data Governance) αλλά και όλες οι τεχνολογίες/πλατφόρμες (Microsoft Fabric, Databricks, Snowflake κ.α.) ουσιαστικά αυτές υλοποιούν.

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

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

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

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

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

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

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

Για να γίνει όμως κάτι τέτοιο δεν φτάνει ένα Data Warehouse να έχει απλά τα δεδομένα. Θα πρέπει να έχει metadata που θα οδηγήσουν τους χρήστες να βρίσκουν τα δεδομένα ευκολότερα και να κατανοούν τι αυτά περιέχουν, να έχει data models που να λειτουργούν αφαιρετικά ώστε να μειώνουν τις δυσκολίες ανάλυσης, να υπάρχει data lineage για να βοηθάει το χρήστη στην κατανόηση της προέλευσης δεδομένων και των μετασχηματισμών που αυτά έχουν υποστεί και βρίσκονται μέσα στο Data Warehouse.

Για να γίνουν όμως αυτά πραγματικότητα έπρεπε να υπάρχουν και οι κατάλληλοι μηχανισμοί που θα μετατρέπουν τα οποιαδήποτε δεδομένα σε πραγματικά οργανικά δεδομένα. Αυτό οδήγησε στην γέννηση των ETL (Extract Transform Load), τα οποία σήμερα τα ονομάζουμε data pipelines καθώς συμπεριλαμβάνουν όλο το κύκλο από το ingestion, το data processing, το storing, και το workflow orchestration.

Με την θεμελίωση του Data Warehouse δεν άνοιξε απλά η πόρτα ανάλυσης των δεδομένων, αλλά σηματοδότησε την ανάγκη ανάλυσης των ιστορικών δεδομένων. Πλέον οι οργανισμοί είχαν την δυνατότητα να αποθηκεύσουν και να επεξεργαστούν/αναλύσουν δεδομένα τριετίας, πενταετίας, δεκαετίας κ.α. καθώς έγινε ξεκάθαρο ότι το παρελθόν είναι ο προγνωστικός παράγοντας για το μέλλον. Αυτό έφερε την αναγέννηση του Machine Learning καθώς οι οργανισμοί ενδιαφέρονταν όλο και περισσότερο για τις αγοραστικές συνήθειες των πελατών τους, τη κατανόηση αγοραστικών patterns κ.α.

Σύντομα όμως ο περιορισμός των δομημένων δεδομένων που απαιτούσε ένα Data Warehouse έγινε εμφανής. Η ραγδαία αύξηση στην ποικιλία των format των δεδομένων (text, images, videos, sound, ΙοΤ κ.α.) που παράγονταν με καταιγιστικούς ρυθμούς από πολλές και διαφορετικές πηγές (machines, web, socials, sensors, call centers κ.α) κατέδειξε αυτό.

Πλέον οι οργανισμοί ήθελαν να αναλύσουν δεδομένα που δεν ήταν δομημένα και που αρκετές φορές περιείχαν σημαντικές πληροφορίες. Αρχικά ήταν δύσκολο να επεξεργαστούμε δεδομένα που ήταν πχ σε text ή images αλλά η εξέλιξη του Machine Learning και Artificial Intelligence το έκανε δυνατό.

Παρόλα αυτά όμως έγινε άμεσα ορατό το πρόβλημα του χώρου και της διαφορετικότητας των δεδομένων. Οι ανάγκες αποθήκευσης διαφορετικών format δεδομένων ώστε να συλλεχθούν σε ένα σημείο και να αναλυθούν μεγάλωσαν. Τότε κάνει την εμφάνιση του το Data Lake το οποίο προσφέρει την συγχώνευση όλων των διαφορετικών format δεδομένων σε ένα ενιαίο χώρο για όλο τον οργανισμό.

Αυτό που ακολούθησε ήταν οι οργανισμοί να ξεφορτώνουν όλα τα δεδομένα τους σε Data Lakes που είχαν χαμηλό κόστος με νέα APIs και open source data formats (Parquet, Avro, OCR, JSON κ.α.) τα οποία ήταν άμεσα προσβάσιμα σε ένα ευρύ φάσμα χρηστών και χρήσης όπως Machine Learning.

Αρχικά το Data Lake θεωρήθηκε σαν να είχαμε βρει το άγιο δισκοπότηρο. Σύντομα όμως έγινε κατανοητό ότι τα δεδομένα που υπάρχουν στο Data Lake τα βλέπουν χρήστες που έχουν διαφορετικές ανάγκες. Άλλες ανάγκες έχει ένας τελικός χρήστης, άλλες ένας data analyst και άλλες ένας data scientist. Για παράδειγμα ο τελικός χρήστης είχε πολλά εμπόδια να υπερπηδήσει για να κάνει την δουλειά του με το Data Lake καθώς δεν ήταν εύκολο για αυτόν να βρει το σημείο που ήταν τα δεδομένα που ήθελε, το πως αυτά συσχετίζονται με άλλα δεδομένα που βρίσκονται στο Data Lake, το πόσο ενημερωμένα και ακριβή είναι αυτά.

Εκτός όμως από αυτό και παρά τις αρχικές υποσχέσεις φάνηκε ότι σε ένα Data Lake δεν είχαμε θεμελιώδεις αρχές όπως transactions, data quality constraints (πχ. Primary key), data governance και κυρίως δεν είχαμε καλό performance. Αυτά όλα οδήγησαν τις περισσότερες υλοποιήσεις σε Data Lake να θυμίζουν βάλτους (data swamps) με δεδομένα που κανείς δεν τα χρησιμοποιεί.

Δεν ήταν όμως μόνο αυτά. Στην δημιουργία των data swamps οδήγησε μια μεγάλη παρανόηση γύρω από το Data Lake που οδήγησε τους οργανισμούς ακατάστατα να μεταφέρουν τα δεδομένα τους σε αυτό με αποτέλεσμα να χάσει τα πλεονεκτήματα του (storage for diverse data, scalability, agility, real-time analytics, low cost, advanced analytics capabilities). Η παρανόηση αυτή συνοψίζεται στην φράση που όλοι μας λίγο ως πολύ έχουμε πει «όλα στο Data Lake».

Έτσι ενώ ένα Data Lake θα έπρεπε να είναι ένα «well organized and structured storage repository for vast amounts of diverse data» εξελίχθηκε σε data swamp ένα «unorganized and chaotic data storage system lacking proper structure, making data difficult to retrieve and utilize effectively». Αυτό συνέβη καθώς κανείς δεν ασχολήθηκε με την επιχειρηματική αξία, το business value που όλοι μας με στόμφο αναφέρουμε των δεδομένων που μεταφέρονται σε ένα Data Lake.

H επιχειρηματική αξία είναι άμεσα συνυφασμένη με το data classification και με αυτό το πρίσμα θα πρέπει να δούμε τα δεδομένα που θα μεταφερθούν στο Data Lake. Θα πρέπει να αξιολογήσουμε τα δεδομένα που προέρχονται από τις καθημερινές δραστηριότητες του οργανισμού (transactions) και να εκτιμήσουμε την μακροπρόθεσμη αξία τους . Επίσης το ίδιο θα πρέπει να γίνει και για τα δεδομένα που δεν είναι δομημένα.

Όλα αυτά ευτυχώς έγιναν άμεσα ορατά και αναζητήθηκαν λύσεις για να φύγουμε από τα data swamps. Από την αναζήτηση αυτή γεννήθηκε το Data Lakehouse συνδυάζοντας δομές και χαρακτηριστικά που υπάρχουν στο Data Warehouse και στο Data Lake. Μια αρχιτεκτονική που είναι ανοικτή σε διαφορετικά data formats αλλά ταυτόχρονα είναι τυποποιημένη και έχει γίνει performance optimization. Συνοπτικά η σύγκριση μεταξύ των Data Warehouse, Data Lake, Data Lakehouse.

Με όλες αυτές τις παραπάνω αρχιτεκτονικές θα περίμενε κανείς ότι δεν χρειαζόμαστε άλλες, όμως η ραγδαία εξέλιξη έφερε και άλλες στο προσκήνιο που αφορούν το data management και είναι οι Data Mesh και Data Fabric. Δύο διαφορετικές προσεγγίσεις που η κάθε μια έχει τα πλεονεκτήματα της σε συγκεκριμένα use cases.

Το Data Mesh είναι ιδιαίτερα επωφελές ειδικά για μεγάλους οργανισμούς που ασχολούνται με πολύπλοκα περιβάλλοντα δεδομένων με κυρίαρχα πλεονεκτήματα την επεκτασιμότητα εξαιτίας της distributed αρχιτεκτονικής του, την αποκεντρωμένη ιδιοκτησία δεδομένων με την ανάθεση ιδιοκτησίας δεδομένων σε συγκεκριμένους επιχειρηματικούς τομείς (domains) θεωρώντας ότι όσοι κατανοούν καλύτερα τα δεδομένα είναι υπεύθυνοι για αυτά, την αντιμετώπιση των δεδομένων ως προϊόντος με σκοπό τη παροχή αξιόπιστων δεδομένων υψηλής ποιότητας που ανταποκρίνονται στις ανάγκες όσων τα χρησιμοποιούν, τις δυνατότητες αυτοεξυπηρέτησης, επιτρέποντας στις ομάδες να έχουν πρόσβαση και να χρησιμοποιούν δεδομένα χωρίς μεγάλη εξάρτηση από το κεντρικό IT, την ευθυγράμμιση με τους επιχειρηματικούς στόχους με πρακτικές διαχείρισης δεδομένων που διευκολύνουν την εξαγωγή αξιοποιήσιμων πληροφοριών.

Το Data Fabric αν και κυρίως θεωρείται αρχιτεκτονική είναι όμως και design pattern. Πρόκειται για ένα ολοκληρωμένο framework που έχει σχεδιαστεί για τη διαχείριση και την ενσωμάτωση δεδομένων σε διάφορα περιβάλλοντα, συμπεριλαμβανομένων των on-premises, cloud και υβριδικών συστημάτων.

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

Σαν design pattern είναι technology agnostic καθώς μπορεί να υλοποιηθεί χρησιμοποιώντας διάφορες τεχνολογίες (databases, data lakes, cloud storages, ETL tools, data pipelines και πλατφόρμες για data analytics & visualization) καθιστώντας το ευέλικτο και προσαρμόσιμο, χρησιμοποιεί τεχνητή νοημοσύνη και μηχανική μάθηση για την αυτοματοποίηση εργασιών που αφορούν τη διαχείρισης δεδομένων και κάνει διαχείριση metadata καθώς διατηρεί έναν ολοκληρωμένο κατάλογο πόρων των δεδομένων.

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

Έχοντας πλέον διαθέσιμες τόσες αρχιτεκτονικές και τα data pipelines για τις υλοποιήσουμε βρεθήκαμε στην ανάγκη να ορίσουμε data design patterns για τα διάφορα use cases, και ιδιαίτερα σε αυτά που είναι κοινά και επαναλαμβανόμενα και συμβάλλουν στη διασφάλιση της συνέπειας, της αποτελεσματικότητας και της επεκτασιμότητας στην επεξεργασία και διαχείριση δεδομένων. Έτσι στη γενικότερη περιοχή του data engineering εμφανίστηκαν τα εξής data design patterns:

Batch Processing Pattern: περιλαμβάνει τη συλλογή δεδομένων κατά τη διάρκεια μιας περιόδου και την επεξεργασία τους μαζικά σε προγραμματισμένα χρονικά διαστήματα. Είναι χρήσιμο για εργασίες που δεν απαιτούν επεξεργασία σε πραγματικό χρόνο.

Stream Processing Pattern: χειρίζεται δεδομένα σε πραγματικό χρόνο καθώς ρέουν μέσω του συστήματος, εξασφαλίζοντας επεξεργασία χαμηλής καθυστέρησης. Είναι ιδανικό για εφαρμογές που χρειάζονται άμεσες πληροφορίες δεδομένων.

Lambda Architecture: συνδυάζει την batch & stream επεξεργασία για να παρέχει μια ολοκληρωμένη λύση επεξεργασίας δεδομένων. Επιτρέπει τόσο την ανάλυση δεδομένων σε πραγματικό χρόνο όσο και ιστορικά.

Kappa Architecture: παρόμοια με τη Lambda, αλλά επικεντρώνεται αποκλειστικά στην stream επεξεργασία. Είναι απλούστερο και πιο αποτελεσματικό για εφαρμογές που δεν χρειάζονται μαζική επεξεργασία.

Event-Driven Pattern: επεξεργάζεται δεδομένα με βάση events & triggers. Είναι χρήσιμο για εφαρμογές που πρέπει να ανταποκρίνονται σε συγκεκριμένες ενέργειες ή αλλαγές στα δεδομένα.

Data Lake Pattern: περιλαμβάνει την αποθήκευση μεγάλων όγκων ανεπεξέργαστων δεδομένων στην εγγενή μορφή (raw data) τους μέχρι να χρειαστούν. Παρέχει ευελιξία για διάφορους τύπους ανάλυσης δεδομένων.

Fan-Out/Fan-In Pattern: κατανέμει εργασίες επεξεργασίας δεδομένων σε πολλούς κόμβους (fan-out) και στη συνέχεια συγκεντρώνει τα αποτελέσματα (fan-in). Είναι χρήσιμο για παράλληλη επεξεργασία και βελτίωση της απόδοσης.

Συγκεντρωτικά στο πίνακα που ακολουθεί οι διαφορές μεταξύ των παραπάνω design patterns.

Όμως δεν σταμάτησε η εξέλιξη σε αυτά τα design patters καθώς με την εξέλιξη του data engineering και την άνοδο των Data Lakehouse ακόμα ένα design pattern έκανε την εμφάνιση του και ονομάστηκε Medallion Architecture. Στοχεύει στη σταδιακή και προοδευτική βελτίωση της δομής και της ποιότητας των δεδομένων καθώς ρέουν μέσα από διαφορετικά επίπεδα της αρχιτεκτονικής. Αυτά τα στρώματα αναφέρονται συνήθως ως Bronze, Silver και Gold.

Το Bronze Layer είναι το raw data layer όπου τα δεδομένα απορροφώνται από διάφορες πηγές. Τα δεδομένα αποθηκεύονται στην αρχική τους μορφή χωρίς μετασχηματισμούς. Αυτό το επίπεδο χρησιμεύει ως βάση για κάθε μεταγενέστερη επεξεργασία και ανάλυση.

Στο Silver Layer, τα raw data του Bronze καθαρίζονται, επικυρώνονται και μετασχηματίζονται. Ο στόχος στο layer αυτό είναι η δημιουργία ενός πιο εκλεπτυσμένου συνόλου δεδομένων που είναι έτοιμο για περαιτέρω ανάλυση. Αυτό το επίπεδο συχνά περιλαμβάνει κατάργηση διπλότυπων δεδομένων, φιλτράρισμα και ένωση δεδομένων από διαφορετικές πηγές.

Το Gold Layer περιέχει τα πιο εκλεπτυσμένα και συγκεντρωτικά δεδομένα. Είναι βελτιστοποιημένο για επιχειρηματική ευφυΐα και αναλυτικά στοιχεία. Αυτό το επίπεδο συνήθως περιλαμβάνει σύνθετους μετασχηματισμούς και συγκεντρώσεις για τη δημιουργία συνόλων δεδομένων που είναι έτοιμα για reporting & machine learning.

Τελευταία έχει κάνει την εμφάνιση του ακόμα ένα layer στην Medallion αρχιτεκτονική το Platinum Layer, μια προτεινόμενη επέκταση πέρα από τα παραδοσιακά Bronze, Silver, Gold. Στόχος του είναι να παρέχει ένα επιπλέον στάδιο βελτίωσης και συγκέντρωσης δεδομένων, καθιστώντας το ακόμα πιο κατάλληλο για προηγμένες αναλύσεις και επιχειρηματική ευφυΐα, αξιοποιώντας συχνά προηγμένα εργαλεία όπως το Microsoft Fabric και το OneLake, τα οποία μπορούν να βελτιώσουν την απόδοση και να παρέχουν πρόσθετες δυνατότητες για τη διαχείριση δεδομένων. Ενώ το Platinum Layer μπορεί να προσφέρει οφέλη, είναι σημαντικό να τα σταθμίσετε καθώς η προσθήκη του μπορεί να εισαγάγει πολυπλοκότητα, να αυξήσει το κόστος αποθήκευσης και να δημιουργήσει σιλό δεδομένων.

Στις μέρες μας το data engineering είναι αρκετά σημαντικό και ένας οργανισμός για την υλοποίηση του ενιαίου οικοσυστήματος δεδομένων θα πρέπει να καταλάβει ότι υπάρχει learning curve. Αυτό σημαίνει ότι πρέπει να επενδύσει στην εκπαίδευση των στελεχών του ή να βρει συνεργάτες που κατέχουν αυτό καλά πριν την έναρξη της υλοποίησης. Το «θα μάθουμε στην πράξη» δεν ισχύει καθώς «η εμπειρία πρώτα σε εξετάζει και μετά σε μαθαίνει». Καλύτερα να μάθεις πρώτα καλά τι κάνει η κάθε τεχνολογία και αρχιτεκτονική, να κατανοήσεις πως θα την μετατρέψεις σε εργαλείο για την κάλυψη των αναγκών σου, παρά να αρχίζεις να υλοποιείς με βάση την εμπειρία σου και μετά να ανακαλύψεις ότι αυτό δεν είναι σωστό.

Το 2025 θα βρει κάποιους οργανισμούς να είναι σε κάποια φάση υλοποίησης, κάποιους άλλους σε φάση αναζήτησης και κάποιους άλλους χωρίς να το έχουν ακόμα σκεφτεί. Γιατί όμως;

Αυτό που φοβίζει περισσότερο τους οργανισμούς είναι η ποικιλία των διαθέσιμων επιλογών και φυσικά το learning curve. Οι περισσότεροι συχνά με ρωτάνε να τους πω ποια είναι η καλύτερη σε ποια να επενδύσουν. Προσωπικά έχω επενδύσει σε δύο, το Microsoft Fabric και το Databricks καθώς έχουν πολλά κοινά στοιχεία μεταξύ τους και μέχρι τώρα φαίνεται ότι καλώς επένδυσα σε αυτές.

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