Azure'da bulut ölçeği analizini ölçeklendirme
Ölçeklenebilir bir veri platformu, verilerin hızlı büyümesine yardımcı olmak için kritik öneme sahiptir. Dünyanın dört bir yanında her saniye çok büyük miktarlarda veri oluşturulur. Kullanılabilir veri miktarının önümüzdeki birkaç yıl içinde katlanarak artmaya devam etmesi beklenmektedir. Veri oluşturma hızı arttıkça veri taşıma hızı da artar.
Ne kadar veriniz olursa olsun kullanıcılarınız hızlı sorgu yanıtları talep eder. Sonuçlar için saat değil dakika beklemeyi beklerler. Bu makalede Azure bulut ölçeğinde analiz çözümünüzü nasıl ölçeklendirebileceğiniz ve hız için kullanıcı taleplerini karşılamaya nasıl devam ettiğiniz açıklanmaktadır.
Giriş
Birçok kuruluşta büyük veri platformu monolitleri vardır. Bu monolitler tek bir Azure Data Lake 2. Nesil hesabı ve bazen de tek bir depolama kapsayıcısı etrafında oluşturulur. Tek bir Azure aboneliği genellikle veri platformuyla ilgili tüm görevler için kullanılır. Abonelik düzeyinde ölçeklendirme çoğu mimari platformda yoktur ve kullanıcılar Azure aboneliği veya hizmet düzeyi sınırlamalarından herhangi birine karşılaşırsa Azure'ın sürekli benimsenmesini engelleyebilir. Kısıtlamaların bazıları geçici sınırlar olsa da, bunlara basmak veri platformunuz üzerinde önemli bir olumsuz etkiye neden olabilir.
Veri platformunuzu yapılandırırken kuruluşunuzun yapısını göz önünde bulundurun. Ekiplerinizin veri sahipliğini ve işlevsel sorumluluklarını not edin. Kuruluşunuz ekiplere büyük ölçüde özerklik ve dağıtılmış sahiplik sağlıyorsa en iyi seçeneğiniz veri ağı mimarisidir.
Bir çözümün çeşitli görevlerinden sorumlu olan farklı ekiplerin (alma, temizleme, toplama ve sunma gibi görevler) olduğu durumlardan kaçının. Birden çok takıma bağlı olarak hız kaybına neden olabilir. Örneğin, sunum katmanındaki veri tüketicilerinizin yeni veri varlıklarını eklemesi veya belirli bir veri varlığı için işlevsel değişiklikler yapması gerekiyorsa, çok adımlı bir işlemden geçmeleri gerekir. Bu örnekte adımlar şunlardır:
- Veri tüketicisi, bir veri işlem hattı aşamasından sorumlu olan tüm ekiplere bir bilet gönderir.
- Katmanlar birbirine bağlı olduğundan ekiplerin eşitlenmiş olarak birlikte çalışması gerekir. Yeni hizmetler, veri temizleme katmanında değişiklik yapılmasını gerektirir ve bu da veri toplama katmanında değişikliklere ve hizmet katmanında değişikliklere yol açar. Değişiklikler her işlem hattı aşamasını etkileyebilir.
- Uçtan uca yaşam döngüsünün tamamına genel bir bakışa sahip olmadıklarından, ekiplerin değişiklikleri işlemenin olası etkilerini görmesi zordur. Mevcut tüketiciler ve işlem hatları üzerindeki etkileri en aza indiren iyi tanımlanmış bir yayın planı tasarlamak için birlikte çalışmalıdırlar. Bu bağımlılık yönetimi yönetim ek yükünü artırır.
- Kural olarak, ekipler veri tüketicisinin istediği veri varlığı konusunda uzman değildir. Yeni veri kümesi özelliklerini veya parametre değerlerini anlamak için bir uzmana danışmaları gerekir.
- Tüm değişiklikler uygulandıktan sonra veri tüketicisine yeni veri varlığının kullanıma hazır olduğu bildirilir.
Her büyük kuruluşun binlerce veri tüketicisi vardır. Merkezi ekipler iş birimleri için bir performans sorunu haline geldiği için, açıklanan gibi karmaşık bir süreç büyük mimarilerde hızı ciddi ölçüde azaltır. Sonuç daha az yenilik ve sınırlı etkinliktir. Potansiyel olarak, iş birimleri hizmetten ayrılmaya ve kendi veri platformlarını oluşturmaya karar verebilir.
Ölçeklendirme yöntemleri
Bulut ölçeğinde analiz, iki temel kavramı kullanarak ölçeklendirme zorluklarına çözüm sağlar:
- Ölçeklendirme için veri giriş bölgelerini kullanma
- Dağıtılmış ve merkezi olmayan veri sahipliğini mümkün kılmak için ölçeklendirme için veri ürünlerini veya veri tümleştirmelerini kullanma
Tek bir veri giriş bölgesi veya birden çok veri giriş bölgesi dağıtabilirsiniz. Veri giriş bölgeleri, bir veri yönetimi giriş bölgesine bağlanarak verileri keşfetmenizi ve yönetmenizi sağlar. Her veri yönetimi giriş bölgesi tek bir Azure aboneliği içindedir.
Abonelikler Azure'ın yönetim, faturalama ve ölçek birimleridir. Bunlar, büyük ölçekli Azure benimseme planınızda kritik bir rol oynar.
Veri giriş bölgeleriyle ölçeklendirme
Bulut ölçeğinde analizin temel kavramları, veri yönetimi giriş bölgesi ve veri giriş bölgesidir. Her bir aboneliği kendi Azure aboneliğine yerleştirmelisiniz. Bunları ayırmak, görevleri net bir şekilde ayırmanıza, en az ayrıcalık ilkesine uymanıza ve daha önce bahsedilen abonelik ölçeği sorunlarını kısmen çözmenize olanak tanır. Minimum bulut ölçeğinde analiz kurulumu, tek bir veri giriş bölgesi ve tek bir veri yönetimi giriş bölgesi içerir.
Ancak, büyük ölçekli veri platformu dağıtımları için minimum kurulum yeterli değildir. Şirketler büyük ölçekli platformlar oluşturur ve zaman içinde verilerini ve analiz çalışmalarını tutarlı ve verimli bir şekilde ölçeklendirmek için yatırımlar yapar. Abonelik düzeyi sınırlamalarını aşmak için bulut ölçeğinde analiz, Azure giriş bölgelerinde açıklandığı gibi ölçeklendirme birimi olarak abonelikleri kullanır. Bu teknik, mimariye daha fazla veri giriş bölgesi ekleyerek veri platformu ayak izini artırmayı mümkün kılar. Bu tekniğin benimsenilmesi, her veri giriş bölgesi üç veri gölü içerdiğinden bir Azure Data Lake 2. Nesil'in tüm kuruluş için kullanılması sorununu da giderir. Birden çok etki alanından projeler ve etkinlikler birden fazla Azure aboneliğine dağıtılabilir ve böylece daha fazla ölçeklenebilirlik sağlanır.
Bulut ölçeğinde analiz mimarisi uygulamadan önce kuruluşunuzun kaç veri giriş bölgesi gerektirdiğine karar verin. Doğru karar vermek, etkili ve verimli bir veri platformunun temelini oluşturur.
Gerekli olan veri giriş bölgelerinin sayısı, özellikle de birçok faktöre bağlıdır:
- Kaç iş biriminin kendi veri giriş bölgesine ihtiyacı olduğu gibi kurumsal hizalama
- Kuruluşunuzun bir iş birimine özgü operasyon kaynaklarını ve kaynaklarını nasıl uyumlu hale getirmesi gibi operasyonel konular.
Doğru veri giriş bölgesi modelinin kullanılması, gelecekte veri ürünlerini ve veri varlıklarını bir giriş bölgesinden diğerine taşıma çabalarını en aza indirir. Ayrıca gelecekte büyük veri ve analiz çalışmalarını etkili ve tutarlı bir şekilde ölçeklendirmenize de yardımcı olur.
Dağıtılacak veri giriş bölgesi sayısına karar ve alırken aşağıdaki faktörleri göz önünde bulundurun.
| Faktör | Tanım |
|---|---|
| Kuruluş yapısı ve veri sahipliği | Kuruluşunuzun nasıl yapılandırıldığını ve verilerin kuruluşunuza nasıl ait olduğunu düşünün. |
| Bölge ve konum | Birden çok bölgede dağıtım yaparsanız, veri bölgelerini hangi bölgenin veya bölgelerin barındırılacağına karar verin. Tüm veri yerleşimi gereksinimlerini karşıladığınızdan emin olun. |
| Kotalar | Abonelik kotaları kapasite garantisi değildir ve bölge bazında uygulanır. |
| Veri egemenliği | Veri hakimiyeti düzenlemeleri nedeniyle verilerin belirli bir bölgede depolanması ve bölgeye özgü ilkeleri izlemesi gerekir. |
| Azure ilkeleri | Veri giriş bölgeleri, çeşitli Azure ilkelerinin gereksinimlerini karşılamalıdır. |
| Yönetim sınırı | Abonelikler, idare ve yalıtım için endişeleri açıkça ayıran bir yönetim sınırı sağlar. |
| Ağ | Her giriş bölgesinin bir sanal ağı vardır. Bir sanal ağ tek bir bölgede bulunduğundan, her yeni bölge için yeni bir giriş bölgesi gerekir. Etki alanları arası iletişimi etkinleştirmek için sanal ağların eş sanal ağlar olması gerekir. |
| Sınırlar | Aboneliğin sınırları vardır. Birkaç aboneliğe sahip olarak bu sınırları aşmanın tehlikelerini azaltabilirsiniz. |
| Maliyet tahsisatı | Merkezi olarak ödenen depolama hesapları gibi paylaşılan hizmetlerin iş birimine veya etki alanına göre bölünmesi gerekip gerekmediğini göz önünde bulundurun. Ayrı bir abonelik kullanmak maliyet ayırma için bir sınır oluşturur. Etiketleri kullanarak aynı işlevi elde edebilirsiniz. |
| Veri sınıflandırmaları ve çok gizli veriler | Güvenlik mekanizmaları, veri ürün geliştirmeyi ve veri platformunun kullanılabilirliğini etkileyebilir. Veri sınıflandırmalarını göz önünde bulundurun ve son derece gizli veri kümelerinin tam zamanında erişim, müşteri tarafından yönetilen anahtarlar (CMK), ayrıntılı ağ denetimleri veya daha fazla şifreleme gibi özel işlemlere gerek olup olmadığına karar verin. |
| Diğer yasal veya güvenlik etkileri | Verilerin mantıksal veya fiziksel ayrımını gerektiren başka yasal veya güvenlik gereksinimleri olup olmadığını göz önünde bulundurun. |
Veri ağı mimarisi uygularsanız, veri giriş bölgelerinizi ve veri etki alanlarınızı dağıtmaya karar verirseniz aşağıdaki faktörleri göz önünde bulundurun.
| Faktör | Tanım |
|---|---|
| Veri etki alanları | Kuruluşunuzun kullandığı veri etki alanlarını göz önünde bulundurun ve hangisinin veri platformunuzda olacağını belirleyin. Tek tek veri etki alanlarınızın boyutunu göz önünde bulundurun. Daha fazla bilgi için bkz. Veri etki alanları nedir? |
| Gecikme süresi | Büyük miktarda veri üzerinde işbirliği yapan etki alanları, giriş bölgeleri arasında büyük miktarda veri aktarabilir. Etki alanlarınızı aynı giriş bölgesine veya bölgeye ayırmayı göz önünde bulundurun. Bunların ayrılması gecikme süresini artırır ve bölgeler arası etki alanlarında maliyetleri artırabilir. |
| Güvenlik | Bazı hizmet dağıtımları veya yapılandırmaları abonelikte yükseltilmiş ayrıcalıklar gerektirir. Bu ayrıcalıkların bir etki alanındaki kullanıcıya örtük olarak verilmesi, söz konusu kullanıcıya aynı abonelikteki diğer etki alanlarında da aynı ayrıcalıkları verir. |
Abonelikler için bulut benimseme çerçevesi kılavuzunda daha fazla önemli nokta bulabilirsiniz.
Birçok kuruluş, kurumsal veri platformlarının verimli bir şekilde ölçeklendirilmesini ister. İş birimleri, benzersiz gereksinimlerini karşılamak için kendi veri çözümlerini ve uygulamalarını oluşturabilmelidir. Mevcut veri platformlarının çoğu ölçeklenebilirlik ve merkezi olmayan sahiplik kavramlarına göre oluşturulmadığından bu özelliğin sağlanması zor olabilir. Bu eksiklik, bu veri platformlarının mimarisinde, ekip yapısında ve operasyon modelinde açıkça görülmektedir.
Veri giriş bölgeleri kuruluşunuzda veri siloları oluşturmaz. Bulut ölçeğinde analiz için önerilen ağ kurulumu, giriş bölgeleri arasında güvenli ve yerinde veri paylaşımına olanak tanır ve bu da veri etki alanları ve iş birimleri arasında yeniliklere olanak tanır. Daha fazla bilgi edinmek için bkz . Ağ mimarisiyle ilgili dikkat edilmesi gerekenler.
Kimlik katmanı için de aynı durum geçerlidir. Tek bir Microsoft Entra kiracısı kullandığınızda, kimliklere birden çok veri giriş bölgesinde bulunan veri varlıklarına erişim izni vekleyebilirsiniz. Kullanıcı ve kimlik yetkilendirme işlemi hakkında daha fazla bilgi edinmek için bkz . Veri erişim yönetimi.
Dekont
Birden çok veri giriş bölgeniz varsa, her bölge başka bölgelerde barındırılan verilere bağlanabilir. Bu, grupların işletmeniz genelinde işbirliği yapmasına olanak tanır.
Bulut ölçeğinde analiz, tutarlı idareyi desteklemek için ortak bir mimari kullanır. Mimariniz temel özellikleri ve ilkeleri tanımlar. Tüm veri giriş bölgeleri aynı denetim ve denetimlere bağlıdır. Ekipleriniz veri işlem hatları oluşturabilir, kaynakları alabilir ve raporlar ve panolar gibi veri ürünleri oluşturabilir. Teams gerektiğinde Spark/SQL analizi de yapabilir. İlkedeki özelliğe hizmet ekleyerek veri giriş bölgesi özelliklerini artırabilirsiniz. Örneğin, bir ekip bir iş gereksinimini gidermek için üçüncü taraf grafik altyapısı ekleyebilir.
Bulut ölçeğinde analiz, verileri korumak ve çeşitli grupların veri ürünlerini keşfetmesini mümkün kılmak için merkezi kataloglama ve sınıflandırmaya güçlü bir vurgu yapar.
Dikkat
Bölgeler arasında verileri sorgulamanızı öneririz. Bunun yerine verilerin, bölgesel sınırlara dikkat ederek bunu kullanan işlemle yakın olduğundan emin olun.
Bulut ölçeğinde analiz mimarisi ve veri giriş bölgeleri kavramı, kuruluşunuzun zaman içinde veri platformunuzun boyutunu kolayca artırmasını mümkün hale getirir. Aşamalı bir yaklaşımda daha fazla veri giriş bölgesi ekleyebilirsiniz. Müşterilerinizin ilk başta birden çok giriş bölgesi olması gerekmez. Bu mimariyi benimsediğinizde, birkaç veri giriş bölgesine ve bunların içerdiği veri ürünlerine öncelik belirleyin. Uygun öncelik belirleme, bulut ölçeğinde analiz dağıtımınızın başarısını sağlamaya yardımcı olur.
Veri ürünleri veya veri tümleştirmeleri ile ölçeklendirme
Kuruluşunuz her giriş bölgesi içinde veri uygulamalarını kullanarak ölçeklendirilebilir. Veri uygulamaları, veri mimarinizin diğer veri uygulamaları tarafından kullanılmak üzere okuma için iyileştirilmiş veri ürünleri sağlayan işlevleri kapsülleyen birimleri veya bileşenleridir. Azure'da veri uygulamaları, işlevsel ekiplerin veri çözümleri ve iş yükleri uygulamasını mümkün hale getiren kaynak grupları biçimindeki ortamlardır. veri çözümünün veri alımı, temizleme, toplama ve görev sunma dahil olmak üzere uçtan uca yaşam döngüsünü ilişkili bir ekip üstlenir.
Bulut ölçeğinde analiz, daha önce ele alınan veri tümleştirme ve sorumluluk sorunlarını ele alır. Başvuru tasarımı, tablo alımı ve kaynak sistem tümleştirmesi için monolitik işlevsel sorumluluklar yerine veri etki alanları tarafından yönetilen dağıtılmış bir mimari sağlar. İşlevsel ekipler, veri kapsamının uçtan uca işlevsel sorumluluğunu ve sahipliğini üstlenmiştir.
Merkezi bir teknik yığına ve veri işleme iş akışınızın tüm görevlerinden sorumlu bir ekime sahip olmak yerine, uçtan uca sorumluluğu birden çok otonom işlevsel veri tümleştirme ekibine dağıtabilirsiniz. Her ekibin bir etki alanı veya alt etki alanı özelliği vardır ve veri tüketicilerinin gerektirdiği şekilde veri kümeleri sunmaları teşvik edilir.
Bu mimari farklılıklar, veri platformunuzda hızın artmasına yol açar. Veri tüketicilerinizin artık bir dizi merkezi takıma güvenmesi veya istenen değişikliklerin önceliklendirilmek için mücadele etmeleri gerekmez. Daha küçük ekipler uçtan uca tümleştirme iş akışınızın sahipliğini aldıkça, veri sağlayıcısı ile veri tüketicisi arasındaki geri bildirim döngüsü çok daha kısa olur. Bu yaklaşım daha hızlı öncelik belirleme, daha hızlı geliştirme döngüleri ve daha çevik bir geliştirme süreciyle sonuçlanır. İşlevsel veri tümleştirme ekibinin uçtan uca teknik yığın ve değişikliklerin etkileri konusunda tam farkındalığı olduğundan ekiplerinizin artık işlemleri ve sürüm planlarını kendi aralarında eşitlemesi gerekmez. Tüketiciler üzerindeki genel etkiyi en aza indirmek için birim ve tümleştirme testleri çalıştırmak için yazılım mühendisliği uygulamalarını kullanabilir.
İdeal olarak, veri tümleştirme sistemlerinin sahibi olan ekip de kaynak sistemlere sahip olur. Bu ekip, kaynak sistemlerde çalışan veri mühendislerinden, veri kümeleri, bulut mühendisleri ve veri ürünü sahipleri için konu uzmanlarından (KOBİ) oluşmalıdır. Bu tür bir işlevsel ekip oluşturmak, dış ekiplerle gereken iletişim miktarını azaltır ve altyapıdan gerçek veri işlem hatlarına kadar tüm yığınınızı geliştirirken çok önemlidir.
Veri platformunuzun temeli, kaynak sistemlerden tümleştirilmiş veri kümeleridir. Bu veri kümeleri, veri ürün ekiplerinizin iş olgu tablolarında yenilik yapmasını ve karar alma ile iş süreçlerini geliştirmesini mümkün hale getirir. Veri tümleştirme ekipleriniz ve veri ürün ekipleriniz tüketicilere SLA'lar sunmalı ve tüm sözleşmelerin karşılandığından emin olmalıdır. Sunulan SLA'lar veri kalitesi, güncellik, hata oranları, çalışma süresi ve diğer görevlerle ilgili olabilir.
Özet
Kuruluşunuz, bulut ölçekli analiz mimarinizin ölçeklendirme mekanizmalarını kullanarak azure içindeki veri varlıklarınızı zaman içinde büyütürken iyi bilinen teknik sınırlamalardan kaçınmaktadır. Bu makalede açıklanan ölçeklendirme yöntemlerinin her ikisi de farklı teknik karmaşıklıkların üstesinden gelmenize yardımcı olur ve basit ve verimli bir şekilde kullanılabilir.