ڈیٹا سائنس کے ساتھ کیا غلط ہو سکتا ہے؟ ڈیٹا اکٹھا کرنا

آج ڈیٹا سائنس کے 100500 کورسز ہیں اور یہ بات طویل عرصے سے معلوم ہے کہ ڈیٹا سائنس میں سب سے زیادہ رقم ڈیٹا سائنس کورسز کے ذریعے کمائی جا سکتی ہے (جب آپ بیلچے بیچ سکتے ہیں تو کھودیں کیوں؟) ان کورسز کا بنیادی نقصان یہ ہے کہ ان کا حقیقی کام سے کوئی لینا دینا نہیں ہے: کوئی بھی آپ کو مطلوبہ فارمیٹ میں صاف، پراسیس شدہ ڈیٹا نہیں دے گا۔ اور جب آپ کورس چھوڑ دیتے ہیں اور ایک حقیقی مسئلہ حل کرنا شروع کرتے ہیں تو بہت سی باریکیاں سامنے آتی ہیں۔

لہذا، ہم میرے ساتھ پیش آنے والے حقیقی واقعات پر مبنی "ڈیٹا سائنس کے ساتھ کیا غلط ہو سکتا ہے" نوٹوں کا ایک سلسلہ شروع کر رہے ہیں۔ ہم حقیقی مثالوں کا استعمال کرتے ہوئے ڈیٹا سائنس کے عام کاموں کا تجزیہ کریں گے: یہ حقیقت میں کیسے ہوتا ہے۔ آئیے آج ڈیٹا اکٹھا کرنے کا کام شروع کرتے ہیں۔

اور پہلی چیز جس سے لوگ ٹھوکر کھاتے ہیں جب وہ حقیقی ڈیٹا کے ساتھ کام کرنا شروع کرتے ہیں وہ دراصل اس ڈیٹا کو اکٹھا کرنا ہے جو ہمارے لیے سب سے زیادہ متعلقہ ہے۔ اس مضمون کا اہم پیغام:

ہم ڈیٹا اکٹھا کرنے، صاف کرنے اور تیار کرنے کے لیے درکار وقت، وسائل اور کوشش کو منظم طریقے سے کم سمجھتے ہیں۔

اور سب سے اہم بات یہ ہے کہ ہم اس پر بات کریں گے کہ اس کو روکنے کے لیے کیا کرنا چاہیے۔

مختلف اندازوں کے مطابق، صفائی، تبدیلی، ڈیٹا پروسیسنگ، فیچر انجینئرنگ وغیرہ میں 80-90% وقت لگتا ہے، اور تجزیہ 10-20%، جب کہ تقریباً تمام تعلیمی مواد صرف تجزیہ پر مرکوز ہوتا ہے۔

آئیے ایک عام مثال کے طور پر تین ورژنوں میں ایک سادہ تجزیاتی مسئلہ کو دیکھتے ہیں اور دیکھتے ہیں کہ "اضطراب پیدا کرنے والے حالات" کیا ہیں۔

اور ایک مثال کے طور پر، ایک بار پھر، ہم ڈیٹا اکٹھا کرنے اور کمیونٹیز کا موازنہ کرنے کے کام کے اسی طرح کے تغیرات پر غور کریں گے:

1. دو Reddit subreddits
2. حبر کے دو حصے
3. Odnoklassniki کے دو گروپ

نظریہ میں مشروط نقطہ نظر

سائٹ کھولیں اور مثالیں پڑھیں، اگر یہ واضح ہے تو پڑھنے کے لیے چند گھنٹے، مثالوں اور ڈیبگنگ کا استعمال کرتے ہوئے کوڈ کے لیے چند گھنٹے مختص کریں۔ جمع کرنے کے لیے چند گھنٹے شامل کریں۔ ریزرو میں چند گھنٹوں میں پھینک دیں (دو سے ضرب کریں اور N گھنٹے شامل کریں)۔

کلیدی نکتہ: وقت کا تخمینہ مفروضوں اور اندازے پر مبنی ہوتا ہے کہ اس میں کتنا وقت لگے گا۔

اوپر بیان کردہ مشروط مسئلہ کے لیے درج ذیل پیرامیٹرز کا تخمینہ لگا کر وقت کا تجزیہ شروع کرنا ضروری ہے۔

• ڈیٹا کا سائز کیا ہے اور اس میں سے کتنے کو جسمانی طور پر جمع کرنے کی ضرورت ہے (*نیچے دیکھیں*)۔
• ایک ریکارڈ کو جمع کرنے کا وقت کیا ہے اور دوسرا جمع کرنے سے پہلے آپ کو کتنا انتظار کرنا ہوگا؟
• لکھنے والے کوڈ پر غور کریں جو ریاست کو بچاتا ہے اور جب (اگر نہیں) سب کچھ ناکام ہوجاتا ہے تو دوبارہ شروع ہوتا ہے۔
• معلوم کریں کہ آیا ہمیں اجازت کی ضرورت ہے اور API کے ذریعے رسائی حاصل کرنے کا وقت مقرر کریں۔
• ڈیٹا کی پیچیدگی کے فنکشن کے طور پر غلطیوں کی تعداد کو سیٹ کریں - کسی خاص کام کے لیے اندازہ کریں: ساخت، کتنی تبدیلیاں، کیا اور کیسے نکالنا ہے۔
• نیٹ ورک کی خرابیوں اور غیر معیاری پروجیکٹ کے رویے کے ساتھ مسائل کو درست کریں۔
• اس بات کا اندازہ لگائیں کہ کیا مطلوبہ فنکشن دستاویزات میں ہیں اور اگر نہیں، تو پھر ایک کام کے لیے کس طرح اور کتنی ضرورت ہے۔

سب سے اہم بات یہ ہے کہ وقت کا اندازہ لگانے کے لیے - آپ کو درحقیقت وقت اور کوشش کو "قوت میں تلاش" پر خرچ کرنے کی ضرورت ہے - تب ہی آپ کی منصوبہ بندی کافی ہو گی۔ لہذا، اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کو "ڈیٹا جمع کرنے میں کتنا وقت لگتا ہے" کہنے پر مجبور کیا جاتا ہے - اپنے آپ کو ابتدائی تجزیہ کے لیے کچھ وقت خریدیں اور اس بات پر بحث کریں کہ کام کے حقیقی پیرامیٹرز کے لحاظ سے وقت کتنا مختلف ہوگا۔

اور اب ہم مخصوص مثالوں کا مظاہرہ کریں گے جہاں اس طرح کے پیرامیٹرز تبدیل ہوں گے۔

کلیدی نکتہ: تخمینہ کام کے دائرہ کار اور پیچیدگی کو متاثر کرنے والے کلیدی عوامل کے تجزیہ پر مبنی ہے۔

قیاس پر مبنی تخمینہ ایک اچھا نقطہ نظر ہے جب فعال عناصر کافی چھوٹے ہوں اور ایسے بہت سے عوامل نہیں ہیں جو مسئلہ کے ڈیزائن کو نمایاں طور پر متاثر کر سکتے ہیں۔ لیکن ڈیٹا سائنس کے متعدد مسائل کی صورت میں، ایسے عوامل بہت زیادہ ہو جاتے ہیں اور ایسا نقطہ نظر ناکافی ہو جاتا ہے۔

Reddit کمیونٹیز کا موازنہ

آئیے سب سے آسان کیس سے شروع کریں (جیسا کہ یہ بعد میں پتہ چلتا ہے)۔ عام طور پر، مکمل طور پر ایماندار ہونے کے لیے، ہمارے پاس تقریباً ایک مثالی معاملہ ہے، آئیے اپنی پیچیدگی کی چیک لسٹ دیکھیں:

