Μοντέλα και πλατφόρμες AI

Έρικ Γκφέσερ, Αρχιτεκτονικός Σύμβουλος για την Πρακτική Δεδομένων της SPR – Σειρά Συνεντεύξεων

mm
Προσθέστε το Unite.AI στις προτιμώμενες πηγές σας στο Google

Ο Έρικ εντάχθηκε στην πρακτική δεδομένων της SPR ως Αρχιτεκτονικός Σύμβουλος το 2018.

Ο Έρικ ειδικεύτηκε στα δεδομένα, την ανοικτή ανάπτυξη με τη χρήση της Java και την πρακτική αρχιτεκτονική επιχειρήσεων, συμπεριλαμβανομένης της κατασκευής PoC, προτύπων και MVP.

Τι σας έκανε να ενδιαφερθείτε αρχικά για το machine learning;

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

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

Ενδιαφέρον είναι ότι το ενδιαφέρον μου για το machine learning έχει κάνει τον κύκλο του, поскольку ο μεταπτυχιακός μου σύμβουλος με προειδοποίησε να μην ειδικευτώ σε αυτό που τότε ονομάζονταν τεχνητή νοημοσύνη, λόγω του χειμώνα της ΤΝ. Αποφάσισα να χρησιμοποιήσω όρους όπως ML επειδή αυτά έχουν λιγότερες συνδηλώσεις και επειδή ακόμη και η AWS αναγνωρίζει ότι η υπηρεσία AI είναι στην πραγματικότητα μια υψηλότερη αφαίρεση που κατασκευάζεται πάνω από την υπηρεσία ML. Ενώ κάποιο από το hype του ML εκεί έξω είναι αρεστό, παρέχει ισχυρές ικανότητες από την πλευρά των dévelopτερ, υπό τον όρο ότι αυτοί οι ίδιοι αναγνώστές αναγνωρίζουν το γεγονός ότι η αξία που παρέχει το ML είναι μόνο τόσο καλή όσο τα δεδομένα που επεξεργάζονται από αυτό.

 

Είστε ένας μεγάλος υποστηρικτής του ανοικτού κώδικα, θα μπορούσατε να συζητήσετε γιατί ο ανοικτός κώδικας είναι τόσο σημαντικός;

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

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

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

Η πρώτη μου εμπειρία με ανοικτό κώδικα έλαβε χώρα ενώ κατασκεύαζα το προϊόν υγείας που ανέφερα νωρίτερα, χρησιμοποιώντας εργαλεία όπως το Apache Ant, που χρησιμοποιείται για την κατασκευή λογισμικού, και ένα πρώιμο προϊόν DevOps που ονομάζεται Hudson (η βάση κώδικα της οποίας αργότερα έγινε Jenkins). Ο πρωταρχικός λόγος πίσω από τις αποφάσεις μας να χρησιμοποιήσουμε αυτά τα ανοικτά προϊόντα ήταν ότι αυτά παρείχαν καλύτερες λύσεις από τις εμπορικές εναλλακτικές, ή ήταν καινοτόμες λύσεις που δεν προσφέρονταν από εμπορικές οντότητες, όχι αναφέροντας ότι η εμπορική αδειοδότηση κάποιων από τα προϊόντα που χρησιμοποιούσαμε ήταν υπερβολικά περιοριστική, οδηγώντας σε υπερβολικό κόκκινο χάλι όταν ήρθε η ώρα να χρειαζόμασταν περισσότερες άδειες, λόγω του κόστους που εμπλεκόταν.

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

 

Έχετε χρησιμοποιήσει ανοικτό κώδικα για την κατασκευή PoC, προτύπων και MVP. Θα μπορούσατε να μοιραστείτε το ταξίδι σας πίσω από κάποια από αυτά τα προϊόντα;

Όπως εξήγησα σε ένα από τα καθοδηγητικά принципια που παρουσίασα σε έναν πρόσφατο πελάτη, οι κατασκευές για την πλατφόρμα δεδομένων που κατασκεύασα για αυτούς θα πρέπει να συνεχιστούν με τη διαδικασία της επανειλημμένης κατασκευής όποτε χρειάζεται με τον καιρό. Τα στοιχεία που κατασκευάστηκαν για αυτήν την πλατφόρμα δεν θα πρέπει να αναμενθούν να παραμείνουν στατικά, καθώς οι ανάγκες αλλάζουν και νέα στοιχεία και χαρακτηριστικά της πλατφόρμας θα είναι διαθέσιμα με τον καιρό.

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

Το MVP που κατασκεύασα για αυτό το προϊόν χρειαζόταν να κατασκευαστεί με τέτοιο τρόπο, ώστε να μπορούν να κατασκευαστούν πρόσθετοι τρόποι χρήσης πάνω του, ακόμη και αν ήρθε με την υλοποίηση ενός seul τρόπου χρήσης, για ανίχνευση ανωμαλιών εξόδων. Σε αντίθεση με αυτόν τον πελάτη, ένα προϊόν που κατασκεύασα νωρίτερα είχε κάποια ιστορία πριν από την άφιξή μου. Σε αυτήν την περίπτωση, οι μετόχοι είχαν συζητήσει για τρία χρόνια (!) πώς θα προσεγγίσουν το προϊόν που ήθελαν να κατασκευάσουν. Ένας εκτελεστής του πελάτη εξήγησε ότι ένας από τους λόγους που με έφερε ήταν να βοηθήσει την εταιρεία να ξεπεράσει κάποιες από τις εσωτερικές συζητήσεις, ιδιαίτερα επειδή το προϊόν που ήθελε να κατασκευάσει χρειαζόταν να ικανοποιήσει την ιεραρχία των οργανισμών που εμπλέκονταν.

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

Νωρίτερα στην καριέρα μου, κατέληξα στο συμπέρασμα ότι μια αρχιτεκτονική ποιότητα που ονομάζεται “χρηστικότητα” δεν ήταν περιορισμένη μόνο στους τελικούς χρήστες, αλλά και στους dévelopτερ themselves. Ο λόγος γι’ αυτό είναι ότι ο κώδικας που γράφεται πρέπει να είναι χρήσιμος, όπως και οι διεπαφές χρήστη πρέπει να είναι χρήσιμες από τους τελικούς χρήστες. Για να γίνει ένα προϊόν χρήσιμο, πρέπει να κατασκευαστούν αποδείξεις έννοιας για να αποδείξουν ότι οι dévelopτερ θα είναι σε θέση να κάνουν αυτό που θέλουν, ιδιαίτερα όταν σχετίζεται με τις συγκεκριμένες τεχνολογικές επιλογές που κάνουν. Αλλά οι αποδείξεις έννοιας είναι μόνο η αρχή, καθώς τα προϊόντα είναι καλύτερα όταν εξελίσσονται με τον καιρό. Κατά τη γνώμη μου, η βάση για ένα MVP, ωστόσο, θα πρέπει να κατασκευαστεί σε προτύπα που παρουσιάζουν κάποια σταθερότητα, ώστε οι dévelopτερ να είναι σε θέση να συνεχίσουν να το εξελίσσουν.

 

Κατά τη διάρκεια της αναθεώρησης του βιβλίου ‘Machine Learning at Enterprise Scale’ ανέφερε ότι ‘η χρήση ανοικτών προϊόντων, πλαισίων και γλωσσών μαζί με μια ευέλικτη αρχιτεκτονική που αποτελείται από μείγμα ανοικτών και εμπορικών στοιχείων παρέχει την ευελιξία που πολλές εταιρείες χρειάζονται αλλά δεν αντιλαμβάνονται αμέσως στην αρχή’. Θα μπορούσατε να εξηγήσετε γιατί πιστεύετε ότι οι εταιρείες που χρησιμοποιούν ανοικτό κώδικα είναι πιο ευέλικτες;

Πολλά εμπορικά προϊόντα δεδομένων χρησιμοποιούν κρίσιμα ανοικτά στοιχεία κάτω από την επιφάνεια και επιτρέπουν στους dévelopτερ να χρησιμοποιούν δημοφιλείς γλωσσές προγραμματισμού όπως η Python. Οι εταιρείες που κατασκευάζουν αυτά τα προϊόντα γνωρίζουν ότι τα ανοικτά στοιχεία που έχουν επιλέξει να ενσωματώσουν τους δίνουν ένα άλμα στην αρχή όταν αυτά είναι ήδη ευρέως χρησιμοποιημένα από την κοινότητα.

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

Επιπλέον, η τεκμηρίωση για τέτοιου είδους στοιχεία δεν είναι σε μεγάλο βαθμό διαθέσιμη δημόσια, οδηγώντας σε συνεχείς εξαρτήσεις των dévelopτερ από αυτές τις εταιρείες. Όταν ανοικτά στοιχεία με ισχυρές κοινότητες όπως το Apache Spark είναι το κεντρικό σημείο, όπως με προϊόντα όπως η Databricks Unified Analytics Platform, πολλά από αυτά τα στοιχεία είναι ήδη διαθέσιμα στην κοινότητα, ελαχιστοποιώντας τα τμήματα στα οποία οι ομάδες ανάπτυξης χρειάζονται να εξαρτώνται από εμπορικές οντότητες για να κάνουν τη δουλειά τους.

Επιπλέον, επειδή στοιχεία όπως το Apache Spark είναι ευρέως αποδεκτά ως de facto βιομηχανικά πρότυπα, ο κώδικας μπορεί επίσης να μεταφερθεί πιο εύκολα μεταξύ εμπορικών υλοποιήσεων τέτοιων προϊόντων. Οι εταιρείες θα είναι πάντα προτιμότερες να ενσωματώσουν αυτά που θεωρούν конкурεντικές διαφορές, αλλά πολλοί dévelopτερ δεν θέλουν να χρησιμοποιήσουν προϊόντα που είναι完全 νέα επειδή αυτό αποδεικνύεται προκλητικό να μετακινηθούν μεταξύ εταιρειών και να κόψουν τις ισχυρές κοινότητες που έχουν έρθει να περιμένουν.

Από προσωπική εμπειρία, έχω εργαστεί με τέτοιου είδους προϊόντα στο παρελθόν και μπορεί να είναι προκλητικό να λάβω την κατάλληλη υποστήριξη. Και αυτό είναι ειρωνικό, δεδομένου ότι τέτοιες εταιρείες πουλάνε τα προϊόντα τους με την προσδοκία ότι θα παρέχουν υποστήριξη σε εύθετο χρόνο. Έχω την εμπειρία να υποβάλω μια αίτηση pull σε ένα ανοικτό проект, με την επιδιόρθωση να ενσωματώνεται στην κατασκευή την ίδια μέρα, αλλά δεν μπορώ να πω το ίδιο για κανένα εμπορικό έργο με το οποίο έχω εργαστεί.

 

Κάτι άλλο που πιστεύετε για ανοικτό κώδικα είναι ότι οδηγεί σε ‘πρόσβαση σε ισχυρές κοινότητες dévelopτερ’. Πόσο μεγάλες είναι κάποιες από αυτές τις κοινότητες και τι τις κάνει τόσο αποτελεσματικές;

Οι κοινότητες dévelopτερ γύρω από ένα δεδομένο ανοικτό προϊόν μπορούν να φτάσουν τις εκατοντάδες χιλιάδες. Οι ταχύτητες υιοθέτησης δεν δείχνουν απαραίτητα την ισχύ της κοινότητας, αλλά είναι ένας καλός δείκτης ότι αυτό είναι το caso. Θεωρώ τις κοινότητες ισχυρές όταν παράγουν υγιή συζήτηση και αποτελεσματική τεκμηρίωση και όταν ενεργός ανάπτυξη λαμβάνει χώρα.

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

 

Έχετε αναθεωρήσει εκατοντάδες βιβλία στο site σας, υπάρχουν τρία που θα μπορούσατε να συστήσετε στους αναγνώστες μας;

Αυτοί οι giorni διαβάζω πολύ λίγα βιβλία προγραμματισμού και ενώ υπάρχουν εξαιρέσεις, η πραγματικότητα είναι ότι αυτά είναι συνήθως ξεπερασμένα πολύ γρήγορα και η κοινότητα dévelopτερ συνήθως παρέχει καλύτερες εναλλακτικές μέσω φόρουμ συζήτησης και τεκμηρίωσης. Πολλά από τα βιβλία που διαβάζω τώρα είναι διαθέσιμα δωρεάν για μένα, είτε μέσω τεχνολογικών ενημερωτικών δελτίων στα οποία συνδρομή, είτε από συγγραφείς και δημοσιογράφους που με επικοινωνούν, είτε από αυτά που η Amazon (AMZN ) με στέλνει. Για παράδειγμα, η Amazon με έστειλε ένα αντίγραφο του “The Lean Startup” για αναθεώρηση το 2011, εισαγωγώντας με στην έννοια του MVP και πρόσφατα με έστειλε ένα αντίγραφο του “Julia for Beginners”.

(1) Ένα βιβλίο από την O’Reilly που έχω συστήσει είναι “In Search of Database Nirvana”. Ο συγγραφέας καλύπτει λεπτομερώς τις προκλήσεις για einen κινητήρα ερωτήματος βάσης δεδομένων για να υποστηρίξει φορτία που καλύπτουν το φάσμα της OLTP από τη μια πλευρά, στα ανάλυση από την άλλη πλευρά, με λειτουργικές και επιχειρηματικές πληροφορίες εργασιών στο μέσο. Αυτό το βιβλίο μπορεί να χρησιμοποιηθεί ως οδηγός για να αξιολογήσει einen κινητήρα βάσης δεδομένων ή συνδυασμό ερωτήματος και αποθήκευσης, προσανατολισμένο να ικανοποιήσει τις απαιτήσεις του φορτίου εργασίας, είτε αυτές είναι συναλλακτικές, αναλυτικές ή ένα μείγμα αυτών των δύο. Επιπλέον, η κάλυψη του συγγραφέα του “swinging database pendulum” τα τελευταία χρόνια είναι ιδιαίτερα καλή.

(2) Ενώ πολλά έχουν αλλάξει στο χώρο των δεδομένων τα τελευταία χρόνια, από τότε που νέα προϊόντα ανάλυσης δεδομένων εισάγονται, το “Disruptive Analytics” παρουσιάζει μια προσιτή, σύντομη ιστορία των τελευταίων 50 ετών καινοτομίας στην ανάλυση που δεν έχω δει αλλού και συζητά δύο τύπους διακοπής: διακοπή καινοτομίας εντός της αλυσίδας αξίας ανάλυσης και βιομηχανική διακοπή από καινοτομίες στην ανάλυση. Από την πλευρά των startups και των praktikων ανάλυσης, η επιτυχία είναι δυνατή με την διακοπή των βιομηχανιών τους, επειδή η χρήση ανάλυσης για να διαφοροποιήσει ένα προϊόν είναι ένας τρόπος για να δημιουργήσει ένα διαruptive επιχειρηματικό μοντέλο ή να δημιουργήσει νέες αγορές. Από την πλευρά της επένδυσης σε τεχνολογία ανάλυσης για τις οργανώσεις τους, μια стратегία “περίμενε και δες” μπορεί να έχει νόημα επειδή οι τεχνολογίες που κινδυνεύουν από διακοπή είναι ριψοκίνδυνες επενδύσεις λόγω της συντομίας της χρήσιμης διάρκειας.

(3) Ένα από τα καλύτερα τεχνολογικά επιχειρηματικά κείμενα που έχω διαβάσει είναι “The Limits of Strategy”, από einen συνιδρυτή της Research Board (κτημένη από την Gartner), einem διεθνούς think tank που ερευνά τις εξελίξεις στον κόσμο της υπολογιστικής και πώς οι εταιρείες πρέπει να προσαρμοστούν. Ο συγγραφέας παρουσιάζει πολύ λεπτομερείς σημειώσεις από πολλές από τις συζητήσεις του με επιχειρηματίες, παρέχοντας ε sâuστό анализ σε όλη τη διάρκεια για τις εμπειρίες του στη δημιουργία (με τη σύζυγό του) μιας ομάδας πελατών, μεγάλων εταιρειών που χρειάζονταν να συνδυάσουν τις στρατηγικές τους με τον εκρηκτικό κόσμο της υπολογιστικής. Όπως σχολίασα στην αναθεώρησή μου, αυτό που διακρίνει αυτό το βιβλίο από άλλα σχετικά είναι δύο φαινομενικά αντίθετα χαρακτηριστικά: βιομηχανικό πλάτος και οικειότητα που είναι διαθέσιμη μόνο μέσω προσωπικής αλληλεπίδρασης.

 

Είστε ο Αρχιτεκτονικός Σύμβουλος για την πρακτική δεδομένων της SPR. Θα μπορούσατε να περιγράψετε τι κάνει η SPR;

Η SPR είναι μια ψηφιακή εταιρεία συμβούλων τεχνολογίας με έδρα την περιοχή του Σικάγου, που παρέχει τεχνολογικά έργα για eine σειρά από πελάτες, από εταιρείες Fortune 1000 έως τοπικές startups. Κατασκευάζουμε ολοκληρωμένες ψηφιακές εμπειρίες χρησιμοποιώντας eine σειρά από τεχνολογικές ικανότητες, από την προσαρμοσμένη ανάπτυξη λογισμικού, την εμπειρία χρήστη, τα δεδομένα και την υποδομή cloud, μέχρι την προπόνηση DevOps, το τεστ λογισμικού και τη διαχείριση έργων.

 

Τι είναι κάποιες από τις ευθύνες σας με την SPR;

Ως αρχιτεκτονικός σύμβουλος, η κύρια ευθύνη μου είναι να οδηγήσω την παράδοση λύσεων για τους πελάτες, ηγεσία αρχιτεκτονικής και ανάπτυξης για έργα και αυτό συχνά σημαίνει να φοράω άλλα καπέλα όπως product owner επειδή η ικανότητα να συναγωνιστεί πώς τα προϊόντα κατασκευάζονται από μια πρακτική πλευρά ζυγίζει πολύ σε σχέση με το πώς η δουλειά πρέπει να προτεραιότητα, ιδιαίτερα όταν κατασκευάζουμε από το μηδέν. Συχνά συμμετέχω σε συζητήσεις με πελάτες όταν η εμπειρία μου χρειάζεται και η εταιρεία μου ζήτησε πρόσφατα να ξεκινήσω μια συνεχιζόμενη σειρά συνεδριών με fellow αρχιτεκτονικούς στην πρακτική δεδομένων για να συζητήσω έργα πελάτων, πλάγια έργα και τι οι συνάδελφοί μου κάνουν για να μείνουν στην κορυφή της τεχνολογίας, παρόμοια με αυτό που είχα τρέξει για μια προηγούμενη εταιρεία συμβούλων, αν και τα εσωτερικά meetups για αυτήν την άλλη εταιρεία περιελάμβαναν όλη την τεχνολογική πρακτική, όχι συγκεκριμένα για δεδομένα.

Για το μεγαλύτερο μέρος της καριέρας μου, έχω ειδικευτεί στην ανοικτή ανάπτυξη με τη χρήση της Java, εκτελώντας μια αυξανόμενη ποσότητα εργασίας δεδομένων κατά τη διάρκεια.除了 αυτά τα δύο ειδικεύματα, έχω επίσης κάνει αυτό που οι συνάδελφοί μου και εγώ έχουμε έρθει να ονομάζουμε “πρακτική” ή “πραγματική” αρχιτεκτονική επιχειρήσεων, που σημαίνει την εκτέλεση αρχιτεκτονικών εργασιών στο контέκστ του τι θα κατασκευαστεί και στην πραγματικότητα κατασκευάζοντας το, αντί να μιλάμε γι’ αυτό ή να ζωγραφίζουμε διαγράμματα γι’ αυτό, συνειδητοποιώντας φυσικά ότι αυτά τα άλλα έργα είναι επίσης σημαντικά.

Κατά τη γνώμη μου, αυτά τα τρία ειδικεύματα перекrývουν μεταξύ τους και δεν είναι αμοιβαία αποκλειστικά. Έχω εξηγήσει σε εκτελεστίους τα τελευταία χρόνια ότι η γραμμή που είχε τραβηχτεί παραδοσιακά από την τεχνολογική βιομηχανία μεταξύ ανάπτυξης λογισμικού και εργασίας δεδομένων δεν είναι πλέον καλά καθορισμένη, частично επειδή το εργαλείο μεταξύ αυτών των δύο χώρων έχει συγκλίνει και частично επειδή, ως αποτέλεσμα αυτής της σύγκλισης, η εργασία δεδομένων herself έχει σε μεγάλο βαθμό γίνει μια προσπάθεια ανάπτυξης λογισμικού. Ωστόσο,既然 παραδοσιακοί praktikοι δεδομένων συνήθως δεν έχουν背景 ανάπτυξης λογισμικού και vice versa, βοηθώ να καλύψω αυτό το χάσμα.

 

Τι είναι ένα ενδιαφέρον έργο που εργάζεστε τώρα με την SPR;

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

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

 

Υπάρχει κάτι άλλο που θα θέλατε να μοιραστείτε για ανοικτό κώδικα, SPR ή άλλο έργο που εργάζεστε;

Ένα άλλο έργο (διαβάστε γι’ αυτό εδώ και εδώ) που οδηγούσα πρόσφατα αφορούσε την επιτυχή υλοποίηση της Databricks Unified Analytics Platform και τη μετεγκατάσταση της εκτέλεσης μοντέλων machine learning σε αυτή από Azure HDInsight, μια διανομή Hadoop, για τον διευθυντή της ομάδας δεδομένων μιας μεγάλης ασφαλιστικής εταιρείας.

Όλα αυτά τα μετεγκαταστημένα μοντέλα προορίζονταν να προβλέψουν το επίπεδο κατανάλωσης που μπορεί να αναμενθεί για διάφορα ασφαλιστικά προϊόντα, με κάποια από αυτά να έχουν μετεγκατασταθεί από SAS πριν από quelques χρόνια, όταν η εταιρεία μετέβαλε την उपयोग της HDInsight. Η μεγαλύτερη πρόκληση ήταν η κακή ποιότητα δεδομένων, αλλά άλλες προκλήσεις περιελάμβαναν την έλλειψη ολοκληρωμένης έκδοσης, φυλή και ελλιπής τεκμηρίωση και ακαδημαϊκή τεκμηρίωση και υποστήριξη σε σχέση με τη χρήση R την εποχή εκείνη (η υλοποίηση Azure της Databricks είχε μόλις κυκλοφορήσει quelques μήνες πριν από αυτό το έργο).

Για να αντιμετωπίσω αυτές τις κρίσιμες προκλήσεις, ως Nachfolge unserer Implementierungsarbeit, έκανα συστάσεις γύρω από αυτοματοποίηση, ρύθμιση και έκδοση, διαχωρισμό ανησυχιών δεδομένων, τεκμηρίωση και απαραίτητη ευθυγράμμιση μεταξύ των ομάδων δεδομένων, πλατφόρμας και μοντέλων. Η δουλειά μας πείστησε έναν αρχικά πολύ σκεπτικό Chief Data Scientist ότι η Databricks είναι ο δρόμος προς τα εμπρός, με τον στόχο μετά την αναχώρησή μας να μετεγκαταστήσει τα υπόλοιπα μοντέλα τους στη Databricks όσο το δυνατόν γρηγορότερα.

Αυτή ήταν μια fascinující συνέντευξη που άγγιξε πολλά θέματα, νιώθω ότι έχω μάθει πολλά για ανοικτό κώδικα. Οι αναγνώστες που μπορεί να θέλουν να μάθουν περισσότερα μπορεί να επισκεφθούν τον ιστότοπο της SPR ή τον ιστότοπο του Erik Gfesser.

Ο Antoine είναι ένας οραματιστής ηγέτης και συνιδρυτής της Unite.AI, οδηγείται από μια αμετάβλητη страсть για το σχήμα και την προώθηση του μέλλοντος της τεχνητής νοημοσύνης και της ρομποτικής. Ένας σειριακός επιχειρηματίας, πιστεύει ότι η τεχνητή νοημοσύνη θα είναι τόσο διαταρακτική για την κοινωνία όσο και η ηλεκτρική ενέργεια, και συχνά πιάνεται να μιλάει για το δυναμικό των διαταρακτικών τεχνολογιών και της AGI.

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