Biz bir neçə hazır açıq mənbə alətini tez və asanlıqla birləşdirə, onları stackoverflow-un məsləhətinə əsasən, “çox hərflərə” girmədən “şüurunuz söndürüldü” vəziyyətində quraşdıra bildiyiniz və işə sala biləcəyiniz heyrətamiz bir dövrdə yaşayırıq. onları kommersiya fəaliyyətinə. Və yeniləmək/genişləndirmək lazım olduqda və ya kimsə təsadüfən bir neçə maşını yenidən işə saldıqda - başa düşürsən ki, bir növ obsesif pis yuxu başlayıb, hər şey tanınmayacaq dərəcədə mürəkkəbləşib, geriyə dönüş yoxdur, gələcək qeyri-müəyyən və daha təhlükəsizdir, proqramlaşdırma yerinə arı yetişdirin və pendirlə məşğul olun.
Əbəs yerə deyil ki, daha təcrübəli həmkarlar, başları böcəklərlə səpələnmiş və buna görə də artıq boz, daxili dəstəyi ilə "moda dillərdə" onlarla serverdə "kublar" şəklində "konteynerlər" paketlərini inanılmaz sürətlə yerləşdirməyi düşünürlər. asinxron bloklanmayan I/O, təvazökarlıqla gülümsəyin. Və onlar səssizcə “man ps”-i yenidən oxumağa davam edir, gözləri qanana qədər “nginx” mənbə kodunu araşdırır və vahid testləri yazır, yazırlar, yazırlar. Həmkarlar bilirlər ki, ən maraqlı şey “bütün bunlar” bir gün Yeni il ərəfəsində gecələr bahalaşanda baş verəcək. Onlara yalnız unix-in mahiyyətini dərindən başa düşmək, yadda saxlanan TCP/IP vəziyyət cədvəli və əsas çeşidləmə-axtarış alqoritmləri kömək edəcək. Zənglər vuran kimi sistemi yenidən həyata qaytarmaq.
Bəli, bir az diqqətimi yayındırdım, amma ümid edirəm ki, gözlənti vəziyyətini çatdıra bildim.
Bu gün mən tamamilə fərqli struktur bölmələri üçün şirkətdə analitik tapşırıqların əksəriyyətini həll edən DataLake üçün rahat və ucuz stek yerləşdirmək təcrübəmizi bölüşmək istəyirəm.
Bir müddət əvvəl biz anladıq ki, şirkətlər həm məhsulun, həm də texniki analitikanın meyvələrinə getdikcə daha çox ehtiyac duyurlar (maşın öyrənmə formasında tortun üzərindəki buzlanmanı demirəm) və tendensiyaları və riskləri anlamaq üçün - toplayıb təhlil etməliyik. getdikcə daha çox göstərici.
Bitrix24-də əsas texniki analitika
Bir neçə il əvvəl, Bitrix24 xidmətinin istifadəyə verilməsi ilə eyni vaxtda biz infrastrukturdakı problemləri tez görməyə və növbəti addımı planlaşdırmağa kömək edəcək sadə və etibarlı analitik platformanın yaradılmasına fəal şəkildə vaxt və resurslar sərf etdik. Əlbəttə ki, mümkün qədər sadə və başa düşülən hazır alətlər götürmək məqsədəuyğun idi. Nəticədə monitorinq üçün nagios, analitika və vizuallaşdırma üçün isə munin seçildi. İndi nagiosda minlərlə çekimiz, munində yüzlərlə qrafikimiz var və həmkarlarımız hər gün onlardan uğurla istifadə edirlər. Metriklər aydındır, qrafiklər aydındır, sistem bir neçə ildir etibarlı işləyir və ona mütəmadi olaraq yeni testlər və qrafiklər əlavə olunur: yeni xidməti istifadəyə verəndə biz bir neçə test və qrafik əlavə edirik. Uğurlar.
Nəbzdə Barmaq - Qabaqcıl Texniki Analitika
Problemlər haqqında məlumatı "mümkün qədər tez" almaq istəyi bizi sadə və başa düşülən alətlər - pinba və xhprof ilə aktiv təcrübələrə apardı.
Pinba bizə PHP-də veb-səhifələrin hissələrinin işləmə sürəti ilə bağlı UDP paketlərində statistik məlumatlar göndərdi və biz MySQL yaddaşında onlayn olaraq görə bildik (Pinba sürətli hadisələrin analitikası üçün öz MySQL mühərriki ilə gəlir) problemlərin qısa siyahısını və onlara cavab verə bildik. onlar. Və xhprof avtomatik olaraq bizə müştərilərdən ən yavaş PHP səhifələrinin icrasının qrafiklərini toplamağa və buna nəyin səbəb ola biləcəyini təhlil etməyə imkan verdi - sakitcə, çay tökmək və ya daha güclü bir şey.
Bir müddət əvvəl alətlər dəsti əfsanəvi Lucene kitabxanasında - Elastic/Kibana-da mükəmməl şəkildə həyata keçirilən əks indeksləşdirmə alqoritminə əsaslanan başqa kifayət qədər sadə və başa düşülən mühərriklə tamamlandı. Jurnallardakı hadisələrə əsaslanan sənədlərin tərs Lucene indeksinə çox yivli qeyd edilməsi və faset bölgüsündən istifadə edərək onlar vasitəsilə sürətli axtarışın sadə ideyası həqiqətən faydalı oldu.
Kibanadakı vizualizasiyaların "yuxarıya doğru axan" "vədrə" kimi aşağı səviyyəli anlayışları və hələ tamamilə unudulmamış əlaqə cəbrinin yenidən ixtira edilmiş dili ilə kifayət qədər texniki görünüşünə baxmayaraq, alət bizə aşağıdakı tapşırıqlarda yaxşı kömək etməyə başladı:
- Bitrix24 müştərisində son bir saat ərzində p1 portalında neçə PHP səhvi olub və hansılar? Anlayın, bağışlayın və tez düzəldin.
- Əvvəlki 24 saat ərzində Almaniyada portallarda nə qədər videozəng edilib, hansı keyfiyyətlə və kanal/şəbəkə ilə bağlı hər hansı çətinlik olubmu?
- Ən son xidmət yeniləməsində mənbədən tərtib edilən və müştərilərə təqdim edilən sistem funksionallığı (PHP üçün C genişlənməsimiz) nə dərəcədə yaxşı işləyir? Səhvlər varmı?
- Müştəri məlumatları PHP yaddaşına uyğundurmu? Proseslərə ayrılmış yaddaşı aşmaqla bağlı hər hansı səhvlər varmı: “yaddaş yoxdur”? Tapın və zərərsizləşdirin.
Konkret misal. Hərtərəfli və çoxsəviyyəli sınaqlara baxmayaraq, çox qeyri-standart işi və zədələnmiş giriş məlumatları olan müştəri zəhlətökən və gözlənilməz bir səhv aldı, siren səsləndi və onu tez bir zamanda düzəltmə prosesi başladı:
Bundan əlavə, kibana müəyyən edilmiş hadisələr üçün bildirişlər təşkil etməyə imkan verir və qısa müddətdə şirkətdəki alət müxtəlif departamentlərdən - texniki dəstək və inkişafdan tutmuş QA-ya qədər onlarla işçi tərəfindən istifadə olunmağa başladı.
Şirkət daxilində hər hansı bir departamentin fəaliyyəti izləmək və ölçmək üçün əlverişli hala gəldi - serverlərdə qeydləri əl ilə təhlil etmək əvəzinə, sadəcə bir dəfə təhlil jurnallarını qurmaq və onları elastik klasterə göndərmək lazımdır, məsələn, kibanada fikirləşmək. tablosuna son ay ayı üçün 3-D printerdə çap edilmiş satılan iki başlı pişik balalarının sayı.
Əsas Biznes Analitikası
Hər kəs bilir ki, şirkətlərdə biznes analitikası çox vaxt Excel-in son dərəcə aktiv istifadəsi ilə başlayır. Amma əsas odur ki, bununla bitmir. Bulud əsaslı Google Analytics də yanğına yanacaq qatır - siz tez yaxşı şeylərə alışmağa başlayırsınız.
Ahəngdar şəkildə inkişaf edən şirkətimizdə burada və orada daha böyük məlumatlarla daha intensiv işləyən "peyğəmbərlər" görünməyə başladı. Daha dərin və çoxşaxəli hesabatlara ehtiyac müntəzəm olaraq ortaya çıxmağa başladı və müxtəlif departamentlərdən olan oğlanların səyləri ilə bir müddət əvvəl sadə və praktik bir həll təşkil edildi - ClickHouse və PowerBI birləşməsi.
Uzun müddətdir ki, bu çevik həll çox kömək etdi, lakin tədricən ClickHouse-un rezin olmadığı və bu şəkildə istehza edilə bilməyəcəyi anlaşılmağa başladı.
Burada yaxşı başa düşmək lazımdır ki, ClickHouse, Druid kimi, Vertica kimi, Amazon RedShift (postgres-ə əsaslanır) kimi kifayət qədər rahat analitika (cəmlər, toplamalar, sütun üzrə minimum-maksimum və bir neçə mümkün birləşmə) üçün optimallaşdırılmış analitik mühərriklərdir. ), çünki MySQL və bizə məlum olan digər (sətir yönümlü) verilənlər bazalarından fərqli olaraq, əlaqəli cədvəllərin sütunlarının səmərəli saxlanması üçün təşkil edilmişdir.
Əslində, ClickHouse sadəcə olaraq daha tutumlu “verilənlər bazasıdır” və çox da rahat olmayan nöqtə-nöqtədir (belə nəzərdə tutulub, hər şey qaydasındadır), lakin xoş analitika və verilənlərlə işləmək üçün maraqlı güclü funksiyalar toplusudur. Bəli, hətta bir çoxluq yarada bilərsiniz - ancaq mikroskopla dırnaqları döymək tamamilə düzgün olmadığını başa düşürsünüz və biz başqa həll yolları axtarmağa başladıq.
Python və analitiklərə tələbat
Şirkətimizin PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash dillərində demək olar ki, hər gün 10-20 il ərzində kod yazan bir çox developerləri var. Statistikanın qanunlarına uyğun gəlməyən birdən çox tamamilə inanılmaz fəlakətlə üzləşmiş bir çox təcrübəli sistem administratoru da var (məsələn, reyd-10-da disklərin əksəriyyəti güclü ildırım vurması nəticəsində məhv edildikdə). Belə bir şəraitdə uzun müddət “python analitikinin” nə olduğu aydın deyildi. Python PHP kimidir, yalnız adı bir az uzundur və tərcüməçinin mənbə kodunda zehni dəyişdirən maddələrin izləri bir qədər azdır. Bununla belə, getdikcə daha çox analitik hesabat yaradıldıqca, təcrübəli tərtibatçılar numpy, pandas, matplotlib, seaborn kimi alətlərdə dar ixtisaslaşmanın əhəmiyyətini getdikcə daha çox anlamağa başladılar.
Çox güman ki, həlledici rolu işçilərin "logistik reqressiya" sözlərinin birləşməsindən qəfil huşunu itirməsi və bəli, bəli, pyspark-dan istifadə edərək böyük məlumatlar üzrə effektiv hesabatın nümayişi oynadı.
Apache Spark, onun relyasiya cəbrinin mükəmməl uyğunlaşdığı funksional paradiqması və onun imkanları MySQL-ə öyrəşmiş tərtibatçılarda elə təəssürat yaratdı ki, sıraların təcrübəli analitiklərlə gücləndirilməsi zərurəti gün keçdikcə aydın oldu.
Apache Spark/Hadoop-un növbəti uçuş cəhdləri və skriptə uyğun olmayan şeylər
Bununla belə, tezliklə aydın oldu ki, Spark ilə sistemli olaraq bir şey düzgün deyil və ya sadəcə əllərinizi daha yaxşı yumaq lazımdır. Əgər Hadoop/MapReduce/Lucene yığını kifayət qədər təcrübəli proqramçılar tərəfindən hazırlanıbsa, bu, Java-dakı mənbə koduna və ya Lucene-dəki Doug Cutting-in ideyalarına diqqətlə baxsanız, aydın görünür, o zaman Spark birdən Scala ekzotik dilində yazılır. praktiklik baxımından çox mübahisəlidir və hazırda inkişaf etmir. Və əməliyyatları azaltmaq üçün yaddaşın ayrılması ilə (birdən çox açar bir anda daxil olur) məntiqsiz və çox şəffaf olmayan iş səbəbindən Spark klasterində hesablamaların müntəzəm azalması onun ətrafında böyümək üçün yer olan bir şeyin bir halosunu yaratdı. Bundan əlavə, vəziyyəti çoxlu sayda qəribə açıq portlar, ən anlaşılmaz yerlərdə böyüyən müvəqqəti fayllar və cəhənnəm jar asılılıqları ağırlaşdırdı - bu, sistem administratorlarında uşaqlıqdan yaxşı bilinən bir hiss keçirməyə səbəb oldu: şiddətli nifrət (və ya bəlkə də. əllərini sabunla yumaq lazım idi).
Nəticədə, biz Apache Spark (o cümlədən Spark Streaming, Spark SQL) və Hadoop ekosistemindən (və sair və s.) fəal şəkildə istifadə edən bir neçə daxili analitik layihədən “sağ qaldıq”. Vaxt keçdikcə "onu" çox yaxşı hazırlamağı və izləməyi öyrənməyimizə və məlumatların təbiətindəki dəyişikliklər və vahid RDD hashing balansının pozulması səbəbindən "o" praktiki olaraq qəfil qəzaya uğramağı dayandırmağımıza baxmayaraq, artıq hazır bir şey götürmək istəyi. , buludda bir yerdə yeniləndi və idarə olundu, gücləndi və gücləndi. Məhz bu zaman biz Amazon Web Services-in hazır bulud yığıncağından istifadə etməyə çalışdıq - və sonradan ondan istifadə edərək problemləri həll etməyə çalışdı. EMR, Cloudera/Hortonworks qurmaları kimi, ekosistemdən əlavə proqram təminatı ilə Amazon tərəfindən hazırlanmış Apache Spark-dır.
Analitika üçün rezin fayl saxlama təcili ehtiyacdır
Bədənin müxtəlif hissələrinin yanıqları olan Hadoop/Spark-ı “bişirmək” təcrübəsi əbəs deyildi. Aparat çatışmazlığına davamlı və müxtəlif sistemlərdən müxtəlif formatlarda faylları saxlamaq və bu məlumatlardan hesabatlar üçün səmərəli və vaxta qənaət edən nümunələr hazırlamaq mümkün olan vahid, ucuz və etibarlı fayl anbarının yaradılması ehtiyacı getdikcə artdı. aydın.
Mən həm də istəyirdim ki, bu platformanın proqram təminatının yenilənməsi 20 səhifəlik Java izlərini oxumaqla və Spark History Server və arxa işıqlı böyüdücü şüşədən istifadə edərək klasterin kilometrlərlə ətraflı qeydlərini təhlil etməklə Yeni il kabusuna çevrilməsin. Çox yaxşı seçilməmiş mənbə məlumatlarının bölmə alqoritmi səbəbindən məlumatların azaldılması işçisi yaddaşdan çıxdıqda, tərtibatçının standart MapReduce sorğusu yerinə yetirilməyi dayandırarsa, başlıq altında müntəzəm dalğıc tələb etməyən sadə və şəffaf bir alətə sahib olmaq istəyirdim.
Amazon S3 DataLake üçün namizəddirmi?
Hadoop/MapReduce ilə təcrübə bizə məlumatların şəbəkə üzərindən ötürülməməsi üçün məlumatlara “yaxınlaşan” miqyaslana bilən, etibarlı fayl sisteminə və miqyaslana bilən işçilərə ehtiyacımız olduğunu öyrətdi. İşçilər müxtəlif formatlarda məlumatları oxumağı bacarmalı, lakin üstünlük verilən lazımsız məlumatları oxumamalı və məlumatları işçilər üçün əlverişli formatlarda əvvəlcədən saxlaya bilməlidirlər.
Bir daha, əsas fikir. Böyük məlumatları bir klaster analitik mühərrikinə “tökmək” arzusu yoxdur, bu, gec-tez boğulacaq və siz onu çirkin şəkildə parçalamalı olacaqsınız. Mən sadəcə faylları başa düşülən formatda saxlamaq və müxtəlif, lakin başa düşülən alətlərdən istifadə etməklə onlar üzrə effektiv analitik sorğular yerinə yetirmək istəyirəm. Və müxtəlif formatlarda daha çox fayl olacaq. Mühərriki deyil, mənbə məlumatlarını parçalamaq daha yaxşıdır. Bizə genişlənən və universal DataLake lazımdır, qərara gəldik...
Hadoop-dan öz pirzolalarınızı hazırlamadan faylları tanış və tanınmış Amazon S3 bulud yaddaşında saxlasanız necə olar?
Fərdi məlumatların "aşağı" olduğu aydındır, bəs biz onları oradan götürsək və "effektiv şəkildə idarə etsək" digər məlumatlar haqqında nə demək olar?
Amazon Veb Xidmətlərinin klaster-bigdata-analitika ekosistemi - çox sadə sözlərlə
AWS ilə təcrübəmizə əsasən, Apache Hadoop/MapReduce orada uzun müddət müxtəlif souslar altında, məsələn DataPipeline xidmətində fəal şəkildə istifadə olunur (həmkarlarıma həsəd aparıram, onlar onu necə düzgün hazırlamağı öyrəndilər). Burada DynamoDB cədvəllərindən müxtəlif xidmətlərdən ehtiyat nüsxələri quraşdırırıq:
Və onlar artıq bir neçə ildir ki, saat mexanizmi kimi quraşdırılmış Hadoop/MapReduce klasterlərində müntəzəm olaraq işləyirlər. "Onu təyin et və unut":
Siz həmçinin analitiklər üçün buludda Yupiter noutbuklarını quraşdırmaqla və süni intellekt modellərini döyüşə hazırlamaq və yerləşdirmək üçün AWS SageMaker xidmətindən istifadə etməklə məlumat satanizmi ilə effektiv şəkildə məşğul ola bilərsiniz. Bu, bizim üçün necə görünür:
Bəli, özünüz və ya buluddakı analitikiniz üçün noutbuk götürə və onu Hadoop/Spark klasterinə əlavə edə, hesablamalar apara və sonra hər şeyi düzəldə bilərsiniz:
Fərdi analitik layihələr üçün həqiqətən əlverişlidir və bəziləri üçün böyük miqyaslı hesablamalar və analitika üçün EMR xidmətindən uğurla istifadə etdik. DataLake üçün sistem həlli haqqında nə demək olar, o işləyəcəkmi? Bu an ümid və ümidsizlik astanasında idik və axtarışa davam etdik.
AWS Glue - steroid üzərində səliqəli şəkildə qablaşdırılmış Apache Spark
Məlum oldu ki, AWS-in “Hive/Pig/Spark” yığınının öz versiyası var. Hive rolu, yəni. DataLake-də faylların və onların növlərinin kataloqu Apache Hive formatı ilə uyğunluğunu gizlətməyən “Məlumat kataloqu” xidməti tərəfindən həyata keçirilir. Siz bu xidmətə fayllarınızın harada yerləşdiyi və hansı formatda olması barədə məlumat əlavə etməlisiniz. Məlumatlar təkcə s3-də deyil, həm də verilənlər bazasında ola bilər, lakin bu yazının mövzusu deyil. DataLake məlumat kataloqumuzun necə təşkil olunduğu budur:
Fayllar qeydə alınıb, əla. Fayllar yenilənibsə, biz ya əl ilə, ya da cədvəl üzrə sürünənləri işə salırıq ki, bu da göldən onlar haqqında məlumatları yeniləyəcək və onları saxlayacaq. Sonra göldən alınan məlumatlar emal oluna və nəticələr harasa yüklənə bilər. Ən sadə halda biz də s3-ə yükləyirik. Məlumatların emalı istənilən yerdə edilə bilər, lakin AWS Glue API vasitəsilə qabaqcıl imkanlardan istifadə edərək Apache Spark klasterində emalı konfiqurasiya etməyiniz tövsiyə olunur. Əslində, siz pyspark kitabxanasından istifadə edərək köhnə və tanış olan python kodunu götürə və Hadoop-un bağırsaqlarını qazmadan və docker-moker konteynerlərini sürükləmədən və asılılıq münaqişələrini aradan qaldırmadan, monitorinqlə müəyyən tutumlu klasterin N qovşağında icrasını konfiqurasiya edə bilərsiniz. .
Yenə də sadə bir fikir. Apache Spark-ı konfiqurasiya etməyə ehtiyac yoxdur, sadəcə olaraq pyspark üçün python kodu yazmaq, onu masaüstünüzdə yerli olaraq sınaqdan keçirmək və sonra mənbə məlumatının harada olduğunu və nəticəni hara qoymaq lazım olduğunu göstərərək onu buludda böyük klasterdə işə salmaq lazımdır. Bəzən bu lazımlı və faydalıdır və onu necə qura bilərik:
Beləliklə, əgər s3-də verilənlərdən istifadə edərək Spark klasterində nəyisə hesablamaq lazımdırsa, biz python/pyspark-da kod yazırıq, onu sınaqdan keçiririk və buluda uğurlar arzu edirik.
Bəs orkestr haqqında? Tapşırıq düşsə və yoxa çıxsa? Bəli, Apache Pig üslubunda gözəl bir boru kəməri hazırlamaq təklif olunur və biz hətta onları sınadıq, lakin hələlik biz PHP və JavaScript-də dərin fərdiləşdirilmiş orkestrimizdən istifadə etmək qərarına gəldik (başa düşürəm, koqnitiv dissonans var, amma işləyir, çünki illər və səhvsiz).
Göldə saxlanılan faylların formatı performansın açarıdır
Daha iki əsas məqamı başa düşmək çox, çox vacibdir. Göldəki fayl məlumatları ilə bağlı sorğuların mümkün qədər tez yerinə yetirilməsi və yeni məlumatlar əlavə edildikdə performansın pisləşməməsi üçün sizə lazımdır:
- Faylların sütunlarını ayrıca saxlayın (sütunlarda nə olduğunu başa düşmək üçün bütün sətirləri oxumaq məcburiyyətində qalmamaq üçün). Bunun üçün sıxılma ilə parket formatını götürdük
- Faylları qovluqlara bölmək çox vacibdir: dil, il, ay, gün, həftə. Bu cür qırıntıları başa düşən mühərriklər ardıcıl olaraq bütün məlumatları süzmədən yalnız lazımi qovluqlara baxacaqlar.
Əslində, bu şəkildə, yuxarıda asılmış analitik mühərriklər üçün mənbə məlumatlarını ən səmərəli formada yerləşdirirsiniz, hətta parçalanmış qovluqlarda da fayllardan yalnız lazımi sütunları seçərək daxil edə və oxuya bilərsiniz. Məlumatları heç bir yerdə "doldurmağa" ehtiyac yoxdur (saxlama sadəcə partlayacaq) - dərhal ağıllı şəkildə fayl sisteminə düzgün formatda qoyun. Əlbəttə, burada aydın olmalıdır ki, sütunları çıxarmaq üçün əvvəlcə klaster tərəfindən sətir-sətir oxunmalı olan nəhəng csv faylını DataLake-də saxlamaq çox məqsədəuyğun deyil. Bütün bunların niyə baş verdiyi hələ aydın deyilsə, yuxarıdakı iki məqamı yenidən düşünün.
AWS Athena - qutuda olan jak
Və sonra göl yaradan zaman təsadüfən Amazon Athena ilə qarşılaşdıq. Birdən məlum oldu ki, nəhəng log fayllarımızı düzgün (parket) sütun formatında qovluq parçalarına diqqətlə yerləşdirməklə, siz onlardan çox tez son dərəcə məlumatlandırıcı seçimlər edə və Apache Spark/Glue klasteri olmadan hesabatlar yarada bilərsiniz.
s3-də verilənlərlə təchiz edilmiş Athena mühərriki əfsanəvi mühərrikə əsaslanır - s3 və Hadoop-dan Cassandra-ya və adi mətn fayllarına qədər məlumatların yerləşdiyi yerdə götürülərək məlumatların emalına yanaşmalar ailəsinin MPP (kütləvi paralel emal) nümayəndəsi. Siz sadəcə Athenadan SQL sorğusunu yerinə yetirməsini xahiş etməlisiniz və sonra hər şey “tez və avtomatik işləyir”. Qeyd etmək vacibdir ki, Athena "ağıllıdır", o, yalnız zəruri parçalanmış qovluqlara gedir və sorğuda yalnız lazım olan sütunları oxuyur.
Athenaya müraciətlərin qiymətləri də maraqlıdır. Biz ödəyirik . Bunlar. dəqiqədə klasterdə olan maşınların sayına görə deyil, amma... 100-500 maşında faktiki olaraq skan edilmiş məlumatlar üçün yalnız sorğunu tamamlamaq üçün lazım olan məlumatlar.
Düzgün parçalanmış qovluqlardan yalnız lazımi sütunları tələb etməklə, Athena xidmətinin bizə ayda onlarla dollara başa gəldiyi məlum oldu. Klasterlər üzrə analitika ilə müqayisədə əla, demək olar ki, pulsuzdur!
Yeri gəlmişkən, məlumatlarımızı s3-də necə paylaşırıq:
Nəticədə, qısa müddət ərzində şirkətin informasiya təhlükəsizliyindən tutmuş analitikaya qədər tamamilə fərqli departamentləri Athenaya aktiv şəkildə sorğular göndərməyə başladılar və tez bir zamanda, kifayət qədər uzun müddət ərzində “böyük” məlumatlardan faydalı cavablar aldılar: aylar, yarım il və s. P.
Ancaq daha da irəli getdik və cavablar üçün buluda getməyə başladıq : analitik SQL sorğusunu tanış konsolda yazır, bu sorğu 100-500 maşında “pennies üçün” s3-ə məlumat göndərir və adətən bir neçə saniyə ərzində cavab qaytarır. Rahat. Və sürətli. Mən hələ də buna inana bilmirəm.
Nəticədə, məlumatları s3-də, səmərəli sütunlu formatda və məlumatların qovluqlarda ağlabatan parçalanması ilə saxlamağa qərar verərək... DataLake və sürətli və ucuz analitik mühərriki pulsuz əldə etdik. Və o, şirkətdə çox məşhur oldu, çünki... SQL-i başa düşür və klasterlərin işə salınması/dayandırılması/qurulmasından daha sürətli böyüklük sifarişləri işləyir. "Nəticə eynidirsə, niyə daha çox pul ödəyirsiniz?"
Athenaya müraciət belə görünür. İstəyirsinizsə, əlbəttə ki, kifayət qədər formalaşdıra bilərsiniz , lakin biz özümüzü sadə qruplaşdırma ilə məhdudlaşdıracağıq. Gəlin müştərinin bir neçə həftə əvvəl veb server qeydlərində hansı cavab kodlarına malik olduğunu görək və heç bir səhv olmadığından əmin olun:
Tapıntılar
Uzun, lakin ağrılı bir yol keçərək, riskləri və mürəkkəblik səviyyəsini və dəstəyin dəyərini daim adekvat qiymətləndirərək, DataLake və analitika üçün həm sürət, həm də sahiblik dəyəri ilə bizi sevindirməyə davam edən bir həll tapdıq.
Məlum oldu ki, şirkətin tamamilə fərqli departamentlərinin ehtiyacları üçün effektiv, sürətli və ucuz idarə olunan DataLake qurmaq hətta heç vaxt memar kimi işləməmiş və kvadratlarda kvadratlar çəkməyi bilməyən təcrübəli tərtibatçıların imkanlarına tamamilə uyğundur. oxlar və Hadoop ekosistemindən 50 termin bilirik.
Səyahətinin əvvəlində başım açıq və qapalı proqram təminatı və nəsillər qarşısında məsuliyyət yükünü dərk edən çoxlu vəhşi zooparklardan ayrılırdı. Sadəcə olaraq sadə alətlərdən DataLake qurmağa başlayın: nagios/munin -> elastik/kibana -> Hadoop/Spark/s3..., rəy toplamaq və baş verən proseslərin fizikasını dərindən dərk etmək. Hər şey mürəkkəb və qaranlıqdır - onu düşmənlərə və rəqiblərə verin.
Buluda getmək istəmirsinizsə və açıq mənbəli layihələri dəstəkləmək, yeniləmək və yamaq istəsəniz, Hadoop və Presto olan ucuz ofis maşınlarında yerli olaraq bizimkinə bənzər bir sxem qura bilərsiniz. Əsas odur ki, dayanmayın və irəliləyin, saymayın, sadə və aydın həllər axtarın və hər şey mütləq nəticə verəcəkdir! Hər kəsə uğurlar və yenidən görüşənədək!
Mənbə: www.habr.com