Erik Gfesser ، المهندس الرئيسي لممارسة البيانات في SPR - سلسلة المقابلات

انضم إريك إلى ممارسة البيانات الخاصة بـ SPRمجموعة التكنولوجيا الناشئة كمهندس رئيسي في 2018.

أصبح إريك متخصصًا في البيانات ، وتطوير المصادر المفتوحة باستخدام Java ، والهندسة العملية للمؤسسات ، بما في ذلك بناء PoCs ، والنماذج الأولية ، و MVPs.

ما الذي جذبك في البداية إلى التعلم الآلي؟

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

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

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

أنت مدافع ضخم عن المصادر المفتوحة ، هل يمكنك مناقشة سبب أهمية المصدر المفتوح؟

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

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

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

حدثت تجربتي الأولى مع المصدر المفتوح أثناء بناء منتج الرعاية الصحية الذي ذكرته سابقًا ، والاستفادة من الأدوات مثل Apache Ant ، المستخدمة في إنشاء البرامج ، ومنتج DevOps المبكر في ذلك الوقت المسمى Hudson (قاعدة الكود التي أصبحت فيما بعد Jenkins ). كان السبب الرئيسي وراء قراراتنا لاستخدام هذه المنتجات مفتوحة المصدر هو أنها إما قدمت حلولًا أفضل للبدائل التجارية ، أو كانت حلولًا مبتكرة لم تقدمها حتى الكيانات التجارية ، ناهيك عن الترخيص التجاري لبعض المنتجات التي كنا نستخدمها كان مقيدًا بشكل مفرط ، مما أدى إلى الروتين المفرط عندما حان وقت الحاجة إلى المزيد من التراخيص ، بسبب التكاليف المترتبة على ذلك.

بمرور الوقت ، رأيت العروض مفتوحة المصدر مستمرة في التطور ، مما يوفر ابتكارًا تمس الحاجة إليه. على سبيل المثال ، تم حل العديد من المشكلات التي ناضلنا أنا وزملائي معها لبناء منتج الرعاية الصحية هذا لاحقًا من خلال منتج Java مبتكر مفتوح المصدر بدأنا باستخدامه يسمى Spring Framework ، والذي لا يزال قوياً بعد أكثر من عقد من الزمن ، ونظامه البيئي تمتد الآن إلى ما هو أبعد من بعض الابتكارات التي قدمتها في البداية ، والتي يُنظر إليها الآن على أنها شائعة ، مثل حقن التبعية.

لقد استخدمت المصدر المفتوح لبناء PoCs والنماذج الأولية و MVPs. هل يمكنك مشاركة رحلتك وراء بعض هذه المنتجات؟

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

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

يلزم صراحة تصميم MVP الذي أنشأناه لهذا المنتج بحيث يمكن الاستمرار في إنشاء حالات استخدام إضافية فوقه ، على الرغم من أنها تأتي مع تنفيذ حالة استخدام واحدة ، لاكتشاف الانحراف في النفقات. على عكس هذا العميل ، كان للمنتج السابق الذي قمت بإنشائه بعض التاريخ وراءه قبل وصولي. في هذه الحالة ، كان أصحاب المصلحة يناقشون لمدة ثلاث سنوات (!) كيف يجب أن يتعاملوا مع منتج كانوا يتطلعون إلى بنائه. أوضح أحد العملاء التنفيذيين أن أحد الأسباب التي دفعته إلى إحضاري هو مساعدة الشركة على تجاوز بعض هذه المناقشات الداخلية ، خاصة وأن المنتج الذي كان يتطلع إلى بنائه يحتاج إلى تلبية التسلسل الهرمي للمنظمات المعنية.

توصلت إلى أن حروب النفوذ هذه كانت مرتبطة إلى حد كبير بالبيانات التي يمتلكها العميل والشركات التابعة له وعملائه الخارجيين ، لذلك في هذه الحالة ، تمحور تراكم المنتج بالكامل حول كيفية استيعاب هذه البيانات وتخزينها وتأمينها واستهلاكها لحالة الاستخدام الفردي التي تنشئ شبكات سريعة لمقدمي الرعاية الصحية لتحليل التكلفة.

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

بينما مراجعة كتاب "التعلم الآلي على نطاق المؤسسة" لقد ذكرت أن "استخدام المنتجات والأطر واللغات مفتوحة المصدر جنبًا إلى جنب مع بنية رشيقة تتألف من مزيج من المصادر المفتوحة والمكونات التجارية يوفر المرونة التي تحتاجها العديد من الشركات ولكن لا تدركها على الفور في البداية". هل يمكنك الخوض في بعض التفاصيل حول سبب اعتقادك أن الشركات التي تستخدم المصادر المفتوحة أكثر ذكاءً؟

تستخدم العديد من منتجات البيانات التجارية مكونات رئيسية مفتوحة المصدر تحت الغلاف ، وتمكن المطورين من استخدام لغات البرمجة الشائعة مثل Python. تعرف الشركات التي تصنع هذه المنتجات أن المكونات مفتوحة المصدر التي اختاروا دمجها تمنحهم بداية سريعة عندما يتم استخدامها بالفعل على نطاق واسع من قبل المجتمع.

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

بالإضافة إلى ذلك ، لا يتم إتاحة وثائق مثل هذه المكونات للجمهور إلى حد كبير ، مما يؤدي إلى استمرار اعتماد المطورين على هذه الشركات. عندما تكون المكونات مفتوحة المصدر المقبولة على نطاق واسع مثل Apache Spark هي التركيز المركزي ، كما هو الحال مع منتجات مثل Databricks Unified Analytics Platform ، يتم توفير العديد من هذه العناصر بالفعل في المجتمع ، مما يقلل من الأجزاء التي تحتاج فرق التطوير إلى الاعتماد على الكيانات التجارية للقيام بعملهم.

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

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

شيء آخر تعتقده بشأن المصدر المفتوح هو أنه يؤدي إلى "الوصول إلى مجتمعات مطورين قوية". ما هو حجم بعض هذه المجتمعات وما الذي يجعلها فعالة للغاية؟

يمكن أن تصل مجتمعات المطورين حول منتج مفتوح المصدر إلى مئات الآلاف. لا تشير معدلات التبني بالضرورة إلى قوة المجتمع ، ولكنها مؤشر جيد على أن هذا هو الحال بسبب ميلهم إلى إنتاج دورات حميدة. أنا أعتبر المجتمعات قوية عندما تنتج نقاشًا صحيًا وتوثيقًا فعالًا ، وحيث يتم التطوير النشط.

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

لقد قمت بمراجعة مئات الكتب على موقع الويب الخاص بك ، فهل هناك ثلاثة كتب يمكنك التوصية بها لقرائنا؟

في هذه الأيام أقرأ عددًا قليلاً جدًا من كتب البرمجة ، وفي حين أن هناك استثناءات ، فإن الحقيقة هي أنها عادة ما تكون قديمة جدًا بسرعة كبيرة ، وعادة ما يوفر مجتمع المطورين بدائل أفضل عبر منتديات المناقشة والوثائق. العديد من الكتب التي أقرأها حاليًا متاحة لي مجانًا ، إما من خلال النشرات الإخبارية التكنولوجية التي أشترك فيها ، أو من خلال النشرات الإخبارية للتكنولوجيا التي أشترك فيها ، أو من خلال المؤلفين والمعلنين الذين يتواصلون معي ، أو تلك التي ترسلها أمازون إلي. على سبيل المثال ، أرسلت أمازون لي دليلًا سابقًا للنشر غير مصحح لـ "The Lean Startup" لمراجعي في عام 2011 ، وقدم لي مفهوم MVP ، وأرسلت لي مؤخرًا نسخة من "Julia for Beginners".

(1) كتاب واحد من O'Reilly الذي أوصيت به هو "بحثًا عن قاعدة بيانات نيرفانا". يغطي المؤلف بالتفصيل التحديات التي تواجه محرك استعلام البيانات لدعم أعباء العمل التي تمتد عبر طيف OLTP من جهة ، إلى التحليلات على الطرف الآخر ، مع وجود أعباء عمل ذكاء الأعمال والتشغيل في المنتصف. يمكن استخدام هذا الكتاب كدليل لتقييم محرك قاعدة بيانات أو مجموعة من محركات الاستعلام والتخزين ، الموجهة نحو تلبية متطلبات عبء العمل ، سواء كانت معاملات أو تحليلية أو مزيجًا من هذين الاثنين. بالإضافة إلى ذلك ، فإن تغطية المؤلف لـ "بندول قاعدة البيانات المتأرجح" في السنوات الأخيرة تمت بشكل جيد بشكل خاص.

