Büyük veri mimarisi, geleneksel veritabanı sistemleri için çok büyük veya karmaşık olan verilerin alımını, işlenmesini ve analizini yönetecek şekilde tasarlanmıştır. Kuruluşların büyük veri bölgesine girdiği eşik, kullanıcıların ve araçlarının yeteneklerine bağlı olarak farklılık gösterir. Bazı durumlarda bu eşik yüzlerce gigabayt veri anlamına gelirken, bazıları için yüzlerce terabaytı ifade eder. Büyük veri kümeleriyle çalışma araçları ilerledikçe büyük verilerin anlamı da ilerlemektedir. Bu tür durumlarda çok büyük veri boyutları söz konusu olabilse de, yalnızca veri boyutunu aşan bu kavramın, gelişmiş analiz yoluyla veri kümelerinizden elde edebileceğiniz değerle ilişkisi giderek artıyor.
Yıllar içinde veri manzarası değişti. Verilerle yapabilecekleriniz veya yapmanız beklenenler değişti. Depolama maliyeti çarpıcı bir şekilde azaldı, ancak bunun sonucunda verilerin toplanma yöntemi büyüme devam ediyor. Bazı veriler yüksek bir hızda ulaşır ve sürekli olarak toplama ve gözleme gerektirir. Bazı veriler ise daha yavaş ancak daha büyük öbekler halinde ulaşır ve çoğunlukla on yıllık geçmiş verileri biçimindedir. İleri bir analiz sorunuyla veya makine öğrenimi gerektiren bir sorunla karşılaşabilirsiniz. Bunlar, büyük veri mimarilerinin çözmeye çalıştığı sorunlardır.
Büyük veri çözümleri genellikle aşağıdaki iş yükü türlerinden bir veya daha fazlasını içerir:
- Bekleyen büyük veri kaynaklarının toplu işlenmesi.
- Hareket halindeki büyük verilerin gerçek zamanlı işlenmesi.
- Büyük verilerin etkileşimli incelenmesi.
- Tahmine dayalı analiz ve makine öğrenimi.
Aşağıdaki gereksinimlere sahip olduğunuzda büyük veri mimarilerini düşünün:
- Geleneksel bir veritabanı için çok büyük hacme sahip veri depolama ve işleme.
- Yapılandırılmamış verileri analiz ve raporlama için dönüştürme.
- Sınırsız veri akışlarını gerçek zamanlı olarak veya düşük gecikme süresiyle yakalama, işleme ve analiz etme.
Büyük veri mimarisinin bileşenleri
Aşağıdaki diyagramda bir büyük veri mimarisine uygun olan mantıksal bileşenler gösterilmiştir. Her çözüm, bu diyagramdaki her bir öğeyi içermeyebilir.
Büyük veri mimarilerinin çoğu, aşağıdaki bileşenlerin bazılarını veya tümünü içerir:
Veri kaynakları. Tüm büyük veri çözümleri bir veya daha fazla veri kaynağıyla başlar. Örnekler şunları içerir:
- İlişkisel veritabanları gibi uygulama verisi depoları.
- Uygulamalar tarafından üretilen web sunucusu günlük dosyaları gibi statik dosyalar.
- IoT cihazları gibi gerçek zamanlı veri kaynakları.
Veri depolama. Toplu işleme yönelik veriler genellikle çeşitli biçimlerdeki büyük dosyaları yüksek miktarlarda tutabilen bir dağıtılmış dosya deposunda depolanır. Bu tür depolara genelde veri gölü adı verilir. Bu depolamayı uygulamak seçenekleri arasında Azure Depolama'daki blob kapsayıcıları ve Azure Data Lake Store bulunur.
Toplu işleme. Veri kümeleri çok büyük olduğundan büyük veri çözümleri genellikle uzun süre çalışan toplu işler aracılığıyla verileri filtreleyerek, toplayarak ve diğer yollardan analize hazırlayarak veri dosyalarını işlemelidir. Bu işler, çoğu zaman kaynak dosyaların okunması, işlenmesi ve çıktının yeni dosyalara yazılmasını içerir. Seçenekler arasında Azure Data Lake Analytics’te U-SQL işleri çalıştırma, bir HDInsight Hadoop kümesinde Hive, Pig veya özel Map/Reduce işleri kullanma veya bir HDInsight Spark kümesinde Java, Scala veya Python programları kullanma bulunur.
Gerçek zamanlı ileti alımı. Çözüm gerçek zamanlı kaynaklar içeriyorsa mimarinin akış işlemek için gerçek zamanlı iletileri yakalayıp depolayacak bir yol içermesi gerekir. Bu yol, gelen iletilerin işlenmek üzere bir klasöre bırakıldığı basit bir veri deposu olabilir. Ancak, birçok çözüm ileti alım deposunun iletiler için bir arabellek görevi görmesini, ayrıca ölçeği genişletme işlemini, güvenilir teslimi ve diğer iletiyi kuyruğa alma semantiğini desteklemesini gerektirir. Bir akış mimarisinin bu kısmı genellikle akışı arabelleğe alma olarak adlandırılır. Azure Event Hubs, Azure IoT Hub ve Kafka seçenekleri mevcuttur.
Akış işleme. Çözümün, gerçek zamanlı iletileri yakaladıktan sonra filtreleme, toplama ve diğer verileri analize hazırlama işlemleriyle bu iletileri işlemesi gerekir. İşlenen akış verileri daha sonra bir çıkış havuzuna yazılır. Azure Stream Analytics, sınırsız akışlar üzerinde sürekli çalıştırılan SQL sorgularına dayalı yönetilen bir akış işleme hizmeti sağlar. HdInsight kümesinde Spark Streaming gibi apache akış teknolojilerini açık kaynak de kullanabilirsiniz.
Makine öğrenmesi. Analiz için hazırlanan verileri okuma (toplu işlem veya akış işlemeden), sonuçları tahmin eden veya verileri sınıflandırabilen modeller oluşturmak için makine öğrenmesi algoritmaları kullanılabilir. Bu modeller büyük veri kümeleri üzerinde eğitilebilir ve sonuçta elde edilen modeller yeni verileri analiz etmek ve tahminlerde bulunmak için kullanılabilir. Bu, Azure Machine Learning kullanılarak yapılabilir
Analitik veri deposu. Büyük veri çözümlerinin çoğu, verileri analiz için hazırlar ve sonra işlenen verileri analiz araçları kullanılarak sorgulanabilecek yapılandırılmış bir biçimde sunar. Bu sorgulara hizmet veren analitik veri deposu, birçok geleneksel iş zekası (BI) çözümünde görüldüğü gibi Kimball tarzında ilişkisel bir veri ambarı olabilir. Alternatif olarak, veriler HBase gibi düşük gecikme süreli bir NoSQL teknolojisi veya dağıtılmış veri deposundaki veri dosyalarının meta verilerle özetini sağlayan etkileşimli bir Hive veritabanı aracılığıyla sunulabilir. Azure Synapse Analytics büyük ölçekli, bulut tabanlı veri ambarlamaya yönelik yönetilen bir hizmet sağlar. HDInsight; Interactive Hive, HBase ve analiz için verileri sunmak amacıyla da kullanılabilen Spark SQL’i destekler.
Analiz ve raporlama. Büyük veri çözümlerinin çoğunun amacı analiz ve raporlama aracılığıyla veriler hakkında öngörüler sağlamaktır. Mimari, kullanıcılara veri analizi desteği sağlamak amacıyla Azure Analysis Services’te çok boyutlu OLAP küpü veya tablo verisi modeli gibi bir veri modelleme katmanı içerebilir. Ayrıca, Microsoft Power BI veya Microsoft Excel'deki modelleme ve görselleştirme teknolojilerini kullanarak self servis BI işlemlerini de destekleyebilir. Analiz ve raporlama, veri uzmanları veya veri analistlerinin etkileşimli veri incelemelerini de içerir. Bu senaryolar için birçok Azure hizmeti Jupyter gibi analitik not defterlerini destekleyerek bu kullanıcıların Python veya Microsoft R ile mevcut becerilerini kullanmalarını sağlar. Büyük ölçekli veri keşfi için Microsoft R Server'ı tek başına veya Spark ile kullanabilirsiniz.
Düzenleme. Büyük veri çözümlerinin çoğu, iş akışlarıyla temsil edilen şekilde yinelenen veri işleme faaliyetlerinden oluşur. Bu iş akışları kaynak verileri dönüştürür, verileri çeşitli kaynaklar ve havuzlar arasında taşır, işlenen verileri bir analitik veri deposuna yükler ya da sonuçları doğrudan bir rapora veya panoya gönderir. Bu iş akışlarını otomatik hale getirmek için Azure Data Factory veya Apache Oozie ve Sqoop gibi bir düzenleme teknolojisi kullanabilirsiniz.
Lambda mimarisi
Çok büyük veri kümeleriyle çalışırken, istemcilerin gereksinim duyduğu sorgu sırasını çalıştırmak uzun sürebilir. Bu sorgular gerçek zamanlı olarak yapılamaz ve genellikle tüm veri kümesinde paralel olarak çalışan MapReduce gibi algoritmalar gerektirir. Sonuçlar daha sonra ham verilerden ayrı ayrı depolanır ve sorgulama için kullanılır.
Bu yaklaşımın bir dezavantajı, gecikme süresine neden olmasıdır; işleme birkaç saat sürerse, sorgu birkaç saatlik sonuçlar döndürebilir. İdeal olarak, bazı sonuçları gerçek zamanlı olarak almak (belki de biraz doğruluk kaybı ile) ve bu sonuçları toplu analiz sonuçlarıyla birleştirmek isteyebilirsiniz.
İlk olarak Nathan Marz tarafından önerilen lambda mimarisi, veri akışı için iki yol oluşturarak bu sorunu ele alır. Sisteme gelen tüm veriler bu iki yoldan geçer:
Toplu iş katmanı (durgun yol) tüm gelen verileri ham biçiminde depolar ve veriler üzerinde toplu işlem gerçekleştirir. Bu işlemin sonucu bir toplu görünüm olarak depolanır.
Hız katmanı (etkin yol), verileri gerçek zamanlı olarak analiz eder. Bu katman, doğruluktan ödün vererek düşük gecikme için tasarlanmıştır.
Toplu iş katmanı, verimli sorgulama için toplu iş görünümünü dizinleyen bir hizmet katmanına akış yapar. Hızı katman, en son verileri temel alan artımlı güncelleştirmelerle hizmet katmanını güncelleştirir.
Etkin yola akan veriler, mümkün olduğunca hızlı işleme alınabilmesi için hız katmanının oluşturduğu gecikme süresi gereksinimleri ile kısıtlanır. Genellikle, mümkün olduğunca hızlı bir şekilde hazır olan veriler için biraz daha fazla doğruluk gerektirir. Örneğin, çok sayıda sıcaklık sensörünün telemetri verileri gönderdiği bir IoT senaryosu düşünün. Hızı katmanı, gelen verilerin kayan zaman penceresini işleme almak için kullanılabilir.
Diğer yandan, durgun yola akan veriler ise aynı düşük gecikme süresi gereksinimlerine tabi değildir. Bu durum, her zaman son derece zaman yoğunluklu olabilen büyük veri kümelerinde yüksek doğrulukta hesaplama yapmayı sağlar.
Sonuç olarak, etkin ve durgun yollar analiz istemci uygulamasında birbirine yaklaşır. İstemcinin verileri zamanında ancak belki de daha az doğrulukla gerçek zamanlı olarak görüntülemesi gerekirse, sonucunu etkin yoldan alır. Aksi takdirde, daha az zamanında ancak daha doğru verileri görüntülemek için durgun yoldan sonuçları seçer. Diğer bir deyişle, etkin yolda görece küçük bir zaman penceresine ait veriler bulunur ve bu zaman penceresinden sonra sonuçlar durgun yoldaki daha doğru verilerle güncelleştirilebilir.
Toplu iş katmanında depolanan ham veriler sabittir. Gelen veriler her zaman var olan verilere eklenir ve hiçbir zaman önceki verilerin üzerine yazılmaz. Belirli bir verinin değerinde meydana gelen tüm değişiklikler yeni bir zaman damgalı olay kaydı olarak depolanır. Bunun yapılması, toplanan verilerin geçmişi boyunca herhangi bir zaman noktasında yeniden hesaplama yapmayı sağlar. Özgün ham verilerden toplu iş görünümünü yeniden hesaplama olanağı, sistem geliştikçe yeni görünümlerin oluşturulmasına izin verdiği için önemlidir.
Kappa mimarisi
Lambda mimarisinin karmaşıklığı bir dezavantajdır. İşleme mantığı, farklı çerçeveler kullanılarak iki farklı yerde (soğuk ve sık erişimli yollar) görünür. Bunun sonucunda yinelenen hesaplama mantığı ve her iki yol için mimariyi yönetme karmaşıklığı ortaya çıkar.
Kappa mimarisi, Jay Kreps tarafından lambda mimarisinin bir alternatifi olarak önerilmiştir. Bir önemli farklılık dışında lambda mimarisi ile aynı temel hedeflere sahiptir: Tüm veriler bir akış işleme sistemi kullanarak tek bir yoldan akar.
Olay verilerinin sabit olması ve bir alt küme yerine tümünün toplanması gibi, lambda mimarisinin toplu iş katmanıyla bazı benzerlikler bulunur. Veriler, dağıtılmış ve hataya dayanıklı birleşik bir günlüğe olay akışı olarak alınır. Bu olaylar sıralanır ve bir olayın mevcut durumu yalnızca eklenen yeni bir olayla değiştirilir. Bir lambda mimarisinin hız katmanına benzer şekilde tüm olay işlemesi giriş akışında gerçekleştirilir ve gerçek zamanlı bir görünüm olarak kalıcı hale getirilir.
Tüm veri kümesini yeniden hesaplamanız gerekir (lambda mimarisinde toplu iş katmanının yaptığı işleme eşdeğerdir), genellikle hesaplamayı zamanında tamamlamak üzere paralellik kullanarak akışı yeniden oynatmanız yeterlidir.
Nesnelerin İnterneti (IoT)
Pratik bir bakış açısından Nesnelerin İnterneti (IOT), İnternet'e bağlı herhangi bir cihazı temsil eder. Bu cihazlara bilgisayarınız, cep telefonunuz, akıllı saatiniz, akıllı termostatınız, akıllı buzdolabınız, İnternet’e bağlı otomobiliniz, kalp izleme implantları ve İnternet’e bağlanıp veri gönderen veya alan diğer cihazlar dahildir. Bağlı cihazların sayısı ve bu cihazlardan toplanan veri miktarı gün geçtikçe artmaktadır. Bu veriler genellikle yüksek oranda kısıtlanmış, bazı durumlarda yüksek gecikme süreli ortamlarda toplanır. Bazı durumlarda ise veriler binlerce veya milyonlarca cihaz tarafından düşük gecikme süreli ortamlardan gönderilir; böyle durumlarda verilerin hızlıca alınabilmesi ve uygun şekilde işlenebilmesi gerekir. Bu nedenle, bu kısıtlamaları ve benzersiz gereksinimleri karşılamak için doğru planlama gereklidir.
Olay denetimli mimariler, IoT çözümlerinin merkezidir. Aşağıdaki diyagramda IoT’ye yönelik olası bir mantıksal mimari gösterilmektedir. Diyagramda mimarinin olay akışı bileşenleri vurgulanmaktadır.
Bulut ağ geçidi, düşük gecikmeli güvenilir bir mesajlaşma sistemi kullanarak bulut sınırındaki cihaz olaylarını alır.
Cihazlar olayları bulut ağ geçidine doğrudan veya bir alan ağ geçidi üzerinden gönderebilir. Alan ağ geçidi genellikle cihazlarla aynı konumda olan ve olayları alıp bulut ağ geçidine ileten özel bir cihaz veya yazılımdır. Alan ağ geçidi aynı zamanda ham cihaz olaylarını yeniden işleyerek filtreleme, toplama veya protokol dönüştürme gibi işlevler de gerçekleştirebilir.
Alım sonrasında olaylar, verileri (örneğin, depolamaya) yönlendirebilen ya da analiz ve diğer işlemleri gerçekleştirebilen bir veya birden çok akış işlemcisinden geçer.
Aşağıda sık kullanılan bazı işleme türleri verilmiştir. (Bu liste tam kapsamlı değildir.)
Arşivleme veya toplu analiz amacıyla olay verilerini soğuk depolamaya yazma.
Etkin yol analizi: anormallikleri algılamak, toplanan zaman pencereleri üzerinden düzenleri tanımak veya akışta belirli bir koşul oluştuğunda uyarıları tetiklemek için olay akışını gerçek zamanlıya yakın olarak analiz etme.
Cihazlardan alınan, bildirim ve alarm gibi telemetri dışı özel ileti türlerini işleme.
Makine öğrenimi.
Gri gölgeli kutular bir IoT sisteminin, doğrudan olay akışıyla bağlantılı olmayan ancak bütünlük açısından buraya dahil edilen bileşenlerini gösterir.
Cihaz kayıt defteri, cihaz kimlikleri ve genellikle konum gibi cihaz meta verileri de dahil olmak üzere sağlanan cihazlardan oluşan bir veritabanıdır.
Sağlama API’si, yeni cihazların sağlanmasına ve kaydedilmesine yönelik olarak sık kullanılan bir dış arabirimdir.
Bazı IoT çözümleri komut ve denetim iletilerinin cihazlara gönderilmesini sağlar.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazar:
- Zoiner Tejada | CEO ve Mimar
Sonraki adımlar
Aşağıdaki ilgili Azure hizmetlerine bakın: