أفكار الحل
تصف هذه المقالة فكرة الحل. يمكن لمهندس السحابة الخاص بك استخدام هذه الإرشادات للمساعدة في تصور المكونات الرئيسية لتنفيذ نموذجي لهذه البنية. استخدم هذه المقالة كنقطة بداية لتصميم حل جيد التصميم يتوافق مع المتطلبات المحددة لحمل العمل الخاص بك.
يتعلق هذا المثال بكيفية إجراء التحميل التزايدي في مسار استخراج وتحميل وتحويل (ELT ). ويستخدم Azure Data Factory لأتمتة البنية الأساسية لبرنامج ربط العمليات التجارية ELT. يقوم المسار ينقل أحدث بيانات OLTP بشكل متزايد من قاعدة بيانات SQL Server المحلية إلى Azure Synapse. يتم تحويل بيانات المعاملات إلى نموذج جدولي لتحليلها.
بناء الأنظمة
قم بتنزيل ملف Visio لهذه البنية.
تعتمد هذه البنية على تلك المعروضة في Enterprise BI باستخدام Azure Synapse، ولكنها تضيف بعض الميزات المهمة لسيناريوهات تخزين بيانات المؤسسة.
- أتمتة البنية الأساسية لبرنامج ربط العمليات التجارية باستخدام Data Factory.
- التحميل التزايدي.
- دمج مصادر متعددة للبيانات.
- تحميل البيانات الثنائية مثل بيانات الموضع الجيوفضائي والصور.
سير العمل
تتكون البنية من الخدمات والمكونات التالية.
مصادر البيانات
خادم SQL المحلي. توجد بيانات المصدر في قاعدة بيانات SQL Server في أماكن العمل. لمحاكاة البيئة المحلية. يتم استخدام نموذج قاعدة بيانات Wide World Importers OLTP كقاعدة بيانات المصدر.
بيانات خارجية. السيناريو الشائع لمستودعات البيانات هو دمج مصادر بيانات متعددة. تقوم هذه البنية المرجعية بتحميل مجموعة البيانات الخارجية المتضمنة سكان المدينة حسب السنة، وتدمجها مع البيانات من قاعدة بيانات OLTP. يمكنك استخدام هذه البيانات للحصول على رؤى مثل: "هل يتطابق نمو المبيعات في كل منطقة مع النمو السكاني أو يتجاوزه؟"
الإدخال وتخزين البيانات
تخزين كائن ثنائي كبير الحجم. يتم استخدام تخزين Blob كمنطقة التشغيل المرحلي للبيانات المصدر قبل تحميلها على Azure Synapse.
Azure Synapse. Azure Synapse هو نظام مُوزّع مصمم لأداء التحليلات على البيانات الكبيرة. وهو يدعم المعالجة المتوازية الضخمة (MPP)، مما يجعلها مناسبة لتشغيل التحليلات عالية الأداء.
Azure Data Factory. Data Factory هي خدمة مُدارة تقوم بتنسيق حركة البيانات وتحويل البيانات وأتمتتها. في هذه البنية، تنسق المراحل المختلفة لعملية ELT.
التحليل وإعداد التقارير
Azure Analysis Services. «خدمات التحليل» هي خدمة مُدارة بالكامل توفر إمكانيات تكوين نماذج البيانات. يتم تحميل النموذج الدلالي على Analysis Services.
Power BI. إن Power BI عبارة عن مجموعة من أدوات تحليل الأعمال لتحليل البيانات من أجل رؤى الأعمال. في هذه البنية، تستعلم عن النموذج الدلالي المخزن في Analysis Services.
المصادقة
يصادق معرف Microsoft Entra المستخدمين الذين يتصلون بخادم Analysis Services من خلال Power BI.
يمكن ل Data Factory أيضا استخدام معرف Microsoft Entra للمصادقة على Azure Synapse، باستخدام كيان الخدمة أو هوية الخدمة المدارة (MSI).
المكونات
- مخزن البيانات الثنائية كبيرة الحجم لـ Azure
- Azure Synapse Analytics
- Azure Data Factory
- خدمات تحليل Azure
- Power BI
- معرِّف Microsoft Entra
تفاصيل السيناريو
البنية الأساسية لبرنامج ربط العمليات التجارية للبيانات
في Azure Data Factory، فإن البنية الأساسية لبرنامج ربط العمليات التجارية هي تجميع منطقي للأنشطة المستخدمة لتنسيق مهمة — في هذه الحالة، تحميل البيانات وتحويلها إلى Azure Synapse.
تُعرّف هذه البنية المرجعية البنية الأساسية الأصل لبرنامج ربط العمليات التجارية التي تقوم بتشغيل سلسلة من المسارات الفرعية. يقوم كل مسار فرعي بتحميل البيانات في جدول مستودع بيانات واحد أو أكثر.
التوصيات
التحميل التزايدي
عند تشغيل عملية ETL أو ELT المؤتمتة، فإنها الطريقة الأكثر فعالية لتحميل البيانات التي تغيرت منذ التشغيل السابق فقط. يسمى ذلك بالتحميل التزايدي، على خلاف التحميل الكامل الذي يقوم بتحميل جميع البيانات. لتنفيذ تحميل تزايدي، تحتاج إلى إيجاد طريقة لتحديد البيانات التي تغيرت. إن السياسة الأكثر شيوعًا هي استخدام قيمة علامة مائية عالية، ما يعني تتبع أحدث قيمة لبعض الأعمدة في الجدول المصدر، إما عمود التاريخ والوقت أو عمود العدد الصحيح الفريد.
انطلاقًا من SQL Server 2016، يمكنك استخدام جداول المعالجة الزمنية. هذه هي الجداول التي تم إصدارها من النظام والتي تحتفظ بمحفوظات كاملة عن التغييرات المُجراة في البيانات. يسجل محرك قاعدة البيانات تلقائيًا محفوظات كل تغيير تم إجراؤه في جدول منفصل للمحفوظات. يمكنك الاستعلام عن البيانات التاريخية عن طريق إضافة عبارة FOR SYSTEM_TIME إلى استعلام. داخليًا، يستعلم محرك قاعدة البيانات عن جدول المحفوظات، ولكنه واضح للتطبيق.
إشعار
بالنسبة للإصدارات السابقة من SQL Server، يمكنك استخدام Change Data Capture (CDC). إن ذلك الأسلوب أقل ملاءمة من جداول المعالجة الزمنية، حيث يجب عليك الاستعلام عن جدول التغيير المنفصل، ويتم تعقب التغييرات بواسطة رقم تسلسل السجل، بدلاً من الطابع الزمني.
إن جداول المعالجة الزمنية مفيدة لبيانات البعد، التي يمكن تغييرها بمرور الوقت. تمثل جداول الحقائق عادةً معاملة غير قابلة للتغيير مثل البيع، حيث لا يبدو الاحتفاظ بمحفوظات إصدار النظام منطقيًا. بدلاً من ذلك، عادة ما تحتوي المعاملات على عمود يمثل تاريخ المعاملة، ويمكن استخدامه كقيمة العلامة المائية. على سبيل المثال، في قاعدة بيانات Wide World Importers OLTP، تحتوي جداول Sales.Invoices و Sales.InvoiceLines على حقل LastEditedWhen
يجعل الإعداد الافتراضي على sysdatetime()
.
فيما يلي التدفق العام للبنية البنية الأساسية لبرنامج ربط العمليات التجارية لـ ELT:
لكل جدول في قاعدة البيانات المصدر، قم بتعقب وقت التوقف حيث شُغّلت آخر مهمة لـ ELT. قم بتخزين هذه المعلومات في مستودع البيانات. (في الإعداد الأولي، يتم تعيين جميع الأوقات على "1-1-1900".)
أثناء خطوة تصدير البيانات، يتم تمرير وقت القطع كمعلمة إلى مجموعة من الإجراءات المُخزّنة في قاعدة البيانات المصدر. تستعلم هذه الإجراءات المُخزّنة عن أي سجلات تم تغييرها أو إنشاؤها بعد وقت التوقف. بالنسبة لجدول حقائق Sales، يتم استخدام عمود
LastEditedWhen
. بالنسبة للبيانات البعيد، يتم استخدام جداول المعالجة الزمنية التي أصدرها النظام.عند اكتمال ترحيل البيانات، قم بتحديث الجدول الذي يخزن أوقات التوقف.
من المفيد أيضًا تسجيل دورة الحياة لكل عملية تشغيل لـ ELT. بالنسبة لأي سجل معين، تربط دورة حياة البيانات هذا السجل بعملية تشغيل مهمة ELT التي أنتجت البيانات. لكل عملية تشغيل لمهمة ETL، يتم إنشاء سجل دورة حياة جديدة للبيانات لكل جدول، مما يعرض أوقات بداية التحميل ونهايتها. يتم تخزين مفاتيح دورة حياة البيانات لكل سجل في جداول الأبعاد وجداول الحقيقة.
بعد تحميل دفعة جديدة من البيانات في المستودع، قم بتحديث النموذج الجدولي لـ Analysis Services. راجع التحديث غير المتزامن باستخدام «واجهة برمجة تطبيقات» REST.
تنقية البيانات
يجب أن يكون تطهير البيانات ضمن عملية ELT. في هذه البنية المرجعية، يعد أحد مصادر البيانات غير الصحيحة هو جدول سكان المدينة، حيث لا يوجد عدد سكاني في بعض المدن، ربما بسبب عدم توفر البيانات. أثناء المعالجة، تزيل البنية الأساسية لبرنامج ربط العمليات التجارية لـ ELT تلك المدن من جدول سكان المدينة. قم بتنظيف البيانات من جداول التقسيم المرحلي، بدلاً من الجداول الخارجية.
مصادر البيانات الخارجية
غالبًا ما تقوم مستودعات البيانات بدمج البيانات من مصادر متعددة. على سبيل المثال، مصدر بيانات خارجي يحتوي على بيانات ديموغرافية. تتوفر مجموعة البيانات في تخزين Azure blob ضمن نموذج WorldWideImportersDW.
يمكن لـ Azure Data Factory إجراء النسخ مباشرةً من تخزين blob، باستخدام موصل تخزين blob. ومع ذلك، يتطلب الموصل سلسلة اتصال أو توقيع وصول مشترك، لذلك لا يمكن استخدامه لنسخ blob مع وصول القراءة العام. كحل بديل، يمكنك استخدام PolyBase لإنشاء جدول خارجي عبر تخزين Blob ثم نسخ الجداول الخارجية إلى Azure Synapse.
التعامل مع البيانات الثنائية الكبيرة
على سبيل المثال، في قاعدة البيانات المصدر، يحتوي جدول المدينة على عمود الموقع الذي يحتوي على نوع بيانات جغرافية مكانية . لا يدعم Azure Synapse نوع الجغرافيا في الأصل، لذلك يتم تحويل هذا الحقل إلى نوع الثنائي المتغير أثناء التحميل. (راجع الحلول البديلة لأنواع البيانات غير المدعومة.)
ومع ذلك، يدعم PolyBase الحد الأقصى لحجم العمود البالغ varbinary(8000)
، مما يعني أنه يمكن اقتطاع بعض البيانات. إن الحل البديل لهذه المشكلة هو تقسيم البيانات إلى مجموعات أثناء التصدير، ثم إعادة تجميع المجموعات، على النحو التالي:
قم بإنشاء جدول تقسيم مرحلي مؤقت لعمود «الموقع».
في كل مدينة، قم بتقسيم بيانات الموقع إلى مجموعات تبلغ 8000 بايت، مما يؤدي إلى صفوف 1 - N لكل مدينة.
لإعادة تجميع المجموعات، استخدم عامل تشغيل PIVOT T-SQL لتحويل الصفوف إلى أعمدة ثم تتسلسل قيم الأعمدة لكل مدينة.
تتمثل الصعوبة في تقسيم كل مدينة إلى عدد مختلف من الصفوف، اعتمادًا على حجم البيانات الجغرافية. لكي يعمل عامل تشغيل PIVOT، يجب أن يكون لكل مدينة عدد الصفوف نفسه. لجعل هذا العمل، يقوم استعلام T-SQL ببعض الحيل لتجميد الصفوف بقيم فارغة، بحيث يكون لكل مدينة نفس عدد الأعمدة بعد العرض المحوري. يتضح أن الاستعلام الناتج هو أسرع بكثير من التكرار عبر الصفوف واحدًا تلو الآخر.
يتم استخدام الأسلوب نفسه لبيانات الصورة.
الأبعاد بطيئة التغير
إن بيانات البعد ثابتة نسبيًا، ولكنها قد تتغير. على سبيل المثال، قد يتم إعادة تعيين منتج إلى فئة مختلفة من المنتج. توجد العديد من الأساليب للتعامل مع الأبعاد بطيئة التغير. إن التقنية الشائعة، التي تسمى النوع 2، هي إضافة سجل جديد كلما تغير البعد.
لتنفيذ سياسة النوع 2، تحتاج جداول الأبعاد إلى أعمدة إضافية تحدد نطاق تاريخ السريان لسجل معين. وكذلك، سيتم تكرار المفاتيح الأساسية من قاعدة البيانات المصدر، لذلك يجب أن يحتوي جدول الأبعاد على مفتاح أساسي اصطناعي.
على سبيل المثال، تعرض الصورة التالية جدول Dimension.City. إن عمود WWI City ID
هو المفتاح الأساسي من قاعدة البيانات المصدر. إن عمود City Key
هو مفتاح اصطناعي تم إنشاؤه أثناء البنية الأساسية لبرنامج ربط العمليات التجارية لـ ETL. لاحظ أيضًا أن الجدول يحتوي على أعمدة Valid From
و Valid To
، التي تحدد النطاق عندما كان كل صف صالحًا. إن القيم الحالية Valid To
لتساوي '9999-12-31'.
تكمن ميزة هذا السياسة في أنه يحافظ على البيانات التاريخية، التي يمكن أن تكون ذات قيمة في التحليل. ومع ذلك، فهذا يعني أيضًا أنه سيكون هناك صفوف متعددة للكيان نفسه. على سبيل المثال، فيما يلي السجلات التي تطابق WWI City ID
= 28561:
لكل حقيقة مبيعات، قد ترغب في ارتباط هذه الحقيقة بصف واحد في جدول الأبعاد للمدينة، المطابق لتاريخ الفاتورة.
الاعتبارات
تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.
الأمان
ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. للمزيد من المعلومات، يرجى الرجوع إلى نظرة عامة على ركيزة الأمان.
لمزيد من الأمان، يمكنك استخدام نقاط تقديم خدمة «الشبكة الظاهرية» لتأمين موارد خدمة Azure إلى شبكتك الظاهرية فقط. يزيل ذلك الوصول العام إلى الإنترنت إلى الموارد الكاملة، مما يسمح فقط بنسبة استخدام الشبكة من شبكتك الافتراضية.
باستخدام هذا الأسلوب، يمكنك إنشاء «شبكة ظاهرية» في Azure ثم إنشاء نقاط تقديم خدمة خاصة لخدمات Azure. ثم تقتصر هذه الخدمات على نسبة استخدام الشبكة من تلك الشبكة الظاهرية. يمكنك أيضًا الوصول إليها من شبكتك المحلية من خلال بوابة.
كن على علم بالقيود التالية:
إذا تم تمكين نقاط تقديم الخدمة لـ Azure Storage، لا يمكن لـ PolyBase أن تنسخ البيانات من «التخزين» إلى Azure Synapse. يوجد سبيل لتخفيف هذه المشكلة. لمزيد من المعلومات، راجع تأثير استخدام نقاط تقديم خدمة VNet باستخدام Azure storage.
لنقل البيانات من أماكن العمل إلى Azure Storage، ستحتاج إلى السماح بعناوين IP العامة من الموقع المحلي أو ExpressRoute. للحصول على التفاصيل، راجع تأمين خدمات Azure للشبكات الظاهرية.
لتمكين Analysis Services من قراءة البيانات من Azure Synapse، قم بنشر «الجهاز الظاهري» لنظام تشغيل Windows إلى الشبكة الظاهرية التي تحتوي على نقطة تقديم خدمة Azure Synapse. قم بتثبيت Azure On-premises Data Gateway على هذا «الجهاز الظاهري». ثم قم بتوصيل خدمة Azure Analysis ببوابة البيانات.
DevOps
قم بإنشاء مجموعات موارد منفصلة لبيئات التشغيل والتطوير والاختبار. تسهل مجموعات الموارد المنفصلة إدارة عمليات التوزيع وحذف عمليات التوزيع التجريبية وتعيين حقوق الوصول.
ضع كل حمل عمل في قالب توزيع منفصل، وقم بتخزين الموارد في أنظمة التحكم بالمصادر. يمكنك توزيع القوالب معاً أو بشكل فردي كجزء من عملية CI/CD، مما يجعل عملية الأتمتة أسهل.
في هذه البنية، هناك ثلاثة أحمال عمل رئيسية:
- خادم مستودع البيانات وAnalysis Services والموارد ذات الصلة.
- Azure Data Factory.
- سيناريو محاكاة محلي إلى سحابي.
كل حِمل عمل له قالب توزيع خاص به.
يتم إعداد خادم مستودع البيانات وتكوينه باستخدام أوامر Azure CLI التي تتبع النهج الضروري لممارسة IaC. ضع في اعتبارك استخدام البرامج النصية للتوزيع ودمجها في عملية التنفيذ التلقائي.
ضع في اعتبارك تنظيم أحمال عملك. قم بالتوزيع في مراحل مختلفة، وقم بإجراء فحوصات التحقق من الصحة في كل مرحلة قبل الانتقال إلى المرحلة التالية. بهذه الطريقة يمكنك دفع التحديثات إلى بيئات الإنتاج الخاصة بك بطريقة خاضعة للتحكم بدرجة عالية وتقليل مشكلات التوزيع غير المتوقعة. استخدم إستراتيجيات التوزيع الأزرق والأخضر وإصدارات Canary لتحديث بيئات الإنتاج الحية.
احصل على إستراتيجية تراجع جيدة للتعامل مع عمليات التوزيع الفاشلة. على سبيل المثال، يمكنك إعادة توزيع عملية توزيع سابقة وناجحة تلقائياً من محفوظات التوزيع الخاصة بك. راجع معلمة علامة --rollback-on-error في Azure CLI.
Azure Monitor هو الخيار الموصى به لتحليل أداء مستودع البيانات ونظام التحليلات Azure الأساسي بالكامل للحصول على تجربة مراقبة متكاملة. Azure Synapse Analytics توفر تجربة مراقبة داخل مدخل Microsoft Azure لإظهار نتائج تحليلات لأحمال عمل مستودع البيانات. مدخل Microsoft Azure هي الأداة الموصى بها عند مراقبة مستودع البيانات لأنها توفر فترات استبقاء قابلة للتكوين وتنبيهات وتوصيات ومخططات ولوحات معلومات قابلة للتخصيص للقياسات والسجلات.
لمزيد من المعلومات، راجع قسم DevOps في Microsoft Azure Well-Architected Framework.
تحسين التكلفة
يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.
استخدم حاسبة تسعير Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات للخدمات المستخدمة في هذه البنية المرجعية.
Azure Data Factory
يقوم Azure Data Factory بأتمتة البنية الأساسية لبرنامج ربط العمليات التجارية ELT. تنقل البنية الأساسية لبرنامج ربط العمليات التجارية البيانات من قاعدة بيانات SQL Server المحلية إلى Azure Synapse. ثم يتم تحويل البيانات إلى نموذج جدولي لتحليلها. بالنسبة لهذا السيناريو، يبدأ التسعير من تشغيل نشاط بقيمة 0.001 دولار شهريًا المتضمن تشغيل النشاط، والمشغل، وتصحيح الأخطاء. يعد ذلك السعر الرسوم الأساسية فقط للتنسيق. كما يتم تحصيل رسوم منك مقابل أنشطة التنفيذ، مثل نسخ البيانات وعمليات البحث والأنشطة الخارجية. يتم تسعير كل نشاط بشكل فردي. كما يتم تحصيل رسوم منك مقابل البنية الأساسية لبرنامج ربط العمليات التجارية بدون مشغلات أو عمليات تشغيل مرتبطة خلال الشهر. يتم تقسيم جميع الأنشطة بالتناسب بالدقيقة وتقريبها.
مثال لتحليل التكلفة
ضع في اعتبارك حالة الاستخدام حيث يوجد نشاطان لعمليات البحث من مصدرين مختلفين. يستغرق أحدهما 1 دقيقة واحدة و 2 ثانية (يقترب من دقيقتين) ويستغرق الآخر 1 دقيقة واحدة مما يؤدي إلى مجموع وقت مدته 3 دقائق. يستغرق النشاط الواحد لنسخ البيانات 10 دقائق. يستغرق النشاط الواحد للإجراء المُخزّن 2 دقيقة. يُشغّل إجمالي النشاط لمدة 4 دقائق. يتم حساب التكلفة على النحو التالي:
تشغيل النشاط: 4 * 0.001 دولار = 0.004 دولار
عمليات البحث: 3 * (0.005 دولار / 60) = 0.00025 دولار
الإجراء المُخزّن: 2 * (0.00025 دولار / 60) = 0.000008 دولار
نسخ البيانات: 10 * (0.25 دولار / 60) * 4 وحدات تكامل بيانات (DIU) = 0.167 دولار
- التكلفة الإجمالية لكل عملية تشغيل للبنية الأساسية لبرنامج ربط العمليات التجارية: 0.17 دولار.
- التشغيل مرة واحدة يوميًا لمدة 30 يوما: 5.1 دولار شهريًا.
- التشغيل مرة واحدة يوميًا لكل 100 جدول لمدة 30 يومًا: 510 دولار
إن لكل نشاط تكلفة مرتبطة به. افهم نموذج التسعير واستخدم حاسبة تسعير ADF للحصول على حل لا يُحسّن الأداء فحسب بل أيضًا التكلفة. يمكنك إدارة التكاليف من خلال بدء تشغيل خدماتك، وإيقافها، وإيقافها مؤقتًا، وتحجيمها.
Azure Synapse
يعد Azure Synapse مثالي لأحمال العمل المكثفة التي لديها متطلبات عالية لأداء الاستعلام وقابلية لتوسع الحساب. يمكنك اختيار نموذج الدفع أولاً بأول أو استخدام الخطط المحجوزة لسنة واحدة (توفير 37%) أو 3 سنوات (توفير 65%).
يتم شحن تخزين البيانات بشكل منفصل. يتم أيضاً دفع تكلفة خدمات أخرى مثل الإصلاح بعد كارثة واكتشاف التهديدات بشكل منفصل.
لمزيد من المعلومات، راجع أسعار Azure Synapse.
Analysis Services
تعتمد أسعار Azure Analysis Services على الطبقة. يستخدم التطبيق المرجعي لهذه البنية طبقة Developer، الموصى بها للتقييم والتطوير والاختبار. تشمل المستويات الأخرى، المستوى الأساسي، الموصى به لبيئة الإنتاج الصغيرة؛ المستوى القياسي لتطبيقات الإنتاج ذات المهام الحرجة. لمزيد من المعلومات، راجع الطبقة الصحيحة عندما تحتاجها.
لا يتم تطبيق أي رسوم عند إيقاف المثيل مؤقتًا.
لمزيد من المعلومات، راجع أسعار خدمات تحليل Azure.
مخزن البيانات الثنائية الكبيرة
ضع في اعتبارك استخدام ميزة سعة التخزين المحجوزة في Azure لتقليل تكلفة التخزين. مع هذا النموذج، تحصل على خصم إذا كان بإمكانك الالتزام بالحجز لسعة تخزين ثابتة لمدة عام أو ثلاث سنوات. لمزيد من المعلومات، راجع تحسين تكاليف تخزين Blob بالسعة المحجوزة.
لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.
الخطوات التالية
- مقدمة إلى Azure Synapse Analytics
- البدء باستخدام Azure Synapse Analytics
- مقدمة إلى مصنع البيانات Azure
- ما هو Azure Data Factory؟
- البرامج التعليمية ل Azure Data Factory
الموارد ذات الصلة
قد ترغب في مراجعة سيناريوهات أمثلة Azure التالية التي توضح حلولاً محددة باستخدام بعض التقنيات نفسها: