Graf semantiği için en iyi yöntemler

2025-05-29

Şunlar için geçerlidir: ✅Microsoft Fabric

Graf semanitcs graflarla çalışmak için iki birincil yaklaşımı destekler: her sorgu için bellek içinde oluşturulan geçici grafikler ve veritabanında grafik modelleri ve anlık görüntüler olarak tanımlanan kalıcı grafikler. Bu makalede, en iyi yaklaşımı seçmenize ve KQL graf semantiğini verimli bir şekilde kullanmanıza olanak tanıyan her iki yöntem için de en iyi yöntemler sağlanmaktadır.

Bu kılavuz aşağıdakileri kapsar:

Graf oluşturma ve iyileştirme stratejileri
Sorgulama teknikleri ve performansla ilgili dikkat edilmesi gerekenler
Kalıcı grafikler için şema tasarımı
Diğer KQL özellikleriyle tümleştirme
Kaçınılması gereken yaygın tuzaklar

Graf modelleme yaklaşımları

Grafiklerle çalışmaya yönelik iki yaklaşım vardır: geçici ve kalıcı.

Geçici grafikler

make-graph operatörü kullanılarak dinamik olarak oluşturuldu. Bu grafikler yalnızca sorgu yürütme sırasında bulunur ve küçük ve orta ölçekli veri kümelerinde geçici veya keşif analizi için idealdir.

Kalıcı grafikler

Grafik modelleri ve grafik anlık görüntüleri kullanılarak tanımlanır. Bu grafikler veritabanında depolanır, şema ve sürüm oluşturmayı destekler ve yinelenen, büyük ölçekli veya işbirliğine dayalı analiz için iyileştirilmiştir.

Geçici grafikler için en iyi yöntemler

işleci kullanılarak make-graph bellek içinde oluşturulan geçici grafikler geçici analiz, prototip oluşturma ve grafik yapısının sık sık değiştiği veya yalnızca kullanılabilir verilerin bir alt kümesini gerektirdiği senaryolar için idealdir.

Performans için graf boyutunu iyileştirme

make-graph, yapı ve özellikleri içeren bir bellek içi gösterim oluşturur. Performansı optimize etme:

Filtreleri erken uygulama - Grafik oluşturmadan önce yalnızca ilgili düğümleri, kenarları ve özellikleri seçin
Projeksiyonları kullanma - Bellek tüketimini en aza indirmek için gereksiz sütunları kaldırma
Toplamaları uygulama - Graf karmaşıklığını azaltmak için uygun yerlerde verileri özetleme

Örnek: Filtreleme ve projeksiyon aracılığıyla graf boyutunu küçültme

Bu senaryoda Bob, yöneticileri Alice yerine Eve olarak değiştirdi. Graf boyutunu en aza indirirken yalnızca en son kuruluş durumunu görüntülemek için:

let allEmployees = datatable(organization: string, name:string, age:long)
[
  "R&D", "Alice", 32,
  "R&D","Bob", 31,
  "R&D","Eve", 27,
  "R&D","Mallory", 29,
  "Marketing", "Alex", 35
];
let allReports = datatable(employee:string, manager:string, modificationDate: datetime)
[
  "Bob", "Alice", datetime(2022-05-23),
  "Bob", "Eve", datetime(2023-01-01),
  "Eve", "Mallory", datetime(2022-05-23),
  "Alice", "Dave", datetime(2022-05-23)
];
let filteredEmployees =
    allEmployees
    | where organization == "R&D"
    | project-away age, organization;
let filteredReports =
    allReports
    | summarize arg_max(modificationDate, *) by employee
    | project-away modificationDate;
filteredReports
| make-graph employee --> manager with filteredEmployees on name
| graph-match (employee)-[hasManager*2..5]-(manager)
  where employee.name == "Bob"
  project employee = employee.name, topManager = manager.name

Çıktı:

çalışan	üst düzey yönetici
Bob	Mallory

Mevcut durumu materyalize görünümlerle koruyun.

Önceki örnekte, summarize ve arg_max kullanarak bilinen son durumun nasıl elde edildiği gösterildi. Bu işlem yoğun işlem gücü kullanabilir, bu nedenle gelişmiş performans için gerçekleştirilmiş görünümleri kullanmayı göz önünde bulundurun.

1. Adım: Sürüm oluşturma ile tablo oluşturma

Grafik zaman serisi için sürüm oluşturma mekanizmasıyla tablolar oluşturun:

.create table employees (organization: string, name:string, stateOfEmployment:string, properties:dynamic, modificationDate:datetime)

.create table reportsTo (employee:string, manager:string, modificationDate: datetime)

2. Adım: Gerçekleştirilmiş görünümler oluşturma

En son durumu belirlemek için arg_max toplama işlevini kullanın:

.create materialized-view employees_MV on table employees
{
    employees
    | summarize arg_max(modificationDate, *) by name
}

.create materialized-view reportsTo_MV on table reportsTo
{
    reportsTo
    | summarize arg_max(modificationDate, *) by employee
}

3. Adım: Yardımcı işlevler oluşturma

Yalnızca gerçekleştirilmiş bileşenin kullanıldığından emin olun ve ek filtreler uygulayın:

.create function currentEmployees () {
    materialized_view('employees_MV')
    | where stateOfEmployment == "employed"
}

.create function reportsTo_lastKnownState () {
    materialized_view('reportsTo_MV')
    | project-away modificationDate
}

Bu yaklaşım, geçmiş verilere erişimi korurken geçerli durum analizi için daha hızlı sorgular, daha yüksek eşzamanlılık ve daha düşük gecikme süresi sağlar.

let filteredEmployees =
    currentEmployees
    | where organization == "R&D"
    | project-away organization;
reportsTo_lastKnownState
| make-graph employee --> manager with filteredEmployees on name
| graph-match (employee)-[hasManager*2..5]-(manager)
  where employee.name == "Bob"
  project employee = employee.name, reportingPath = hasManager.manager

Graf zaman yolculuğu yapmayı uygula

Geçmiş graf durumlarını temel alarak verilerin çözümlenmesi değerli zamansal bağlam sağlar. summarize ve arg_max ile zaman filtrelerini birleştirerek bu "zaman yolculuğu" özelliğini uygulayın.

.create function graph_time_travel (interestingPointInTime:datetime ) {
    let filteredEmployees =
        employees
        | where modificationDate < interestingPointInTime
        | summarize arg_max(modificationDate, *) by name;
    let filteredReports =
        reportsTo
        | where modificationDate < interestingPointInTime
        | summarize arg_max(modificationDate, *) by employee
        | project-away modificationDate;
    filteredReports
    | make-graph employee --> manager with filteredEmployees on name
}

Kullanım örneği:

Haziran 2022 graf durumuna göre Bob'un en üst yöneticisini sorgula:

graph_time_travel(datetime(2022-06-01))
| graph-match (employee)-[hasManager*2..5]-(manager)
  where employee.name == "Bob"
  project employee = employee.name, reportingPath = hasManager.manager

Çıktı:

çalışan	üst düzey yönetici
Bob	Demirci

Birden çok düğüm ve kenar türünü işleme

Birden çok düğüm türü içeren karmaşık grafiklerle çalışırken kurallı özellik grafı modeli kullanın. Düğümleri, nodeId (dize), label (dize) ve properties (dinamik) gibi özniteliklerle tanımlayın; kenarlar ise source (dize), destination (dize), label (dize) ve properties (dinamik) alanlarını içerir.

Örnek: Fabrika bakım analizi

Ekipman sorunlarını ve sorumlu personeli araştıran bir fabrika yöneticisi düşünün. Senaryo, üretim ekipmanının varlık grafiklerini bakım personeli hiyerarşisiyle birleştirir:

Fabrika insanlarının, donatma ve ölçümlerin grafiği

Bu varlıkların verileri doğrudan kümenizde depolanabilir veya farklı bir hizmete sorgu federasyonu kullanılarak edinilebilir. Örneği göstermek için sorgunun bir parçası olarak aşağıdaki tablosal veriler oluşturulur:

let sensors = datatable(sensorId:string, tagName:string, unitOfMeasure:string)
[
  "1", "temperature", "°C",
  "2", "pressure", "Pa",
  "3", "speed", "m/s"
];
let timeseriesData = datatable(sensorId:string, timestamp:string, value:double, anomaly: bool )
[
    "1", datetime(2023-01-23 10:00:00), 32, false,
    "1", datetime(2023-01-24 10:00:00), 400, true,
    "3", datetime(2023-01-24 09:00:00), 9, false
];
let employees = datatable(name:string, age:long)
[
  "Alice", 32,
  "Bob", 31,
  "Eve", 27,
  "Mallory", 29,
  "Alex", 35,
  "Dave", 45
];
let allReports = datatable(employee:string, manager:string)
[
  "Bob", "Alice",
  "Alice", "Dave",
  "Eve", "Mallory",
  "Alex", "Dave"
];
let operates = datatable(employee:string, machine:string, timestamp:datetime)
[
  "Bob", "Pump", datetime(2023-01-23),
  "Eve", "Pump", datetime(2023-01-24),
  "Mallory", "Press", datetime(2023-01-24),
  "Alex", "Conveyor belt", datetime(2023-01-24),
];
let assetHierarchy = datatable(source:string, destination:string)
[
  "1", "Pump",
  "2", "Pump",
  "Pump", "Press",
  "3", "Conveyor belt"
];

Çalışanlar, algılayıcılar, diğer varlıklar ve ilişkiler kurallı veri modelini paylaşmaz. Birleşim işleci, verileri birleştirmek ve standartlaştırmak için kullanılabilir.

Aşağıdaki sorgu, anormal okumalara sahip algılayıcıları tanımlamak için algılayıcı verilerini zaman serisi verileriyle birleştirir ve ardından grafik düğümleri için ortak bir model oluşturmak üzere bir projeksiyon kullanır.

let nodes =
    union
        (
            sensors
            | join kind=leftouter
            (
                timeseriesData
                | summarize hasAnomaly=max(anomaly) by sensorId
            ) on sensorId
            | project nodeId = sensorId, label = "tag", properties = pack_all(true)
        ),
        ( employees | project nodeId = name, label = "employee", properties = pack_all(true));

Kenarlar benzer şekilde dönüştürülür.

let edges =
    union
        ( assetHierarchy | extend label = "hasParent" ),
        ( allReports | project source = employee, destination = manager, label = "reportsTo" ),
        ( operates | project source = employee, destination = machine, properties = pack_all(true), label = "operates" );

Standartlaştırılmış düğümler ve kenar verileriyle, graf yapma işlecini kullanarak grafik oluşturabilirsiniz

let graph = edges
| make-graph source --> destination with nodes on nodeId;

Grafik oluşturulduktan sonra yol desenini tanımlayın ve gerekli bilgileri yansıtın. Desen bir etiket düğümünde başlar ve ardından bir nesneye değişken uzunlukta bir kenar gider. Bu varlık, reportsTo adlı değişken uzunlukta bir kenar aracılığıyla üst yöneticiye rapor veren bir operatör tarafından çalıştırılır. Graph-match işlecinin kısıtlamalar bölümü, bu durumda where yan tümcesi, etiketleri belirli bir günde çalıştırılan anomaliye sahip olanlara filtreler.

graph
| graph-match (tag)-[hasParent*1..5]->(asset)<-[operates]-(operator)-[reportsTo*1..5]->(topManager)
    where tag.label=="tag" and tobool(tag.properties.hasAnomaly) and
        startofday(todatetime(operates.properties.timestamp)) == datetime(2023-01-24)
        and topManager.label=="employee"
    project
        tagWithAnomaly = tostring(tag.properties.tagName),
        impactedAsset = asset.nodeId,
        operatorName = operator.nodeId,
        responsibleManager = tostring(topManager.nodeId)

Çıkış

Anomalilik Etiketi	etkilenen varlık	operatörAdı	sorumlu yönetici
sıcaklık	Pompa	Arife	Mallory

içindeki graph-match projeksiyon, sıcaklık algılayıcısının belirtilen günde bir anomali sergilediğini gösteriyor. Algılayıcı, Sonunda Mallory'ye rapor veren Eve tarafından çalıştırıldı. Bu bilgilerle fabrika yöneticisi, anomaliyi daha iyi anlamak için Eve ve gerekirse Mallory ile iletişime geçebilir.

Kalıcı grafikler için en iyi yöntemler

Grafik modelleri ve grafik anlık görüntüleri kullanılarak tanımlanan kalıcı grafikler, gelişmiş graf analizi ihtiyaçları için sağlam çözümler sağlar. Bu grafikler büyük, karmaşık veya gelişen veri ilişkilerinin tekrar tekrar analiz edilmesini gerektiren senaryolarda üstünlük sağlar ve ekiplerin standartlaştırılmış grafik tanımlarını ve tutarlı analitik sonuçları paylaşmasını sağlayarak işbirliğini kolaylaştırır. Bu yaklaşım, veritabanındaki grafik yapılarını kalıcı hale alarak yinelenen sorgular için performansı önemli ölçüde artırır ve gelişmiş sürüm oluşturma özelliklerini destekler.

Tutarlılık ve performans için şemayı ve tanımı kullanma

Grafik modelinizin özellikleriyle birlikte düğüm ve kenar türlerini belirttiği için net bir şema gereklidir. Bu yaklaşım, veri tutarlılığını sağlar ve verimli sorgulama sağlar. Definition bölümünü, AddNodes ve AddEdges adımları aracılığıyla, verilerinizi kullanarak düğümlerin ve kenarların nasıl oluşturulduğunu belirtmek için kullanın.

Esnek modelleme için statik ve dinamik etiketlerden yararlanma

Grafınızı modellerken, en iyi esneklik için hem statik hem de dinamik etiketleme yaklaşımlarını kullanabilirsiniz. Statik etiketler, nadiren değişen iyi tanımlanmış düğüm ve kenar türleri için idealdir; bunları Schema bölümünde tanımlayın ve adımlarınızın Labels dizisinde bunlara referans verin. Düğüm veya kenar türlerinin veri değerlerine göre belirlendiği durumlarda (örneğin, tür bir sütunda depolandığında), çalışma zamanında etiket atamak için adımınızda bir LabelsColumn belirterek dinamik etiketleri kullanın. Bu yaklaşım özellikle heterojen veya gelişen şemalara sahip grafikler için yararlıdır. Her iki mekanizma da etkili bir şekilde birleştirilebilir; statik etiketler için bir Labels dizi tanımlayabilir ve ayrıca hem sabit hem de veri temelli kategorilere sahip karmaşık grafikleri modellerken maksimum esneklik sağlayarak verilerinizden ek etiketler eklemek için belirtebilirsiniz LabelsColumn .

Örnek: Birden çok düğüm ve kenar türü için dinamik etiketler kullanma

Aşağıdaki örnekte, profesyonel ilişkileri temsil eden bir grafikte dinamik etiketlerin etkili bir şekilde uygulanması gösterilmektedir. Bu senaryoda grafik, kişileri ve şirketleri düğüm olarak içerir ve aralarındaki kenarları oluşturan istihdam ilişkileri vardır. Bu modelin esnekliği, düğüm ve kenar türlerini doğrudan kaynak verilerdeki sütunlardan belirleyerek graf yapısının temel alınan bilgilere organik olarak uyum sağlamasına olanak sağlar.

.create-or-alter graph_model ProfessionalNetwork ```
{
  "Schema": {
    "Nodes": {
      "Person": {"Name": "string", "Age": "long"},
      "Company": {"Name": "string", "Industry": "string"}
    },
    "Edges": {
      "WORKS_AT": {"StartDate": "datetime", "Position": "string"}
    }
  },
  "Definition": {
    "Steps": [
      {
        "Kind": "AddNodes",
        "Query": "Employees | project Id, Name, Age, NodeType",
        "NodeIdColumn": "Id",
        "Labels": ["Person"],
        "LabelsColumn": "NodeType"
      },
      {
        "Kind": "AddEdges",
        "Query": "EmploymentRecords | project EmployeeId, CompanyId, StartDate, Position, RelationType",
        "SourceColumn": "EmployeeId",
        "TargetColumn": "CompanyId",
        "Labels": ["WORKS_AT"],
        "LabelsColumn": "RelationType"
      }
    ]
  }
}
```

Bu dinamik etiketleme yaklaşımı, çok sayıda düğüm ve kenar türüne sahip grafikleri modellemek için olağanüstü esneklik sağlar ve verilerinizde her yeni varlık türü görüntülendiğinde şemanızı değiştirme gereksinimini ortadan kaldırır. Mantıksal modeli fiziksel uygulamadan ayrıştırarak, grafiğiniz temel şemada yapısal değişikliklere gerek kalmadan yeni ilişkileri temsil etmek için sürekli olarak gelişebilir.

Büyük ölçekli ISV senaryoları için çok kiracılı bölümleme stratejileri

Büyük kuruluşlarda, özellikle ISV senaryolarında grafikler birden çok milyarlarca düğümden ve kenardan oluşabilir. Bu ölçek, maliyetleri ve karmaşıklığı yönetirken performansı korumak için stratejik bölümleme yaklaşımları gerektiren benzersiz zorluklar sunar.

Zorluğu anlama

Büyük ölçekli çok kiracılı ortamlar genellikle aşağıdaki özellikleri sergiler:

Milyarlarca düğüm ve kenar - Geleneksel graf veritabanı özelliklerini aşan kurumsal ölçekli grafikler
Kiracı boyutu dağıtımı - Genellikle kiracıların 99,9% küçük ve orta büyüklükte grafiklere sahip olduğu, 0,1% ise büyük grafiklere sahip olduğu bir güç yasasına uyar
Performans gereksinimleri - Hem gerçek zamanlı analiz (geçerli veriler) hem de geçmiş analiz özellikleri için ihtiyaç
Maliyetle ilgili dikkat edilmesi gerekenler - Altyapı maliyetleri ile analitik özellikler arasında denge

Doğal sınırlara göre bölümleme

Büyük ölçekli grafikleri yönetmek için en etkili yaklaşım, genellikle kiracı tanımlayıcıları veya kuruluş birimleri gibi doğal sınırlara göre bölümlemedir:

Anahtar bölümleme stratejileri:

Kiracı tabanlı bölümleme - Grafikleri müşteriye, kuruluşa veya iş birimine göre ayırma
Coğrafi bölümleme - Bölgeye, ülkeye veya veri merkezi konumuna göre bölme
Zamansal bölümleme - Geçmiş analizi için zaman aralıklarına göre ayırın
İşlevsel bölümleme - İş etki alanına veya uygulama alanına göre bölme

Örnek: Çok kiracılı kuruluş yapısı

// Partition employees and reports by tenant
let tenantEmployees = 
    allEmployees
    | where tenantId == "tenant_123"
    | project-away tenantId;

let tenantReports = 
    allReports
    | where tenantId == "tenant_123"
    | summarize arg_max(modificationDate, *) by employee
    | project-away modificationDate, tenantId;

tenantReports
| make-graph employee --> manager with tenantEmployees on name
| graph-match (employee)-[hasManager*1..5]-(manager)
  where employee.name == "Bob"
  project employee = employee.name, reportingChain = hasManager.manager

Karma yaklaşım: Kiracı boyutuna göre geçici ve kalıcı grafikler

En uygun maliyetli strateji, kiracı özelliklerine göre hem geçici hem de kalıcı grafikleri birleştirir:

Küçük ve orta ölçekli kiracılar (kiracıların 99,9%)

Kiracıların çoğu için geçici grafikler kullanın:

Avantajlar:

Her zaman up-to-tarih verisi - Anlık görüntü bakımı gerektirmez
Daha düşük işlem yükü - Grafik modeli veya anlık görüntü yönetimi yok
Uygun maliyetli - Grafik yapıları için ek depolama maliyeti yoktur
Anında kullanılabilirlik - Ön işlem gecikmesi yok

Uygulama düzeni:

.create function getTenantGraph(tenantId: string) {
    let tenantEmployees = 
        employees
        | where tenant == tenantId and stateOfEmployment == "employed"
        | project-away tenant, stateOfEmployment;
    let tenantReports = 
        reportsTo
        | where tenant == tenantId
        | summarize arg_max(modificationDate, *) by employee
        | project-away modificationDate, tenant;
    tenantReports
    | make-graph employee --> manager with tenantEmployees on name
}

// Usage for small tenant
getTenantGraph("small_tenant_456")
| graph-match (employee)-[reports*1..3]-(manager)
  where employee.name == "Alice"
  project employee = employee.name, managerChain = reports.manager

Büyük kiracılar (%0,1% kiracılar)

En büyük kiracılar için kalıcı grafikler kullanın: