Τι μπορεί να πάει στραβά με την Επιστήμη των Δεδομένων; Συλλογή δεδομένων

Τι μπορεί να πάει στραβά με την Επιστήμη των Δεδομένων; Συλλογή δεδομένων
Σήμερα υπάρχουν 100500 μαθήματα Επιστήμης Δεδομένων και είναι γνωστό εδώ και καιρό ότι τα περισσότερα χρήματα στην Επιστήμη Δεδομένων μπορούν να κερδίσουν μέσω μαθημάτων Επιστήμης Δεδομένων (γιατί να σκάβεις όταν μπορείς να πουλήσεις φτυάρια;). Το κύριο μειονέκτημα αυτών των μαθημάτων είναι ότι δεν έχουν καμία σχέση με πραγματική εργασία: κανείς δεν θα σας δώσει καθαρά, επεξεργασμένα δεδομένα στην απαιτούμενη μορφή. Και όταν αφήνετε το μάθημα και ξεκινάτε να λύνετε ένα πραγματικό πρόβλημα, αναδύονται πολλές αποχρώσεις.

Ως εκ τούτου, ξεκινάμε μια σειρά σημειώσεων «Τι μπορεί να πάει στραβά με την Επιστήμη των Δεδομένων», βασισμένες σε πραγματικά γεγονότα που συνέβησαν σε εμένα, τους συντρόφους και τους συναδέλφους μου. Θα αναλύσουμε τυπικές εργασίες Επιστήμης Δεδομένων χρησιμοποιώντας πραγματικά παραδείγματα: πώς συμβαίνει αυτό στην πραγματικότητα. Ας ξεκινήσουμε σήμερα με την εργασία συλλογής δεδομένων.

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

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

Και το πιο σημαντικό, θα συζητήσουμε τι πρέπει να κάνουμε για να το αποτρέψουμε.

Σύμφωνα με διάφορες εκτιμήσεις, ο καθαρισμός, ο μετασχηματισμός, η επεξεργασία δεδομένων, η μηχανική χαρακτηριστικών κ.λπ. απαιτούν το 80-90% του χρόνου και η ανάλυση 10-20%, ενώ σχεδόν όλο το εκπαιδευτικό υλικό εστιάζει αποκλειστικά στην ανάλυση.

Ας δούμε ένα απλό αναλυτικό πρόβλημα σε τρεις εκδοχές ως χαρακτηριστικό παράδειγμα και ας δούμε τι είναι οι «επιβαρυντικές περιστάσεις».

Και ως παράδειγμα, πάλι, θα εξετάσουμε παρόμοιες παραλλαγές του έργου της συλλογής δεδομένων και της σύγκρισης κοινοτήτων για:

  1. Δύο Reddit subreddits
  2. Δύο τμήματα του Habr
  3. Δύο ομάδες Odnoklassniki

Θεωρητική προσέγγιση υπό όρους

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

Βασικό σημείο: Οι εκτιμήσεις χρόνου βασίζονται σε υποθέσεις και εικασίες σχετικά με το χρόνο που θα διαρκέσει.

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

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

Το πιο σημαντικό είναι ότι για να υπολογίσετε τον χρόνο - στην πραγματικότητα χρειάζεται να ξοδέψετε χρόνο και προσπάθεια για "αναγνωρίσεις σε ισχύ" - μόνο τότε ο προγραμματισμός σας θα είναι επαρκής. Επομένως, ανεξάρτητα από το πόσο πολύ σας πιέζουν να πείτε «πόσο χρόνο χρειάζεται για τη συλλογή δεδομένων» - αγοράστε λίγο χρόνο για μια προκαταρκτική ανάλυση και επιχειρηματολογήστε κατά πόσο θα διαφέρει ο χρόνος ανάλογα με τις πραγματικές παραμέτρους του προβλήματος.

Και τώρα θα δείξουμε συγκεκριμένα παραδείγματα όπου αυτές οι παράμετροι θα αλλάξουν.

Βασικό Σημείο: Η εκτίμηση βασίζεται σε ανάλυση βασικών παραγόντων που επηρεάζουν το εύρος και την πολυπλοκότητα της εργασίας.

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

Σύγκριση κοινοτήτων Reddit

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

  • Υπάρχει ένα τακτοποιημένο, σαφές και τεκμηριωμένο API.
  • Είναι εξαιρετικά απλό και το πιο σημαντικό, ένα διακριτικό αποκτάται αυτόματα.
  • Υπάρχει περιτύλιγμα python - με πολλά παραδείγματα.
  • Μια κοινότητα που αναλύει και συλλέγει δεδομένα στο reddit (ακόμη και σε βίντεο YouTube που εξηγούν πώς να χρησιμοποιήσετε το περιτύλιγμα python) Για παράδειγμα.
  • Οι μέθοδοι που χρειαζόμαστε πιθανότατα υπάρχουν στο API. Επιπλέον, ο κώδικας φαίνεται συμπαγής και καθαρός, παρακάτω είναι ένα παράδειγμα λειτουργίας που συλλέγει σχόλια σε μια ανάρτηση.

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

Παρμένο από αυτό μια επιλογή από βολικά βοηθητικά προγράμματα για τύλιγμα.

Παρά το γεγονός ότι αυτή είναι η καλύτερη περίπτωση, αξίζει να ληφθούν υπόψη ορισμένοι σημαντικοί παράγοντες από την πραγματική ζωή:

  • Όρια API - αναγκαζόμαστε να λαμβάνουμε δεδομένα σε παρτίδες (αναμονή μεταξύ αιτημάτων κ.λπ.).
  • Χρόνος συλλογής - για μια πλήρη ανάλυση και σύγκριση, θα πρέπει να αφιερώσετε σημαντικό χρόνο μόνο για να περπατήσει η αράχνη στο subreddit.
  • Το ρομπότ πρέπει να τρέχει σε έναν διακομιστή - δεν μπορείτε απλώς να το εκτελέσετε στον φορητό υπολογιστή σας, να το βάλετε στο σακίδιό σας και να ασχοληθείτε με την επιχείρησή σας. Έτσι, έτρεξα τα πάντα σε ένα VPS. Χρησιμοποιώντας τον κωδικό προσφοράς habrahabr10 μπορείτε να εξοικονομήσετε άλλο 10% του κόστους.
  • Η φυσική αδυναμία πρόσβασης ορισμένων δεδομένων (είναι ορατά στους διαχειριστές ή είναι πολύ δύσκολο να συλλεχθούν) - αυτό πρέπει να λαμβάνεται υπόψη· κατ' αρχήν, δεν μπορούν να συλλεχθούν όλα τα δεδομένα σε επαρκή χρόνο.
  • Σφάλματα δικτύου: Η δικτύωση είναι ένας πόνος.
  • Αυτά είναι ζωντανά δεδομένα - δεν είναι ποτέ καθαρά.

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

Σύγκριση τμημάτων Habr

