غالبًا ما نعثر على مقالات رائعة باللغة الإنجليزية تبدو مفيدة لفريقنا ، وقررنا أن يكون من الرائع مشاركة ترجماتها مع قراء Habra. أعددنا اليوم ترجمة لمقال من إعداد تريستان هاندي ، مؤسس تحليلات فيشتاون.
دور مهندس البيانات في الشركات الناشئة الحديثة يتغير بسرعة. هل أنت متأكد من أنك تفهم جيدًا متى ولماذا قد يحتاج فريقك إلى مثل هذا الاختصاص؟
غالبًا ما أتواصل مع كبار ممثلي عالم التحليلات وألاحظ أن فهمهم لدور مهندس البيانات في الفريق غير صحيح. هذا يمكن أن يخلق صعوبات لفريق تحليل البيانات بأكمله ، وأود أن تتعلم الشركات كيفية تجنب مثل هذه المشاكل.
في هذه المقالة أريد أن أشارك أفكاري حول متى وكيف ولماذا يستحق الأمر التعاقد مع مهندس بيانات. تستند مناقشتي إلى تجربتي في Fishtown Analytics ، حيث عملت مع أكثر من مائة شركة ناشئة بدعم من رأس المال الاستثماري وساعدتهم في بناء فرق لتحليل البيانات ومعالجتها ، فضلاً عن المعرفة المكتسبة من خلال التواصل مع ممثلي مختلف شركات معالجة البيانات.
إذا كنت تقود فريقًا من خبراء البيانات ، فهذا المنشور يناسبك.
دور مهندس البيانات يتغير
يتيح البرنامج الحديث لأتمتة المزيد من العمل الممل المتعلق بتحليل البيانات ومعالجتها.
في عام 2012 ، طُلب من مهندس بيانات واحد على الأقل تحليل مجموعة البيانات بالكامل في شركة ناشئة ممولة من مشروع. كان على هذا المتخصص أن يستخرج البيانات من أنظمة مختلفة حتى يتمكن المحللون وعملاء الشركات من العمل معهم. في كثير من الأحيان كان من الضروري تحويل البيانات بطريقة ما بحيث كان من السهل تحليلها. بدون مهندس بيانات ، لن يكون للمتخصصين في تحليل البيانات ومعالجتها ببساطة البيانات التي يمكنهم العمل بها ، وغالبًا ما كان مع مهندس البيانات الذي بدأ الفريق في تشكيله.
بحلول عام 2019 ، يمكن إجراء معظم ذلك من خلال حلول جاهزة. في معظم الحالات ، يمكنك أنت وفريق من المحللين بناء خط أنابيب لمعالجة البيانات بنفسك ، دون مساعدة من شخص لديه خبرة واسعة في علم البيانات. ولن يكون خط الأنابيب هذا سيئًا على الإطلاق - الأدوات الحديثة الجاهزة مثالية لحل مثل هذه المشكلات.
لقد أتيحت الفرصة للمحللين وعلماء البيانات مؤخرًا لبناء خطوط أنابيب بأنفسهم - منذ 2-3 سنوات فقط. حدث هذا بشكل رئيسي بسبب ثلاثة منتجات: Stitch و Fivetran و dbt (تجدر الإشارة إلى أن dbt هو منتج لشركتي ، Fishtown Analytics). تم إصدارها فورًا بعد Amazon Redshift تقريبًا ، عندما أدركت فرق بدء التشغيل أنها بحاجة لإنشاء مستودعات بيانات. استغرق الأمر عدة سنوات أخرى لجعل هذه المنتجات ذات الجودة العالية - في عام 2016 كنا لا نزال رواد.
أصبح الآن خط أنابيب تم إنشاؤه باستخدام Stitch أو Fivetran أو dbt أكثر موثوقية بكثير مما تم تصميمه خصيصًا باستخدام Airflow. أنا لا أعرف هذا من الناحية النظرية ، ولكن من تجربتي الخاصة. أنا لا أقول أنه من المستحيل بناء بنية تحتية موثوقة مع Airflow ، معظم الشركات الناشئة لا تفعل ذلك. في Fishtown Analytics ، عملنا مع أكثر من 100 فريق تحليل في الشركات الناشئة المختلفة ، وقد تكرر هذا السيناريو عدة مرات. نحن نساعد الناس باستمرار على التحول من خطوط الأنابيب الخاصة بهم إلى حلول متكاملة ، وفي كل مرة يكون التأثير إيجابيًا.
يجب أن لا يكتب مهندس البيانات ETL
في عام 2016 ، كتب Jeff Magnusson منشورًا أساسيًا ، ألا ينبغي أن يكتب مهندسو البيانات ETL . كانت هذه أول مشاركة في ذاكرتي تدعو إلى مثل هذا التغيير. هنا هو الجزء المفضل لدي من هناك:
* "على مدى السنوات الخمس الماضية ، تطورت أدوات وتقنيات معالجة البيانات. لقد تطورت معظم التقنيات بالفعل لدرجة أنها يمكن أن تتكيف مع احتياجاتك ، ما لم تكن ، بالطبع ، تحتاج إلى معالجة بايت من البيانات أو بلايين الأحداث في اليوم.
إذا لم تكن بحاجة إلى تجاوز قدرات هذه التقنيات ، فمن الأرجح أنك لا تحتاج إلى فريق من المبرمجين المتخصصين لتطوير حلول إضافية.
إذا تمكنت من توظيفهم ، فسوف يصبحون مللين قريبًا. إذا شعروا بالملل ، فسوف يتركونك على Google و Facebook و LinkedIn و Twitter - الأماكن التي تكون فيها تجربتهم ضرورية حقًا. إذا لم يشعروا بالملل ، فمن المحتمل أن يكونوا متواضعين. وقد نجح المبرمجون المتوسطون حقًا في بناء قدر كبير من التعقيد وغير المناسب لهراء العمل العادي الذي يطلقون عليه "حلول". "*
يعجبني هذا الاقتباس لأنه لا يشدد فقط على أنك لا تحتاج اليوم إلى مهندسي بيانات لحل معظم مشكلات ETL ، بل تشرح أيضًا لماذا لا تطلب منهم حل هذه المشكلات على الإطلاق .
إذا قمت بتوظيف مهندسي بيانات وطلب منهم إنشاء خط أنابيب ، فسوف يعتقدون أن مهمتهم هي إنشاء خط أنابيب. هذا يعني أن أدوات مثل Stitch و Fivetran و dbt سوف تشكل تهديدًا لهم ، وليست مصدرًا قويًا للقوة. سيجدون أسبابًا لعدم تلبية خطوط الأنابيب الجاهزة لاحتياجاتك الفردية من البيانات ولماذا لا ينبغي للمحللين الدخول بشكل مستقل في تحويل البيانات. سوف يكتبون كودًا سيكون هشًا ، يصعب صيانته ، وغير فعال. وستعتمد على هذا الرمز لأنه يكمن وراء كل شيء آخر يقوم به فريقك.
اهرب من المتخصصين مثل الطاعون. سينخفض معدل النمو في فريق المحللين لديك انخفاضًا حادًا ، وسوف تقضي كل وقتك في حل مشاكل البنية التحتية ، وهذا ليس هو ما يدر دخلك على الإطلاق.
إن لم يكن ETL ، ثم ماذا؟
هل يحتاج فريقك بالفعل إلى مهندس بيانات؟ نعم
حتى مع وجود أدوات جديدة تتيح لمحللي البيانات وخبراء علم البيانات إنشاء خطوط أنابيب بأنفسهم ، لا يزال مهندسو البيانات جزءًا مهمًا من أي فريق بيانات محترف. ومع ذلك ، فإن المهام التي ينبغي أن تعمل عليها قد تغيرت ، والتسلسل الذي يستحق توظيف الموظفين للعمل مع البيانات. أدناه ، سأتحدث عن وقت القيام بذلك ، والآن دعونا نتحدث عن مهندسي البيانات في الشركات الناشئة الحديثة.
لا يزال مهندسو البيانات جزءًا مهمًا من أي فريق بيانات محترف.
لا ينبغي لمهندسي البيانات إنشاء خطوط أنابيب تتوفر لها بالفعل حلول جاهزة وكتابة تحويلات بيانات SQL. إليك ما يجب التركيز عليه:
- تنظيم وتحسين البنية التحتية للبيانات الأساسية ،
- بناء ودعم خطوط الأنابيب المخصصة ،
- دعم فريق من متخصصي البيانات من خلال تحسين تصميم وأداء خطوط الأنابيب والاستعلامات ،
- بناء تحويلات البيانات غير SQL.
تنظيم وتحسين البنية التحتية للبيانات الأساسية
على الرغم من أن مهندسي البيانات في الشركات الناشئة لم يعودوا بحاجة إلى إدارة مجموعات Hadoop أو تكوين المعدات لـ Vertica ، لا يزال العمل مطلوبًا في هذا المجال. بعد التأكد من أن التكنولوجيا الخاصة بك لجمع البيانات ونقلها ومعالجتها في ذروتها ، ستحصل على تحسن كبير في الأداء أو التكاليف أو كليهما. يتضمن هذا عادة المهام التالية:
- إنشاء بنية تحتية للمراقبة لتتبع حالة خطوط الأنابيب ،
- مراقبة جميع المهام التي تؤثر على أداء الكتلة ،
- الصيانة الدورية
- مخططات جدول الضبط (التقسيم ، الضغط ، التوزيع) لتقليل التكاليف وزيادة الإنتاجية ،
- تطوير البنية التحتية للبيانات المخصصة عند عدم وجود حلول جاهزة.
غالبًا ما يتم التغاضي عن هذه المهام في المراحل الأولى من التطوير ، لكنها تصبح مهمة مع نمو الفريق وكمية البيانات. في أحد المشروعات ، تمكنا من تخفيض تكلفة بناء طاولة في BigQuery تدريجياً من 500 دولار إلى 1 دولار يوميًا عن طريق تحسين أقسام الجدول. هذا مهم حقا.
يعد Uber مثالاً جيدًا على الشركة التي نجحت. قام متخصصو معالجة البيانات في Uber بإنشاء أداة تسمى Queryparser تتعقب جميع الطلبات تلقائيًا على البنية التحتية للبيانات الخاصة بهم وتجمع إحصائيات حول الموارد المستخدمة وأنماط الاستخدام. يمكن لمهندسي Uber Data استخدام البيانات الأولية لتخصيص البنية التحتية.
غالبًا ما يكون مهندسو البيانات مسؤولين عن بناء وصيانة خط أنابيب CI / CD الذي يدير البنية التحتية للبيانات. في عام 2012 ، كان لدى العديد من الشركات بنية تحتية ضعيفة جدًا للتحكم في الإصدارات وإدارتها واختبارها ، ولكن الآن كل شيء يتغير ، وهذا ما يقف وراءه مهندسو البيانات.
أخيرًا ، يشارك مهندسو البيانات في الشركات الرائدة غالبًا في إنشاء أدوات غير موجودة. على سبيل المثال ، أنشأ مهندسو Airbnb خدمة Airflow لأنهم لم يكن لديهم أي وسيلة لإنشاء دفاتر معالجة البيانات بكفاءة. ومهندسو Netflix مسؤولون عن إنشاء وصيانة بنية أساسية متطورة لتطوير وتشغيل عشرات الآلاف من أجهزة Jupyter Notebooks .
يمكنك فقط شراء معظم البنية الأساسية الخاصة بك ، ولكن لا يزال يتعين على شخص ما أن يخدمها. وإذا كنت شركة تقدمية بالفعل ، فربما تريد توسيع قدرات الأدوات الحالية. يمكن لمهندسي البيانات المساعدة في كليهما.
بناء وصيانة خطوط أنابيب مخصصة
على الرغم من أن مهندسي البيانات لم يعودوا بحاجة إلى نقل البيانات يدويًا إلى Postgres أو Salesforce ، فإن البائعين لديهم "فقط" حوالي 100 خيار تكامل. يمكن لمعظم عملائنا الوصول على الفور إلى 75 إلى 90٪ من مصادر البيانات التي يعملون بها.
في الممارسة العملية ، يتم التكامل عن طريق الأمواج. عادةً ما تتضمن المرحلة الأولى قاعدة بيانات التطبيق الرئيسية وتتبع الأحداث ، وتشمل المرحلة الثانية أنظمة التسويق مثل ESP والمنصات الإعلانية. اليوم ، حلول تسليم المفتاح لكلتا المرحلتين متاحة بالفعل للبيع. عندما تتعمق في التعامل مع البيانات من بائعي SaaS في مجال الموضوع الخاص بك ، ستحتاج إلى مهندسي البيانات لبناء خطوط أنابيب معالجة البيانات هذه والمحافظة عليها.
على سبيل المثال ، تتفاعل الشركات العاملة في مجال المبيعات عبر الإنترنت مع مجموعة من المنتجات المختلفة في مجال تخطيط موارد المؤسسات والخدمات اللوجستية والتسليم. العديد من هذه المنتجات هي محددة للغاية وتقريبا أي منها متاحة تجاريا. توقع من مهندسي البيانات أن يقوموا بإنشاء منتجات مماثلة في المستقبل المنظور.
يعد إنشاء خطوط أنابيب موثوقة لمعالجة البيانات وصيانتها مهمة صعبة. إذا قررت أن تستثمر مواردك في إنشائها ، فكن على استعداد لأن يتطلب ذلك أموالًا أكثر مما هو متصور في الميزانية ، وأن الصيانة ستحتاج أيضًا إلى بذل جهد أكبر مما كنت تخطط له. يمكن بناء الإصدار الأول من خط الأنابيب ببساطة ، ولكن من الصعب جعله يحافظ على تناسق البيانات في وحدة التخزين الخاصة بك. لا تلزم نفسك بالحفاظ على خط أنابيب معالجة البيانات الخاص بك حتى تتأكد من أن عملك يعمل. بمجرد القيام بذلك ، تأخذ من الوقت لجعلها موثوقة. فكر في استخدام Singer ، إطار عمل مفتوح المصدر من المبدعين في Stitch ، قمنا ببناء حوالي 20 تكاملًا باستخدامه.
دعم فريق من متخصصي البيانات من خلال تحسين تصميم وأداء خطوط الأنابيب والاستعلامات
أحد التغييرات التي رأيناها في مجال هندسة البيانات على مدى السنوات الخمس الماضية هو ظهور ELT - إصدار جديد من ETL ، والذي يحول البيانات بعد تحميلها في التخزين ، وليس قبل ذلك. لقد تم بالفعل تغطية جوهر هذا التغيير وأسبابه بالفعل في مصادر أخرى. أريد أن أؤكد أن هذا التحول له تأثير كبير على من يبني خطوط الأنابيب هذه.
إذا كتبت رمزًا على Scalding لمسح تيرابايت من بيانات الأحداث في S3 ثم تحميلها إلى Vertica ، فربما تحتاج إلى مهندس بيانات. ولكن إذا كانت بيانات الحدث (التي تم تصديرها من Google Analytics 360) موجودة بالفعل في BigQuery ، فهي متوفرة بالفعل بالكامل في بيئة عالية الأداء وقابلة للتطوير. الفرق هو أن هذه البيئة تتحدث SQL. هذا يعني أنه يمكن للمحللين الآن إنشاء خطوط أنابيب لتحويل البيانات الخاصة بهم.
تطور هذا الاتجاه في عام 2014 عندما أصدرت Looker أداة PDT . تكثف هذا الاتجاه عندما بدأت فرق كاملة من خبراء البيانات في بناء مخططات معالجة البيانات من أكثر من 500 عقدة ومعالجة مجموعات البيانات الكبيرة باستخدام dbt على مدار العامين الماضيين. في هذه المرحلة ، يتجذر النموذج بعمق في الفرق الحديثة ومنح المحللين قدرًا كبيرًا من الاستقلال كما كان دائمًا.
التبديل إلى ELT يعني أن مهندسي البيانات لم يعدوا بحاجة إلى أداء معظم مهام تحويل البيانات . وهذا يعني أيضًا أنه يمكن للفرق التي ليس بها مهندسون أن تقطع شوطًا طويلًا باستخدام أدوات تحويل البيانات المصممة للمحللين. ومع ذلك ، لا يزال مهندسو البيانات يلعبون دورًا مهمًا في بناء خطوط أنابيب تحويل البيانات. هناك حالتان تكون مشاركتهما في غاية الأهمية:
1. عندما تحتاج إلى زيادة الإنتاجية
في بعض الأحيان ، يتطلب منطق عملية العمل بعض التحولات المعقدة بشكل خاص ، ومن المفيد إشراك مهندس بيانات لتقييم كيفية تأثير نهج معين لإنشاء جدول على الأداء. العديد من المحللين ليس لديهم خبرة كبيرة في تحسين الأداء في مستودعات البيانات التحليلية ، وهذا سبب ممتاز لبدء العمل مع أخصائي أضيق.
2. عندما يحصل رمز معقدة للغاية
يحلل المحللون جيدًا في حل مشكلات العمل باستخدام البيانات ، لكن غالبًا لا يفكرون في كيفية كتابة التعليمات البرمجية القابلة للمد. للوهلة الأولى ، أصبح البدء في بناء الجداول في قاعدة البيانات أمرًا سهلاً ، لكن كل شيء يمكن أن ينفد سريعًا. قم بمشاركة مهندس بيانات يمكنه التفكير في البنية العامة لتخزينك وتطوير تحويلات معقدة بشكل خاص ، وإلا فإنك تخاطر بأن تترك بمفردك متشابكًا يكاد يكون من المستحيل كشفه.
بناء تحويلات البيانات غير SQL
يمكن لـ SQL في البداية تلبية معظم احتياجات تحويل البيانات ، لكنه لا يستطيع حل جميع المشكلات. على سبيل المثال ، من الضروري غالبًا إضافة بيانات جغرافية إلى قاعدة البيانات عن طريق أخذ خطوط الطول والعرض وربطها بمنطقة معينة. لا يمكن للعديد من المستودعات التحليلية الحديثة حل مثل هذه المشكلة (على الرغم من أن هذا قد بدأ يتغير! ) ، لذا فإن أفضل حل هو بناء خط أنابيب في بيثون ، والذي سيكمل البيانات الموجودة في مستودعك بمعلومات عن المنطقة.
حالة استخدام واضحة أخرى لبيثون (أو لغات أخرى بخلاف SQL) هي للتعلم الآلي. إذا كانت لديك توصيات مخصصة للمنتج ، أو نموذج للتنبؤ بالطلب ، أو خوارزمية للتنبؤ بالتدفق الخارجي تأخذ البيانات من السعة التخزينية وترتب الأوزان ، فيمكنك إضافتها كعقد نهاية لرسمة معالجة بيانات SQL الخاصة بك.
تستخدم معظم الشركات الحديثة التي تعمل على حل هذه المشكلات باستخدام SQL غير Airflow. يتم استخدام dbt للجزء المستندة إلى SQL من digraph البيانات ، ويتم إضافة العقد غير SQL كأوراق. تأخذ هذه الطريقة أفضل الطرق - إذ لا يزال محللو البيانات مسؤولين بشكل أساسي عن التحويلات القائمة على SQL ، ويمكن لمهندسي البيانات أن يكونوا مسؤولين عن كود ML للاستخدام الصناعي.
متى يحتاج فريقك إلى مهندس بيانات؟
تغيير دور مهندس البيانات يعني أيضًا إعادة التفكير في تسلسل توظيف الموظفين. كان يُعتقد سابقًا أنك تحتاج في المقام الأول إلى مهندسي البيانات ، لأن المحللين والمتخصصين في علوم البيانات ليس لديهم ما تعمل بدون منصة معالجة وتحليل جاهزة للبيانات. اليوم ، يمكن لمتخصصي تحليل ومعالجة البيانات العمل بشكل مستقل وإنشاء الإصدار الأول من البنية التحتية للبيانات باستخدام أدوات جاهزة. فكر في تعيين مهندس بيانات عندما يكون لدى بدء التشغيل الخاص بك أي من علامات القياس الأربعة:
- هناك 3 محللين / متخصصين في علوم البيانات في فريقك ،
- تحتوي منصة BI على 50 مستخدمًا نشطًا ،
- أكبر طاولة في التخزين تصل إلى مليار صف ،
- أنت تعلم أنك بحاجة إلى إنشاء 3 أو أكثر من خطوط أنابيب معالجة البيانات المخصصة خلال الأرباع القليلة القادمة ، وكلها مهمة.
إذا لم تواجه أيًا من هذه المواقف بعد ، فمن المحتمل أن يعمل فريقك من خبراء البيانات بمفردهم ، باستخدام التقنيات الجاهزة ، والدعم من الاستشاريين الخارجيين ومشورة الزملاء (على سبيل المثال ، في مجتمعات Optimistic أو dbt في Slack).
الشيء الرئيسي الذي يجب فهمه هو أن مهندس البيانات في حد ذاته ليس له قيمة بالنسبة إلى العمل ، وتتمثل مهمته الرئيسية في زيادة إنتاجية المحللين لديك. يتفاعل فريق خبراء البيانات الخاص بك مع أصحاب المصلحة ، ويقيس مؤشر الأداء الرئيسي وينشئ تقارير ونماذج - هذه هي التي تساعد عملك على التحرك في الاتجاه الصحيح كل يوم. يمكنك الاستعانة بمهندس بيانات لتعزيز فريق كبير حالي: إذا قمت بعد تعيين مهندس بيانات ، زادت كفاءة المحللين الأربعة بنسبة 33٪ ، فقد كان هذا على الأرجح حلاً جيدًا.
يستفيد مهندسو معالجة البيانات من الأعمال من خلال مساعدة المحللين وعلماء البيانات لديك على أن يكونوا أكثر إنتاجية.
في رأيي ، إذا قررت توسيع فريقك من متخصصي البيانات ، فإن أفضل نسبة هي ما يقرب من 5 إلى 1: خمسة محللين / متخصصين في علوم البيانات لكل مهندس بيانات. إذا كنت تعمل مع مجموعات بيانات كبيرة أو غير عادية ، فقد تتغير هذه النسبة ، لكن هذا دليل جيد.
من يستحق التوظيف؟
عندما يتغير دور مهندس البيانات ، تتغير متطلبات المرشح المثالي. قال زميلي العزيز مايكل كامينسكي جيدًا حول هذا الأمر في مراسلاتنا حول هذا الموضوع ، لذلك سأقتبسه هنا:
"أفكر في كل هذه التغييرات ، أولاً وقبل كل شيء ، حول دور مهندس البيانات في الفريق. من خالق البنية التحتية ، تحول إلى رابط دعم لمجموعة أوسع من المتخصصين. هذا تغيير كبير ، وبعض مهندسي البيانات (الذين يرغبون في التركيز على بناء البنية التحتية) ليسوا سعداء دائمًا بهذا.
أعتقد أن أهم شيء بالنسبة للشركات الناشئة هو تعيين مهندس بيانات مليء بالطاقة والرغبة في إنشاء أدوات لفريق من محللي / متخصصي علوم البيانات. إذا قمت بتعيين مهندس بيانات يريد فقط الخوض في الخلفية ويكره العمل مع أشخاص لديهم مهارات تقنية أقل ، فمن المحتمل أن ينتهي هذا بشكل سيء. أبحث عن مهندسي بيانات سعداء بالعمل مع المحللين والباحثين ومستعدون للقول: "ما تفعلونه يبدو لي غير فعال تمامًا ، وأريد إحداث تغيير للأفضل".
أنا أتفق تماما مع مايكل. الآن أفضل مهندسي البيانات في الشركات الناشئة هم دعم ودعم الفريق ، فهم يشاركون في كل ما يقوم به فريق البيانات تقريبًا. يجب أن يحبوا العمل الجماعي ويجب أن يكونوا متحمسين للنجاح كفريق واحد.
إذا وصلت إلى هذا المكان ، شكرًا للقراءة :) هذا الموضوع يقلقني كثيرًا. يرجى كتابة تعليق إذا كنت تعتقد أنني مخطئ تمامًا - أنا مهتم بمعرفة خبرتك في العمل مع مهندسي البيانات في فريقك.
أخيرًا ، إذا اتخذت قرارًا بتوظيف مهندس بيانات في الوقت الحالي ، فإن شركتي تجري الكثير من المقابلات مع مثل هؤلاء المتخصصين - نعتقد أن هذه طريقة جيدة لمواكبة هذه الصناعة. إذا كنت ترغب في ترتيب آخر اختبار أداء لعضو جديد محتمل في الفريق قبل تقديم عرض ، فسيسعدنا إجراء مقابلة أخيرة مع المرشحين لديك ، ما عليك إلا الكتابة إلينا!
تعليق من Gleb Sologub ، مدير التحليلات في Skyeng :
لدينا الآن في Skyeng أكثر من 30 محللًا كاملًا ولا يوجد مهندسون بيانات بعد. أصبح هذا ممكنًا لأن البنية الأساسية للبيانات بالكامل مبنية على الخدمات السحابية التي يتحدث عنها تريستان. نحن نستخدم Amazon Redshift كمستودع تحليلي و Stitch و Matillion ETL لجمع البيانات من أكثر من 40 قاعدة بيانات إنتاج ، Segment لجمع الأحداث ، Redash و Tableau للتقارير ولوحات المعلومات ، Amazon SageMaker for ML.
— - . , MVP- , , . , , , Tableau .
, , , - . , , : , .
- -, , , , . 90% , . , Skyeng.