Büyük Veri ile başlıyorsanız, aralarından seçim yapabileceğiniz çok sayıda araç, çerçeve ve seçenek karşısında bunalmış hissetmeniz yaygındır. Bu yazıda, Büyük Veri yolculuğunuza başlamanız için malzemeleri ve temel tarifi özetlemeye çalışacağım . Amacım, farklı araçları kategorize etmek ve her bir aracın amacını ve ekosisteme nasıl uyduğunu açıklamaya çalışmaktır.
Öncelikle bazı hususları gözden geçirelim ve gerçekten bir Büyük Veri sorununuz olup olmadığını kontrol edelim . Üzerinde durulacak açık kaynak dağıtılabilir çözümleri on-Prem . Bulut sağlayıcıları, veri ihtiyaçlarınız için çeşitli çözümler sunar ve bunlardan biraz bahsedeceğim. Bulutta çalışıyorsanız, sizin için hangi seçeneklerin mevcut olduğunu gerçekten kontrol etmeli ve maliyet, çalıştırılabilirlik, yönetilebilirlik, izleme ve pazara ulaşma süresi boyutlarına bakarak açık kaynaklı çözümlerle karşılaştırmalısınız.
(Büyük veri deneyiminiz varsa, sonraki bölüme geçin…)
Büyük Veri karmaşıktır , kesinlikle mecbur kalmadıkça içine atlamayın. İçgörüler elde etmek için küçük başlayın, bilgi toplamaya başlamak için Elastik Arama ve Prometheus / Grafana'yı kullanabilir ve işletmeniz hakkında bilgi almak için gösterge tabloları oluşturabilirsiniz. Verileriniz genişledikçe, bu araçlar yeterince iyi veya bakımı için çok pahalı olmayabilir. Bu, bir veri gölü veya veri ambarı düşünmeye başlamanız gereken zamandır; ve büyük düşünmeye başlamak için zihninizi değiştirin .
Kontrol verilerinizin hacmi kadar var ve ne kadar süre için mağazaya gerekiyor nasıl. Sıcaklığı kontrol edin ! zamanla değer kaybediyor, bu durumda verileri ne kadar süreyle saklamanız gerekiyor? Kaç tane saklama katmanına (sıcak / ılık / soğuk) ihtiyacınız var? verileri arşivleyebilir veya silebilir misiniz?
Kendinize sormanız gereken diğer sorular şunlardır: Ne tür veriler depoluyorsunuz? hangi formatları kullanıyorsunuz? yasal zorunluluğun var mı? Verileri ne kadar hızlı beslemeniz gerekiyor? sorgulama için mevcut verilere ne kadar hızlı ihtiyacınız var? Ne tür sorgular bekliyorsunuz? OLTP veya OLAP? Altyapı sınırlamalarınız nelerdir? Verileriniz ne tür? İlişkisel mi? Grafik? Belge? Uygulamanız gereken bir şema var mı?
Bununla ilgili birkaç makale yazabilirim , bu tarifin işe yaraması için verilerinizi anlamanız, sınırlar , gereksinimler, yükümlülükler vb. Belirlemeniz çok önemlidir .
Veri hacmi anahtardır, günde milyarlarca olay veya büyük veri kümeleriyle ilgileniyorsanız, ardışık düzeninize Büyük Veri ilkelerini uygulamanız gerekir. Ancak, " küçük " ile " büyük " veriyi birbirinden ayıran tek bir sınır yoktur ve hız , ekip organizasyonunuz , şirketin büyüklüğü, gerekli analiz türü, altyapı veya iş hedefleri gibi diğer unsurları etkileyecektir. büyük veri yolculuğunuz. Bazılarını gözden geçirelim…
Birkaç yıl önce işletmeler, kullanıcıları ve diğer yapılandırılmış verileri ( OLTP ) depolamak için kullanılan ilişkisel bir veritabanıyla desteklenen çevrimiçi uygulamalara sahipti . Bir gecede bu veriler, karmaşık işler kullanılarak veri analizi ve iş zekası ( OLAP ) için optimize edilmiş bir veri ambarında arşivlendi . Geçmiş veriler veri ambarına kopyalandı ve iş kararları vermek için kullanılan raporlar oluşturmak için kullanıldı.
Veriler büyüdükçe, veri ambarları pahalı ve yönetilmesi zor hale geldi. Ayrıca şirketler, görüntüler veya günlükler gibi yapılandırılmamış verileri depolamaya ve işlemeye başladı. İle Büyük Verilerden , şirketler yaratmak için başlatılan veri göller tüm verilerin tek bir depo oluşturmak üzere onlardan yapılandırılmış ve yapılandırılmamış verileri merkezde için.
Kısacası, bir veri gölü, verileri bir HA dosya sisteminde depolayan bir dizi bilgisayar düğümü ve verileri işlemek ve bunlardan içgörüler elde etmek için bir dizi araçtır . Map Azaltmaya Dayalı Spark gibi çok büyük bir araç ekosistemi yaratıldı, bu tür Spark , daha uygun maliyetli olan ticari donanım kullanarak her türlü veriyi işlemek için oluşturuldu . Fikir, verileri ucuz donanımda işleyip depolayabilmeniz ve ardından depolanan dosyaları doğrudan sorgulayabilmenizdir bir veritabanı kullanmak, ancak daha sonra tartışacağımız dosya formatlarına ve harici şemalara güvenmek. Hadoop , verileri uygun maliyetli bir şekilde depolamak için HDFS dosya sistemini kullanır .
İçin OLTP , son yıllarda, doğru bir değişim vardı NoSQL veritabanları böyle kullanılarak, MongoDB veya Cassandra SQL veritabanları ile ilgili sınırlamalar dışında ölçeklendirebilecekleri. Ancak, yeni veritabanları büyük miktarda veriyi işleyebilir ve hem OLTP hem de OLAP için kullanılabilir ve bunu hem akış hem de toplu işlem için düşük bir maliyetle yapabilir ; YugaByteDB gibi işlemsel veritabanları bile büyük miktarda veriyi işleyebilir. Birçok sistemi, uygulaması, kaynağı ve veri türü olan büyük kuruluşlar, analitik ihtiyaçlarını karşılamak için bir veri ambarına ve / veya veri gölüne ihtiyaç duyacaktır, ancak şirketinizin çok fazla bilgi kanalı yoksa ve / veya bulutta çalışıyorsanız, tek bir devasa veritabanı , mimarinizi basitleştirmeye ve maliyetleri önemli ölçüde azaltmaya yetebilir .
2006'da piyasaya sürüldüğünden beri Hadoop , Büyük Veri dünyasında ana referans olmuştur. MapReduce programlama modeline dayanarak, basit bir programlama modeli kullanarak büyük miktarda veriyi işlemeye izin verdi. Ekosistem, yıllar içinde katlanarak büyüdü ve herhangi bir kullanım durumu ile başa çıkmak için zengin bir ekosistem yarattı.
Son zamanlarda, Hadoop Ekosistemine yönelik bazı eleştiriler oldu ve kullanımın son birkaç yıldır azalmakta olduğu açık. Kendi veri formatlarını kullanarak ultra düşük gecikmeyle alma ve sorgulama yapabilen yeni OLAP motorları, Hadoop'taki en yaygın sorgu motorlarından bazılarının yerini alıyor; ancak en büyük etki, herhangi bir altyapıyı yönetmeden herhangi bir Büyük Veri görevini gerçekleştirebileceğiniz bulut sağlayıcıları tarafından piyasaya sürülen Sunucusuz Analitik çözümlerinin sayısının artmasıdır .
Hadoop ekosisteminin boyutu ve büyük kullanıcı tabanı göz önüne alındığında, ölü olmaktan uzak görünüyor ve yeni çözümlerin çoğunun, uyumlu API'ler ve Hadoop Ekosistemiyle entegrasyonlar oluşturmaktan başka seçeneği yok. HDFS, ekosistemin merkezinde yer almasına rağmen, bulut sağlayıcıları S3 veya GCS gibi daha ucuz ve daha iyi derin depolama sistemleri oluşturduğundan artık yalnızca şirket içinde kullanılıyor . Bulut sağlayıcıları , kutudan çıktığı gibi yönetilen Hadoop kümeleri de sağlar . Öyle görünüyor ki, Hadoop hala hayatta ve tekmeliyor, ancak Hadoop ekosisteminizi oluşturmaya başlamadan önce başka yeni alternatiflerin de olduğunu aklınızda bulundurmalısınız. Bu yazımda, hangi araçların Hadoop ekosisteminin bir parçası olduğunu, hangilerinin onunla uyumlu olduğunu ve hangilerinin Hadoop ekosisteminin bir parçası olmadığını anlatmaya çalışacağım.
Veri sıcaklığınızın analizine bağlı olarak, gerçek zamanlı akışa mı, toplu işlemeye mi yoksa çoğu durumda her ikisine birden mi ihtiyacınız olduğuna karar vermeniz gerekir .
Mükemmel bir dünyada, canlı verilerden tüm içgörülerinizi gerçek zamanlı olarak alırsınız ve pencere tabanlı toplamalar gerçekleştirirsiniz. Bununla birlikte, bazı kullanım durumları için bu mümkün değildir ve diğerleri için uygun maliyetli değildir; bu nedenle birçok şirket hem toplu işlem hem de akış işlemeyi kullanır . İş ihtiyaçlarınızı kontrol etmeli ve hangi yöntemin size daha uygun olduğuna karar vermelisiniz. Örneğin, sadece bazı raporlar oluşturmanız gerekiyorsa, toplu işlem yeterli olmalıdır. Toplu iş daha basit ve daha ucuzdur .
4. nesil büyük veri motorları olarak da bilinen Apache Flink veya Apache Beam gibi en yeni işleme motorları , toplu işin sadece 24 saatte bir akış işlemesinin yapıldığı toplu ve akışlı veriler için birleşik bir programlama modeli sağlar. Bu, programlama modelini basitleştirir.
Yaygın bir model, kredi kartı sahtekarlığı ve raporlama ve analitik için toplu iş gibi zaman açısından kritik öngörülere sahip akış verilerine sahip olmaktır. Daha yeni OLAP motorları her ikisini birleşik bir şekilde sorgulamaya izin verir.
Kullanım durumunuza bağlı olarak , verileri yüklerken veya okurken dönüştürmek isteyebilirsiniz . ELT, sorgunun bir parçası olarak verileri dönüştüren ve bir araya getiren sorguları yürütebileceğiniz anlamına gelir; bu, işlevleri uygulayabileceğiniz, verileri filtreleyebileceğiniz, sütunları yeniden adlandırabileceğiniz, görünümler oluşturabileceğiniz vb. SQL kullanarak yapmak mümkündür. Bu, Büyük Veri OLAP motorları ile mümkündür. ELT tarzında gerçek zamanlı ve toplu sorgulamanın bir yolunu sağlar. Diğer seçenek, verileri yüklerken ( ETL ) dönüştürmektir, ancak işleme sırasında birleştirme ve toplamalar yapmanın önemsiz bir iş olmadığını unutmayın. Genel olarak, veri ambarları sabit bir şema (yıldız veya kar tanesi) gerektirdikleri için ETL kullanır , oysa veri gölleri daha esnektir ve okumada ELT ve şema yapabilir .
Her yöntemin kendi avantajları ve dezavantajları vardır. Kısacası, okumada dönüşümler ve toplama daha yavaştır ancak daha fazla esneklik sağlar. Sorgularınız yavaşsa, işleme aşamasında önceden katılmanız veya bir araya getirmeniz gerekebilir. Daha sonra tartışılacak OLAP motorları, alım sırasında ön toplama gerçekleştirebilir.
Son olarak, şirket politikalarınız, organizasyonunuz, metodolojileriniz, altyapınız, ekip yapınız ve becerileriniz Büyük Veri kararlarınızda önemli bir rol oynar . Örneğin, bir ardışık düzen oluşturmanızı gerektiren ancak büyük miktarda veriyle uğraşmanıza gerek kalmayan bir veri sorununuz olabilir, bu durumda bir veri alma, zenginleştirme ve dönüştürme gerçekleştirdiğiniz bir akış uygulaması yazabilirsiniz. daha kolay olan tek boru hattı; ancak şirketinizin zaten bir veri gölü varsa, mevcut platformu kullanmak isteyebilirsiniz, bu sıfırdan inşa etmeyeceğiniz bir şeydir.
Başka bir örnek ETL ve ELT'dir. Geliştiriciler, verilerin basit bir biçimde sorgulanmaya hazır olduğu ETL sistemleri oluşturma eğilimindedir, böylece teknik olmayan çalışanlar gösterge tabloları oluşturabilir ve içgörüler alabilir. Bununla birlikte, güçlü bir veri analisti ekibiniz ve küçük bir geliştirici ekibiniz varsa, geliştiricilerin yalnızca beslemeye odaklandığı ELT yaklaşımını tercih edebilirsiniz; ve veri analistleri, verileri dönüştürmek ve toplamak için karmaşık sorgular yazar. Bu, büyük veri yolculuğunuzda ekip yapınızı ve becerilerinizi göz önünde bulundurmanın ne kadar önemli olduğunu gösterir.
Veriler, tüm organizasyonda işlevler arası bir unsur olduğundan, birlikte çalışan farklı becerilere ve geçmişe sahip farklı bir ekibin olması önerilir. Veri gölleri, veri yönetimini ve güvenliğini korurken kolay iş birliği sağlama konusunda son derece iyidir .
Büyük Veri dünyasının çeşitli yönlerini inceledikten sonra, temel bileşenlerin neler olduğuna bakalım.
İhtiyacınız olan ilk şey, tüm verilerinizi depolayacağınız bir yer. Maalesef ihtiyaçlarınızı karşılayacak tek bir ürün yok, bu yüzden kullanım durumlarınıza göre doğru depolamayı seçmeniz gerekiyor.
Gerçek zamanlı veri alımı için , gerçek zamanlı olayları depolamak için bir ekleme günlüğü kullanmak yaygındır, en ünlü motor Kafka'dır . Bir alternatif Apache Pulsar'dır . Her ikisi de akış yeteneklerinin yanı sıra etkinlikleriniz için depolama sağlar. Bu, uygun maliyetli olmadığı için genellikle sıcak veriler için kısa süreli depolamadır (veri sıcaklığını unutmayın!). Apache NiFi gibi kendi depolama alanına sahip verileri almak için kullanılan başka araçlar da vardır . Sonunda, ekleme günlüğünden veriler, bir veritabanı veya dosya sistemi olabilecek başka bir depolama birimine aktarılır.
Devasa Veritabanları
Hadoop HDFS, veri gölleri için en yaygın biçimdir ancak; büyük ölçekli veritabanları, bir dosya sistemi yerine veri ardışık düzeniniz için arka uç olarak kullanılabilir; Daha fazla bilgi için Massive Scale Databases hakkındaki önceki makaleme göz atın . Özetle Cassandra , YugaByteDB veya BigTable gibi veritabanları büyük miktarda veriyi bir veri gölünden çok daha hızlı tutabilir ve işleyebilir, ancak bu kadar ucuz olamaz; ancak, veri gölü dosya sistemi ile veritabanı arasındaki fiyat farkı her yıl gitgide küçülüyor; bu, Hadoop / NoHadoop kararınızın bir parçası olarak dikkate almanız gereken bir konudur . Artık daha fazla şirket, veri ihtiyaçları için veri gölü yerine büyük bir veri veritabanı seçiyor ve yalnızca arşivleme için derin depolama dosya sistemini kullanıyor.
Hadoop ekosistemi dışındaki veritabanları ve depolama seçeneklerini özetlemek gerekirse :
Hadoop Veritabanları
HBase , Hadoop ekosistemindeki en popüler veri tabanıdır. Sütun biçiminde büyük miktarda veri tutabilir. BigTable'a dayanmaktadır.
Dosya Sistemleri (Derin Depolama)
İçin veri göller , Hadoop ekosistemde, HDF'ler dosya sistemi kullanılmaktadır. Bununla birlikte, çoğu bulut sağlayıcısı, onu S3 veya GCS gibi kendi derin depolama sistemleriyle değiştirdi .
Bu dosya sistemleri veya derin depolama sistemleri, veri tabanlarından daha ucuzdur, ancak sadece temel depolama sağlar ve güçlü ACID garantileri sağlamaz .
İhtiyaçlarınıza ve bütçenize göre kullanım durumunuz için doğru depolamayı seçmeniz gerekecektir. Örneğin, bütçeniz izin veriyorsa besleme için bir veritabanı kullanabilir ve ardından veriler dönüştürüldükten sonra OLAP analizi için veri gölünüzde depolayabilirsiniz. Veya her şeyi derin depolamada, ancak ilişkisel veritabanı gibi hızlı bir depolama sisteminde küçük bir sıcak veri alt kümesinde depolayabilirsiniz.
Dosya formatları
Bir HDFS kullanıyorsanız bir diğer önemli karar , dosyalarınızı depolamak için hangi formatı kullanacağınızdır. Derin depolama sistemlerinin verileri dosyalar olarak depoladığını ve farklı dosya formatlarının ve sıkıştırma algoritmalarının belirli kullanım durumları için avantajlar sağladığını unutmayın. Veri gölünüzde verileri nasıl sakladığınız çok önemlidir ve biçim , sıkıştırma ve özellikle verilerinizi nasıl bölümlediğinizi göz önünde bulundurmanız gerekir .
En yaygın formatlar CSV, JSON, AVRO , Protokol Tamponları , Parquet ve ORC'dir .
Biçimi seçerken dikkate alınması gereken bazı noktalar şunlardır:
Son olarak, dosya boyutu ve CPU maliyetleri arasındaki dengeyi göz önünde bulundurarak dosyalarınızdaki verileri nasıl sıkıştıracağınızı da düşünmeniz gerekir . Bazı sıkıştırma algoritmaları daha hızlıdır ancak dosya boyutu daha büyüktür ve diğerleri daha yavaştır ancak daha iyi sıkıştırma oranlarına sahiptir. Daha fazla ayrıntı için bu makaleye bakın .
Çok fazla CPU gücü gerektirmediğinden veri akışı için hızlı kullanmanızı tavsiye ederim. Toplu iş için bzip2 harika bir seçenektir.
Yine, daha önce bahsettiğimiz hususları gözden geçirmeniz ve incelediğimiz tüm yönlere göre karar vermeniz gerekiyor. Örnek olarak bazı kullanım durumlarını inceleyelim:
Kullanım Durumları
Mevcut altyapınız, hangi araçların kullanılacağına karar verirken seçeneklerinizi sınırlayabilir. Sorulacak ilk soru: Bulut ve On-Prem . Bulut sağlayıcıları birçok seçenek ve esneklik sunar. Ayrıca, Büyük Veri ihtiyaçlarınız için yönetimi ve izlemesi daha kolay olan Sunucusuz çözümler sunarlar. Kesinlikle bulut, Büyük Veri için olması gereken yerdir; Hadoop ekosistemi için bile bulut sağlayıcıları, yönetilen kümeler ve şirket içinden daha ucuz depolama sunar. Bulut çözümleriyle ilgili diğer makalelerime göz atın.
Eğer çalışıyorsa tesislerinde aşağıdakilerden düşünmelisin:
Bir sonraki bileşen, veri ardışık düzeninizin başarısı için çok önemlidir. Büyük veri dünyasında, süreçleriniz ve verileriniz hakkında sürekli geri bildirime ihtiyacınız var . Ölçümleri toplamanız, günlükleri toplamanız, sistemlerinizi izlemeniz, uyarılar , gösterge tabloları oluşturmanız ve çok daha fazlasını yapmanız gerekir .
İzleme ve uyarı için Prometheus ve Grafana gibi açık kaynaklı araçları kullanın . Günlükleri toplamak ve bunları ElasticSearch gibi bir yerde saklamak için günlük toplama teknolojilerini kullanın .
Mümkün olduğunda izleme ve uyarma için bulut sağlayıcılarının yeteneklerinden yararlanın . Platformunuza bağlı olarak, farklı bir araç seti kullanacaksınız. Bulut Sunucusuz platform için bulut sağlayıcı araçlarınıza ve en iyi uygulamalarınıza güveneceksiniz. Kubernetes için açık kaynaklı monitör çözümlerini veya kurumsal entegrasyonları kullanacaksınız. Farklı çözümlere göz atıp kontrol edebileceğiniz ve kendi APM çözümünüzü oluşturabileceğiniz bu web sitesini gerçekten tavsiye ederim .
Büyük Veri dünyasında dikkate alınması gereken bir diğer husus da denetlenebilirlik ve hesap verebilirliktir. Farklı düzenlemeler nedeniyle, veri boru hattından akarken her değişikliği yakalayıp kaydetmeniz, verileri izlemeniz gerekebilir. Buna veri kaynağı veya soy adı verilir . Verilerinizi kontrol etmek, kaydetmek ve yönetmek için Apache Atlas gibi araçlar kullanılır. Apache NiFi gibi diğer araçlar , veri kökenini kutudan çıkarır . İçin gerçek zamanlı izleri, çek aç Telemetri veya Jaeger . Datadog gibi birçok bulut hizmeti de var .
Hadoop kullanımı için, Ganglia .
Apache Ranger , Hadoop platformunuz için birleşik bir güvenlik izleme çerçevesi sağlar. Merkezi bir kullanıcı arayüzünde güvenlikle ilgili tüm görevleri yönetmek için merkezi güvenlik yönetimi sağlar. Sağladığı yetki farklı yöntem ve tüm Hadoop platformu genelinde de tam denetlenebilirlik kullanarak.
Takımınız başarının anahtarıdır. Büyük Veri Mühendislerini bulmak zor olabilir. Eğitim, beceri geliştirme ve atölyelere yatırım yapın. Siloları ve bürokrasiyi kaldırın, yinelemeleri basitleştirin ve ekip sınırlarınızı ve sorumluluklarınızı belirlemek için Etki Alanına Dayalı Tasarım'ı kullanın.
Büyük Veri için iki geniş kategoriniz olacak :
Bu önemli bir husustur, diğer tüm malzemeleri satın almak için paraya ihtiyacınız vardır ve bu sınırlı bir kaynaktır. Sınırsız paranız varsa, devasa bir veritabanı kurabilir ve onu büyük veri ihtiyaçlarınız için pek çok karmaşıklık olmadan kullanabilirsiniz, ancak bu size mal olur. Bu nedenle, bu makalede bahsedilen her teknoloji, onu kullanma, uygulama ve sürdürme becerisine sahip kişiler gerektirir. Bazı teknolojiler diğerlerinden daha karmaşıktır, bu yüzden bunu hesaba katmanız gerekir.
Artık malzemelere sahip olduğumuza göre, büyük veri tarifimizi pişirelim. Bir de Özetle işlemi basittir; farklı kaynaklardan veri almanız, zenginleştirmeniz, bir yerde saklamanız, meta verileri (şema) depolamanız, temizlemeniz, normalleştirmeniz, işlemeniz, kötü verileri karantinaya almanız, verileri optimum şekilde bir araya getirmeniz ve son olarak aşağı akışlı sistemler tarafından tüketilecek bir yerde depolamanız gerekir. .
Her adıma biraz daha detaylı bakalım…
İlk adım veriyi elde etmek , bu aşamanın amacı ihtiyacınız olan tüm verileri elde etmek ve tek bir depoda ham formatta depolamaktır. Bu genellikle, verilerini Kafka'ya veya bir veri deposuna aktaran diğer ekiplere aittir.
Çok fazla miktarda veriye sahip olmayan basit ardışık düzenler için, verileri tek bir ardışık düzende (alım + dönüştürme) alabilen, zenginleştirebilen ve dönüştürebilen basit bir mikro hizmet iş akışı oluşturabilirsiniz , bağımlılıkları düzenlemek için Apache Airflow gibi araçları kullanabilirsiniz . Bununla birlikte, Büyük Veri için beslemeyi işlemeden ayırmanız önerilir; paralel olarak çalışabilen devasa işlem motorları, engelleme çağrılarını, yeniden denemeleri, karşı basıncı vb. İşlemek için harika değildir. Bu nedenle, tüm verilerin önceden kaydedilmesi önerilir. işlemeye başlıyorsunuz. İşlemden önce referans verileri de dahil olmak üzere tüm verilerin göle indiğinden emin olmak için diğer sistemleri arayarak verilerinizi alımın bir parçası olarak zenginleştirmelisiniz.
İki alım modu vardır :
Bağımlılıkları en aza indirgemek için , diğer kaynak sistemlerle sıkı sıkıya bağlı olacağınız için , kaynak sistemin veriyi ekibinizin çekmesi yerine Kafka'ya göndermesi her zaman daha kolaydır . Bu mümkün değilse ve yine de besleme sürecine sahip olmanız gerekiyorsa, besleme için iki geniş kategoriye bakabiliriz :
NiFi , kategorize edilmesi zor olan bu araçlardan biridir. Kendi başına bir canavar. Besleme, düzenleme ve hatta basit dönüşümler için kullanılabilir. Yani teoride basit Büyük Veri problemlerini çözebilir. Bu bir olduğunu yönetilen çözüm . Bileşenleri sadece sürükleyip bırakabileceğiniz ve verileri alıp zenginleştirmek için kullanabileceğiniz görsel bir arayüze sahiptir . Bu sahiptir işlemciler inşa 300'den fazla sayıda görevleri yerine ve kendi uygulayarak bunu uzatabilirsiniz.
Kendi mimarisi vardır, bu nedenle herhangi bir veri tabanı HDFS kullanmaz, ancak Hadoop Ekosistemindeki birçok araçla entegrasyona sahiptir . API'leri çağırabilir, Kafka, FTP, birçok dosya sistemi ve bulut depolama ile entegre edebilirsiniz. Yönlendirme, filtreleme ve temel ETL gerçekleştiren veri akışını yönetebilirsiniz. Bazı kullanım durumları için ihtiyacınız olan tek şey NiFi olabilir.
Ancak, kümedeki 10 düğümden fazla düğümler arası iletişim nedeniyle NiFi belirli bir noktanın ötesine ölçeklenemez. Dikey olarak daha iyi ölçeklendirme eğilimindedir, ancak özellikle karmaşık ETL için sınırına ulaşabilirsiniz. Ancak, verileri işlemek için Spark gibi araçlarla entegre edebilirsiniz. NiFi, verilerinizi almak ve zenginleştirmek için harika bir araçtır.
Druid veya Pinot gibi modern OLAP motorları ayrıca toplu iş ve akış verilerinin otomatik olarak alınmasını sağlar, bunlardan başka bir bölümde bahsedeceğiz.
Ayrıca , pahalı hesaplamalar olmadıkları veya sınırlı bağlamı geçmedikleri sürece, alım sırasında bazı ilk doğrulama ve veri temizliği yapabilirsiniz, boş bir alanın sizinle alakasız olabileceğini ancak başka bir ekip için önemli olabileceğini unutmayın.
Son adım, verileri nereye yerleştireceğimize karar vermek, bunun hakkında zaten konuştuk. Bir veritabanı veya derin bir depolama sistemi kullanabilirsiniz. Bir veri gölü için, bunu HDFS'de saklamak yaygındır, format sonraki adıma bağlı olacaktır; Satır düzeyinde işlemler yapmayı planlıyorsanız, Avro harika bir seçenektir. Avro ayrıca , beslenen verileriniz için şemayı nispeten kolay bir şekilde değiştirmenize olanak tanıyan harici bir kayıt defteri kullanarak şema gelişimini destekler .
Verilerinizi depoladıktan sonraki adım, meta verilerini (verilerin kendisiyle ilgili bilgiler) kaydetmektir. En yaygın meta veriler şemadır . Harici bir meta veri deposu kullanarak, veri gölünüzdeki veya veri ardışık düzeninizdeki farklı araçlar, veri şemasını çıkarmak için onu sorgulayabilir.
Avro'yu ham veriler için kullanıyorsanız , harici kayıt defteri iyi bir seçenektir. Bu şekilde yutmanın işlemden kolayca ayrılmasını sağlayabilirsiniz.
Veriler alındıktan sonra, OLAP motorları tarafından sorgulanmak için SQL DDL kullanmak çok yaygındır . Hadoop ekosisteminde en çok kullanılan veri göl / veri ambarı aracı Apache Hive , sen tanımlanmış bir şemaya bir veri depo gibi veri göl kullanabilmesi için bir meta veri deposu sağlar. Hive üzerinde SQL sorguları çalıştırabilir ve Spark gibi diğer birçok aracı Spark SQL kullanarak SQL sorguları çalıştırmak için bağlayabilirsiniz . Hive, Hadoop ekosisteminde analitik sorgularınız için merkezi bir meta veritabanı sağlayan önemli bir araçtır . Apache Tajo gibi diğer araçlar , veri gölünüzde veri ambarlama yetenekleri sağlamak için Hive'ın üzerine inşa edilmiştir.
Apache Impala ,Hadoop için meta veri deposu sağlayanyerel bir analitik veritabanıdır , yine de Hcatalog kullanarak meta veriler için Hive'a bağlanabilirsiniz .
Apache Phoenix'in ayrıca bir meta deposu vardır ve Hive ile çalışabilir. Phoenix, işlemlere ACID özellikli sorgular sağlayan OLTP'ye odaklanır. Esnekdir ve destek deposu olarak HBase'den yararlanarak NoSQL dünyasından şema okuma yetenekleri sağlar. Apache Druid veya Pinot ayrıca meta veri deposu sağlar.
Bu aşamanın amacı , verileri tek bir şema kullanarak temizlemek, normalleştirmek, işlemek ve kaydetmektir. Sonuç, iyi tanımlanmış bir şemaya sahip güvenilir bir veri kümesidir.
Genel olarak, aşağıdaki gibi bir tür işlem yapmanız gerekir:
Ardışık düzen işleme, toplu işlem durumunda üç aşamaya ayrılabilir :
İşleme Çerçeveleri
İşleme için kullanabileceğiniz araçlardan bazıları şunlardır:
Veri hattı düzenlemesi, diğer tüm görevler arasındaki bağımlılıkları yöneten kesişen bir süreçtir. Akış işlemeyi kullanıyorsanız, her akış uygulamasının bağımlılıklarını toplu olarak düzenlemeniz gerekir, işleri planlamanız ve düzenlemeniz gerekir.
Görevler ve uygulamalar başarısız olabilir, bu nedenle tüm veri ardışık düzeninizi birleşik bir şekilde planlamak , yeniden planlamak , yeniden yürütmek , izlemek , yeniden denemek ve hatalarını ayıklamak için bir yönteme ihtiyacınız vardır.
Dagster veya Prefect gibi daha yeni çerçeveler, daha fazla yetenek ekler ve veri varlıklarını, ardışık düzeninize anlamsallık ekleyerek izlemenize olanak tanır.
Bazı seçenekler şunlardır:
Büyük Veride genellikle göz ardı edilen önemli bir husus, veri kalitesi ve güvencesidir. Veri kalitesi sorunları nedeniyle şirketler her yıl tonlarca para kaybediyor. Sorun şu ki, bu veri biliminde henüz olgunlaşmamış bir alan, geliştiriciler bu alanda onlarca yıldır çalışıyorlar ve BDD veya TDD gibi harika test çerçevelerine ve metodolojilerine sahipler , ancak ardışık düzeninizi nasıl test edersiniz?
Bu alanda iki yaygın sorun vardır:
Bu sorunu azaltmak için, DDD ilkelerini takip etmeye çalışın ve sınırların belirlendiğinden ve ortak bir dil kullanıldığından emin olun. NiFi veya Dagster gibi veri kökenini destekleyen çerçeveler kullanın.
Veri kalitesine odaklanan bazı araçlar şunlardır:
Artık pişmiş tarifinize sahip olduğunuza göre, nihayet ondan değeri almanın zamanı geldi. Bu noktaya kadar, verilerinizi veri gölünüzde HDFS gibi bazı derin depolamayı kullanarak Parquet gibi sorgulanabilir bir formatta veya bir OLAP veritabanında depolamış olursunuz .
Verileri sorgulamak için kullanılan çok çeşitli araçlar vardır, her birinin avantajları ve dezavantajları vardır. Çoğu OLAP'a odaklandı, ancak birkaçı da OLTP için optimize edildi. Bazıları standart biçimleri kullanır ve yalnızca sorguları çalıştırmaya odaklanırken, diğerleri performansı artırmak için işlemeyi kaynağa göndermek için kendi biçimlerini / depolamalarını kullanır. Bazıları yıldız veya kar tanesi şeması kullanılarak veri ambarlama için optimize edilirken diğerleri daha esnektir. Özetlemek gerekirse, farklı hususlar şunlardır:
Önceki bölümde anlattığımız motorların çoğu, Hive gibi meta veri sunucusuna bağlanabilir ve sorgular çalıştırabilir, görünümler oluşturabilir, vb. Bu, iyileştirilmiş raporlama katmanları oluşturmak için yaygın bir kullanım durumudur.
Spark SQL , SQL sorgularını Spark programlarıyla sorunsuz bir şekilde karıştırmanın bir yolunu sağlar, böylece DataFrame API'sini SQL ilekarıştırabilirsiniz. JDBC veya ODBC aracılığıyla Hive entegrasyonuna ve standart bağlantıya sahiptir; Böylece Tableau , Looker veya herhangi bir BI aracını Spark aracılığıyla verilerinizebağlayabilirsiniz.
Apache Flink ayrıca SQL API sağlar. Flink'in SQL desteği, SQL standardını uygulayan Apache Calcite'a dayanmaktadır . Aynı zamanda entegre Hive aracılığıyla
HiveCatalog. Örneğin, kullanıcılar Kafka veya ElasticSearch tablolarını kullanarak Hive Metastore'da depolayabilir
HiveCatalogve daha sonra bunları SQL sorgularında yeniden kullanabilir.
Bu tür araçlar, farklı veri kaynaklarını ve biçimlerini birleşik bir şekilde sorgulamaya odaklanır . Buradaki fikir, veri gölünüzü ilişkisel bir veritabanı gibi SQL sorguları kullanarak sorgulamaktır, ancak bazı sınırlamaları vardır. Bu araçlardan bazıları NoSQL veritabanlarını ve çok daha fazlasını sorgulayabilir . Bu araçlar , veri gölünüze güvenli bir şekilde bağlanmak için Tableau veya Looker gibi harici araçlar için bir JDBC arayüzü sağlar . Sorgu motorları en yavaş seçenektir ancak maksimum esneklik sağlar.
Hadoop, OLAP için optimize edilmiş olsa da, etkileşimli bir uygulama için OLTP sorguları gerçekleştirmek istiyorsanız yine de bazı seçenekler vardır.
HBase , ölçeklendirmek için yapıldığından ve kutudan ACID yetenekleri sağlamadığından, tasarım gereği çok sınırlı ACID özelliklerine sahiptir, ancak bazı OLTP senaryoları için kullanılabilir.
Apache Phoenix , HBase üzerine inşa edilmiştir ve Hadoop ekosisteminde OTLP sorgularını gerçekleştirmek için bir yol sağlar. Apache Phoenix; Spark, Hive, Pig, Flume ve Map Reduce gibi diğer Hadoop ürünleriyle tamamen entegredir. Ayrıca meta verileri depolayabilir ve DDL komutları aracılığıyla tablo oluşturmayı ve sürümlü artımlı değişiklikleri destekler. Oldukça hızlıdır , Drill veya diğer sorgu motorlarından daha hızlıdır.
OTLP için Cassandra, YugaByteDB, ScyllaDB gibi Hadoop ekosisteminin dışında herhangi bir büyük ölçekli veritabanını kullanabilirsiniz .
Son olarak, MongoDB veya MySQL gibi herhangi bir türden hızlı bir veritabanında genellikle en yeni olan bir veri alt kümesine sahip olmak çok yaygındır. Sorgu motorları yukarıda belirtilen tek bir sorgu yavaş ve hızlı veri depolama arasında veri katılabilir.
Bu araçlar, yapılandırılmamış metin verilerini depolamak ve aramak için bir yol sağlar ve verileri depolamak için özel yapılara ihtiyaç duyduklarından Hadoop ekosisteminin dışında yaşarlar. Buradaki fikir, hızlı aramalar gerçekleştirmek için tersine çevrilmiş bir dizin kullanmaktır . Metin aramanın yanı sıra bu teknoloji, günlükleri, olayları vb. Depolamak gibi çok çeşitli kullanım durumları için kullanılabilir. İki ana seçenek vardır:
Analitik için de kullanılabilir ; Verilerinizi dışa aktarabilir, dizine ekleyebilir ve ardından Kibana'yı kullanarak sorgulayabilir , gösterge tabloları, raporlar ve çok daha fazlasını oluşturabilir, histogramlar, karmaşık toplamalar ekleyebilir ve hatta verilerinizin üzerine makine öğrenimi algoritmaları çalıştırabilirsiniz. Esnek Ekosistem çok büyük ve keşfedilmeye değer.
Bu kategoride, şemalar ve sorgu yetenekleri için bir meta veri deposu da sağlayabilen veritabanlarımız vardır. Sorgu motorlarıyla karşılaştırıldığında, bu araçlar ayrıca depolama sağlar ve veri ambarları (yıldız şeması) durumunda belirli şemaları uygulayabilir. Bu araçlar SQL sözdizimini kullanır ve Spark ve diğer çerçeveler onlarla etkileşim kurabilir.
Bu kategoriye, hepsi bir arada bir analitik platformu oluşturarak daha fazla işlevsellik sağlayan önceki OLAP veritabanlarının bir evrimi olan daha yeni motorları dahil ediyorum . Aslında, OLAP veritabanlarınıza indeksleme ekleyen önceki iki kategorinin melezidirler . Hadoop platformunun dışında yaşıyorlar ancak sıkı bir şekilde bütünleşmişler. Bu durumda, genellikle işleme aşamasını atlar ve bu araçları kullanarak doğrudan beslersiniz.
Gerçek zamanlı ve geçmiş verileri sorgulama sorununu tek tip bir şekilde çözmeye çalışırlar , böylece gerçek zamanlı verileri kullanılabilir olur olmaz, düşük gecikmeyle geçmiş verilerle birlikte anında sorgulayabilir, böylece etkileşimli uygulamalar ve gösterge tabloları oluşturabilirsiniz. Bu araçlar, çoğu durumda ham verileri ELT tarzında neredeyse hiç dönüşüm olmadan sorgulama, ancak normal OLAP veritabanlarından daha iyi bir performansla sorgulama olanağı sağlar .
What they have in common is that they provided a unified view of the data, real time and batch data ingestion, distributed indexing, its own data format, SQL support, JDBC interface, hot-cold data support, multiple integrations and a metadata store.
Finally, Greenplum is another OLAP engine with more focus on AI.
Finally, for visualization you have several commercial tools such Qlik, Looker or Tableau. For Open Source, check SuperSet, an amazing tool that support all the tools we mentioned, has a great editor and it is really fast. Metabase or Falcon are other great options.
We have talked a lot about data: the different shapes, formats, how to process it, store it and much more. Remember: Know your data and your business model. Use an iterative process and start building your big data platform slowly; not by introducing new frameworks but by asking the right questions and looking for the best tool which gives you the right answer.
Review the different considerations for your data, choose the right storage based on the data model (SQL), the queries(NoSQL), the infrastructure and your budget. Remember to engage with your cloud provider and evaluate cloud offerings for big data(buy vs. build). It is very common to start with a Serverless analysis pipeline and slowly move to open source solutions as costs increase.
Data Ingestion is critical and complex due to the dependencies to systems outside of your control; try to manage those dependencies and create reliable data flows to properly ingest data. If possible have other teams own the data ingestion. Remember to add metrics, logs and traces to track the data. Enable schema evolution and make sure you have setup proper security in your platform.
Use the right tool for the job and do not take more than you can chew. Tools like Cassandra, Druid or ElasticSearch are amazing technologies but require a lot of knowledge to properly use and manage. If you just need to OLAP batch analysis for ad-hoc queries and reports, use Hive or Tajo. If you need better performance, add Kylin. If you also need to join with other data sources add query engines like Drill or Presto. Furthermore, if you need to query real time and batch use ClickHouse, Druid or Pinot.
Feel free to get in touch if you have any questions or need any advice.
I hope you enjoyed this article. Feel free to leave a comment or share this post. Follow me for future post.
Vakumlama, PostgreSQL'de yer kazanmaya ve performansı artırmaya yardımcı olan önemli bir bakım görevidir. Bu yazıda, vakumlamanın ne olduğunu, neden gerekli olduğunu ve PostgreSQL 13'te nasıl gerçekleştirileceğini tartışacağız.
Makale, OLAP ve OLTP sistemlerinin kısa bir açıklamasına odaklanır ve amaç, işlem süreleri, veri kaynağı vb. açısından birbirlerinden nasıl farklı olduklarını araştırır. Her şeyden önce, OLAP ve OLTP sistemleri nelerdir? Veri İşleme sistemleri.
MIT Seçim Laboratuvarı'nda yüksek lisans araştırmacısı ve doktora derecesi olan Jesse Clark tarafından yazılmıştır.
Oakland, CA'da halka açık verileri kullanarak hava kalitesini tahmin etmek Google ve EDF, Oakland'daki hava kirliliğini haritalama çalışmalarını yayınladığında, bu çalışmanın sonuçları büyük ilgi gördü. Yayınladıkları veriler, hava kalitesinin Doğu ve Batı Oakland'daki şehir bloklarına göre nasıl değiştiğini gösteren ilk veri kümelerinden biriydi.
Daniel Fleck ve David Lubert ile yazılmıştır Dizimizin ilk blogu, bir veri bilimi projesini uygun şekilde değerlendirmek için Net Şimdiki Değer (NPV), İç Getiri Oranı (IRR) ve Karlılık Endeksi'ni (PI) kullanmaya odaklanacaktır. Ayrıca, bir veri bilimi metodolojisinin kullanılmasının, bu aynı ekonomik ölçütlerin girdilerini daha yüksek kaliteli değerlendirmeler geliştirmek için nasıl daha da iyileştirebileceğini tartışacağız.
Öz bileşimi ve SVD için yararlı olan doğrusal cebir temel kavramını anlayın Bu makalede, öz ayrıştırma veya tekil değer ayrıştırma (SVD) gibi matris çarpanlara ayırma yöntemlerini anlamanın ilginç bir yolu olan temel kavramını öğreneceksiniz. Tanımlar Temel, vektör uzaylarını (vektör setleri) tanımlamak için kullanılan bir koordinat sistemidir.