Birkaç hazır açık kaynaklı aracı hızlı ve kolay bir şekilde bağlayabileceğiniz, bunları "çoklu harflere" girmeden, yığın akışı tavsiyelerine göre "bilinciniz kapalı" olarak ayarlayabileceğiniz ve başlatabileceğiniz harika bir zamanda yaşıyoruz. ticari işletmeye alırlar. Güncellemeniz/genişletmeniz gerektiğinde veya birisi birkaç makineyi yanlışlıkla yeniden başlattığında - bir tür takıntılı kötü rüyanın başladığını, her şeyin tanınmayacak kadar dramatik bir şekilde karmaşık hale geldiğini, geri dönüşün olmadığını, geleceğin belirsiz ve daha güvenli olduğunu fark edersiniz. programlamak yerine arı yetiştirin ve peynir yapın.
Kafaları böceklerle dolu ve bu nedenle zaten gri olan daha deneyimli meslektaşların, yerleşik destekle "moda dillerde" düzinelerce sunucuda "küpler" halinde "konteyner" paketlerinin inanılmaz derecede hızlı konuşlandırılmasını düşünmeleri boşuna değil. asenkron, engellemeyen G/Ç, alçakgönüllü bir şekilde gülümseyin. Ve sessizce "man ps"yi yeniden okumaya, gözleri kanayana kadar "nginx" kaynak kodunu araştırmaya ve birim testleri yazmaya, yazmaya, yazmaya devam ediyorlar. Meslektaşları biliyor ki en ilginç şey, "tüm bunların" bir gün yılbaşı gecesinde riske atılmasıyla ortaya çıkacak. Ve onlara yalnızca unix'in doğasının, ezberlenmiş TCP/IP durum tablosunun ve temel sıralama-arama algoritmalarının derinlemesine anlaşılmasıyla yardımcı olunacaktır. Çanlar çaldıkça sistemi hayata döndürmek.
Ah evet, biraz dikkatim dağıldı ama umarım beklenti durumunu aktarmayı başarabilmişimdir.
Bugün, tamamen farklı yapısal bölümler için şirketteki analitik görevlerin çoğunu çözen DataLake için kullanışlı ve ucuz bir yığının dağıtımına ilişkin deneyimimizi paylaşmak istiyorum.
Bir süre önce, şirketlerin hem ürün hem de teknik analitiğin meyvelerine (makine öğrenimi şeklindeki pastanın kremasından bahsetmeye bile gerek yok) ve trendleri ve riskleri anlamak için giderek daha fazla ihtiyaç duyduğunu anlamaya başladık; bunları toplayıp analiz etmemiz gerekiyor. gittikçe daha fazla ölçüm.
Bitrix24'te temel teknik analizler
Birkaç yıl önce, Bitrix24 hizmetinin piyasaya sürülmesiyle eş zamanlı olarak, altyapıdaki sorunları hızlı bir şekilde görmenize ve bir sonraki adımı planlamanıza yardımcı olacak basit ve güvenilir bir analitik platform oluşturmak için aktif olarak zaman ve kaynak yatırımı yaptık. Elbette olabildiğince basit ve anlaşılır hazır araçların alınması tavsiye edildi. Sonuç olarak izleme için nagios, analiz ve görselleştirme için ise munin seçildi. Artık nagios'ta binlerce çekimiz, munin'de yüzlerce haritamız var ve meslektaşlarımız bunları her gün başarıyla kullanıyor. Ölçüler açık, grafikler açık, sistem birkaç yıldır güvenilir bir şekilde çalışıyor ve düzenli olarak yeni testler ve grafikler ekleniyor: yeni bir hizmeti devreye aldığımızda birkaç test ve grafik ekliyoruz. İyi şanlar.
Nabızdaki Parmak - İleri Teknik Analitik
Sorunlar hakkında "mümkün olduğu kadar çabuk" bilgi alma arzusu, bizi basit ve anlaşılır araçlarla (pinba ve xhprof) aktif deneylere yöneltti.
Pinba bize UDP paketleri halinde, PHP'deki web sayfalarının bazı bölümlerinin çalışma hızı hakkında istatistikler gönderdi ve biz de çevrimiçi olarak MySQL deposunda (Pinba, hızlı olay analitiği için kendi MySQL motoruyla birlikte gelir) sorunların kısa bir listesini görebilir ve bunlara yanıt verebiliriz. onlara. Ve xhprof otomatik olarak istemcilerden en yavaş PHP sayfalarının yürütülmesine ilişkin grafikleri toplamamıza ve buna neyin yol açabileceğini analiz etmemize olanak tanıdı - sakince, çay dökmek veya daha güçlü bir şey.
Bir süre önce araç seti, efsanevi Lucene kütüphanesinde - Elastic/Kibana - mükemmel bir şekilde uygulanan, ters indeksleme algoritmasına dayanan oldukça basit ve anlaşılır başka bir motorla dolduruldu. Günlüklerdeki olaylara dayalı olarak belgelerin ters Lucene indeksine çok iş parçacıklı olarak kaydedilmesi ve faset bölümü kullanılarak bunlar arasında hızlı bir arama yapılması gibi basit bir fikrin gerçekten faydalı olduğu ortaya çıktı.
Kibana'daki görselleştirmelerin "kova", "yukarı doğru akan" gibi düşük seviyeli kavramları içeren oldukça teknik görünümüne ve henüz tamamen unutulmamış ilişkisel cebirin yeniden keşfedilen diline rağmen, araç aşağıdaki görevlerde bize oldukça yardımcı olmaya başladı:
- Son bir saat içinde Bitrix24 istemcisinin p1 portalında kaç PHP hatası oluştu ve hangileri? Anlayın, affedin ve hızla düzeltin.
- Son 24 saat içinde Almanya'daki portallarda kaç görüntülü görüşme yapıldı, hangi kalitede ve kanalda/ağda herhangi bir sorun yaşandı mı?
- En son hizmet güncellemesinde kaynaktan derlenen ve istemcilere sunulan sistem işlevselliği (PHP için C uzantımız) ne kadar iyi çalışıyor? Segfault'lar var mı?
- Müşteri verileri PHP belleğine sığıyor mu? İşlemlere ayrılan belleğin aşılmasıyla ilgili herhangi bir hata var mı: “bellek yetersiz”? Bul ve etkisiz hale getir.
İşte somut bir örnek. Kapsamlı ve çok seviyeli testlere rağmen, oldukça standart olmayan bir duruma ve hasarlı giriş verilerine sahip müşteri, can sıkıcı ve beklenmedik bir hata aldı, bir siren çaldı ve hızlı bir şekilde düzeltme süreci başladı:
Ayrıca kibana, belirli etkinlikler için bildirimler düzenlemenize olanak tanır ve kısa sürede şirketteki araç, teknik destek ve geliştirmeden kalite güvenceye kadar farklı departmanlardan onlarca çalışan tarafından kullanılmaya başlandı.
Şirket içindeki herhangi bir departmanın faaliyeti takip ve ölçüm için uygun hale geldi; sunuculardaki günlükleri manuel olarak analiz etmek yerine, günlükleri ayrıştırma işlemini bir kez ayarlamanız ve örneğin kibana'da düşünmenin keyfini çıkarmak için bunları elastik kümeye göndermeniz yeterlidir. Son ay için 3 boyutlu yazıcıda basılan iki başlı kedi yavrularının satılan sayısını gösteren gösterge tablosu.
Temel İş Analitiği
Herkes şirketlerdeki iş analitiğinin genellikle Excel'in son derece aktif kullanımıyla başladığını bilir. Ama asıl önemli olan işin burada bitmemesi. Bulut tabanlı Google Analytics de yangını körüklüyor; iyi şeylere hızla alışmaya başlıyorsunuz.
Uyumlu bir şekilde gelişen şirketimizde, daha büyük verilerle daha yoğun çalışmanın “peygamberleri” yer yer ortaya çıkmaya başladı. Daha ayrıntılı ve çok yönlü raporlara olan ihtiyaç düzenli olarak ortaya çıkmaya başladı ve farklı departmanlardaki kişilerin çabalarıyla bir süre önce ClickHouse ve PowerBI'nin birleşimi olan basit ve pratik bir çözüm organize edildi.
Oldukça uzun bir süre boyunca bu esnek çözüm çok yardımcı oldu, ancak yavaş yavaş ClickHouse'un kauçuk olmadığı ve bu şekilde alay edilemeyeceği anlayışı oluşmaya başladı.
Burada ClickHouse'un, Druid gibi, Vertica gibi, Amazon RedShift (postgres'e dayalı) gibi, oldukça uygun analizler (toplamlar, toplamalar, sütun bazında minimum-maksimum ve birkaç olası birleştirme) için optimize edilmiş analitik motorlar olduğunu iyi anlamak önemlidir. ), Çünkü MySQL ve bildiğimiz diğer (satır odaklı) veritabanlarının aksine, ilişkisel tabloların sütunlarının verimli bir şekilde depolanması için düzenlenmiştir.
Temelde, ClickHouse, noktadan noktaya eklemeye pek uygun olmayan (bu şekilde tasarlandı, her şey yolunda), ancak hoş analizler ve verilerle çalışmak için bir dizi ilginç güçlü işlev içeren, yalnızca daha geniş bir "veritabanı" dır. Evet, bir küme bile oluşturabilirsiniz - ancak mikroskopla çivi çakmanın tamamen doğru olmadığını anlıyorsunuz ve başka çözümler aramaya başladık.
Python ve analistlere talep
Şirketimizde 10-20 yıldır neredeyse her gün PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash dillerinde kod yazan birçok geliştirici bulunmaktadır. Ayrıca, istatistik yasalarına uymayan, tamamen inanılmaz birden fazla felaketle karşılaşan birçok deneyimli sistem yöneticisi de vardır (örneğin, bir baskın-10'daki disklerin çoğunluğunun güçlü bir yıldırım çarpmasıyla yok edilmesi). Bu gibi durumlarda uzun bir süre “python analistinin” ne olduğu belli değildi. Python PHP gibidir, yalnızca adı biraz daha uzundur ve yorumlayıcının kaynak kodunda zihin değiştirici maddelerin izleri biraz daha azdır. Ancak giderek daha fazla analitik rapor oluşturuldukça deneyimli geliştiriciler, numpy, pandas, matplotlib, seaborn gibi araçlarda dar uzmanlığın önemini giderek daha fazla anlamaya başladı.
Belirleyici rol, büyük olasılıkla, çalışanların "lojistik regresyon" kelimelerinin birleşiminden ve evet, evet pyspark kullanılarak büyük veriler üzerinde etkili raporlamanın gösterilmesinden dolayı ani bayılmaları tarafından oynandı.
İlişkisel cebirin mükemmel uyum sağladığı fonksiyonel paradigma Apache Spark ve yetenekleri, MySQL'e alışkın geliştiriciler üzerinde öyle bir etki yarattı ki, deneyimli analistlerle safların güçlendirilmesi ihtiyacı gün geçtikçe netleşti.
Apache Spark/Hadoop'un daha fazla başarılı olma girişimleri ve senaryoya göre işler pek yolunda gitmedi
Ancak çok geçmeden Spark'ta sistematik olarak bir şeylerin yolunda gitmediği ya da ellerinizi daha iyi yıkamanız gerektiği ortaya çıktı. Hadoop/MapReduce/Lucene yığını oldukça deneyimli programcılar tarafından oluşturulduysa, Java'daki kaynak koduna veya Doug Cut'ın Lucene'deki fikirlerine yakından bakarsanız bu açıkça görülür, o zaman Spark aniden egzotik dil Scala'da yazılır. pratiklik açısından çok tartışmalı ve şu anda gelişmiyor. Ayrıca, azaltma işlemleri için bellek tahsisi ile mantıksız ve çok şeffaf olmayan çalışma (birçok anahtarın aynı anda gelmesi) nedeniyle Spark kümesindeki hesaplamalardaki düzenli düşüş, etrafında büyümek için yeri olan bir şeyin halesini yarattı. Buna ek olarak, durum çok sayıda garip açık bağlantı noktası, en anlaşılmaz yerlerde büyüyen geçici dosyalar ve çok sayıda jar bağımlılığı nedeniyle daha da kötüleşti; bu da sistem yöneticilerinin çocukluktan beri iyi bilinen bir duyguya sahip olmasına neden oldu: şiddetli nefret (veya belki de) ellerini sabunla yıkamaları gerekiyordu).
Sonuç olarak, Apache Spark'ı (Spark Streaming, Spark SQL dahil) ve Hadoop ekosistemini (vb. vb.) aktif olarak kullanan birçok dahili analitik projeden "hayatta kalmayı" başardık. Zamanla "onu" oldukça iyi hazırlamayı ve izlemeyi öğrenmiş olmamıza ve "o", verilerin doğasındaki değişiklikler ve tek tip RDD karmasının dengesizliği nedeniyle aniden çökmeyi durdurmasına rağmen, zaten hazır bir şeyi alma arzusu Bulutta bir yerde güncellenen ve yönetilen yazılım giderek daha da güçlendi. Bu sırada Amazon Web Services'in hazır bulut derlemesini kullanmaya çalıştık - ve daha sonra sorunları onu kullanarak çözmeye çalıştı. EMR, Cloudera/Hortonworks'ün derlemelerine benzer şekilde Amazon tarafından ekosistemden ek yazılımlarla hazırlanan Apache Spark'tır.
Analitik için kauçuk dosya depolama acil bir ihtiyaçtır
Hadoop/Spark'ı vücudun çeşitli yerlerinde yanıklarla “pişirme” deneyimi boşuna değildi. Donanım arızalarına karşı dayanıklı, farklı sistemlerden farklı formatlardaki dosyaları saklamanın ve bu verilerden raporlar için verimli ve zaman tasarrufu sağlayan örnekler oluşturmanın mümkün olacağı tek, ucuz ve güvenilir bir dosya deposu oluşturma ihtiyacı giderek arttı. temizlemek.
Ayrıca Spark History Server ve arkadan aydınlatmalı bir büyüteç kullanarak 20 sayfalık Java trace'lerini okuyarak ve kümenin kilometrelerce detaylı loglarını analiz ederek bu platformun yazılımını güncellemenin yılbaşı kabusuna dönüşmemesini istedim. Geliştiricinin standart MapReduce isteğinin, çok iyi seçilmemiş bir kaynak veri bölümleme algoritması nedeniyle veri azaltma çalışanının belleği yetersiz kalması durumunda yürütmeyi durdurması durumunda, basit ve şeffaf bir araca sahip olmak istedim.
Amazon S3 DataLake'e aday mı?
Hadoop/MapReduce deneyimimiz bize, verileri ağ üzerinden yönlendirmemek için ölçeklenebilir, güvenilir bir dosya sistemine ve bunun üzerine verilere "yaklaşan" ölçeklenebilir çalışanlara ihtiyacımız olduğunu öğretti. Çalışanlar farklı formatlardaki verileri okuyabilmeli, ancak tercihen gereksiz bilgileri okumamalı ve verileri çalışanlar için uygun formatlarda önceden depolayabilmelidir.
Bir kez daha temel fikir. Büyük verileri tek bir küme analitik motoruna "dökme" arzusu yoktur; bu, er ya da geç boğulacaktır ve onu çirkin bir şekilde parçalamak zorunda kalacaksınız. Dosyaları, sadece dosyaları anlaşılır bir formatta depolamak ve farklı ama anlaşılır araçlar kullanarak bunlar üzerinde etkili analitik sorgular gerçekleştirmek istiyorum. Ve farklı formatlarda giderek daha fazla dosya olacak. Ve motoru değil kaynak verileri parçalamak daha iyidir. Genişletilebilir ve evrensel bir DataLake'e ihtiyacımız var, karar verdik...
Hadoop'tan kendi pirzolalarınızı hazırlamak zorunda kalmadan, dosyalarınızı tanıdık ve iyi bilinen ölçeklenebilir bulut depolama alanı Amazon S3'te saklarsanız ne olur?
Kişisel verilerin "düşük" olduğu açık, ancak bunları ortaya çıkarır ve "etkili bir şekilde kullanırsak" diğer veriler ne olacak?
Amazon Web Services'in küme-büyük veri-analitiği ekosistemi - çok basit bir ifadeyle
AWS ile olan deneyimimize bakılırsa Apache Hadoop/MapReduce uzun süredir çeşitli soslar altında aktif olarak kullanılıyor, örneğin DataPipeline hizmetinde (meslektaşlarımı kıskanıyorum, nasıl doğru şekilde hazırlanacaklarını öğrendiler). Burada DynamoDB tablolarından farklı hizmetlerden yedeklemeler ayarlıyoruz:
Ve birkaç yıldır yerleşik Hadoop/MapReduce kümeleri üzerinde düzenli olarak çalışıyorlar. “Ayarlayın ve unutun”:
Ayrıca analistler için bulutta Jupiter dizüstü bilgisayarlar kurarak ve yapay zeka modellerini savaşta eğitmek ve dağıtmak için AWS SageMaker hizmetini kullanarak veri satanizmine etkili bir şekilde girişebilirsiniz. Bizim için şöyle görünüyor:
Ve evet, kendiniz veya buluttaki bir analist için bir dizüstü bilgisayar alıp onu bir Hadoop/Spark kümesine bağlayabilir, hesaplamaları yapabilir ve ardından her şeyi halledebilirsiniz:
Bireysel analitik projeler için gerçekten kullanışlıdır ve bazılarında büyük ölçekli hesaplamalar ve analizler için EMR hizmetini başarıyla kullandık. DataLake için bir sistem çözümüne ne dersiniz, işe yarayacak mı? Şu anda umudun ve umutsuzluğun eşiğindeydik ve aramaya devam ettik.
AWS Glue - steroidler üzerinde özenle paketlenmiş Apache Spark
AWS'nin "Hive/Pig/Spark" yığınının kendi sürümüne sahip olduğu ortaya çıktı. Hive'ın rolü, yani. DataLake'teki dosyaların ve türlerinin kataloğu, Apache Hive formatıyla uyumluluğunu gizlemeyen "Veri kataloğu" hizmeti tarafından gerçekleştirilir. Bu servise dosyalarınızın nerede bulunduğu ve hangi formatta olduğu bilgisini eklemeniz gerekmektedir. Veriler sadece s3'te değil veritabanında da olabilir ama bu yazının konusu bu değil. DataLake veri dizinimiz şu şekilde düzenlenmiştir:
Dosyalar kaydedildi, harika. Dosyalar güncellendiyse, tarayıcıları manuel olarak veya bir programa göre başlatırız, bu da onlar hakkındaki bilgileri gölden günceller ve kaydeder. Daha sonra gölden gelen veriler işlenebilir ve sonuçlar bir yere yüklenebilir. En basit durumda s3'e de yükleme yapıyoruz. Veri işleme her yerde yapılabilir ancak AWS Glue API aracılığıyla gelişmiş yetenekleri kullanarak işlemeyi bir Apache Spark kümesinde yapılandırmanız önerilir. Aslında, pyspark kitaplığını kullanarak eski ve tanıdık python kodunu alabilir ve Hadoop'un derinliklerine inmeden ve docker-moker konteynerlerini sürüklemeden ve bağımlılık çatışmalarını ortadan kaldırmadan, izleme ile belirli bir kapasiteye sahip bir kümenin N düğümleri üzerinde yürütülmesini yapılandırabilirsiniz. .
Yine basit bir fikir. Apache Spark'ı yapılandırmanıza gerek yoktur; yalnızca pyspark için python kodu yazmanız, bunu masaüstünüzde yerel olarak test etmeniz ve ardından kaynak verinin nerede olduğunu ve sonucu nereye koyacağınızı belirterek buluttaki büyük bir kümede çalıştırmanız yeterlidir. Bazen bu gerekli ve faydalıdır; bunu şu şekilde ayarlıyoruz:
Bu nedenle, s3'teki verileri kullanarak Spark kümesinde bir şey hesaplamanız gerekiyorsa, python/pyspark'ta kod yazıp test ediyoruz ve buluta iyi şanslar diliyoruz.
Peki orkestrasyon? Peki ya görev düşüp kaybolursa? Evet, Apache Pig tarzında güzel bir ardışık düzen oluşturulması önerildi ve hatta bunları denedik, ancak şimdilik PHP ve JavaScript'te derinlemesine özelleştirilmiş düzenlememizi kullanmaya karar verdik (anlıyorum, bilişsel uyumsuzluk var, ancak işe yarıyor, çünkü) yıl ve hatasız).
Gölde depolanan dosyaların formatı performansın anahtarıdır
İki önemli noktayı daha anlamak çok ama çok önemlidir. Lake'deki dosya verilerine ilişkin sorguların olabildiğince hızlı yürütülmesi ve yeni bilgiler eklendiğinde performansın düşmemesi için şunları yapmanız gerekir:
- Dosya sütunlarını ayrı ayrı saklayın (böylece sütunlarda ne olduğunu anlamak için tüm satırları okumak zorunda kalmazsınız). Bunun için sıkıştırmalı parke formatını aldık
- Dosyaları dil, yıl, ay, gün, hafta gibi klasörlere bölmek çok önemlidir. Bu tür parçalamayı anlayan motorlar, tüm verileri arka arkaya elemeden yalnızca gerekli klasörlere bakacaktır.
Temel olarak, bu şekilde, parçalanmış klasörlerde bile dosyalardan yalnızca gerekli sütunları seçici olarak girebilen ve okuyabilen, üstte asılı analitik motorlar için kaynak verileri en verimli biçimde düzenlersiniz. Verileri herhangi bir yerde "doldurmanıza" gerek yok (depolama alanı patlayacak) - yalnızca akıllıca bir şekilde dosya sistemine doğru formatta yerleştirmeniz yeterli. Elbette burada, sütunları çıkarmak için önce küme tarafından satır satır okunması gereken devasa bir csv dosyasını DataLake'te saklamanın pek tavsiye edilmediği açık olmalıdır. Tüm bunların neden olduğu henüz net değilse, yukarıdaki iki noktayı tekrar düşünün.
AWS Athena - kullanıma hazır ürün
Ve sonra bir göl oluştururken bir şekilde tesadüfen Amazon Athena'ya rastladık. Birdenbire, büyük günlük dosyalarımızı doğru (parke) sütun formatında klasör parçaları halinde dikkatlice düzenleyerek, bunlardan çok hızlı bir şekilde son derece bilgilendirici seçimler yapabileceğiniz ve bir Apache Spark/Glue kümesi olmadan OLMADAN raporlar oluşturabileceğiniz ortaya çıktı.
S3'teki verilerle desteklenen Athena motoru, efsanevi - s3 ve Hadoop'tan Cassandra'ya ve sıradan metin dosyalarına kadar verileri bulunduğu yerden alan, veri işlemeye yönelik MPP (masif paralel işleme) yaklaşım ailesinin bir temsilcisi. Athena'dan bir SQL sorgusu yürütmesini istemeniz yeterli; ardından her şey "hızlı ve otomatik olarak çalışır." Athena'nın "akıllı" olduğunu, yalnızca gerekli parçalanmış klasörlere gittiğini ve yalnızca istekte gereken sütunları okuduğunu unutmamak önemlidir.
Athena'ya yapılan taleplerin fiyatlandırması da ilgi çekici. Biz ödüyoruz . Onlar. dakika başına kümedeki makine sayısı için değil,... aslında 100-500 makinede taranan veriler için, yalnızca isteği tamamlamak için gereken veriler.
Ve doğru şekilde parçalanmış klasörlerden yalnızca gerekli sütunları talep ettiğimizde, Athena hizmetinin bize ayda onlarca dolara mal olduğu ortaya çıktı. Kümelerdeki analizlerle karşılaştırıldığında harika, neredeyse ücretsiz!
Bu arada, s3'te verilerimizi şu şekilde parçalıyoruz:
Sonuç olarak, kısa sürede, bilgi güvenliğinden analitiklere kadar şirketin tamamen farklı departmanları Athena'ya aktif olarak talepte bulunmaya ve oldukça uzun süreler boyunca, saniyeler içinde, hızlı bir şekilde "büyük" verilerden yararlı yanıtlar almaya başladı: aylar, yarım yıl vb. P.
Ancak daha da ileri gittik ve yanıtlar için buluta gitmeye başladık : Bir analist, tanıdık bir konsolda bir SQL sorgusu yazar; bu konsol, 100-500 makinede "bir kuruş karşılığında" verileri s3'e gönderir ve genellikle birkaç saniye içinde bir yanıt döndürür. Rahat. Ve hızlı. Hala inanamıyorum.
Sonuç olarak, verileri s3'te verimli bir sütunlu formatta ve makul bir şekilde klasörlere bölerek depolamaya karar verdikten sonra... DataLake'i ve hızlı ve ucuz bir analitik motorunu ücretsiz olarak aldık. Ve şirkette çok popüler oldu çünkü... SQL'i anlar ve kümeleri başlatma/durdurma/kurmaya kıyasla çok daha hızlı çalışır. "Peki sonuç aynıysa neden daha fazla ödeyesiniz ki?"
Athena'ya yapılan bir istek buna benzer. İstenirse elbette yeterli miktarda oluşturabilirsiniz , ancak kendimizi basit gruplandırmayla sınırlayacağız. İstemcinin birkaç hafta önce web sunucusu günlüklerinde hangi yanıt kodlarına sahip olduğunu görelim ve herhangi bir hata olmadığından emin olalım:
Bulgular
Uzun ama sancılı bir yol kat ederek, riskleri, karmaşıklık düzeyini ve destek maliyetini sürekli olarak yeterince değerlendirerek, DataLake ve analitik için hem hız hem de sahip olma maliyeti açısından bizi memnun etmekten asla vazgeçmeyen bir çözüm bulduk.
Şirketin tamamen farklı departmanlarının ihtiyaçlarına yönelik etkili, hızlı ve kullanımı ucuz bir DataLake oluşturmanın, hiç mimar olarak çalışmamış ve karelere nasıl kare çizileceğini bilmeyen deneyimli geliştiricilerin bile tamamen yetenekleri dahilinde olduğu ortaya çıktı. okları kullanın ve Hadoop ekosisteminden 50 terim öğrenin.
Yolculuğun başlangıcında kafam, açık ve kapalı yazılımın birçok vahşi hayvanat bahçesinden ve torunlara olan sorumluluk yükünün anlaşılmasından ayrılıyordu. Basit araçlarla DataLake'inizi oluşturmaya başlayın: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., geri bildirim toplayın ve gerçekleşen süreçlerin fiziğini derinlemesine anlayın. Her şey karmaşık ve karanlık - onu düşmanlara ve rakiplere verin.
Buluta gitmek istemiyorsanız ve açık kaynaklı projeleri desteklemekten, güncellemekten ve yamalamaktan hoşlanıyorsanız, Hadoop ve Presto'nun da bulunduğu ucuz ofis makinelerinde yerel olarak bizimkine benzer bir şema oluşturabilirsiniz. Önemli olan durup ilerlemek, saymak, basit ve net çözümler aramak değil ve her şey kesinlikle yoluna girecek! Herkese iyi şanslar ve tekrar görüşmek üzere!
Kaynak: habr.com