Microsoft Azure Data Technologies: An Overview

David Chappell
Microsoft Azure Veri Teknolojileri:
Genel Bilgiler
Microsoft Corporation Sponsorluğunda
Telif Hakkı © 2014 Chappell & Associates
İçindekiler
Blobs ................................................................................................................................................................... 3
Sanal Makinede DBMS Çalıştırma ....................................................................................................................... 4
SQL Database ...................................................................................................................................................... 5
DocumentDB ....................................................................................................................................................... 7
Tables ................................................................................................................................................................. 8
HDInsight .......................................................................................................................................................... 10
Hadoop MapReduce .............................................................................................................................................10
Hadoop HBase.......................................................................................................................................................12
Search ............................................................................................................................................................... 13
Sonuç ................................................................................................................................................................ 15
Yazar Hakkında ................................................................................................................................................. 15
2
Bulut üzerindeki verilerin analiz edilmesi ve yönetilmesi en az başka yerlerdeki veriler kadar önemlidir. Microsoft
Azure bu konuda size yardımcı olmak amacıyla ilişkisel ve ilişkisel olmayan veri tabanlarıyla çalışırken
kullanılabilecek teknolojiler sağlamaktadır. Bu incelemede bazı önemli seçenekler tanıtılmaktadır.
Blobs
“Blob” sözcüğü “ikili büyük nesne” (Binary Large OBject) ifadesinin kısaltılmış halidir ve tam olarak bir parçanın ne
olduğunu ifade eder: ikili bilgi koleksiyonu. Bloblar sade olmakla birlikte oldukça faydalıdır. Şekil 1'de bu bulut
platformu tarafından sağlanan temel depolama servisi olan Azure Blobs'un temelleri gösterilmektedir.
Şekil 1: Azure Blobs kapsayıcılarda ikili verileri—blobları—depolar.
Blobların kullanılabilmesi için öncelikle bir depolama hesabı oluşturulmalıdır. Bu kapsamda, bu hesap yardımıyla
oluşturulan öğelerin saklanacağı Azure veri merkezi belirlenir. Daha sonra depolama hesabında bir ya da daha
fazla kapsayıcı, bu kapsayıcılar içinde ise bloblar oluşturulur.
Azure iki farklı türde blob sağlamaktadır. Seçenekler şunlardır:
Her biri 200 gigabyte'a kadar veri barındırabilen blok bloblar. İsminden de anlaşılabileceği üzere blok blob,
belirli sayıda alt bölüme ayrılmıştır. Blok blob aktarılırken bir arıza olduğunda yeniden iletim, bütün blobu
tekrar göndermek yerine en son bloktan devam edebilir.
Her biri bir terabayt büyüklüğünde olabilen sayfa blobları. Sayfa blobları rastgele erişim için tasarlanmıştır,
yani her biri belirli sayıda sayfaya bölünmüştür. Blobda tekil sayfaları rastgele olarak okuyabilen ve
yazabilen ücretsiz bir uygulama. Örneğin Azure’unAzure Virtual Machinesadlı servis olarak altyapı (IaaS)
teknolojisinde sanal makineler için kalıcı depolama olarak sayfa blobları kullanılır.
Blok bloblar veya sayfa bloblarından hangisini seçerseniz seçin uygulamalar, blob verilerine doğrudan RESTful
arabirimi aracılığıyla veya Azure Storage Client kitaplığını kullanarak erişim sağlayabilir ve bu, ham RESTful
servisleri için daha geliştirici dostu bir sarmalayıcı sağlar. Bloblar aynı zamanda başka teknolojilerde sahne
arkasında kullanılmaktadır. Bunun örneklerinden biri, verilerin nasıl kullanıldığına göre yerel disk ile Azure Blobs
arasında veri aktarımı yapan bir saha uygulaması olan Microsoft StorSimple'dır. Bloblar, aşağıda anlatılan şekilde
başka Azure veri teknolojilerinde de kullanılmaktadır.
3
Donanım arızalarına karşı önlem alınması ve kullanılabilirliğin iyileştirilmesi amacıyla her blob, Azure veri
merkezindeki üç fiziksel sunucuda çoğaltılmaktadır. Bir bloba yazıldığında dönüş öncesinde üç kopyanın tamamı
güncellenir, böylece daha sonraki okumalarda tutarsız sonuçlar söz konusu olmaz. Daha net ifade etmek gerekirse
bloblar, güçlü tutarlılık olarak bilinen niteliği sağlar. Ayrıca blobdaki verilerin aynı coğrafi bölgede ancak en az 500
mil mesafede bulunan bir Azure veri merkezine kopyalanmasını sağlayabilirsiniz. Coğrafi çoğaltma olarak ifade
edilen bu kopyalama blob güncellendikten sonra birkaç dakika içinde gerçekleşir ve felaket kurtarma anlamında
oldukça faydalıdır. Bloblardaki verilere Azure Content Delivery Network (CDN)aracılığıyla da erişim sağlanabilir.
Blob verilerinin kopyalarının dünyanın dört bir yanındaki düzinelerce sunucu yardımıyla önbelleğe alınmasıyla
CDN, tekrarlı olarak erişim sağlanan verilere erişimi hızlandırabilir.
Bloblar basit olmalarının yanı sıra birçok durumda doğru tercihtir. Video ve ses depolama ve akışının yanı sıra
yedeklemeler ve diğer veri arşivleri de bariz örnekler arasındadır. Geliştiriciler yapılandırılmamış verilerin
saklanması için de bloblardan faydalanabilir. İkili verilere basit ve düşük maliyetli bir erişim imkanının son derece
faydalı olduğu anlaşılmıştır.
Sanal Makinede DBMS Çalıştırma
Günümüzde birçok uygulama, belirli bir veritabanı yönetimi sistemi (DBMS) ile çalışmaktadır. SQL Server gibi
ilişkisel sistemler en sık kullanılan seçenektir ancak topluca NoSQL grubunda değerlendirilen ilişkisel olmayan
yaklaşımların popülerliği her geçen gün artmaktadır. Bulut uygulamalarının veri yönetimi seçeneklerinin
kullanmasını mümkün kılmak amacıyla Azure, IaaS SM'de DBMS (ilişkisel veya NoSQL) çalıştırabilmenizi
sağlamaktadır. Şekil 2'de bunun SQL Server ile nasıl göründüğü gösterilmiştir.
Şekil 2: Azure Sanal Makineleri bloblar tarafından sağlanan kesintisizlikle SM'de DBMS çalıştırılabilmesini
sağlar.
Bu senaryo hem geliştiriciler hem de veritabanı yöneticileri için, aynı yazılımı kendi veri merkezlerinde çalıştırmak
gibidir. Burada gösterilen örnekte SQL Server özelliklerinin neredeyse tamamı kullanılabilir ve sisteme tam
yönetici erişimi sağlanmaktadır. Aynı zamanda yerel olarak çalıştırıldığında olduğu gibi veritabanı yöneticisinin
yönetilmesi sorumluluğu da sizin üzerinizdedir.
Şekilde gösterildiği gibi veritabanınız, sunucunun üzerinde çalıştığı SM'nin yerel diskinde depolanmış gibi
görünmektedir. Ancak esasen bu disklerin her biri bir Azure blobuna yazılmıştır. (LUN şeklinde işlev gören blob ile
kendi veri merkezinizde SAN kullanmak gibidir.) Herhangi bir Azure blobunda olduğu üzere içerdiği veriler veri
merkezi içinde üç kez çoğaltılır ve tercih etmeniz halinde aynı bölgedeki bir başka veri merkezinde coğrafi olarak
çoğaltılır. Daha fazla güvenilirlik için SQL Server veritabanı yansıtması gibi seçenekler de kullanılabilir .
4
SM'de DBMS çalıştırma ile ilgili yaygın ve oldukça makul bir senaryo kuruluşun bir saha uygulamasını Azure'a
taşımasıdır. Farklı bir veri teknolojisine geçmektense halihazırda çalışmakta olanı kullanmak daha kolaydır. Ancak
Azure üzerinde oluşturulan yeni uygulamalar için aşağıda anlatılan veri teknolojilerinden birinin kullanılması daha
iyi bir çözüm olacaktır.
SQL Database
SM'de DBMS çalıştırmak bulut üzerinde veri yönetmek söz konusu olduğunda birçok kişinin aklına gelen ilk
seçenektir. Ancak bu tek seçenek olmadığı gibi her zaman en doğru yaklaşım da değildir. Bazı durumlarda Servis
olarak Platform (PaaS) teknolojisi kullanılarak veri yönetimi yapmak daha makul bir seçenektir. PaaS çözümü sizin
için Azure tarafından yönetilir ve tipik olarak ayarlanması daha hızlı, idaresi daha az zahmetli ve yönetimi daha
uygun maliyetlidir.
Azure‘un ilişkisel veriler için yönetilen servisi SQL Database'dir. Şekil 3'te bu fikir gösterilmektedir.
Şekil 3: SQL Database ilişkisel veriler için yönetilen servis sağlar.
SQL Database müşterilere kendi SQL Server fiziksel örneklerini vermez. Bunun yerine her bir müşteri,
veritabanları ve ilişkisel tablolar oluşturabileceği bir mantıksal SQL Database sunucusu alır. Bloblarda olduğu gibi
SQL Database'de de tüm veriler Azure veri merkezindeki üç farklı fiziksel sunucuda çoğaltılır ve veritabanları için
dahili olarak yüksek kullanılabilirlik sağlanır.
Bir uygulama için SQL Database, SQL Server'a oldukça benzerdir. Uygulamalar ilişkisel tablolara göre SQL sorguları
yayınlayabilir, T-SQL'de saklanan prosedürleri kullanabilir ve veritabanındaki birden fazla tabloda işlem yürütebilir.
Uygulamalar SQL Database'e erişim SQL Server'ında kullanılan yaklaşım ile aynı şekilde Tabular Data Stream (TDS)
protokolünü kullanarak erişim sağladığından Entity Framework, ADO.NET, JDBC ve diğer sık kullanılan veri erişim
arabirimleri ile veri üzerinde çalışabilirler.
Ancak SQL Database Azure veri merkezlerinde çalışan bir bulut servisi olduğundan disk kullanımı gibi sistemin
fiziksel unsurlarını yönetmeniz gerekli değildir. Ayrıca yazılımı güncelleme veya diğer alt düzey yönetim görevleri
gibi konularla ilgilenmenize de gerek yoktur. Her müşteri organizasyonu tabi ki şemalar ve oturum açmalar da
dahil olmak üzere kendi veritabanını yönetmeye devam eder ancak gündelik yönetim görevlerinin birçoğu sizin
için halledilir.
5
SQL Database kullanmak başka bir şekilde kendi SQL Server örneğinizi çalıştırmaktan farklıdır. SQL Database
paylaşımlı bir servis olduğundan farklı organizasyonlara ait çok sayıda uygulama tarafından eşzamanlı olarak
kullanılmaktadır. Başka uygulamaların nasıl kullanacağını öngöremeden servisten ihtiyaç duyduğunuz performansı
alacağınızdan nasıl emin olabilirsiniz? Yanıt, SQL Database kullanıcılarının her biri belirli miktarda iş üreten belirli
sayıda veritabanı iş üretme ünitesi (DTU) için ödeme yapıyor olmasıdır. Uygulamanızın ihtiyaç duyduğu DTU'ları
satın alarak bu paylaşımlı servisten öngörülebilir bir performansı garanti edebilirsiniz.
Farklı uygulamalar için farklı iş performansları gereklidir ve bu nedenle SQL Database, her birinde farklı sayıda DTU
bulunan üç farklı seviyede servis sağlar:
İşlem iş yükü göreceli olarak düşük uygulamalar için Basic.
Ana akım iş uygulamalarını destekleyecek şekilde tasarlanmış Standard.
Geniş ölçekli ve kritik veritabanlarını destekleyen Premium.
SQL Database aşağıdakiler de dahil başka servisler de sağlar:
Veritabanınızın gerçekleştirilmiş olan işlemlerin asenkron olarak aktarılmış olduğu kopyalarını başka Azure
veritabanlarında tutmanızı mümkün kılan coğrafi çoğaltma. Yalnızca ana kopya okunur/yazılır olmakla birlikte
aktif coğrafi çoğaltma adlı bir seçenekle diğerlerini de okunabilir hale getirebilirsiniz. Bu, başka işlevlerinin
yanı sıra, ana kopyanın bulunduğu veri merkezinde bir sorun olması halinde verilerin doğru bir kopyasına bir
başka kopyadan ulaşılabilir olması anlamında, felaket kurtarma durumunda oldukça faydalıdır.
Veritabanlarının kopyalarını otomatik olarak oluşturan SQL Database ile yedekleme ve geri yükleme. Bu
yedekleri, bir veritabanını belirli bir zamandaki durumuna geri döndürmek için kullanabilirsiniz. Servis aynı
zamanda farklı bir Azure veri merkezinde yedekler saklamanızı mümkün kılar ve ana veri merkezi çalışamaz
hale gelse dahi ulaşılabilir olmalarını sağlar.
Veritabanı okuma, yazma ve diğer tür erişimleri takip eden denetim. Bu tür bir denetim izi belirli uyumluluk
gereksinimlerinin karşılanması için gerekli olabilir ve başka şekillerde de faydalıdır. Örneğin uygulamaların
verilerinizi nasıl kullandığına dair ayrıntılı bir görünüm, güvenlik ihlallerini algılamanıza ve veritabanının ne
zaman ve nerede çoğaltılması gerektiğini anlamanıza yardımcı olabilir.
SQL Database ile SQL Database veya SQL Server'daki başka bir veritabanı arasında veri senkronizasyonu
yapabilmenizi mümkün kılan SQL Data Sync. Verilerin SQL Database'de saklandığı şekilde birden fazla Azure
veri merkezinde bir uygulama çalıştırdığınızı ve tüm kopyaların okunur/yazılır olmasına ihtiyaç duyduğunuzu
varsayalım. SQL Data Sync'i kullanarak bu verileri senkronize halde tutabilirsiniz (bu senkronizasyon tüm
kopyalarda tam olarak anlık değildir, bir miktar gecikme söz konusudur). SQL Data Sync'i kullanarak ayrıca
saha uygulamaları tarafından kullanılan yerel bir SQL Server veritabanı ile Azure üzerinde çalışan uygulamalar
tarafından kullanılan SQL Database üzerindeki bulut kopya arasında veri senkronizasyonu sağlayabilirsiniz.
Amaç, çeşitli gereksinimleri bulunan bir dizi senaryoyu desteklemektir. SQL Database’in PaaS yaklaşımı, veri
yönetimini daha kolay ve daha uygun maliyetli hale getirdiğinden, birçok durumda doğru tercih olabilir.
6
DocumentDB
İlişkisel veri kesinlikle faydalıdır ancak tek seçenek değildir. NoSQL çözümleri giderek daha popüler hale
gelmektedir. Bunun nedenlerinden biri ilişkisel veritabanlarının ölçeklendirilmesinin zorluğudur, yani çok sayıda
kullanıcı ve verinin yönetileceği bir uygulama oluşturuyorsanız başka bir yere bakmanız gerekebilir. Geliştiriciler
NoSQL veritabanlarını aynı zamanda uygulama verilerinin ilişkisel tablolarla eşlenmesinin sorun olmaması
nedeniyle tercih etmektedir; daha sade bir platformdan veya sabit bir şemanın kısıtlamalarından kaçınmak
istemektedirler ya da başka nedenler söz konusudur.
Belge veritabanları başlıca NoSQL kategorileri arasındadır ve bütün bunları sağlayabilir. İlişkisel DBMS'de olduğu
gibi Azure SM'ler ile kendi başınıza belge veritabanı çalıştırabilirsiniz; günümüzde birçok kişi MongoDB veya başka
seçeneklerle bunu yapmaktadır. Bu yaklaşımın kullanılmasını kolaylaştırmak amacıyla Azure, bir PaaS belge
veritabanı servisi olan DocumentDB'yi sağlamaktadır. Şekil 4'te bu yönetilen servisin temel öğeleri gösterilmiştir.
Şekil 4: DocumentDB koleksiyonlarda JSON belgelerini depolayan bir yönetilen servis sağlar.
DocumentDB'de uygulama verilerinin tamamı koleksiyonlar halinde gruplandırılmış belgeler içinde saklanır. Her
belgede basit bir metin tabanlı format olan JavaScript Object Notation'da (JSON) anlatılan veriler yer alır. Şekilde
gösterildiği üzere bir koleksiyonda benzer veriler veya tamamen farklı veriler içeren belgeler bulunabilir; sabit bir
şema söz konusu değildir. DocumentDB aynı SQL Database gibi yönetilen bir servis olduğundan DBMS altyapısı
kurma ya da yönetme ihtiyacı söz konusu değildir.
Bu verilerle çalışmak için uygulamaların tamamı sonuç olarak JSON veren birkaç seçeneği bulunmaktadır.
Seçenekler şunlardır:
Uygulamalar DocumentDB’nin RESTful arabirimini doğrudan veya .NET, JavaScript, Python ve diğer ortamlar
için sağlanan istemci kitaplıkları üzerinden kullanabilir.
Servis DocumentDB SQL adlı bir sorgu dili sağlar. Adından da anlaşılacağı üzere bu dilin söz dizimi, günümüzün
en yaygın kullanılan sorgu dili olan SQL'i temel almaktadır.
7
DocumentDB, her ikisi de JavaScript'te yazılmış ve servisin içinde çalışan kayıtlı prosedürleri ve tetikleyicileri
destekler.
Document DB verilere hızlı erişim sağlayacak şekilde tasarlanmıştır. Bunun yöntemlerinden biri her JSON
belgesindeki tüm verilerin otomatik olarak dizinlenmesidir. Örneğin Şekil 4'te gösterilen belgelerde sistem, her bir
belgedeki ad, ülke, yaş, görev, seviye ve diğer JSON öğeleri için otomatik olarak dizinler oluşturur. Geliştiricilerin
hangi verilere hızlı erişim sağlamak istediklerine ve dolayısıyla hangi dizinlerin oluşturulacağına önceden karar
vermeleri yerine DocumentDB, her şeyi dizinler.
Tek bir veritabanında çeşitli farklı sunuculara dağılmış birçok koleksiyon bulunabilir. Sonuç olarak her
DocumentDB veritabanında yüzlerce terabayt veri bulunabilir. Ancak verilerin bu şekilde bölünmesi çeşitli
kısıtlamalar getirir. Birden fazla güncellemenin tek bir işleme paketlenmesi mümkün olmakla birlikte bu
güncellemelerin tamamının aynı koleksiyondaki belgeler olması gerekmekte, bir işlem birden fazla koleksiyona
bakamamaktadır. Aynı zamanda bir uygulama tarafından yapılan her istek belirli bir koleksiyonu hedeflemelidir,
yani bir uygulamanın aradığı verilerin nerede saklandığını bilmesi gerekir.
Diğer Azure veri servisleri gibi DocumentDB, farklı makinelerde her koleksiyonun birden fazla kopyasını tutar. Bu,
servisin hem performansını hem de güvenilirliğini artırır. Ancak DocumentDB güçlü bir tutarlılığı zorunlu kılmaz.
Güçlü bir tutarlılık, uygulamaların eski verileri veya güncellemeleri görmemesini sağlamakla birlikte işleri de
yavaşlatabilir. Yine de bazı uygulamalarda daha yüksek performans sağlanacak olması halinde eski verilerin
görülmesi kabul edilebilir, yani DocumentDB güçlü bir tutarlılık sağlamamakla birlikte başka seçenekler
sunmaktadır. Amaç geliştiricilerin performans ile tutarlılık arasında uygulamaları için en uygun tercihi
yapmalarıdır.
Belge veritabanları hızla popülerlik kazanmaktadır. Geliştiriciler basit veri modelinden, gerekli bir şemanın söz
konusu olmamasından, ölçeklenebilirlikten ve çok daha fazlasından hoşlanırlar. DocumentDB'nin amacı bu
faydaları yönetilen servisin sadeliği ile birleştirirken SQL tabanlı bir sorgu dili ve kayıtlı prosedürler gibi standart
veritabanı özelliklerini de sağlamaktır1.
Tables
NoSQL veritabanları çeşitli şekillerde gelir. Günümüzde popüler olan bir yaklaşım anahtar/değer mağazası
yaklaşımıdır. Uygulamanızın geniş miktarda gevşek yapılandırılmış veriye hızlı ve kolay erişimi gerekliyse bu
NoSQL tarzı en iyi seçeneğiniz olabilir.
Azure Tables bir PaaS anahtar/değer mağazası sağlar. Diğer bir ifadeyle bu NoSQL tarzını yönetilen servis olarak
sunar. Ancak kafanız karışmasın: adına rağmen Tables standart ilişkisel tabloları desteklemez. Bunun yerine bir
grup veriyi belirli bir anahtarla ilişkilendirir ve bir anahtar ile uygulamanın bu verilere ulaşabilmesini sağlar. Şekil
5'te bu fikir gösterilmektedir.
1Bu konuda daha fazla bilgi almak için bkz.DocumentDB'ye Giriş: Microsoft Azure için NoSQL Veritabanı.
8
Şekil 5: Azure Tables, büyük miktarda veriye hızlı ve kolay erişim sağlayan bir yönetilen servistir.
Şekilde gösterildiği gibi her tablo, her birinde ayrı bir makinenin saklanabildiği belirli sayıda bölüme ayrılmıştır.
Her bölüm birden fazla makinede çoğaltılır ve Tables, okuma ve yazma için güçlü tutarlılık sağlar. Azure Blobs gibi
uygulamalar bir tabloya RESTful arabirimi aracılığıyla doğrudan veya Azure Storage Client kitaplığı tarafından
sağlanan paketleyiciler ile erişim sağlayabilir.
Tablodaki her bölüm, her birinin belirli sayıda özelliği bulunan bir grup varlığı saklar. Her özelliğin bir adı, tipi
(Binary, Bool, DateTime, Int veya String gibi) ve değeri bulunur. Bu tabloların sabit bir şeması yoktur ve aynı
tablodaki farklı varlıkların farklı tiplerde farklı özellikleri bulunabilir. Örneğin bir varlıkta yalnızca ad içeren bir
String özelliği bulunurken aynı tablodaki bir başka varlıkta müşteri kod numarası ve kredi değeri içeren iki Int
özelliği bulunabilir.
Bir tablodaki belirli bir varlığın belirlenebilmesi için bir uygulama, varlık anahtarını sağlar. Anahtarın iki kısmı vardır:
belirli bir bölümü tanımlayan bölüm anahtarı ve bu bölümdeki bir varlığı tanımlayan satır anahtarı. Örneğin Şekil
5'te istemci, bölüm anahtarı B ve satır anahtarı 1 varlığını istemektedir. Azure Tables içerdiği tüm parametrelerle
birlikte bu varlığı verir.
Bu yapı çok büyük tablolara izin verir ve içerdikleri verilere hızlı erişimi mümkün kılar. Ancak bunun sınırlamaları da
vardır. Örneğin tabloları veya tek bir tablodaki bölümleri kapsayan işlem güncellemeleri için destek söz konusu
değildir. Tabloya yapılacak bir dizi güncelleme, tüm varlıkların aynı bölümde bulunması halinde yalnızca atomik bir
işlemde gruplanabilir. Ayrıca ikincil dizinler oluşturulamaz (yani anahtar dışındaki özellikler dizinleri) ve birden fazla
tablo içeren birleştirmeler desteklenmez. Standart ilişkisel veritabanlarının aksine Azure Tables, saklı yordamları
veya tetikleyicileri desteklemez.
9
Azure Tables çok sayıda gevşek yapılandırılmış veriye hızlı ve uygun maliyetli erişime ihtiyaç duyan uygulamalar
için iyi bir seçenektir. Örneğin çok sayıda kullanıcı için profil bilgilerini saklayan bir internet uygulaması Tables'dan
faydalanabilir. Bu durumda hızlı erişim önemlidir ve uygulamanın muhtemelen ilişkisel veritabanının tam gücüne
ihtiyacı yoktur. Hız ve büyüklük için bu işlevsellikten vazgeçilmesi faydalı olabilir ve Tables, bu tür durumlar için en
doğru çözüm olabilir.
HDInsight
Son birkaç yılda veri analizleri ile ilgili düşüncelerimiz önemli ölçüde değişmiştir. Şu anda çok miktarda veri
kullanılabilmektedir ve depolamanın giderek düşen maliyeti dikkate alındığında bunlar niçin kaydedilmesin? Peki
bu verileri standart veri ambarlarının kullandığı ilişkisel formata dönüştürmekle niçin uğraşılsın? Bunun yerine
veriler niçin yapılandırılmamış biçiminde bırakılmasın ve bununla akıllı olarak çalışabilen uygulamalar
oluşturulmasın?
Bu verilerin saklanması ve analiz etmek için gereken uygulamaların oluşturulması için yeni bir tür yazılım temeli
gereklidir. Sektörümüzde bunun için belirli bir yaklaşım geniş ölçüde oturmuştur: Hadoop adlı bir açık kaynak
teknolojisi. Tek bir adı olmakla birlikte Hadoop, esasen sunucu kümesi üzerinde çalışacak şekilde tasarlanmış bir
teknoloji grubunun adıdır. Şekil 6'da temel hususlar gösterilmektedir.
Şekil 6: Hadoop, sunucu kümeleri üzerinde çalışan bir grup teknolojidir.
Çok miktarda veriyi uygun maliyetle saklamak için Hadoop, Hadoop Distributed File System'a (HDFS) sahiptir.
HDFS düşük maliyetli standart disklerle yüksek boyutlu dosyaların saklanmasını mümkün kılar. Bunun yanı sıra
Hadoop, Yet Another Resource Negotiator'a (YARN)sahiptir. YARN küme yönetimi yazılımıdır ve küme üzerinde
çeşitli başka teknolojiler içerir. Örneğin bir Hadoop kümesinde büyük verilerin analiz edilmesi için dağıtık
uygulamalar oluşturulmasını destekleyen MapReduce kullanımı yaygındır. Şekilde gösterildiği üzere Hadoop
ailesinde doğrudan HDPS üzerinde çalışan bir NoSQL veritabanı olan HBase öğesi de yer alır.
Azure HDInsight bütün bu teknolojileri destekleyen bir yönetilen servistir. Bu bölümün geri kalanında HDInsight'ın
en görülür iki unsuruna daha yakından bakılmaktadır: MapReduce ve HBase.
Hadoop MapReduce
Organizasyonlar yıllardır veri ambarları inşa etmektedir. Genellikle ilişkisel tablolarda saklanan bu bilgi
koleksiyonları ile insanlar birçok farklı şekilde çalışabilir ve öğrenebilir. Örneğin SQL Server ile bunun için SQL
Server Analysis Services gibi araçlar kullanmak oldukça yaygındır.
10
Ancak ilişkisel olmayan verileri analiz etmek istediğinizi düşünelim. Verileriniz birçok şekilde olabilir:
algılayıcılardan veya RFID etiketlerinden gelen bilgiler, sunucu gruplarındaki günlük dosyaları, web uygulamaları
tarafından oluşturulan tıklatma dizisi verileri, tıbbi tanılama cihazlarından görüntüler, vs. İlişkisel olmamasının yanı
sıra bu veriler, klasik veri ambarında kullanım için fazla büyük olabilir. Birkaç yıl öncesine kadar sık rastlanmayan
bunun gibi büyük veri sorunları artık oldukça yaygındır ve Hadoop MapReduce tam olarak bunun için
tasarlanmıştır.
MapReduce dağıtık uygulamaların bir makine kümesinde çalıştırılmasına yönelik bir çerçeve sağlar. Genel
anlamda uygulamanın her bir parçası, parçanın üzerinde çalıştığı makinedeki verilerle çalışır. Veriler paralel olarak
işlendiğinden büyük veri kümeleri dahi makul bir sürede analiz edilebilir. MapReduce uygulaması ne kadar çok
makine kullanırsa, yaptığı işi o kadar hızlı tamamlayabilir.
Bu tür bir sorun genel bulut için doğal bir sonuçtur. Zamanın büyük bir kısmında boş oturacak saha
sunucularından oluşan bir ordu beslemektense bulut üzerinde Hadoop çalıştırarak yalnızca ihtiyacınız olduğunda
SM'ler oluşturabilir ve yalnızca gerektiğinde ödeme yapabilirsiniz. Daha da önemlisi bulut üzerinde Hadoop
MapReduce ile analiz etmek isteyeceğiniz veriler giderek daha fazla oluşturulmakta ve taşınması sorunu ortadan
kalkmaktadır. Şekil 7'de Azure üzerinde HDInsight MapReduce gösterilmektedir.
Şekil 7: Azure HDInsight, birden fazla sanal makine kullanarak paralel şekilde veri işleyen MapReduce işlerini
çalıştırır.
HDInsight kullanmak için öncelikle bu yönetilen servisten, ihtiyaç duyulan SM sayısı belirlenerek bir Hadoop
kümesi oluşturması istenir. Bir Hadoop kümesi oluşturmak kolay bir işlem değildir ve bunu Azure'un yapmasına
izin vermek oldukça makuldür.
Küme çalışmaya başladıktan sonra genellikle iş adı verilen MapReduce uygulamasını gönderebilirsiniz. Şekilde
gösterildiği gibi iş, çok sayıda SM'de eşzamanlı olarak çalışır.
Ancak HDInsight, HDFS yerine Azure Blobs'u kullanır. Bloblar bazı açılardan HDFS'ye benzer, örneğin her ikisi de
birden fazla fiziksel sunucuda veri çoğaltır. Bu işlevselliği kopyalamak yerine HDInsight, bunun yerine şekilde
gösterildiği üzere Blobları HDFS API aracılığıyla açar. MapReduce işinin mantığı standart HDFS dosyalarına erişim
11
sağladığını düşünmekle birlikte iş aslında bloblarda depolanan verilerle çalışmaktadır. Birden fazla işin aynı veriler
üzerinde çalıştığı durumların desteklenmesi amacıyla HDInsight, verilerin bloblardan SM'lerde çalışan HDFS'ye
kopyalanmasını destekler.
MapReduce işleri günümüzde genellikle Java'da yazılmakta ve bu yaklaşım HDInsight tarafından
desteklenmektedir. Microsoft, MapReduce işlerinin C#, F# ve JavaScript de dahil başka dillerde de
oluşturulabilmesi için gereken desteği eklemiştir. Amaç bu büyük veri teknolojisini daha çok geliştirici için
ulaşılabilir kılmaktır.
Yine de MapReduce işlerinin yazılması çok kolay değildir, oldukça özel bir beceri gerektirir. Bunu kolaylaştırmak
adına insanlar genellikle, kendileri MapReduce işleri yazmadan verileri analiz etmelerini mümkün kılan başka
teknolojiler kullanmaktadır. Örneğin Pig büyük verileri analiz etmek için tasarlanmış üst düzey bir dilken Hive,
HiveQL adlı SQL benzeri bir dil sağlar. Pig ve Hive esasen MapReduce işleri oluşturabilir, ancak bu karmaşıklığı
kullanıcılarından saklarlar.
HDInsight'ta hem Pig hem de Hive bulunmaktadır. Microsoft aynı zamanda iş analistlerinin MapReduce işlerini
doğrudan Excel üzerinden oluşturmalarını ve çalıştırmalarını, ardından PowerPivot ve diğer Excel araçlarını
kullanarak sonuçları işlemelerini ve görselleştirmelerini mümkün kılan bir Excel eklentisi sağlamaktadır. Buradaki
amaç bu dağıtık veri analizi programının geniş bir yelpazede kullanıcılar tarafından kullanımını mümkün
kılmaktır.
Hadoop HBase
MapReduce'un Hadoop ailesinin en göz önündeki üyesi olduğu söylenebilir. İnsanlar “Hadoop” derken genellikle
yalnızca yapılandırılmamış verilerin paralel analizine yönelik bir platform olarak işlevini kastetmektedirler. Ancak
Hadoop bundan fazlasını sunar. Örneğin HBase'e sahiptir.
HBase bir NoSQL veritabanıdır. HDFS üzerinde çalışmakla birlikte veri okuma ve yazma uygulamalarını
desteklemeye yöneliktir, veri analizi odaklı değildir. HBase'i bunun yerine kendi veri organizasyonu yöntemlerine
sahip bir DocumentDB veya Tables alternatifi olarak düşünün. Şekil 8 HBase'in bunu nasıl yaptığını
göstermektedir.
Şekil 8: Azure HBase, birçok satıra ve sütuna sahip geniş ve seyrek tabloları destekler.
12
HBase, sütun ailesi mağazası adı verilen NoSQL tarzının örneğidir. Şekilde gösterildiği üzere verileri satırlar ve
sütunlarla birlikte tablolarda saklar. Sütunların aileler şeklinde gruplandırılmış olması sayesinde uygulama; sütun
ailesi, sütun tanımlayıcı ve satır anahtarının belirli bir kombinasyonunu kullanarak verilere erişebilir. Bu örnekte
uygulama, sütun ailesi F1, sütun C2, satır 3'teki verileri istemektedir. Burada gösterilmemekle birlikte HBase
tablosundaki bir hücre, verilerin çoklu zaman etiketli versiyonlarını içererek uygulamanın hangi sürümü istediğini
belirlemesini mümkün kılabilir.
HBase şekilde gösterildiği üzere tabloyu bölgelere ayırır ve farklı bölgeler farklı sunucularda saklanır. DocumentDB
ve Azure Tables'da olduğu gibi verilerin bu şekilde çeşitli makinelere dağıtılması sistemi daha ölçeklendirilebilir hale
getirir. Esasen tek bir HBase tablosunda milyonlarca sütun, milyarlarca satır ve yüzlerce terabayt veri bulunabilir.
Ancak bir HBase tablsunun oldukça seyrek olması da yaygındır; sistemin fiziksel depolama alanı bu verimliliği
sağlayacak şekilde tasarlanmıştır. Her bir bölgenin birden fazla çoğaltması, Azure veri merkezindeki farklı
makinelerde saklanır ve kullanılabilirlik ve performans artar. Azure Tables gibi HBase de güçlü tutarlılık sağlar ve
böylece uygulama, tablonun zamanı geçmiş veya devre dışı güncellemelerini görmez.
NoSQL teknolojilerinde standart olduğu üzere HDInsight HBase'de ilişkisel veritabanlarında standart olan bazı
şeyler yoktur. Örneğin sorgu dili veya satır anahtarı dışında dizin oluşturma olanağı bulunmamaktadır. İşlemler
yapılabilir ancak sınırlıdır: bir işlemdeki tüm verilerin aynı tablodaki tek bir satırda bulunması gerekir. HBase'de
veri türü kavramı yoktur; her şeyi bayt dizisi olarak saklar.
Azure üzerinde HBase ile çalışmak için HDInsight kullanarak bir Hadoop kümesi oluşturabilir ve HBase'in bu
kümeye uygulanmasını isteyebilirsiniz. MapReduce'da olduğu gibi HDInsight HBase de verileri HDFS değil Azure
bloblarında saklar. Çok büyük tablolarla çalışması gereken uygulamalar için HDInsight HBase doğru çözüm
olabilir.
Search
Arama işlevini İnternet'te herkes kullanmaktadır. Veri ile bu şekilde etkileşim hem kolay hem de güçlüdür: az
çaba ile çok iş yapılabilir. Ancak sahne arkasında olan biten birçok şey vardır. Aramayı uygulamak kolay değildir.
Ne kadar çok insanın arama yaptığı düşünüldüğünde özel uygulamaların da verilerle bu tür çalışmayı
desteklemesi mükemmel olacaktır. Her geliştiricinin kendi arama motorunu uygulamaya almasını beklemek
makul değildir; bu, çok fazla iş demektir. Gereken birçok farklı uygulamayla kullanılabilecek genel bir arama
servisi geliştirmektir. Azure Search tam olarak bunu sağlar.
Bir çevrimiçi mağaza oluşturduğunuzu varsayalım. Müşterileriniz tabi ki sitede ilgilendikleri şeylerin aranabilmesini
bekleyecektir. Google ve Bing gibi internet arama motorları konusundaki deneyimleri nedeniyle sitenizin arama
alt yapısından arama öğeleri ile ilgili yazılırken tavsiyede bulunulması gibi işlevler bekleyeceklerdir. Yönetilen bir
servis olan Azure Search'ü kullanarak bütün bunları sağlayabilirsiniz. Şekil 9'da temel hususlar gösterilmektedir.
13
Şekil 9: Azure Search ile kullanıcılar için standart bir arama deneyimi sağlayan uygulamalar
oluşturulabilir.
Azure Search, uygulamanın kullanıcı tarafından yapılan isteği gönderebilmesini mümkün kılan bir arama motoru
sağlar. Arama motoru bu istek ile eşleşen ilgili tüm verileri bulmak için bir dizin sağlar ve sonuç listesini JSON
metni şeklinde uygulamaya geri gönderir. Kullanıcı arabiriminin tamamen uygulamanız tarafından tanımlandığına
dikkat edin; Azure Search'ün kendi arama arabirimi yoktur. Bunun yerine RESTful arabirimini diğer yazılımların
kullanımına açar.
Peki uygulamanızın kendi arama işlevine niçin ihtiyacı vardır? Bing ve Google ile uygulamanız yalnızca kapsamı site
ile belirlenmiş aramalar yapabilir. Yalnızca bunu kullanmak daha kolay olmaz mıydı? Yanıt evet, daha kolay olurdu.
Ancak bu yöntemde birçok şeyden de vazgeçilmiş olur. Örneğin müşterilerin hangi aramaları yaptığını göremez
veya sizde bulunmayan neleri aradıklarını fark edemezsiniz. Daha da önemlisi harici bir arama servisi
kullanıldığında arama sonuçlarının sıralamasını kontrol edemezsiniz. Örneğin en yüksek kar marjını sağlayan
öğelerin daha önce gösterilmesini veya deponuzda mevcut olan ürünlere göre sıralama yapılmasını istiyor
olabilirsiniz.
Azure Search bütün bu seçenekleri destekleyecek şekilde tasarlanmıştır. Her dizinde aranabilir verileri içeren
belirli sayıda alan yer alır. Örneğin çevrimiçi alışveriş amaçlı bir sitenin dizini ürün adı, ürün tipi, ürün tanımı ve
markanın yanı sıra müşterilerin muhtemelen arama yapmak isteyeceği başka alanları içerecektir. Aynı zamanda
kar marjı gibi müşterinin arama yapamayacağı başka alanlar da yer alabilir. Search ile bunların arama sonuçlarını
nasıl etkileyeceğini belirleyebilirsiniz.
En bariz örnekler e-ticaret siteleri olmakla birlikte Azure Search, bundan daha fazlası için fayda sağlamaktadır.
Sinema tartışma siteleri gibi içeriği kullanıcı tarafından oluşturulan ve kullanıcının ilgilendiği şeyleri arama yoluyla
bulduğu bir siteyi düşünün. Bu sitede sonuçları iş gereksinimlerine göre aramak isteyen reklamcılar bulunabilir ve
bu, Azure Search ile mümkündür. Uluslararası bir kurumsal uygulamada da, özellikle en kolay arama yoluyla
ulaşılabilen çok sayıda ve farklı içerikte veriler varsa, Azure Search kullanılabilir. Kullanıcılar bu tarz erişimi tercih
eder ve bir sonraki iş uygulamanızda aramanın desteklenmesi, şirketinizde kişiler tarafından uyarlanmasının daha
kolay olmasına yardımcı olabilir.
Her durumda arama gerekli olmamakla birlikte kullanıcı, uygulamalarla bu şekilde etkileşim kurmayı giderek
daha fazla bekleyecektir. Bunun etkili bir şekilde yapılması için uzman teknoloji gerekir ve Microsoft’un bulut
platformu Azure Search'ü sağlamaktadır.
14
Sonuç
Veri, son derece önemlidir. Esasen şu anda bilgi teknolojisi adı verilen çalışma alanımız eskiden bilgi işlem olarak
anılırdı, ki bu da merkezi verilerin işimiz için ne anlama geldiğini ifade etmektedir. İlişkisel sistemlerin hüküm
sürdüğü onlarca yılın ardından veri dünyası genişlemiştir. NoSQL, büyük veri analitikleri, arama ve başka
kavramların yükselişiyle artık veriler üzerinde yeni yöntemlerle çalışabiliyoruz.
Azure bu nedenle bu kadar geniş bir yelpazede veri yönetimi teknolojileri sağlıyor: Bloblar, SM'de DBMS çalıştırma
desteği, SQL Veritabanı, DocumentDB, Tables, HDInsight (Hadoop ve HBase dahil) ve Search. Hangi uygulamayı
oluşturmaya çalışırsanız çalışın bu bulut platformunda işinize yarayacak bir şey bulabilirsiniz
Yazar Hakkında
David Chappell, San Francisco, California'daki Chappell & Associates'in (http://www.davidchappell.com)
yöneticisidir. Konuşmaları, yazıları ve danışmanlık hizmetleriyle dünyanın dört bir yanından insanların yeni
teknolojileri anlamasına, kullanmasına ve bunlar hakkında daha iyi seçimler yapmasına yardımcı olmaktadır.
15