Microsoft Fabric karar kılavuzu: veri deposu seçme
Microsoft Fabric iş yükleriniz için bir veri deposu seçmenize yardımcı olması için bu başvuru kılavuzunu ve örnek senaryoları kullanın.
Veri deposu özellikleri
Ambar, göl evi, Eventhouse, SQL veritabanı ve Power BI datamart gibi Doku veri depolarını veri hacmi, tür, geliştirici kişisi, beceri kümesi, işlemler ve diğer özelliklere göre karşılaştırmak için bu bilgileri kullanın. Bu karşılaştırmalar aşağıdaki iki tablo halinde düzenlenmiştir:
| Tablo 1 / 2 | Lakehouse | Ambarı | Eventhouse |
|---|---|---|---|
| Veri birimi | Sınırsız | Sınırsız | Sınırsız |
| Veri türü | Yapılandırılmamış yarı yapılandırılmış, yapılandırılmış |
Yapılandırılmış yarı yapılandırılmış (JSON) |
Yapılandırılmamış yarı yapılandırılmış, yapılandırılmış |
| Birincil geliştirici kişisi | Veri mühendisi, veri bilimcisi | Veri ambarı geliştiricisi, veri mimarı, veri mühendisi, veritabanı geliştiricisi | Uygulama geliştirici, veri bilimcisi, veri mühendisi |
| Temel geliştirme becerisi | Spark (Scala, PySpark, Spark SQL, R) | SQL | Kod yok, KQL, SQL |
| Verileri göre düzenlenmiş | Klasörler ve dosyalar, veritabanları ve tablolar | Veritabanları, şemalar ve tablolar | Veritabanları, şemalar ve tablolar |
| Okuma işlemleri | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Yazma işlemleri | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, bağlayıcı ekosistemi |
| Çok tablolu işlemler | Hayır | Evet | Evet, çok tablolu veri alımı için |
| Birincil geliştirme arabirimi | Spark not defterleri, Spark iş tanımları | SQL betikleri | KQL Queryset, KQL Veritabanı |
| Güvenlik | RLS, CLS**, tablo düzeyi (T-SQL), Spark için yok | Nesne düzeyi, RLS, CLS, DDL/DML, dinamik veri maskeleme | RLS |
| Kısayollar aracılığıyla verilere erişme | Evet | Evet, SQL analitik uç noktası aracılığıyla | Evet |
| Kısayollar için kaynak olabilir | Evet (dosyalar ve tablolar) | Evet (tablolar) | Evet |
| öğeler arasında sorgu | Evet | Evet | Evet |
| Gelişmiş analiz | Büyük ölçekli veri işleme, yerleşik veri paralelliği ve hataya dayanıklılık için arabirim | Büyük ölçekli veri işleme, yerleşik veri paralelliği ve hataya dayanıklılık için arabirim | Time Series yerel öğeleri, tam coğrafi uzamsal ve sorgu özellikleri |
| Gelişmiş biçimlendirme desteği | PARQUET, CSV, AVRO, JSON ve Apache Hive uyumlu herhangi bir dosya biçimi kullanılarak tanımlanan tablolar | PARQUET, CSV, AVRO, JSON ve Apache Hive uyumlu herhangi bir dosya biçimi kullanılarak tanımlanan tablolar | Serbest metin ve JSON gibi yarı yapılandırılmış veriler için tam dizin oluşturma |
| alma gecikme süresi | Sorgulama için anında kullanılabilir | Sorgulama için anında kullanılabilir | Kuyruğa alınmış veri alımı ve akış veri alımı birkaç saniye gecikme süresine sahiptir. |
* Spark, kısayolları kullanarak tablolardan okumayı destekler, henüz görünümlere, saklı yordamlara, işlevlere vb. erişmeyi desteklemez.
| Tablo 2 / 2 | Fabric SQL veritabanı | Power BI Datamart |
|---|---|---|
| Veri birimi | 4 TB | En fazla 100 GB |
| Veri Türü | Yapılandırılmış yarı yapılandırılmış, Yapılandırılmamış |
Yapılandırılmış |
| Birincil geliştirici kişisi | Yapay zeka geliştiricisi, Uygulama geliştiricisi, veritabanı geliştiricisi, DB yöneticisi | Veri bilimcisi, veri analisti |
| Temel geliştirme becerisi | SQL | Kod yok, SQL |
| Verileri göre düzenlenmiş | Veritabanları, şemalar, tablolar | Veritabanı, tablolar, sorgular |
| Okuma işlemleri | T-SQL | Spark, T-SQL |
| Yazma işlemleri | T-SQL | Veri akışları, T-SQL |
| Çok tablolu işlemler | Evet, tam ACID uyumluluğu | Hayır |
| Birincil geliştirme arabirimi | SQL betikleri | Power BI |
| Güvenlik | Nesne düzeyi, RLS, CLS, DDL/DML, dinamik veri maskeleme | Yerleşik RLS düzenleyicisi |
| Kısayollar aracılığıyla verilere erişme | Evet | Hayır |
| Kısayollar için kaynak olabilir | Evet (tablolar) | Hayır |
| Öğeler arasında sorgulama | Evet | Hayır |
| Gelişmiş analiz | T-SQL analitik özellikleri, analiz için OneLake'e kopyalanan verilerin Delta Parquet formatında olmasıyla sağlanır. | Otomatik performans ayarlama ile veri işleme arabirimi |
| Gelişmiş biçimlendirme desteği | OLTP, JSON, vektör, grafik, XML, uzamsal, anahtar-değer için tablo desteği | PARQUET, CSV, AVRO, JSON ve Apache Hive uyumlu herhangi bir dosya biçimi kullanılarak tanımlanan tablolar |
| alma gecikme süresi | Sorgulama için anında kullanılabilir | Sorgulama için anında kullanılabilir |
** T-SQL kullanarak SQL analiz uç noktası üzerinden Lakehouse'da sütun düzeyinde güvenlik sağlanır.
Senaryo
Doku'da veri deposu seçme konusunda yardım için bu senaryoları gözden geçirin.
Senaryo 1
Profesyonel bir geliştirici olan Susan, Microsoft Fabric'i yeni kullanmaya başladı. Verileri temizlemeye, modellemeye ve analiz etmeye başlamaya hazırdır ancak veri ambarı veya göl evi oluşturmaya karar vermeleri gerekir. Önceki tablodaki ayrıntılar gözden geçirildikten sonra, birincil karar noktaları kullanılabilir beceri kümesi ve çok tablolu işlemlere duyulan gereksinimdir.
Susan, ilişkisel veritabanı altyapılarında veri ambarları oluşturmak için uzun yıllar harcadı ve SQL söz dizimi ve işlevselliği hakkında bilgi sahibidir. Daha büyük bir ekibi düşündüğümüzde, bu verilerin birincil tüketicileri de SQL ve SQL analiz araçları konusunda yeteneklidir. Susan, ekibin öncelikli olarak T-SQL ile etkileşim kurmasını sağlarken kuruluştaki tüm Spark kullanıcılarının da verilere erişmesine izin veren bir Fabric ambarıkullanmaya karar verir.
Susan yeni bir veri ambarı oluşturur ve diğer SQL sunucusu veritabanları gibi T-SQL kullanarak bu veri ambarıyla etkileşim kurar. SQL Server'da ambarını oluşturmak için yazdığı mevcut T-SQL kodunun çoğu, Fabric veri ambarında çalışır ve geçişi kolaylaştırır. Eğer o isterse, SQL Server Management Studio gibi diğer veritabanlarıyla çalışan aynı araçları bile kullanabilir. Fabric portalında SQL düzenleyicisini kullanarak Susan ve diğer ekip üyeleri, lakehouse'lardaki Delta tablolarına ve diğer veri ambarlarına başvuran analiz sorguları yazmak için yalnızca üç parçalı adlar kullanarak veritabanları arası sorgular gerçekleştirir.
Senaryo 2
Veri mühendisi Rob'un Fabric'te birkaç terabayt veri depolaması ve modellemesi gerekir. Ekip, PySpark ve T-SQL becerilerinin bir karışımına sahiptir. T-SQL sorgularını çalıştıran ekibin çoğu tüketicidir ve bu nedenle INSERT, UPDATE veya DELETE deyimleri yazması gerekmez. Kalan geliştiriciler not defterlerinde rahatça çalışabilir ve veriler Delta'da depolandığından benzer bir SQL söz dizimi ile etkileşim kurabiliyorlar.
Rob bir lakehousekullanmaya karar verir, bu da veri mühendisliği ekibinin çeşitli becerilerini veriler üzerinde uygulamasına olanak tanırken, T-SQL'de yüksek vasıflı olan ekip üyelerinin verilere erişmesine ve kullanmasına izin verir.
Senaryo 3
Bir vatandaş geliştirici olan Ash, bir Power BI geliştiricisi. Excel, Power BI ve Office hakkında bilgi sahibidirler. Bir iş birimi için veri ürünü oluşturmaları gerekir. Veri ambarı veya göl evi oluşturma becerilerine sahip olmadığını biliyorlar ve bunlar ihtiyaçları ve veri hacimleri için çok fazla gibi görünüyor. Önceki tablodaki ayrıntıları gözden geçirir ve birincil karar noktalarının kendi becerileri ve self servis, kod özelliği yok ve 100 GB'ın altındaki veri hacmine olan ihtiyaçları olduğunu görürler.
Ash, Power BI ve Microsoft Office hakkında bilgi sahibi olan iş analistleriyle birlikte çalışır ve zaten bir Premium kapasite aboneliğine sahip olduklarını bilir. Büyük ekiplerini düşünürken, bu verilerin birincil tüketicilerinin kod içermeyen ve SQL analiz araçlarına aşina olan analistler olduğunu fark ederler. Ash, Power BI datamartkullanmaya karar veriyor ve bu, ekibin kod gerektirmeyen bir deneyimle hızlı bir şekilde yetenek geliştirmesini ve etkileşim kurmasını sağlıyor. Sorgular Power BI ve T-SQL aracılığıyla yürütülebilir ve kuruluştaki Spark kullanıcılarının da verilere erişmesine olanak sağlar.
Senaryo 4
Daisy, büyük bir küresel perakende zincirinin tedarik zinciri performans sorunlarını analiz etmek için Power BI kullanma konusunda deneyimli iş analistidir. Milyarlarca veri satırını işleyebilen ve iş kararları almak için kullanılabilecek panolar ve raporlar oluşturmak için kullanılabilen ölçeklenebilir bir veri çözümü oluşturmaları gerekir. Veriler çeşitli yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış biçimlerdeki tesislerden, tedarikçilerden, nakliyecilerden ve diğer kaynaklardan gelir.
Daisy ölçeklenebilirliği, hızlı yanıt süreleri, zaman serisi analizi, jeo-uzamsal işlevler ve Power BI'daki hızlı doğrudan sorgu modu gibi gelişmiş analiz özellikleri nedeniyle eventhouse kullanmaya karar verir. Mevcut ve önceki dönemler arasında karşılaştırma yapmak, ortaya çıkan sorunları hızla belirlemek veya kara ve deniz yolları için jeo-uzamsal analiz sağlamak için Power BI ve KQL kullanılarak sorgular yürütülebilir.
Senaryo 5
Kirby, işletimsel veriler için .NET uygulamaları geliştirme konusunda deneyimli bir uygulama mimarıdır. İlişkisel bütünlük için tam ACID işlem uyumluluğu ve güçlü bir şekilde zorunlu yabancı anahtarlara sahip yüksek eşzamanlılık veritabanına ihtiyaç duyarlar. Kirby, günlük veritabanı yönetimini basitleştirmek için otomatik performans ayarlama avantajını istiyor.
Kirby, Azure SQL Veritabanı ile aynı SQL Veritabanı Altyapısı ile Fabric'te birSQL veritabanı seçer. Fabric'teki SQL veritabanları, iş günü boyunca talebi karşılayacak şekilde otomatik olarak ölçeklendirilir. Bunlar, işlem tablolarının tam kapasitesine ve serileştirilebilirden okunan anlık görüntüye kadar işlem yalıtım düzeylerinin esnekliğine sahiptir. Fabric üzerindeki SQL veritabanı, zamanla gözlemlenen yürütme planlarından gelen güçlü sinyallere göre otomatik olarak kümelenmemiş dizinler bırakır ve oluşturur.
Kirby'nin senaryosunda, işletimsel uygulamadaki veriler Fabric içerisindeki diğer verilerle birleştirilmelidir: Spark'ta, bir veri ambarında ve Eventhouse'taki gerçek zamanlı olaylardan elde edilen verilerle. Her Doku veritabanı bir SQL analiz uç noktası içerdiğinden, verilere Spark'tan veya DirectLake modu kullanılarak Power BI sorgularından gerçek zamanlı olarak erişilir. Bu raporlama çözümleri, birincil işletimsel veritabanını analiz iş yüklerinin yükünden ayırır ve normal dışı bırakmadan kaçınır. Kirby'nin diğer SQL veritabanlarında da mevcut işletimsel verileri vardır ve bu verileri dönüştürmeden içeri aktarması gerekir. Kirby, veri türü dönüştürmesi olmadan mevcut işletimsel verileri içeri aktarmak için Doku Data Factory ile veri işlem hatları tasarlar ve verileri Fabric SQL veritabanına aktarır.