(2) في حين أن الكثير قد تغير في مساحة البيانات على مدى السنوات القليلة الماضية ، منذ استمرار تقديم منتجات تحليلات البيانات الجديدة ، "التحليلات التخريبية" يقدم تاريخًا قصيرًا ودودًا للسنوات الخمسين الماضية من الابتكار في التحليلات التي لم أرها في أي مكان آخر ، ويناقش نوعين من الاضطراب: الابتكار التخريبي ضمن سلسلة قيمة التحليلات ، وتعطيل الصناعة من خلال الابتكارات في التحليلات. من منظور الشركات الناشئة والعاملين في مجال التحليلات ، يتم تمكين النجاح من خلال تعطيل صناعاتهم ، لأن استخدام التحليلات لتمييز منتج ما هو وسيلة لإنشاء نموذج أعمال معطّل أو لإنشاء أسواق جديدة. من منظور الاستثمار في تكنولوجيا التحليلات لمؤسساتهم ، قد يكون اتباع نهج الانتظار والمراقبة منطقيًا لأن التقنيات المعرضة لخطر الانقطاع هي استثمارات محفوفة بالمخاطر بسبب الأعمار المفيدة المختصرة.

(3) أحد أفضل نصوص الأعمال التكنولوجية التي قرأتها هو "حدود الإستراتيجية"، من قبل أحد مؤسسي Research Board (الذي استحوذت عليه شركة Gartner) ، وهو مؤسسة فكرية دولية تبحث في التطورات في عالم الحوسبة وكيف ينبغي أن تتكيف الشركات. يقدم المؤلف ملاحظات مفصلة للغاية من العديد من محادثاته مع قادة الأعمال ، ويقدم تحليلاً ثاقبًا طوال الوقت حول تجاربه في بناء (مع زوجته) مجموعة من العملاء والشركات الكبرى التي تحتاج إلى دمج استراتيجياتها مع عالم الحوسبة المتفجر. كما علقت في مراجعتي ، فإن ما يميز هذا الكتاب عن الجهود الأخرى ذات الصلة هما خاصيتان متعارضتان على ما يبدو: اتساع نطاق الصناعة ، والعلاقة الحميمة التي لا تتوفر إلا من خلال التفاعل وجهًا لوجه.

أنت المهندس الرئيسي لممارسة البيانات في SPR. هل يمكنك وصف ما يفعله SPR؟

SPR هي شركة استشارية للتكنولوجيا الرقمية مقرها في منطقة شيكاغو ، وتقدم مشاريع تكنولوجية لمجموعة من العملاء ، من شركات Fortune 1000 إلى الشركات الناشئة المحلية. نحن نبني تجارب رقمية شاملة باستخدام مجموعة من القدرات التكنولوجية ، كل شيء بدءًا من تطوير البرامج المخصصة وتجربة المستخدم والبيانات والبنية التحتية السحابية ، إلى تدريب DevOps واختبار البرامج وإدارة المشاريع.

ما هي بعض مسؤولياتك مع SPR؟

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

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

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

ما هو المشروع المثير للاهتمام الذي تعمل عليه حاليًا مع SPR؟

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

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

هل هناك أي شيء آخر ترغب في مشاركته حول المصدر المفتوح أو SPR أو مشروع آخر تعمل عليه؟  

مشروع آخر (اقرأ عنه هنا و  هنا) قمت مؤخرًا بقيادة Databricks Unified Analytics Platform بنجاح ، وترحيل تنفيذ نماذج التعلم الآلي إليها من Azure HDInsight ، وهو توزيع Hadoop ، لمدير هندسة البيانات لشركة تأمين كبيرة.

كل هذه النماذج التي تم ترحيلها كانت تهدف إلى التنبؤ بمستوى تبني المستهلك الذي يمكن توقعه لمنتجات التأمين المختلفة ، حيث تم ترحيل بعضها من SAS قبل بضع سنوات في ذلك الوقت الذي انتقلت فيه الشركة إلى استخدام HDInsight. كان التحدي الأكبر هو ضعف جودة البيانات ، ولكن التحديات الأخرى تضمنت الافتقار إلى الإصدار الشامل ، والمعرفة القبلية ، والتوثيق غير المكتمل ، وتوثيق قواعد البيانات غير الناضجة والدعم فيما يتعلق باستخدام R في ذلك الوقت (تم للتو إتاحة تطبيق Azure لـ Databricks بشكل عام قبل بضعة أشهر من هذا المشروع).

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

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