Veri ambarlama

Veri ambarı, bir veya daha fazla farklı kaynaktaki tümleşik verilerin merkezi bir deposudur. Veri ambarları, mevcut ve geçmiş verileri depolar ve verilerin raporlanması ile analizi için kullanılır.

Azure 'da veri depolama

Verileri bir veri ambarına taşımak için veriler, önemli iş bilgileri içeren çeşitli kaynaklardan düzenli olarak ayıklanır. Veriler taşındığında, biçimlendirme, Temizleme, doğrulama, özetleme ve yeniden düzenlenmiş olabilir. Alternatif olarak, veriler, raporlama için ambarda sunulan toplanmış görünümlerle birlikte en düşük ayrıntı düzeyinde depolanabilir. Her iki durumda da, veri ambarı raporlama, analiz ve iş zekası (BI) için kalıcı bir veri deposu haline gelir.

Veri ambarı mimarileri

Aşağıdaki başvuru mimarileri, Azure 'da uçtan uca veri ambarı mimarilerini gösterir:

Bu çözüm ne zaman kullanılır?

İşlemsel sistemlerden çok büyük miktarlarda verileri, anlaşılması kolay bir biçimde açmanız gerektiğinde bir veri ambarı seçin. Veri ambarlarının OLTP veritabanlarında kullanmakta olduğunuz terse veri yapısını izlemesi gerekmez. İş kullanıcıları ve analistleri açısından anlamlı olan sütun adlarını kullanabilir, ilişkileri basitleştirecek şemayı yeniden yapılandırabilir ve çeşitli tabloları bir içinde birleştirebilirsiniz. Bu adımlar, bir veritabanı Yöneticisi (DBA) veya veri geliştiricisi yardımı olmadan, raporları oluşturması ve bı sistemlerindeki verileri analiz etmek isteyen kullanıcılara kılavuzluk eder.

Performans nedenleriyle geçmiş verileri kaynak işlem sistemlerinden ayrı tutmanız gerektiğinde bir veri ambarı kullanmayı düşünün. Veri ambarları, ortak biçimler, anahtarlar ve veri modelleri kullanarak merkezi bir konum sağlayarak birden çok konumdan geçmiş verilere erişmeyi kolaylaştırır.

Veri ambarları okuma erişimi için iyileştirildiğinden, raporların oluşturulması, raporlama için kaynak işlem sisteminin kullanılmasından daha hızlıdır.

Diğer avantajlar şunlardır:

  • Veri ambarı, birden fazla kaynaktan geçmiş verileri saklayabilir ve tek bir gerçeği kaynağını temsil edebilir.
  • Veri ambarına içeri aktarılırken verileri silerek veri kalitesini geliştirebilirsiniz.
  • Raporlama araçları, sorgu işleme döngüleri için işlem sistemleriyle rekabet vermez. Veri ambarı, okuma isteklerinin büyük çoğunluğunu karşılarken, veri ambarı yazma işlemlerini işlemeye odaklanmayı sağlar.
  • Veri ambarı, farklı yazılımlardan verileri birleştirebilir.
  • Veri araştırma araçları, otomatik yöntemleri kullanarak verilerde gizli desenleri bulabilir.
  • Veri ambarları, yetkili kullanıcılara güvenli erişim sağlamayı kolaylaştırır ve bu da başkalarına erişimi kısıtlamakla daha kolay hale gelir. İş kullanıcılarının, olası bir saldırı vektörünü kaldırarak kaynak verilere erişmesi gerekmez.
  • Veri ambarları, OLAP küplerigibi iş zekası çözümlerinin oluşturulmasını kolaylaştırır.

Zorluklar

Bir veri ambarını işletmenizin ihtiyaçlarına uyacak şekilde doğru şekilde yapılandırmak aşağıdaki güçlüklerden bazılarını gerçekleştirebilir:

  • İş kavramlarınızı doğru şekilde modellemek için gereken süre yürütülüyor. Veri ambarları bilgi odaklı. İşle ilgili terimleri ve para birimi ve tarih gibi ortak biçimleri standartlaştırmanız gerekir. Şemayı iş kullanıcılarına anlamlı bir şekilde yeniden yapılandırmak gerekir, ancak yine de veri toplamaların ve ilişkilerin doğruluğunu sağlar.

  • Veri düzenleme bilgilerinizi planlama ve ayarlama. Kaynak işlem sisteminden veri ambarına veri kopyalamayı ve geçmiş verilerin işletimsel veri depolarından ne zaman ambara taşınacağını göz önünde bulundurun.

  • Verileri ambara aktarılırken silerek veri kalitesini koruyun veya geliştirir.

Azure 'da veri depolama

Müşteri hareketlerinden veya iş uygulamalarından bağımsız olarak bir veya daha fazla veri kaynağınız olabilir. Bu veriler, geleneksel olarak bir veya daha fazla OLTP veritabanında depolanır. veriler, ağ paylaşımları, Azure Depolama blob 'ları veya bir veri gölü gibi diğer depolama ortamlarının hiçbirinde kalıcı hale gelebilir. veriler ayrıca veri ambarının kendisi veya Azure SQL Veritabanı gibi bir ilişkisel veritabanında da depolanabilir. Analitik veri deposu katmanının amacı, veri ambarına karşı analiz ve raporlama araçları tarafından verilen sorguları karşılamadır. Azure 'da, bu analitik depolama özelliği Azure SYNAPSE veya Hive veya etkileşimli sorgu kullanan Azure HDInsight ile karşılanamaz. Bunlara ek olarak, veri depolama alanından veri ambarı 'na taşımak veya verileri kopyalamak için bir düzenleme düzeyi gerekir. Bu işlem, Azure HDInsight üzerinde Azure Data Factory veya Oozie kullanılarak yapılabilir.

Gereksinimlerinize bağlı olarak, Azure 'da bir veri ambarı uygulamaya yönelik çeşitli seçenekler vardır. Aşağıdaki listeler, simetrik çoklu işlem (SMP) ve yüksek düzeyde paralel işleme (MPP) olmak üzere iki kategoride bölünmüştür.

SMP

MPP

Genel bir kural olarak, SMP tabanlı ambarlar, küçük ve orta ölçekli veri kümeleri (4-100 TB 'a kadar) için idealdir, ancak MPP genellikle büyük veriler için kullanılır. Küçük/orta ve büyük veriler arasındaki ölümde, kuruluşunuzun tanımıyla ve destekleyici altyapıda olması gerekmez. (Bkz. OLTP veri deposu seçme.)

Veri boyutlarının ötesinde, iş yükü deseninin türü büyük olasılıkla faktörü daha fazla belirlemede daha fazla olabilir. Örneğin, karmaşık sorgular bir SMP çözümü için çok yavaş olabilir ve bunun yerine bir MPP çözümü gerektirir. MPP tabanlı sistemler genellikle işlerin nasıl dağıtıldığı ve düğümler arasında birleştirilme nedeniyle küçük veri boyutları ile performans cezası olur. Veri boyutlarınız zaten 1 TB 'yi aşarsa ve sürekli büyüme bekleniyorsa, bir MPP çözümünü seçmeyi düşünün. Ancak, veri boyutlarınız daha küçükse, ancak iş yükleriniz SMP çözümünüzün kullanılabilir kaynaklarını aşalıyorsa MPP en iyi seçenek de olabilir.

veri ambarınızda erişilen veya depolanan veriler, Azure Data Lake Storagegibi bir veri gölü dahil olmak üzere çeşitli veri kaynaklarından gelebilir. Azure Data Lake kullanılabilecek MPP hizmetlerinin farklı güçlerini karşılaştıran bir video oturumu için, bkz. Azure Data Lake ve Azure veri ambarı: uygulamanıza modern uygulamalar uygulama.

SMP sistemleri, tüm kaynakları (CPU/bellek/disk) paylaşan bir ilişkisel veritabanı yönetim sisteminin tek bir örneği tarafından belirlenir. Bir SMP sisteminin ölçeğini değiştirebilirsiniz. bir vm üzerinde çalışan SQL Server için vm boyutunu ölçeklendirebilirsiniz. Azure SQL Veritabanı için, farklı bir hizmet katmanını seçerek ölçeği değiştirebilirsiniz.

MPP sistemleri daha fazla işlem düğümü (kendi CPU, bellek ve g/ç alt sistemleri) eklenerek genişletilebilir. Bir sunucunun ölçeklendirilmesine yönelik fiziksel sınırlamalar vardır. bu noktada, iş yüküne bağlı olarak genişleme ölçeğini daha da tercih edilir. Ancak, sorgulama, modelleme ve veri bölümleme farklılıkları, MPP çözümlerinin farklı bir yetenek kümesi gerektirdiğini anlamına gelir.

hangi SMP çözümünün kullanılacağına karar verirken bkz. Azure vm 'lerde Azure SQL Veritabanı ve SQL Server daha yakından bakış.

azure Synapse (eskiden azure SQL veri ambarı), iş yükünün işlem ve bellek yoğun olduğu küçük ve orta ölçekli veri kümeleri için de kullanılabilir. Azure SYNAPSE desenleri ve genel senaryolar hakkında daha fazla bilgi edinin:

Anahtar seçim ölçütleri

Seçimleri daraltmak için, bu soruları yanıtlayarak başlayın:

  • Kendi sunucularınızı yönetmek yerine yönetilen bir hizmet istiyor musunuz?

  • Son derece büyük veri kümeleriyle veya çok karmaşık, uzun süre çalışan sorgularla çalışıyor musunuz? Yanıt Evet ise, bir MPP seçeneği düşünün.

  • Büyük bir veri kümesi için veri kaynağı yapılandırılmış veya yapılandırılmamış mı? Yapılandırılmamış verilerin HDInsight üzerinde Spark, Azure Databricks, Hive LLAP veya Azure Data Lake Analytics gibi büyük bir veri ortamında işlenmesi gerekebilir. Bunlar, ELT (Ayıkla, yükle, Dönüştür) ve ETL (Ayıkla, Dönüştür, Yükle) altyapıları olarak işlev görebilir. İşlenen verileri yapılandırılmış verilere, Azure SYNAPSE veya diğer seçeneklerden birine yüklemeyi kolaylaştırır. Yapılandırılmış veriler için, Azure SYNAPSE, yoğun, yoğun performans gerektiren yoğun işlem gücü gerektiren iş yükleri için Işlem için Iyileştirilmiş adlı bir performans katmanına sahiptir.

  • Geçmiş verilerinizi geçerli, işletimsel verilerden ayırmak istiyor musunuz? Bu durumda, düzenleme gereken seçeneklerden birini belirleyin. Bunlar, ağır okuma erişimi için optimize edilmiş tek başına ambarlardır ve ayrı bir geçmiş veri deposu olarak en iyi şekilde idealdir.

  • OLTP veri deponuzda daha fazla sayıda kaynaktan veri tümleştirmeniz gerekiyor mu? Bu durumda, birden çok veri kaynağını kolayca tümleştiren seçenekleri göz önünde bulundurun.

  • Çok kullanıcılı bir gereksiniminiz mi var? Öyleyse, Azure Synapse bu gereksinim için ideal değildir. Daha fazla bilgi için bkz. Azure Synapse Desenler ve Anti-Patterns.

  • İlişkisel veri deposu mu tercih edersiniz? Öyleyse, ilişkisel veri deposu olan bir seçenek belirleyin, ancak gerekirse ilişkisel olmayan veri depolarını sorgulamak için PolyBase gibi bir araç kullanabileceğinizi unutmayın. Ancak PolyBase kullanmaya karar veriyorsanız, iş yükünüz için yapılandırılmamış veri kümelerinize karşı performans testleri çalıştırın.

  • Gerçek zamanlı raporlama gereksinimleriniz var mı? Yüksek hacimli tekli eklemelerde hızlı sorgu yanıt süreleri gerekirse, gerçek zamanlı raporlamayı destekleyen bir seçenek belirleyin.

  • Çok sayıda eşzamanlı kullanıcı ve bağlantı desteklemeniz gerekiyor mu? Bir dizi eşzamanlı kullanıcı/bağlantı destekleme özelliği çeşitli faktörlere bağlıdır.

    • Daha Azure SQL Veritabanı için hizmet katmanınıza göre belgelenmiş kaynak sınırlarına bakın.

    • SQL Server en fazla 32.767 kullanıcı bağlantısına izin verir. Bir VM üzerinde çalışan performans, VM boyutuna ve diğer faktörlere bağlıdır.

    • Azure Synapse sorguların ve eş zamanlı bağlantıların sınırları vardır. Daha fazla bilgi için bkz. Azure Synapse'de eşzamanlılık ve iş yükü yönetimi. Veri sınırlamalarını aşmak için Azure Analysis Services gibitamamlayıcı hizmetleri Azure Synapse.

  • Ne tür bir iş yükünüz var? Genel olarak, MPP tabanlı ambar çözümleri analiz, toplu iş odaklı iş yükleri için en uygun seçenektir. İş yükleriniz doğası gereği işlemselse, çok sayıda küçük okuma/yazma işlemi veya birden çok satır satır işlem varsa, SMP seçeneklerden birini kullanmayı göz önünde bulundurabilirsiniz. Bu kılavuzun bir istisnası, Spark Streaming gibi bir HDInsight kümesinde akış işleme kullanmak ve verileri bir Hive tablosunda depolamaktır.

Yetenek Matrisi

Aşağıdaki tablolarda, özellikler arasındaki temel farklar özetlenmiştir.

Genel özellikler

Özellik Azure SQL Veritabanı SQL Server (VM) Azure Synapse HDInsight'ta Apache Hive HDInsight üzerinde Hive LLAP
Yönetilen hizmet Yes Hayır Yes Evet 1 Evet 1
Veri düzenlemesi gerektirir (verilerin/geçmiş verilerin kopyasını tutar) Hayır Hayır Yes Yes Yes
Birden çok veri kaynağı kolayca tümleştirin Hayır Hayır Yes Yes Yes
İşlem duraklatma desteği Hayır Hayır Yes Hayır 2 Hayır 2
İlişkisel veri deposu Yes Yes Yes Hayır Hayır
Gerçek zamanlı raporlama Yes Yes Hayır Hayır Yes
Esnek yedekleme geri yükleme noktaları Yes Yes Hayır 3 Evet 4 Evet 4
SMP/MPP SMP SMP MPP MPP MPP

[1] El ile yapılandırma ve ölçeklendirme.

[2] HDInsight kümeleri gerekli değilken silinebilir ve sonra yeniden oluşturulabilir. Kümenizi silebilirsiniz verilerinizin korunarak kümenize bir dış veri deposu ekleme. İş yük Azure Data Factory için isteğe bağlı bir HDInsight kümesi oluşturarak kümenizin yaşam döngüsünü otomatikleştirmek için Azure Data Factory kullanabilir ve işlem tamamlandıktan sonra silebilirsiniz.

[3] Azure Synapse ile bir veritabanını son yedi gün içinde kullanılabilir herhangi bir geri yükleme noktasına geri yükleyebilirsiniz. Anlık görüntüler dört ile sekiz saatte bir başlar ve yedi gün boyunca kullanılabilir. Bir anlık görüntü yedi günden eski olduğunda süresi dolar ve geri yükleme noktası artık kullanılamaz.

[4] Gerektiğinde desteklenemez ve geri yüklenebilir bir dış Hive meta veri deposu kullanmayı göz önünde bulundurarak. Blob Depolama veya Data Lake Depolama için geçerli olan standart yedekleme ve geri yükleme seçenekleri ya da Daha fazla esneklik ve kullanım kolaylığı sağlamak için, Blob Depolama gibi üçüncü taraf HDInsight yedekleme ve geri yükleme çözümleri kullanılabilir.

Ölçeklenebilirlik özellikleri

Özellik Azure SQL Veritabanı SQL Server (VM) Azure Synapse HDInsight'ta Apache Hive HDInsight üzerinde Hive LLAP
Yüksek kullanılabilirlik için yedekli bölgesel sunucular Yes Yes Yes Hayır Hayır
Sorgu ölçeğini uzdurma (dağıtılmış sorgular) destekler Hayır Hayır Yes Yes Yes
Dinamik ölçeklenebilirlik Yes Hayır Evet 1 Hayır Hayır
Verilerin bellek içi önbelleğe alınmasını destekler Yes Yes Yes Yes Yes

[1] Azure SYNAPSE, veri ambarı birimlerinin (DWU) sayısını ayarlayarak ölçeği büyütme veya küçültme olanağı sağlar. Bkz. Azure 'da işlem gücünü yönetme SYNAPSE.

Güvenlik özellikleri

Özellik Azure SQL Veritabanı bir sanal makinede SQL Server Azure Synapse HDInsight üzerinde Apache Hive HDInsight üzerinde Hive LLAP
Kimlik Doğrulaması SQL/Azure Active Directory (Azure AD) SQL/Azure AD/Active Directory SQL/Azure AD Yerel/Azure AD 1 Yerel/Azure AD 1
Yetkilendirme Yes Yes Yes Yes Evet 1
Denetim Yes Yes Yes Yes Evet 1
Bekleme sırasında veri şifrelemesi Evet 2 Evet 2 Evet 2 Evet 2 Evet 1
Satır düzeyinde güvenlik Yes Yes Yes Hayır Evet 1
Güvenlik duvarlarını destekler Yes Yes Yes Yes Evet 3
Dinamik veri maskeleme Yes Yes Yes Hayır Evet 1

[1], etki alanına katılmış bir HDInsight kümesikullanılmasını gerektirir.

[2], bekleyen verileri şifrelemek ve şifresini çözmek için Saydam Veri Şifrelemesi (tde) kullanılmasını gerektirir.

[3] bir Azure sanal ağı içinde kullanıldığındadesteklenir.

Veri ambarınızın güvenliğini sağlama hakkında daha fazla bilgi edinin: