امروزه 100500 دوره علوم داده وجود دارد و مدت هاست که مشخص شده است که بیشترین درآمد را در علوم داده می توان از طریق دوره های علوم داده به دست آورد (چرا وقتی می توانید بیل بفروشید حفاری کنید؟). نقطه ضعف اصلی این دوره ها این است که هیچ ارتباطی با کار واقعی ندارند: هیچ کس داده های تمیز و پردازش شده را در قالب مورد نیاز به شما نمی دهد. و هنگامی که دوره را ترک می کنید و شروع به حل یک مشکل واقعی می کنید، تفاوت های ظریف زیادی ظاهر می شود.
بنابراین، ما مجموعه ای از یادداشت ها را شروع می کنیم "چه چیزی ممکن است با Data Science اشتباه کند" بر اساس رویدادهای واقعی که برای من، رفقا و همکارانم اتفاق افتاده است. ما وظایف معمولی علم داده را با استفاده از مثال‌های واقعی تجزیه و تحلیل می‌کنیم: این که واقعاً چگونه اتفاق می‌افتد. بیایید امروز را با کار جمع آوری داده ها شروع کنیم.
و اولین چیزی که مردم هنگام شروع کار با داده های واقعی به آن دچار می شوند، در واقع جمع آوری این داده هایی است که بیشترین ارتباط را با ما دارد. پیام کلیدی این مقاله:
ما به طور سیستماتیک زمان، منابع و تلاش مورد نیاز برای جمع آوری، تمیز کردن و آماده سازی داده ها را دست کم می گیریم.
و مهمتر از همه، ما در مورد آنچه برای جلوگیری از این امر باید انجام دهیم صحبت خواهیم کرد.
بر اساس تخمین های مختلف، تمیز کردن، تبدیل، پردازش داده ها، مهندسی ویژگی ها و غیره 80-90٪ زمان و تجزیه و تحلیل 10-20٪ طول می کشد، در حالی که تقریباً تمام مطالب آموزشی منحصراً بر تجزیه و تحلیل متمرکز هستند.
بیایید به یک مسئله تحلیلی ساده در سه نسخه به عنوان یک مثال معمولی نگاه کنیم و ببینیم که "شرایط تشدید کننده" چیست.
و به عنوان مثال، مجدداً، تغییرات مشابهی از کار جمع آوری داده ها و مقایسه جوامع برای موارد زیر را در نظر خواهیم گرفت:
- دو زیرمجموعه Reddit
- دو بخش از حبر
- دو گروه از Odnoklassniki
رویکرد مشروط در تئوری
سایت را باز کنید و مثال ها را بخوانید، اگر واضح است، چند ساعت برای خواندن، چند ساعت برای کد با استفاده از مثال ها و اشکال زدایی وقت بگذارید. چند ساعت برای جمع آوری اضافه کنید. چند ساعت ذخیره کنید (در دو ضرب کنید و N ساعت اضافه کنید).
نکته کلیدی: تخمین های زمان بر اساس فرضیات و حدس و گمان ها در مورد مدت زمانی است که طول می کشد.
لازم است تجزیه و تحلیل زمانی را با تخمین پارامترهای زیر برای مسئله شرطی که در بالا توضیح داده شد آغاز کنیم:
- اندازه داده ها چقدر است و چه مقدار از آن باید به صورت فیزیکی جمع آوری شود (*به زیر مراجعه کنید*).
- زمان جمع آوری یک رکورد چقدر است و چه مدت باید منتظر بمانید تا بتوانید رکورد دوم را جمع آوری کنید؟
- نوشتن کدی را در نظر بگیرید که وضعیت را ذخیره می کند و هنگامی که (نه اگر) همه چیز خراب شود، راه اندازی مجدد را شروع می کند.
- مشخص کنید که آیا به مجوز نیاز داریم یا خیر و زمان دسترسی از طریق API را تعیین کنید.
- تعداد خطاها را به عنوان تابعی از پیچیدگی داده ها تنظیم کنید - برای یک کار خاص ارزیابی کنید: ساختار، تعداد تغییرات، چه چیزی و چگونه استخراج شود.
- رفع خطاهای شبکه و مشکلات مربوط به رفتار غیر استاندارد پروژه.
- ارزیابی کنید که آیا عملکردهای مورد نیاز در مستندات وجود دارد و اگر نه، پس چگونه و چقدر برای یک راه حل مورد نیاز است.
مهمترین چیز این است که برای تخمین زمان - در واقع باید زمان و تلاش خود را صرف "تجسس در نیرو" کنید - تنها در این صورت برنامه ریزی شما کافی خواهد بود. بنابراین، مهم نیست که چقدر برای گفتن «مدت زمان لازم برای جمع‌آوری داده‌ها» تحت فشار قرار می‌گیرید - مدتی برای تجزیه و تحلیل اولیه برای خود بخرید و بر اساس پارامترهای واقعی مشکل بحث کنید که چقدر زمان متفاوت خواهد بود.
و اکنون نمونه های خاصی را نشان خواهیم داد که در آن چنین پارامترهایی تغییر می کنند.
نکته کلیدی: برآورد بر اساس تجزیه و تحلیل عوامل کلیدی موثر بر دامنه و پیچیدگی کار است.
تخمین مبتنی بر حدس زمانی رویکرد خوبی است که عناصر عملکردی به اندازه کافی کوچک باشند و عوامل زیادی وجود نداشته باشد که بتواند به طور قابل توجهی بر طراحی مشکل تأثیر بگذارد. اما در مورد تعدادی از مشکلات علم داده، چنین عواملی بسیار زیاد می شوند و چنین رویکردی ناکافی می شود.
مقایسه جوامع Reddit
بیایید با ساده ترین مورد (همانطور که بعدا مشخص شد) شروع کنیم. به طور کلی، برای اینکه کاملا صادق باشیم، ما یک مورد تقریبا ایده آل داریم، بیایید چک لیست پیچیدگی خود را بررسی کنیم:
- یک API منظم، واضح و مستند وجود دارد.
- بسیار ساده است و مهمتر از همه، یک توکن به طور خودکار به دست می آید.
- وجود دارد - با مثال های فراوان
- انجمنی که داده‌ها را در reddit تجزیه و تحلیل و جمع‌آوری می‌کند (حتی ویدیوهای YouTube که نحوه استفاده از python wrapper را توضیح می‌دهند) .
- روش هایی که ما نیاز داریم به احتمال زیاد در 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) یک خطا پرتاب می کند: از آنجایی که در Habré یک منهای وجود دارد، به عنوان مثال، در خط "–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 با تکرار و جستجو بر اساس ID.
- اسناد ساختار ناهمگن
- مکان های زیادی وجود دارد که کد به راحتی می تواند سقوط کند.
- نوشتن || ضروری است کد
- مستندات لازم، نمونه‌های کد و/یا انجمن وجود ندارد.
زمان تخمین زده شده برای این کار 3-5 برابر بیشتر از جمع آوری داده ها از Reddit خواهد بود.
مقایسه گروه های Odnoklassniki
بیایید به جالب ترین موردی که از نظر فنی توضیح داده شده است برویم. برای من، دقیقاً به این دلیل جالب بود که در نگاه اول، کاملاً پیش پا افتاده به نظر می رسد، اما به هیچ وجه اینطور نیست - به محض اینکه یک چوب به آن فشار دهید.
بیایید با چک لیست دشواری خود شروع کنیم و توجه داشته باشیم که بسیاری از آنها بسیار دشوارتر از آن چیزی هستند که در ابتدا به نظر می رسند:
- یک API وجود دارد، اما تقریباً به طور کامل فاقد توابع لازم است.
- برای برخی از عملکردها باید از طریق پست درخواست دسترسی کنید، یعنی اعطای دسترسی آنی نیست.
- این به طرز وحشتناکی مستند است (برای شروع، اصطلاحات روسی و انگلیسی در همه جا با هم مخلوط شده اند، و کاملاً متناقض - گاهی اوقات فقط باید حدس بزنید که آنها در جایی از شما چه می خواهند) و، به عنوان مثال، طراحی برای به دست آوردن داده ها مناسب نیست. ، .
- به یک جلسه در مستندات نیاز دارد، اما در واقع از آن استفاده نمی‌کند - و هیچ راهی برای درک همه پیچیدگی‌های حالت‌های API وجود ندارد، جز اینکه به اطراف بپردازید و امیدوار باشید چیزی کار کند.
- هیچ نمونه و هیچ جامعه ای وجود ندارد، تنها نقطه پشتیبانی در جمع آوری اطلاعات کوچک است در پایتون (بدون مثال های زیاد).
- به نظر می رسد سلنیوم کارآمدترین گزینه باشد، زیرا بسیاری از داده های لازم قفل شده اند.
1) یعنی مجوز از طریق یک کاربر ساختگی (و ثبت نام به صورت دستی) صورت می گیرد.2) با این حال، با سلنیوم هیچ تضمینی برای کار صحیح و قابل تکرار وجود ندارد (حداقل در مورد ok.ru مطمئنا).
3) وب سایت Ok.ru حاوی خطاهای جاوا اسکریپت است و گاهی اوقات رفتاری عجیب و ناسازگار دارد.
4) شما باید صفحه بندی، بارگذاری عناصر و غیره را انجام دهید.
5) خطاهای API که wrapper می دهد باید به طرز ناخوشایندی مدیریت شوند، به عنوان مثال، مانند این (یک قطعه کد آزمایشی):
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) در نهایت، سلنیوم + API منطقی ترین گزینه به نظر می رسد.
- لازم است وضعیت را ذخیره کنید و سیستم را مجدداً راه اندازی کنید، خطاهای زیادی را مدیریت کنید، از جمله رفتار ناسازگار سایت - و تصور این خطاها بسیار دشوار است (البته مگر اینکه تجزیه کننده را به صورت حرفه ای بنویسید).
تخمین زمان مشروط برای این کار 3-5 برابر بیشتر از جمع آوری داده ها از Habr خواهد بود. علیرغم اینکه در مورد Habr از رویکرد frontal با تجزیه HTML استفاده می کنیم و در مورد OK می توانیم در مکان های حساس با API کار کنیم.
یافته ها
مهم نیست که چقدر از شما خواسته می شود تا ضرب الاجل های یک ماژول خط لوله پردازش داده های حجیم را برآورد کنید (ما امروز در حال برنامه ریزی هستیم)، تقریباً هرگز نمی توان زمان اجرا را حتی از نظر کیفی بدون تجزیه و تحلیل پارامترهای وظیفه تخمین زد.
از نظر فلسفی‌تر، استراتژی‌های برآورد چابک برای کارهای مهندسی به خوبی کار می‌کنند، اما مسائلی که بیشتر تجربی و به یک معنا «خلاقانه» و اکتشافی هستند، یعنی کمتر قابل پیش‌بینی هستند، مانند نمونه‌هایی از موضوعات مشابه، مشکلاتی دارند. که در اینجا به آن پرداخته ایم.
البته، جمع‌آوری داده‌ها فقط یک مثال اصلی است - معمولاً یک کار فوق‌العاده ساده و از نظر فنی بدون پیچیدگی است، و شیطان اغلب در جزئیات است. و دقیقاً در این کار است که می‌توانیم طیف وسیعی از گزینه‌های ممکن را برای مواردی که ممکن است اشتباه پیش برود و دقیقاً چقدر طول بکشد، نشان دهیم.
اگر بدون آزمایش‌های اضافی به ویژگی‌های کار نگاهی بیندازید، Reddit و OK شبیه به هم هستند: یک API، یک پوشش پایتون وجود دارد، اما در اصل، تفاوت بسیار زیاد است. با قضاوت بر اساس این پارامترها، پارس هابر پیچیده تر از OK به نظر می رسد - اما در عمل کاملاً برعکس است، و این دقیقاً همان چیزی است که می توان با انجام آزمایش های ساده برای تجزیه و تحلیل پارامترهای مسئله به آن پی برد.
در تجربه من، موثرترین رویکرد تخمین تقریبی زمانی است که برای خود آنالیز اولیه و آزمایش های اولیه ساده، خواندن مستندات نیاز دارید - اینها به شما امکان می دهد یک برآورد دقیق برای کل کار ارائه دهید. از نظر روش پرطرفدار چابک، از شما می‌خواهم بلیطی برای «تخمین پارامترهای کار» ایجاد کنید، که بر اساس آن می‌توانم ارزیابی از آنچه می‌توان در «sprint» انجام داد و تخمین دقیق‌تری برای هر یک ارائه داد. وظیفه.
بنابراین، به نظر می‌رسد مؤثرترین استدلال، استدلالی باشد که به یک متخصص «غیر فنی» نشان دهد که بسته به پارامترهایی که هنوز ارزیابی نشده‌اند، چقدر زمان و منابع متفاوت خواهد بود.
منبع: www.habr.com