ستساعدك المقالة التالية: من OLTP إلى Data Lakehouse – نحو AI
نُشر في الأصل على نحو AI ، الشركة الرائدة في العالم في مجال الذكاء الاصطناعي والأخبار التقنية والإعلام. إذا كنت تقوم ببناء منتج أو خدمة متعلقة بالذكاء الاصطناعي ، فنحن ندعوك للتفكير في أن تصبح راعيًا للذكاء الاصطناعي. في نحو الذكاء الاصطناعي ، نساعد في توسيع نطاق الشركات الناشئة في مجال الذكاء الاصطناعي والتكنولوجيا. دعنا نساعدك على إطلاق التكنولوجيا الخاصة بك للجماهير.
نظرة عامة عامة على النظام البيئي للبيانات في بضع فقرات
لقد نما النظام البيئي للبيانات بشكل كبير في السنوات الماضية ، مع التقنيات الناشئة وزيادة الضجيج من البائعين مما يفسد الطريق للوافدين الجدد. هذا المنشور هو محاولتي المختصرة والبسيطة لشرح الأصل والمسار من OLTP إلى Data Lakehouse في بضع فقرات قصيرة.
احملوا معي ، آمل أن تكون الرحلة واضحة في غضون خمس دقائق.
من أعلى إلى أسفل ، يمكننا التفكير بشكل عام في فئتين عريضتين من قواعد البيانات: SQL و NoSQL. بعبارات بسيطة وعامة ، الأول هو قواعد البيانات العلائقية في حين أن هذا الأخير غير علائقية. السابق على أساس الجدول، في حين أن هذا الأخير يمكن أن يكون خيارات تخزين متعددة (مفتاح ، مستند ، رسم بياني ، وعمود عريض). السابق يتوقف بشدة على مفهوم معاملات متعددة الصفوف (يمكنك التفكير في المعاملات كمجموعة من المهام التي إما أن تنجح ككل ، أو تفشل ككل) ، والأخيرة هي أكثر ملاءمة لـ بيانات غير منظمة (على الرغم من أن هذا الخط أصبح مؤخرًا أكثر ضبابية).
نظم إدارة قواعد البيانات العلائقية (RDBMS) ينفذ حامض الامتثال ، الذي يدير ، من بين أمور أخرى المعاملات ل SQL المستندة قواعد بيانات. NoSQL قواعد البيانات ، بدورها ، تلتزم ب قاعدة امتثال ().
تعتمد معظم أنظمة الخلفية على معالجة المعاملات عبر الإنترنت (OLTP) ، والتعامل مع عدة المعاملات، يقرأ السجل ويكتب ويحدث ويحذف (الخام عمليات) ، وعادة ، لا تحفظ البيانات التاريخية. ومع ذلك ، بالنسبة لفرق البيانات ، فإن كل تغيير مهم ، وبالتالي ، فإننا نحتاج إلى أنظمة يمكنها التعامل مع كميات كبيرة للغاية من السجلات التي تحتوي على كل تغيير متعلق بالعمل حدث في قواعد البيانات التشغيلية! لكن هذه البيانات الكبيرة تحتاج الآن إلى تخزينها والاستعلام عنها بكفاءة. لهذا الغرض، RDBMS كان موسع لدعم الاستعلامات المعقدة ل كميات كبيرة من البيانات التاريخية، مجمعة من قواعد بيانات OLTP ومصادر أخرى ، مما أدى إلى معالجة تحليلية عبر الإنترنت (OLAP). عادة ، يتم تخزين هذه البيانات الضخمة في شكل ملف مستودع البيانات، هياكل بيانات محسّنة للتحليل تصل غالبًا إلى حجم بيتابايت.
بينما OLAP يعمل في العديد من المواقف ، مثل جميع أنظمة RDBMS ، هم عموديا قابلة للتطوير (ملاحظة: تعالج SQL الموزعة هذه النقطة ، ومع ذلك ، فإن شعبيتها صغيرة في الوقت الحالي). NoSQL بدوره أفقيا معنى قابل للتحجيم ، انخفاض تكاليف تخزين البيانات مع نمو بياناتك ، خاصية مرغوبة للغاية ولكن غير قابلة للتحقيق لـ OLAP لفترة طويلة ، نظرًا لأن امتثال ACID المفقود في NoSQL ، يعد مفيدًا بشكل لا يصدق. ماذا لو استطعنا يجمع الامتثال RDBMS ACIDو OLAP’s تحليل البيانات التاريخية الضخمة القدرات ، مع NoSQLs قابلية التوسع الأفقي؟ هذا هو المكان داتا ليك هاوس يضيء.
بحيرة البيانات الاستفادة من مفهوم بحيرات البياناتوأنظمة الملفات التي تدعم كميات هائلة من البيانات المهيكلة وغير المهيكلة بتكاليف منخفضة ؛ مستودعات البيانات؛ و معالجة منفصلة. بعبارة أخرى، لا تتطلب مستودعات البيانات لديك الخادم باستمرار على الإنترنت كما يفعل RDBMS ، ويستخدم بحيرات البيانات للتخزين. لماذا هذا مهم؟
- إذا لم تكن هناك حاجة للوصول إلى بياناتك كل ثانية ، فيمكنك ذلك توفير تكلفة امتلاك خادم متصل بالإنترنت باستمرار ، مع مقايضة وجود بعض الكمون لاسترداد بياناتك
- في الواقع ، منذ ذلك الحين المعالجة مستقلة عن التخزين، يمكنك في الواقع استخدامها مجموعات أكثر قوة لمعالجة بياناتك ، والتي تعمل فقط – وتدفع فقط مقابل – طوال مدة عبء العمل. بمعنى ، تحصل المزيد من العصير مقابل جزء بسيط من التكلفة. بالإضافة إلى ذلك ، يمكنك أيضًا تكوين خصائص خادم لكل حمل عمل ، مما يؤدي إلى زيادة تحسين التكاليف
- RDBMS نكون غالي في النمو ، بالاعتماد على الأجهزة باهظة الثمن والمزدوجة. لكن أ داتا ليك هاوس يعتمد على الملفات التي ، مع بعض السحر ، لديها طبقة امتثال ACID فوقها ، جنبًا إلى جنب مع بعض التحسينات والميزات الأنيقة الأخرى (انظر). وكلنا نعلم ، ملف التخزين رخيصو
- أنت تستطيع يبني لك مستودع البيانات مباشرة في دلتا الاستفادة من المزايا المذكورة أعلاه
- دلتا يحتوي على مجموعة من ميزات قوية للغاية التي تسهل بشكل كبير مهمة مهندس البيانات: معاملات ACID ، والبيانات الوصفية القابلة للتطوير ، والسفر عبر الزمن ، والدُفعات / الدفق الموحد ، وتطور المخطط وتطبيقه ، وعمليات التدقيق ، وعمليات DML ، وما إلى ذلك ، وكل ذلك ، في مشروع مفتوح المصدر ، لا قفل البائع
- أنت تستطيع الاحتفاظ بالبيانات بتنسيقات متعددة ومستويات تنظيمو يخدم حالات استخدام متعددة: من تحليل البيانات / BI إلى Data Science / ML
ألا توجد عيوب؟ مثل جميع التقنيات ، لا يوجد شيء مثالي و يجب أن يتم اختيار التكنولوجيا وفقًا للسياق والمتطلبات. ليك هاوس لا يختلفون ، وهم يعانون من مجموعتهم الخاصة عيوب:
- ال تكنولوجيا إلى حد ما مؤخرًا (تم اعتماد Delta Lake 1.0 من قبل المجتمع في مايو 2021) مما يعني أن العديد من الميزات قد تتغير وقد تكون بعض الميزات المرغوبة للغاية مفقودة في الوقت الحالي
- التكنولوجيا مختلف جدا من RDBMS التقليدية ، على وجه الخصوص ، من حيث تحسين وبالتالي يمثل خطرًا أكبر وقد يكون من الصعب العثور على محترفين ذوي خبرة
- هم صعب التحسين، بالاعتماد على عدة تقنيات مختلفة ، يجب تنفيذ بعضها منذ بداية المشروع (Bloom Filters)
- مثل جميع التقنيات الجديدة ، الوثائق والأمثلة وأفضل الممارسات نادرة
- أخيرًا ، من المهم التفكير في BI / طبقة التقارير منذ بعض أدوات ذكاء الأعمال (Power BI على سبيل المثال) ، سيجعل ملف الاستعلام عن كل مرئي ومن ثم ، فإن لوحات المعلومات المعقدة ، وخاصة هؤلاء المستخدمين الذين يتفاعلون معها كثيرًا ، قد يؤدي إلى ارتفاع التكاليف
اسمحوا لي أن أعرف ما إذا كانت المقالة تساعد في إلقاء بعض الضوء على النظام البيئي – وإن كان بعبارات بسيطة – أو إذا كنت تشعر أن شيئًا ما ليس دقيقًا تمامًا!
من OLTP إلى Data Lakehouse نُشر في الأصل في Towards AI on Medium ، حيث يواصل الأشخاص المحادثة من خلال تسليط الضوء على هذه القصة والرد عليها.
تم النشر عبر نحو الذكاء الاصطناعي