• ایک صاف، واضح اور دستاویزی API ہے۔
• یہ انتہائی آسان ہے اور سب سے اہم بات یہ ہے کہ ایک ٹوکن خود بخود حاصل ہو جاتا ہے۔
• ہے ازگر کی چادر - بہت ساری مثالوں کے ساتھ۔
• ایک کمیونٹی جو reddit پر ڈیٹا کا تجزیہ کرتی ہے اور جمع کرتی ہے (یہاں تک کہ یوٹیوب ویڈیوز تک یہ بتاتی ہے کہ 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 کی حدیں - ہم بیچوں میں ڈیٹا لینے پر مجبور ہیں (درخواستوں کے درمیان نیند وغیرہ)۔
• جمع کرنے کا وقت - مکمل تجزیہ اور موازنہ کے لیے، آپ کو صرف مکڑی کے سبریڈیٹ سے گزرنے کے لیے اہم وقت مختص کرنا ہوگا۔
• بوٹ کو سرور پر چلنا چاہیے — آپ اسے صرف اپنے لیپ ٹاپ پر نہیں چلا سکتے، اسے اپنے بیگ میں رکھ سکتے ہیں، اور اپنے کاروبار کو آگے بڑھا سکتے ہیں۔ تو میں نے سب کچھ VPS پر چلایا۔ پروموشنل کوڈ habrahabr10 کا استعمال کرتے ہوئے آپ مزید 10% لاگت بچا سکتے ہیں۔
• کچھ ڈیٹا کی فزیکل ناقابل رسائی (وہ منتظمین کے لیے نظر آتے ہیں یا جمع کرنا بہت مشکل ہیں) - اس کو ضرور مدنظر رکھا جانا چاہیے؛ اصولی طور پر، تمام ڈیٹا کو مناسب وقت میں جمع نہیں کیا جا سکتا۔
• نیٹ ورک کی خرابیاں: نیٹ ورکنگ ایک تکلیف ہے۔
• یہ زندہ حقیقی ڈیٹا ہے - یہ کبھی بھی خالص نہیں ہوتا ہے۔

یقینا، ان باریکیوں کو ترقی میں شامل کرنا ضروری ہے۔ مخصوص گھنٹے/دن اسی طرح کے کاموں پر کام کرنے والے ترقیاتی تجربے یا تجربے پر منحصر ہوتے ہیں، تاہم، ہم دیکھتے ہیں کہ یہاں کام خالصتاً انجینئرنگ ہے اور اسے حل کرنے کے لیے جسم کی اضافی حرکت کی ضرورت نہیں ہے - ہر چیز کا بہت اچھی طرح سے اندازہ لگایا جا سکتا ہے، طے شدہ اور کیا جا سکتا ہے۔

حبر حصوں کا موازنہ

آئیے حبر کے دھاگوں اور/یا حصوں کا موازنہ کرنے کے ایک زیادہ دلچسپ اور غیر معمولی معاملے کی طرف چلتے ہیں۔

آئیے اپنی پیچیدگی کی چیک لسٹ چیک کرتے ہیں - یہاں، ہر ایک نکتے کو سمجھنے کے لیے، آپ کو اپنے کام میں تھوڑا سا کھودنا ہوگا اور تجربہ کرنا ہوگا۔

• پہلے آپ کو لگتا ہے کہ ایک API ہے، لیکن وہاں نہیں ہے۔ ہاں، ہاں، ہیبر کے پاس ایک API ہے، لیکن یہ صارفین کے لیے قابل رسائی نہیں ہے (یا شاید یہ بالکل کام نہیں کرتا ہے)۔
• پھر آپ صرف html - "درآمد کی درخواستیں" کو پارس کرنا شروع کرتے ہیں، کیا غلط ہو سکتا ہے؟
• ویسے بھی تجزیہ کیسے کریں؟ سب سے آسان اور کثرت سے استعمال ہونے والا طریقہ یہ ہے کہ آئی ڈیز پر اعادہ کیا جائے، یاد رکھیں کہ یہ سب سے زیادہ کارآمد نہیں ہے اور اسے مختلف معاملات کو ہینڈل کرنا پڑے گا - یہاں تمام موجودہ آئی ڈیز کے درمیان اصلی IDs کی کثافت کی ایک مثال ہے۔

  
  سے لیا اس مضامین

• ویب کے اوپر 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
  

  ہو سکتا ہے کوئی تاریخ، پلس اور مائنس بالکل نہ ہو (جیسا کہ ہم اوپر چیک_ڈیٹ فنکشن میں دیکھتے ہیں، ایسا ہوا)۔

  2) غیر محفوظ خصوصی کردار - وہ آئیں گے، آپ کو تیار رہنے کی ضرورت ہے۔

  3) پوسٹ کی قسم کے لحاظ سے ڈھانچہ تبدیل ہوتا ہے۔

  4) پرانی پوسٹس میں **عجیب ڈھانچہ** ہوسکتا ہے۔

• بنیادی طور پر، غلطی سے نمٹنے اور کیا ہو سکتا ہے یا نہیں ہو سکتا اس کو ہینڈل کرنا پڑے گا اور آپ یقین سے اندازہ نہیں لگا سکتے کہ کیا غلط ہو گا اور ڈھانچہ کیسے ہو سکتا ہے اور کہاں گرے گا - آپ کو صرف کوشش کرنی ہو گی اور اس کو مدنظر رکھنا ہو گا۔ وہ غلطیاں جو تجزیہ کار پھینکتا ہے۔
• تب آپ کو احساس ہوگا کہ آپ کو کئی تھریڈز میں پارس کرنے کی ضرورت ہے، بصورت دیگر ایک میں پارس کرنے میں 30+ گھنٹے لگیں گے (یہ خالصتاً پہلے سے کام کرنے والے سنگل تھریڈڈ پارسر کا عمل درآمد کا وقت ہے، جو سوتا ہے اور کسی پابندی کے تحت نہیں آتا ہے)۔ میں اس مضمون، اس نے کسی وقت اسی طرح کی اسکیم کی طرف لے جایا:

پیچیدگی کے لحاظ سے کل چیک لسٹ:

• نیٹ ورک کے ساتھ کام کرنا اور HTML کو تکرار کے ساتھ پارس کرنا اور ID کے ذریعے تلاش کرنا۔
• متناسب ساخت کی دستاویزات۔
• بہت ساری جگہیں ہیں جہاں کوڈ آسانی سے گر سکتا ہے۔
• لکھنا ضروری ہے || کوڈ
• ضروری دستاویزات، کوڈ کی مثالیں، اور/یا کمیونٹی غائب ہیں۔

اس کام کا تخمینہ وقت Reddit سے ڈیٹا اکٹھا کرنے کے مقابلے میں 3-5 گنا زیادہ ہوگا۔

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 سب سے زیادہ عقلی آپشن کی طرح لگتا ہے۔

• ریاست کو بچانے اور سسٹم کو دوبارہ شروع کرنے، سائٹ کے متضاد رویے سمیت بہت سی غلطیوں کو سنبھالنا ضروری ہے - اور ان غلطیوں کا تصور کرنا کافی مشکل ہے (جب تک کہ آپ پیشہ ورانہ طور پر تجزیہ کار نہ لکھیں)۔

اس کام کے لیے مشروط وقت کا تخمینہ Habr سے ڈیٹا اکٹھا کرنے کے مقابلے میں 3-5 گنا زیادہ ہوگا۔ اس حقیقت کے باوجود کہ Habr کے معاملے میں ہم HTML پارسنگ کے ساتھ فرنٹل اپروچ استعمال کرتے ہیں، اور OK کی صورت میں ہم اہم جگہوں پر API کے ساتھ کام کر سکتے ہیں۔

نتائج

اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کو ایک بڑے ڈیٹا پروسیسنگ پائپ لائن ماڈیول کی "موقع پر" (آج ہم منصوبہ بنا رہے ہیں!) کی آخری تاریخ کا اندازہ لگانے کی کتنی ضرورت ہے، کام کے پیرامیٹرز کا تجزیہ کیے بغیر عمل درآمد کے وقت کا اندازہ لگانا تقریباً ممکن نہیں ہے۔

قدرے زیادہ فلسفیانہ نوٹ پر، چست اندازی کی حکمت عملی انجینئرنگ کے کاموں کے لیے اچھی طرح کام کرتی ہے، لیکن ایسے مسائل جو زیادہ تجرباتی ہیں اور ایک لحاظ سے، "تخلیقی" اور تحقیقی، یعنی کم پیشین گوئی، مشکلات کا سامنا ہے، جیسا کہ اسی طرح کے موضوعات کی مثالوں میں، جس پر ہم نے یہاں بات کی ہے۔

بلاشبہ، ڈیٹا اکٹھا کرنا صرف ایک اہم مثال ہے - یہ عام طور پر ایک ناقابل یقین حد تک آسان اور تکنیکی طور پر غیر پیچیدہ کام ہے، اور شیطان اکثر تفصیلات میں ہوتا ہے۔ اور یہ بالکل اس کام پر ہے کہ ہم ممکنہ اختیارات کی پوری رینج دکھا سکتے ہیں کہ کیا غلط ہوسکتا ہے اور کام میں کتنا وقت لگ سکتا ہے۔

اگر آپ اضافی تجربات کے بغیر کام کی خصوصیات پر نظر ڈالتے ہیں، تو Reddit اور OK ایک جیسے نظر آتے ہیں: ایک API ہے، ایک ازگر کا ریپر، لیکن جوہر میں، فرق بہت بڑا ہے۔ ان پیرامیٹرز کو دیکھتے ہوئے، Habr کے پارس OK سے زیادہ پیچیدہ نظر آتے ہیں - لیکن عملی طور پر اس کے بالکل برعکس ہے، اور مسئلہ کے پیرامیٹرز کا تجزیہ کرنے کے لیے سادہ تجربات کرنے سے یہی معلوم کیا جا سکتا ہے۔

میرے تجربے میں، سب سے زیادہ مؤثر طریقہ یہ ہے کہ آپ کو ابتدائی تجزیہ کے لیے درکار وقت کا اندازہ لگانا اور آسان پہلے تجربات، دستاویزات کو پڑھ کر - یہ آپ کو پورے کام کا درست تخمینہ لگانے کی اجازت دے گا۔ مقبول چست طریقہ کار کے لحاظ سے، میں آپ سے "تخمینہ ٹاسک پیرامیٹرز" کے لیے ایک ٹکٹ بنانے کو کہتا ہوں، جس کی بنیاد پر میں اس بات کا اندازہ لگا سکتا ہوں کہ "اسپرنٹ" کے اندر کیا کیا جا سکتا ہے اور ہر ایک کے لیے زیادہ درست تخمینہ دے سکتا ہوں۔ کام

لہذا، سب سے زیادہ مؤثر دلیل ایک "غیر تکنیکی" ماہر کو دکھائے گی کہ پیرامیٹر کے لحاظ سے کتنا وقت اور وسائل مختلف ہوں گے جن کا ابھی اندازہ ہونا باقی ہے۔

ماخذ: www.habr.com