X
تبلیغات
داده کاوی و هوش مصنوعی - وب کاوي استفاده از وب

داده هاي  وب

يکي از گام هاي کليدي در کشف دانش در پايگاه داده، ايجاد يک مجموعه داده مناسب جهت انجام داده کاوي مي باشد.در وب کاوي اين داده مي تواند از سمت سرور، مشتري، پروکسي سرور يا از يک پايگاه داده سازمان جمع آوري شود. هر کدام از اين داده ها نه تنها از نظ منابع داده متفاوت مي باشند بلکه از نظر انواع داده هاي موجود و محدوده مکاني که آن داده از آنجا جمع آوري مي شود و متد پياده سازي آن

انواع داده اي که در وب کاوي استفاده مي شود شامل:

محتوا: داده واقعي در صفحات وب، داده اي که صفحه وب براي نمايش آن به کاربران طراحي شده است.که معمولاً از متن و گرافيک تشکيل شده ولي به آن محدود نمي شود.

ساختار: داده اي که سازمان دهي محتوا را مشخص مي سازد. اطلاعات ساختار درون صفحات شامل ترتيب انواع تگ هاي XML  يا HTML در يک صفحه داده شده مي باشد و مي تواند به صورت يک ساختار درختي نمايش داده شود که تگ ريشه درخت مي باشد. اصلي ترين نوع از اطلاعات ساختاري بين صفحات، هايپرلينک است که يک صفحه را به ديگري مرتبط مي کند.

استفاده: داده اي که الگوي استفاده از صفحات وب را مشخص مي سازد، مثل آدرس هاي IP، رجوع به صفحات و تاريخ و زمان دسترسي

پروفايل کاربر: داده اي که اطلاعات آماري درباره کاربران وب سايت فراهم مي سازد که شامل داده ثبت نام و اطلاعات پروفايل مشتري مي باشد.

 

منابع داده

داده هاي استفاده که از منابع مختلفي جمع آوري مي شود، الگوهاي راهبري از بخش هاي مختلفي از کل ترافيک وب را نمايش مي دهد.

 

جمع آوري در سطح سرور

لاگ هاي وب سرور يک منبع مهم براي اجراي وب کاوي استفاده از وب محسوب مي شود زيرا به طور صريح رفتار مرورگري تمام مشاهده کنندگان سايت را ثبت مي کند. داده اي که در لاگ سرور ثبت مي شود، دسترسي به يک وب سايت که از سوي  تمام کاربران صورت مي گيرد را منعکس مي کند. اين فايل هاي لاگ به فرمت هاي گوناگوني چون Common log يا Extended log ذخير مي شوند.

جمع آوري در سطح مشتري

جمع آوري داده در سطح مشتري مي تواند با بکارگيري يک عامل از راه دور( مثل اپلت هاي جاوا يا جاوا اسکريپت) يا با تغيير کد مرجع يک مرورگر موجود( مثل Mozilla يا Mosaic)  پياده سازي شود.پياده سازي اين نوع روش  جمع آوري داده در سطح مشتري به همکاري کاربر در هر دو مورد ذکر شده نياز دارد.

 

جمع آوري در سطح پروکسي

يک پروکسي وب به عنوان يک سطح مياني از ذخيره سازي بين مرورگر سمت مشتري و وب سرور محسوب مي شود تا زمان بارگذاري  صفحه وبي که توسط کاربر تجربه شده را کاهش دهد همانطور که بار ترافيکي در سمت مشتري و سرور را کاهش مي دهد.

داده هاي لاگ مربوط به وب معمولاً حجيم و گسترده هستند وبه منظور کشف الگو،  اين داده ها بايد در يک ديد يکپارچه، سازگار و جامع جمع آوري شوند . در بيشتر کاربردهاي داده کاوي پيش پردازش داده با حذف و فيلتر کردن داده هاي افزونه و بي ربط  و حذف نويزو تبديل و رفع  هر ناسازگاري   سروکار دارد. پيش پردازش داده  نقش اساسي در کاربردهاي کشف دانش در  داده  استفاده از وب [1]دارا هستند و مهمترين مساله در بيشتر روش هاي کشف الگو، مشکل آن ها در اداره داده هاي استفاده از وب در مقياس بزرگ است . به همين خاطر اکثر فرايندهاي KDWUD   به طور غير بر خط انجام مي شوند . تحليل داده استفاده بدون روش پيش پردازش مناسب نتايج ضعيف و يا حتي خرابي را بدنبال خواهد داشت . بنابراين متودولوژي براي پيش پردازش بايد به کار گرفته شود تا هر مجموعه اي از فايل هاي لاگ وب سرور را به مجموعه ساختاريافته اي از جداول در مدل پايگاه داده رابطه اي تبديل کند . فايل هاي لاگ از وي سايت هاي مختلف يک سازمان با هم ادغام مي شوند تا رفتار کاربراني که از طريقي ملموس راهبري داشته اند را نمايش دهد . بنابراين اين فايل ها بايد با حذف درخواست هايي که مورد نياز نيستند، پاک[2] مي شوند مانند درخواست هاي ضمني براي آبجکت هاي تعبيه شده در صفحات وب و يا درخواست هايي که بوسيله مشتري هاي غير انساني وب سايت ها يجاد مي شود . درخواست هاي باقيمانده  با کاربر، نشست هاي کاربر و مشاهدات و مشاهده  صفحات،  گروه بندي مي شود . و در نهايت مجموعه هاي پاک و تبديل شده از درخواست هاي کاربران در يک مدل پايگاه داده رابطه اي ذخيره مي شود . از فيلتر هايي براي فيلتر کردن داده هاي بدون استفاده، بي ربط و ناخواسته استفاده مي شود تحليلگر مي تواند فايل هاي لاگ را از وب سرورهاي متفاوت جمع آوري کند و تصميم گيري کند که کداميک از ورودي ها مطلوب هستند . در واقع هدف اين است که اندازه بزرگ داده هاي استفاده از وب موجود به طور قابل توجهي کاهش يابد  و در عين حال کيفيت آن با سازمان دهي آن و فراهم سازي متغير هاي يکپارچه  اضافي براي تحليل  داده کاوي افزايش يابد .

 

 

فرمول بندي مساله

فرض کنيد مجموعه R={r1,r2,r3,…,rn}   مجموعه تمام منابع وب [3]از يک وب سايت باشد . اگرU={u1,u2,…,um}  مجموعه تمام کاربراني که به سايت دسترسي داشتند،  باشد؛ عنصر لاگ بصورت li=   تعريف مي شود که  ui Є U ; ri ЄRاست و t  زمان دسترسي را نمايش مي دهد،  s  وضعيت درخواست وref i  صفحه مورد مراجعه را نمايش مي دهد . ref i در برخي ازفرمت هاي لاگ هاي وب مثل CLF در حالي که صفحه مورد مراجعه ثبت نشده،  اختياري است . s يک کد سه رقمي است که موفقيت يا شکست درخواست مورد نظر را نشان مي دهد . همچنين در موارد ديگر دليل شکست را نيز بيان مي کند . يک وضعيت با مقدار s=200 نشان مي دهد که درخواست  موفق است در حالي که وضعيت با مقدار s=404  نشان دهنده اين است که فايل مورد درخواست  در محل مورد نظر يافت نشده است . li={li1,li2,…,lim}  به ترتيب صعودي ذخيره مي شوند که يک لاگ وب سرور را تشکيل مي دهند . در صورت داشتن N وب سرور، مجموعه فايل هاي لاگ,…,LN}  Log={L1, L2 است .با بکارگيري اين علائم مسئله پيش پردازش به صورت زير فرمول بندي مي شود . " با دريافت يک مجموعه از فايل هاي لاگ مربوط به لاگ هاي وب سايت هاي مختلف، کاربر، نشست هاي کاربر، مشاهده  و مشاهدات صفحات کاربران وب سايت در يک بازه زماني مشخص ∆t  استخراج مي شود ."

پيش پردازش داده

همانطور که در شکل نشان داده شده است فرايند پيش پردازش گام هاي زير را در بر مي گيرد :

·        ادغام فايل هاي لاگ از وب سرورهاي گوناگون

·        پاک کردن داده

·        شناسايي کاربران، نشست ها و مشاهده  ها

·        فرمت بندي داده و خلاصه سازي آن

 

ادغام

در ابتداي پيش پردازش داده، درخواست از تمام فايل هاي لاگ در Log در يک فايل لاگ الحاقي £همراه  با نام وب سرور جهت تشخيص بين درخواست هاي ايجاد شده مربوط به وب سرورهاي مختلف  وهمچنين توجه به همگام سازي کلاک هاي وب سرورهاي مختلف که از لحاظ  زماني متفاوت اند . در شکل 2 شبه کد مربوط  به اين عمل نشان داده شده است . به خاطر دلايل محرمانگي، فايل لاگ نتيجه f را بي نام کرده  بطوريکه وقتي که فايل هاي لاگ  به اشتراک گذاشته مي شود يا نتايج  منتشر مي شوند،  نام  ميزبان يا آدرس هاي IP ، از بين مي روند . بنابراين  نام اصلي ميزبان با يک شناسنده اي که اطلاعاتي درباره محدوده دامنه ( کد کشور يا نوع سازمان مثل .edu , .com ,.org) نگهداري مي کند، جايگزين مي شود . مسئله ادغام به صورت زير فرمولبندي مي شود:

با دريافت يک مجموعه فايل هاي لاگ Log={L1,L2,…,Ln}  اين فايل هاي لاگ در يک فايل لاگ مجزا و منفرد ادغام مي شود ( فايل لاگ الحاقي ) فرض کنيد Li، i امين فايل لاگ مي باشد . Li.c را به عنوان اشاره گر بر روي درخواست هاي Li در نظر بگيريد وLi.1 عنصر لاگ جاري از Li است که با Li.c نشان داده مي شود و Li.1.time، زمان t مربوط به عنصرلاگ  جاري از Li مي باشد و همچنين  S=(w1,w2,…,wn) آرايه اي از اسامي وب سرورها مي باشد به طوري که S[i]  نام وب سرور مربوط به لاگ L i.1 مي باشد .

مراحل :

1.      مقداردهي اوليه اشاره گر فايل لاگ الحاقي  £

2.      اسکن عناصر لاگ از هر فايل لاگ Li در Log  و افزودن  آن به £

3.      مرتب سازي عناصر £ به طور صعودي بر اساس زمان دسترسي آن ها

برگرداندن مقدار £

پاک کردن داده

 

·        گام دوم در پيش پردازش داده حذف درخواست هاي بدون استفاده  از فايل هاي لاگ مي باشد . بطوريکه اگر تمام ورودي هاي لاگ معتبر نباشند، بايد ورودي هاي بيربط را حذف کنيم .معمولاً اين فرايند تمام درخواستهايي که منابع غير قابل تحليل مثل تصاوير، فايل هاي چندرسانه اي و فايل هاي مربوط به سبک صفحات را در بر مي گيرند، را حذف مي کند . براي مثال درخواستهاي مربوط  به  محتواي صفحات گرافيکي ( تصاوير *.jpg & *.gif) و همچنين درخواستهاي مربوط  به هر فايل ديگر در يک صفحه وب يا حتي نشست هاي راهبري که توسط رباط ها و اسپا يدر هاي وب انجام مي شود .  با فيلتر کردن داده هاي بي استفاده، مي توانيم سايز فايل لاگ را کاهش داده تا از فضاي ذخيره سازي کوچکتري  استفاده کرده و نيز کارهاي بعدي را آسان تر  کنيم .براي نمونه، با فيلتر کردن درخواست هاي تصاوير، سايز فايل هاي لاگ وب سرور نسبت به سايز اوليه اش تا 50 درصد کاهش مي يابد . بنابراين پاک کردن داده حذف ورودي  هاي بي ربطي چون موارد زير مي باشد:

·        درخواستهايي که توسط برنامه هاي خودکار انجام مي شود مثل : Web Robot ,Spiders و Crawler ها .اين برنامه ها ترافيکي بر روي وب سايت ايجاد مي کنند که مي توانند بر روي  آمار سايت  تاثير بگذارند و همچنين در بررسي هايي که توسط KDWUD انجام مي شود مطلوب نيستند .

·        درخواستهاي مربوط به فايل هاي تصويري که  به صفحات  مشخصي اختصاص داده مي شود . درخواست يک کاربر براي مشاهده يک صفحه خاص معمولاً در چندين در چندين عنصر از لاگ منعکس مي شود زيرا هر صفحه گرافيک هايي را شامل مي شود که فقط آنهايي براي ما مهم هستند که کاربر صريحاً آنها را درخواست کرده که معمولاً فايل هاي منتي هسنتد .

·        عناصر با کدهاي وضعيت HTTP  نا موفق . کدهاي وضعيت HTTP  براي نشان دادن موفقيت يا شکست يک درخواست بکار مي روند که در اينجا ما فقط عناصر با کد بين 200 تا 299 که با موفقيت انجام شده اند در نظر مي گيريم .

·        عناصري که متدي به غير از GET  و POST  دارند .

 

شناسايي

در اين گام درخواستهاي غير ساختيافته يک فايل لاگ به صورت کاربر(user) ، نشست کاربر(user session) ، مشاهدات و ملافات صفحات(page view ,visit)   گروه بندي مي شود . در پايان اين گام فايل لاگ به صورت يک مجموعه از تراکنش ها خواهد بود (نشست کاربر يا مشاهدات )

 

 

 

کاربر

در بيشتر موارد فايل لاگ فقط آدرس هاي کامپيوتر ( نام يا IP)  و عامل کاربر را فراهم مي سازد ( به عنوان مثال فايل هاي لاگ ECLF ) . براي وب سايتهايي که نيازمند ثبت کاربرهستند، فايل لاگ همچنين  User login را شامل مي شود ( به عنوان سومين رکورد در يک عنصر لاگ ) که براي شناسايي کاربر استفاده مي شود . وقتي که user login موجود نباشد هر IP  به عنوان کابر در نظر گرفته مي شود . با اين حال اين واقعيت وجود دارد که يک آدرس IP  توسط چندين کاربر استفاده مي شود واين  براي KDWUD جهت شناسايي کاربر کافي نيست . به هر حال هنوز هم  مکانيزمي براي تشخيص و تمايز بين کاربران براي تحليل رفتار دسترسي کاربر مورد نياز است .

 

نشست کاربر

شناسايي نشست کاربر از فايل لاگ بدليل پروکسي سرورها، آدرس هاي پويا و مواردي که چندين کاربر از طريق يک کامپيوتر دسترسي پيدا مي کنند ( در کتابخانه، کافي نت و...) يا يک کابر از چندين مرورگر يا کامپيوتر استفاده مي کند، امکان پذير نمي باشد . يک نشست کاربر به صورت ترتيبي از درخواست ها که بوسيله يک کاربرمنفرد  در يک دوره زماني مشخص تعريف مي شود . يک کاربر مي تواند يک (يا چند) نشست در طول يک دوره زماني داشته باشد .شناسايي نشست عبارت است از فرايند قطعه بندي لاگ دسترسي هر کاربر به نشست هاي دسترسي مجزا .دو روش بر اساس زمان وجود دارد که شامل روش مبتني بر طول نشست (Session-duration)  و روش مبتني بر page-stay-time . همچنين مي توانيم از يک  آستانه زماني timeout  استفاده مي کنيم . در ادامه شبه کد مربوط به فرايند شناسايي نشست آورده شده است و بررسي مي کند که آيا نشست به پايان رسيده يا اينکه فايل مورد رجوع در هيچ يک از نشست هاي باز قبلي وجود ندارد . در اين صورت يک نشست جديد باز مي شود .از آنجاييکه Log بوسيله IP address/Agent  ذخيره مي شود تمام نشست هاي باز کانديدهاي بالقوه اي براي دسترسي به فايل پردازش شده هستند . تابع Session_ Gen   تابع Distance را فراخواني مي کند که اين تابع history  مربوط به فايل هايي که اخيراً به فايل f دسترسي داشته اند را پيدا مي کند .

نماي صفحات(page view)  

گام مربوط به شناسايي نماي صفحه تعيين مي کند کدام درخواست فايل صفحه بخشي از همان نماي صفحه است و اينکه چه محتوايي ارائه شده است .اين گام  لازم است  تا نتايج معناداري  براي  فاز تحليل الگو فراهم شود و اگر اين گام اجرا نشود الگوهاي کشف شده تحت تاثير فايل هاي صفحه که يک نماي صفحه معروف و مشخص را تشکيل مي دهد قرار مي گيرد . نماي صفحه با بکارگيري زمان درخواست مشخص مي شود . براي درخواست هايي که در يک لحظه ايجاد شده اند تنها اولين درخواست حفظ مي شود و بقيه دور ريخته مي شوند . بعد از شناسايي نماي صفحه، فايل لاگ به طور نرمال فقط يک درخواست براي هر عمل کاربر در بر مي گيرد . هر نشست بايد با يک نماي صفحه ابتدايي شروع شود . يک فايل صفحه آغازين يا يک مجموعه از فايل هاي صفحه از تمام نماي صفحات بعدي مشتق مي شود . در اکثر موارد، نماي صفحه آغازين از يک فايل تشکيل مي شود يا با يک فايل منفرد که ساختار قاب را مشخص مي سازد و بلافاصله منجر به درخواست فايل هاي صفحه بعدي مي شود .خيلي به ندرت اتفاق مي افتد که يک سايت غير مرتبط به بيش از يک فايل صفحه ازيک  سايت ديگر از طريق يک ابر متن منفرد متصل شود .  در هر صورت چنين امري امکان پذير است و براي چنين مواردي تمام فايل هاي صفحه که در نماي صفحه آغازين شرکت دارد، بايد صراحتاً وارد الگوريتم شود .

 

خلاصه سازي و فرمت بندي داده  [4]

اين گام، آخرين گام پيش پردازش داده است . فايل ساختاريافته نشست ها و مشاهداتي را شامل مي شود که به يک مدل پايگاه داده رابطه اي تبديل مي شود . سپس يک متد تجميع  داده در سطح درخواست  اعمال شده و با مشاهدات و نشست هاي کاربر يکپارچه گشته بطور کامل پايگاه داده را پر کند . دو جدول در مدل پايگاه داده رابطه اي طراحي مي شود؛ يکي براي ذخيره داده لاگ و ديگري براي ذخيره نشست ها . خلاصه سازي داده بر روي محاسبه متغير هاي تجميع شده در سطوح مختلف انتزاع دلالت دارد ( درخواست، مشاهده و نشست کاربر) .

اين متغيرهاي جمع آوري شده بعداً در گام  داده کاوي مورد استفاده قرار مي گيرد و مقادير آماري را نمايش مي دهند که اشياء آناليز شده را مشخص مي سازند. براي نمونه، اگر شي مورد تحليل يک نشست کاربر باشد، در داده جمع آوري شده در فرايند محاسباتي، متغيرهاي زير محاسبه مي شوند:

·        تعداد ملاقات ها در هر نشست

·        طول هر نشست در ثانيه( اختلاف بين تاريخ  آخرين و اولين نشست) يا در صفحات مشاهده شده( تعداد کل مشاهدات صفحه)

·        تعداد مشاهدات براي يک دوره زماني مشخص، که مي تواند يک روز، هفته يا يک ماه باشد.

 

اگر شي مورد تحليل يک مشاهده باشد، متغيرهاي زير محاسبه مي شوند:

·        طول مشاهدات بر حسب  زمان و صفحه مشاهده شده

·        فاکتور تکراري در مشاهده

·        درصد درخواست هاي موفقيت آميز

·        ميانگين زمان سپري شده بر روي يک صفحه

 

به طور مشابه، ساير متغيرهاي جمع آوري شده که مي توانند محاسبه شوند:

·        درصد درخواست ها يي که به هر وب سرور اختصاص يافته

·        تعداد مشاهده کنندگان و ميزبان هاي منحصر به فرد در هر ساعت، هفته و ماه

·        تعداد عاملان کاربر منحصر به فرد در هر ساعت،روز، هفته و ماه

 



[1] Knowledge Discovery from Web Usage Data

[2] Clean

[3] Web Resource

[4] Data Formatting and Summarization

+ نوشته شده در شنبه نوزدهم دی 1388ساعت 18:5 توسط مهدی نصیری |