Otomatik kurumsal iş zekası

Microsoft Entra ID
Azure Analysis Services
Azure Blob Storage
Azure Data Factory
Azure Synapse Analytics

Çözüm fikirleri

Bu makale bir çözüm fikridir. İçeriği olası kullanım örnekleri, alternatif hizmetler, uygulama konuları veya fiyatlandırma yönergeleri gibi daha fazla bilgiyle genişletmemizi isterseniz GitHub geri bildirimi sağlayarak bize bildirin.

Bu örnek, ayıklama , yükleme ve dönüştürme (ELT) işlem hattında artımlı yükleme gerçekleştirme hakkındadır. ELT işlem hattını otomatikleştirmek için Azure Data Factory'yi kullanır. İşlem hattı, şirket içi SQL Server veritabanındaki en son OLTP verilerini artımlı olarak Azure Synapse'e taşır. İşlem verileri analiz için tablosal modele dönüştürülür.

Mimari

Architecture diagram for automated enterprise BI with Azure Synapse Analytics and Azure Data Factory.

Bu mimarinin bir Visio dosyasını indirin.

Bu mimari, Azure Synapse ile Enterprise BI'da gösterilen mimariye dayalıdır, ancak kurumsal veri ambarı senaryoları için önemli olan bazı özellikler ekler.

  • Data Factory kullanarak işlem hattının otomasyonu.
  • Artımlı yükleme.
  • Birden çok veri kaynağını tümleştirme.
  • Jeo-uzamsal veriler ve görüntüler gibi ikili verileri yükleme.

İş Akışı

Mimari aşağıdaki hizmet ve bileşenlerden oluşur.

Veri kaynakları

Şirket içi SQL Server. Kaynak veriler şirket içindeki bir SQL Server veritabanında bulunur. Şirket içi ortamın benzetimini yapmak için. Kaynak veritabanı olarak Wide World Importers OLTP örnek veritabanı kullanılır.

Dış veriler. Veri ambarları için yaygın bir senaryo, birden çok veri kaynağını tümleştirmektir. Bu başvuru mimarisi, yıla göre şehir popülasyonlarını içeren bir dış veri kümesini yükler ve OLTP veritabanındaki verilerle tümleştirir. Bu verileri şu içgörüler için kullanabilirsiniz: "Her bölgedeki satış artışı nüfus artışıyla eşleşir veya aşıyor mu?"

Veri alımı ve veri depolama

Blob Depolama. Blob depolama, kaynak verileri Azure Synapse'e yüklemeden önce hazırlama alanı olarak kullanılır.

Azure Synapse. Azure Synapse , büyük verilerde analiz gerçekleştirmek için tasarlanmış dağıtılmış bir sistemdir. Yüksek hacimli paralel işleme (MPP) özelliğini destekleyen Azure Synapse yüksek performanslı analiz çalıştırmaya uygundur.

Azure Data Factory. Data Factory , veri taşımayı ve veri dönüştürmeyi düzenleyen ve otomatik hale getiren bir yönetilen hizmettir. Bu mimaride, ELT işleminin çeşitli aşamalarını koordine eder.

Analiz ve raporlama

Azure Analysis Services. Analysis Services , veri modelleme özellikleri sağlayan tam olarak yönetilen bir hizmettir. Anlam modeli Analysis Services'e yüklenir.

Power BI. Power BI, iş içgörüleri için verileri analiz etmeye yönelik bir iş analizi araçları paketidir. Bu mimaride Analysis Services'de depolanan anlam modelini sorgular.

Kimlik Doğrulaması

Microsoft Entra Id (Microsoft Entra ID), Power BI aracılığıyla Analysis Services sunucusuna bağlanan kullanıcıların kimliğini doğrular.

Data Factory, hizmet sorumlusu veya Yönetilen Hizmet Kimliği (MSI) kullanarak Azure Synapse'de kimlik doğrulaması yapmak için Microsoft Entra Id'yi de kullanabilir.

Bileşenler

Senaryo ayrıntıları

Veri işlem hattı

Azure Data Factory'de işlem hattı, bir görevi koordine etmek için kullanılan etkinliklerin mantıksal bir gruplandırmasıdır; bu durumda verileri Azure Synapse'e yükler ve dönüştürür.

Bu başvuru mimarisi, bir dizi alt işlem hattı çalıştıran bir üst işlem hattını tanımlar. Her alt işlem hattı verileri bir veya daha fazla veri ambarı tablosuna yükler.

Screenshot of the pipeline in Azure Data Factory.

Öneriler

Artımlı yükleme

Otomatik bir ETL veya ELT işlemi çalıştırdığınızda, yalnızca önceki çalıştırmadan sonra değişen verileri yüklemek en verimli yöntemdir. Bu, tüm verileri yükleyen tam yük yerine artımlı yük olarak adlandırılır. Artımlı yük gerçekleştirmek için hangi verilerin değiştiğini belirlemek için bir yol gerekir. En yaygın yaklaşım yüksek su işareti değeri kullanmaktır. Bu, kaynak tablodaki bir sütunun en son değerini (tarih saat sütunu veya benzersiz bir tamsayı sütunu) izlemek anlamına gelir.

SQL Server 2016'dan başlayarak, zamana bağlı tabloları kullanabilirsiniz. Bunlar, veri değişikliklerinin tam geçmişini tutan sistem sürümü tablolardır. Veritabanı altyapısı, her değişikliğin geçmişini otomatik olarak ayrı bir geçmiş tablosunda kaydeder. Sorguya for SYSTEM_TIME yan tümcesi ekleyerek geçmiş verileri sorgulayabilirsiniz. Dahili olarak, veritabanı altyapısı geçmiş tablosunu sorgular, ancak bu uygulama için saydamdır.

Dekont

SQL Server'ın önceki sürümleri için Veri Yakalamayı Değiştir (CDC) kullanabilirsiniz. Ayrı bir değişiklik tablosu sorgulamanız gerektiğinden ve değişiklikler zaman damgası yerine günlük dizisi numarasıyla izlendiğinden, bu yaklaşım zamansal tablolardan daha az kullanışlıdır.

Zamana bağlı tablolar, zaman içinde değişebilen boyut verileri için kullanışlıdır. Olgu tabloları genellikle satış gibi sabit bir işlemi temsil eder ve bu durumda sistem sürümü geçmişini tutmak mantıklı değildir. Bunun yerine, işlemler genellikle filigran değeri olarak kullanılabilen işlem tarihini temsil eden bir sütuna sahiptir. Örneğin, Geniş Dünya İçeri Aktarıcıları OLTP veritabanında Sales.Invoices ve Sales.InvoiceLines tablolarında varsayılan olarak sysdatetime()olarak belirlenmiş bir LastEditedWhen alan vardır.

ELT işlem hattının genel akışı aşağıdadır:

  1. Kaynak veritabanındaki her tablo için, son ELT işinin çalıştırıldığında kesme süresini izleyin. Bu bilgileri veri ambarında depolayın. (İlk kurulumda, tüm zamanlar '1-1-1900' olarak ayarlanır.)

  2. Veri dışarı aktarma adımı sırasında kesme süresi, kaynak veritabanındaki bir dizi saklı yordama parametre olarak geçirilir. Bu saklı yordamlar, kesme zamanından sonra değiştirilen veya oluşturulan tüm kayıtları sorgular. Satış bilgileri tablosu için LastEditedWhen sütun kullanılır. Boyut verileri için sistem sürümüne dayalı zamana bağlı tablolar kullanılır.

  3. Veri geçişi tamamlandığında kesme sürelerini depolayan tabloyu güncelleştirin.

Her ELT çalıştırması için bir köken kaydetmek de yararlıdır. Belirli bir kayıt için, köken bu kaydı verileri oluşturan ELT çalıştırmasıyla ilişkilendirir. Her ETL çalıştırması için, her tablo için başlangıç ve bitiş yükleme sürelerini gösteren yeni bir köken kaydı oluşturulur. Her kaydın köken anahtarları boyut ve olgu tablolarında depolanır.

Screenshot of the city dimension table

Ambara yeni bir veri toplu işlemi yüklendikten sonra Analysis Services tablolu modelini yenileyin. Bkz . REST API ile zaman uyumsuz yenileme.

Veri temizleme

Veri temizleme, ELT işleminin bir parçası olmalıdır. Bu başvuru mimarisinde hatalı verilerden biri, bazı şehirlerin hiç veri olmadığından sıfır nüfusa sahip olduğu şehir nüfus tablosudur. İşlem sırasında ELT işlem hattı bu şehirleri şehir nüfus tablosundan kaldırır. Dış tablolar yerine hazırlama tablolarında veri temizleme gerçekleştirin.

Dış veri kaynakları

Veri ambarları genellikle birden çok kaynaktan verileri birleştirir. Örneğin, demografik veriler içeren bir dış veri kaynağı. Bu veri kümesi, WorldWideImportersDW örneğinin bir parçası olarak Azure blob depolamada kullanılabilir.

Azure Data Factory, blob depolama bağlayıcısını kullanarak doğrudan blob depolamadan kopyalayabilir. Ancak, bağlayıcı bir bağlantı dizesi veya paylaşılan erişim imzası gerektirir, bu nedenle blobu genel okuma erişimiyle kopyalamak için kullanılamaz. Geçici bir çözüm olarak, PolyBase kullanarak Blob depolama üzerinden bir dış tablo oluşturabilir ve ardından dış tabloları Azure Synapse'e kopyalayabilirsiniz.

Büyük ikili verileri işleme

Örneğin, kaynak veritabanında, Şehir tablosunda coğrafya uzamsal veri türünü barındıran bir Konum sütunu vardır. Azure Synapse coğrafya türünü yerel olarak desteklemediğinden bu alan yükleme sırasında varbinary türüne dönüştürülür. (Bkz. Desteklenmeyen veri türleri için geçici çözümler.)

Ancak PolyBase, sütun boyutu üst sınırını varbinary(8000)destekler ve bu da bazı verilerin kesilebileceği anlamına gelir. Bu sorunun geçici bir çözümü, dışarı aktarma sırasında verileri öbeklere ayırmak ve sonra öbekleri aşağıdaki gibi yeniden bir araya getirmektir:

  1. Konum sütunu için geçici bir hazırlama tablosu oluşturun.

  2. Her şehir için konum verilerini 8000 baytlık öbeklere bölerek her şehir için 1 – N satır elde edin.

  3. Öbekleri yeniden birleştirmek için, T-SQL PIVOT işlecini kullanarak satırları sütunlara dönüştürün ve sonra her şehrin sütun değerlerini birleştirin.

Zorluk, her şehrin coğrafya verilerinin boyutuna bağlı olarak farklı sayıda satıra bölünmesidir. PIVOT işlecinin çalışması için her şehrin aynı sayıda satıra sahip olması gerekir. Bu işe yaraması için T-SQL sorgusu, her şehrin özetten sonra aynı sayıda sütuna sahip olması için satırları boş değerlerle doldurmaya yönelik bazı püf noktaları yapar. Sonuçta elde edilen sorgu, satırlar arasında teker teker döngüye geçmekten çok daha hızlı sonuçlanır.

Görüntü verileri için de aynı yaklaşım kullanılır.

Yavaşça değişen boyutlar

Boyut verileri görece statiktir, ancak değişebilir. Örneğin, bir ürün farklı bir ürün kategorisine yeniden atanabilir. Yavaş değişen boyutları işlemeye yönelik çeşitli yaklaşımlar vardır. Tür 2 olarak adlandırılan yaygın bir teknik, boyut her değiştiğinde yeni bir kayıt eklemektir.

Tür 2 yaklaşımını uygulamak için boyut tablolarının belirli bir kayıt için geçerlilik tarihi aralığını belirten ek sütunlara ihtiyacı vardır. Ayrıca, kaynak veritabanındaki birincil anahtarlar yinelenir, bu nedenle boyut tablosunun yapay bir birincil anahtarı olmalıdır.

Örneğin, aşağıdaki resimde Dimension.City tablosu gösterilmektedir. WWI City ID Sütun, kaynak veritabanındaki birincil anahtardır. City Key sütunu ETL işlem hattı sırasında oluşturulan yapay bir anahtardır. Ayrıca tabloda Valid From , her satırın geçerli olduğu aralığı tanımlayan ve Valid To sütunları olduğuna da dikkat edin. Geçerli değerler Valid To '9999-12-31' değerine eşittir.

Screenshot of the city dimension table

Bu yaklaşımın avantajı, analiz için değerli olabilecek geçmiş verileri korumasıdır. Ancak, aynı varlık için birden çok satır olacağı anlamına da gelir. Örneğin, = 28561 ile eşleşen WWI City ID kayıtlar şunlardır:

Second screenshot of the city dimension table

Her Satış olgusunda, bu olguyu Fatura tarihine karşılık gelen Şehir boyutu tablosundaki tek bir satırla ilişkilendirmek istiyorsunuz.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Güvenlik

Güvenlik, kasıtlı saldırılara ve değerli verilerinizin ve sistemlerinizin kötüye kullanılmasına karşı güvence sağlar. Daha fazla bilgi için bkz . Güvenlik sütununa genel bakış.

Ek güvenlik için Sanal Ağ hizmet uç noktalarını kullanarak Azure hizmet kaynaklarının güvenliğini yalnızca sanal ağınızla sağlayabilirsiniz. Bu, bu kaynaklara genel İnternet erişimini tamamen kaldırır ve yalnızca sanal ağınızdan gelen trafiğe izin verir.

Bu yaklaşımla Azure'da bir sanal ağ oluşturur ve ardından Azure hizmetleri için özel hizmet uç noktaları oluşturursunuz. Bu hizmetler daha sonra bu sanal ağdan gelen trafikle sınırlandırılır. Bunlara şirket içi ağınızdan bir ağ geçidi üzerinden de ulaşabilirsiniz.

Aşağıdaki sınırlamalara dikkat edin:

  • Hizmet uç noktaları Azure Depolama için etkinleştirildiyse PolyBase, Depolama Azure Synapse'e veri kopyalayamaz. Bu sorun için bir azaltma vardır. Daha fazla bilgi için bkz . Azure depolama ile Sanal Ağ Hizmet Uç Noktalarını kullanmanın etkisi.

  • Verileri şirket içinden Azure Depolama taşımak için şirket içi veya ExpressRoute'unuzdan genel IP adreslerine izin vermeniz gerekir. Ayrıntılar için bkz . Azure hizmetlerinin sanal ağlarla güvenliğini sağlama.

  • Analysis Services'ın Azure Synapse'ten veri okumasını sağlamak için Azure Synapse hizmet uç noktasını içeren sanal ağa bir Windows VM dağıtın. Bu VM'ye Azure Şirket İçi Veri Ağ Geçidi'ni yükleyin. Ardından Azure Analysis hizmetinizi veri ağ geçidine bağlayın.

DevOps

  • Üretim, geliştirme ve test ortamları için ayrı kaynak grupları oluşturun. Ayrı kaynak grupları dağıtımları yönetmeyi, test dağıtımlarını silmeyi ve erişim haklarını atamayı kolaylaştırır.

  • Her iş yükünü ayrı bir dağıtım şablonuna yerleştirin ve kaynakları kaynak denetim sistemlerinde depolayın. Şablonları bir CI/CD işleminin parçası olarak birlikte veya tek tek dağıtarak otomasyon sürecini kolaylaştırabilirsiniz.

    Bu mimaride üç ana iş yükü vardır:

    • Veri ambarı sunucusu, Analysis Services ve ilgili kaynaklar.
    • Azure Data Factory.
    • Şirket içi ortamdan buluta simülasyon senaryosu.

    Her iş yükünün kendi dağıtım şablonu vardır.

    Veri ambarı sunucusu, IaC uygulamasının kesinlik temelli yaklaşımını izleyen Azure CLI komutları kullanılarak ayarlanır ve yapılandırılır. Dağıtım betiklerini kullanmayı ve bunları otomasyon işlemiyle tümleştirmeyi göz önünde bulundurun.

  • İş yüklerinizi hazırlamayı göz önünde bulundurun. Çeşitli aşamalara dağıtın ve sonraki aşamaya geçmeden önce her aşamada doğrulama denetimleri çalıştırın. Bu şekilde, güncelleştirmeleri üretim ortamlarınıza yüksek denetimli bir şekilde gönderebilir ve tahmin edilmeyen dağıtım sorunlarını en aza indirebilirsiniz. Canlı üretim ortamlarını güncelleştirmek için Mavi-yeşil dağıtım ve Kanarya sürümleri stratejilerini kullanın.

    Başarısız dağıtımları işlemek için iyi bir geri alma stratejisine sahip olun. Örneğin, dağıtım geçmişinizden daha önceki ve başarılı bir dağıtımı otomatik olarak yeniden dağıtabilirsiniz. Azure CLI'da --rollback-on-error bayrağı parametresine bakın.

  • Azure İzleyici , tümleşik izleme deneyimi için veri ambarınızın ve azure analiz platformunun tamamının performansını analiz etmek için önerilen seçenektir. Azure Synapse Analytics , veri ambarı iş yükünüzle ilgili içgörüleri göstermek için Azure portalında bir izleme deneyimi sağlar. Azure portalı, ölçümler ve günlükler için yapılandırılabilir saklama süreleri, uyarılar, öneriler ve özelleştirilebilir grafikler ve panolar sağladığından veri ambarınızı izlerken önerilen araçtır.

Daha fazla bilgi için Microsoft Azure İyi Tasarlanmış Çerçeve'deki DevOps bölümüne bakın.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış.

Maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Bu başvuru mimarisinde kullanılan hizmetlerle ilgili dikkat edilmesi gereken bazı noktalar aşağıdadır.

Azure Data Factory

Azure Data Factory, ELT işlem hattını otomatikleştirir. İşlem hattı, şirket içi SQL Server veritabanındaki verileri Azure Synapse'e taşır. Daha sonra veriler analiz için tablosal modele dönüştürülür. Bu senaryo için fiyatlandırma, etkinlik, tetikleyici ve hata ayıklama çalıştırmaları içeren aylık 0,001 ABD doları etkinlik çalıştırmasından başlar. Bu fiyat yalnızca düzenleme için temel ücrettir. Ayrıca verileri kopyalama, aramalar ve dış etkinlikler gibi yürütme etkinlikleri için ücretlendirilirsiniz. Her etkinlik ayrı ayrı fiyatlanır. Ayrıca, ilişkili tetikleyicisi olmayan veya ay içinde çalıştırılan işlem hatları için de ücretlendirilirsiniz. Tüm etkinlikler dakika başına eşit olarak dağıtılır ve yukarı yuvarlanır.

Örnek maliyet analizi

İki farklı kaynaktan iki arama etkinliğinin olduğu bir kullanım örneğini düşünün. Biri 1 dakika 2 saniye (2 dakikaya yuvarlanır) ve diğeri 1 dakika sürer ve toplam 3 dakika sürer. Bir veri kopyalama etkinliği 10 dakika sürer. Bir saklı yordam etkinliği 2 dakika sürer. Toplam etkinlik 4 dakika boyunca çalışır. Maliyet aşağıdaki gibi hesaplanır:

Etkinlik çalıştırmaları: 4 * 0,001 USD = 0,004 USD

Aramalar: 3 * ($0,005 / 60) = $0,00025

Saklı yordam: 2 * ($0,00025 / 60) = $0,000008

Veri kopyalama: 10 * (0,25 ABD doları / 60) * 4 veri tümleştirme birimi (DIU) = 0,167 USD

  • İşlem hattı çalıştırması başına toplam maliyet: 0,17 ABD doları.
  • 30 gün boyunca günde bir kez çalıştırın: 5,1 abd doları.
  • 30 gün boyunca her 100 tablo için günde bir kez çalıştır: 510 ABD doları

Her etkinliğin ilişkili bir maliyeti vardır. Fiyatlandırma modelini anlayın ve ADF fiyatlandırma hesaplayıcısını kullanarak yalnızca performans için değil maliyet için de iyileştirilmiş bir çözüm elde edin. Hizmetlerinizi başlatarak, durdurarak, duraklatarak ve ölçeklendirerek maliyetlerinizi yönetin.

Azure Synapse

Azure Synapse, daha yüksek sorgu performansı ve işlem ölçeklenebilirliği gereksinimlerine sahip yoğun iş yükleri için idealdir. Kullandıkça öde modelini seçebilir veya bir yıllık (%37 tasarruf) veya 3 yıllık (%65 tasarruf) ayrılmış planları kullanabilirsiniz.

Veri depolama ayrı ücretlendirilir. Olağanüstü durum kurtarma ve tehdit algılama gibi diğer hizmetler de ayrı ücretlendirilir.

Daha fazla bilgi için bkz . Azure Synapse Fiyatlandırması.

Analysis Services

Azure Analysis Services fiyatlandırması katmana bağlıdır. Bu mimarinin başvuru uygulaması değerlendirme, geliştirme ve test senaryoları için önerilen Geliştirici katmanını kullanır. Diğer katmanlar arasında küçük üretim ortamı için önerilen Temel katman; görev açısından kritik üretim uygulamaları için Standart katman yer alır. Daha fazla bilgi için bkz . İhtiyacınız olduğunda doğru katman.

Örneğinizi duraklattığınızda ücret uygulanmaz.

Daha fazla bilgi için bkz . Azure Analysis Services fiyatlandırması.

Blob Depolama

Depolama maliyetini düşürmek için Azure Depolama ayrılmış kapasite özelliğini kullanmayı göz önünde bulundurun. Bu modelle, bir veya üç yıl boyunca sabit depolama kapasitesi için rezervasyona kaydolabiliyorsanız indirim alırsınız. Daha fazla bilgi için bkz . Ayrılmış kapasite ile Blob depolama maliyetlerini iyileştirme.

Daha fazla bilgi için Microsoft Azure İyi Tasarlanmış Çerçeve'deki Maliyet bölümüne bakın.

Sonraki adımlar

Aynı teknolojilerden bazılarını kullanarak belirli çözümleri gösteren aşağıdaki Azure örnek senaryolarını gözden geçirmek isteyebilirsiniz: