عندما تفعل العكس والحصول على نفس ...
بعد مهمة معالجة البيانات التحليلية (الحسابية / التجميعية) ، يجب عليك إيجاد حل وسط بين الاستجابة والسرعة والراحة.
تتم فهرسة بعض الأنظمة بشكل جيد ، ويمكن للآخرين حساب البيانات وتجميعها بسرعة ، في حين أن الأنظمة الأخرى بسيطة. في مكان ما ، من الضروري تنظيم التحميل المسبق للفهرسة للبيانات بكل الصعوبات المصاحبة لها ، وفي مكان ما ، يتم تزويد المستخدم بنموذج مجرد من مصدره والبيانات المجمعة بالإضافة إلى المخازن المادية وقواعد البيانات المضمنة أو الخارجية المستخدمة مباشرة أثناء العمليات الحسابية. في أي حال ، يتعين على المستخدم ، من المبرمج إلى المحلل ، القيام بعمل كبير نسبيًا ، بدءًا من إعداد البيانات الأولية وتجميع الاستعلامات ، وحساب النماذج ، وينتهي بتصور النتيجة على الحاجيات ، بالطبع ، "مثير" - جميل ، سريع الاستجابة ومفهوم - خلاف ذلك كل العمل المنجز سوف ينخفض. في كثير من الأحيان ، كما الحظ ، يمر بمخاض اختيار الحل ، نلاحظ كيف تتطور مهمة بسيطة ومفهومة للوهلة الأولى إلى وحش زاحف ، لا فائدة منه للقتال بالوسائل المتاحة ، ونحن بحاجة إلى اختراع شيء على وجه السرعة - دراجة "مع لعبة البلاك جاك والقحبة" ©. ذهب دراجتنا ، بل إنها تجعل جولة جيدة من المطبات والتكيف مع العقبات التي يمكن للمرء أن يخمن فقط من قبل.
أدناه سيتم وصف جانب واحد من الجهاز الداخلي الأصلي من "Rubik's Cube" الخيالي - المعالجة الحسابية لتصور البيانات التفاعلي.
يجب حل المهمة البسيطة ببساطة ، ويجب أن تكون المهمة الصعبة بسيطة ولكنها أطول ...
بدأنا بإنشاء نظام مع قوى صغيرة ، انتقلنا من البسيط إلى المعقد. من خلال إنشاء مُنشئ ، كنا مقتنعين داخليًا بأننا نتفهم جيدًا الغرض من النظام ، ونقاتل في وقت واحد مع الرغبة في عدم فعل الكثير والرغبة المعاكسة في أتمتة كل شيء وكل شيء ، وخلق إطار لكل شيء. علاوة على ذلك ، كان أحد الأطر الرائعة لدينا جاهزًا وحتى تم اختباره في الإنتاج - jsBeans. لذلك ، بدأنا في تطوير نظام معالجة البيانات التالي ، الذي نما وأصبح الآن في الوقت نفسه منتجًا مكتفًا ذاتيًا - مصممًا ومنصة لتطوير فئة كاملة من أنظمة معالجة البيانات. بشرط ، في المقال سنطلق عليه "مكعب روبيك" من أجل الاستغناء عن الإعلان ، ولكن لوصف الحلول المثيرة للاهتمام في رأينا.
مكعب ، شريحة ، والقياس
المهمة الرئيسية - وجود مجموعات من البيانات غير ذات الصلة ، بما في ذلك قواعد البيانات والملفات الخارجية غير المتجانسة ، لتشكيل نموذج متعدد الأبعاد من العناصر المترابطة للبيانات المصدر ونتائج معالجتها التحليلية للتصور على لوحات المعلومات الديناميكية والحاجيات المترابطة.
ببساطة ، على سبيل المثال ، كلوحة تحكم قابلة للنقر:
يُطلق على نموذج البيانات المتعدد الأبعاد هذا في نظامنا "Cube" ويمثل حرفيًا مجموعة مجردة من مجموعات البيانات القابلة للتغيير والتي تسمى "شريحة" ، مترابطة من خلال حقول / أعمدة الإخراج المشترك (المعروضة) أو الحقول الداخلية التي تسمى "الأبعاد" وتستخدم للتصفية و ربط الشرائح مع بعضها البعض.
يمكن تمثيل الشريحة كجدول أو طريقة عرض افتراضية ( CTE ) مع معلمات ونص طلب متغير ، اعتمادًا على شروط التصفية. الشيء الرئيسي هو أن بيانات المخرجات تتغير ، اعتمادًا على شروط البحث في السياق (داخل عنصر واجهة المستخدم) والمرشح العام ، الذي تم إنشاؤه من خلال تحديد القيم على عناصر واجهة المستخدم واستخدام وظائف المنطق الأساسية (AND / OR / NOT) والمجموعات.
يسمح لك الفلتر العالمي "بتدوير مكعب روبيك" ، كما في الفيديو :
إذا كان حقل إخراج شريحة ما في نفس الوقت قياسًا في شريحة أخرى ، يحمل نفس الاسم ، فسيتم اعتبار قيم هذا الحقل من قِبل النظام "حقائق" (إذا كنا نتحدث عن OLAP ) ، يتم تعيينها في شكل مرشح عام يغير مجموعات البيانات الأصلية أثناء العمليات الحسابية والتجميعية . نتيجة لذلك ، هناك تفاعل ديناميكي للعناصر الذكية ، حيث تعتمد قيم المؤشرات المعروضة على العناصر والمرشحات المحددة.
الشريحة هي مجموعة من البيانات التي يمكن تغييرها "عن طريق القياسات" —النتائج الأولية أو نتائج العمليات الحسابية التحليلية ؛ تتميز بحقول / أعمدة الإخراج وقائمة من القياسات المدعومة ومجموعة من المعلمات ذات القيم الافتراضية ؛ تم وصفه بواسطة استعلام أنيق نسبيًا في محرر مرئي يدعم التصفية والفرز والتجميع / التجميع والتقاطعات (JOIN) والنقابات (UNION) والتكرار والإحداثيات الأخرى.
تصف الشرائح التي تستخدم بعضها البعض كمصادر البنية الداخلية للمكعب ، على سبيل المثال:
مثال تقطيع في المحرر:
تدعم الشريحة كلا القياسات المحددة صراحة في حقول الإخراج وترث القياسات من مصادر الاستعلام - وهذا يعني أنه يمكن تغيير بيانات الإخراج للشريحة حتى نتيجة للتغيرات في مصادر الشرائح الأخرى. بمعنى آخر ، يمكن تصفية نتائج الشريحة ليس فقط بواسطة حقول الإخراج ، ولكن أيضًا بواسطة قياسات الحقول الداخلية للمصادر ، في مكان ما في عمق الاستعلام ، حتى جداول قاعدة البيانات الأساسية.
يتم توسيع هيكل الاستعلام وتغييره تلقائيًا في وقت التنفيذ ، اعتمادًا على عامل التصفية والإدخال العالمي الحالي ، وسحبها بشكل أعمق إلى الاستعلام وفقًا لنموذج المكعب والأبعاد المعلنة والشرائح.
مثال على مرشح عام بسيط ، حرفيًا ، عندما يكون المستخدم قد التزم أو حدد قيمًا على عدة عناصر واجهة مستخدم:
يتم تخزين المرشح العام في طلب JSON:
يأتي الطلب إلى المصدر الأساسي (إلى قاعدة البيانات) بالفعل في نموذج معد ، بعد أن مرت عدة مراحل رئيسية:
- طلب التجميع ، بما في ذلك اختيار وتضمين الشرائح المثلى ، مع مراعاة المرشح العام الحالي (عندما يكون المرشح غائبًا أو بسيطًا ، يمكنك تحديد شرائح بسيطة / سريعة ؛ عندما يكون المرشح معقدًا - شرائح بهيكل معقد وقياسات إضافية) ؛
- تضمين مرشح عام وإضافة عوامل تصفية إلى نصوص الاستعلامات والاستعلامات الفرعية ؛
- تضمين وحدات ماكرو وتعبيرات استعلام القالب ؛
- تحسين الاستعلام ، بما في ذلك إزالة الحقول والتعبيرات غير المستخدمة ؛
- عمليات إضافية مع الاستعلام عن تفاصيل قواعد البيانات الأساسية (على سبيل المثال ، إذا كنا نتحدث عن SQL وكانت قاعدة البيانات لا تحتوي على WITH ، فسيتم تضمين الاستعلامات المسماة).
والمرحلة الأخيرة هي ترجمة الطلب إلى تنسيق المصدر الأساسي ، على سبيل المثال ، في SQL:
عندما تكون المصادر مختلفة
كقاعدة عامة ، كل شيء بسيط وواضح عندما تضطر إلى العمل مع مستودع بيانات واحد. لكن ، عندما يكون هناك العديد منهم ويختلفون اختلافًا جذريًا - يجب عليك تطبيق حيل مختلفة لكل مهمة محددة. وتريد دائمًا أن يكون لديك حل عالمي مناسب دائمًا ، ويفضل أن يكون خارج الصندوق ، مع تعديلات طفيفة بحد أقصى. للقيام بذلك ، يطرحها تجريد آخر: فوق مستودعات البيانات ، أولاً ، تحقيق تنسيق تنسيقات اللغات واللغات ، وثانياً ، ضمان ترابط البيانات ، على الأقل على مستوى شروط التصفية الإضافية في الاستعلامات إلى مصدر ما بواسطة القيم من مصدر آخر.
للقيام بذلك ، قمنا بتطوير لغة استعلام عالمية ، مناسبة لتمثيل نموذج ظاهري لبيانات المكعب وللتعامل مع مخازن تعسفية مشروطة عن طريق ترجمة الطلب إلى التنسيق واللغة المرغوبة. من قبيل المصادفة المحظوظة ، نمت لغة الاستفسار ، التي كانت تهدف في الأصل إلى رسم الخرائط وتصفية البيانات من مصادر مختلفة ، بسهولة إلى لغة بحث ومعالجة كاملة للبيانات ، مما يسمح للشخص ببناء إنشاءات حسابية من أبسطها إلى أكثرها تعقيدًا في عدة صفحات ومع العديد من الاستعلامات الفرعية.
يمكن تقسيم المصادر إلى ثلاثة أنواع:
- ملفات البيانات التي تتطلب التنزيل إلى النظام ؛
- قواعد البيانات التي تدعم المعالجة الكاملة للبيانات وغيرها من العمليات ؛
- وحدات التخزين التي تدعم استخراج البيانات فقط مع أو بدون تصفية ، بما في ذلك أنواع مختلفة من الخدمات الخارجية.
كل شيء لا لبس فيه مع النوع الأول - وحدة الاستيراد مدمجة في النظام ، الذي يوزع تنسيقات الإدخال المختلفة ويغمر النتائج في المستودع. للاستيراد ، تم تطوير مُنشئ خاص ، والذي يجب مناقشته بشكل منفصل.
النوع الثاني هو قواعد بيانات قائمة بذاتها ، والتي تحتاج فقط لترجمة الطلب الأصلي إلى التنسيق المطلوب ولغة الطلب ، وهي اللهجة.
النوع الثالث يتطلب على الأقل مرحلة ما بعد معالجة البيانات. وجميع الأنواع في نفس الوقت يمكن أن تتطلب أيضًا مرحلة ما بعد المعالجة - التقاطعات والنقابات والتجميع والحسابات النهائية. يحدث هذا عندما تحتاج معالجة البيانات في قاعدة بيانات واحدة إلى أن تؤخذ في الاعتبار نتائج التصفية في خارجي آخر.
أبسط مثال على ذلك هو عندما يتم إجراء بحث غامض في قاعدة بيانات واحدة ، وعند الإخراج من الضروري الحصول على مجموعة من المؤشرات المخزنة في قاعدة بيانات أخرى على خادم آخر ، مع مراعاة نتائج البحث.
لتنفيذ عمل مثل هذا المخطط ، يتم تنفيذ خوارزمية بسيطة في نظامنا - يتم إعداد الطلب الأولي في وقت واحد من قبل العديد من المترجمين الفوريين ، يمكن لكل منهما إما رفض تنفيذ الطلب عندما يكون غير متوافق ، أو إرجاع مكرر مع البيانات ، أو تحويل الطلب وبدء عمل سلسلة إعداد الطلب التالية بواسطة مترجم آخر . نتيجةً لذلك ، للحصول على طلب واحد ، نحصل على واحد من عدة أدوات تكرار كسول تشكل نفس النتيجة ، ولكن بطرق مختلفة ، يتم تحديد الأفضل منها (وفقًا للمعايير المختلفة التي يحددها المطور في التكوين).
يتم تحديد استراتيجية اختيار التكرار في معلمات التكوين أو الاستعلام. حاليًا ، يتم دعم العديد من الاستراتيجيات الرئيسية:
- أولاً ، أي ، آخر ؛
- حسب نوع قاعدة البيانات ذات الأولوية ؛
- حسب أولوية السلاسل التي شكلت التكرارات ؛
- بواسطة وظيفة الوزن من "طلب الترجيح" ؛
- وفقًا للنتيجة الأولى - يتم إطلاق جميع التكرارات بالتوازي ويتوقع أن تكون النتيجة الأولى ، ونتيجة لذلك ، يتم استخدام التكرار الأسرع ، ويتم إغلاق الباقي.
نتيجة لمثل هذا الجمع بين طلب إدخال واحد ، نحصل على عدة خيارات لتنفيذه ، سواء باستخدام مصادر مختلفة أو مع استراتيجيات تنفيذ مختلفة - اختيار قاعدة البيانات الرئيسية / الهدف التي سيتم فيها تنفيذ الجزء الرئيسي من الطلب والتجميع النهائي للنتائج.
إذا كان الهدف DBMS يدعم اتصال المصادر الخارجية ، يصبح من الممكن إنشاء دائرة عكسية حيث يتم توصيل DBMS بواجهة برمجة تطبيقات النظام لتلقي كميات صغيرة من البيانات من النظام ، على سبيل المثال ، لتصفية كميات كبيرة "في المكان". يكون هذا التكامل شفافًا للمستخدم النهائي والمحلل - لا يتغير نموذج المكعب ، ويتم تنفيذ جميع العمليات تلقائيًا بواسطة النظام.
بالنسبة للحالات الأكثر تعقيدًا ، يقوم النظام بتنفيذ مترجم استعلام داخلي في الذاكرة على محرك قاعدة البيانات H2 Embedded الرائع ، والذي يسمح بدمج أي قاعدة بيانات مدعومة خارج الصندوق. حرفيًا ، يعمل مثل هذا - ينقسم الطلب إلى أجزاء حسب مجموعات المصادر ، يتم إرسالها للتنفيذ ، وبعد ذلك يتم تنفيذ التجميع والمعالجة النهائية للنتائج في الذاكرة ، في H2.
للوهلة الأولى ، يبدو مخطط تكامل البيانات هذا على مستوى المترجم الداخلي "صعبًا" ، وهذا صحيح إذا كان عليك العمل مع كميات كبيرة من بيانات الإدخال والحاجة إلى إجراء عمليات حسابية بعد التقاطعات وربط مجموعات من مصادر خارجية. في الواقع ، تم تسوية هذا الظرف جزئيًا - في نفس الوقت ، يتم تنفيذ الطلب بواسطة عدة معالجات في إصدارات مختلفة ، لذلك ، لا يتم استخدام المترجم الفوري إلا في الحالات القصوى ، كحل عالمي خارج المربع. في النهاية ، يقتصر أي تكامل على تكاليف النقل النموذجية لإعداد البيانات ونقلها عبر الشبكة وتلقيها ، وهذه مهمة مختلفة تمامًا.
الجانب الفني
من الجانب الفني ، الذي ، على الأرجح ، لا يمكن الاستغناء عنه ، ولمس هذا الموضوع ، يتم ترتيب النظام أيضًا وفقًا للمبدأ - للقيام بالمزيد ، ولكن تبسيط كل شيء قدر الإمكان.
يتم تطبيق نظام معالجة البيانات في أعلى إطار عمل خادم jsBeans كمجموعة من الوحدات الإضافية ومشروعات التجميع المحددة. يتم تطبيق jsBeans ، بدوره ، في Java ، ويعمل كخادم تطبيقات ، وهو إلى حد كبير مجموعة من Rhino و Jetty و Akka ، كما يشتمل أيضًا على تقنية bean-server لخبراء فريقنا ومكتبة غنية بالمكونات التي تم تجميعها على مدار عدة سنوات من التطبيق الناجح.
يتم تطبيق Rubik's Cube بشكل كامل وكامل في JavaScript في شكل العديد من صناديق js-bins (ملفات * .jsb) ، يعمل بعضها على الخادم فقط. الجزء الآخر هو على العميل ، والباقي مكون مكون ، يعمل ككل موزعة ، الأجزاء التي تتفاعل مع بعضها البعض ، شفافة للمطور ، ولكن تحت سيطرته. يمكن أن تحتوي صناديق Js-bins على استراتيجيات حياة مختلفة ، على سبيل المثال ، مع أو بدون جلسة مستخدم ، وأكثر من ذلك بكثير. الفاصوليا غير متجانسة ؛ فهي تسمح لكل من العميل والخادم بالعمل معها كمثيل افتراضي لفئة عادية. يتم وصف الحاوية بواسطة ملف واحد ويتضمن ثلاثة أقسام - للحقول والأساليب التي تعمل على العميل ، لحقول الخادم ، وكذلك قسم من الحقول المتزامنة الشائعة.
نظرًا لأن المقال قد أصبح بالفعل مطوّلًا حتى لا يتحمل القراء ، فقد حان الوقت للمضي قدماً في الاكتمال ، بقصد وصف التفاصيل والحلول المعمارية الأكثر إثارة للاهتمام في تنفيذ JsBeans ومشاريعنا استنادًا إلى ذلك - نظام التصور الفرعي الذي تم إنشاؤه والعمليات التحليلية والمصمم الأنطولوجي لمجالات المواضيع واللغة الاستعلامات واستيراد البيانات وشيء آخر ...
لماذا هذا
هذا لم يحدث من قبل ، وهنا مرة أخرى ...
في البداية ، كان هناك عدد قليل من مجموعات البيانات الأولية. تم تحديد مجالات الموضوع والمهام بالكامل. يبدو ، لماذا هذا العذاب؟ تبدو المهمة بسيطة ، حيث أراد الجميع الحصول على النتيجة فورًا - خاصةً عندما يكون الحل السريع على السطح ، والحل الصحيح يتطلب المثابرة والقرارات المتوازنة ، مع ملاحظة الإعداد الأصلي. لقد ذهبنا في الاتجاه المعاكس ، من الحلول المعقدة والطويلة إلى الحلول البسيطة والسريعة ، على طريق تعميم مشكلات معينة.
الشرط الرئيسي هو أنه يجب بناء لوحات معلومات جديدة بسرعة ، حتى لو كان موضوع الموضوع الجديد والاحتياجات التحليلية مختلفة تمامًا عن السابقة. من الواضح أنك لن تخمن حتى نصف المتطلبات المستقبلية ، يجب أن يكون النظام مرنًا في المقام الأول. يعد تحسين مكتبة المكونات والخوارزميات التحليلية وربط أنواع المصادر الجديدة جزءًا لا يتجزأ من تكييف النظام. بمعنى آخر ، لقد نجحت المجموعة - حيث يبني المحللون استعلامات ولوحات المعلومات ، ويدرك المبرمجون بسرعة احتياجات جديدة لهم. ونحن ، كمبرمجين ، سعينا في البداية إلى تبسيط عملنا في المستقبل ، في محاولة لعدم الإضرار بقدرة الاستخدام.
وتم إنشاء النظام فورًا على مستوى عالمي وقابل للتكيف - لقد صممنا "مُنشئًا مُنشئًا منشئًا" ، ونطور إطارًا على قمة إطار تم إنشاؤه مسبقًا له غرض مشابه ، لكن أكثر عمومية.
يعد تصنيف مدارس موسكو استنادًا إلى نتائج امتحان الدولة الموحدة والأولمبياد مثالًا على لوحة القيادة التي تم إنشاؤها بالطريقة الموضحة أعلاه من التفريغ من بوابة البيانات المفتوحة لحكومة موسكو.
Cube-Rubik هي عبارة عن منصة أساسية لتطوير نظم المعلومات والتحليل. صممت لتكون فرعًا واستمرارًا منطقيًا لـ jsBeans. ويشمل جميع الوحدات اللازمة لحل مشاكل التجميع والمعالجة والتحليل (الحسابية والموجهة نحو العملية) والتصور.
jsBeans عبارة عن إطار عمل ويب مكتمل الشكل مكدس يقوم بتطبيق تقنية JavaScript الخاصة بملقم العميل ، والتي تم تطويرها بترخيص مفتوح كأداة عالمية. أثناء الاستخدام ، أثبتت نفسها بشكل جيد ، في معظم الحالات ، من المناسب بشكل مثالي في المهام الماثلة أمامنا.