هذه المقالة هي امتداد لسلسلة Case Locomizer ، انظر أيضًا
مرحبا
هل تعرف ما هو الوفاة؟ هذه قصة عن كيف وصلنا إلى هذه الحياة.
لست متأكدًا منكم ، لكني أحب قراءة القصص حول عملية تطوير بعض البرامج عالية التخصص أو منخفضة المستوى. قد يكون لدى الزملاء فكرة مثيرة للاهتمام للعمل معهم ، ومن الغريب دائمًا أن يتبعوا ما حدث للبرنامج من النموذج الأولي إلى المنتج الناضج ، مما يؤدي إلى بعض السحر في مجال موضوع غير مألوف.
بالإضافة إلى ذلك ، إذا قمت للتو بإلقاء رابط إلى مستودع به مثل هذه البرامج ، فمن غير المرجح أن يتمكن أي شخص من الحصول على فكرة عن ماهية هذا البرنامج ولماذا ولما هي المهام التي يمكن أن تكون مفيدة. حتى لو كنت أترجم من الإنجليزية ثلاث عشرة صفحة من التعليمات للبدء. ومع ذلك ، فإن إطار
سبارك ليس مجرد حرفة أخرى على الزاوي ، يجب أن يكون مفهوما
أن المؤلفين
دخنوا سبب كتابتها بهذه الطريقة وليس بطريقة أخرى.
هذه المقالة مقدمة تاريخية لـ One Ring. لا يوجد كود فيه ، والقصة أكثر شعبية من العلمية. ولكن فقط عن التنمية ، وعن أي شيء آخر ، باستثناء عامين ونصف العام من التنمية.
في المرة الأخيرة ، تحدثت بتفصيل كافٍ (آمل ما يكفي) عن صعوبات استخراج البيانات من مجموعات البيانات المجهولة الهوية في الممر الأوسط ، وفي النهاية ، اكتشفت أنها ليست مؤامرة ضعيفة. دعونا نترك قرارها لآخر مرة ، واليوم سوف نتحدث عن الطريق الطويل والصعب للوصول إلى الكمال في أداتنا الرئيسية:
- البيانات الكبيرة كبيرة
- حالتنا غير قياسية
- النموذج الأولي في C # و PostGIS
- النهج الأول ل Hadoop MapReduce
- ظهور CI و Spark
- التقريب الثالث في GeoSpark
- المحللين اليابانيين والهجرة من أزور إلى AWS
- Ash Nazg Durbatuluk، Ash Nazg Gimbatul، Ash Nazg Trakatuluk، Ag Burzum Ishi Krimpatul !!
- الأمثل و geocatarsis مع اوبر H3
- في كل البيض
البيانات الكبيرة كبيرة
البيانات الكبيرة ليست حول الحجم.
قد يكون هناك عشرات ، أو حتى مئات الملايين من السجلات في مجموعة بيانات شهرية في منطقة لندن الكبرى ، لكن هذا ليس كثيرًا. يعتمد التكرار الفردي عليها من البداية إلى النهاية على سرعة القراءة الخطية من القرص. إذا كان محرك الأقراص هو SSD ، فسوف يستغرق الأمر بضع ثوانٍ.
(أذكرك بأن مجموعة البيانات المعنية هي مجموعة من ملفات CSV تحتوي على مجموعة من الحقول الخاصة بالموفر. يحدث تجميع السجلات مع إحداثيات المستخدمين المجهولين في ملف على طول حدود المنطقة الإدارية للبلد أو المحافظة أو المدينة. يتم إنشاء الملفات نفسها على التاريخ المحدد ، يوميًا أو
شهريًا. مزيد من التفاصيل
موصوفة في الجزء السابق ، قم
بتشغيلها بشكل مائل إذا لم يكن هناك سياق كافٍ.)
عمليتنا متعددة الخطوات. عمليات الاستدلال الأولي لإثراء البيانات الخام التي تعمل فقط في وضع التكرار الفردي سريعة ، ويمكنك كتابتها على الأقل في Python ، على الأقل في C ++ ، حتى في PHP. حتى على جهاز ضعيف ، ستكون المعالجة سريعة.
إذا كانت مجموعة البيانات في مكان ما في السحابة ، إذن ، بشرط وضع المعالج في نفس السحابة ، فلا توجد مشكلة معينة للوصول إليها والمضي فيها وحفظ النتيجة بجانبها. علاوة على ذلك ، عادةً ما يكون الملف موجودًا بالفعل ، لأن موفري البيانات بسرور كبير سيرفعون الأرشيف إلى التخزين السحابي الخاص بهم ، مما يوفر لك رابط تنزيل. يبقى فقط نشر الجهاز الظاهري ، وسيتم وضع جميع المكتبات للوصول إلى المستودع بعناية من قبل البائع عليه ، يتم تسجيل جميع مفاتيح الوصول ، فقط أمسك API في يديك واستخدمها. سيكون سريع جدا.
حسنًا ، مع الخطوات الأولى ، كل شيء واضح. أخذوا الملف ، مروا به عدة مرات ، وأعدوا النسخة التي تمت معالجتها. ولكن ماذا يحدث إذا كانت الخطوات اللاحقة للخوارزمية الخاصة بنا تتطلب مجموعة من الحسابات المعقدة قليلاً لكل سجل؟
تأخذ شيئا مثل تحديد المسافة بين زوج من الإحداثيات. هناك طريقة
Haversine سريعة للغاية ("haversinuses" وفقًا لإصدار القاعة) ، والتي توفر دقة مقبولة على مسافات قصيرة ، وتتيح لك عدم أخذ
GGW84 الجيوديسي ، الذي يعمل حسابه ببطء أكثر بكثير.
في حد ذاته ، اتضح أن مثل هذا الحساب لا يكلف الكثير إذا كان أحاديًا. وحتى لو كان هناك عشرات الملايين منهم ، فإن هذا ، من حيث المبدأ ، هراء.
والآن نأخذ الحالة من خوارزمية لدينا حاصلة على براءة اختراع ، عندما نحتاج إلى حساب المسافة من كل إشارة إلى كل نقطة مهمة من الفئة المحددة ، وتجاهل تلك التي تزيد عن نصف كيلومتر (مثل هذه المسافة التي يسهل السير فيها).
بالنسبة لمنطقة لندن الكبرى ، يقع ما يقرب من مليون مؤسسة في
نقاط الاهتمام المستهدفة في فئة المتاجر والمنافذ. وكما قلت ، في البيانات الشهرية العشرات ، مئات الملايين من السجلات تأتي له. وهكذا نحصل ...
1،000،000 POIs × N ، 000،000 إشارة = N ، 000،000،000،000 مسافات.
أوه ، تعال. تريليونات مجنون من الحسابات عن بعد ومقارنات ثابتة عتبة.
الوضع الكلاسيكي مع
المنتج الديكارتي . مجموعتان غير قويتين بشكل فردي تعطيان بسهولة نتائج متوسطة × N
12 ، وهذا شهر واحد فقط في منطقة واحدة! مثل هذا المبلغ يتحول بالفعل إلى الجودة. ليس فقط حجم النتيجة الوسيطة يمثل مشكلة خطيرة بالفعل ، لأنه لا يتلاءم مع الذاكرة تمامًا ، ومن الضروري معالجتها فورًا في مكان الاستلام ، ولكن مقدار الحسابات اللازمة للحصول عليها يستغرق وقتًا طويلاً في الكمبيوتر. وإذا كان هناك سجل واحد ، مع مراعاة جميع التأخيرات في الإرسال عبر الشبكة ، والتكاليف العامة الأخرى ، يتم إنفاق 100 نانو ثانية فقط ، ثم ملايين الثواني هي أيام وأسابيع من العمليات الحسابية في دفق واحد.
أو ، إذا احتجنا إلى استبعاد جزء من عامة السكان ، على سبيل المثال ، الحالة "لا تأخذ في الاعتبار اهتمامات المستخدمين الذين يعيشون في منطقة معينة" ، فسوف يتعين علينا مقارنة الجهاز _id لكل سجل من مجموعة بيانات المخصب للمنطقة بأكملها بمجموعة تضم مئات الآلاف من السجلات بها تم استبعاد الجهاز_المقيم في هذه المنطقة. وهذه مقارنات سلسلة في نواح كثيرة ، وليس بالسرعة بالنسبة لإثنين من النت. مرة أخرى ، هناك نوع من العدد المجنون من الأصفار في تقييم عملية واحدة بسيطة ، ولدينا مجموعة كاملة من الاستدلال لمشروع متوسط مع عشرات ، أو أكثر.
البيانات الكبيرة هي البيانات التي تجعل من الضروري ، نظرًا لحجمها ، استخدام تقنيات حسابية خاصة بسبب عدم ملاءمة العملية أو تنفيذها بشكل غير مباشر.
... حتى إذا كانت النتيجة النهائية للحساب تنهار في شاشة واحدة من جدول Excel.
يمكنك محاولة موازنة المعالج "الساذج" بعدد المعالجات الافتراضية المتاحة على الجهاز الذي ندير فيه الحساب. يمكنك تقسيم مجموعة البيانات إلى أجزاء وتشغيل حساب أحجار الراين على عشرة أجهزة افتراضية في السحابة. ولكن كل هذا لن يعطي نتيجة ممتازة من الناحية النوعية. القياس "في العرض" يعطي
عائدات متناقصة تبدأ من عرض معين. ومن المؤكد أن مشكلة المزامنة والتقسيم ستظهر ، وستكلف إدارة أسطول كامل من الأجهزة الافتراضية وقت الخيل. إن إبقائها قيد التشغيل طوال الوقت أمر مكلف ، كما أن بدء الطلب ووقفه يتطلب عمالة كثيفة.
لذلك ، بالنسبة للبيانات الضخمة ، يتم استخدام حزم برامج خاصة من نظام Hadoop البيئي ، الذي يحتوي بالفعل على عناصر تحكم في النطاق ، بالإضافة إلى مجموعة خاصة من الخوارزميات التي تسمح للماموث بتناول الطعام في أجزاء صغيرة دون التعرض لخطر الاختناق على الكمية الفلكية للبيانات الوسيطة ، ويبسط إلى حد كبير حياة مطور البيانات الكبير. لكن لا يمكنك فقط استخدام Hadoop والبدء في استخدامه. تحتاج أولا إلى وضع خطة.
خاصة إذا ...
حالتنا غير قياسية
إذا سألت كيف تقوم المكاتب المعنية بالتحليلات في مجموعات البيانات الكبيرة ببناء عملياتها ، فقد اتضح أنه يتم استخدام طريقتين رئيسيتين في الممارسة العالمية.
النهج رقم 1. بحيرة البيانات
بالنسبة للبيانات التي تتراكم بمرور الوقت ، وتظل ذات صلة إلى الأبد ، تم تصميم نوع خاص من التخزين ، يُطلق عليه "
بحيرة البيانات ".
تم تحسين بنية هذه المستودعات للوصول العشوائي السريع. تتم ترجمة العديد من مجموعات البيانات التي تم جمعها إلى تنسيق متخصص يتيح لك تنفيذ التحديدات والشرائح متعددة المعايير بسرعة حسب مجموعات الأعمدة. على عكس قواعد البيانات التقليدية العلائقية والموجهة نحو المستندات ، يتم استخدام تخزين الأعمدة في بحيرات البيانات. عادةً ما تكون نهائية ، أي أن تنسيق الحاويات مع البيانات هو أنه بعد التعبئة والفهرسة ، لن تتغير البيانات الموجودة في نفس مجموعة البيانات مرة أخرى. على سبيل المثال ، ملفات الباركيه التي لا تتطلب التعديل.
بعد ذلك ، تجمع حشد من البيانات ،
الشيطانيين أو
محللي البيانات ، وفي البرامج المتخصصة ("أجهزة الكمبيوتر المحمولة" مثل Jupyter) بجمع الإحصاءات والمؤشرات ، إلخ. على الانترنت. يتم تفريغ هذه الإحصاءات من البحيرة في مكان ما إلى الخارج ، أو ببساطة تضاف معًا في شكل نفس الملفات النهائية لتجميعها لاحقًا.
النهج رقم 2. تدفق البيانات
بالنسبة للبيانات التي تصل في الوقت الفعلي وتحتاج إلى معالجتها بسرعة (أي ، دفق البيانات) ، تم تصميم حافلات البيانات أو قوائم انتظار الرسائل.
في البنية التحتية التي تحتوي على ناقل بيانات ، يوجد مولدات في طرف واحد ، والمستهلكون في الطرف الآخر ، وتتكون تدفقات البيانات نفسها من الأحداث.
يتم إنشاء المولدات ، ويقوم المستهلكون ، في الوقت الحقيقي أو القريب من الوقت الفعلي ، بتحليل الأحداث ، وتراكم بعض النتائج النهائية ، والتي يمكن أن تولد مرة أخرى أحداثًا تستهلكها المجموعة التالية من المجمعات عبر نفس الناقل ، وهكذا حتى يتم الحصول على النتيجة النهائية ، مطوية في مستودع النتائج النهائية.
يقودها أباتشي كافكا وتخزين سريع مثل Aerospike.
قضيتنا
لكن قضيتنا لا تنسجم مع هذين النهجين.
أولاً ، ليس من المنطقي بالنسبة لنا الاحتفاظ بمجموعة بيانات ، لأن أهمية مجموعة البيانات نادراً ما تتجاوز عامًا (لا يحتاج أي شخص إلى مسارات المستخدمين لعام 2016 في عام 2019) ، وفي كل مرة يحتاج العملاء إلى جزء لا يمكن التنبؤ به تمامًا من جميع البيانات المتراكمة. أيضًا ، نظرًا لحقيقة أنه بالنسبة لكل شريحة من السكان والفئة التي يتم فيها إنشاء القالب الخاص به ، ما زلنا مضطرين إلى أخذ القطعة المطلوبة فقط ، ودمجها في بحيرة مشتركة ليس له معنى كبير. من الأسهل الاحتفاظ بكل مجموعة بيانات شهرية في شكلها الأصلي - ملفات CSV في دليلها المنفصل. يتم الحصول على المسار إلى الملف ... / المزود / البلد / المنطقة / دون الإقليمية / السنة / الشهر / ملفات البيانات ، ويتم تحديد مجموعة فرعية ببساطة عن طريق قناع اسم الملف ، على سبيل المثال ، ... / Tamoco / UK / Greater_London / * / 2019 / {6 ، 7.8} / *.
ثانياً ، طبيعة مجموعات البيانات منفصلة وليست متدفقة. بالطبع ، يمكن للمرء ، بالطبع ، أن يحسب مباشرة بعض المؤشرات مباشرة في عملية التحميل على شبكة التخزين ، ولكن خرائط الحرارة النهائية لمنطقة موسكو ومنطقة موسكو المجاورة لن ترتبط بالخريطة الحرارية النهائية لمنطقة موسكو والمنطقة المدمجة ( نظرًا لحقيقة أن الكثيرين منهم يعيشون في المنطقة ويعملون في موسكو) ، وما زلنا لا نعرف مقدمًا المنطقة التي سنحتاج إليها. ربما لا موسكو ولا منطقة موسكو ، ولكن فقط مدينة 17. يعد محرك الاستدلال مكلفاً للغاية وحساب المؤشرات لجميع مجموعات البيانات.
نتيجةً لذلك ، يتعين علينا تحديد مجموعة فرعية من مجموعات البيانات المتراكمة بسرعة ، ونشر مزرعة للحوسبة تتناسب بسرعة مع الطاقة ، وتنفيذ عملية حسابية فريدة ولكن موحدة بسرعة ، وإخراج النتيجة ، ... وربما لن نعود مرة أخرى إلى مجموعة فرعية أو إلى مزرعة بهذا الحجم ، وليس إلى القالب. ولا يمكننا مطلقًا الاحتفاظ بمجموعة أداء مضبوطة جيدًا على أجهزتنا الخاصة ، والتي ستغطي احتياجات جميع مشاريعنا من الأصغر إلى الأصعب ، نظرًا لأنها مختلفة جدًا.
لا أعتقد أننا فريدون للغاية. في المحادثات مع الزملاء ، تظهر الحاجة إلى أجهزة الحالات
المتفجرة المماثلة بشكل منتظم ، ولكن هنا يبني الجميع العملية بطريقته الخاصة. عادة ، يتم إرفاق حلول الحالات غير القياسية إلى الناقل الحالي من النهج رقم 1 أو رقم 2 على الجانب ؛ تتكون عمليتنا بالكامل من مشاريع خاصة ، لدينا جميع المهام مثل "انفجار".
حسنا الان لمدة عامين وبنس واحد ، تمكنا من التوصل إلى مجموعة أدوات لأتمتة عملي قدر الإمكان ، وهذا بالضبط هو ما سأقدمه للاستخدام العام في الجزء الثالث من قصتي. في غضون ذلك ، دعونا نتحدث عن التطور ، وجميع تلك الأخطاء والمشاكل ، وتصحيح وحل التي وصلنا إليها في عملية مستدامة من خلال التجربة.
النموذج الأولي في C # و PostGIS
بدأ كل شيء قبل بضع سنوات. اثنان من الرجال الأذكياء للغاية يدعى
أليكسي بولياكوف وأليكسي بولياكوف - لا تضحك ، إنهما تحملان اسماء
حقيقية ، ولكن من أنحاء مختلفة من العالم - عالم أحياء ومسوق ، قررا تطبيق الأسلوب من الأطروحة على السلوك الجماعي لمجموعات الخلايا في ثقافات الخلايا ، تم اختبارهما تجريبياً حتى الفئران ، إلى الإعلان والتسويق.
عملت على الناس.
ثم جاء مشروع Locomizer. أقول "مشروع" لأنه مثل بدء التشغيل مع
شركة ذات
مسؤولية محدودة لإبرام العقود ، ولكن ليس تمامًا. أعضاء فريقنا منتشرون في جميع أنحاء العالم ، ويعملون في أماكن ومكاتب مختلفة كعمال مستقلين أو خارجيين (وليس كل الوقت بدوام كامل) ، ونحن نستخدم خوارزمياتنا لعملاء مختلفين للغاية مع نماذج مختلفة من التفاعل عند استلامنا أو العثور على الطلبات. هناك اشتراكات ، ولكن المزيد من المهام لمرة واحدة خاصة.
ولكن هذا هو الآن. وقبل بضع سنوات كان كل شيء أكثر فوضوية. الذي كتب أول تطبيق للبرنامج لحساب السرعة ، وأنا عموما لا أعرف. (إذا كنت تعرف فجأة هؤلاء الأبطال المجهولين ، فقل لهم مرحباً.) في نهاية مقالي الأخير عن مهنة مبرمج في مدينة معينة ، كتبت حرفيًا ما يلي: "جئت لأتحدث إلى المكان الذي أعمل فيه الآن ، وأبلغت PM من الحد الأدنى بذلك المشروع جهنمي. Nichosi. مرة أخرى ، GIS ، تعتمد الحسابات فقط على MapReduce (وأريدها على Spark) ، والخرائط على ArcGIS ، وكل هذا يدور في السحب التي لا يمكن لأحد أن يبتكرها. في رأيي ، خيار رائع! "- في تلك اللحظة كان الأمر كذلك بالفعل ، ولا يمكنني سوى استعادة المرحلة الأولى من تطوير المشروع في الكود من ذكريات
mitra_kun ، التي ظهرت في المشروع قبل عام واحد فقط.
تمت كتابة الاستدلال البدائي لمعالجة مجموعات البيانات الأولية بلغة PHP و Python و C ++ ، وتم تنفيذ الحساب الرئيسي لسرعة خريطة الحرارة بواسطة برنامج في C #.
عملت مثل هذا:
- أولاً ، نقرأ السلسلة مباشرةً في الصفيف من ملف مجموعة البيانات.
- تشغيله foreach'em ، بناء جدول التجزئة على polzakz.
- قاعدة POI هي جدول حرفي في قاعدة بيانات PostgreSQL مع حقول PostGIS من النوع GEOMETRY ، ولحساب المسافة بين كل إشارة مستخدم وكل نقطة مهمة ، يتم سحب وظيفة ST_DISTANCE من خلال مساحة تخزين صغيرة ، وتتم إضافة النتيجة إلى جدول تجزئة مع مفتاح لكل مستخدم.
- ثم نقوم بالتنبؤ على الطاولة بتراكم نتيجة درجة الاهتمام لكل مفتاح في الصفيف.
- مرة أخرى ، مجموعة ، لكل فئة.
- بعد انتهاء العملية الحسابية ، والتي تستغرق كلياً من ساعتين إلى أسبوع من الوقت ، تتم إضافة النتيجة إلى ملف CSV ...
- ... ثم لا تزال تتم معالجتها يدويًا وتراكبها على الخريطة وتصورها في ArcGIS .
من الواضح أن الحد الأقصى لوحدة التخزين التي يتم معالجتها محدود بواسطة الذاكرة المتوفرة على الجهاز ، وأن سرعة الاستعلامات الفردية لقاعدة البيانات تتسبب في حدوث إنذار معين.
النهج الأول ل Hadoop MapReduce
تم حساب شيء ما على النموذج الأولي المحلي ، وتم اختبار مدى ملاءمة العلاجات المطبقة لإعداد مجموعات البيانات وبناء خرائط الحرارة ، ونشأ سؤال حول كيفية وضع العمل على الدفق. حسنًا ، من المهم عدم التعامل مع غروب الشمس يدويًا ، ولكن استخدام قدرات بعض الأنظمة الأساسية ، ويفضل أن تكون مكتوبة بواسطة الحيتان الصناعية ، والتوسع على الأقل إلى الحد الأدنى.
كما قلت ، فإن منصة معالجة البيانات الكبيرة القياسية هي نظام Hadoop البيئي. مجموعة كبيرة من المكتبات غير المتجانسة ، بما في ذلك نظام الملفات الموزعة ، والقواطع للمهام المتوازية ، والتجريدات الملائمة نسبياً عبر تصغير الخريطة ، ومحركات تنفيذ الاستعلامات ، وحتى مجموعة كبيرة من الأشياء لتحليل البيانات. وكل هذه البنية التحتية للبرامج متاحة في السحابة من مختلف البائعين في شكل حزم متكاملة ، وسيتم تشغيلها تلقائيًا ، لكن المزيد حول ذلك لاحقًا.
حسنا جوجل ، ابحث عن Hadoop. لقد اتخذ أسلافي النموذج الأولي ، وأعدوا كتابة الحساب الرئيسي من C # إلى Java ، واستبدلوا حرفيًا كل التباين بـ Hadup Mapper و Reducer ، واتخذوا جميع الخطوات لإعداد مجموعات البيانات وإثرائها في أدوات مساعدة منفصلة بلغات البرمجة النصية للتطور بشكل أسرع ، وذلك بسبب ظهور مختلف بدأت خوارزميات العملاء تتطور بنشاط. بشكل منفصل ، بدأنا في كتابة واجهة خلفية لـ Web UI في Spring (ليس هو الحل الأفضل ، إذا لم تكن هناك خبرة سابقة في تطوير Java ، فمن الأفضل أن تكتب بلغة PHP) ، مع مقدمة على Node.js مع تكامل الخريطة من ArcGIS.
رفعوا "مجموعة كبيرة" من Hadoop على خمسة أجهزة افتراضية في Microsoft Azure لهذه الحالة. لماذا أزور أولاً ، بالنسبة للشركات الناشئة هناك خصم كبير في السنوات القليلة الأولى. ثانياً ، تم نشر ArcGIS Desktop for Windows لتصور الخرائط بالفعل في هذه السحابة.
تم نشر مجموعة Hadoop يدويًا ، وليس من خدمة Azure HDInsight المقابلة ، والتي كان من الصعب تكوينها.
على كل من آلات الكتلة ، رفعوا Postgre + PostGIS (قرار مشكوك فيه إلى حد ما ، لأن MR والقاعدة بدأوا في التنافس على المعالج) حتى لا يذهبوا مسافات إلى خادم منفصل. لقد صنعنا نصًا صغيرًا مبعثرًا للنسخ المتماثلة لقاعدة بيانات النقاط المهمة عبر عقد الكتلة.كان المشروع لا يزال نموذجًا أوليًا ، وكان أكثر تقدمًا بقليل. لا يزال PostGIS يستخدم بسبب ظهور geofencing ، ولم يعرف الرجال بعد كيف يمكن تنفيذه بأقل تكلفة ممكنة. شعرت أن كل شيء كان بطيئًا بشكل رهيب ، وتجاوز عدد الخطوات التي يجب القيام بها يدويًا اثنتي عشرة ونصفًا.في هذه اللحظة ، كنت مهتمًا باقتراح من بلدة غير معروفة على نطاق واسع في بلدتنا الصغيرة ولكن في مجال تكنولوجيا المعلومات (يوجد أكثر من سبعة عشر مكتبًا في إيجيفسك مع موظفي التطوير ، حيث يعمل حوالي ثلاثة آلاف مبرمج) ، وهو مكتب يحمل اسمًا عامًا تمامًا "تكنولوجيا المعلومات الروسية" فجأة ، بدون سبب ، تطلب الأمر من مطور جافا الأقدم خبرة واسعة في النشر والتشغيل الآلي ، وعلى الأقل سمعت عن البيانات الكبيرة والسحب من أسفل أذني. حسنًا ، بحلول الوقت الذي سمعت فيه القليل عن السحب والبيانات الضخمة.بالنسبة لكل شيء آخر ، لدي خبرة أكثر من كافية :( لذلك ، فإن أول ما قلته عندما رأيت الكود وحالة العمليات كان في أفضل تقاليد Artemy Lebedev ، بصوت عالٍ وكثير. لن أكرر ذلك.حسنًا ، إذا كانت الشفرة والعمليات ذات جودة مفهومة ، فمن المؤكد أن لديهم مكانًا للقيام بالتحسين. بالنسبة للمبتدئين ، يمكنك على الأقل إرسال طلبات إلى PostGIS واحدًا تلو الآخر ، ولكن على دفعات ، حوالي 5000 نقطة في المرة الواحدة. تعد قواعد البيانات ، كقاعدة عامة ، مثالية لتحسين دقة المنتجات الديكارتية. يقال - تم القيام به ، تمت إعادة كتابة التخزين مع استدعاء ST_DISTANCE بطريقة لإرجاع مجموعة كبيرة على الفور لمجموعة من النقاط ، ومن البداية تم تسريع الحساب فورًا 40 مرة ، لأنه لم تعد هناك حاجة الآن إلى إنشاء اتصال بقاعدة البيانات كثيرًا ، فهناك العديد من المؤشرات على الهندسة في الجدول مع POI بدأ العمل مع شعور كبير.صحيح ، تسلل خطأ مقصور على فئة معينة إلى الحساب مباشرةً ، نظرًا لحقيقة أن النموذج الأولي لم يتم نقله بشكل صحيح من C # إلى Java. غاب الرجال عن نقطة متغير واحد مهم ، ولم تصلهم المعارف التقليدية الرسمية على النموذج الأولي على الإطلاق ، وخسرت في مكان ما على طول الطريق. ثم استعدنا جميع الخوارزميات من أوصاف مجزأة ، ولكن هذا كان بالفعل في وقت لاحق. ومع ذلك ، فإن هذا الخطأ ككل لا يفسد نتيجة الحساب ، بل إنه يقلل من تباين خريطة الحرارة.لكنك لن تحصل على الكثير من الأداء من MapReduce ، لأن المصمم يقرأ البيانات من HDFS ويكتبها مرة أخرى ، ويقوم المخفض التالي في السلسلة بنفس الطريقة ، وهكذا حتى تكتمل كل الخطوات. كما أنه من غير المريح إدارة عملية متعددة الخطوات ، خاصةً إذا كانت الخوارزمية لها فروع بسبب الإعدادات. الخوارزمية بأكملها عبارة عن قرص صلب ، وإذا كنت ترغب في إعادة ترتيب الخطوات بطريقة ما ، فيجب عليك نقلها إلى وحدات منفصلة باستخدام المشغِّل الخاص بك ، والتفاف نوع من المنطق في الخارج.حسنًا ، لا يزال سحب PostGIS من داخل الحساب ، حتى لو قمت بتكرار قاعدة البيانات على كل عقدة من الكتلة ، فكرة مؤلمة للغاية.ظهور CI و Spark
- أتمتة ذلك! - بلدي الثاني الكبرى البند الفائدة rofessionalny بعد enterprayznogo ن rogrammirovaniya على الضفدع ... ورفض. ثانيا - هو ن itstsa، ن ASTA و ن udingi، ثم ترك يكون هناك ثلث - هو ن توقف ن العمليات والتشغيل الآلي الخاصة بهم. (I مثل shef- ن اوفار مثل أن يكون كل شيء في ص . علامة التصنيف # ن echenki).العمل اليدوي يحمل الكثير من المخاطر. الأشخاص غير موثوق بهم وغالبًا ما يرتكبون أخطاء ، حتى لو قاموا بنفس الشيء ، لذا فمن الأفضل لك قضاء بعض الوقت في إضفاء الطابع الرسمي على التدفق الكلي للمشروع وكتابة برنامج نصي لن يفشل عند استدعاء الأداة المساعدة لنسخ مجموعة البيانات من وحدة التخزين طويلة الأجل إلى شبكة الإنترنت ، ولن يخلط ترتيب الخطوات ، من الاستمرار في المشي أشعل النار.كان المشي المشطوب مجرد أخطر مشكلة يجب حلها أولاً. أولاً ، قمت بنشرها إلى teamCity افتراضية صغيرة منفصلة، وقم بتكوين التجميع مع تشغيل جميع الاختبارات بحيث تكون الأداة التي تم التحقق منها دائمًا في متناول اليد ، ولا يلزم طرحها على نظام المجموعة يدويًا. كانت الخطوة الثانية هي كتابة برنامج التفاف لتشغيل مهمة MR واحدة مع مجموعة البيانات المحددة ومجموعة من المعلمات على الكتلة مباشرة من نفس TC ، مع النسخ التلقائي نفسه من مجموعات البيانات الأصلية إلى الكتلة ونتائج الحساب في مخزن النتائج.والخطوة الثالثة ، التي استغرقت الكثير من الوقت خارج العادة ، هي أتمتة نشر المجموعة نفسها ، وضبط معاييرها ، وبدء الحساب على مجموعة بيانات مدمجة في Azure Blob Storage. وفجأة ، كانت هناك مشاريع بدأت تضيع فيها مجموعة ثابتة من خمسة أجهزة افتراضية و / أو لا ينبغي خلط مجموعات البيانات الخاصة بها مع تفريغ الملفات القديمة على HDFS.أزور HDInsight هو في الواقعHortonworks HDP (راحة الأرض في سلام) ، وبعض إعداداته مصنوعة في واجهة برمجة التطبيقات ، ويمكن تسجيل بعضها فقط من خلال برنامج Ambari. قد يستغرق نشر مجموعة تعتمد على تحميل السحابة ما يصل إلى ساعة ، ويمكن أن تستغرق دورة التوليف ، أي التحقق من تأثير أي مجموعة من الإعدادات على أداء الكود ، يومًا كاملاً. يأكل الإصدار المحلي من HDP Sandbox في الجهاز الظاهري 11 غيغابايت من ذاكرة الوصول العشوائي ، ويطالبك بشدة على النظام الفرعي للقرص ، لذلك حتى تصحيح الأخطاء المحلي غير سار للغاية ، وإعداداته تختلف قليلاً عن الإصدار السحابي. لقد أتيحت لي الكثير من الوقت للتجارب ، لكنني على الأقل اكتشفت كيف يعمل كل شيء ، وماذا أفعل إذا كانت العملية الحسابية معلقة فجأة في الوسط باستخدام OOM التالي ، لأنه من غير المريح أيضًا تحليل السجلات يدويًا.بينما كنت أتعامل مع HDP ، بدأ مبرمج آخر في توحيد المراحل المختلفة لإعداد مجموعات البيانات على Apache Spark. قام Spark بحل مشكلة كتابة / قراءة البيانات الوسيطة التي تحدث باستمرار بين خطوات عملية حسابية واحدة ، وبشكل عام ، تم تصميمها مع مراعاة جميع الأماكن السيئة في MR ، ويمكنها القيام بذلك عدة مرات خارج الصندوق. و RDD كسول سبارك هو شيء مفيد للغاية.في موازاة ذلك ، قمت بكتابة نصوص Azure Templates على PowerShell لتكوين عقدة الحافة لـ PostGIS - مثيل منفصل كثيف عالي الكعب في المجموعة ، مع مجموعة من النوى والذاكرة لتسريع الطلبات ، بالإضافة إلى مجموعة من الخطوات الأولية لإعداد مجموعات البيانات ، التي وضعت لأول مرة على قرصها المحلي ، ثم تحميلها في HDFS على الكتلة.لذا فإن رابط البرنامج النصي ، الذي اعتقد في البداية أنه سيعمل بشكل تفاعلي وفي وضع دفعي على TC كبناء منفصل ، تعلم تدريجياً تشغيل مزيج تعسفي من الخطوات على MR و Spark وحزم البرامج الأخرى التي لم نستخدمها من مجموعة HDInsight ، ولكن لا يزال مع المعلمات بدائية. ومع ذلك ، فإن نقل معلمات الإنشاء إلى مستودع تخزين مجاور مع مجموعة من ملفات .ini (لكل مكون من مكونات النظام الأساسي ولكل خطوة من خطوات العملية) ، والحفاظ على قوالب العملية في فروع هذا المستودع تبين أنها ممارسة ملائمة لا نزال نستخدمها.تقدم بالفعل. مع أتمتة روتين يدوي ، تم تقليل وقت التحضير للحساب أربع مرات ، ناهيك عن الأخطاء البشرية التي أصبحت أقل من ذلك بكثير. لكنه لم يحن بعد وقت الحساب نفسه.التقريب الثالث في GeoSpark
استغرق الأمر حوالي ستة أشهر. بحلول هذا الوقت ، تراكمت مجموعة من الأساليب البحثية التي تم تصحيحها واختبارها بشكل تدريجي ، بالفعل مع تطبيقات منفصلة على Spark ، وليس مع أي نصوص برمجية ، وتم تطوير بعض قوالب العمليات النموذجية. الآن كان من الضروري تحسينها.
كان المبرمج الثاني ، الذي لم يكن لديه خبرة سابقة في أي فريق أو مؤسسة ، يتصرف مع وحداته بشكل مباشر تمامًا - بعد الانتهاء من نقل أحد مجريات الأمور إلى سبارك ، قام ببساطة بنسخ المشروع بأكمله ، وبدأ في استبدال الخوارزمية القديمة بالخيار الجديد فيها. نتيجة لذلك ، عندما كان هناك ثمانية من هذه الوحدات المتوازية ، ولكل منها مجموعة متشابهة ولكنها مختلفة بعض الشيء ، وقليلًا من دلالات المكالمة الممتازة - وأيضًا الكثير من كود الخدمة المكرر - بدأت في طرح مشكلة أخرى. لمزيد من التعليمات البرمجية ، يتم إنفاق المزيد من الوقت على دعمها ، خاصةً إذا لم تتوقف عن التطور طوال هذا الوقت. وبسبب لصق نسخة ثابتة ، بدأت المعلمات غير المستخدمة وغيرها من القمامة تتراكم فيها.
بعد أن انتهيت من المشكلة الملحة المتمثلة في الأتمتة والتعامل مع تكوين المجموعات ، الآن يمكنني بالفعل تناول وحدات إعداد البيانات والاستدلال. بادئ ذي بدء ، أخذت كل الشفرة المكررة في مشروع كومنز منفصل ، تم توصيله كوحدة
فرعية فرعية ، وفي وحدات الحساب ، أصبحت الفوضى عدة مرات. قمت بتجميع قالب لإرشادي نموذجي ، وجاء بالفعل مشروع جديد منه ، دون الحاجة إلى استبدال أجزاء من التعليمات البرمجية ودون الأوساخ غير الضرورية في تاريخ الالتزامات. بدأت التنمية لتكون أسرع.
المشكلة الكبيرة التالية التي يجب هزمها جاءت من منطق حساب المنتج الديكارتي × إشارات النقاط المهمة.
مجرد نقل الدفعات نقله إلى قاعدة البيانات ، ولكن لا يقلل من عدد العمليات ، حتى لو كانت قاعدة البيانات تستخدم بشكل فعال الفهارس والاستعلام الأمثل. سيكون من المنطقي عدم التفكير في المسافة لتلك الأزواج حيث تتجاوز بوضوح الحد الذي نحتاجه. لكن كيف تتخلص من الأزواج بمسافة أكبر من العتبة دون حساب هذه المسافة؟
الإجابة:
تقسيم كل من الإشارات ونقاط الاهتمام على شبكة هندسية.
علاوة على ذلك ، فإن خريطة الحرارة تتكون بالفعل من شبكة من المضلعات. وإذا اخترت حجم خلية هذه الشبكة بالطريقة الصحيحة ، فبالنسبة لكل نقطة مهمة من المضلع المحدد ، من الممكن أن نحصر أنفسنا في حساب المسافات إلى الإشارات التي تقع في نفس المضلع ، والخلايا المجاورة لها ، وهذا كل شيء. يمكن التخلص من الباقي ؛ وسوف يقعون بالتأكيد خارج حدود الأهمية.
لدى Spark بالفعل أداة جاهزة للعمل مع الشبكات -
GeoSpark . بدأ المبرمج الثاني في استخدامه ، وظهرت العملية الأولية "سحب مجموعة البيانات على الشبكة". لكنها لم تتحسن ، تم استبدال مشكلة خطيرة بمشكلة خطيرة أخرى.
الآن هذه هي مشكلة "الذيل الطويل" - المستخدمون ، حيث يكون عدد الإشارات بالملايين. لا يوجد الكثير منهم ، ولكن إذا تراكمت في وسط المدينة ، حيث ترتفع نقاط الاهتمام ، وتتراكم هناك ، كما يحالفنا الحظ ، فبغض النظر عن كيفية
تقسيمك في الهندسة (على الأقل
Voronoi ، على الأقل
رباعي ) ، سيظل هناك المضلعات حيث يتجاوز عدد المقارنات مقدار معقول. لكن عليك أيضًا التحقق من المضلعات المجاورة حيث تكون الكثافة عالية.
وإذا نجحت 99٪ من الأقسام ذات المضلعات منخفضة التشبع في العمل بسرعة ، فإن 1٪ من محطات عمل Spark بالخلايا عالية الكثافة تستمر في التعلق بالنصر وتناول الذاكرة كما لو كانت فاقدًا للوعي وتفسد جميع أنواع التوت. يحاول Spark وضع كل شيء في الاعتبار ، وإذا كان هناك تباين قوي في حجم الأقسام في RDD ، فإن توليف كامل لاستهلاك الذاكرة ينتقل إلى الأسفل ، لأنه يجب القيام به من أجل الأكبر.
اتضح أن 99 ٪ من الحساب تم تسريعها مع التقسيم الهندسي لمئات المرات ، و 1 ٪ من الذيل الطويل خفضت التحسين الكامل إلى لا شيء تقريبًا.
بشكل عام ، حقق الانتقال إلى GeoSpark مكسبًا بمقدار خمسة أضعاف ، ولكن فقط على حجم المدراء التنفيذيين الذين كانوا عاجزين عن الذاكرة للغاية - وبالتالي ، المجموعات التي تحتوي على أجهزة افتراضية باهظة الثمن. باختصار ، تحول التقسيم الهندسي للبيانات الجغرافية عالية الكثافة إلى طريق مسدود.
وبعد ذلك كانت هناك سعادة في شخص مكتب التحليل في واحدة من أكبر شركات الاتصالات اليابانية. شركة فرعية صغيرة تعتمد على بيانات تحديد الموقع الجغرافي التي تم جمعها من قبل الشركة الرئيسية.
المحللين اليابانيين والهجرة من أزور إلى AWS
اليابانيون لديهم عقلية مثيرة للاهتمام. هم أنفسهم ليسوا في عجلة من أمرهم ، ولكن إذا تم إعطاء gaijin فقط لدغة إصبعهم ، يتم قطع كلتا يديه. أبدا إعطاء تواريخ محددة اليابانية! وإذا اتصلت ، فاخذ ثلاثة أضعاف العرض على الأقل. سيكون التنسيق طويلاً للغاية وبصعوبة في تنسيق الاختصاصات ، ولن يتدخل فقط الدقة اليابانية المشهورة ، بل وأيضًا الفرق في التفكير. ببساطة قد لا يتبقى وقت لتنفيذ النسخة النهائية من TOR.
مشروع التكامل مع "ابنة" الاتصالات اليابانية كادت أن تقتل مشروعنا. كانت الآفاق مشرقة لتصبح المزود الحصري للبيانات لسوق الإعلان الياباني المجنون ، والأعمال التجارية ... قليلاً ، يمكنني القيام به دون تعليق.
أولا ، لا أزور. AWS فقط ، المتشددين فقط.
ثانياً ، تم تعديل الواجهة لتلبية احتياجاتهم ، والتي كانت تتغير باستمرار في جميع أنحاء المشروع. أراد المسوقون من هذا المكتب دائمًا شيئًا لم يعرفوه هم بالضبط ، ولم يتمكنوا من التعبير عنه بالفعل ، وكان لا بد من إعادة بنائه عشر مرات في كل مرحلة ، وتغيير منطق الحساب للمؤشرات الجديدة التالية على الطاير.
في مرحلة ما ، شعرت بالخوف ، وقمت بمجموعة من "العمليات الأولية" - حوالي 15 إجراءًا بدائيًا على RDD مع استدعاء الأساليب الأساسية مثل الصلات والرسمات ووضع القيم الافتراضية وتلخيص قيم الأعمدة - وغيرها من العمليات الصغيرة - بسرعة تغيير منطق سلسلة الحساب ، كما لو كانت مجموعة من عبارات SQL.
(العادية Spark SQL غير قابلة للتطبيق في حالتنا بسبب حقيقة أنه لا يوجد كتابة صارمة ولا مجموعة صارمة من الحقول. في مجموعة البيانات ، في أي وقت يمكنك إضافة أكبر عدد ممكن من الحقول الإضافية ، ويتغير أثناء تدفق العملية من الصعب جدًا وصف البيانات الوصفية في ظل ظروف متغيرة باستمرار.)
كانت المهمة الرفيعة المستوى هي: اختيار منطقة تعسفية في اليابان ، وبناء خريطة حرارة لفترة تعسفية من الزمن باستخدام مجموعة عشوائية من الفئات مع مجموعة كبيرة من المؤشرات الخاصة بالمدافن. أي نوع من المؤشرات ، وكيفية حسابها - العميل نفسه لم يفهم هذا حقًا.
مجموعة بيانات الاختبار (أي ، صغيرة) التي تحتوي على إشارات المستخدم للفترة 2016-2017 ، والتي اضطررنا إلى تطوير التكنولوجيا بها ، هي 5 تيرابايت من البيانات ، 14000.000.000 سجل. في طوكيو وحدها ، هناك عدة ملايين من النقاط المهمة ، وفي الشبكة في منطقة هوكايدو ، يوجد 1600000 خلية.
وينبغي اعتبار البطاقات لجميع الفئات الألفين لكل واحدة من 47 لغة يابانية مثالية "على الطاير" ، لأنه ينبغي بيعها كخدمة سحابية.
مهمة عظيمة لكسر الدماغ. في مكان ما ثلاثة أو أربعة أوامر من حجم أعلى من قدراتنا ثم من حيث "سرعة الحساب" و "حجم البيانات".
بعد أن أصبحنا حزينين ، قررنا مع ذلك إجراء حساب مسبق لكل منطقة (بفضل آلهة الشنتو ، لم يكن اليابانيون بحاجة إلى توحيد المناطق) وشهرًا حتى تم بناء خريطة الحرارة وفقًا للدرجات المعدة مسبقًا. لا تدع في الوقت الحقيقي ، ولكن بضع دقائق أو عشرات (وسط طوكيو) دقائق. استغرق الحساب المسبق عدة أشهر مع مجموعات من 25 من أقوى الأجهزة الافتراضية المتاحة في منطقة طوكيو AWS.
ولكن من أجل تشغيل AWS ، كان عليك أولاً إعادة كتابة الأتمتة تحت واجهة AWS. والسحب المختلفة ، على الرغم من أنها تقدم خدمات مشابهة بشكل مشابه ظاهريًا ، إلا أنها تختلف داخليًا تمامًا. من الجيد في هذه اللحظة أن يكون PowerShell قد وصل بالفعل إلى الإصدار 6 من مرشح الإصدار ، وأن البرامج النصية للربط Azur لنشر الكتلة وتشغيل الحساب يمكن نقلها وتشغيلها بجرأة على Linux TeamCity (لأن نشر الخوادم على Windows في AWS يعد فكرة ). بتعبير أدق ، لا تقم بمنفذ ، ولكن افتح برنامج نصي موجودًا على شاشة واحدة ، واكتب تطبيقًا موازيًا لسحابة أخرى في الثانية.
وأيضًا ، تعد AWS أقدم بكثير ، وبالتالي فهي قديمة أكثر من Azure ، وهي معمارية ، وهناك الكثير من الأعمال اليدوية لتكوين المستوى الأدنى للبنية التحتية. ويضيف المزاد المحلي لبيع موارد الحوسبة صداعًا عندما لا يكون لديك السيارات ذات الحجم الصحيح بالسعر المطلوب ، ولا يخصص العميل ميزانية لحساب السعر الكامل.
ولكن النظام البيئي Hadoop نفسه في التجسد الأمازون - EMR - هو شيء أقرب إلى الفانيليا ، والعمل معها أسهل من HDInsight. حسنًا ، على الأقل أصبح الأمر أسهل.
ولكن ليس مع S3. هنا حصلت مشكلة من حيث لم ينتظروا. S3 له حدود غير موثقة. على سبيل المثال ، في مجموعة واحدة لا يمكن أن يكون هناك أكثر من 110000000 كائن تقريبًا ، لأنهم في مكان ما في الأمعاء العميقة لواجهة برمجة التطبيقات يقومون بفرز المفاتيح بترتيب معجم لكل طلب (كل!) ، ولا يسمح المخزن المؤقت المخصص لذلك بالفرز خطوط أكثر ، خاصة إذا كانت طويلة. لتسريع الحساب ، لم ندمج الأقسام في النهاية ، وفي مرحلة ما وصلنا إلى هذا الحد ، وبعد ذلك توقفت العملية ببساطة.
وفقًا للعقل ، يجب أن يتم الدمج ، وهناك أيضًا أداة - الأداة المساعدة s3-dist-cp ، لكن استخدامها عبارة عن صداع منفصل. كتب الحيوانات المفترسة للأجانب فائدة بالتأكيد ، فهي تتصرف بطريقة عكسية. وله عيب فادح - تحت الملف المدمج ، تحتاج إلى مساحة كبيرة على HDFS مثل كل الملفات الأصلية. ودمج عشرات الآلاف من ملفات الأقسام من مئات البايتات إلى عشرات الميجا بايت في الحجم ، موزعة على مجموعة من 25 جهازًا ، ستستمر فترة طويلة جدًا.
ومع ذلك ، بالفعل مع وجود مليون كائن في المجموعة ، يبدأ S3 في نقل الطلبات إليه بهدوء. وفي ظروف الاتساق في نهاية المطاف ، تكون هذه كارثة بشكل عام - قد تنهار سبارك ، دون انتظار المكتب التالي ، العدد المتفق عليه من المرات. هناك حل - استخدم الإضافة الأمازون EMRFS المملوكة ، لكنه يعمل مع DynamoDB ، وهذا شيء مكلف للغاية. ومع حدودها الخاصة على عدد الطلبات في الثانية الواحدة.
باختصار ، في ظل ضيق الوقت ، قررنا العودة إلى النظام الثابت - نشر مجموعة دائمة على مثيلات صغيرة الحجم (وإن كانت باهظة الثمن ولكنها أرخص من DynamoDB) ، ودمج جميع تيرابايت مجموعات البيانات الأصلية والمحسوبة في HDFS عليها ، وقراءة البطاقات محليًا.
ولكن تطور الحبكة التالية كان الطلب الياباني على التحول من الشبكة سداسية المتولدة إلى
شبكة اليابان - وهي الطريقة القياسية للتقسيم الجغرافي مع الخلايا المستطيلة التي تعتمد فقط على إحداثيات النقطة. شيء جيد للغاية ، لأنه يسمح لك بالتخلي عن الخطوة الثقيلة الحسابية المتمثلة في "سحب الإشارات على الشبكة".
العيب هو أن شبكة اليابان مش لا تنطبق إلا على اليابان والأقاليم الجزرية التي تدعي تاريخيا أنها ، ولكن ليس على بقية العالم. ولكن على الأقل بالنسبة لليابانيين ، أصبح من الممكن التخلي عن GeoSpark البطيء ، وتقسيم الإشارات بالتساوي دون الرجوع إلى هندسة خارجية. ومع رحيل "الذيل الطويل" ، تسارعت الحسابات مرة أخرى على الفور مرة أخرى في الساعة 10.
من المؤسف أن هذا قد حدث بعد أن اكتشفنا جميعًا السداسي ، وقضينا الكثير من المال والوقت سدى. يجب إلقاء مجموعة تحتوي على تيرابايت من مجموعات البيانات المعدة.
وعلى أي حال ، في مكان ما في منتصف العمل ، لا يزال اليابانيون يطلبون تحويل البنية التحتية بالكامل من حساب AWS إلى آخر. كما لو لا تهتم بكل العمل المنجز على الإعداد. حسنًا ، لقد تمكنت من البرمجة النصية إلى قالب CloudFormation بحلول وقت الانتقال ، وبالتالي فقد تمت عملية الترحيل بسلاسة إلى حد ما.
وباعتباره الكرز الأخير على الكعكة ، قرر اليابانيون أخيرًا أن الجبهة لم تستسلم لهم ، وسيقومون بسحب الحسابات يدويًا بناءً على طلب عملائهم ، لذا نشكرنا على الخوارزميات (لأول مرة قمنا بتوثيقها جميعًا بالتفصيل - ووجدنا بعضًا منها) الأخطاء) ، والآن. حسنا ... حظا سعيدا وأراك لاحقا.
بررر. أتذكر هذا المشروع برعب وقشعريرة.
Ash Nazg Durbatuluk، Ash Nazg Gimbatul، Ash Nazg Trakatuluk، Ag Burzum Ishi Krimpatul !!
ولكن من الإيجابية ، بالإضافة إلى توثيق جميع الخوارزميات ، كانت هناك أيضا تحسينات عامة.
لقد تعلمنا طالبًا في Java Junior ، وأجرى دراسة لمجموعة من المكتبات الجغرافية ، ونتيجة لذلك تمكن أخيرًا من اختيار المكتبة المناسبة وإلقائها خارج بيئة PostGIS.
المحاولات السابقة كانت فاشلة بسبب ضعف الدقة. في دائرة نصف قطرها ثلاثة كيلومترات ، يعطي Haversins خطأً ملحوظًا بالفعل بالنسبة لنا ، وكانت معظم المكتبات التي حاولنا أن نأخذها من البداية رديئة في خطوط العرض شمال سان بطرسبرج ، ونتيجة لذلك ظهرت ثقوب أو تداخل مزدوج في الشبكة. ونحن الفنلنديون عملاء متكررة ، لذلك من الأهمية بمكان أن يعمل كل شيء بشكل صحيح في خطوط العرض الخاصة بهم.
إلى أن نتوصل إلى أننا نحتاج إلى lib مع geoid عادي (ويفضل أن يكون ذلك في PostGIS ، WGS84) ، فإن النتائج لا تتفق مع النتائج المتوقعة. ولكن بعد التبديل إلى GeographicLib ، تم التخلص من عنق الزجاجة في شكل اتصالات Postgre ، وتم تسريع المرحلة الأخيرة من حساب السرعة 40 مرة. غادر Golovnyak مع التكوين الإضافي لمثيل RDS منفصل تحت القاعدة وتحميل تفريغ مع POI فيه ، والتي انتقلت إلى مجموعات البيانات المعتادة في S3. التوحيد!
في الوقت نفسه ، اكتشف الطالب نفسه وأصلح الخطأ الذي تسبب في ظهور البطاقات بشكل أكثر هدوءًا مما كان عليه في الواقع. حسنًا ، عندما تكون هناك مهمة دون حدود زمنية ، أحسد الطلاب.
نقطة أخرى مهمة. مرة واحدة ، للمرة الألف ، نظرت إلى البرامج النصية الملزمة التي تسمي وحدة سبارك واحدة تلو الأخرى ، فكرت ، لكن ما نوع الشيطان الذي نستخدمه في قصر الدائرة؟
لماذا احفظ النتائج الوسيطة في كل مرة في S3 أو HDFS ، إذا كان من الممكن ببساطة إعادة توجيه RDD النهائي للوحدة السابقة إلى إدخال التالي في السلسلة. لم يكد يقول من فعل ، تم كتابة MetaRunner في بضع ساعات. ساعد وجود المشاعات كثيرًا في هذا الأمر ، فقد تم توحيد الوحدات إلى حد ما بحلول ذلك الوقت ، خاصة وأن معلمات كل وحدة من الوحدات كانت موجودة بالفعل في نفس المهام. مع وجود بادئات رئيسية تتوافق مع أسمائها.
يتم تقديم انتباهك مع مخطط كتلة لخريطة (الخطوة الأخيرة قبل إصدارها في المقدمة ، ولكن ليس الإصدار النهائي) ، مكتوبة على العمليات الأولية:
إذا تخلصت من 24 مكالمة وسيطة لـ HDFS ، وبالتحديد يتم تسريع هذا الحساب بحوالي 50 مرة.
ولكن ماذا لو قمت بإضافة دعم متغير لقالب العملية بحيث لا تضطر إلى تجديد المهام. كل مرة تقوم فيها بتغيير المعلمات في متجر العقارات؟
- الرماد Nazg! صرخت. نظر الزملاء إلى بعضهم البعض في حيرة. المتأنق له سقف بسبب هؤلاء الناس اليابانيين ، لكن حسنًا ، هذا يحدث.
"Ash nazg ... burzum-ishi krimpatul" ، لقد تذمرتها (لم ينجح الأمر جيدًا) ، وذهبت إلى رئيس الوزراء لمناقشة دمج جميع الأدوات الخمسة عشر (عدد الاستدلال والمرافق الإضافية كان ينمو تدريجياً) في وحدات الحساب في مستودع واحد.
إذا قمنا بقص الدائرة بين الوحدات مع بعضها البعض ، فلا ندخل بعد الآن مع بطانة جميع JARs الفردية في مسار الفصل من الشرارة ، ودع المجموعة الكاملة من منطق Locomizer الحاصل على براءة اختراع (وعملياتنا المساعدة) مجمعة في JAR سمين واحد. في نفس الوقت ومحليا ، سيكون من الممكن الآن تشغيل ، دون كتلة. والأهم من ذلك ، يمكن نقل منطق تحليل المهام. inini من روابط PowerShell إلى كود جافا ، حيث يكون استبدال المتغير أسهل بكثير.
الزملاء الذين يتنهدون حول الاقتراح الداعي إلى تسمية مشروع "حلقة القوة الكلية" ، - حلقة واحدة - ولكن القليل من الرثاء الصحي لن يضر.
بعد أن انتهزت لحظة الجولة التالية من التنسيق اللامتناهي للمعارف التقليدية على الجبهة ، جمعت كل الوحدات في كومة. Maven هي أداة متقدمة لحل التبعيات في مشروع متعدد الوحدات ، لذلك اتضح لتنظيف الأجزاء الأخيرة من التعليمات البرمجية المكررة ، وتوحيد إصدارات جميع المكتبات ، وخيارات البناء للبيئات المحلية والسحابة. علاوة على ذلك ، تظل كل وحدة في المشروع الفرعي الخاص بها ، ويمكن لمؤلفها العمل عليها بشكل مستقل تمامًا ، دون التدخل في الباقي.
بالمناسبة ، أنا أعتبر مثل هذا النهج مع بلورة التجريدات وبناء نوع من الهندسة المعمارية من مجموعة موجودة من الكيانات المتجانسة أكثر من مجرد محاولة لتصميم مستوى مجردة مقدمًا وتنفيذه في مهام معينة. بدون ممارسات وأنماط الاستخدام المعمول بها ، من غير المجدي تصميم بنية - لا يمكن توقع جميع الحالات مسبقًا ، ويمكن أن تختلف خيارات سلوك مستخدمي النظام جذريًا عن أفكار المصمم.
باستخدام المنطق الموحد لمعالجة المعلمات ، كان من الممكن عمل نموذج كائن موحد متميز لتكوين الوحدة النمطية ، وإجراء اختبارات طبيعية على صحة واتساق تكوينات الوحدات النمطية مع بعضها البعض داخل نفس العملية.
هذا مهم بشكل خاص مع مجموعات البيانات بتنسيق CSV - التحكم في عدد الحقول وترتيبها في كل سجل RDD ، وكذلك صحة نقل مجموعة البيانات نفسها من إخراج وحدة نمطية واحدة إلى إدخال عدة وحدات لاحقة ، كل ذلك على جانب الاتصال. وإذا كانت هناك نقطة تحكم واحدة ، فيمكن فعلها جيدًا بالفعل.لماذا لا نرتفع ونعمل مع RDD وليس إطارات البيانات؟ لنفس السبب أننا لا نستخدم Spark SQL. لكن بالإضافة إلى ذلك ، فإن التنفيذ على Spark هو المرحلة الأخيرة والأخيرة من الكود ، والتي تبدأ بورق أبيض ، يتم تصحيحها بالكامل في Python ، وعندها فقط يتم تحسينها في بضع خطوات إلى الإصدار الأكثر إنتاجية. وكلما اقتربنا من البدائية للمكتبة الأساسية ، عادة ما يتم تشغيل الرمز بشكل أسرع.
... إذا نمت أيدي المطور من كتفيه ورأسه مشرق. من الناحية النظرية.
اتضح أنه في ظروفنا ، يكون من الأسهل بكثير قيادة خط CSV الأصلي في شكل نص أصلي Hadoup مضغوط (تحت الغطاء هو مجرد مجموعة من البايتات) ، ووصف فقط تلك الأعمدة التي تعرفها العملية الحالية وفقط لها. أيضًا ، وفقًا لنتائج التجارب ، تعطي إطارات البيانات مقدارًا أكبر من الحمل لاستهلاك الذاكرة من الحاجة إلى تحليل ملف CSV عند إدخال كل عملية ، والضغط مرة أخرى على النص عند الإخراج. حسنًا ومع ذلك - من المهم بالنسبة لنا الحفاظ على القدرة على تقسيم RDDs الوسيطة يدويًا بعد كل خطوة ، لأن مجموعات البيانات الجديدة من المتجر يمكن أن تختلط معها (هذا مرئي بوضوح في الرسم التخطيطي) ، لذلك لا يزال عليك النزول إلى مستوى واحد ، بغض النظر عن الطريقة التي ترغب في البقاء بها عند المستوى ورقة بيضاء المنطق.ولكن في الكود "ذي المستوى المنخفض" في Java ، هناك إيجابيات أيضًا. على سبيل المثال ، إذا وصفت معلمات التشغيل (بالإضافة إلى RDDs المتوقعة والمنشأة) في البيانات التعريفية ، يمكنك تلقائيًا إنشاء كل من التوثيق ومثال التكوين ، وعدم كتابتها بعد الآن يدويًا. وستكون الأرصفة ذات صلة دائمًا ، بعد كل بناء.ملف التكوين task.ini نفسه ، من مجموعة غير متجانسة من المعلمات لكل وحدة ، تحولت على الفور إلى برنامج في نوع من لغة البرمجة التعريفي. ليست جميلة جدا ، ولكن داخليا منطقيا وقراءة الإنسان نسبيا. لا يمثل الانتهاء من الأمر حتى DSL الحقيقي باستخدام بناء جملة خاص به مشكلة ، لكنني لم أفعل ذلك بشكل غير ضروري. لكن بعد ذلك بقليل أضاف وجهة نظر إلى JSON للجبهة المستقبلية مع محرر مرئي.تلقت عملية قصيرة الدائرة ، في المتوسط ، ثلاث إلى خمس مرات أخرى أسرع من سلسلة من المكالمات الفردية لوظائف Spark.ليس مائة مرة ، لأنه الآن ، في إطار وظيفة Spark نفسها ، يمكن خلط خطوات مهام التعقيد الحسابي المختلفة وتشبع البيانات. نتيجة لذلك ، فقد الضبط الرفيع لمعلمات الكتلة لكل جزء من أجزاء عملية متعددة الخطوات أي معنى عملي. ولكن تدريجياً ، وبالنسبة لهذا الخيار ، تم العثور على بعض الأنماط العامة التي مكنت من تحديد الإعدادات المسبقة لحجم الكتلة بناءً على حجم مجموعة البيانات الأصلية والعدد الإجمالي للخطوات في قالب عملية المعالجة فقط.لتلخيص هذه المرحلة ، بحلول نهاية عملنا مع اليابانيين ، لدينا بالفعل أدوات مطورة:لكن ما لم ينجح هو الجبهة. واجهة تعامل الويب Locomizer Web UI القديمة عفا عليها الزمن بشكل يائس ، لم نتمكن أبدًا من إنهاء اليابانيين الجدد إلى حالة عقلانية قبل أن يتخلوا عنها تمامًا. نعم ، ورمز الواجهة الخلفية لواجهة المستخدم هذه ، المكتوبة مع قدمي الخلفية اليسرى في ليلة مظلمة في شهر أكتوبر ، لم أستطع التمشيط حتى النهاية بسبب الحجم الكبير.الأمثل و geocatarsis مع اوبر H3
بعد الزفير ، عدنا إلى المشاريع الخاصة. المزاج بعد اليابانيين كان ، بصراحة ، كان الفريق بأكمله جيدًا جدًا.لكنني تخلصت أخيرًا من الحاجة إلى الاحتفاظ بنسخة احتياطية في المقدمة مع نبعها Bogomersssky ، holm ، holm ، الربيع. (هذا هو رأيي الشخصي. EE ، أنا لا أحب أقل من ذلك بقليل ، لأنه يحتوي على قدر أقل من التوحد والافتراضات الضمنية ؛ لذلك لا يهم في المقام الأول ما هو فظيع المشروع هو كتابة RESTs).كان هناك وقت للنظر داخل كل وحدة مع إدمان.— , . , , , . - . — . , — .
ليس هذا لأنني كنت أبحث عن كود زملائي عن غير قصد. كل شخص فقط يشارك في المهمة المعطاة له ، وبينما يتم تنفيذها من خلال النتيجة المرغوبة ، لا تتدخل مع المطور الذي يقوم بعمله. إذا كانت الخوارزمية تعمل بشكل صحيح ، وهذا ما تؤكده الاختبارات ، فسيكون كل شيء على ما يرام. وفقًا لسرعة العمل ، - يكون مقبولًا أو غير ذلك - يتم اتخاذ القرار بواسطة رئيس الوزراء.لا أتدخل حتى أتعرف على المخاطرة العالية للحصول على مزيد من الدعم في القرار الذي اتخذه المطور عند تنفيذ مهمة جديدة. وسيتم الحفاظ على وحدات قابلة للتطبيق على مستوى عملي كما هو ، وبغض النظر عن الوحدات القديمة والقبيحة ، التي كُتبت في عهد القيصر غوروخ من قبل شخص ترك المشروع لفترة طويلة ، ولكنها ضرورية للعمل ، ستكون في مستوى عملي كما هو ، وبغض النظر عن رائحته. هذا يبدو ساذجًا ، لكني براغماتي ، وليس مثاليًا ، نتيجة العمل أهم بالنسبة لي أكثر من جمال الكود.لكن في بعض الأحيان يكون من الضروري توضيح الدين الفني حتى لا يدفن المشروع تحت ثقله.سبارك مكتبة عالية المستوى. يتيح لك إجراء عمليات على RDD بعدة طرق مترادفة تعطي نفس النتيجة ، ويمكن أن تحتوي كل طريقة على عدة قطع من الخيارات الممتازة القليلة. تحتاج إلى قراءة وصف كل منهم بعناية ، وإذا كان هناك شك في تسلق المصدر لفهم ما هو الأمثل في هذه الحالة. ستكون النتيجة هي نفسها ، لكن الفرق في سرعة حسابها يمكن أن يكون عدة مرات ، وإذا كان منطق بعض الأساليب البحثية يكشف عن مائة سطر من التعليمات البرمجية على Spark ، فأنت بحاجة إلى توخي الحذر بشكل خاص لاستخدام أكثر الطرق ملائمة لتحويل البيانات.اللغات عالية المستوى - فهي تجعلك تفكر بشكل تجريدي.ولكن في الوقت نفسه ، يجب أن يكون المطور على دراية بالمستوى المنخفض ، بغض النظر عن مقدار ارتفاعه إلى التجريدات العالية. على سبيل المثال ، يتم استدعاء أي lambda تم تمريره إلى طريقة .map () ، والتي يتم تخصيص الذاكرة فيها لبعض الكائنات الغامقة ، مرة أخرى لكل سجل وإعادة تخصيص الكائن نفسه ، ولا يحب أي من JVM الموجودة التخصيصات الغامقة المتكررة.وإذا كنت تفكر في دعم التعليمات البرمجية ، فسيكون من الجيد وجود أجزاء من الخوارزمية متصلة بالمنطق الداخلي ، ولكن في نفس الوقت معزولة تمامًا عن بعض قيم المعلمات ، قم بمعزلها عن بقية التعليمات البرمجية ، خاصةً إذا كانت هذه القطع في بداية الخوارزمية أو نهايتها. يمكن بشكل عام إخراجها في عملية منفصلة ، وفي نفس الوقت ستصبح الاختبارات ذات التغطية الكاملة لجميع الحالات أقصر.لقد كان من السابق لأوانه القيام بالتحسين ، ولكن الآن حان الوقت الذي حان الوقت ، ولقيت شهرين في مقدمة الغمر في أحشاء الوحدات الحسابية برمز التنميط الذي كتبه زملائي على مدار عامين.عندما غطست هناك ، كان لدى Ring Ring 29 عملية (تحتوي بعض الوحدات على أكثر من واحدة). عندما ظهر - 43 ، وأسرع من الأصل ، من بضعة في المئة إلى عشرات المرات. لكن الأهم من ذلك هو أن تلك العمليات التي تم اختناقها سابقًا ببيانات على أجزاء مكونة من 10000 عنصر ، تمضغ الآن بسهولة على أجزاء في مليون سجل. في بعض الأماكن ، اضطررت إلى التضحية بمرونة التعليمات البرمجية وقابلية قراءتها ، وفي بعض الأماكن كلف الأمر الاستبدال البسيط لـ .map () بـ .mapPartition () ، ولكن توقف الرمز عن التعطل.كان هناك عنق الزجاجة واحد فقط - geofencing في منطقة تعسفية. كان لا يزال حل هجين غريب مع شبكة خارجية. كان من الممكن استخدام Japan Mesh for Japan ، لكن بالنسبة لبقية العالم ، كان من الضروري البحث عن متغير مناسب للشبكة الديناميكية ، والذي يعتمد فقط على إحداثيات النقطة ، وهو مناسب للاستخدام.تم العثور على مثل هذا الخيار - اوبر H3 .كما أفهمها ، يتم تشفير شجرة سداسية في اسم H3 - وهذه شبكة جغرافية مع ميزات رائعة. إنه مستقر عبر مجموعة الإحداثيات بأكملها ، فهو سريع للغاية (يطلق على الكود الأصلي) ، ويعطي خلايا ذات حجم موحد دون ثغرات على جميع الأراضي ، ويسمح لك بعمل مجموعة من الخيارات المختلفة لتغطية المضلعات والنقاط والمسارات. أيضًا ، تحتوي الخلية الشبكية سداسية العدد الأدنى من الجيران ، ويغطي المستوى التالي الخلايا السبع للخلية السابقة أعلى مركز الخلية بشكل صحيح ، وهو مناسب عند إنشاء خرائط مجمعة.مع الانتقال إلى H3 ، يبدو أن اللغز قد تطور بالكامل.إذا قارنا ما كان عليه في البداية ، منذ 2.5 عام ، ثم منذ الأسابيع التي أمضيت على خريطة حرارة مؤسفة واحدة في مجموعة بيانات إلى بضعة ملايين من الإشارات ، وصلنا إلى الدقائق التي تم إنفاقها على عشرات البطاقات مع مجموعات البيانات ، وحجمها لا يهتم محلل البيانات كثيرًا (يجب عليك التذمر عندما يحدد الإعداد المسبق مرتفعًا جدًا لحجم الكتلة إذا كانت كتابة النتيجة إلى S3 تستغرق وقتًا أطول من الحساب نفسه). ولم يعد ينظر إلى TC بنفسه ، بل يسد مصفوفة المعلمات في مكان ما في المنزل ، ويسحب العدد المطلوب من البنيات اللازمة مع الثعبان.أضف عملية جديدة - كل ما تحتاجه هو تنفيذ فئة العملية بشكل صحيح (يمكنك أيضًا استخدام Scala إذا كنت تريد ذلك) ، وقم بتثبيتها بالبيانات الأولية ، وقم بتضمينها في التكوين الخاص بك ، ومن ثم ستكتشف One Ring ما إذا كنت تتصل بالكشف عن مجريات الأمور الجديدة أم تعالج في السلسلة بشكل صحيح.حسنا ، كل شيء يعمل محليا وفي AWS. سيكون أيضًا في بعض السحابة الأخرى إذا كان يدعم S3 ، ويمكن سحب Spark عبر Livy هناك - وتخلصنا من كل التبعيات الخارجية الأخرى.في كل البيض
- غاندالف؟!لكن ما زلنا لا نملك واجهة لإطلاق عمليات مرنة. ويجب كتابة القوالب الخاصة بهذه العمليات بنفس الطريقة القديمة - من خلال يدي VSCode ، لكنني أردت أن أكون ماوسًا في محرر مشابه لبرنامج Visio. شيء من هذا القبيل: لقد قمت حتى بتقديم خدمة REST صغيرة كجزء من One Ring ، والتي تحتوي على كل ما تحتاجه لكتابة مثل هذا المحرر ، ولكن آخر مرة عملت فيها في المقدمة كانت منذ حوالي 10 سنوات ، وليس في مسارات الاتجاهات الحالية. ليس من أجل JSF أن أبرمها ، لن يكون الأمر كذلك قديمًا ، لكن بالفعل نوعًا من necro. سيكون من الجميل أن نجعلها سبا ثابتة على شيء عصري. فقط ليس لدي أي فكرة عما. اهتمامي الشخصي الأناني بكشف رمز حلقة واحدة
لكن بشكل عام ، نحن ، فريق مهندسي البيانات ، لا نريد الاحتفاظ بالأداة النهائية في خزانة ملابسنا. نحن متأكدون: سيكون مفيدًا ليس فقط لنا. وليس فقط لاحتياجات نظم المعلومات الجغرافية ، ولكن بشكل عام أي معالجة انفجارية لمجموعات البيانات مع خطوات معالجة قابلة للمعايير.
في المقالة الأخيرة (أو مقالتين ، مرة أخرى يستغرق الأمر وقتًا طويلاً) سأخبرك بكيفية إنشاء حلقة واحدة وتشغيلها وتوسيعها واستخدامها لمهام البحث.* لا تتضمن شفرة مصدر One Ring OSS خوارزميات إرشادية خاصة بـ Locomizer الخاصة. لكن مستودعها سيحتوي على واجهات وأوصاف ، يمكن بموجبها إعادة إنشاء تطبيقات الاستدلال المجانية هذه باستخدام طريقة الغرفة النظيفة ، أي دون مطالبات من جانبي فيما يتعلق بالكود.شكر
... للزملاء Gregory pomadchin للحصول على تعليقات جوهرية حول الموضوع ، و sshikov لإجراء تقييم مستقل لسهولة النص ، وكذلك إلى Anton dartov Zadorozhny للحصول على تعليقات غير متوقعة على المقال السابق في هذه السلسلة.