يوجد اليوم 100500 دورة تدريبية في علوم البيانات، ومن المعروف منذ فترة طويلة أن معظم الأموال في علوم البيانات يمكن كسبها من خلال دورات علوم البيانات (لماذا تحفر بينما يمكنك بيع المجارف؟). العيب الرئيسي لهذه الدورات هو أنها لا علاقة لها بالعمل الحقيقي: لن يمنحك أحد بيانات نظيفة ومعالجتها بالتنسيق المطلوب. وعندما تترك الدورة وتبدأ في حل مشكلة حقيقية، تظهر العديد من الفروق الدقيقة.
لذلك، نبدأ سلسلة من الملاحظات "ما الأخطاء التي يمكن أن تحدث في علم البيانات"، بناءً على أحداث حقيقية حدثت لي ولرفاقي وزملائي. سنقوم بتحليل مهام علم البيانات النموذجية باستخدام أمثلة حقيقية: كيف يحدث هذا بالفعل. لنبدأ اليوم بمهمة جمع البيانات.
وأول شيء يتعثر فيه الناس عندما يبدأون العمل مع البيانات الحقيقية هو في الواقع جمع هذه البيانات الأكثر أهمية بالنسبة لنا. الرسالة الرئيسية لهذا المقال:
نحن نقلل بشكل منهجي من الوقت والموارد والجهد اللازم لجمع البيانات وتنظيفها وإعدادها.
والأهم من ذلك أننا سنناقش ما يجب فعله لمنع ذلك.
وفقًا لتقديرات مختلفة، يستغرق التنظيف والتحويل ومعالجة البيانات وهندسة الميزات وما إلى ذلك 80-90% من الوقت، والتحليل 10-20%، في حين تركز جميع المواد التعليمية تقريبًا بشكل حصري على التحليل.
دعونا ننظر إلى مشكلة تحليلية بسيطة في ثلاثة إصدارات كمثال نموذجي ونرى ما هي "الظروف المشددة".
وكمثال، مرة أخرى، سننظر في اختلافات مماثلة لمهمة جمع البيانات ومقارنة المجتمعات من أجل:
- اثنين من subreddit ريديت
- قسمين من الهبر
- مجموعتان من Odnoklassniki
النهج الشرطي من الناحية النظرية
افتح الموقع واقرأ الأمثلة، إذا كانت واضحة، خصص بضع ساعات للقراءة، وبضع ساعات للكود باستخدام الأمثلة وتصحيح الأخطاء. أضف بضع ساعات للتجميع. قم برمي بضع ساعات في الاحتياطي (اضربها في اثنين وأضف N ساعة).
النقطة الأساسية: تعتمد تقديرات الوقت على الافتراضات والتخمينات حول المدة التي سيستغرقها الأمر.
من الضروري أن يبدأ تحليل الوقت من خلال تقدير المعلمات التالية للمشكلة الشرطية الموضحة أعلاه:
- ما هو حجم البيانات وكم منها يجب جمعه فعليًا (*انظر أدناه*).
- ما هو وقت جمع سجل واحد وكم من الوقت يجب عليك الانتظار قبل أن تتمكن من جمع السجل الثاني؟
- فكر في كتابة تعليمات برمجية تحفظ الحالة وتبدأ عملية إعادة التشغيل عندما (وليس إذا) فشل كل شيء.
- اكتشف ما إذا كنا بحاجة إلى إذن وحدد الوقت للحصول على الوصول عبر واجهة برمجة التطبيقات.
- قم بتعيين عدد الأخطاء كدالة لتعقيد البيانات - قم بتقييم مهمة محددة: البنية، وعدد التحويلات، وماذا وكيفية استخراجها.
- إصلاح أخطاء الشبكة ومشاكل سلوك المشروع غير القياسي.
- قم بتقييم ما إذا كانت الوظائف المطلوبة موجودة في الوثائق، وإذا لم تكن كذلك، فكيف ومقدار ما هو مطلوب للحل البديل.
الشيء الأكثر أهمية هو أنه من أجل تقدير الوقت - فأنت تحتاج فعليًا إلى قضاء الوقت والجهد في "الاستطلاع الساري" - عندها فقط سيكون تخطيطك كافيًا. لذلك، بغض النظر عن مدى دفعك للقول "كم من الوقت يستغرق جمع البيانات" - امنح نفسك بعض الوقت لإجراء تحليل أولي وناقش مقدار الوقت الذي سيختلف اعتمادًا على المعلمات الحقيقية للمهمة.
والآن سنعرض أمثلة محددة حيث ستتغير هذه المعلمات.
النقطة الأساسية: يعتمد التقدير على تحليل العوامل الرئيسية التي تؤثر على نطاق العمل وتعقيده.
يعد التقدير المبني على التخمين أسلوبًا جيدًا عندما تكون العناصر الوظيفية صغيرة بدرجة كافية ولا توجد عوامل كثيرة يمكن أن تؤثر بشكل كبير على تصميم المشكلة. ولكن في حالة وجود عدد من مشاكل علم البيانات، تصبح هذه العوامل عديدة للغاية ويصبح هذا النهج غير مناسب.
مقارنة بين المجتمعات رديت
لنبدأ بأبسط حالة (كما سيتضح لاحقًا). بشكل عام، لنكون صادقين تمامًا، لدينا حالة مثالية تقريبًا، دعنا نتحقق من قائمة التحقق من التعقيد لدينا:
- هناك واجهة برمجة تطبيقات أنيقة وواضحة وموثقة.
- إنه أمر بسيط للغاية والأهم من ذلك أنه يتم الحصول على الرمز المميز تلقائيًا.
- هنالك - مع الكثير من الأمثلة.
- مجتمع يقوم بتحليل وجمع البيانات على موقع 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% أخرى من التكلفة.
- عدم إمكانية الوصول الفعلي إلى بعض البيانات (فهي مرئية للمسؤولين أو يصعب جمعها) - يجب أن يؤخذ ذلك في الاعتبار؛ من حيث المبدأ، لا يمكن جمع كل البيانات في الوقت المناسب.
- أخطاء الشبكة: الشبكات مؤلمة.
- هذه بيانات حقيقية حية - وهي ليست نقية أبدًا.
بالطبع، من الضروري تضمين هذه الفروق الدقيقة في التطوير. تعتمد الساعات/الأيام المحددة على خبرة التطوير أو الخبرة في العمل على مهام مماثلة، ومع ذلك، نرى أن المهمة هنا هندسية بحتة ولا تتطلب حركات إضافية للجسم لحلها - يمكن تقييم كل شيء وجدولته وتنفيذه بشكل جيد للغاية.
مقارنة أقسام حبر
دعنا ننتقل إلى حالة أكثر إثارة للاهتمام وغير تافهة لمقارنة المواضيع و/أو أقسام الهبر.
دعونا نتحقق من قائمة التعقيد الخاصة بنا - هنا، من أجل فهم كل نقطة، سيتعين عليك التعمق قليلاً في المهمة نفسها والتجربة.
- في البداية تعتقد أن هناك واجهة برمجة التطبيقات (API)، لكن لا توجد. نعم، نعم، يحتوي Habr على واجهة برمجة التطبيقات (API)، لكنها ليست في متناول المستخدمين (أو ربما لا تعمل على الإطلاق).
- ثم تبدأ في تحليل HTML - "طلبات الاستيراد"، ما الخطأ الذي يمكن أن يحدث؟
- كيفية تحليل على أي حال؟ الطريقة الأبسط والأكثر استخدامًا هي التكرار على المعرفات، لاحظ أنها ليست الأكثر كفاءة وسيتعين عليها التعامل مع حالات مختلفة - فيما يلي مثال على كثافة المعرفات الحقيقية بين جميع المعرفات الموجودة.
مأخوذ من المادة. - تعتبر البيانات الأولية المغلفة بتنسيق HTML أعلى الويب أمرًا مؤلمًا. على سبيل المثال، تريد جمع تقييم مقال وحفظه: لقد قمت بحذف النتيجة من HTML وقررت حفظها كرقم لمزيد من المعالجة:
1) int(score) يلقي خطأ: نظرًا لوجود علامة ناقص في حبري، كما هو الحال، على سبيل المثال، في السطر "-5" - هذه شرطة قصيرة، وليست علامة ناقص (بشكل غير متوقع، أليس كذلك؟) في مرحلة ما اضطررت إلى إعادة المحلل اللغوي إلى الحياة بمثل هذا الإصلاح الرهيب.
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) بخلاف البحث والأمل في أن ينجح شيء ما.
- لا توجد أمثلة ولا مجتمع، ونقطة الدعم الوحيدة في جمع المعلومات هي نقطة صغيرة في بايثون (بدون أمثلة كثيرة للاستخدام).
- يبدو أن السيلينيوم هو الخيار الأكثر عملية، حيث أن العديد من البيانات الضرورية مقفلة.
1) أي أن التفويض يتم من خلال مستخدم وهمي (والتسجيل باليد).2) ومع ذلك، مع السيلينيوم لا توجد ضمانات للعمل الصحيح والقابل للتكرار (على الأقل في حالة 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 نستخدم نهجًا أماميًا مع تحليل HTML، وفي حالة OK يمكننا العمل مع واجهة برمجة التطبيقات في الأماكن المهمة.
النتائج
بغض النظر عن مقدار المواعيد النهائية المطلوبة منك لتقدير المواعيد النهائية "على الفور" (نحن نخطط اليوم!) لوحدة خط أنابيب معالجة البيانات الضخمة، يكاد يكون من غير الممكن أبدًا تقدير وقت التنفيذ حتى من الناحية النوعية دون تحليل معلمات المهمة.
من ناحية أكثر فلسفية قليلًا، تعمل استراتيجيات التقدير الرشيقة بشكل جيد للمهام الهندسية، لكن المشكلات التي تكون أكثر تجريبية، وبمعنى ما، "إبداعية" واستكشافية، أي أقل قابلية للتنبؤ بها، تواجه صعوبات، كما في أمثلة المواضيع المماثلة، التي ناقشناها هنا.
وبطبيعة الحال، جمع البيانات هو مجرد مثال رئيسي - فهو عادة مهمة بسيطة بشكل لا يصدق وغير معقدة من الناحية الفنية، وغالبا ما يكون الشيطان في التفاصيل. وفي هذه المهمة بالتحديد، يمكننا إظهار مجموعة كاملة من الخيارات الممكنة لما يمكن أن يحدث من خطأ والمدة التي يمكن أن يستغرقها العمل بالضبط.
إذا ألقيت نظرة على خصائص المهمة دون تجارب إضافية، فإن Reddit و OK يبدوان متشابهين: هناك واجهة برمجة التطبيقات (API)، ومجمع Python، ولكن في جوهرها، الفرق كبير. إذا حكمنا من خلال هذه المعلمات، فإن بارامترات هبر تبدو أكثر تعقيدًا من حسنًا - ولكنها في الواقع عكس ذلك تمامًا، وهذا هو بالضبط ما يمكن اكتشافه من خلال إجراء تجارب بسيطة لتحليل معلمات المشكلة.
في تجربتي، فإن النهج الأكثر فعالية هو التقدير التقريبي للوقت الذي ستحتاجه للتحليل الأولي نفسه والتجارب الأولى البسيطة، وقراءة الوثائق - سيسمح لك ذلك بتقديم تقدير دقيق للعمل بأكمله. فيما يتعلق بمنهجية Agile الشائعة، أطلب منك إنشاء تذكرة لـ “تقدير معلمات المهمة”، والتي يمكنني على أساسها تقديم تقييم لما يمكن إنجازه ضمن “Sprint” وإعطاء تقدير أكثر دقة لكل منها مهمة.
ولذلك، يبدو أن الحجة الأكثر فعالية هي تلك التي من شأنها أن تظهر للمتخصص "غير الفني" مقدار الوقت والموارد التي ستختلف اعتمادًا على المعلمات التي لم يتم تقييمها بعد.
المصدر: www.habr.com