Bu, analitik sistemlerle ilgili bir dizi makalenin ikinci kısmıdır ().
Bugün, dikkatli veri işlemenin ve sonuçların yorumlanmasının neredeyse her türlü işletmeye yardımcı olabileceğine artık hiç şüphe yok. Bu bağlamda, analitik sistemler giderek daha fazla parametrelerle dolu hale geliyor ve uygulamalardaki tetikleyicilerin ve kullanıcı olaylarının sayısı artıyor.
Bu nedenle şirketler analistlerine analiz etmeleri ve doğru kararlara dönüştürmeleri için giderek daha fazla ham bilgi veriyor. Bir şirket için analitik sisteminin önemi hafife alınmamalı ve sistemin kendisi de güvenilir ve istikrarlı olmalıdır.
Müşteri analistleri
Müşteri analitiği, bir şirketin resmi SDK aracılığıyla web sitesine veya uygulamasına bağladığı, kendi kod tabanına entegre ettiği ve olay tetikleyicilerini seçtiği bir hizmettir. Bu yaklaşımın bariz bir dezavantajı var: Seçtiğiniz herhangi bir hizmetin sınırlamaları nedeniyle toplanan tüm veriler tam olarak istediğiniz şekilde işlenemeyebilir. Örneğin bir sistemde MapReduce görevlerini çalıştırmak kolay olmayacak, diğerinde ise modelinizi çalıştıramayacaksınız. Diğer bir dezavantaj, hizmetler için düzenli (etkileyici) fatura olacaktır.
Piyasada çok sayıda müşteri analitiği çözümü var, ancak er ya da geç analistler her göreve uygun tek bir evrensel hizmetin olmadığı gerçeğiyle karşı karşıya kalacaklar (bu arada tüm bu hizmetlerin fiyatları sürekli artıyor). Böyle bir durumda şirketler genellikle gerekli tüm özel ayarlara ve yeteneklere sahip kendi analiz sistemlerini oluşturmaya karar verirler.
Sunucu analistleri
Sunucu tarafı analitiği, bir şirketin kendi sunucularına ve (genellikle) kendi çabalarıyla dağıtılabilen bir hizmettir. Bu modelde, tüm kullanıcı olayları dahili sunucularda depolanarak geliştiricilerin farklı depolama veritabanlarını denemesine ve en uygun mimariyi seçmesine olanak sağlanır. Bazı görevler için hâlâ üçüncü taraf istemci analitiğini kullanmak isteseniz bile bu yine de mümkün olacaktır.
Sunucu tarafı analitiği iki şekilde dağıtılabilir. İlk olarak: bazı açık kaynak yardımcı programlarını seçin, bunları makinelerinize dağıtın ve iş mantığını geliştirin.
Avantajları:
Eksileri
İstediğiniz her şeyi özelleştirebilirsiniz
Bu genellikle çok zordur ve ayrı geliştiriciler gerektirir
İkincisi: Kendiniz dağıtmak yerine SaaS hizmetlerini (Amazon, Google, Azure) alın. Üçüncü bölümde SaaS'tan daha detaylı bahsedeceğiz.
Avantajları:
Eksileri
Orta hacimlerde daha ucuz olabilir ancak büyük bir büyümeyle yine de çok pahalı hale gelecektir.
Tüm parametreleri kontrol etmek mümkün olmayacak
Yönetim tamamen servis sağlayıcının omuzlarına devredilir
Hizmetin içinde ne olduğu her zaman bilinmez (gerekli olmayabilir)
Sunucu analizleri nasıl toplanır?
Müşteri analitiğini kullanmaktan uzaklaşıp kendi analitiğini oluşturmak istiyorsak, öncelikle yeni sistemin mimarisini düşünmemiz gerekiyor. Aşağıda size adım adım neleri dikkate almanız gerektiğini, her adımın neden gerekli olduğunu ve hangi araçları kullanabileceğinizi anlatacağım.
1. Veri alma
Tıpkı müşteri analitiğinde olduğu gibi, şirket analistleri öncelikle gelecekte incelemek istedikleri olay türlerini seçer ve bunları bir liste halinde toplar. Tipik olarak bu olaylar, "olay modeli" adı verilen belirli bir sırada meydana gelir.
Daha sonra, bir mobil uygulamanın (web sitesinin) düzenli kullanıcılara (cihazlara) ve çok sayıda sunucuya sahip olduğunu hayal edin. Olayları cihazlardan sunuculara güvenli bir şekilde aktarmak için bir ara katmana ihtiyaç vardır. Mimariye bağlı olarak birkaç farklı olay kuyruğu olabilir.
- Mı Olayları toplamak için kuyruk olarak kullanılır.
Göre 2014 yılında Apache Kafka'nın yaratıcısı, "yazma için optimize edilmiş bir sistem" olması ve Kafka'nın çalışmalarını sevmesi nedeniyle yazılıma Franz Kafka'nın adını vermeye karar verdi. —
Örneğimizde çok sayıda veri üreticisi ve veri tüketicisi (cihazlar ve sunucular) vardır ve Kafka bunların birbirine bağlanmasına yardımcı olur. Tüketiciler, ana konuların olacağı ilerleyen adımlarda daha detaylı anlatılacaktır. Şimdi sadece veri üreticilerini (olayları) ele alacağız.
Kafka kuyruk ve bölüm kavramlarını özetlemektedir; bu konuyu başka bir yerde daha spesifik olarak okumak daha iyidir (örneğin, ). Detaylara girmeden iki farklı işletim sistemi için bir mobil uygulamanın başlatıldığını düşünelim. Daha sonra her sürüm kendi ayrı olay akışını oluşturur. Yapımcılar olayları Kafka'ya gönderir, uygun bir sıraya kaydedilir.
(resim )
Aynı zamanda Kafka, parçalar halinde okumanıza ve bir olay akışını mini gruplar halinde işlemenize olanak tanır. Kafka, artan ihtiyaçlara (örneğin, olayların coğrafi konumuyla) uygun şekilde ölçeklenebilen çok kullanışlı bir araçtır.
Genellikle bir parça yeterlidir, ancak ölçeklendirme sırasında işler daha da karmaşıklaşır (her zaman olduğu gibi). Mimarinin hataya dayanıklı olması gerektiğinden muhtemelen hiç kimse üretimde yalnızca tek bir fiziksel parça kullanmak istemeyecektir. Kafka'ya ek olarak iyi bilinen başka bir çözüm daha var - RabbitMQ. Bunu üretimde etkinlik analitiği için bir kuyruk olarak kullanmadık (böyle bir deneyiminiz varsa, yorumlarda bize bundan bahsedin!). Ancak biz AWS Kinesis'i kullandık.
Bir sonraki adıma geçmeden önce, sistemin ek bir katmanından daha bahsetmemiz gerekiyor: ham günlük depolama. Bu gerekli bir katman değil ancak bir şeyler ters giderse ve Kafka'daki olay kuyrukları sıfırlanırsa faydalı olacaktır. Ham günlüklerin saklanması karmaşık ve pahalı bir çözüm gerektirmez; bunları yalnızca doğru sırayla bir yere (hatta sabit sürücüye) yazabilirsiniz.
2. Olay akışlarının işlenmesi
Tüm eventleri hazırlayıp uygun sıralara yerleştirdikten sonra işleme adımına geçiyoruz. Burada size en yaygın iki işleme seçeneğinden bahsedeceğim.
İlk seçenek Apache sisteminde Spark Streaming'i etkinleştirmektir. Tüm Apache ürünleri, dosya kopyalarına sahip güvenli bir dosya sistemi olan HDFS'de bulunur. Spark Streaming, akış verilerini işleyen ve iyi ölçeklendiren, kullanımı kolay bir araçtır. Ancak bakımı zor olabilir.
Başka bir seçenek de kendi olay işleyicinizi oluşturmaktır. Bunu yapmak için örneğin bir Python uygulaması yazmanız, onu Docker'da oluşturmanız ve Kafka kuyruğuna abone olmanız gerekir. Tetikleyiciler liman işçisi işleyicilerine ulaştığında işlem başlayacaktır. Bu yöntemle uygulamalarınızı her zaman çalışır durumda tutmanız gerekir.
Yukarıda açıklanan seçeneklerden birini seçtiğimizi ve işleme devam ettiğimizi varsayalım. İşlemciler, verilerin geçerliliğini kontrol ederek, çöpleri ve "bozuk" olayları filtreleyerek başlamalıdır. Doğrulama için genellikle kullanırız . Bundan sonra veri eşleme yapabilirsiniz: farklı kaynaklardan gelen veriler ortak bir tabloya eklenmek üzere normalleştirilir ve standartlaştırılır.
3. Veritabanı
Üçüncü adım normalleştirilmiş olayları sürdürmektir. Hazır bir analitik sistemle çalışırken bunlara sık sık erişmemiz gerekecek, bu nedenle uygun bir veritabanı seçmek önemlidir.
Veriler sabit bir şemaya iyi uyuyorsa, veya başka bir sütunlu veritabanı. Bu şekilde toplamalar çok hızlı çalışacaktır. Dezavantajı ise şemanın sıkı bir şekilde sabitlenmiş olması ve bu nedenle değişiklik yapılmadan rastgele nesnelerin eklenmesinin mümkün olmayacağıdır (örneğin, standart olmayan bir olay meydana geldiğinde). Ama gerçekten çok hızlı sayabilirsiniz.
Yapılandırılmamış veriler için NoSQL'i kullanabilirsiniz, örneğin: . HDFS üzerinde çalışır, iyi çoğalır, birçok örneği yükseltebilirsiniz ve hataya dayanıklıdır.
Ayrıca daha basit bir şeyi de yükseltebilirsiniz, örneğin, . Oldukça yavaştır ve küçük hacimler içindir. Ancak artısı, çok basit olması ve bu nedenle başlangıç için uygun olmasıdır.
4. Toplamalar
Tüm olayları dikkatlice kaydettikten sonra, gelen partideki tüm önemli bilgileri toplamak ve veritabanını güncellemek istiyoruz. Küresel olarak ilgili kontrol panellerini ve ölçümleri almak istiyoruz. Örneğin olaylardan bir kullanıcı profili toplayın ve bir şekilde davranışı ölçün. Etkinlikler toplanır, toplanır ve tekrar kaydedilir (kullanıcı tablolarında). Aynı zamanda toplayıcı-koordinatöre bir filtre bağlayabileceğiniz bir sistem de oluşturabilirsiniz: yalnızca belirli bir etkinlik türünden kullanıcıları toplayın.
Bundan sonra ekipteki bir kişinin yalnızca üst düzey analizlere ihtiyacı varsa harici analiz sistemlerine bağlanılabilir. Mixpanel'i tekrar alabilirsiniz. ancak oldukça pahalı olduğundan, tüm kullanıcı etkinlikleri oraya gönderilmez, yalnızca ihtiyaç duyulanlar oraya gönderilir. Bunu yapmak için, bazı ham olayları veya daha önce kendimiz topladığımız bir şeyi harici sistemlere, API'lere veya reklam platformlarına aktaracak bir koordinatör oluşturmamız gerekiyor.
5. Ön uç
Ön ucu oluşturulan sisteme bağlamanız gerekir. İyi bir örnek hizmettir , kontrol panelleri oluşturmaya yardımcı olan bir veritabanı GUI'sidir. Etkileşim nasıl çalışır:
- Kullanıcı bir SQL sorgusu yapar.
- Yanıt olarak bir işaret alır.
- Kendisi için 'yeni bir görselleştirme' oluşturur ve kendinize kaydedebileceğiniz güzel bir grafik elde eder.
Hizmetteki görselleştirmeler otomatik olarak güncellenmektedir, izlemenizi özelleştirebilir ve takip edebilirsiniz. Redash, kendi kendine barındırılıyorsa ücretsizdir, ancak SaaS olarak aylık 50 ABD dolarına mal olacaktır.
Sonuç
Yukarıdaki tüm adımları tamamladıktan sonra sunucu analitiğinizi oluşturacaksınız. Her şeyin sizin tarafınızdan yapılandırılması gerektiğinden, bunun yalnızca müşteri analizlerini bağlamak kadar basit olmadığını lütfen unutmayın. Bu nedenle, kendi sisteminizi oluşturmadan önce, ciddi bir analitik sistemine olan ihtiyacı, ona ayırmaya hazır olduğunuz kaynaklarla karşılaştırmaya değer.
Hesaplamayı yaptıysanız ve maliyetlerin çok yüksek olduğunu fark ettiyseniz, bir sonraki bölümde sunucu tarafı analitiğinin daha ucuz bir versiyonunun nasıl oluşturulacağından bahsedeceğim.
Okuduğunuz için teşekkürler! Yorumlarda soru sormaktan memnuniyet duyarım.
Kaynak: habr.com