مايك أولسون يتحدث عن Hadoop *

انضمت مؤخراً Microsoft لقائمة داعمي تقنية Hadoop.

motamayez كتب:

انضمت مؤخراً Microsoft لقائمة داعمي تقنية Hadoop.

Microsoft تتخلى عن مشروعها Dryad لتعمل على مشروع Hadoop مفتوح المصدر

و عليكم السلام.

لم أشاهد الفيديو، فقط أرد لاستفسار بسيط، ما المقصود بـ"وهو واقف" في الموضوع و سابقًا في العنوان؟

sitesmaker كتب:

و عليكم السلام.

لم أشاهد الفيديو، فقط أرد لاستفسار بسيط، ما المقصود بـ"وهو واقف" في الموضوع و سابقًا في العنوان؟

ههه .. تقدر تقول psycho تظهر عندما أكتب مواضيع قبل و بعد صلاة الفجر :-) .

لكن شاهد الفيديو أخي ، هناك أمور قد لا نفهمها من أول قراءة ، ولا ندرك أهميتها ، لكن بكثرة القراءة و المشاهدة تبدأ الأمور بالاتضاح. أتذكر جيداً كيف كنت أعاني لأفهم بعض المفاهيم في Relational Databases .

طبعاً لم أفهم جيداً كيفية عمل Hadoop . أحتاج سنة لأستوعب .

شاهدت جزء من الفيديو و لم أفهم معظم ما قيل ... ربما بسبب لهجة التحدث ... ربما بسبب تعقيد الموضوع ...

ربما هو تحدث عن.. عدم ملائمة ال RDBMS ... الحاجه لنظام ملفات خاص (كما مع جوجل)

ذهبت إلى Apache و تصفحت بعض ال sub projects ... و لم أفهم شئ أكثر مما فهمته من الفيديو ...

تصفحت الكود الخاص بالمشروع commons و وجدت أنهم يستخدمون جافا! (مع Native calls to C/C++)

-------

شكراً أخ عبدالله على الموضوع, درس رائع على الواقف :)

اقتباس

ربما هو تحدث عن.. عدم ملائمة ال RDBMS ... الحاجه لنظام ملفات خاص (كما مع جوجل)

جوجل تستخدم نظام ملفات خاص لتطبيقاتها الموزعة لكي تحصل على أعلى أداء مقابل كل قرش يدفعونه في هذه الأجهزة. الفكرة من وراء Hadoop هي نفس الفكرة من وراء نظام الـ map/reduce المستخدم في جوجل. الفكرة نفسها سهلة بمجرد أن تفهم الأساسيات و لكن هناك الكثير من القرارات "الهندسية" للـ framework التي ستعقد المسألة لو لم تفهم الأساس.

ببساطة Map/Reduce عبارة عن دالة يتم تطبيقها على مصفوفة من المتغيرات(قد يكون كل متغير مجموعة من العناصر) و هذا هو الـmapping. ثم يتم تطبيق عملية اختزال للحصول على المطلوب, و عملية الاختزال عبارة عن دالة أخرى تطبق على نواتج الـ mapping و هذا ما يقصد به الـ reduce. خذ مثلاً, لو أن لديك مليون صفحة. و كان لديك عشرة أجهزة, و كل ما تريده هو معرفة تكرار كل كلمة موجودة في تلك الصفحات. سيكون لديك الدالة التالية افتراضاً:

hashtable<string, int> count_words(Page page);

الآن هذه الدالة ستعمل على العشرة أجهزة, بحيث أن كل جهاز يعد ما استطاع من الكلمات في الصفحات التي تصل إليه. هذا هو الـ mapping, أي قمنا بعمل mapping من الصفحات إلى عدد الكلمات فيها. الخطوة التالية, هي اختزال تلك المعلومات لأنها ما زالت مجزأة, بحيث أن لدينا عملية أخرى و هي جمع الـ hashtables التي لدينا مع بعضها البعض reduction:

hashtable<string, int> combine_hashtables
	(hashtable<string, int> first, hashtable<string, int> second);

ربما يقوم كل جهاز بطلب الـ hashtable الخاص بالجهاز الذي يليه, و هكذا حتى تتم العملية و نحصل على hashtable يحوي تكرار المليون صفحة التي وزعت على الأجهزة.

في النهاية, إذا استخدمت framework فأنت تكتب الـ mapping function و الـ reduction function و تترك الباقي(تقريباً) للـ framework لكي يوزع العمل بالشكل الأفضل.

الآن عندما تنزل من عالم الأحلام و النظريات, فإنك تحتاج إلى Framework لنقل البيانات, و لنقل الكود و جدولة توزيع المهام scheduling و fault tolerance و هذا ما توفره هذه الـ framework. فكرة الـ map/reduce كلها يمكن تلخيصها في التالي إذا أردت أن تكون دقيقاً:

قواعد البيانات العلائقية, قد تستخدم في الأجهزة كـ implementation detail و لكن لا تعتقد أبداً أن المشكلة فعلاً في تعلم إحدى تلك الـ frameworks لكي تصل إلى النجوم. المشكلة كلها في إمكانية حل المسألة التي لديك بحيث أن المشكلة يمكن أن تجزأ إلى أجزاء أصغر منفصلة عن بعضها "يمكن جمع النتائج فيما بعد", و الباقي أمور روتينية!!! عندما تكون أجزاء المشكلة تعتمد على أجزاء أخرى أي هناك dependency فإنك لن تستفيد أي شيء من وراء الـ map/reduce و ستحتاج لشراء supercomputer لحل المشكلة :blush:

هل هناك مثال على مشكلة يمكن تقسيمها ومشكلة لا يمكن تقسيمها :-) . مثلاً سأقوم بتطوير تطبيق ويب مثل twitter يخزن الحالات status و يبحث عنها .. أعرف جيداً عمل هذا من خلال Relational ، ولكن كيف سيتغير الوضع مع Hadoop .

Abdullah.Alshammeri كتب:

هل هناك مثال على مشكلة يمكن تقسيمها ومشكلة لا يمكن تقسيمها :-) . مثلاً سأقوم بتطوير تطبيق ويب مثل twitter يخزن الحالات status و يبحث عنها .. أعرف جيداً عمل هذا من خلال Relational ، ولكن كيف سيتغير الوضع مع Hadoop .

الـRelational أصلًا هي ما ترفض فكرتها لأسباب عديدة. و فكرة التوزيع أو التقسيم العادي، صعبة على ما أفهم مع التحديث المستمر، و توسع البيانات، تخيل البحث على "الفريق العربي للبرمجة" ليضطر المحرك للمرور بجميع السجلات على مثلًا عشرة آلاف سيرفر! و تخيل المجهود اللازم لمنع تكرار أو تلف البيانات....

اقتباس

هل هناك مثال على مشكلة يمكن تقسيمها ومشكلة لا يمكن تقسيمها

لو أن لديك مجموعة من الناس, و تريد تقسيمهم إلى مجموعات بحيث أن عناصر أي مجموعة ليس لها علاقة بالمجموعة الأخرى على الإطلاق. هذا قد يستعمل في الـ Social Networks لتقسيم الأعضاء إلى unique subsets. هذا الأمر يمكن حله بالتوازي على CUDA أو على supercomputer بسهولة, بينما لا يوجد حل يمكن أن تصفه بأنه efficiently distributed. في النهاية map/reduce اخترعت لبناء distributed supercomputers, لأن كم البيانات هائل بحيث أنه لا يوجد supercomputer واحد حقاً يمكنه معالجة هذا الكم من البيانات.

اقتباس

مثلاً سأقوم بتطوير تطبيق ويب مثل twitter يخزن الحالات status و يبحث عنها .. أعرف جيداً عمل هذا من خلال Relational ، ولكن كيف سيتغير الوضع مع Hadoop .

بالطبع لو كنت صاحب Twitter :P فسيكون لديك أكثر من خادم! عندما تريد تلخيص المعلومات كلها أو جزء كبير منها, لن تستطيع جمعها في مكان واحد للعمل عليها, و ستضطر لتلخيص المعلومات محلياً ثم جمع النتائج, هذه هي map/reduce ليست سحراً و لا شعوذة, الفكرة أنه لو كان لديك 20000 خادم هل يستغلها الـ framework حقاً, أم أنك تقوم بإهدار مواردك في عمليات الاتصال الغير لازمة على افتراض أن الخوارزمية التي تعمل محلياً هي أفضل ما وصلت إليه؟

اعتقد اننا احوج مانحتاج الى مواضيع مبسطه عن الrepresentations لماذا نختارها وكيف ندرسها ونقيمها ؟

بالنسبة لسؤالك عبدالله .. لايحضرني مثال لكني كعادتي احب اتفلسف من ناحية فلسفية بحته/

الامر بالاخير يرجع لطريقة تمثيل البيانات،

مثلاً لو وجدت ان البيانات تاخذ شكل قراف Graph (بدون ماندخل في تعقيدات اكثر) ووجدت ان هنالك علاقة ما تتيح لك فرصة ان تفصل sub graph عن الاخر

فهذا (باعتقادي الشخصي) يضمن لك انك قادر على تقسيم المشكلة.

تقسيم المشكلة لايعني بالضروره distributed app فاحياناً تقسيم المشكلة الى مشاكل اصغر يحفظ كثير من الوقت بغض النظر عن عدد الprocessors

الامر الاخر المهم (بعد ضبط الrepresentation المناسب) هو الخوارزمية المستخدمة..

بمعنى اخر ان expressive representation+efficient algorithm=best وطبعاً هذه معادلة صعبة ،،

مدري احس اني اغرد خارج السرب بس موضوع جميل،