
مرحبًا ، اسمي فيكتوريا ، وأنا مسؤول عن التسويق في CROC Cloud Services. الآن نحن نستضيف بانتظام mitaps سحابة. حصلت مؤخرًا على أروع أداء لديميتري أنوشين ، الذي يعمل الآن في أمازون ، وأريد مشاركته.
كان لدي شعور قوي بأن الشركات التجارية الكبرى قررت أن تجمع بشكل عام جميع البيانات الممكنة في العالم التي يمكن أن تصل إليها. من ناحية ، وهذا يترجم إلى تحليلات متقدمة ، وزيادة المبيعات وجاذبية المنتجات. من ناحية أخرى ، أصبحت البيانات جريئة وشاملة لدرجة أن النكات المتعلقة بالشاحنات المزودة بأقراص CD-ROM أصبحت شائعة منذ فترة طويلة.
دعونا نرى لماذا قد يكون من الضروري الانتقال إلى السحابة وما حصلت عليه أمازون من نقل البنية التحتية الداخلية إلى Redshift و NoSQL DynamoDB. دعنا نحلل الفرق بين مفاهيم SMP و MPP و ETL و ELT ونحاول أن نفهم سبب الحاجة إلى السحب للبيانات الضخمة.
حسنًا ، إذا كنت على دراية بما حدث في الصناعة في السنوات الأخيرة ، فاستعرض على الفور حالة معينة. تعال تحت الخفض ، قمت بإعداد ملخص للنقاط الرئيسية للأداء.
القياس عن بعد من كل مصباح

الشركات الكبيرة لديها اتجاه ملحوظ للغاية نحو تشكيل النظم الإيكولوجية المتكاملة حول مستخدميها. أي أنك استيقظت وذهبت لتنظيف أسنانك وفي الوقت نفسه تنظر إلى الأخبار في مرآة وسائط متعددة. يتضمن عمود Alexa موسيقى مفعم بالحيوية في الصباح ويذكر باجتماعات اليوم. هنا يمكنك طلب القهوة الطازجة مع التوصيل إلى المنازل ، حيث أن القهوة القديمة تنفد بالفعل. تصل إلى السيارة ، ثم مرة أخرى Alexa ، وهو مدمج مع نظام الوسائط المتعددة للسيارة ويستمر في مرافقته على الطريق. بالإضافة إلى سوار ذكي وسماعات رأس وتطبيقات في الهاتف وآلاف مصادر المعلومات الأخرى.
هذا هو في الوقت نفسه مستقبل مخيف قليلاً يأتي بسرعة من جميع الاتجاهات ، في محاولة لخلق قيمة إضافية للمستهلك النهائي من الشركات. يجب أن توافق على أنه رائع عندما ، على سبيل المثال ، وفقًا لبرنامج Amazon Key In-Car ، سيتم تسليم مشترياتك مباشرة إلى صندوق السيارة في موقف السيارات. أنا الآن أعيش في كندا ، ومثل هذه الدمج تجعل الحياة أكثر راحة. بالنسبة للشركة ، تعد هذه أيضًا بيانات قيمة للغاية فيما يتعلق باستهداف المبيعات والتنبؤ بالطلب وتحسين الخدمات اللوجستية والمزيد. مربح للجانبين.
مشكلة واحدة. كما قلت بالفعل ، هناك شعور قوي بأن الشركات غالباً ما تجمع البيانات على نطاق مفرط على أمل تسييلها في المستقبل. وهذه هي تيرابايت. في الواقع تيرابايت من المعلومات السيئة التنظيم التي تتدفق باستمرار على خوادم الشركة ، تلتهم موارد الشبكة والحوسبة والتخزين. وهذا هو سبب أهمية مشكلة الاستخدام الأمثل للموارد وضمان سرعة الحوسبة. وتحتاج أيضًا إلى تزويد محللي الأعمال بواجهة عادية لا تتطلب منهم الحصول على معرفة متخصصة في بناء البنية التحتية السحابية. لذلك ، انتقلت العديد من الشركات الكبيرة نحو السحب.
ليس هناك سحابة

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

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

لطالما أحببت هذا الرسم التوضيحي دائمًا ، والذي يظهر جيدًا درجة تفويض مهام البنية الأساسية لشركتك إلى البائع.
خيار On-Premises التقليدي هو شراء الطعام ، سخن الفرن ، وطهي البيتزا بنفسك. مثالية! ولكن عليك أن تحصل على جميع المعدات والمكونات وأكثر من ذلك.
IaaS هو خيار تأجير البنية التحتية. لقد استأجرت مطبخًا يحتوي على جميع المعدات ، وجلبت منتجاتك وطهي البيتزا الرائعة. سيقوم الأشخاص المدربون تدريباً خاصاً بغسل الفرن من الدهون ، ولا داعي للقلق بشأن حدة السكاكين والتافه الأخرى.
PaaS هي عبارة عن منصة كخدمة. توفر لك الخدمة بعض الأشياء الجيدة الإضافية بالإضافة إلى البنية التحتية العارية. على سبيل المثال ، Amazon Redshift - كمستودع بيانات ، والذي يتيح لك الحفظ في DBA والتركيز على المنتج. في مثال البيتزا لدينا ، يمكن أن يكون ، على سبيل المثال ، عجينة جاهزة الصنع يمكن ذوبانها فقط ، مع انتشارها مع الصلصة العطرية ، مع رشها بالفطر ، وشرائح لحم الخنزير المقدد الطري والبارميزان المبشور.
الخيار الأخير هو ادارة العلاقات مع. في هذه الحالة ، يمكنك الحصول على المنتج النهائي الأكثر بناءً على عملك. على سبيل المثال ، قم بتشغيل مدونة بناءً على النظام الأساسي لشخص آخر. في مثالنا ، سيكون هذا الخيار أغلى ولكن بسيط لطلب البيتزا الجاهزة في المنزل.
شاحنة البيانات. الثلج المحمول
هناك حكاية قديمة ملتحة منذ وقت "الصفر": "كان فريق من سائقي الشاحنات قادرين على توصيل 100000 قرص مدمج من أوديسا إلى كييف بين عشية وضحاها. وبالتالي ، وصلوا إلى معدل نقل بيانات يبلغ 2.43 تيرابايت في الثانية على مسافة تزيد عن 500 كيلومتر دون استخدام كابلات باهظة الثمن. "

في ذلك الوقت كانت مجرد مزحة. ومع ذلك ، مع الكميات الحديثة من دفق مستمر من الصور من كل هاتف محمول ، والصوت والفيديو وغيرها من القياس عن بعد ، يصبح غير قابل للسخرية تماما ويتحول إلى مشكلة حقيقية. عندما لا يكون لديك رابط بصري سميك مستأجر مباشر إلى مركز البيانات ، فإن نقل كميات كبيرة من البيانات إلى السحابة قد يمثل مشكلة كبيرة. خدمات مثل كرة الثلج الأمازون تأتي لإنقاذ.
إنها تجلب لك مثل هذه الحقيبة المحمية الوحشية المليئة بـ 50 تيرابايت من الأقراص عالية السرعة وواجهات شبكة 10 جيجابت. ثم يمكنك توصيله مباشرة إلى متجرك ودمج جميع البيانات بأقصى سرعة. في حالة السرقة أو غيرها من المشاكل ، تترك البيانات غرفة الخادم الخاص بك فقط في شكل مشفر. هناك وحدة نمطية TPM في هذه الحالة ، وتتم إدارة مفاتيح التشفير باستخدام خدمة إدارة المفاتيح AWS (KMS). لا يتم تخزين مفاتيح التشفير على الجهاز نفسه.
في الحالات المتقدمة بشكل خاص ، يمكنك الاتصال بـ Snowball Truck - مركز بيانات متنقل بسعة 100 بيتابايت. عندما تقترب مقاييس البيانات من إكسابايت ، سيتطلب اتصال نموذجي 10 جيجابت 26 عامًا لنقل البيانات. وستتمكن هذه الشاحنات البيضاء من سحب البيانات وإسقاطها لمدة ستة أشهر.
الأمازون تهاجر من أوراكل إلى Redshift
ما كان لديناسأخبركم قليلاً عن القضية التي عملت معها في أمازون. منصات التداول الرئيسية مثل Amazon لها عمل مؤلم للغاية - أيام البرايم. هذه هي ذروة مبيعات الجمعة السوداء ومبيعات عيد الميلاد. في هذه المرحلة ، تذوب الخوادم تحت الحمل ، والمستودعات مزدحمة بالوادر ، واللوجستيات تختنق تحت تدفق مستمر للبضائع. هذا وقت مهم للغاية من وجهة نظر المبيعات ، وكل ساعة من التوقف أو عدم إمكانية الوصول إلى الخدمة تكلف الكثير من الخسائر.
جاءت المشكلة من Oracle DB. توقفت قاعدة البيانات ببساطة عن تصدير مثل هذا الحجم من الاستعلامات المتزامنة ، والتي تواجه مشكلات في القياس. تم تطوير الموقع تقريبًا تحت هجمة العملاء ، وأصبحت قاعدة البيانات مشكلة من حيث التوسع.
بعد تحليل دقيق ، توصلوا إلى استنتاج مفاده أن قواعد بيانات SQL التقليدية ليست مناسبة كخلفية لمنصة تداول بهذا الحجم. بالإضافة إلى ذلك ، تعد Oracle أيضًا مكلفة للغاية من حيث التراخيص والدعم. ونتيجة لذلك ، تقرر الانتقال إلى نظامهم الأساسي السحابي ، الذي كان يستند إلى Redshift و NoSQL DynamoDB.
كان DynamoDB تطوراً داخلياً مع النسخ المتماثل المتزامن بين مراكز البيانات وآلية فعالة للغاية لتقليل تكرار البيانات ، مما سمح بتوفير كبير في التخزين. ميزة هامة للغاية هي القياس التلقائي - تغيير حجم قاعدة البيانات الديناميكية للكمية المطلوبة من البيانات. تم دمج كبير مع Hadoop أيضا.
ما هي المشكلة الرئيسية لقاعدة البيانات التقليدية؟

تكمن المشكلة في أن الإصدار القديم من Oracle يشير إلى بنية SMP ، والتي لا تتضمن سوى التوسع الرأسي. أي أن لديك جهازًا قويًا ذا ذاكرة معينة ومجموعة من التخزين السريع ، وجميع الطلبات تتدفق بطريقة أو بأخرى عليها. إنه نموذج أوراكل كلاسيكي يركز على تقديم خوادمه المستقلة القوية. في الوقت نفسه ، لم تؤمن الشركة بشكل خاص بالغيوم ، ولم تعد الحوسبة المتوازية حلاً واعداً. ونحتاج إلى MPP - بنية متوازية تتيح لك تلطيخ طلب للعديد من الأجهزة المنفصلة ومعالجة البيانات بشكل أسرع.
هناك نقطة مهمة أخرى - نهج ETL مقابل ELT لإدخال البيانات في قاعدة البيانات.
ETL - استخراج -> تحويل -> تحميل. أي أننا نتلقى أولاً بيانات من مصادرنا وننظمها بعناية ، وعندها فقط نملأها في مستودعاتنا. يتضمن منهج ELT تعبئة البيانات الصاخبة الخام في التخزين والمعالجة موجودة بالفعل من جانبها. من حيث المبدأ ، يدعم RedShift كلا النهجين ، لكن لدى ETL ميزة: الوصول إلى البيانات التي تمت تصفيتها أسرع وأسهل في المعالجة. رغم أنه في نفس الوقت يتم إنفاق المزيد من الموارد على التحليل الأولي للمعلومات الأولية. هناك لحظة واحدة غير واضحة. يقلل ETL المخاطر من حيث إجمالي الناتج المحلي في القانون الأوروبي من خلال تصفية المعلومات الحساسة مقدمًا قبل أن يصل إلى المستودع العام. هذا يقلل من خطر الوصول غير المصرح به إلى البيانات. الأداة الرئيسية لمعالجة البيانات الأولية في الهيكل الجديد كانت Matillion. يوجد بالفعل واجهة المستخدم الرسومية لطيفة ، وهو شكلي للغاية ويأتي بالفعل في خيار مصمم خصيصا لالامازون RedShift. شكرا له ، اتضح لخفض عتبة الدخول. يمكن الآن لمديري المنتجات تكوين تدفقات البيانات الواردة في شكل مصمم مرئي دون مساعدة مهندسي البيانات لدينا.

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

لقد قدمنا أيضًا Tableau ، مما سمح لنا بالانتقال من الجداول غير المتصلة بشكل جيد في Excel إلى لوحات المعلومات المفردة والملائمة للإدارة.
وسأشرح فقط في حالة: هناك Oracle OLTP (الواجهة الخلفية) في المتجر ، وهناك Oracle DW - مستودع بيانات تحليلية. كان المشروع يستهدف كلا الأمرين ، لكنني أتحدث بالتحديد عن Oracle DW! أي أن المخطط والوصف المعطيان محليان ، ولا يهمهما سوى فريق Amazon. الشيء نفسه ينطبق على Tableau. عندما أقول "لقد قمنا بتنفيذ لوحة النتائج" ، أقصد المشروع المحلي ، حيث يتم تقسيم كل شيء في Amazon إلى فرق ، والجميع يختار ما يجب القيام به وما يجب تنفيذه واستخدامه.
الغيوم ، على الرغم من الضجة غير الصحية المحيطة بها إلى حد ما ، هي بالفعل الواقع الحالي. على الأرجح ، سيتم بناء معظم المشاريع التجارية حول هذه البنية التحتية. نعم ، ربما ليس كل شركة لديها مثل هذه الحلول. لكن الأمر يستحق التخطيط لمزيد من التطوير الآن ، وإلا سيكون من الصعب الاستجابة السريعة لمعلمات السوق المتغيرة بسرعة والمنافسة الشرسة.
إذا كان أي شخص مهتمًا بموضوع تحليلات السحابة والحلول الحديثة ،
فانتقل إلى هنا . أنا إسقاط محتوى مفيد هناك.
تعال إلى لقائنا

لقد نجحت CROC Cloud Services بالفعل في سلسلة من الخطب من قبل متحدثين ممتازين ، على سبيل المثال ، كان موضوع التخفيف هو الاستخدام العملي لخدمات AWS في الحياة. في العام المقبل ، خططنا لعدة أحداث أخرى ، وسنتحدث عنها بالتفصيل. متابعة الأحداث.