Ας προχωρήσουμε σε μια πιο ενδιαφέρουσα και μη τετριμμένη περίπτωση σύγκρισης νημάτων ή/και τμημάτων του Habr.

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

  • Στην αρχή νομίζετε ότι υπάρχει API, αλλά δεν υπάρχει. Ναι, ναι, το Habr έχει ένα API, αλλά απλώς δεν είναι προσβάσιμο στους χρήστες (ή ίσως δεν λειτουργεί καθόλου).
  • Στη συνέχεια ξεκινάτε να αναλύετε το html - "αιτήματα εισαγωγής", τι μπορεί να πάει στραβά;
  • Πώς να αναλύσω τέλος πάντων; Η απλούστερη και πιο συχνά χρησιμοποιούμενη προσέγγιση είναι η επανάληψη των αναγνωριστικών, σημειώστε ότι δεν είναι η πιο αποτελεσματική και θα πρέπει να χειριστεί διαφορετικές περιπτώσεις - εδώ είναι ένα παράδειγμα της πυκνότητας των πραγματικών αναγνωριστικών μεταξύ όλων των υπαρχόντων.

    Τι μπορεί να πάει στραβά με την Επιστήμη των Δεδομένων; Συλλογή δεδομένων
    Παρμένο από αυτό άρθρα.

  • Τα ανεπεξέργαστα δεδομένα που είναι τυλιγμένα σε HTML στην κορυφή του ιστού είναι οδυνηρά. Για παράδειγμα, θέλετε να συλλέξετε και να αποθηκεύσετε τη βαθμολογία ενός άρθρου: αφαιρέσατε το σκορ από το html και αποφασίσατε να το αποθηκεύσετε ως αριθμό για περαιτέρω επεξεργασία: 

    1) το int(score) ρίχνει ένα σφάλμα: αφού στο Habré υπάρχει ένα μείον, όπως, για παράδειγμα, στη γραμμή "–5" - αυτό είναι μια παύλα en, όχι ένα σύμβολο μείον (απροσδόκητα, σωστά;), οπότε στο κάποια στιγμή έπρεπε να αναζωογονήσω τον αναλυτή με μια τόσο τρομερή λύση.

    try:
          score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
          score = int(score_txt)
          if check_date(date):
            post_score += score
    

    Μπορεί να μην υπάρχουν καθόλου ημερομηνία, συν και πλην (όπως βλέπουμε παραπάνω στη συνάρτηση check_date, αυτό συνέβη).

    2) Ειδικοί χαρακτήρες χωρίς διαφυγή - θα έρθουν, πρέπει να είστε προετοιμασμένοι.

    3) Η δομή αλλάζει ανάλογα με τον τύπο της ανάρτησης.

    4) Οι παλιές δημοσιεύσεις μπορεί να έχουν **περίεργη δομή**.

  • Ουσιαστικά, ο χειρισμός σφαλμάτων και τι μπορεί ή δεν μπορεί να συμβεί θα πρέπει να αντιμετωπιστεί και δεν μπορείτε να προβλέψετε με βεβαιότητα τι θα πάει στραβά και πώς αλλιώς μπορεί να είναι η δομή και τι θα πέσει πού - θα πρέπει απλώς να προσπαθήσετε και να λάβετε υπόψη τα λάθη που ρίχνει ο αναλυτής.
  • Στη συνέχεια, συνειδητοποιείτε ότι πρέπει να αναλύσετε σε πολλά νήματα, διαφορετικά η ανάλυση σε ένα θα διαρκέσει 30+ ώρες (αυτός είναι καθαρά ο χρόνος εκτέλεσης ενός ήδη λειτουργούντος αναλυτή μονού νήματος, ο οποίος κοιμάται και δεν εμπίπτει σε καμία απαγόρευση). ΣΕ αυτό άρθρο, αυτό οδήγησε κάποια στιγμή σε ένα παρόμοιο σχέδιο:

Τι μπορεί να πάει στραβά με την Επιστήμη των Δεδομένων; Συλλογή δεδομένων

Συνολική λίστα ελέγχου κατά πολυπλοκότητα:

  • Εργασία με το δίκτυο και ανάλυση html με επανάληψη και αναζήτηση κατά αναγνωριστικό.
  • Έγγραφα ετερογενούς δομής.
  • Υπάρχουν πολλά μέρη όπου ο κωδικός μπορεί εύκολα να πέσει.
  • Είναι απαραίτητο να γράψετε || κώδικας.
  • Λείπει η απαραίτητη τεκμηρίωση, παραδείγματα κώδικα ή/και κοινότητα.

Ο εκτιμώμενος χρόνος για αυτήν την εργασία θα είναι 3-5 φορές υψηλότερος από ό,τι για τη συλλογή δεδομένων από το Reddit.

Σύγκριση ομάδων Odnoklassniki

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

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

  • Υπάρχει ένα API, αλλά του λείπουν σχεδόν εντελώς οι απαραίτητες λειτουργίες.
  • Σε ορισμένες λειτουργίες πρέπει να ζητήσετε πρόσβαση μέσω ταχυδρομείου, δηλαδή η παραχώρηση πρόσβασης δεν είναι στιγμιαία.
  • Είναι τρομερά τεκμηριωμένο (αρχικά, οι ρωσικοί και αγγλικοί όροι αναμειγνύονται παντού και εντελώς ασυνεπείς - μερικές φορές απλά πρέπει να μαντέψετε τι θέλουν από εσάς κάπου) και, επιπλέον, ο σχεδιασμός δεν είναι κατάλληλος για τη λήψη δεδομένων, για παράδειγμα , τη λειτουργία που χρειαζόμαστε.
  • Απαιτεί μια συνεδρία στην τεκμηρίωση, αλλά δεν τη χρησιμοποιεί στην πραγματικότητα - και δεν υπάρχει τρόπος να κατανοήσετε όλες τις περιπλοκές των λειτουργιών API εκτός από το να περιηγηθείτε και να ελπίζετε ότι κάτι θα λειτουργήσει.
  • Δεν υπάρχουν παραδείγματα και καμία κοινότητα· το μόνο σημείο υποστήριξης στη συλλογή πληροφοριών είναι ένα μικρό περικάλυμμα σε Python (χωρίς πολλά παραδείγματα χρήσης).
  • Το σελήνιο φαίνεται να είναι η πιο εφαρμόσιμη επιλογή, αφού πολλά από τα απαραίτητα δεδομένα είναι κλειδωμένα.
    1) Δηλαδή η εξουσιοδότηση πραγματοποιείται μέσω εικονικού χρήστη (και η εγγραφή με το χέρι).

    2) Ωστόσο, με το Selenium δεν υπάρχουν εγγυήσεις για σωστή και επαναλαμβανόμενη εργασία (τουλάχιστον στην περίπτωση του ok.ru σίγουρα).

    3) Ο ιστότοπος Ok.ru περιέχει σφάλματα JavaScript και μερικές φορές συμπεριφέρεται παράξενα και ασυνεπή.

    4) Πρέπει να κάνετε σελιδοποίηση, φόρτωση στοιχείων κ.λπ...

    5) Τα σφάλματα API που δίνει το περιτύλιγμα θα πρέπει να αντιμετωπίζονται άβολα, για παράδειγμα, ως εξής (ένα κομμάτι πειραματικού κώδικα):

    def get_comments(args, context, discussions):
        pause = 1
        if args.extract_comments:
            all_comments = set()
    #makes sense to keep track of already processed discussions
            for discussion in tqdm(discussions): 
                try:
                    comments = get_comments_from_discussion_via_api(context, discussion)
                except odnoklassniki.api.OdnoklassnikiError as e:
                    if "NOT_FOUND" in str(e):
                        comments = set()
                    else:
                        print(e)
                        bp()
                        pass
                all_comments |= comments
                time.sleep(pause)
            return all_comments
    

    Το αγαπημένο μου λάθος ήταν:

    OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

    6) Τελικά, το Selenium + API μοιάζει με την πιο λογική επιλογή.

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

Η υπό όρους εκτίμηση χρόνου για αυτήν την εργασία θα είναι 3-5 φορές υψηλότερη από ό,τι για τη συλλογή δεδομένων από το Habr. Παρά το γεγονός ότι στην περίπτωση του Habr χρησιμοποιούμε μια μετωπική προσέγγιση με ανάλυση HTML, και στην περίπτωση του ΟΚ μπορούμε να εργαστούμε με το API σε κρίσιμα σημεία.

Ευρήματα

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

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

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

Αν ρίξετε μια ματιά στα χαρακτηριστικά της εργασίας χωρίς πρόσθετα πειράματα, τότε το Reddit και το OK μοιάζουν: υπάρχει ένα API, ένα περιτύλιγμα python, αλλά στην ουσία, η διαφορά είναι τεράστια. Κρίνοντας από αυτές τις παραμέτρους, το pars του Habr φαίνεται πιο περίπλοκο από το ΟΚ - αλλά στην πράξη είναι ακριβώς το αντίθετο, και αυτό ακριβώς μπορεί να βρεθεί με τη διεξαγωγή απλών πειραμάτων για την ανάλυση των παραμέτρων του προβλήματος.

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

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

Τι μπορεί να πάει στραβά με την Επιστήμη των Δεδομένων; Συλλογή δεδομένων

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο