Biz bir nechta tayyor ochiq manbali vositalarni tez va oson ulashingiz, ularni stackoverflow maslahatiga ko'ra, "ko'p harflar"ga kirmasdan "ongingiz o'chirilgan" holda sozlashingiz va ishga tushirishingiz mumkin bo'lgan ajoyib davrda yashayapmiz. ularni tijorat faoliyatiga aylantiradi. Va siz yangilash/kengaytirish kerak bo'lganda yoki kimdir tasodifan bir nechta mashinani qayta ishga tushirganda - siz qandaydir obsesif yomon tush boshlanganini, hamma narsa tanib bo'lmaydigan darajada murakkablashganini, orqaga qaytishning iloji yo'qligini, kelajak noaniq va xavfsizroq ekanligini tushunasiz, dasturlash o'rniga asalarilarni ko'paytirish va pishloq qilish.
Tajribali hamkasblar boshlari xatolarga to'la va shuning uchun allaqachon kulrang bo'lib, o'rnatilgan qo'llab-quvvatlanadigan "moda tillarida" o'nlab serverlarda "kublar" shaklida "konteynerlar" to'plamini juda tez joylashtirish haqida o'ylashlari bejiz emas. asinxron bloklanmagan kiritish-chiqarish, kamtarona tabassum. Va ular jimgina "man ps" ni qayta o'qishni davom ettiradilar, ko'zlari qon bo'lguncha "nginx" manba kodini o'rganadilar va birlik testlarini yozadilar, yozadilar, yozadilar. Hamkasblar bilishadiki, eng qiziqarli narsa "bularning barchasi" bir kun yangi yil arafasida tunda qolib ketganda keladi. Va ularga faqat unix tabiatini chuqur tushunish, yodlangan TCP/IP holati jadvali va asosiy saralash-qidiruv algoritmlari yordam beradi. Qo'ng'iroq chalinayotganda tizimni hayotga qaytarish uchun.
Ha, men biroz chalg'ib qoldim, lekin umid qilamanki, men kutish holatini etkaza oldim.
Bugun men DataLake uchun qulay va arzon stekni joylashtirish bo'yicha tajribamiz bilan o'rtoqlashmoqchiman, bu kompaniyadagi ko'pgina tahliliy vazifalarni butunlay boshqa tarkibiy bo'linmalar uchun hal qiladi.
Bir muncha vaqt oldin biz kompaniyalarga mahsulot va texnik tahlillar (mashinalarni o'rganish ko'rinishidagi pirojnoe haqida gapirmasa ham bo'ladi) va tendentsiyalar va xavflarni tushunish uchun ko'proq ehtiyoj borligini tushundik - biz to'plashimiz va tahlil qilishimiz kerak. tobora ko'proq ko'rsatkichlar.
Bitrix24 da asosiy texnik tahlillar
Bir necha yil oldin, Bitrix24 xizmati ishga tushirilishi bilan bir vaqtda, biz infratuzilmadagi muammolarni tezda ko'rish va keyingi qadamni rejalashtirishga yordam beradigan oddiy va ishonchli tahliliy platformani yaratish uchun vaqt va resurslarni faol ravishda sarfladik. Albatta, iloji boricha sodda va tushunarli bo'lgan tayyor vositalarni olish maqsadga muvofiq edi. Natijada monitoring uchun nagios, tahlil va vizualizatsiya uchun esa munin tanlandi. Endi bizda nagiosda minglab cheklar, muninda yuzlab jadvallar mavjud va bizning hamkasblarimiz ulardan har kuni muvaffaqiyatli foydalanadilar. Ko'rsatkichlar aniq, grafiklar aniq, tizim bir necha yillardan beri ishonchli ishlaydi va unga muntazam ravishda yangi testlar va grafiklar qo'shiladi: biz yangi xizmatni ishga tushirganimizda, biz bir nechta test va grafiklarni qo'shamiz. Omad.
Pulse barmoq - ilg'or texnik tahlil
Muammolar haqida ma'lumotni "iloji boricha tezroq" olish istagi bizni oddiy va tushunarli vositalar - pinba va xhprof bilan faol tajribalarga olib keldi.
Pinba bizga PHP-da veb-sahifalar qismlarining ishlash tezligi haqida UDP paketlarida statistik ma'lumotlarni yubordi va biz MySQL xotirasida onlayn ko'rishimiz mumkin edi (Pinba tezkor hodisalarni tahlil qilish uchun o'zining MySQL dvigateli bilan birga keladi) muammolarning qisqa ro'yxatini va javoblarni ular. Va xhprof avtomatik ravishda bizga mijozlardan eng sekin PHP sahifalarining bajarilishi grafiklarini yig'ish va bunga nima olib kelishi mumkinligini tahlil qilish imkonini berdi - tinchgina, choy yoki kuchliroq narsalarni quyish.
Bir muncha vaqt oldin asboblar to'plami afsonaviy Lucene kutubxonasida mukammal tarzda amalga oshirilgan teskari indekslash algoritmiga asoslangan boshqa juda oddiy va tushunarli dvigatel bilan to'ldirildi - Elastic/Kibana. Jurnallardagi voqealarga asoslangan teskari Lucene indeksiga hujjatlarni ko'p bosqichli yozishning oddiy g'oyasi va faset bo'linmasi yordamida ular orqali tezkor qidiruv haqiqatan ham foydali bo'ldi.
Kibanadagi “paqir” “yuqoriga qarab oqadigan” kabi past darajadagi tushunchalar va hali toʻliq unutilmagan relyatsion algebraning qayta ixtiro qilingan tiliga ega vizualizatsiyaning ancha texnik koʻrinishiga qaramay, ushbu vosita bizga quyidagi vazifalarni bajarishda yaxshi yordam bera boshladi:
- Bitrix24 mijozi oxirgi soat ichida p1 portalida nechta PHP xatosi bor edi va qaysilari? Tushuning, kechiring va tezda tuzating.
- Oldingi 24 soat ichida Germaniyadagi portallarda qancha video qo'ng'iroqlar amalga oshirildi, qanday sifatda va kanal/tarmoq bilan bog'liq qiyinchiliklar bormi?
- Xizmatning so'nggi yangilanishida manbadan tuzilgan va mijozlarga taqdim etilgan tizim funksionalligi (PHP uchun C kengaytmamiz) qanchalik yaxshi ishlaydi? Nosozliklar bormi?
- Mijoz ma'lumotlari PHP xotirasiga mos keladimi? Jarayonlarga ajratilgan xotiradan oshib ketishda xatolar bormi: "xotira yo'q"? Toping va zararsizlantiring.
Mana, aniq bir misol. Puxta va ko'p darajali sinovlarga qaramay, mijoz juda nostandart holat va buzilgan kirish ma'lumotlari bilan zerikarli va kutilmagan xatoga yo'l qo'ydi, sirena eshitildi va uni tezda tuzatish jarayoni boshlandi:
Bundan tashqari, kibana ko'rsatilgan voqealar uchun bildirishnomalarni tashkil qilish imkonini beradi va qisqa vaqt ichida kompaniyadagi vosita turli bo'limlarning o'nlab xodimlari tomonidan qo'llanila boshlandi - texnik qo'llab-quvvatlash va ishlab chiqishdan tortib QAgacha.
Kompaniya ichidagi har qanday bo'limning faoliyatini kuzatish va o'lchash qulay bo'ldi - serverlardagi jurnallarni qo'lda tahlil qilish o'rniga, siz bir marta tahlil jurnallarini o'rnatishingiz va ularni elastik klasterga yuborishingiz kerak, masalan, kibanada o'ylash. asboblar panelida oxirgi oyda 3D printerda chop etilgan sotilgan ikki boshli mushukchalar soni.
Asosiy biznes tahlili
Hamma biladiki, kompaniyalarda biznes-tahlil ko'pincha Exceldan juda faol foydalanish bilan boshlanadi. Lekin asosiysi, bu u erda tugamaydi. Bulutli Google Analytics ham olovga yoqilg'i qo'shadi - siz tezda yaxshi narsalarga ko'nikishni boshlaysiz.
Bizning uyg'un rivojlanayotgan kompaniyamizda u erda va u erda kattaroq ma'lumotlar bilan yanada intensiv ishlaydigan "payg'ambarlar" paydo bo'la boshladi. Chuqurroq va ko'p qirrali hisobotlarga bo'lgan ehtiyoj muntazam ravishda paydo bo'la boshladi va turli bo'limlarning yigitlari sa'y-harakatlari bilan bir muncha vaqt oldin oddiy va amaliy yechim - ClickHouse va PowerBI kombinatsiyasi tashkil etildi.
Uzoq vaqt davomida bu moslashuvchan yechim ko'p yordam berdi, lekin asta-sekin ClickHouse kauchuk emas va uni masxara qilib bo'lmaydi degan tushuncha paydo bo'ldi.
Bu erda shuni yaxshi tushunish kerakki, ClickHouse, Druid, Vertica, Amazon RedShift (bu postgres-ga asoslangan) juda qulay tahlillar (summalar, yig'ishlar, ustunlar bo'yicha minimal-maksimal va bir nechta mumkin bo'lgan birlashmalar) uchun optimallashtirilgan analitik dvigatellardir. ), chunki MySQL va bizga ma'lum bo'lgan boshqa (satrga yo'naltirilgan) ma'lumotlar bazalaridan farqli o'laroq, relyatsion jadvallar ustunlarini samarali saqlash uchun tashkil etilgan.
Aslini olganda, ClickHouse shunchaki ko'proq sig'imli "ma'lumotlar bazasi" bo'lib, unchalik qulay bo'lmagan nuqtama-nuqta qo'shish (bu shunday mo'ljallangan, hammasi joyida), lekin yoqimli tahlil va ma'lumotlar bilan ishlash uchun qiziqarli kuchli funktsiyalar to'plami. Ha, siz hatto klaster ham yaratishingiz mumkin - lekin siz mikroskop bilan mixlarni urish mutlaqo to'g'ri emasligini tushunasiz va biz boshqa echimlarni izlay boshladik.
Python va tahlilchilarga talab
Kompaniyamizda PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash tillarida deyarli har kuni 10-20 yil davomida kod yozadigan ko'plab dasturchilar mavjud. Bundan tashqari, statistika qonunlariga to'g'ri kelmaydigan bir nechta mutlaqo aql bovar qilmaydigan ofatlarni boshdan kechirgan ko'plab tajribali tizim ma'murlari bor (masalan, reyd-10 disklarining aksariyati kuchli chaqmoq urishi natijasida vayron bo'lganda). Bunday sharoitda, uzoq vaqt davomida "python tahlilchisi" nima ekanligi aniq emas edi. Python PHP ga o'xshaydi, faqat nomi biroz uzunroq va tarjimonning manba kodida aqlni o'zgartiruvchi moddalarning izlari biroz kamroq. Biroq, tobora ko'proq tahliliy hisobotlar yaratilishi bilan tajribali ishlab chiquvchilar numpy, pandas, matplotlib, seaborn kabi vositalarda tor ixtisoslashuvning ahamiyatini tobora ko'proq tushuna boshladilar.
Hal qiluvchi rolni, ehtimol, xodimlarning "logistik regressiya" so'zlari birikmasidan to'satdan hushidan ketishlari va "ha, ha, pyspark" dan foydalangan holda katta ma'lumotlar bo'yicha samarali hisobot berishning namoyishi o'ynadi.
Apache Spark, uning relyatsion algebra juda mos keladigan funksional paradigmasi va uning imkoniyatlari MySQL-ga o'rganib qolgan dasturchilarda shunday taassurot qoldirdiki, saflarni tajribali tahlilchilar bilan mustahkamlash zarurati kun sayin ayon bo'ldi.
Apache Spark/Hadoop-ning parvozga bo'lgan keyingi urinishlari va nimalar skriptga ko'ra umuman bo'lmadi
Biroq, tez orada Spark bilan tizimli ravishda biror narsa noto'g'ri ekanligi ma'lum bo'ldi yoki shunchaki qo'lingizni yaxshiroq yuvish kerak edi. Agar Hadoop/MapReduce/Lucene stegi juda tajribali dasturchilar tomonidan yaratilgan bo'lsa, bu Java-dagi manba kodiga yoki Dug Cuttingning Lucene-dagi g'oyalariga diqqat bilan qarasangiz, Spark kutilmaganda Scala ekzotik tilida yozilgan. amaliylik nuqtai nazaridan juda ziddiyatli va hozirda rivojlanmaydi. Spark klasteridagi hisob-kitoblarning mantiqsiz va unchalik shaffof bo'lmagan operatsiyalari tufayli qisqarishi (ko'p kalitlar bir vaqtning o'zida keladi) tufayli uning atrofida o'sishi uchun joy bo'lgan narsaning halosini yaratdi. Bundan tashqari, vaziyatni juda ko'p sonli g'alati ochiq portlar, eng tushunarsiz joylarda o'sadigan vaqtinchalik fayllar va jahannamga bog'liqliklar yomonlashtirdi - bu tizim ma'murlarida bolalikdan yaxshi ma'lum bo'lgan bitta tuyg'uni keltirib chiqardi: shafqatsiz nafrat (yoki ehtimol). qo'llarini sovun bilan yuvishlari kerak edi).
Natijada, biz Apache Spark (jumladan, Spark Streaming, Spark SQL) va Hadoop ekotizimidan (va hokazo va hokazo) faol foydalanadigan bir nechta ichki tahliliy loyihalardan "omon qoldik". Vaqt o'tishi bilan biz "uni" yaxshi tayyorlash va kuzatishni o'rganganimizga qaramay, "u" ma'lumotlarning tabiatidagi o'zgarishlar va yagona RDD xeshingining nomutanosibligi tufayli to'satdan ishdan chiqishni to'xtatgan bo'lsak ham, allaqachon tayyor bo'lgan narsani olish istagi. , bulutning biron bir joyida yangilangan va boshqariladigan narsalar kuchayib bordi. Aynan o'sha paytda biz Amazon Web Services-ning tayyor bulutli yig'ilishidan foydalanishga harakat qildik - va, keyinchalik, undan foydalanish muammolarni hal qilishga harakat qildi. EMR bu Apache Spark bo'lib, Amazon tomonidan ekotizimning Cloudera/Hortonworks tuzilmalari kabi qo'shimcha dasturiy ta'minot bilan tayyorlangan.
Analitika uchun kauchuk fayllarni saqlash shoshilinch zaruratdir
Hadoop/Sparkni tananing turli qismlari kuyishi bilan “pishirish” tajribasi bejiz emas edi. Uskuna nosozliklariga chidamli bo'lgan va turli xil tizimlardan turli formatlarda fayllarni saqlash va ushbu ma'lumotlardan hisobotlar uchun samarali va vaqtni tejaydigan namunalarni yaratish mumkin bo'lgan yagona, arzon va ishonchli fayl omborini yaratish zarurati tobora ortib bormoqda. aniq.
Men ushbu platformaning dasturiy ta'minotini yangilash 20 sahifali Java izlarini o'qish va Spark History Server va orqadan yoritilgan lupa yordamida klasterning kilometrlik batafsil jurnallarini tahlil qilish bilan yangi yil dahshatli tushiga aylanib qolmasligini xohlardim. Men oddiy va shaffof vositaga ega bo'lishni xohlardim, agar dasturchining standart MapReduce so'rovi juda yaxshi tanlanmagan manba ma'lumotlarini bo'lish algoritmi tufayli ma'lumotlarni qisqartirish ishchisi xotiradan tushib qolsa, bajarilishi to'xtatilsa.
Amazon S3 DataLake uchun nomzodmi?
Hadoop/MapReduce bilan bo'lgan tajriba bizga ma'lumotlarni tarmoq orqali boshqarmaslik uchun ma'lumotlarga yaqinroq keladigan, kengaytiriladigan, ishonchli fayl tizimi va uning ustiga kengaytiriladigan ishchilar kerakligini o'rgatdi. Ishchilar turli formatlardagi ma'lumotlarni o'qiy olishlari kerak, lekin keraksiz ma'lumotlarni o'qimasliklari va ma'lumotlarni ishchilar uchun qulay formatlarda oldindan saqlashlari kerak.
Yana bir bor asosiy fikr. Katta ma'lumotlarni bitta klasterli analitik dvigatelga "to'kish" istagi yo'q, bu ertami-kechmi bo'g'ilib qoladi va siz uni xunuk qilib parchalashingiz kerak bo'ladi. Men fayllarni, shunchaki fayllarni tushunarli formatda saqlashni va turli, ammo tushunarli vositalardan foydalangan holda ular bo'yicha samarali tahliliy so'rovlarni bajarishni xohlayman. Va har xil formatdagi fayllar ko'proq bo'ladi. Va dvigatelni emas, balki manba ma'lumotlarini parchalash yaxshiroqdir. Bizga kengaytiriladigan va universal DataLake kerak, biz qaror qildik ...
Agar siz Hadoop-dan o'zingizning pirzolangizni tayyorlamasdan turib, Amazon S3-ning taniqli va taniqli bulutli xotirasida fayllarni saqlasangiz nima bo'ladi?
Shaxsiy ma'lumotlarning "past" ekanligi aniq, ammo agar biz uni olib chiqib, "samarali boshqarsak" boshqa ma'lumotlar haqida nima deyish mumkin?
Amazon Web Services klaster-bigdata-analitik ekotizim - juda oddiy so'z bilan aytganda
AWS bilan bo'lgan tajribamizga qaraganda, Apache Hadoop/MapReduce u erda uzoq vaqt davomida turli xil soslar ostida, masalan, DataPipeline xizmatida faol foydalanilgan (men hamkasblarimga hasad qilaman, ular uni qanday qilib to'g'ri tayyorlashni o'rganishdi). Bu erda biz DynamoDB jadvallaridan turli xizmatlarning zaxira nusxalarini o'rnatamiz:
Va ular bir necha yillardan beri muntazam ravishda o'rnatilgan Hadoop/MapReduce klasterlarida soat mexanizmi kabi ishlamoqda. "O'rnating va unuting":
Shuningdek, siz tahlilchilar uchun bulutda Yupiter noutbuklarini oʻrnatish va AI modellarini jangga oʻrgatish va joylashtirish uchun AWS SageMaker xizmatidan foydalanish orqali maʼlumotlar satanizmi bilan samarali shugʻullanishingiz mumkin. Bu biz uchun qanday ko'rinadi:
Ha, siz o'zingiz yoki bulutdagi tahlilchi uchun noutbukni olishingiz va uni Hadoop/Spark klasteriga biriktirishingiz, hisob-kitoblarni amalga oshirishingiz va keyin hamma narsani aniqlab olishingiz mumkin:
Individual tahliliy loyihalar uchun haqiqatan ham qulay va ba'zilari uchun biz keng ko'lamli hisob-kitoblar va tahlillar uchun EMR xizmatidan muvaffaqiyatli foydalandik. DataLake uchun tizim yechimi haqida nima deyish mumkin, u ishlaydi? Ayni damda umid va umidsizlik yoqasida edik va izlanishni davom ettirdik.
AWS Glue - steroidlarda chiroyli tarzda qadoqlangan Apache Spark
Ma'lum bo'lishicha, AWS "Hive/Pig/Spark" stekining o'ziga xos versiyasiga ega. Hive roli, ya'ni. DataLake-dagi fayllar katalogi va ularning turlari "Ma'lumotlar katalogi" xizmati tomonidan amalga oshiriladi, bu Apache Hive formati bilan mosligini yashirmaydi. Ushbu xizmatga fayllaringiz qayerda va qaysi formatda ekanligi haqida ma'lumot qo'shishingiz kerak. Ma'lumotlar nafaqat s3-da, balki ma'lumotlar bazasida ham bo'lishi mumkin, ammo bu maqolaning mavzusi emas. Bizning DataLake ma'lumotlar katalogimiz qanday tashkil etilgan:
Fayllar ro'yxatdan o'tgan, ajoyib. Agar fayllar yangilangan bo'lsa, biz brauzerlarni qo'lda yoki jadval bo'yicha ishga tushiramiz, ular ko'ldan ular haqidagi ma'lumotlarni yangilaydi va ularni saqlaydi. Keyin ko'ldan olingan ma'lumotlarni qayta ishlash va natijalarni biror joyga yuklash mumkin. Eng oddiy holatda biz s3 ga ham yuklaymiz. Ma'lumotlarni qayta ishlash istalgan joyda amalga oshirilishi mumkin, ammo AWS Glue API orqali rivojlangan imkoniyatlardan foydalangan holda Apache Spark klasterida ishlov berishni sozlash tavsiya etiladi. Haqiqatan ham, siz pyspark kutubxonasidan foydalanib, eski yaxshi va tanish python kodini olishingiz va Hadoop-ning chuqurligiga kirmasdan va docker-moker konteynerlarini tortmasdan va qaramlik ziddiyatlarini bartaraf qilmasdan, uning bajarilishini bir oz sig'imli klasterning N tugunlarida monitoring bilan sozlashingiz mumkin. .
Yana bir bor oddiy fikr. Apache Spark-ni sozlashning hojati yo'q, siz shunchaki pyspark uchun python kodini yozishingiz, uni ish stolingizda mahalliy sinovdan o'tkazishingiz va keyin uni bulutdagi katta klasterda ishga tushirishingiz, manba ma'lumotlari qayerda ekanligini va natijani qaerga qo'yish kerakligini ko'rsatishingiz kerak. Ba'zan bu zarur va foydali bo'ladi va biz uni qanday sozlashimiz mumkin:
Shunday qilib, agar siz s3-dagi ma'lumotlardan foydalanib, Spark klasterida biror narsani hisoblashingiz kerak bo'lsa, biz python/pyspark-da kod yozamiz, uni sinab ko'ramiz va bulutga omad tilaymiz.
Orkestr haqida nima deyish mumkin? Vazifa tushib, g'oyib bo'lsa-chi? Ha, Apache Pig uslubida chiroyli quvur liniyasini yaratish taklif qilinmoqda va biz hatto ularni sinab ko'rdik, ammo hozircha biz PHP va JavaScript-da chuqur moslashtirilgan orkestrimizdan foydalanishga qaror qildik (men tushunaman, kognitiv dissonans bor, lekin u ishlaydi, chunki yillar va xatosiz).
Ko'lda saqlangan fayllar formati ishlashning kalitidir
Yana ikkita asosiy fikrni tushunish juda muhim. Ko'ldagi fayl ma'lumotlari bo'yicha so'rovlar imkon qadar tezroq bajarilishi va yangi ma'lumotlar qo'shilganda unumdorlik pasaymasligi uchun sizga quyidagilar kerak:
- Fayllar ustunlarini alohida saqlang (ustunlarda nima borligini tushunish uchun barcha satrlarni o'qish shart emas). Buning uchun biz siqish bilan parket formatini oldik
- Fayllarni til, yil, oy, kun, hafta kabi papkalarga ajratish juda muhim. Ushbu turdagi shardingni tushunadigan dvigatellar ketma-ket barcha ma'lumotlarni elakdan o'tkazmasdan, faqat kerakli papkalarga qarashadi.
Asosan, shu tarzda siz yuqorida osilgan analitik dvigatellar uchun manba ma'lumotlarini eng samarali shaklda joylashtirasiz, ular hatto parchalangan papkalarda ham fayllardan faqat kerakli ustunlarni tanlab kiritishi va o'qishi mumkin. Ma'lumotni biron bir joyda "to'ldirish" shart emas (saqlash shunchaki yorilib ketadi) - darhol oqilona fayl tizimiga to'g'ri formatda joylashtiring. Albatta, bu erda aniq bo'lishi kerakki, DataLake-da ustunlarni olish uchun avval klaster tomonidan satr bo'yicha o'qilishi kerak bo'lgan ulkan csv faylni saqlash juda tavsiya etilmaydi. Bularning barchasi nima uchun sodir bo'layotgani hali aniq bo'lmasa, yuqoridagi ikkita fikrni yana bir bor o'ylab ko'ring.
AWS Athena - jak-in-the-box
Va keyin, ko'lni yaratishda biz tasodifan Amazon Afinaga duch keldik. To'satdan ma'lum bo'ldiki, bizning ulkan log fayllarimizni to'g'ri (parket) ustun formatidagi papka parchalariga ehtiyotkorlik bilan joylashtirish orqali siz ulardan juda tez ma'lumot beruvchi tanlovlarni amalga oshirishingiz va Apache Spark/Glue klasterisiz hisobotlarni yaratishingiz mumkin.
S3-dagi ma'lumotlar bilan ishlaydigan Athena dvigateli afsonaviyga asoslangan - s3 va Hadoop-dan Cassandra va oddiy matnli fayllargacha bo'lgan ma'lumotlarni olish, ma'lumotlarni qayta ishlashga yondashuvlar oilasining MPP (massive parallel processing) vakili. Siz shunchaki Afinadan SQL so'rovini bajarishni so'rashingiz kerak, keyin hamma narsa "tez va avtomatik ishlaydi". Shuni ta'kidlash kerakki, Afina "aqlli", u faqat kerakli shard papkalarga o'tadi va faqat so'rovda kerakli ustunlarni o'qiydi.
Afinaga so'rovlar uchun narxlar ham qiziq. Biz to'laymiz . Bular. daqiqada klasterdagi mashinalar soni uchun emas, balki... 100-500 ta mashinada haqiqatda skanerlangan ma'lumotlar uchun faqat so'rovni bajarish uchun zarur bo'lgan ma'lumotlar.
Va to'g'ri ajratilgan papkalardan faqat kerakli ustunlarni so'rash orqali, Afina xizmati oyiga o'nlab dollarga tushishi ma'lum bo'ldi. Klasterlar bo'yicha tahlillarga qaraganda ajoyib, deyarli bepul!
Aytgancha, biz ma'lumotlarimizni s3-da qanday taqsimlaymiz:
Natijada, qisqa vaqt ichida kompaniyaning mutlaqo boshqa bo'limlari, axborot xavfsizligidan tortib, tahliliygacha, Afinaga faol so'rovlar yubora boshladilar va bir necha soniya ichida juda uzoq vaqt davomida "katta" ma'lumotlardan foydali javoblarni olishdi: oylar, yarim yil va boshqalar P.
Ammo biz oldinga bordik va javoblar uchun bulutga borishni boshladik : tahlilchi tanish konsolda SQL so'rovini yozadi, u 100-500 ta mashinada "tinglar uchun" s3-ga ma'lumotlarni yuboradi va odatda bir necha soniya ichida javob qaytaradi. Qulay. Va tez. Haligacha ishonmayapman.
Natijada, ma'lumotlarni s3-da, samarali ustunli formatda va ma'lumotlarni papkalarga oqilona taqsimlash bilan saqlashga qaror qilib, biz DataLake va tez va arzon analitik dvigatelni oldik - bepul. Va u kompaniyada juda mashhur bo'ldi, chunki ... SQL-ni tushunadi va klasterlarni ishga tushirish/to'xtatish/o'rnatishdan ko'ra kattalikdagi buyurtmalarni tezroq ishlaydi. "Agar natija bir xil bo'lsa, nima uchun ko'proq pul to'lash kerak?"
Afinaga so'rov shunday ko'rinadi. Agar so'ralsa, albatta, siz etarli darajada shakllantirishingiz mumkin , lekin biz oddiy guruhlash bilan cheklanamiz. Keling, bir necha hafta oldin mijozning veb-server jurnallarida qanday javob kodlari borligini ko'rib chiqamiz va hech qanday xatolik yo'qligiga ishonch hosil qilamiz:
topilmalar
Uzoq, ammo og'riqli yo'lni bosib o'tib, xavf-xatarlarni va murakkablik darajasini va qo'llab-quvvatlash narxini doimiy ravishda baholab, biz DataLake va analitika uchun yechim topdik, bu bizni tezlik va egalik narxi bilan xursand qilishdan to'xtamaydi.
Ma'lum bo'lishicha, kompaniyaning mutlaqo boshqa bo'limlari ehtiyojlari uchun samarali, tez va arzon ishlaydigan DataLake qurish hatto hech qachon me'mor bo'lib ishlamagan va kvadratlarga kvadratchalar chizishni bilmagan tajribali dasturchilarning imkoniyatlariga to'liq kiradi. strelkalar va Hadoop ekotizimidan 50 ta atamani biling.
Sayohat boshida mening boshim ochiq va yopiq dasturiy ta'minotning ko'plab yovvoyi hayvonot bog'laridan va avlodlar oldidagi mas'uliyat yukini tushunishdan ajralib turardi. DataLake-ni oddiy vositalardan yaratishni boshlang: nagios/munin -> elastik/kibana -> Hadoop/Spark/s3..., fikr-mulohazalarni yig'ish va sodir bo'layotgan jarayonlar fizikasini chuqur tushunish. Hamma narsa murakkab va noaniq - uni dushmanlar va raqobatchilarga bering.
Agar siz bulutga o'tishni istamasangiz va ochiq manbali loyihalarni qo'llab-quvvatlash, yangilash va tuzatishni yoqtirsangiz, biznikiga o'xshash sxemani Hadoop va Presto o'rnatilgan arzon ofis mashinalarida qurishingiz mumkin. Asosiysi, to'xtamaslik va oldinga siljish, hisoblash, oddiy va aniq echimlarni izlash va hamma narsa albatta amalga oshadi! Hammaga omad va yana ko'rishguncha!
Manba: www.habr.com