ما الذي يتغير عندما يكون حجم مدخلاتك بحجم Giga/Terabyte؟

Question

لقد أخذت للتو خطوة الطفل الأولى اليوم إلى الحوسبة العلمية الحقيقية اليوم عندما تم عرض مجموعة بيانات حيث يكون أصغر ملف هو 48000 حقل بمقدار 1600 صف (أنماط فردية لعدة أشخاص ، للكروموسوم 22). وهذا يعتبر صغيرًا.

أنا أكتب Python ، لذلك قضيت الساعات القليلة الماضية في القراءة عن HDF5 ، و Numpy ، و Pytable ، لكنني ما زلت أشعر أنني لا أتعامل مع مجموعة البيانات بحجم terabyte في الواقع بالنسبة لي كمبرمج.

على سبيل المثال ، أشار شخص ما إلى أنه مع مجموعات بيانات أكبر ، يصبح من المستحيل قراءة كل شيء في الذاكرة ، ليس لأن الجهاز لديه ذاكرة الوصول العشوائي غير الكافية ، ولكن لأن الهندسة المعمارية لديها مساحة عنوان غير كافية! فجرت ذهني.

ما هي الافتراضات الأخرى التي كنت أعتمد عليها في الفصل الدراسي التي لا تعمل مع إدخال هذا الكبير؟ ما هي أنواع الأشياء التي أحتاجها لبدء القيام بها أو التفكير فيها بشكل مختلف؟ (هذا لا يجب أن يكون بيثون محددًا.)

Answer 1

أنا مشارك حاليًا في الحوسبة عالية الأداء في زاوية صغيرة من صناعة النفط وأعمل بانتظام مع مجموعات البيانات من أوامر الحجم التي تشعر بالقلق بشأنها. فيما يلي بعض النقاط التي يجب مراعاتها:

1. قواعد البيانات ليس لديها الكثير من الجر في هذا المجال. يتم الاحتفاظ بجميع بياناتنا تقريبًا في الملفات ، وتستند بعض هذه الملفات إلى تنسيقات ملفات الشريط المصممة في السبعينيات. أعتقد أن جزءًا من سبب عدم استخدام قواعد البيانات تاريخية ؛ 10 ، حتى 5 ، منذ سنوات ، أعتقد أن Oracle و Kin لم يكن على مستوى مهمة إدارة مجموعات البيانات الفردية لـ O (TB) ناهيك عن قاعدة بيانات تضم 1000 من مجموعات البيانات هذه.

   سبب آخر هو عدم التوافق المفاهيمي بين قواعد التطبيع لتحليل قاعدة البيانات الفعال والتصميم وطبيعة مجموعات البيانات العلمية.

   أعتقد (على الرغم من أنني لست متأكدًا) من أن سبب (أسباب) الأداء أقل إقناعًا اليوم. وربما يكون سبب عدم التطابق المفهوم أقل إلحاحًا أيضًا بعد أن يمكن لمعظم قواعد البيانات الرئيسية المتاحة التعامل مع مجموعات البيانات المكانية التي هي عمومًا مناسبة مفاهيمية أكثر بكثير لمجموعات البيانات العلمية الأخرى. لقد رأيت استخدامًا متزايدًا لقواعد البيانات لتخزين بيانات التعريف ، مع نوع من المرجع ، إذن ، إلى الملفات (الملفات) التي تحتوي على بيانات المستشعر.

   ومع ذلك ، ما زلت أنظر ، في الواقع أنظر ، HDF5. إنه يحتوي على اثنين من عوامل الجذب بالنسبة لي (أ) إنه مجرد تنسيق ملف آخر ، لذا لا يتعين علي تثبيت DBMs والتصارع مع تعقيداته ، و (ب) مع الأجهزة المناسبة يمكنني قراءة/كتابة ملف HDF5 بالتوازي . (نعم ، أعلم أنه يمكنني قراءة وكتابة قواعد البيانات بالتوازي أيضًا).

2. الأمر الذي يأخذني إلى النقطة الثانية: عند التعامل مع مجموعات بيانات كبيرة جدًا ، تحتاج حقًا إلى التفكير في استخدام حساب متوازي. أعمل في الغالب في فورتران ، واحدة من نقاط قوتها هي بناء جملة الصفيف الذي يتناسب بشكل جيد مع الكثير من الحوسبة العلمية ؛ آخر هو الدعم الجيد للتوازي المتاح. أعتقد أن Python لديه كل أنواع دعم التوازي أيضًا ، لذا ربما لا يكون خيارًا سيئًا لك.

   من المؤكد أنه يمكنك إضافة التوازي إلى أنظمة متسلسلة ، ولكن من الأفضل بكثير البدء في التصميم للتوازي. لأخذ مثال واحد فقط: أفضل خوارزمية متسلسلة لمشكلة ما في كثير من الأحيان ليس أفضل مرشح للتوازي. قد تكون أفضل حالًا في استخدام خوارزمية مختلفة ، واحدة تعمل بشكل أفضل على معالجات متعددة. مما يؤدي بدقة إلى النقطة التالية.

3. أعتقد أيضًا أنه قد تضطر إلى التصالح مع تسليم أي مرفقات لديك (إذا كان لديك) إلى الكثير من الخوارزميات الذكية وهياكل البيانات التي تعمل بشكل جيد عندما تكون جميع بياناتك مقيمة في الذاكرة. في كثير من الأحيان تحاول تكييفهم مع الموقف حيث لا يمكنك إدخال البيانات في الذاكرة في وقت واحد ، تكون أصعب بكثير (وأقل أداء) من القوة الغاشمة وخصوص الملف بأكمله كصفيف كبير واحد.

4. يبدأ الأداء في المهمة بطريقة جادة ، كل من أداء تنفيذ البرامج ، وأداء المطورين. ليس الأمر أن مجموعة بيانات 1 تيرابايت تتطلب 10 أضعاف أكبر عدد من التعليمات البرمجية مثل مجموعة بيانات 1 جيجابايت ، لذا عليك أن تعمل بشكل أسرع ، فهذا بعض الأفكار التي ستحتاج إلى تنفيذها ستكون معقدة بشكل جنون ، وربما يجب كتابتها من قبل متخصصين في المجال ، أي العلماء الذين تعمل معهم. هنا يكتب المتخصصون في المجال في ماتلاب.

لكن هذا يحدث لفترة طويلة ، من الأفضل أن أعود إلى العمل

Answer 2

باختصار ، الاختلافات الرئيسية IMO:

1. يجب أن تعرف مسبقًا ما سيكون عنق الزجاجة المحتمل (I/O أو CPU) والتركيز على أفضل خوارزمية وبنية تحتية لمعالجة هذا الأمر. I/O في كثير من الأحيان هو عنق الزجاجة.
2. غالبًا ما يهيمن اختيار الخوارزمية على أي خيار آخر.
3. حتى التغييرات المتواضعة على الخوارزميات وأنماط الوصول يمكن أن تؤثر على الأداء حسب أوامر الحجم. سوف تكون مثيرا للحيوانات الجزئية كثيرا. سيكون الحل "الأفضل" يعتمد على النظام.
4. تحدث إلى زملائك وغيرهم من العلماء للاستفادة من تجاربهم مع مجموعات البيانات هذه. لا يمكن العثور على الكثير من الحيل في الكتب المدرسية.
5. يمكن أن يكون الحاسوب والتخزين ناجحًا للغاية.

النطاق الترددي و I/O

في البداية ، غالبًا ما يكون عرض النطاق الترددي وإدخال/إخراج عنق الزجاجة. لإعطائك منظورًا: عند الحد النظري ل SATA 3, ، يستغرق حوالي 30 دقيقة لقراءة 1 تيرابايت. إذا كنت بحاجة إلى وصول عشوائي ، أو اقرأ عدة مرات أو تكتب ، فأنت تريد القيام بذلك في الذاكرة معظم الوقت أو تحتاج إلى شيء أسرع إلى حد كبير (على سبيل المثال ISCSI مع إنفينيباند). يجب أن يتمكن نظامك بشكل مثالي من القيام به موازية I/O لكي تقترب قدر الإمكان من الحد النظري لأي واجهة تستخدمها. على سبيل المثال ، ما عليك سوى الوصول إلى ملفات مختلفة بالتوازي في عمليات مختلفة ، أو HDF5 في قمة ال MPI-2 I/O شائع جدا. من الناحية المثالية ، تقوم أيضًا بالحساب والإدخال/الإخراج بالتوازي بحيث يكون أحدهما "مجانًا".

عناقيد المجموعات

اعتمادًا على قضيتك ، قد تكون إما I/O أو وحدة المعالجة المركزية من عنق الزجاجة. بغض النظر عن أي واحد ، يمكن تحقيق زيادات ضخمة في الأداء مع مجموعات إذا كان يمكنك توزيع مهامك بشكل فعال (مثال MapReduce). قد يتطلب هذا خوارزميات مختلفة تمامًا عن أمثلة الكتب المدرسية النموذجية. إن قضاء وقت التنمية هنا غالبًا ما يكون أفضل وقت يقضيه.

الخوارزميات

في الاختيار بين الخوارزميات ، يعد Big O من الخوارزمية مهمة للغاية ، ولكن يمكن أن تختلف الخوارزميات ذات الكبار المماثل بشكل كبير في الأداء اعتمادًا على الموقع. كلما كانت الخوارزمية المحلية الأقل محلية هي (أي كلما زاد عدد ذاكرة التخزين المؤقت والذاكرة الرئيسية) ، كلما كان الأداء أسوأ - يكون الوصول إلى التخزين عادةً أمرًا أبطأ من الذاكرة الرئيسية. الأمثلة الكلاسيكية للتحسينات ستكون تبليط لمضاعفات المصفوفة أو تبادل الحلقة.

الكمبيوتر واللغة والأدوات المتخصصة

إذا كان عنق الزجاجة الخاص بك هو I / O ، فهذا يعني أن الخوارزميات لمجموعات البيانات الكبيرة يمكن أن تستفيد من المزيد من الذاكرة الرئيسية (على سبيل المثال 64 بت) أو لغات البرمجة / هياكل البيانات مع استهلاك أقل للذاكرة (على سبيل المثال ، في بيثون __slots__ قد تكون مفيدة) ، لأن المزيد من الذاكرة قد تعني أقل I/O لكل وحدة المعالجة المركزية. راجع للشغل ، أنظمة مع TBS من الذاكرة الرئيسية ليست غير معروفة (على سبيل المثال HP Superdomes).

وبالمثل ، إذا كان عنق الزجاجة الخاص بك هو وحدة المعالجة المركزية ، فإن الآلات واللغات والمترجمين الأسرع سيم مثل SSE) قد تزيد من الأداء بترتيب الحجم.

يمكن أن تكون طريقة العثور على البيانات والوصول إليها ، وتخزين معلومات التعريف مهمة للغاية للأداء. ستقوم غالبًا باستخدام الملفات المسطحة أو الحزم غير القياسية الخاصة بالمجال لتخزين البيانات (على سبيل المثال ، ليس DB علائقي مباشرة) تمكنك من الوصول إلى البيانات بشكل أكثر كفاءة. فمثلا، KDB+ هي قاعدة بيانات متخصصة لسلسلة زمنية كبيرة ، و جذر يستخدم TTree كائن للوصول إلى البيانات بكفاءة. ال pytables ذكرت سيكون مثالا آخر.

Answer 3

على الرغم من أن بعض اللغات لديها انخفاض في الذاكرة بشكل طبيعي في أنواعها أكثر من غيرها ، فإن هذا لا يهم حقًا البيانات بهذا الحجم - فأنت لا تمسك مجموعة بياناتك بالكامل في الذاكرة بغض النظر عن اللغة التي تستخدمها ، وبالتالي فإن "النفقات" من بيثون غير ذي صلة هنا. كما أشرت ، لا يوجد ببساطة مساحة عنوان كافية حتى للرجوع إلى كل هذه البيانات ، ناهيك عن التمسك بها.

ما يعنيه هذا عادة هو إما أ) تخزين بياناتك في قاعدة بيانات ، أو ب) إضافة الموارد في شكل أجهزة كمبيوتر إضافية ، وبالتالي إضافة إلى مساحة العنوان المتاحة والذاكرة. من الناحية الواقعية ، ستنتهي في نهاية المطاف القيام بكل من هذين الأشياء. أحد الأشياء الرئيسية التي يجب وضعها في الاعتبار عند استخدام قاعدة بيانات هي أن قاعدة البيانات ليست مجرد مكان لوضع بياناتك أثناء عدم استخدامها - يمكنك القيام بالعمل في قاعدة البيانات ، ويجب أن تحاول القيام بذلك. إن تقنية قاعدة البيانات التي تستخدمها لها تأثير كبير على نوع العمل الذي يمكنك القيام به ، ولكن قاعدة بيانات SQL ، على سبيل المثال ، مناسبة تمامًا للقيام بالكثير من الرياضيات والقيام بها بكفاءة (بالطبع ، هذا يعني أن تصميم المخطط جزء مهم جدا من الهندسة المعمارية العامة). لا تمتص البيانات فقط وتلقيها فقط في الذاكرة - حاول الاستفادة من إمكانات الاستعلام الحسابية لقاعدة البيانات الخاصة بك للقيام بأكبر قدر ممكن من العمل قبل وضع البيانات في الذاكرة في عمليتك.

Answer 4

الافتراضات الرئيسية تدور حول كمية وحدة المعالجة المركزية/ذاكرة التخزين المؤقت/ذاكرة الوصول العشوائي/التخزين/النطاق الترددي الذي يمكنك الحصول عليه في جهاز واحد بسعر مقبول. لا تزال هناك الكثير من الإجابات هنا في Stackoverflow تعتمد على الافتراضات القديمة لآلة 32 بت مع ذاكرة الوصول العشوائي 4G وحوالي terabyte من التخزين وشبكة 1 جيجابايت. مع وحدات RAM 16 جيجا بايت DDR-3 عند 220 يورو ، وذاكرة وصول عشوائي 512 جيجابايت ، يمكن بناء 48 آلات أساسية بأسعار معقولة. يعد التبديل من الأقراص الصلبة إلى SSD تغييرًا مهمًا آخر.