تمت كتابة هذا المنشور بالتعاون مع كلوديا شيتو و جرعة سبيريدون من ACAST.

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

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

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

المشكلة

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

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

لدى Acast عدد متغير من فرق المنتجات، والتي تتطور باستمرار من خلال دمج الفرق الموجودة، أو تقسيمها، أو إضافة أشخاص جدد، أو ببساطة إنشاء فرق جديدة. في العامين الماضيين، كان لديهم ما بين 2 إلى 10 فريقًا، يتكون كل منهم من 20 إلى 4 أشخاص. يمتلك كل فريق حسابين على AWS على الأقل، وما يصل إلى 10 حسابات، حسب الملكية. يتم استخدام غالبية البيانات التي تنتجها هذه الحسابات لأغراض ذكاء الأعمال (BI) وفي أمازون أثينا، من قبل مئات من مستخدمي الأعمال كل يوم.

الحل الذي نفذته Acast هو شبكة بيانات، تم تصميمها على AWS. يعكس الحل الهيكل التنظيمي وليس القرار المعماري الواضح. وفقًا لمناورة Inverse Conway، تعرض البنية التكنولوجية لشركة Acast التماثل مع بنية الأعمال. في هذه الحالة، يتم تمكين مستخدمي الأعمال من خلال بنية شبكة البيانات للحصول على وقت أسرع للرؤى ومعرفة هوية المالكين الخاصين بالنطاق بشكل مباشر، مما يؤدي إلى تسريع التعاون. سيتم تفصيل ذلك بشكل أكبر عندما نناقش أدوار AWS Identity and Access Management (IAM) المستخدمة في شهادة AWS لدينا لأن أحد الأدوار مخصص لمجموعة الأعمال.

معلمات النجاح

نجحت Acast في تمهيد وتوسيع نطاق منتج بيانات جديد موجه نحو الفريق والمجال والبنية التحتية والإعدادات المقابلة له، مما أدى إلى تقليل الاحتكاك في جمع الرؤى وجعل المستخدمين والمستهلكين أكثر سعادة.

ويعني نجاح التنفيذ تقييم الجوانب المختلفة للبنية التحتية للبيانات وإدارة البيانات ونتائج الأعمال. وقاموا بتصنيف المقاييس والمؤشرات في الفئات التالية:

• استخدام البيانات – فهم واضح لمن يستهلك مصدر البيانات، والذي يتجسد من خلال رسم خرائط للمستهلكين والمنتجين. وأظهرت المناقشات مع المستخدمين أنهم كانوا أكثر سعادة لحصولهم على وصول أسرع إلى البيانات بطريقة أبسط، وتنظيم بيانات أكثر تنظيما، ورسم خرائط واضحة لمن هو المنتج. لقد تم إحراز الكثير من التقدم لتعزيز الثقافة القائمة على البيانات (محو الأمية البيانات، ومشاركة البيانات، والتعاون عبر وحدات الأعمال).
• مراقبة البيانات - من خلال تحديد كائن مستوى الخدمة الخاص بهم عندما تكون مصادر البيانات متاحة (من بين تفاصيل أخرى)، تعرف الفرق من يجب إخطاره ويمكنها القيام بذلك في وقت أقصر عندما تكون هناك بيانات متأخرة واردة أو مشكلات أخرى تتعلق بالبيانات. ومع وجود دور مشرف البيانات، تم تعزيز الملكية.
• إنتاجية فريق البيانات - من خلال الاسترجاعات الهندسية، وجدت Acast أن فرقها تقدر الاستقلالية في اتخاذ القرارات المتعلقة بمجالات البيانات الخاصة بها.
• كفاءة التكلفة والموارد - هذا هو المجال الذي لاحظت فيه Acast انخفاضًا في تكرار البيانات، وبالتالي تقليل التكلفة (في بعض الحسابات، إزالة نسخة البيانات بنسبة 100%)، من خلال قراءة البيانات عبر الحسابات مع تمكين التوسع.

نظرة عامة على شبكة البيانات

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

للتلخيص قبل التعمق في تنفيذ Acast، يعتمد مفهوم شبكة البيانات على المبادئ التالية:

• إنه يعتمد على المجال، على عكس خطوط الأنابيب باعتبارها اهتمامًا من الدرجة الأولى
• إنه يخدم البيانات كمنتج
• إنه منتج جيد يُسعد المستخدمين (البيانات جديرة بالثقة، والوثائق متوفرة، وقابلة للاستهلاك بسهولة)
• فهو يوفر حوكمة حسابية موحدة وملكية لا مركزية — منصة بيانات ذاتية الخدمة

بنية تعتمد على المجال

في نهج Acast لامتلاك مجموعات البيانات التشغيلية والتحليلية، يتم تنظيم الفرق وفقًا للملكية بناءً على المجال، والقراءة مباشرة من منتج البيانات، عبر واجهة برمجة التطبيقات (API) أو برمجيًا من تخزين Amazon S3 أو استخدام Athena كمحرك استعلام SQL. يتم عرض بعض الأمثلة على نطاقات Acast في الشكل التالي.

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

البيانات كمنتج

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

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

نظرًا لامتلاك كل فريق حساب AWS ومعرف كتالوج البيانات من Athena، فمن السهل رؤية ذلك من خلال عدسات بحيرة البيانات الموزعة أعلى Amazon S3، مع كتالوج مشترك يرسم خريطة لجميع الكتالوجات من جميع الحسابات.

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

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

كيف تم حل Acast للحصول على محاذاة عالية وبنية مقترنة بشكل غير محكم

يوضح الرسم البياني التالي بنية مفاهيمية لكيفية تنظيم فرق Acast للبيانات والتعاون مع بعضها البعض.

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

في مخطط البنية، يمكننا أن نرى أن كل فريق يمكن أن يكون منتجًا للبيانات، باستثناء الفريق الذي يمتلك الحساب المركزي، والذي يعمل كمنصة بيانات مركزية، ويصمم المنطق من مجالات متعددة لرسم صورة الأعمال الكاملة. يمكن لجميع الفرق الأخرى أن تكون منتجة للبيانات أو مستهلكة للبيانات. يمكنهم الاتصال بالحساب المركزي واكتشاف مجموعات البيانات عبر كتالوج AWS Glue Data عبر الحسابات، أو تحليلها في محرر استعلام Athena أو باستخدام دفاتر ملاحظات Athena، أو تعيين الكتالوج إلى حساب AWS الخاص بهم. يتم تنفيذ الوصول إلى كتالوج Athena المركزي باستخدام IAM Identity Center، مع أدوار البيانات المفتوحة والوصول المقيد إلى البيانات.

بالنسبة للبيانات غير الحساسة (البيانات المفتوحة)، يستخدم Acast قالبًا حيث تكون مجموعات البيانات مفتوحة افتراضيًا للمؤسسة بأكملها للقراءة منها، وذلك باستخدام شرط لتوفير معلمة المعرف المعينة من قبل المؤسسة، كما هو موضح في مقتطف التعليمات البرمجية التالي:

{
    "Version": "2012-10-17",
    "Statement": [
        
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
               "s3:GetObject*",
                "s3:GetBucket*",
                "s3:List*"  
            ],
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "ORG-ID-NUMBER"
                }
            }
        }
    ]
}

عند التعامل مع البيانات الحساسة مثل البيانات المالية، تستخدم الفرق نموذجًا تعاونيًا لإدارة البيانات. يعمل مشرف البيانات مع مقدم الطلب لتقييم مبرر الوصول لحالة الاستخدام المقصودة. ويحددون معًا طرق الوصول المناسبة لتلبية الحاجة مع الحفاظ على الأمان. يمكن أن يشمل ذلك أدوار IAM، أو حسابات الخدمة، أو خدمات AWS محددة. يمكّن هذا النهج مستخدمي الأعمال خارج المؤسسة التقنية (مما يعني أنه ليس لديهم حساب AWS) من الوصول بشكل مستقل إلى المعلومات التي يحتاجون إليها وتحليلها. من خلال منح الوصول من خلال سياسات IAM إلى موارد AWS Glue ومستودعات S3، يوفر Acast إمكانات الخدمة الذاتية مع الاستمرار في التحكم في البيانات الحساسة من خلال المراجعة البشرية. لقد كان دور مشرف البيانات ذا قيمة لفهم حالات الاستخدام، وتقييم المخاطر الأمنية، وتسهيل الوصول في نهاية المطاف الذي يؤدي إلى تسريع الأعمال من خلال الرؤى التحليلية.

بالنسبة لحالة استخدام Acast، لم تكن هناك حاجة إلى عناصر تحكم في الوصول على مستوى الصفوف أو الأعمدة، لذا كان هذا النهج كافيًا. ومع ذلك، قد تحتاج مؤسسات أخرى إلى حوكمة أكثر دقة في مجالات البيانات الحساسة. في تلك الحالات، حلول مثل تكوين بحيرة AWS يمكنه تنفيذ الأذونات المطلوبة، مع الاستمرار في توفير نموذج الوصول إلى البيانات ذاتي الخدمة. لمزيد من المعلومات، راجع صمم بنية شبكة بيانات باستخدام AWS Lake Formation و AWS Glue.

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

تعلم إضافية

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

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

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

وفي الختام

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

في الختام ، أ بنية البيانات الحديثة على AWS يتيح لك إنشاء منتجات البيانات والبنية التحتية لشبكات البيانات بكفاءة وبتكلفة منخفضة دون المساس بالأداء.

فيما يلي بعض الأمثلة على خدمات AWS التي يمكنك استخدامها لتصميم شبكة البيانات المطلوبة على AWS:

حول المؤلف

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

سبيريدون دوسيس هو متخصص في أمن المعلومات في Acast. تدعم Spyridon المنظمة في تصميم وتنفيذ وتشغيل خدماتها بطريقة آمنة لحماية بيانات الشركة والمستخدمين.

سريكانت داس هو مهندس حلول مختبر التسريع في Amazon Web Services. يتمتع بخبرة تزيد عن 13 عامًا في تحليلات البيانات الضخمة وهندسة البيانات، حيث يستمتع ببناء حلول موثوقة وقابلة للتطوير وفعالة. خارج العمل، يستمتع بالسفر وتدوين تجاربه على وسائل التواصل الاجتماعي.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/