Azure purview dağıtımı en iyi uygulamaları

Bu makalede, üretim ortamına purview dağıtmanıza yardımcı olabilecek ortak görevler tanımlanmaktadır. Bu görevler, bir ay veya daha uzun bir süre boyunca aşamalar halinde tamamlanabilir. Bu kılavuzu zaten dağıtmış olan kuruluşlar bile, yatırımlarından en iyi şekilde yararlanmak için bu kılavuzu kullanabilir.

Bir veri yönetimi platformunun (Azure purview gibi) iyi planlanmış bir dağıtımı, aşağıdaki avantajları sağlayabilir:

• Daha iyi veri bulma
• Geliştirilmiş analitik işbirliği
• Büyütülmüş, yatırımdaki dönüş.

Önkoşullar

• geliştirme veya üretim aboneliğiyle Microsoft Azure erişim
• Purview dahil Azure kaynakları oluşturma yeteneği
• test, geliştirme veya üretim ortamlarında Azure Data Lake Storage veya Azure SQL gibi veri kaynaklarına erişim
  • Data Lake Storage için, taranacak gerekli rol okuyucu rolüne sahiptir
  • SQL için, kimliğin sınıflandırmaların örneklemesini sağlamak üzere tabloları sorgulayabilmelidir
• Bulut için Microsoft Defender veya veri etiketlemeye yönelik bulut Yöneticisi için Defender ile işbirliği yapabilme erişimi

Hedefleri ve hedefleri belirleme

Birçok kuruluş, kuruluş genelinde yalıtılmış grupların ve veri etki alanlarının belirli gereksinimlerine karşılık gelen bireysel çözümler geliştirip veri idare yolculuğunu başlattı. Deneyimler sektöre, ürüne ve kültüre bağlı olarak değişebilir, ancak çoğu kuruluş bu çözüm türleri için tutarlı denetimleri ve ilkeleri korumayı zorlaştırır.

Erken aşamalarda tanımlamak isteyebileceğiniz bazı yaygın veri idare hedefleri şunları içerir:

• Verilerinizin iş değerini en üst düzeye çıkarma
• Veri tüketicilerinin verileri kolayca bulabileceği, yorumlayabildiği ve güvenebileceği bir veri kültürünü etkinleştirme
• Tutarlı bir veri deneyimi sağlamak için çeşitli iş birimleri arasında işbirliğini artırma
• Bulutun avantajlarından yararlanmaya yönelik veri analizlerini hızlandırarak yeniliği hızlandırma
• Çeşitli beceri grupları için self servis seçenekleri aracılığıyla verileri keşfetme süresini düşürme
• Hizmeti müşterilerine iyileştiren analiz çözümlerinin teslimatı için pazara harcanan süreyi azaltma
• Etki alanına özgü araçların ve desteklenmeyen teknolojinin kullanılması nedeniyle oluşan işlemsel riskleri azaltma

Genel yaklaşım, bu fazla bu hedefleri çeşitli kategorilere ve hedeflere bölmek için kullanılır. Bazı örnekler şunlardır:

Sorun için sık sorulan sorular

Kuruluşunuz üst düzey hedefleri ve hedefleri kabul ederse, birden çok gruptan çok sayıda soru olacaktır. Tüm kaygıları ele almak için bir plan yapmak üzere bu soruların toplanması önemlidir. İlk aşamada çalıştırabileceğiniz bazı örnek sorular:

1. Ana kuruluş veri kaynakları ve veri sistemleri nelerdir?
2. Henüz purview tarafından desteklenmeyen veri kaynakları için seçeneklerim nelerdir?
3. Kaç tane purview örneğine ihtiyacım var?
4. Who kullanıcılar mı?
5. Who yeni veri kaynaklarını tarayabilmesi mi?
6. Who, purview içindeki içerikleri değiştirebilir mi?
7. Purview 'daki veri kalitesini artırmak için hangi işlemleri kullanabilirim?
8. Mevcut kritik varlıklar, Sözlük terimleri ve ilgili kişilerle platformu önyükleme
9. Mevcut sistemlerle nasıl tümleştirilir?
10. Geri bildirim toplama ve sürdürülebilirlik bir işlem oluşturma

Bu soruların büyük bir kısmını hemen cevaplamadığınızda, kuruluşunuzun bu projeyi taşımasına ve tüm "gerekli-sahip" gereksinimlerinin karşılanmasını sağlamanıza yardımcı olabilir.

Doğru paydaşları dahil et

Tüm kuruluş için takip eden bir işlemin başarısını sağlamak üzere, doğru proje katılımcıları eklemek önemlidir. İlk aşamada yalnızca birkaç kişi yer alır. Ancak, kapsam genişledikçe projeye katkıda bulunmak ve geri bildirim sağlamak için ek kişiler gerekir.

Dahil etmek isteyebileceğiniz bazı anahtar hissedarları:

Anahtar senaryolarını tanımla

Purview, bulut ve şirket içi ortamları kapsayan bir kuruluşun verileri genelinde veri yönetimini merkezi olarak yönetmek için kullanılabilir. Başarılı bir uygulamaya sahip olmak için, iş için kritik olan önemli senaryoları belirlemeniz gerekir. Bu senaryolar, iş birimi sınırlarını düzenleyebilir veya birden çok kullanıcıyı yukarı akış ya da aşağı akış olarak etkileyebilir.

Bu senaryolar çeşitli yollarla yazılabilir, ancak en az şu beş boyutu eklemeniz gerekir:

1. kişi – Who kullanıcılardır mi?
2. kaynak sistem: Azure Data Lake Storage 2. veya Azure SQL Veritabanı gibi veri kaynakları nelerdir?
3. Etki alanı: bu senaryonun kategorisi nedir?
4. Ayrıntılı senaryolar – Kullanıcılar sorunları çözmek için Purview'u nasıl kullanır?
5. Beklenen sonuç – Başarı ölçütleri nedir?

Senaryolar ölçülebilir sonuçlarla belirli, eyleme çalıştırılabilir ve yürütülebilir olabilir. Kullanabileceğiniz bazı örnek senaryolar:

Dağıtım modelleri

Temel tüketim kullanım örnekleriyle Purview kullanan yalnızca bir küçük grubunuz varsa, bu yaklaşım tüm gruba hizmet vermek için tek bir Purview örneğine sahip olmak kadar basit olabilir. Ancak, kurumda birden fazla Purview örneğine ihtiyaç olup olmadığını da merak ediyor da olabilir. Birden çok Purview örneği kullanıyorsanız çalışanlar varlıkları bir aşamadan diğerine nasıl yükseltebilirsiniz?

Purview örneklerinin sayısını belirleme

Çoğu durumda, kuruluşun tamamı için yalnızca bir Purview hesabı olması gerekir. Bu yaklaşım, platformun değerinin platform içinde bulunan verilerin bir işlevi olarak katlanarak arttiği "ağ etkileri" yaklaşımının en yüksek avantajını kullanır.

Ancak, bu düzenin özel durumları vardır:

1. Yeni yapılandırmaları test etme – Kuruluşlar, yalıtılmış ortamlarda tarama yapılandırmalarını veya sınıflandırmalarını test etmek için birden çok örnek oluşturmak istiyor olabilir. Platformun bazı alanlarında sözlük gibi bir "sürüm özelliği" olsa da, serbestçe test etmek için "atılabilir" bir örneğin olması daha kolay olacaktır.
2. Test, Üretim Öncesi ve Üretim arasında ayrım : Kuruluşlar, farklı ortamlarda depolanan farklı veri türleri için farklı platformlar oluşturmak istiyor. Bu tür veriler farklı içerik türleri olduğu için önerilmez. İçerik türlerini yalıt etmek için en üst hiyerarşi düzeyinde veya kategoride sözlük terimini kullanabilirsiniz.
3. Conglomerates ve federated model : Conglomerates'te genellikle ayrı olarak çalışan birçok iş birimi (BU) vardır ve bazı durumlarda faturalandırmayı paylaşmazlar. Bu gibi durumlarda kuruluş, her BU için bir Purview örneği oluşturacak. Bu model ideal değildir, ancak özellikle de BUS'lar genellikle faturalamayı paylaşmaya istekli değildir.
4. Uyumluluk: Meta verileri bile hassas olarak işleyen ve belirli bir coğrafyada olmasını gerektiren bazı katı uyumluluk kuralları vardır. Bir şirketin birden çok coğrafyası varsa tek çözüm, her coğrafya için bir tane olmak için birden çok Purview örneğine sahip olmaktır.

Üretime taşıma işlemi oluşturma

Bazı kuruluşlar, Purview'un tek bir üretim sürümüyle çalışarak işleri basit tutmaya karar verebilirsiniz. Büyük olasılıkla bulma, arama ve göz atma senaryolarını aşan bir yere gitmeleri gerek değildir. Bazı varlıklarda yanlış sözlük terimleri varsa, insanların kendi kendini düzeltmesine izin vermeleri oldukça bağışlayıcıdır. Ancak Purview'u çeşitli iş birimlerine dağıtmak isteyen kuruluşların çoğu bir süreç ve denetim biçimine sahip olmak ister.

Üretim sürecinize dahil etmek için bir diğer önemli yön de sınıflandırmaların ve etiketlerin nasıl geçirilir olduğudur. Purview'da 90'dan fazla sistem sınıflandırıcısı vardır. Dosya, tablo veya sütun varlıklarına sistem veya özel sınıflandırmalar uygulayabilirsiniz. Sınıflandırmalar konu etiketlerine benzer ve tarama sırasında veri emlak içinde bulunan belirli bir türün içeriğini işaretlemek ve tanımlamak için kullanılır. Duyarlılık etiketleri, kuruluş verilerinizdeki sınıflandırma türleri kategorilerini tanımlamak ve ardından her kategoriye uygulamak istediğiniz ilkeleri gruplamak için kullanılır. Veri kaynağıyla aynı hassas bilgi türlerini Microsoft 365, mevcut güvenlik ilkelerinizi ve korumanızı tüm içeriğinize ve veri varlıklarınıza esndirmenizi sağlar. Belgeleri tarar ve otomatik olarak sınıflandırabilirsiniz. Örneğin, multiple.docx adlı bir dosyanız varsa ve içeriğinde Ulusal Kimlik numarası varsa Purview Varlık Ayrıntıları sayfasında AB Ulusal Kimlik Numarası gibi sınıflandırmalar ekler.

Purview'da Katalog Yöneticilerinin yaşam döngüsü boyunca tutarlılık ve bakım için en iyi yöntemlerin sağlanması gereken birkaç alan vardır:

• Veri varlıkları – Veri kaynaklarının ortamlar arasında yenidencanned olması gerekir. Yalnızca geliştirme aşamasında tarama yapmak ve üretimde API'leri kullanarak bunları yeniden oluşturmak önerilmez. Bunun ana nedeni, Purview tarayıcılarının veri varlıklarını arkalarında çok daha fazla "kablolama" yapmalarıdır ve bu da bunları farklı bir Purview örneğine taşımak için karmaşık olabilir. Aynı veri kaynağını üretime eklemek ve kaynakları yeniden taramak çok daha kolaydır. Genel en iyi yöntem, kullanılan tüm taramaların, bağlantıların ve kimlik doğrulama mekanizmalarının belgelerinin olmasıdır.
• Tarama kuralı kümeleri – Bu, algı yapılacak dosya türü ve sınıflandırmalar gibi belirli bir taramaya atanan kurallar koleksiyonunuzdur. Bu kadar çok tarama kuralı kümeniz yoksa, bunları Üretim aracılığıyla el ile yeniden oluşturabilirsiniz. Bunun için bir iç işlem ve iyi belgeler gerekir. Ancak kural kümeleri günlük veya haftalık olarak değişirse, bu sorun, kural REST API giderildi.
• Özel sınıflandırmalar – Sınıflandırmalar düzenli olarak da değişemiyor olabilir. Dağıtımın ilk aşamasında, özel sınıflandırmalarla ilgili çeşitli gereksinimleri anlamak biraz zaman alır. Ancak, bu işlem tamam olduktan sonra çok az değişiklik gerektirir. Bu nedenle buradaki öneri, tüm özel sınıflandırmaları geçişe el ile geçirmek veya sınıflandırmayı REST API.
• Sözlük – UX aracılığıyla sözlük terimlerini dışarı ve içeri aktarma mümkündür. Otomasyon senaryoları için aşağıdaki REST API.
• Kaynak kümesi desen ilkeleri – Bu işlevsellik, tüm tipik kuruluşların uygulayacakları çok gelişmiştir. Bazı durumlarda, Azure Data Lake Depolama klasör adlandırma kuralları ve Purview'un kaynak kümesi oluşturması için sorunlara neden olan belirli bir yapıya sahiptir. İş biriminiz, iş ihtiyaçlarına uygun ek özelleştirmelerle kaynak kümesi derlemesini değiştirmek de istiyor olabilir. Bu senaryo için en iyisi, tüm değişiklikleri REST API takip etmek ve dış sürüm oluşturma platformu aracılığıyla belgelemektedir.
• Rol ataması: Purview'a kimlerin ve hangi izinlerin sahip olduğunu denetlemeniz gereken yer burasıdır. Purview ayrıca REST API ve rollerin dışarı ve içeri aktarmasını desteklemeye yönelik bir destek de içerir, ancak bu Atlas API ile uyumlu değildir. Öneri bir Azure Güvenlik Grubu atamak ve bunun yerine grup üyeliğini yönetmektir.

Purview ile farklı tümleştirme noktaları planlama ve uygulama

Büyük olasılıkla olgun bir kuruluşun zaten mevcut bir veri kataloğu vardır. Asıl soru, mevcut teknolojiyi kullanmaya devam edip Purview ile eşitleme yapmaya devam etmektir. Purview, bir kuruluşta mevcut ürünlerle eşitlemeyi işlemek için Atlas REST API'lerini sağlar. Atlas API'leri hem itme hem de çekme senaryolarını ele alan güçlü ve esnek bir mekanizma sağlar. Bilgiler bootstrap etmek veya başka bir sistemden Purview'a en son güncelleştirmeleri itmek için Atlas API'leri kullanılarak Purview'da yayımlanır. Purview'da bulunan bilgiler Atlas API'leri kullanılarak da okunabilir ve ardından mevcut ürünlerle geri eşitleniyor.

Bilet oluşturma, özel kullanıcı arabirimi ve düzenleme gibi diğer tümleştirme senaryolarında Atlas API'lerini ve Kafka uç noktalarını kullanabilirsiniz. Genel olarak, Purview ile dört tümleştirme noktası vardır:

• Veri Varlığı – Bu, Purview'un bir mağazanın varlıklarını tarayarak bu varlıkların ne olduğunu sıralamasını ve bunlar hakkında hazır meta verileri toplamasını sağlar. Bu SQL veritabanı, tablo, saklı yordam, görünüm ve yapılandırma verileri gibi yerlerde sys.tables tutulabilir. Bu, Azure Data Factory (ADF) gibi bir durum için tüm işlem hatlarını numaralanıyor ve oluşturulduklarında, son çalıştırmada, geçerli durumda veri alıyor olabilir.
• Lineage: Bu, Purview'ın verilerin nasıl hareket halinde olduğuyla ilgili bir analiz/veri koleksiyonu sisteminden bilgi toplamaya olanak sağlar. Spark gibi bir şey için bu, not defterinin hangi verileri alan, nasıl dönüştüren ve nereden çıktı yaptığını görmek için bir not defterinin yürütülmesinden bilgi toplamak olabilir. Bu SQL gibi bir şey için sorgu günlüklerini analiz ederek hangi mühendislik işlemlerinin yürütülebilir ve ne yaptığını tersine çevirebilir. İhtiyaçlara bağlı olarak hem itme hem de çekme tabanlı veri verisi desteği sunar.
• Sınıflandırma– Bu, Purview'ın veri kaynaklarından fiziksel örnekleri alıp sınıflandırma sistemimizde çalıştırmalarını sağlar. Sınıflandırma sistemi bir veri parçasının semantiğini belirler. Örneğin, bir dosyanın bir Parquet dosyası olduğunu ve üç sütunu olduğunu ve üçüncü birinin bir dize olduğunu biliyoruz. Ancak örneklerde çalıştırdığımız sınıflandırıcılar, dizenin bir ad, adres veya telefon numarası olduğunu bize bildirir. Bu tümleştirme noktasını aydınlatma, purview 'ın Not defterleri, işlem hatları, Parquet dosyaları, tablolar ve kapsayıcılar gibi nesneleri nasıl açabildiğimiz anlamına gelir.
• katıştırılmış deneyim – "studio" gibi deneyim (ADF, Synapse, SQL studio, pbı ve Dynamics gibi), genellikle kullanıcıların etkileşimde bulunmak istedikleri verileri bulmasını ve ayrıca çıktı verilerine yönelik yerleri bulmasını sağlamak ister. Takip etme kataloğu, bir ekleme deneyimi sağlayarak bu deneyimleri hızlandırmaya yardımcı olabilir. Bu deneyim, iş ortağının seçeneğinde API veya UX düzeyinde gerçekleşebilir. Kuruluş, purview 'a bir çağrı katıştırarak veri varlıklarını bulmak için veri kaynaklarını bulma, bkz. kökenini, şemaları denetleme, derecelendirmelere bakma, kişiler vb.

1. Aşama: pilot

Bu aşamada, çok küçük bir kullanıcı kümesi için purview oluşturulmalı ve yapılandırılmalıdır. Genellikle, tek bir grup 2-3, birlikte çalışarak uçtan uca senaryolar aracılığıyla çalışmak üzere çalışır. Kuruluşlarındaki purview 'ın advoki olarak değerlendirilir. Bu aşamanın ana amacı, önemli işlevlerin karşılanabileceği ve doğru paydaşların projenin farkında olduğundan emin olmaktır.

Tamamlanacak görevler

Kabul ölçütleri

• Purview hesabı kuruluş kiracısında kuruluş aboneliğinde başarıyla oluşturuldu.
• Birden çok rolü olan küçük bir Kullanıcı grubu, purview 'a erişebilir.
• Takip görünümü en az bir veri kaynağını taramak üzere yapılandırılmıştır.
• Kullanıcılar, şu gibi bir takip görünümü 'nin anahtar değerlerini ayıklayabilmelidir:
  • Ara ve araştır
  • Köken
• Kullanıcılar varlık sayfasından varlık sahipliğini atayabilmelidir.
• Önemli hissedarlara daha fazla tanıma yükseltmek için sunum ve tanıtım.
• MVP aşamasına yönelik ek kaynakları onaylamak için yönetimden satın alın.

2. Aşama: en düşük uygulanabilir ürün

Takip edilen gereksinimlere ve katılan iş birimlerine bir adım eklemek için, bir sonraki adım en düşük uygun ürün (MVP) sürümü üzerinde çalışır. Bu aşamada, takip görünümü kullanımını, yatay ve dikey olarak ek ihtiyaçlarına sahip olacak daha fazla kullanıcıya genişletecaksınız. Sözlük terimleri, arama ve tarama gibi tüm kullanıcılar için yatay olarak karşılanması gereken önemli senaryolar olacaktır. ayrıca, her bir iş birimi veya grubu için kökenini gibi belirli bir uçtan uca senaryoyu kapsayacak şekilde, her bir departman veya grubun, Power BI Azure Data Lake Storage.

Tamamlanacak görevler

Kabul ölçütleri

• Daha büyük bir kullanıcı grubunu Takiview 'a başarıyla ekleme (50 +)
• İş açısından kritik veri kaynaklarını Tara
• Tüm kritik sözlük koşullarını içeri ve ata
• Anahtar varlıklarda önemli etiketlemenin başarıyla test edilmesi
• Katılmış iş birimleri kullanıcıları için en düşük senaryolar başarıyla karşılanmadı

3. Aşama: ön üretim

MVP aşaması geçtikten sonra, üretim öncesi kilometre taşını planlamaya zaman atalım. Kuruluşunuz, ön üretim ve üretim için ayrı bir purview örneğine izin verebilir veya aynı örneği koruyabilir ancak erişimi kısıtlayabilir. Ayrıca, bu aşamada SQL Server gibi şirket içi veri kaynaklarına tarama dahil etmek isteyebilirsiniz. Veri kaynaklarında, purview tarafından desteklenmeyen bir boşluk varsa, ek seçenekleri anlamak için Atlas API 'sini araştırmanız zaman alabilir.

Tamamlanacak görevler

Kabul ölçütleri

• Tüm kullanıcılarla en az bir iş birimini başarıyla ekleme
• SQL Server gibi şirket içi veri kaynağını SQL Server
• REST API kullanarak POC en az bir tümleştirme REST API
• Altyapı ve güvenlikle ilgili önemli alanları içermesi gereken bir üretim planı tamamlama

4. Aşama: Üretim

Daha iyi idare programlarının temeli olan etkili bir bilgi idaresi oluşturmak için yukarıdaki aşamalar izlenmektedir. Veri idaresi, kuruluşta AI, Hadoop, IoT ve blok zinciri gibi artan eğilimlere hazırlanmanıza yardımcı olur. Bu, veri ve analizle ilgili birçok şeyin başlangıcıdır ve tartışılacak çok daha fazla şey vardır. Bu çözümün sonucu şunları sağlar:

• İş Odaklı- Teknik gereksinimlere göre iş gereksinimlerine ve senaryolara uygun bir çözüm.
• Geleceğe Hazır - Bir çözüm platformun varsayılan özelliklerini en üst düzeye çıkaracak ve platformun ilerlemelerini/evrimini desteklemek için yapılandırma veya betik etkinlikleri için standartlaştırılmış sektör uygulamalarını kullanır.

Tamamlanacak görevler

Kabul ölçütleri

• Tüm iş birimini ve kullanıcılarını başarıyla ekleme
• Üretim için altyapı ve güvenlik gereksinimlerini başarıyla karşılama
• Kullanıcılar için gereken tüm kullanım durumlarını başarıyla karşılama

Platform sağlamlaştırma

Ek sağlamlaştırma adımları atabilirsiniz:

• Güvenlik duvarı kaynaklarında taramayı etkinleştirerek veya Özel Bağlantı kullanarak güvenlik duruşlarını artırma
• Tarama performansını geliştirmek için kapsam taramasına ince ayar uygulama
• Yedekleme ve kurtarma için kritik meta verileri ve özellikleri dışarı aktarmaya rest API'leri kullanma
• İnsan hatalarını önlemek için bilet oluşturma ve olay oluşturma adımlarını otomatikleştirmek için iş akışını kullanma

Sonraki adımlar

• Koleksiyonlar için en iyi yöntemler
• Giriş sayfasında gezinme ve varlık arama