Çapraz çalışma alanı dağıtımında bağımlılık bağlamasını anlama

Fabric öğelerini çalışma alanları arasında dağıttığınızda (örneğin, Geliştirme'den Test'e, Üretim'e), öğeler arasındaki bağımlılıklar bozulabilir. Bazı öğeler, bağımlılıklarına referansları nesne kimliği (çalışma alanı özel GUID'ler) olarak saklarken, diğerleri mantıksal kimlikler (dosyada depolanan çapraz çalışma alanı taşınabilir tanımlayıcılar .platform ) kullanır.

Tanımlarında mantıksal kimlikler kullanan öğeler, hedef çalışma alanındaki ilgili öğeye doğru şekilde bağlanır. Nesne kimliği kullanan öğeler kaynak çalışma alanına yönlendirilmiş kalır, bu da dağıtımı bozar.

Bu makale, Git entegrasyonu kullandığınızda mantıksal kimlikler aracılığıyla hangi Fabric öğe türlerinin bağımlılık bağlamasını desteklediğini ve hangilerinin desteklemediğini haritalıyor. Mantıksal kimlikler ve öğelerin kaynak kontrolünde nasıl temsil edildiği hakkında daha fazla bilgi edinmek için Fabric'teki Logical ID'ye bakınız.

Temel kavramlar

  • Mantıksal ID:Dosyada.platform otomatik olarak oluşturulan çapraz çalışma alanı tanımlayıcısı. Aynı mantıksal ID'ye sahip öğeler, çalışma alanları arasında aynı öğe olarak kabul edilir.
  • Nesne Kimliği: Belirli bir örneği tanımlayan çalışma alanına özgü bir GUID. Nesne kimlikleri, manuel müdahale veya parametreleştirme olmadan çalışma alanları arası dağıtımda korunmaz.
  • Bağımlılık bağlaması (Git): Bir Git dalını yeni bir çalışma alanına senkronize ettiğinizde, Fabric mantıksal kimlikler kullanarak bağımlılık referanslarını çözer ve otomatik olarak hedef çalışma alanında doğru öğeye işaret eder.
  • İsimle veya URI'ye göre: Bazı öğeler bağımlılıkları kimlik yerine görüntüleme adı veya URI ile referans verir. Bu referanslar, çalışma alanlarındaki adlandırma kurallarına bağlı olarak doğru şekilde çözülebilir ya da çözülmeyebilir.

Bağımlılık bağlama nasıl çalışır

Bir çalışma alanı içinde, öğeler bağımlılıklarına nesne kimlikleri kullanarak referans verir. Fabric, bir öğeyi Git'e aktardığında, bu nesne kimliklerinin bazılarını dosyadaki mantıksal kimliklerle .platform değiştirir. Git dalını farklı bir çalışma alanına senkronize ettiğinizde, Fabric bu mantıksal kimlikleri hedef çalışma alanındaki doğru nesne ID'lerine geri çözer. İşte bağımlılık bağlamanın işe yaramasını sağlayan şey budur.

Ancak, tüm bağımlılık referansları dışa aktarma sırasında mantıksal kimliklerle değiştirilmez. Git temsilinde nesne kimliklerini tutan öğeler, senkronizasyondan sonra hâlâ orijinal çalışma alanına işaret eder ve bunları manuel olarak veya parametrelendirme yoluyla güncellemeniz gerekir.

Important

Bağımlılık bağlaması yalnızca aynı çalışma alanı içindeki Fabric öğeleri arasındaki referanslar için geçerlidir. Bir öğe farklı bir çalışma alanında bir Fabric öğesine referans verirse, o referans bir nesne kimliği kullanır ve otomatik olarak bağlanmaz. Bağlantılara yapılan referanslar (veri kaynağı bağlantıları, gatewayler) de otomatik bağlanmaz. Ortamlar arasında bağlantı referanslarını yönetmek için ortama özgü değer setlerine sahip Değişken Kütüphaneleri kullanın.

Bağımlılık bağlama uyumluluğu

Aşağıdaki tablolar, her Fabric öğesi türünün bağımlılıklarının çalışma alanları arasında dağıtıldığında doğru şekilde bağlanıp bağlanmadığını gösterir. Şu anda bu makale Git entegrasyon davranışını ele almaktadır. Bağlama, her öğenin tanımında bağımlılık referanslarını nasıl depoladığına bağlı olduğundan, aynı davranış bu tanımları yeniden kullanan diğer dağıtım mekanizmaları için de geçerlidir; örneğin dağıtım boru hatları ve içe (toplu) API'ler gibi.

Bu tablolar, bağımlılığın kaynak öğeyle aynı çalışma alanında başka bir öğe olduğunu varsayır. Farklı bir çalışma alanındaki bir öğeye yapılan referans asla otomatik bağlanmaz. Tabloda gösterilen değer ne olursa olsun, kaynak nesne kimliğine sabitlenir.

Git'te Otomatik Bağlama sütunu şunları gösterir:

  • Evet: Git'teki eşya tanımı, bağımlılık referansını mantıksal bir kimlik olarak saklar. Dalı yeni bir çalışma alanına senkronize ettiğinizde, referans otomatik olarak o çalışma alanındaki eşleştirme öğesine bağlanır.
  • Hayır: Git'teki öğe tanımı, bağımlılık referansını nesne kimliği (çalışma alanına özgü GUID) olarak saklar. Referans, senkronizasyondan sonra kaynak çalışma alanına işaret etmeye devam ediyor. Çapraz çalışma alanı dağıtımı için manuel olarak güncellemeniz veya parametrize etmeniz gerekiyor.
  • Kısmi: Öğe, isim veya URI ile bağımlılığı çözer, bu da çalışma alanları arasında isimlendirme tutarlıysa işe yarayabilir.

Notebooks

Bağımlılık Git'te otomatik bağlama Notlar
Lakehouse Yes Notebook ayarlarında "Git'te Lakehouse Auto-Binding özelliğini" etkinleştirmek gerekiyor. Etkinleştirildiğinde, nesne kimliği mantıksal bir ID ile notebook-settings.jsondeğiştirilir. Bu ayar varsayılan olarak kapalıdır. Daha fazla bilgi için Git'te Lakehouse otomatik bağlama sayfasına bakınız.
Environment Yes
Yansıtılmış Veritabanı Hayır

Uyarı

Notebook'tan Lakehouse'a bağlama varsayılan olarak etkin değil. Her defterin ayarlarında "Lakehouse Auto-Binding in Git" ayarını açmanız gerekiyor. Daha fazla bilgi için Not Defteri Kaynak Kontrolü ve Dağıtımı'na bakın.

Reports

Bağımlılık Git'te otomatik bağlama Notlar
Anlamsal Model (Power BI raporundan) Kısmi Rapor, modele açık bir mantıksal kimlik aracılığıyla değil, byPath içindeki göreli bir definition.pbir başvurusu aracılığıyla atıfta bulunur. Model, hedef çalışma alanında aynı göreceli konuma dağıtıldığında doğru şekilde çözülür, ancak mantıksal bir kimlik üzerinden bağlanmaz. Daha fazla bilgi için Power BI Desktop projeleri rapor klasörüne bakınız.
Anlamsal Modeli (sayfalandırılmış rapordan) Hayır Raporun bağlantı dizesi, dağıtım sırasında yeniden yazılmayan çalışma alanına özgü bir kimlikle anlamsal modele başvurur; bu nedenle kaynak modeli işaret etmeye devam eder. Bu referansı çapraz çalışma alanı dağıtımı için güncellemeniz gerekiyor. (Report Builder'da yazılmış ve modele isimle referans veren raporlar, bunun yerine Kısmi olan görüntü ismine göre çözülebilir.)

Pipeline

Bağımlılık Git'te otomatik bağlama Notlar
Pipeline Yes
Notebook Yes
Dataflow Gen 2 Yes
SQL Database Yes
Spark İş Tanımı Hayır SparkJobDefinition etkinliği, Spark İş Tanımı'na nesne kimliği ile referans verir, mantıksal ID'ye değil, bu yüzden dağıtımdan sonra kaynak öğeye yönlendirilir. Bu değeri çapraz çalışma alanı dağıtımı için parametre etmeniz gerekir.
Lakehouse Yes
Anlam Modeli Hayır PBISemanticModelRefresh etkinliği, mantıksal ID değil, öğe kimliği ile anlamsal modele atıfta bulunur. Bu değeri çapraz çalışma alanı dağıtımı için parametre etmeniz gerekir.
Depo Hayır Depo artifactId, mantıksal kimlik üzerinden çözümlenip yeniden bağlanır, ancak linkedService aynı zamanda kaynak çalışma alanının SQL endpoint öğesini de saklar ve bu yeniden yazılmaz. Çalışma alanları arası dağıtım için endpoint öğesini parametreleştirin.

Anlamsal modeller

Bağımlılık Git'te otomatik bağlama Notlar
Semantik model Kısmi Zincirli veya bileşik model referansları isimlerine göre bağlantı dizelerini kullanır.
SQL Analizi Uç Noktası (lakehouse) Hayır TMDL'deki expressions.tmdl Direct Lake bağlantı dizesi, çalışma alanına özgü bir uç nokta URL'si ve veritabanı GUID içerir. Çapraz çalışma alanı dağıtımı için bu parametreleri değiştirmeniz gerekir.
KQL veritabanı Hayır TMDL ifadelerinde küme URI'sine sahip bağlantı dizesi, çalışma alanına özgü değerler içerir.
SQL database Hayır TMDL ifadelerindeki bağlantı dizesi, çalışma alanına özgü değerler içerir.
Depo Hayır Depo SQL analitik uç noktasına bağlantı ise çalışma alanına özgü bir URL kullanır.

Göl evleri

Bağımlılık Git'te otomatik bağlama Notlar
Lakehouse (kestirme) Yes Göl evi veya ambar gibi başka bir Fabric öğesini işaret eden dahili OneLake kısayolları, mantıksal bir kimlik olarak depolanır ve hedef çalışma alanındaki öğeye yeniden bağlanır. Azure Data Lake Storage 2. Nesil veya Amazon S3 gibi harici kaynaklara kısayollar Fabric'in dışına işaret eder ve bunun yerine bir bağlantı referansı taşır, böylece logical-ID bağlamasına tabi olmazlar. Kestirme hedeflerinin tam listesi için OneLake kısayollarına bakınız. Dağıtım davranışı için Lakehouse Git entegrasyon ve dağıtım boru hatlarına bakınız.

Veri akışları (Gen2)

Varsayılan olarak, Dataflow Gen2 Fabric öğelerine mutlak referanslar oluşturur: sorgu, kaynak çalışma alanı ID'sini ve öğenin nesne kimliğini saklar, bunlar dağıtımda yeniden yazılmaz. Bir kaynak başvurusu, bunun yerine göreli bir başvuru kullanabilir: Bir Fabric bağlayıcısında !(Current Workspace) düğümü altındaki bir öğeyi seçtiğinizde sorgu, öğeyi adıyla saklar (GUID'ler olmadan) ve dağıtım sırasında hedef çalışma alanındaki eşleşen öğeye çözümlenir. Çıkış hedefleri her zaman mutlak referanslar kullanır ve yeniden bağlanmaz. Hedefler ve herhangi bir mutlak kaynak referansı için, çalışma alanları arası dağıtımda kullanmak üzere değerleri parametreleştirin. Daha fazla bilgi için Dataflow Gen2'de Fabric konnektörleriyle ilgili referanslar ve CI/CD ile Git entegrasyonlu Dataflow Gen2'ye bakınız.

Kaynak kaynakları:

Bağımlılık Git'te otomatik bağlama Notlar
Lakehouse Kısmi Yalnızca göreceli referans olarak yazıldığında yeniden bağlanır (!( Güncel çalışma alanı)); Varsayılan mutlak referans yeniden bağlanmaz.
Depo Kısmi Yalnızca göreceli referans olarak yazıldığında yeniden bağlanır (!( Güncel çalışma alanı)); Varsayılan mutlak referans yeniden bağlanmaz.

Varış nokta referansları:

Bağımlılık Git'te otomatik bağlama Notlar
Lakehouse Hayır
Depo Hayır
SQL Database Hayır

Spark İş Tanımları

Bağımlılık Git'te otomatik bağlama Notlar
Environment Yes
Lakehouse Hayır defaultLakehouseArtifactId nesne kimliği kullanır.

Kopyalama İşleri

Bağımlılık Git'te otomatik bağlama Notlar
Lakehouse Yes
Depo Hayır Veri ambarı artifactId, mantıksal kimlik üzerinden çözümlenip yeniden bağlanır; ancak linkedService kaynak çalışma alanının SQL endPoint'sini de depolar ve bu yeniden yazılmaz. Çalışma alanları arası dağıtım için endPoint öğesini parametreleştirin.
SQL Database Yes

GraphQL API'leri

Bağımlılık Git'te otomatik bağlama Notlar
SQL Uç Noktası Yes
Depo Yes
SQL Database Yes

Tüm GraphQL API veri kaynakları için, dağıtımdan sonra bağlantı ve kimlik bilgilerini yeniden yapılandırmanız gerekebilir.

Olay Akışları

Bağımlılık Git'te otomatik bağlama Notlar
Lakehouse Yes
Eventhouse Yes Öğeler aynı çalışma alanında bulunduğunda, tüm hedefler CI/CD kapsamında tamamen desteklenir. Doğrudan Alım modlu Eventhouse için, dağıtımdan sonra bağlantıyı manuel olarak yeniden yapılandırmanız gerekebilir. Daha fazla bilgi için Eventstream CI/CD sayfasına bakınız.
Aktivatör (Reflex) Yes Öğeler aynı çalışma alanında bulunduğunda, tüm hedefler CI/CD kapsamında tamamen desteklenir. Daha fazla bilgi için Eventstream CI/CD sayfasına bakınız.

KQL öğeleri

Bağımlılık Git'te otomatik bağlama Notlar
KQL veritabanından Eventhouse'a Yes DatabaseProperties.json içindeki parentEventhouseItemId, mantıksal bir kimliktir ve hedef eventhouse’a bağlanır. Bir KQL veritabanı, ana eventhouse'un çocuğu olarak dağıtılır.
KQL sorgu kümesinden KQL veritabanına Kısmi Öğe kimliği üzerinden değil, clusterUri ve databaseName üzerinden çözümlenir. Tanım bir databaseItemId'i içerir, ancak bu yeniden bağlanmayan bir nesne kimliğidir, yani çözünürlük ortamlar arasındaki URI'ye bağlıdır.
Real-Time Dashboard'dan KQL veritabanına Kısmi Küme URI'leri olan bir dataSources dizi kullanır. KQL queryset'le aynı desen.

Depolar

Bağımlılık Git'te otomatik bağlama Notlar
Depo (çapraz referans) Hayır Diğer depolara yapılan referanslar nesne kimlikleri kullanır.
SQL Uç Noktası Hayır SQL Endpoint referansları çalışma alanına özgü tanımlayıcılar kullanır.

Değişken Kitaplıkları

Bağımlılık Git'te otomatik bağlama Notlar
Fabric öğeleri (ItemReference türü) Hayır ItemReference değişken tipi, workspaceId ve itemId değerlerini ham GUID'ler olarak saklar. Bu değerleri her ortam için değer setleri üzerinden manuel olarak güncellemeniz veya geçersiz kılmanız gerekir.

Bağımlılığı olmayan öğeler

Aşağıdaki öğelerde çalışma alanları arası bağımlılık bağlamasına ilişkin herhangi bir sorun yoktur:

  • Environment
  • SQL Database
  • Eventhouse (kapsayıcı öğe; KQL veritabanları ona başvurur)
  • Yansıtılmış Veritabanı (yalnızca harici kaynak yapılandırması)

Summary

Fabric öğelerini çalışma alanları arasında dağıttığınızda, göndermeler taşınabilir mantıksal ID'ler yerine çalışma alanına özgü nesne kimlikleri olarak saklanırsa öğeler arasındaki bağımlılıklar bozulabilir. Tüm eşya türleri mantıksal kimlikler aracılığıyla bağımlılık bağlamasını desteklemez. Çapraz çalışma alanı dağıtımı kurmadan önce, bu makaledeki uyumluluk tablolarını inceleyerek hangi bağımlılıkların otomatik bağlandığını ve hangilerinin manuel parametreleştirme gerektirdiğini belirleyin.

İlgili içerik

  • Last updated on