‫Cloud Spanner: ذكاء الرسم البياني باستخدام خوارزميات Spanner Graph

1. دراسة حالة: Intelligent Retail

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

التحديات الأساسية التي يجب معالجتها في المؤسسة

تواجهك أربعة تحديات مهمة تتطلّب فهم كيفية ترابط العملاء والخدمات اللوجستية:

التحدي

المشكلة

الهدف

فجوة التأثير

تحقّق الإعلانات الواسعة النطاق عائد استثمار منخفضًا، ولا يمكن حاليًا تحديد صانعي الموضة الحقيقيين (المؤثرين).

تحديد المؤثرين الذين يشكّلون محورًا أساسيًا في المنتدى من خلال علاقاتهم في شبكة متصلة من العملاء

المرونة اللوجستية

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

تحديد جهات التحكّم بالوصول ، أي الجهات التي لها دور أساسي في ربط شبكات الخدمات اللوجستية ببعضها

الشبكات المتخفية

تستخدم عصابات الاحتيال ملفات شخصية مزيّفة وعناوين مشتركة للتنسيق بشأن عمليات السرقة وزيادة التقييمات بشكل مصطنع.

الكشف عن الجزر المعزولة ، أي المجموعات شديدة الترابط التي لا صلة لها بالمجتمع الشرعي

مفارقة الاختيار

محرك الاقتراحات الحالي بسيط وعام وغالبًا ما يتم تجاهله (على سبيل المثال، "العملاء الذين اشتروا هذا المنتج اشتروا أيضًا ...").

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

ربط تحديات النشاط التجاري باستراتيجية فنية (الصفوف → العلاقات)

في قاعدة البيانات التقليدية، يتم تخزين البيانات في مستودعات معزولة: العملاء في جدول واحد، والمعاملات في جدول آخر، والشحن في جدول ثالث. في حين أنّ SQL مثالية للإجابة عن السؤال "مَن اشترى ماذا؟"، يصعب عليها الإجابة عن الأسئلة المستندة إلى الشبكة.

لحلّ هذه التحديات، يجب أن تركّز الاستراتيجية الفنية على تغيير هذا المنظور:

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

نظرة متعمّقة على المتطلبات

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

كيفية استيفاء Cloud Spanner لهذه المتطلبات الفنية

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

في ما يلي ملخّص سريع حول كيفية تلبية Cloud Spanner للمتطلبات الفنية وغيرها.

بالإضافة إلى ذلك، يوفّر Cloud Spanner بنية فنية متطوّرة.

2. إعداد Data foundation

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

إعداد مثيل Cloud Spanner Enterprise

الخطوة 1: تفعيل Cloud Spanner API

في وحدة تحكّم Google Cloud، انقر على رمز القائمة في أعلى يمين الشاشة للانتقال إلى القائمة الجانبية اليمنى. انتقِل للأسفل واختَر "Spanner"، أو ابحث عن "Spanner".

من المفترض أن تظهر لك الآن واجهة مستخدم Cloud Spanner، وإذا كنت تستخدم مشروعًا لم يتم تفعيل Cloud Spanner API فيه بعد، سيظهر لك مربّع حوار يطلب منك تفعيله. إذا سبق لك تفعيل واجهة برمجة التطبيقات، يمكنك تخطّي هذه الخطوة.

انقر على "تفعيل" للمتابعة:

1d9ce329b076805a.png

الخطوة 2: إنشاء مثيل Cloud Spanner

أولاً، عليك إنشاء مثيل Cloud Spanner. في واجهة المستخدم، انقر على إنشاء آلة افتراضية مُدارة لإنشاء آلة افتراضية جديدة.

في الخطوة الأولى، عليك اختيار إصدار. يُرجى العِلم أنّه يمكنك ترقية الإصدار بعد ذلك أيضًا. لاستخدام إمكانات النماذج المتعددة (Spanner Graph)، يمكننا استخدام إصدار Enterprise.

c44a0b5b5ba24877.png

تسمية الآلة الافتراضية

9cf487f702beece3.png

اختَر إعدادات النشر ومنطقة من اختيارك.

f2c4c364703aecf.png

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

عند ضبط السعة، يمكنك إما البدء بعُقدة كاملة وتوسيع نطاقها تلقائيًا، أو يمكنك استخدام مثيل دقيق (وحدات معالجة؛ 1000 وحدة معالجة = عُقدة واحدة). يمكنك أيضًا بشكل اختياري ضبط أهداف التوسّع التلقائي للمثيل. بالنسبة إلى أحمال العمل التي تتطلّب وقت استجابة منخفضًا، ننصح باستخدام 65% للآلات الافتراضية على مستوى منطقة واحدة و45% للآلات الافتراضية على مستوى مناطق متعدّدة.

6325a8561bbc61c7.png

الخطوة 3: إنشاء قاعدة بيانات

بعد توفير مثيلك، انقر على "إنشاء قاعدة بيانات" لإنشاء قاعدة بيانات لبقية الدرس العملي.

422b0317859ec7df.png

وضع أساس علاقات قوي

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

لغة تعريف البيانات (DDL): إنشاء الجداول

انسخ المربّعات التالية ونفِّذها لإنشاء مخططك العلائقي:

-- NODE: Customer (Parent)
CREATE TABLE Customer (
  customer_id STRING(60) NOT NULL,
  customer_email STRING(32),

  -- Placeholder fields for Algorithm results
  pagerank_score FLOAT64,        
  centrality_score FLOAT64,      
  community_id INT64            
) PRIMARY KEY(customer_id);

-- EDGE: CustomerFriendship (Interleaved in Customer)
CREATE TABLE CustomerFriendship (
  customer_id STRING(60) NOT NULL,
  friend_id STRING(60) NOT NULL,
  friendship_strength FLOAT64,
  created_at TIMESTAMP,
  CONSTRAINT FK_Friend FOREIGN KEY(friend_id) REFERENCES Customer(customer_id)
) PRIMARY KEY(customer_id, friend_id),
  INTERLEAVE IN PARENT Customer ON DELETE CASCADE;

-- NODE: Product
CREATE TABLE Product (
  product_id STRING(60) NOT NULL,
  product_name STRING(32),
  unit_price FLOAT64,
  pagerank_score FLOAT64
) PRIMARY KEY(product_id);

-- NODE: Shipping
CREATE TABLE Shipping (
  shipping_id STRING(60) NOT NULL,
  city STRING(32),
  country STRING(32)
) PRIMARY KEY(shipping_id);

-- EDGE: Transactions (Interleaved in Customer)
CREATE TABLE Transactions (
  customer_id STRING(60) NOT NULL,
  row_id STRING(36) DEFAULT (GENERATE_UUID()),
  product_id STRING(60) NOT NULL,
  shipping_id STRING(60) NOT NULL,
  transaction_date TIMESTAMP,
  amount FLOAT64,
  CONSTRAINT FK_Prod FOREIGN KEY(product_id) REFERENCES Product(product_id),
  CONSTRAINT FK_Ship FOREIGN KEY(shipping_id) REFERENCES Shipping(shipping_id)
) PRIMARY KEY(customer_id, row_id),
  INTERLEAVE IN PARENT Customer ON DELETE CASCADE;

تعبئة الشبكة

بعد أن تصبح جداولنا جاهزة، يجب ملؤها بالمستخدمين والمنتجات والروابط التي تحدّد المنظومة المتكاملة للعميل.

-- Populate Products & Shipping
INSERT INTO Product (product_id, product_name, unit_price) VALUES
('P1', 'Smartphone Pro', 999.00), ('P2', 'Wireless Earbuds', 150.00),
('P3', 'USB-C Cable', 25.00), ('P4', '4K Monitor', 450.00),
('P5', 'Ergonomic Chair', 300.00), ('P6', 'Desk Lamp', 45.00);

INSERT INTO Shipping (shipping_id, city, country) VALUES
('S1', 'New York', 'USA'), ('S2', 'London', 'UK'), ('S3', 'Tokyo', 'Japan'),
('S4', 'San Francisco', 'USA'), ('S5', 'Berlin', 'Germany');

-- Populate Customers
INSERT INTO Customer (customer_id, customer_email) VALUES
('C1', 'alice@example.com'), ('C2', 'bob@example.com'), ('C3', 'charlie@example.com'),
('C4', 'david@example.com'), ('C5', 'eve@example.com'), ('C6', 'frank@example.com'),
('C7', 'grace@example.com'), ('C8', 'heidi@example.com'), ('C9', 'ivan@example.com'),
('C10', 'judy@example.com'), ('C11', 'mallory@example.com'), ('C12', 'trent@example.com');

-- Populate Friendships
INSERT INTO CustomerFriendship (customer_id, friend_id, friendship_strength, created_at) VALUES
('C1', 'C2', 1.0, CURRENT_TIMESTAMP()), ('C1', 'C3', 1.0, CURRENT_TIMESTAMP()), 
('C2', 'C1', 0.8, CURRENT_TIMESTAMP()), ('C3', 'C1', 0.9, CURRENT_TIMESTAMP()),
('C3', 'C4', 0.5, CURRENT_TIMESTAMP()), ('C4', 'C5', 0.5, CURRENT_TIMESTAMP()),
('C5', 'C6', 1.0, CURRENT_TIMESTAMP()), ('C5', 'C7', 0.8, CURRENT_TIMESTAMP()), 
('C7', 'C8', 0.7, CURRENT_TIMESTAMP()), ('C8', 'C5', 0.6, CURRENT_TIMESTAMP()),
('C11', 'C1', 1.0, CURRENT_TIMESTAMP()), ('C11', 'C5', 1.0, CURRENT_TIMESTAMP()), 
('C11', 'C7', 1.0, CURRENT_TIMESTAMP()), ('C11', 'C12', 0.5, CURRENT_TIMESTAMP()),
('C1', 'C11', 0.9, CURRENT_TIMESTAMP()), ('C5', 'C11', 0.9, CURRENT_TIMESTAMP()),
('C9', 'C10', 1.0, CURRENT_TIMESTAMP()), ('C10', 'C9', 1.0, CURRENT_TIMESTAMP());

-- Populate Transactions
INSERT INTO Transactions (customer_id, product_id, shipping_id, amount, transaction_date) VALUES
('C1', 'P1', 'S1', 999.00, CURRENT_TIMESTAMP()), ('C2', 'P1', 'S1', 999.00, CURRENT_TIMESTAMP()),
('C11', 'P4', 'S4', 450.00, CURRENT_TIMESTAMP()), ('C11', 'P5', 'S4', 300.00, CURRENT_TIMESTAMP()),
('C7', 'P5', 'S5', 300.00, CURRENT_TIMESTAMP()), ('C8', 'P6', 'S5', 45.00, CURRENT_TIMESTAMP()),
('C9', 'P1', 'S1', 999.00, CURRENT_TIMESTAMP()), ('C10', 'P1', 'S1', 999.00, CURRENT_TIMESTAMP());

تحدّي العلاقات

قبل أن نعرض الرسم البياني، دعونا نرى كيف تتعامل لغة SQL التقليدية مع تحديات العميل. نفِّذ طلب البحث هذا للعثور على العملاء "المسرفين اجتماعيًا" الذين ينفقون مبالغ كبيرة ولديهم العديد من الأصدقاء.

SELECT 
    c.customer_id, 
    c.customer_email,
    SUM(t.amount) AS total_spent,
    COUNT(DISTINCT f.friend_id) AS friend_count
FROM Customer AS c
LEFT JOIN Transactions AS t ON c.customer_id = t.customer_id
LEFT JOIN CustomerFriendship AS f ON c.customer_id = f.customer_id
GROUP BY c.customer_id, c.customer_email
HAVING total_spent > 500
ORDER BY total_spent DESC;

عيوب المنهج العلائقي

التغلّب على التحديات العلائقية من خلال رسم بياني للعلاقات

للتغلّب على هذه الحدود، نحدّد رسمًا بيانيًا للعلاقات. يؤدي ذلك إلى إنشاء "تراكب" يتيح لنا التعامل مع العلاقات كعناصر أساسية بدون نقل بياناتنا من Spanner.

DDL: إنشاء الرسم البياني للعناصر

تحدّد لغة تعريف البيانات هذه العُقد (الكيانات) والحواف (العلاقات). في هذا المثال، نتبع رسمًا بيانيًا مخططًا، ولكن يتيح Spanner Graph إنشاء رسومات بيانية بدون مخطط لتفعيل عملية تطوير مرنة وسريعة ومتكررة والتعامل مع نماذج البيانات المتطورة بدون تغييرات مستمرة في DDL (لغة تعريف البيانات).

CREATE OR REPLACE PROPERTY GRAPH RetailTransactionGraph
NODE TABLES (
  Customer KEY (customer_id),
  Product KEY (product_id),
  Shipping KEY (shipping_id)
)
EDGE TABLES (
  CustomerFriendship AS IsFriendsWith
    SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
    DESTINATION KEY (friend_id) REFERENCES Customer (customer_id)
    LABEL IsFriendsWith,
    
  Transactions AS Purchased
    SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
    DESTINATION KEY (product_id) REFERENCES Product (product_id)
    LABEL Purchased,

  Transactions AS LivesAt
    SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
    DESTINATION KEY (shipping_id) REFERENCES Shipping (shipping_id)
    LABEL LivesAt
);

بعد تحديد الرسم البياني، يمكننا استخدام لغة طلبات الرسم البياني (GQL) لتنفيذ عمليات اجتياز متعددة الخطوات باستخدام بنية بسيطة وسهلة القراءة.

الاستكشاف 1: استكشاف المحتوى بشكل تعاوني

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

GRAPH RetailTransactionGraph
MATCH (me:Customer)-[:IsFriendsWith]->(friend:Customer)-[:Purchased]->(p:Product)
WHERE me.customer_id = 'C1'
RETURN 
    me.customer_id AS my_id, 
    friend.customer_id AS friend_id, 
    p.product_name AS recommendation

الاستكشاف 2: طلب البحث المختلط (علائقي + بياني)

يتيح لك Spanner تضمين أنماط GQL داخل عبارة FROM عادية في SQL باستخدام الدالة GRAPH_TABLE. يجد هذا الطلب العملاء الذين يعيشون في الموقع الجغرافي نفسه الذي يعيش فيه أصدقاؤهم، وهو تطابق بنمط "معيّن".

SELECT *
FROM GRAPH_TABLE(RetailTransactionGraph
  MATCH (a:Customer)-[:IsFriendsWith]-(b:Customer),
        (a)-[:LivesAt]->(loc:Shipping),
        (b)-[:LivesAt]->(loc)
  RETURN a.customer_id AS user_A, b.customer_id AS user_B, loc.city
)

تصوُّر علاقات العميل

أخيرًا، لنستخدِم GQL لتصوّر شبكتنا. تغلف هذه الطلبات نتائج المسار في SAFE_TO_JSON، ما يسمح لأدوات العرض برسم العُقد والخطوط.

تصوُّر الشخص المؤثّر الفائق

تُبرز هذه الصورة "مالوري" (C11) ومدى وصولها المباشر إلى الجمهور على وسائل التواصل الاجتماعي.

GRAPH RetailTransactionGraph
MATCH p = (c:Customer {customer_id: 'C11'})-[:IsFriendsWith]->(f:Customer)
RETURN SAFE_TO_JSON(p) AS social_paths

f0c713fc048cd0a5.png

تصوُّر أنماط الاحتيال المحتملة

يستأصل طلب البحث هذا "المجموعة المعزولة" (إيفان وجودي) لمعرفة الأماكن التي يتم شحن منتجاتها إليها.

GRAPH RetailTransactionGraph
MATCH p = (c:Customer)-[:Purchased]->(prod:Product),
      q = (c)-[:LivesAt]->(loc:Shipping)
WHERE c.customer_id IN ('C9', 'C10')
RETURN SAFE_TO_JSON(p) AS purchase_path, SAFE_TO_JSON(q) AS shipping_path

3- مقدمة حول خوارزميات Spanner Graph

للاستعداد لنظرة متعمّقة في Graph Intelligence، يوضّح هذا القسم البنية الفنية والقواعد الأساسية لخوارزميات Cloud Spanner Graph. ويُعدّ فهم هذه المبادئ أساسيًا للانتقال من عمليات البحث البسيطة إلى تحليل العلاقات على نطاق واسع جدًا.

مجموعة الخوارزميات

يتوافق Cloud Spanner حاليًا مع 14 خوارزمية رسوم بيانية متوافقة مع معايير المجال، ومصنّفة في أربع مجموعات وظيفية لحلّ مشاكل متنوعة في الأنشطة التجارية:

Category (الفئة)

الخوارزميات المتوافقة

حالة استخدام النشاط التجاري

المركزية

نظام ترتيب الصفحات، ونظام ترتيب الصفحات المخصّص، والوساطة، والقرب

تحديد المؤثّرين والمراكز ونقاط الاختناق

المجتمع

WCC، ونشر التصنيفات، والعثور على المجموعات المتماسكة، والتجميع حسب التشابه

رصد شبكات الاحتيال والمنتديات الاجتماعية والمجموعات المعزولة

التشابه

Jaccard وCosine وCommon Neighbors وTotal Neighbors

تشغيل محركات الاقتراحات وحلّ الكيانات

العثور على المسار

أدوات مساعدة في مسار "إحصاءات Google"، وأقصر مسار من مجموعة إلى مجموعة

تحسين الخدمات اللوجستية وقرب المسارات

اعتبارات مهمة بشأن المخطط والطلب

لضمان تنفيذ خوارزميات Graph بكفاءة، يجب أن تلتزم Spanner Graph بالقواعد التالية:

المتطلب 1: توزيع البيانات الفعلي (التداخل)

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

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

المتطلب 2: متطلبات وضع الملصقات الفريدة

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

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

المنطق

مثال

النتيجة

❌ سيئ

جداول العُقد (كيان LABEL الخاص بالشخص، كيان LABEL الخاص بالحساب)

غير صالح: لا يمكن للخوارزمية التمييز بين "شخص" و"حساب".

✅ جيد

جداول العُقد (العميل ذو التصنيف Person، والحساب ذو التصنيف Account)

صالح: يحتوي كل كيان على تصنيف مميز وفريد.

المتطلب 3: بنية طلب البحث في الخوارزمية (عبارة MATCH)

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

  • نمط واحد لكل MATCH: يمكن لكل عبارة MATCH تحديد متغيّر واحد فقط.
  • عدم استخدام أنماط متعددة العُقد: لا يمكنك تحديد نمط علاقة (مثل (a)-[e]->(b)) مباشرةً داخل عبارة MATCH مخصّصة لاستدعاء خوارزمية.
  • الفلاتر الحرفية فقط: على الرغم من أنّه يمكنك استخدام عبارات WHERE لفلترة العُقد (مثل WHERE a.id > 400)، إلا أنّ مَعلمات طلب البحث (@param) غير متاحة حاليًا في طلبات البحث الخاصة بخوارزميات الرسوم البيانية.

المتطلب 4: عبارة RETURN (القيم العددية فقط)

تعمل عبارة RETURN في طلب بحث الخوارزمية كجسر بين عالم الرسم البياني وعالم العلاقات. يقتصر هذا النوع من الدوال بشكلٍ صارم على عرض قيم عددية وثوابت.

  • القاعدة: لا يمكنك عرض "عنصر رسم بياني" (عقدة أو عنصر حافة أولي).
  • بدون تحويلات: لا يمكنك إجراء عمليات رياضية أو تطبيق دوال على السمات التي يتم عرضها ضمن عبارة RETURN نفسها.

قيود عبارة RETURN

✅ متاح

❌ غير متاح

RETURN node.id, score

عقدة RETURN، النتيجة (لا يمكن إرجاع عنصر الرسم البياني)

RETURN PATH_LENGTH(p)

RETURN node.id + 1, score (No operations on properties)

RETURN node.name

RETURN JSON_OBJECT(node.id, score) (بدون دوال)

المتطلب 5: سلامة البيانات: إزالة الحواف المعلقة

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

  • الحل: استخدِم قيودًا مرجعية (مفاتيح خارجية) وON DELETE CASCADE للحفاظ على تكامل الرسم البياني.
  • أمان طلب البحث: عند استدعاء خوارزمية، يجب التأكّد من أنّ جميع العُقد المشار إليها بواسطة الحواف المحدّدة مضمّنة أيضًا في وسيطة node_labels.

الناتج الثابت: خيارات "تصدير البيانات"

بما أنّ خوارزميات الرسوم البيانية تتطلّب الكثير من العمليات الحسابية، يتم تنفيذها في وضع التنفيذ الموسّع باستخدام عبارة EXPORT DATA. تستفيد هذه الميزة من Data Boost، وذلك باستخدام موارد حوسبة مستقلة بدون خادم لمنع أي تأخير في معاملات الإنتاج.

الخيار 1: إعادة البيانات إلى Cloud Spanner

لدفع النتائج مباشرةً إلى جداولك (مثل حفظ نتيجة PageRank)، استخدِم format = ‘CLOUD_SPANNER'.

  • update_ignore_all: تعدّل هذه السمة الصفوف التي تتضمّن مفاتيح متوفّرة في الجدول المستهدف.
  • ‫upsert_ignore_all: تعدّل الصفوف الحالية أو تُدرج صفوفًا جديدة إذا كانت المفاتيح غير متوفّرة.
EXPORT DATA OPTIONS (
  format = 'CLOUD_SPANNER',
  table = 'Customer',
  write_mode = 'update_ignore_all'
) AS
GRAPH RetailTransactionGraph
CALL PageRank(...)
RETURN node.customer_id, score;

الخيار 2: الاحتفاظ بالنتائج في Google Cloud Storage (GCS)

لإجراء تحليل بلا إنترنت على نطاق واسع، يمكنك التصدير إلى GCS بتنسيقات CSV أو Avro أو Parquet.

  • أحرف البدل: استخدِم uri => 'gs://bucket/file_*.csv' لتفعيل الإخراج المجزّأ، ما يتيح لـ Spanner الكتابة إلى ملفات متعددة بالتوازي لمجموعات البيانات الضخمة.
  • الضغط: تتوافق مع GZIP وSNAPPY وZSTD لتحسين تكاليف التخزين.
EXPORT DATA OPTIONS (
  uri = 'gs://bucket/pagerank_*.csv',
  format = 'CSV',
  overwrite = true
) AS
GRAPH RetailTransactionGraph
CALL PageRank(...)
RETURN node.customer_id, score;

4. التحدي 1: فجوة التأثير (PageRank)

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

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

لحلّ هذه المشكلة، علينا ترتيب عملائنا حسب التأثير.

الحلّ العلائقي (المركزية حسب الدرجة)

في قاعدة بيانات عادية، أسهل طريقة للعثور على مؤثّر هي ببساطة احتساب عدد متابعيه (وهو مقياس يُعرف باسم المركزية حسب الدرجة).

نفِّذ طلب البحث هذا للعثور على المستخدمين الأكثر "شهرة":

SELECT 
    friend_id AS customer_id, 
    COUNT(*) AS follower_count
FROM CustomerFriendship
GROUP BY friend_id
ORDER BY follower_count DESC;

customer_id

follower_count

الزيّ 1

3

الزيّ 5

3

الزيّ 11

2

الزيّ 7

2

الزيّ 10

1

الزيّ 12

1

الزيّ 2

1

الزيّ 3

1

الزيّ 4

1

الزيّ 6

1

الزيّ 8

1

الزيّ 9

1

الذكاء المستند إلى الرسوم البيانية (PageRank)

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

  • نموذج المتصفّح العشوائي: يحاكي PageRank مستخدمًا يتنقّل في الرسم البياني. يمثّل عامل التخميد (القيمة التلقائية 0.85) احتمال مواصلة المستخدمين النقر، وإلا سيتم "نقلهم" إلى عقدة عشوائية .
  • قوة الارتباط: إنّ الرابط الوارد من شخص مؤثّر (مثل "مالوري") يساوي قيمة أكبر بكثير من الرابط الوارد من شخص ليس لديه أي روابط أخرى.

سننفّذ خوارزمية PageRank ونستخدم EXPORT DATA لحفظ النتائج مباشرةً في عمود pagerank_score .

EXPORT DATA OPTIONS (
  format = 'CLOUD_SPANNER',
  table = 'Customer',
  write_mode = 'update_ignore_all' -- Updates existing rows
) AS
GRAPH RetailTransactionGraph
CALL PageRank(
  node_labels => ['Customer'],      -- Target our Customer nodes 
  edge_labels => ['IsFriendsWith'], -- Analyze the social ties
  damping_factor => 0.85,           -- Standard decay
  max_iterations => 10              -- Higher iterations for better precision
)
YIELD node, score               
RETURN node.customer_id, score as pagerank_score;

لوحة بيانات"التأثير" باستخدام PageRank

بعد حفظ النتائج، لنقارن بين "قبل" (عدد المتابعين) و"بعد" (نتيجة PageRank).

-- Note that Higher PageRank score means more influential
SELECT 
    c.customer_id, 
    c.customer_email,
    count_query.follower_count,
    c.pagerank_score
FROM Customer c
JOIN (
    SELECT friend_id, COUNT(*) AS follower_count 
    FROM CustomerFriendship GROUP BY friend_id
) AS count_query ON c.customer_id = count_query.friend_id
ORDER BY c.pagerank_score DESC;

customer_id

customer_email

follower_count

pagerank_score

الزيّ 5

eve@example.com

3

0.158392489

الزيّ 10

judy@example.com

1

0.1093561724

الزيّ 9

ivan@example.com

1

0.1093561724

الزيّ 1

alice@example.com

3

0.1000888124

الزيّ 8

heidi@example.com

1

0.09759821743

الزيّ 11

mallory@example.com

2

0.09466411918

الزيّ 7

grace@example.com

2

0.08016719669

الزيّ 6

frank@example.com

1

0.06022448093

الزيّ 2

bob@example.com

1

0.0547891818

الزيّ 3

charlie@example.com

1

0.0547891818

الزيّ 12

trent@example.com

1

0.04029225558

الزيّ 4

david@example.com

1

0.04028172791

تحليل: من هم النجوم البارزون؟

من خلال تحليل النتائج، يمكنك الآن التوصّل إلى ثلاث اكتشافات تسويقية مهمة:

النقاط الرئيسية المتعلقة بالنشاط التجاري

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

لنحاول الآن تحديد الجهات التي تحافظ على استمرار عمل شبكة الخدمات اللوجستية الخاصة بالعميل.

5- التحدي 2: المرونة اللوجستية (BetweennessCentrality)

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

الحلّ العلائقي (التحليل المستند إلى الحجم)

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

نفِّذ هذا الاستعلام لتحديد "أهم" المراكز حسب عدد المعاملات:

-- Identify "Critical" hubs by transaction volume
SELECT 
    s.city, 
    s.country, 
    COUNT(t.row_id) AS transaction_count,
    SUM(t.amount) AS total_revenue
FROM Shipping s
JOIN Transactions t ON s.shipping_id = t.shipping_id
GROUP BY s.city, s.country
ORDER BY transaction_count DESC;

city

country

transaction_count

total_revenue

نيويورك

الولايات المتحدة الأمريكية

4

3996

Berlin

ألمانيا

2

345

سان فرانسيسكو

الولايات المتحدة الأمريكية

2

750

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

ذكاء الرسم البياني (المركزية بينية)

للعثور على نقاط الاختناق الحقيقية، نستخدم المركزية بينية. تحدّد هذه الخوارزمية عدد المرات التي تعمل فيها العقدة كـ "جسر" على طول أقصر المسارات بين جميع أزواج العُقد الأخرى في الرسم البياني. تحدّد النتائج العالية الجهات المسؤولة عن التحكّم في تدفّق السلع أو المعلومات.

تشغيل مقياس "المركزية بينية" والحفاظ عليه

سننفّذ الخوارزمية باستخدام EXPORT DATA ونحفظ النتائج في عمود centrality_score. نستخدم Data Boost لضمان ألا يكون لهذا الحساب المعقّد "لأقصر مسار" أي تأثير تقريبًا على العمليات المباشرة للعميل.

EXPORT DATA OPTIONS (
  format = 'CLOUD_SPANNER',
  table = 'Customer',
  write_mode = 'update_ignore_all' 
) AS
GRAPH RetailTransactionGraph
CALL BetweennessCentrality(
  -- We include both Customer and Shipping nodes for a full ecosystem view
  node_labels => ['Customer', 'Shipping'], 
  -- We factor in social ties AND physical shipping locations
  edge_labels => ['IsFriendsWith', 'LivesAt'], 
  num_source_nodes => 100
)
YIELD node, score
-- We only persist scores for Customers; Shipping node results are safely ignored
RETURN node.customer_id, score as centrality_score;

التحليل: تحديد "نقاط الاختناق المخفية"

الآن، نقارن المخاطر الهيكلية (centrality_score) بحجم المعاملات (order_count) للعثور على العُقد التي يجب أن تقلق بشأنها القيادة في "العميل".

SELECT 
    c.customer_id, 
    c.customer_email,
    c.centrality_score,
    count_query.order_count
FROM Customer c
LEFT JOIN (
    SELECT customer_id, COUNT(*) AS order_count 
    FROM Transactions GROUP BY customer_id
) AS count_query ON c.customer_id = count_query.customer_id
ORDER BY c.centrality_score DESC;

customer_id

customer_email

centrality_score

order_count

الزيّ 11

mallory@example.com

44.5

2

الزيّ 1

alice@example.com

35.5

1

الزيّ 5

eve@example.com

35.5

الزيّ 7

grace@example.com

12

1

الزيّ 8

heidi@example.com

10

1

الزيّ 3

charlie@example.com

6

الزيّ 4

david@example.com

3.5

الزيّ 10

judy@example.com

0

1

الزيّ 12

trent@example.com

0

الزيّ 2

bob@example.com

0

1

الزيّ 6

frank@example.com

0

الزيّ 9

ivan@example.com

0

1

من خلال تحليل هذه النتائج، توصّل العميل إلى ثلاث اكتشافات مذهلة:

Business Takeaway

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

لنجرّب الآن عزل مناطق الاحتيال.

6. التحدي 3: الشبكات الوهمية (WCC)

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

لحلّ هذه المشكلة، علينا الكشف عن "الجزر المعزولة" هذه.

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

نفِّذ طلب البحث هذا للعثور على العملاء المرتبطين بموقع شحن مشترك:

SELECT 
    shipping_id, 
    COUNT(DISTINCT customer_id) AS customer_count,
    ARRAY_AGG(customer_id) AS linked_customers
FROM Transactions
GROUP BY shipping_id
HAVING customer_count > 1;

shipping_id

customer_count

linked_customers

S1

4

["C1","C10","C2","C9"]

S5

2

["C7","C8"]

للعثور على شبكات الاحتيال، علينا فهم إمكانية الوصول المتعدّدة.

Graph Intelligence (Weakly Connected Components)

للعثور على النطاق الكامل لهذه الحلقات، نستخدم المكوّنات المرتبطة بشكل ضعيف (WCC). ‫WCC هي خوارزمية تجميع تحدّد مجموعات من العُقد التي يتوفّر فيها مسار بين أي عقدتَين، بغض النظر عن اتجاه الحواف.

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

تشغيل WCC والحفاظ على بياناته

سننفّذ خوارزمية WCC ونحفظ النتائج في العمود community_id. نستخدم Data Boost لضمان إجراء تحليل الوصول العميق هذا على موارد حوسبة مستقلة.

EXPORT DATA OPTIONS (
  format = 'CLOUD_SPANNER',
  table = 'Customer',
  write_mode = 'update_ignore_all' 
) AS
GRAPH RetailTransactionGraph
CALL WeaklyConnectedComponents(
  node_labels => ['Customer', 'Shipping'], 
  edge_labels => ['IsFriendsWith', 'LivesAt']
)
YIELD node, cluster
-- node.customer_id will be NULL for Shipping nodes; 
-- EXPORT DATA will safely ignore those rows.
RETURN node.customer_id, cluster AS community_id;

التحليل: شبكات الاحتيال

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

SELECT 
    community_id, 
    COUNT(*) AS member_count,
    ARRAY_AGG(customer_email) AS members
FROM Customer
GROUP BY community_id
ORDER BY member_count ASC;

community_id

member_count

أعضاء

1

2

["judy@example.com","ivan@example.com"]

0

10

["alice@example.com","mallory@example.com","trent@example.com","bob@example.com","charlie@example.com","david@example.com","eve@example.com","frank@example.com","grace@example.com","heidi@example.com"]

من خلال تنفيذ عملية رصد المجموعات هذه، يمكنك تحديد خلل حرج:

Business Takeaway

يمكن للعميل الآن أتمتة ردوده المتعلّقة بالأمان. بدلاً من تتبُّع الحسابات الفردية يدويًا، يمكنهم كتابة قاعدة بسيطة: "إذا كان لدى معرّف المجموعة أقل من ثلاثة أعضاء، يجب الإبلاغ عن المجموعة بأكملها لإجراء مراجعة يدوية لعملية "اعرف عميلك" (KYC)"

.

بعد الكشف عن شبكات الاحتيال، يمكننا حلّ مشكلة "التوأم السلوكي".

7. التحدي 4: التوأم السلوكي (JaccardSimilarity)

في هذا التحدي الأخير، سنتناول العقبة الرابعة: "مفارقة الاختيار"/"التوأم السلوكي". سننتقل من قوائم "يتم شراؤها معًا غالبًا" العامة إلى اقتراحات مخصّصة للغاية استنادًا إلى "بصمات" سلوكية.

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

لحلّ هذه المشكلة، علينا احتساب "القرب" بين المستخدمين.

حلّ مرتبط (تداخل تام)

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

نفِّذ طلب البحث هذا للعثور على المستخدمين القريبين جغرافيًا من "أليس":

SELECT 
    t2.customer_id AS similar_customer,
    COUNT(DISTINCT t1.shipping_id) AS shared_locations
FROM Transactions t1
JOIN Transactions t2 ON t1.shipping_id = t2.shipping_id
WHERE t1.customer_id = 'C1' AND t2.customer_id != 'C1'
GROUP BY similar_customer
ORDER BY shared_locations DESC;

similar_customer

shared_locations

الزيّ 2

1

الزيّ 10

1

الزيّ 9

1

Graph Intelligence (Jaccard Similarity)

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

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

إنشاء "جدول ربط" أولاً

بما أنّ التشابه هو علاقة ثنائية (العميل "أ" يشبه العميل "ب")، ننشئ جدولاً مخصّصًا متداخلاً في Customer لتخزين عمليات الربط هذه.

CREATE TABLE CustomerSimilarity (
  customer_id STRING(60) NOT NULL, -- Renamed from source_id to match Parent PK
  target_id STRING(60) NOT NULL,
  similarity_score FLOAT64,
  CONSTRAINT FK_SourceCustomer FOREIGN KEY(customer_id) REFERENCES Customer(customer_id),
  CONSTRAINT FK_TargetCustomer FOREIGN KEY(target_id) REFERENCES Customer(customer_id)
) PRIMARY KEY(customer_id, target_id),
  INTERLEAVE IN PARENT Customer ON DELETE CASCADE;

تشغيل مقياس التشابه وفقًا لمعامل جاكار

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

EXPORT DATA OPTIONS (
  format = 'CLOUD_SPANNER',
  table = 'CustomerSimilarity', 
  write_mode = 'upsert_ignore_all' 
) AS
GRAPH RetailTransactionGraph
CALL JaccardSimilarity(
  node_labels => ['Customer', 'Shipping'], -- Added Shipping to avoid dangling edges
  edge_labels => ['LivesAt', 'IsFriendsWith'], -- Use both logistics and social edges for holistic similarity
  source_nodes => ARRAY(
    SELECT s FROM GRAPH_TABLE(RetailTransactionGraph 
      MATCH (s:Customer {customer_id: 'C1'}) 
      RETURN s)
  ),
  target_nodes => ARRAY(
    SELECT t FROM GRAPH_TABLE(RetailTransactionGraph 
      MATCH (t:Customer) 
      WHERE t.customer_id != 'C1' 
      RETURN t)
  )
)
YIELD source_node, target_node, similarity
RETURN 
    source_node.customer_id AS customer_id, 
    target_node.customer_id AS target_id, 
    similarity AS similarity_score;

التحليل: التحقّق من "التوأم السلوكي"

بعد اكتمال مهمة التحليل، ننفّذ استعلامًا للتحقّق من الصحة. من خلال ربط جدول الربط الجديد (CustomerSimilarity) بالبيانات الوصفية الأصلية Customer، يمكننا معرفة من هم "التوائم السلوكية" الخاصة بـ "أليس" بالضبط.

نفِّذ هذا الاستعلام لفحص ترتيبات التشابه الخاصة بـ "أليس":

SELECT 
    c.customer_email AS peer_email,
    s.similarity_score,
    c.community_id,
    c.pagerank_score
FROM CustomerSimilarity s
JOIN Customer c ON s.target_id = c.customer_id
WHERE s.customer_id = 'C1'
ORDER BY s.similarity_score DESC;

peer_email

similarity_score

community_id

pagerank_score

judy@example.com

0.200000003

1

0.1093561724

bob@example.com

0.200000003

0

0.0547891818

ivan@example.com

0.200000003

1

0.1093561724

eve@example.com

0.1666666716

0

0.158392489

mallory@example.com

0

0

0.09466411918

trent@example.com

0

0

0.04029225558

charlie@example.com

0

0

0.0547891818

david@example.com

0

0

0.04028172791

frank@example.com

0

0

0.06022448093

grace@example.com

0

0

0.08016719669

heidi@example.com

0

0

0.09759821743

ما يجب البحث عنه في النتائج:

لنحاول الآن إنشاء عرض نهائي لـ "الذكاء الموحّد".

8. Unified Intelligence

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

التقرير 1: "الذكاء الموحّد"

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

تنفيذ طلب بحث "الذكاء الموحّد" للاطّلاع على النظام المتكامل الكامل:

SELECT 
    c.customer_id,
    c.customer_email,
    -- Transactional Data (Relational)
    COALESCE(t.total_spend, 0) AS spend,
    -- Graph Intelligence Data (Algorithms)
    c.pagerank_score AS influence,
    c.centrality_score AS bottleneck_risk,
    c.community_id,
    -- Persona Categorization Logic
    CASE 
        WHEN c.community_id = 1 THEN '🔴 HIGH RISK: Isolated Fraud Ring'
        WHEN c.centrality_score > 25 THEN '🔵 CRITICAL: Network Bridge'
        WHEN c.pagerank_score > 0.08 AND t.total_spend > 500 THEN '⭐ VIP: Influential Spender'
        WHEN c.pagerank_score > 0.08 THEN '📱 SOCIAL: High-Reach Influencer'
        WHEN sim.similarity_to_alice = 1.0 AND c.community_id != 0 THEN '⚠️ WARNING: Identity Anomaly'
        ELSE '🟢 STANDARD: Active Customer'
    END AS business_persona
FROM Customer c
LEFT JOIN (
    -- Aggregate total spend per customer
    SELECT customer_id, SUM(amount) AS total_spend 
    FROM Transactions GROUP BY customer_id
) t ON c.customer_id = t.customer_id
LEFT JOIN (
    -- Pull similarity relative to our reference user 'C1'
    SELECT target_id, similarity_score AS similarity_to_alice 
    FROM CustomerSimilarity WHERE customer_id = 'C1'
) sim ON c.customer_id = sim.target_id
ORDER BY c.centrality_score DESC, c.pagerank_score DESC;

customer_id

customer_email

الإنفاق

تأثير

bottleneck_risk

community_id

business_persona

الزيّ 11

mallory@example.com

750

0.09466411918

44.5

0

‫🔵 CRITICAL: جسر الشبكات

الزيّ 5

eve@example.com

0

0.158392489

35.5

0

‫🔵 CRITICAL: جسر الشبكات

الزيّ 1

alice@example.com

999

0.1000888124

35.5

0

‫🔵 CRITICAL: جسر الشبكات

الزيّ 7

grace@example.com

300

0.08016719669

12

0

‫📱 SOCIAL: شخص مؤثّر يصل إلى عدد كبير من الجمهور

الزيّ 8

heidi@example.com

45

0.09759821743

10

0

‫📱 SOCIAL: شخص مؤثّر يصل إلى عدد كبير من الجمهور

الزيّ 3

charlie@example.com

0

0.0547891818

6

0

🟢 STANDARD: عميل نشط

الزيّ 4

david@example.com

0

0.04028172791

3.5

0

🟢 STANDARD: عميل نشط

الزيّ 10

judy@example.com

999

0.1093561724

0

1

🔴 مخاطر عالية: شبكة احتيال معزولة

الزيّ 9

ivan@example.com

999

0.1093561724

0

1

🔴 مخاطر عالية: شبكة احتيال معزولة

الزيّ 6

frank@example.com

0

0.06022448093

0

0

🟢 STANDARD: عميل نشط

الزيّ 2

bob@example.com

999

0.0547891818

0

0

🟢 STANDARD: عميل نشط

الزيّ 12

trent@example.com

0

0.04029225558

0

0

🟢 STANDARD: عميل نشط

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

"جسر الشبكة الأساسي" (المرونة)

يتم وضع علامة على العُقد، مثل Mallory (C11) وEve (C5) وAlice (C1)، لأنّ قيمة bottleneck_risk (المركزية بينية) الخاصة بها >25.

  • النقاط الأساسية: حصلت Mallory على أعلى درجة خطورة بلغت 44.5، ما يجعلها البوابة الأساسية للشبكة بأكملها.
  • مفارقة الإنفاق الصفري: يبلغ عدد طلبات "إيف" (C5) صفرًا، ومع ذلك، لا يمكن الاستغناء عنها من الناحية الهيكلية، حيث تبلغ نتيجة تقييم المخاطر لديها 35.5. كانت لغة SQL العادية ستتجاهلها تمامًا، ولكن تكشف Graph Intelligence أنّها حلقة وصل مهمة بمجموعة فرعية كاملة من المنتدى.
  • بوابة القيمة العالية: حقّقت "أليس" (C1) النتيجة نفسها التي حقّقتها "إيف"، وهي 35.5، ما يثبت أنّ المنفقين الكبار يمكن أن يكونوا أيضًا نقاط ارتكاز هيكلية مهمة.

"نجوم وسائل التواصل الاجتماعي" (الوصول)

تم تحديد هايدي (C8) وغريس (C7) كشخصيتَين مؤثّرتَين واسعتَي الانتشار بسبب درجات PageRank التي حصلتا عليها .

"شبكة الاحتيال المعزولة" (الحالات الشاذة)

تم وضع علامة على جودي (C10) وإيفان (C9) لأنّهما ينتميان إلى community_id المعزول 1

من إحصاءات النشاط التجاري إلى الإجراءات الاستراتيجية

الشخصية

المقياس الرئيسي

Business Insight

الإجراء الاستراتيجي

🔵 جسور الشبكات

المركزية العالية

الروابط البنيوية: تربط "إيف" (C5) و"مالوري" (C11) الشبكة ببعضها.

الاحتفاظ بالمستخدمين: احرص على الاحتفاظ بهؤلاء المستخدمين لمنع تشتّت المنتدى.

📱 Social Superstars

مستوى PageRank مرتفع

محركات الانتشار: يحقّق المستخدمون مثل "هيدي" (C8) أعلى معدّل وصول في دوائرهم.

التسويق: تُستخدَم في برامج الإحالة وبرامج السفراء الفعّالة.

🔴 مخاطر الاحتيال

Isolated WCC

الشبكات الوهمية: "جودي" (الفئة 10) و"إيفان" (الفئة 9) من العملاء الذين ينفقون مبالغ كبيرة ولكنهم يعيشون في "جزر".

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

🟢 المستخدمون العاديون

النتائج المتوازنة

الشبكة الأساسية السليمة: معظم الشبكة، بما في ذلك الجسور "المحلية" مثل David (C4).

النمو: تطبيق الإعلانات المخصّصة العادية واقتراحات "الجمهور المشابه المستند إلى السلوك"

التقرير 2: تقرير القيم الشاذة في الهوية

عليك الآن معرفة ما إذا كان المحتالون "يقلّدون" حسابات شرعية. يمكننا حلّ هذه المشكلة من خلال العثور على مستخدمين لديهم تشابه سلوكي بنسبة% 100 ولكن ليس لديهم أيّ اتصال اجتماعي.

نفِّذ طلب البحث هذا للإبلاغ عن "حالات شذوذ محتملة في الهوية":

SELECT 
    s.target_id AS suspect_id,
    c.customer_email,
    s.similarity_score AS behavioral_overlap,
    c.community_id AS social_group
FROM CustomerSimilarity s
JOIN Customer c ON s.target_id = c.customer_id
WHERE s.customer_id = 'C1' -- Reference Alice (Legitimate)
  AND s.similarity_score > 0.15 
  AND c.community_id != 0 -- Filter for social strangers
ORDER BY s.similarity_score DESC;

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

suspect_id

customer_email

behavioral_overlap

social_group

الزيّ 10

judy@example.com

0.200000003

1

الزيّ 9

ivan@example.com

0.200000003

1

تحليل النتائج

من خلال دمج التشابه (جاكارد) مع رصد المجموعات (WCC)، نكشف عن المخاطر المخفية التي لا يمكن لرصدها باستخدام بيانات المعاملات التقليدية.

  • التوأم السلوكي (التقارب): يتم الإبلاغ عن العُقد، مثل جودي (C10) وإيفان (C9)، لأنّها تتشارك في نتيجة تشابه جاكار 0.20 مقارنةً بأليس (C1).
  • سلوك العزل: تم تجميع "جودي" (المجموعة 10) و"إيفان" (المجموعة 9) في المجموعة المعزولة 1، بينما تنتمي "أليس" إلى "البر الرئيسي" الاجتماعي (المجموعة 0).
  • علامات الاحتيال: يحدّد التقرير المستخدمين الذين يتشابه سلوكهم بشكل كبير (>0.9) والذين يظلون غير متصلين اجتماعيًا بالشبكة الأساسية.

9- تهانينا والملخّص

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

مزايا Spanner Multi-Model

  • البنية الموحّدة: يتيح لك Spanner الحفاظ على أساس علائقي قوي للغاية مع إمكانية "تراكب" رسم بياني للخصائص على الفور لاستخراج العلاقات بدون أي مخاطر أو تأخير في عملية استخراج البيانات وتحويلها وتحميلها.
  • عزل التحليلات خارج الصندوق: من خلال الاستفادة من Data Boost، يمكنك تنفيذ خوارزميات تتطلّب ذاكرة مكثّفة، مثل PageRank أو WCC، على موارد حوسبة مستقلة بدون خادم، ما يضمن عدم التأثير في أداء عملية الدفع في مرحلة الإنتاج.
  • الأداء المتداخل: يضمن التداخل الفريد في Spanner أن تكون العُقد وعلاقاتها متجاورة جغرافيًا، ما يحوّل عمليات البحث المعقّدة على مستوى العالم إلى عمليات بحث محلية عالية السرعة.

عرض "الكنوز المخفية" والحالات الشاذة

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

جعل البيانات ذكية وقابلة للاستخدام

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