DataLakes & DataWarehouses: كيف يتم استخدامها في تحسين محركات البحث

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

في هذه المقالة ، سنوجهك في تحديد الاختلافات بين DataLakes و DataWarehouses لفهم أغراضها وحالات استخدامها في تحسين محركات البحث وتحليلات الويب.

مستودع البيانات: مخزن منظم للبيانات

يعود أول استخدام لمصطلح "DataWarehouse" إلى عام 1988 في ورقة كتبها Paul Murphy و Barry Delvin ، وهي هندسة لأنظمة الأعمال والمعلومات . تعطينا هذه المقالة التعريف الأول للمفهوم كبيئة قاعدة بيانات علائقية يسهل الوصول إليها ، وتجمع جميع بيانات الأعمال المفيدة لاتخاذ القرارات الاستراتيجية.

ماذا يحتوي مستودع البيانات؟

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

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

من هم المستخدمون اليوميون لمخازن البيانات؟

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

كيف يتواصل المستخدمون مع مستودع البيانات؟

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

لغة البرمجة الأكثر استخدامًا للاستعلام في DataWarehouse هي SQL (أو اللغات المشابهة لـ SQL). تسمح SQL لمحللي البيانات بمعالجة البيانات ومعالجتها من أجل تلبية احتياجات العمل: المراقبة ، واتخاذ القرارات الاستراتيجية ، وما إلى ذلك.

ما حالات الاستخدام وأنواع المشاريع التي تخدمها مستودعات البيانات؟

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

تحسين مستودع البيانات:
غالبًا ما يتم مواجهة هذا النوع من المشروع عند إعداد DataWarehouse ، ولكن أيضًا عند تحديد حاجة جديدة أو حالة استخدام عمل.
يتعلق الأمر هنا بإضافة بيانات جديدة إلى DWH (مرة أخرى ، يمكن أن تكون هذه بيانات داخلية أو خارجية).
في هذه الحالة ، غالبًا ما نتحدث عن عملية ETL (استخراج - تحويل - تحميل):

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

تحقيق التحليلات الإحصائية:
هذا هو استخدام متكرر للغاية من DWHs. قد يكون الهدف هو إثبات X أو Y من خلال البيانات ، لإنتاج إحصائيات بناءً على البيانات التاريخية المتاحة ، أو إنشاء روابط سببية لشرح نتيجة ، إلخ.
الإبلاغ والتنبيه:
هذه ، مرة أخرى ، حالة استخدام متكررة جدًا. في الواقع ، نظرًا لأن البيانات الموجودة في DWH منظمة للغاية ومنسقة (مشاركة مخطط ثابت ومحدّد مسبقًا) ، فهي كلها مناسبة لدفع البيانات إلى لوحات المعلومات لإعداد التقارير أو التنبيه.

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

إذا قمنا بتلخيص كل هذه الأمور ، فلدينا نوعان أو أكثر من المشاريع: مشاريع الحصول على البيانات والتكامل (والتي يمكن مقارنتها أيضًا بشكل من أشكال تخزين البيانات والتأريخ) وتحليل البيانات ومشاريع التقييم (من خلال المراقبة / لوحة القيادة والتنبيه ).

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

هذا ليس هو الحال بالنسبة لمفهوم DataLakes ، وهو أصغر بكثير وأقل انتشارًا.

بيانات عند الزحف³

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

يتعلم أكثر

داتا ليك: بحيرة ميغاداتا (BigData)

يُنسب أصل هذا المفهوم إلى جيمس ديكسون ، كبير مسؤولي التكنولوجيا في Penthao ، الذي يعرفه بأنه حل لتخزين واستغلال كميات كبيرة من البيانات ، دون معالجة مسبقة وبدون بالضرورة حالة استخدام محددة ... على عكس DWHs ، والتي يتم توجيهها إلى حد كبير نحو التنشيط الفوري.
يحاول DL سد الفجوة ، التي تزداد أهمية مع ظهور BigData ، حول ما يجب فعله بكل هذه الكتلة من البيانات التي يمكننا جمعها اليوم وكيفية الاستفادة منها.

ماذا يحتوي DataLake؟

سأبدأ بالاقتباس من جيمس ديكسون الذي يستخدم مقارنة مثيرة للغاية ، حيث يقدم تفسيرًا لاسم "البحيرة" لمفهومه وكتمييز مع DWH:

"إذا كنت تفكر في datamart كمخزن للمياه المعبأة - منظفة ومعبأة ومهيكلة لسهولة الاستهلاك - فإن بحيرة البيانات هي كتلة كبيرة من المياه في حالة طبيعية أكثر. محتويات تيار بحيرة البيانات من مصدر لملء البحيرة ، ويمكن لمستخدمي البحيرة المتعددين القدوم لفحص العينات أو الغوص فيها أو أخذ عينات ".

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

حيث يتم تقييد DWH لاستيعاب البيانات المنظمة ، يتم إنشاء DataLake لتخزين جميع أنواع البيانات الأولية (منظمة أم لا). يمنحنا النقاش بين Tamara Dull (Amazon Web Service) و Anne Buff (Microsoft SAS) رؤية أكثر واقعية لمحتوى DataLake:

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

من هم المستخدمون اليوميون ل DataLakes؟

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

ما هي حالات الاستخدام وأنواع المشاريع التي تخدمها DataLakes؟

نظرًا لطبيعتها غير المهيكلة والحجم الكبير للبيانات التي يمكن أن تحتويها DataLake ، يمكن أن تكون حالات الاستخدام مختلفة جدًا عن تلك الموجودة سابقًا في إطار عمل DWH ، على سبيل المثال:

• تنفيذ خوارزميات التعلم الآلي لخلق قيمة مضافة لـ BigData:
  غالبًا ما نتحدث هنا عن التحليل التنبئي ، استنادًا إلى خوارزميات التعلم الآلي التي تستغل جميع أنواع البيانات.
  لنأخذ مثالًا أكثر واقعية ، دعنا نتخيل أن شركة في القطاع المالي (البنوك والتأمين) تريد تحديد احتمال أن تكون المعاملة المالية X احتيالية. قد يستدعي ذلك علماء البيانات ، القادرون على إنشاء خوارزميات التعلم الآلي التي ستتدرب على الكمية الفلكية من البيانات الموجودة في DataLake (المبلغ والتاريخ والتكرار والملف الشخصي المعتاد للمعاملات التي ينفذها مالك الحساب ، وما إلى ذلك). الهدف هو إجراء دراسة تنبؤية تُستخدم لتحديد المعاملات الاحتيالية المحتملة وبالتالي السماح للشركة بتقليل وقت رد الفعل في اكتشافها وتجنب الخسائر الكبيرة في النهاية لهم ولعملائهم.
  هذا مثال بسيط يتم استخدامه بانتظام لتوضيح الفائدة والقيمة المضافة للتعلم الآلي ، ولكن هناك العديد من الأمثلة الأخرى التي قد تتخيلها.
• DataLakes كمصدر بيانات لـ DataWarehouse:
  ببساطة شديدة ، يمكن أن يعمل DataLake كمنطقة عبور بين مصادر البيانات الداخلية والخارجية المتنوعة و DWH الخاص بك. يتمثل مبدأ DataLake في مركزية جميع أنواع البيانات ، المنظمة أو غير المهيكلة ، من أجل إجراء الدراسات التنبؤية عبر ML ، أو لاستخراجها كعينات للتحليل. لذلك يبدو DWH مناسبًا جدًا لهذه الفئة الثانية من المشروع ويستفيد من DataLake كمصدر محتمل (بشرط أن يتم استيراد بيانات DataLake بطريقة منظمة عبر المعالجة المسبقة ، إذا لزم الأمر).
• من برنامج DataLake إلى BI (ذكاء الأعمال):
  يمكننا أن نرى هذا باعتباره استخدامًا مشابهًا للاستخدام الذي رأيناه مع DataWarehouses ، اعتقدنا أن هناك بعض الخصائص المحددة لاستخدام DataLake لهذا الغرض. سيسمح لك برنامج DataLake بعمل تصورات أكثر غرابة قليلاً (نظرًا لتنوع البيانات التي يحتوي عليها) ، عبر أدوات مثل Tableau و Qlikview و Google Data Studio و Microstrategy وما إلى ذلك.

كيف يتواصل المستخدمون مع DataLake؟

بالنظر إلى حالات الاستخدام والمستخدمين (علماء البيانات) ، سنجد في كثير من الأحيان لغات برمجة مثل Python و Java و R و Scala وما إلى ذلك ...
بالنسبة للجزء الأكبر ، كانت هذه اللغات موجودة في مجال علم البيانات لفترة طويلة.

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

للتلخيص ، فيما يلي جدول بالعناصر المميزة التي تم إنشاؤها منذ بداية هذه المقالة:

التحليل التنبئي ، التعلم الآلي ، منطقة العبور بين مصادر البيانات و DWH ، التصور المتقدم - BI ، التحليل القائم على البيانات

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

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

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

مستودع البيانات و DataLake SEO

سنتحدث هنا عن DataWarehouse أو DataLake (أو كليهما) حيث يمكن استخدام جزء على الأقل من البيانات الموجودة في حالات استخدام تحسين محركات البحث.

لماذا ربط DataLakes و DataWarehouses بالتسويق وكبار المسئولين الاقتصاديين؟

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

• البيانات التحليلية (Google Analytics ، AT internet ، إلخ.)
• بيانات الأداء (Google Search Console ، Analytics)
• بيانات السجل ، "مصدر" بيانات كبير جدًا لبعض المواقع ، والتي تتطلب تكرار تحديث عالي وسعة تخزين كبيرة.
• بيانات Netlinking (Majestic ، Ahrefs ، Babbar)
• بيانات تحديد الموقع (SEMRush ، Monitorank ، إلخ.)
• بيانات الزحف (OnCrawl ، إلخ.)
• في بعض الأحيان بيانات الأعمال / الصناعة كذلك

إلى هذه القائمة ، يجب أيضًا أن نضيف استخدام واجهات برمجة التطبيقات للأدوات مثل Search Console و Majestic و Google Analytics على سبيل المثال ، مما يدفعنا بطبيعة الحال نحو نوع الحلول الموضحة سابقًا في هذه المقالة.
هذا الارتباط القوي بين مُحسّنات محرّكات البحث والبيانات هو الذي يدفع المزيد والمزيد من محللي الويب وخبراء تحسين محركات البحث للتعرف على طرق جديدة لتنظيم خط أنابيب البيانات الخاصة بهم.

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

حالات استخدام مستودع بيانات تحسين محركات البحث (SEO) أو DataLake لتحسين محركات البحث (SEO).

سأبدأ أولاً من نقاط الألم التي يواجهها خبراء تحسين محركات البحث (SEO) قبل شرح كيفية استخدام DataLake أو DataWarehouse هو إجابة يجب مراعاتها عند معالجتها.
من بين نقاط الألم الرئيسية ما يلي:

• مضاعفة ملفات Excel (الورقة السائبة لعقدنا) وما يرتبط بها من نسخ ولصق:
  بالنسبة للعديد من مُحسّنات محرّكات البحث ، لا يزال هذا هو المعيار ، ولكن لنكن صادقين ، فهو يستغرق وقتًا طويلاً ومقيّدًا ويؤدي إلى حدوث خطأ بشري. لهذا ، يعد مستودع البيانات حلاً مثاليًا. لا تسمح مستودعات البيانات فقط بجمع جميع مؤشرات الأداء الرئيسية المطلوبة لأداء هذا أو ذاك من عمليات التدقيق / التحليلات من مصادر البيانات المختلفة المتاحة ، ولكنها تسمح أيضًا بالمعالجة المطلوبة لتحقيق النتيجة المتوقعة لتكون آلية.
  نظرًا لبناء مستودع البيانات ، يتم تحديد المزيد والمزيد من حالات الاستخدام ويتم حل المزيد والمزيد من المشكلات ، مما يؤدي إلى توفير كبير للوقت بشكل متزايد بمرور الوقت.
• حدود السعة (كتذكير ، يمكن لبرنامج Excel فتح ملف كامل فقط إذا لم يتجاوز 1048576 سطرًا. يبدو هذا كثيرًا ، ولكنه ليس كثيرًا في مجلدات اليوم): لا توجد أي حالة استخدام معينة هنا ، لأنه في بشكل عام ، لا يعاني كل من DataLakes و DataWarehouses من هذا النوع من الحدود. كلاهما يوفر وسيلة لطلب كميات كبيرة من البيانات لأي نوع من الاحتياجات. بالنسبة لهذه الحالة المحددة ، من المهم أن تضع في اعتبارك أنه ، بناءً على الحاجة ، سيسمح لك أحدهما أو الآخر بتحرير نفسك من حدود السعة ، وفي النهاية ، معالجة هذه المواقف بسهولة أكبر.
• الاستجابة للحاجة إلى تأريخ البيانات
  Spoiler: يمكن أن تكون إحدى حالات الاستخدام ، على سبيل المثال ، حفظ محفوظات البيانات من Google Search Console في مستودع بيانات تحسين محركات البحث ، بدلاً من نسخ بياناتها وصفحة الصفحة في جداول بيانات Google كل أسبوع للحفاظ على لوحة بيانات استوديو البيانات. رأيي ، لدينا هنا واحدة من أكثر حالات الاستخدام شيوعًا بين خبراء تحسين محركات البحث ، سواء في الوكالات أو في الشركة: تأريخ البيانات. في الواقع ، ينظر العديد من محللي تحسين محركات البحث إلى البيانات التاريخية واستخلاص النتائج منها.
  المثال الذي قد يتبادر إلى ذهنك مباشرة هو حالة Google Search Console. إنه يوفر فقط الوصول إلى 16 شهرًا من التاريخ اليوم (حتى عبر API). وإذا ظل التراكم اليدوي ممكنًا من خلال عمليات التصدير ليتم لصقها في جداول بيانات Google كل أسبوع (أو طرق أخرى غامضة) ، فهذا يعد إهدارًا كبيرًا للوقت بالإضافة إلى كونه مؤلمًا ومملًا.
  هذا شيء جيد لأنه مشكلة بسيطة نسبيًا يجب معالجتها باستخدام DataWarehouse. كل ما عليك فعله هو إعداد اتصال تلقائي بواجهة برمجة تطبيقات Google Search Console ، وتحديد مختلف مجموعات البيانات والمعالجة المسبقة الممكنة اللازمة للحصول على البيانات ذات القيمة المضافة الحقيقية ، وأخيرًا أتمتة استدعاءات واجهة برمجة التطبيقات.
• الرغبة في إجراء مزيد من التحليلات ، لدمج أو "تحليل متقاطع" لبيانات الزحف ، وبيانات الجمهور ، والسجلات ، وما إلى ذلك بطريقة صناعية.
  لأن ميزة تنافسية صغيرة لا تضر أبدًا. الأوصاف التي قدمناها عن DataWarehouse و DataLake تتحدث عن نفسها هنا. أحد الأهداف الأساسية لكلتا الأداتين هو فتح إمكانيات جديدة للتحليل ، من خلال جمع البيانات والتحليل الشامل و / أو التعلم الآلي.
  للاستشهاد بمثال واحد فقط تمثيلي للغاية ؛ استخدام خوارزميات التعلم الآلي مثل Random Forest أو XG-Boost لعمل تنبؤات الترتيب على Google.
  بكل بساطة ، الفكرة هي تدريب خوارزمية على عدد كبير من Google SERPs (صفحات النتائج) وجميع مقاييس تحسين محركات البحث التي يمكن حصادها لـ SERPs من أجل تحديد ، بناءً على تلك المقاييس نفسها ، إمكانية التصنيف لعنوان URL معين (و لذلك ، وبشكل أكثر تحديدًا ، لتحديد أهم المقاييس التي يجب ترتيبها في قطاع / موضوع معين).
  → ستجد المنهجية الكاملة في مقالة فينسينت تيراسي ، مدير المنتج في Oncrawl ، "التنبؤ الناجح بتصنيفات Google في طليعة علم البيانات" ، 2018.
• الرغبة في أتمتة إعداد التقارير قدر الإمكان ، من أجل التركيز على المهام ذات القيمة المضافة العالية. مرة أخرى ، يقع هذا حرفيًا ضمن حالات الاستخدام الكلاسيكية لمخزن البيانات. إنه يوفر إمكانية أتمتة الاسترداد الكامل ومعالجة مصادر البيانات المختلفة ، وهو يعالج بشكل مثالي نقطة الألم هذه. بمجرد الإعداد ، سيتم تغذية الجدول تلقائيًا في DWH ويمكن استخدامه كاتصال ببرنامج BI الخاص بلوحة القيادة ، سواء للمراقبة أو التنبيه ، وما إلى ذلك بالطبع ، لا تتوقف الأتمتة عند الإبلاغ عن المشاريع وحدها. يمكن استخدام كل من DWH و DL للعديد من تحسينات تحسين محركات البحث الآلية. على سبيل المثال ، التحديثات الديناميكية لكتل ​​الارتباط الداخلية على الترتيب ، وميزانية الزحف ، وجمهور تحسين محركات البحث ، وما إلى ذلك (جميع البيانات الواردة في DWH).
• الرغبة في وضع حد نهائيًا للمخاوف الأمنية (نعرف من فعل ماذا وأين نجدها) وتجنب قضاء الوقت في الصيانة ، وننتهي هنا على جانب أكثر توجهاً نحو العملية من حالة الاستخدام ، بالمعنى الدقيق للكلمة.
  تتضمن كل من DataLakes ومستودعات البيانات تنفيذ عمليات معينة يمكن تقديمها بالطريقة المبسطة التالية:
  • نقطة البداية هي ملاحظة مقسمة إلى بيان بالاحتياجات (فريق العمل / تحسين محركات البحث - محلل البيانات).
  • بعد ذلك ، يتم تحويل هذا إلى مواصفات فنية أكثر تسمح للفريق الذي يدير الأداة بفهم ما يجب القيام به وكيف يجب القيام به.
  • يقوم نفس فريق الإدارة بتنفيذ الطلب.
  • يقدم فريق العمل ومحللو البيانات حالة استخدام إجرائية للعمل المنجز.
  • هناك عملية مستمرة يتأكد فيها طرفا السلسلة (فريق العمل وفريق الإدارة في DataWarehouse أو DataLake) من عدم تغير أي شيء من حيث المدخلات والمخرجات.
    هذا هو الحال بشكل خاص بالنسبة لـ DWH ، الذي سيرفض أي بيانات ليست جزءًا من الهيكل (المخطط المحدد مسبقًا).

مرة أخرى ، هذه قائمة غير شاملة بنقاط الألم وحالات الاستخدام المحتملة لـ DataWarehouse - DataLake SEO. يتم مواجهة القيود من خلال الافتقار إلى خيال أولئك الذين يستخدمونها أكثر من الأدوات نفسها.

اختيار DataWarehouse أو DataLake لاستخدامات SEO الخاصة بك

في الختام ، على عكس ما قد تسمعه أو تقرأه غالبًا ، تعد مستودعات البيانات و DataLakes هياكل منفصلة لتخزين البيانات وجمعها ، وليست غير متوافقة. ليست هناك حاجة لاختيار أحدهما على الآخر ، بل على العكس تمامًا. كلاهما له حالات استخدام مختلفة وهناك بعض الالتصاقات.

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