Биз бир нече даяр ачык булак куралдарын тез жана оңой туташтыра ала турган укмуштуу мезгилде жашап жатабыз, аларды stackoverflow кеңешине ылайык, "бир нече тамгаларга" кирбестен, "аң-сезимиңиз өчүрүлгөн" абалда орнотуп, ишке киргизе аласыз. аларды коммерциялык пайдаланууга. Жана жаңыртуу/кеңейтүү керек болгондо же кимдир бирөө кокусунан бир нече машинаны кайра жүктөгөндө - кандайдыр бир обсессивдүү жаман түш башталганын, баары таанылгыс болуп кескин татаалдашып кеткенин, артка кайтууга болбойт, келечек бүдөмүк жана коопсуз, программалоонун ордуна аарыларды көбөйтүп, сыр кылгыла.
Тажрыйбалуу кесиптештери баштары мүчүлүштүктөр менен чачылып, ансыз деле боз болуп, "контейнерлердин" пакеттерин "кубдардагы" ондогон серверлерде орнотулган колдоосу менен "модалуу тилдердеги" укмуштуудай тез жайгаштыруу жөнүндө ойлонуп жатышканы бекер эмес. асинхрондук бөгөттөлбөгөн киргизүү/чыгаруу, жөнөкөй жылмайуу. Алар унчукпай "man ps" кайра окуй беришет, көздөрү канганга чейин "nginx" булак кодун изилдеп, бирдик тесттерин жазып, жазып, жаза беришет. Кесиптештер эң кызыктуусу жаңы жыл түнү түн ичинде “мунун баары” бир күнү ставкага айланганда болорун билишет. Аларга Unixтин табиятын терең түшүнүү, жаттап алынган TCP/IP абалы жана негизги сорттоо-издөө алгоритмдери гана жардам берет. Коңгуроо кагылганда системаны кайра жандандыруу үчүн.
Ооба, мен бир аз алаксып кеттим, бирок күтүү абалын жеткире алдым деп ишенем.
Бүгүн мен DataLake үчүн ыңгайлуу жана арзан стекти жайылтуу боюнча тажрыйбабыз менен бөлүшкүм келет, ал компанияда такыр башка структуралык бөлүмдөр үчүн аналитикалык тапшырмалардын көпчүлүгүн чечет.
Бир нече убакыт мурун, биз компанияларга продукциянын да, техникалык аналитиканын да жемиштерине (машина үйрөнүү түрүндөгү торттогу глазурь жөнүндө айтпай эле коелу) жана тенденцияларды жана тобокелдиктерди түшүнүү үчүн көбүрөөк керек экендигин түшүндүк - биз чогултуп, талдообуз керек. барган сайын көбүрөөк көрсөткүчтөр.
Bitrix24 ичиндеги негизги техникалык аналитика
Бир нече жыл мурун, Bitrix24 кызматын ишке киргизүү менен бир эле убакта биз инфраструктурадагы көйгөйлөрдү тез көрүүгө жана кийинки кадамды пландаштырууга жардам бере турган жөнөкөй жана ишенимдүү аналитикалык платформаны түзүүгө убакытты жана ресурстарды активдүү жумшадык. Албетте, мүмкүн болушунча жөнөкөй жана түшүнүктүү болгон даяр куралдарды алуу максатка ылайыктуу болгон. Натыйжада, мониторинг үчүн нагиос, аналитика жана визуализация үчүн мунин тандалды. Азыр бизде нагиодо миндеген чектер, мунинде жуздогон диаграммалар бар жана биздин кесиптештерибиз аларды кун сайын ийгиликтуу пайдаланып жатышат. Метрикалар так, графиктер так, система бир нече жылдан бери ишенимдүү иштеп жатат жана ага жаңы тесттер жана графиктер үзгүлтүксүз кошулуп турат: жаңы кызматты ишке киргизгенде, биз бир нече тесттерди жана графиктерди кошобуз. Жолуңуз ачык болсун.
Пульстагы манжа - Өркүндөтүлгөн техникалык аналитика
Көйгөйлөр жөнүндө маалыматты "мүмкүн болушунча тезирээк" алуу каалоосу бизди жөнөкөй жана түшүнүктүү куралдар - pinba жана xhprof менен активдүү эксперименттерге алып келди.
Пинба бизге PHPдеги веб-баракчалардын бөлүктөрүнүн иштөө ылдамдыгы жөнүндө статистиканы UDP пакеттеринде жөнөттү жана биз MySQL сактагычынан онлайн көрө алдык (Pinba окуянын тез анализи үчүн өзүнүн MySQL кыймылдаткычы менен келет) көйгөйлөрдүн кыскача тизмесин жана жооп берди. алар. Ал эми xhprof бизге автоматтык түрдө кардарлардан эң жай PHP барактарынын аткарылышынын графиктерин чогултууга жана буга эмне алып келиши мүмкүн экенин талдап чыгууга мүмкүндүк берди - тынч, чай же күчтүүрөөк бир нерсе куюп.
Бир нече убакыт мурун, инструменттер топтому легендарлуу Lucene китепканасында - Elastic/Kibana-да эң сонун ишке ашырылган тескери индекстөө алгоритмине негизделген дагы бир жөнөкөй жана түшүнүктүү кыймылдаткыч менен толукталган. Журналдардагы окуялардын негизинде документтерди тескери Lucene индексине көп жиптүү жазуунун жөнөкөй идеясы жана фасеттик бөлүүнү колдонуу менен алар аркылуу тез издөө чындыгында пайдалуу болду.
Кибанадагы визуализациялардын анча-мынча техникалык көрүнүшүнө карабастан, "чака" "өйдө аккан" сыяктуу төмөн деңгээлдеги түшүнүктөр жана али толук унутула элек реляциялык алгебранын кайра ойлоп табылган тили болгонуна карабастан, курал төмөнкү тапшырмаларды аткарууда жакшы жардам бере баштады:
- Акыркы саатта Bitrix24 кардарында p1 порталында канча PHP катасы болгон жана кайсынысы? Түшүнүп, кечирип, тез оңдоңуз.
- Германияда өткөн 24 сааттын ичинде порталдарда канча видео чалуу болду, кандай сапатта жана каналда/тармакта кыйынчылыктар болдубу?
- Кызматтын акыркы жаңыртууларында булактан топтолгон жана кардарларга жайылтылган тутумдун иштеши (PHP үчүн биздин C кеңейтүүбүз) канчалык жакшы иштейт? Мүмкүнчүлүктөр барбы?
- Кардар маалыматтары PHP эс тутумуна туура келеби? Процесстерге бөлүнгөн эстутумдан ашкан каталар барбы: "эс тутумда жок"? Табып, нейтралдаштыруу.
Мына конкреттүү мисал. Кылдат жана көп деңгээлдүү тестирлөөгө карабастан, кардар, өтө стандарттуу эмес корпусу жана бузулган кириш маалыматтары менен, тажатма жана күтүлбөгөн катаны кабыл алды, сирена угулуп, аны тез оңдоо процесси башталды:
Кошумчалай кетсек, кибана көрсөтүлгөн окуялар үчүн эскертмелерди уюштурууга мүмкүндүк берет жана кыска убакыттын ичинде компаниядагы инструмент ар кандай бөлүмдөрдүн ондогон кызматкерлери тарабынан колдонула баштады - техникалык колдоо жана өнүктүрүүдөн баштап QA.
Компаниянын ичиндеги каалаган бөлүмдүн ишмердүүлүгүн көзөмөлдөө жана өлчөө ыңгайлуу болуп калды - серверлердеги журналдарды кол менен анализдөөнүн ордуна, сиз жөн гана бир жолу талдоо журналдарын орнотуп, аларды ийкемдүү кластерге жөнөтүшүңүз керек, мисалы, кибанада ой жүгүртүү. акыркы ай ичинде 3-D принтерде басылган сатылган эки баштуу мышыктардын саны.
Бизнестин негизги аналитикасы
Компаниялардагы бизнес-аналитика көбүнчө Excel программасын өтө активдүү колдонуу менен башталарын баары билет. Бирок негизги нерсе муну менен эле бүтпөйт. Булуттагы Google Analytics да отко май кошот - сиз жакшы нерселерге бат көнүп баштайсыз.
Биздин гармониялуу өнүгүп жаткан компаниябызда чоңураак маалыматтар менен интенсивдүү иштеген “пайгамбарлар” пайда боло баштады. Тереңирээк жана көп кырдуу отчеттордун зарылдыгы үзгүлтүксүз пайда боло баштады жана ар кандай бөлүмдөрдүн жигиттеринин аракеттери менен бир нече убакыт мурун жөнөкөй жана практикалык чечим уюштурулган - ClickHouse жана PowerBI айкалышы.
Узак убакыт бою бул ийкемдүү чечим көп жардам берди, бирок бара-бара ClickHouse резина эмес жана аны шылдыңдап коюуга болбойт деген түшүнүк келе баштады.
Бул жерде ClickHouse, Druid сыяктуу, Vertica сыяктуу, Amazon RedShift сыяктуу (постгресске негизделген) кыйла ыңгайлуу аналитика үчүн оптималдаштырылган аналитикалык кыймылдаткычтар экенин жакшы түшүнүү керек (суммалар, агрегаттар, мамычалар боюнча минималдуу-максималдуу жана бир нече мүмкүн кошулуулар). ), анткени MySQL жана бизге белгилүү болгон башка (сапка багытталган) маалымат базаларынан айырмаланып, реляциялык таблицалардын мамычаларын натыйжалуу сактоо үчүн уюштурулган.
Түпкүлүгүндө, ClickHouse - бул жөн гана сыйымдуулуктагы "маалыматтар базасы", өтө ыңгайлуу эмес, чекиттен пунктка киргизүү (бул ушундай, баары жакшы), бирок жагымдуу аналитика жана маалыматтар менен иштөө үчүн кызыктуу күчтүү функциялардын жыйындысы. Ооба, сиз кластер түзө аласыз, бирок сиз микроскоп менен мыктарды согуу таптакыр туура эмес экенин түшүндүңүз жана биз башка чечимдерди издей баштадык.
Питон жана аналитиктерге суроо-талап
Биздин компанияда PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash тилдеринде 10-20 жыл бою дээрлик күн сайын код жаза турган көптөгөн иштеп чыгуучулар бар. Статистика мыйзамдарына туура келбеген бир нече абсолюттук кырсыкты башынан өткөргөн көптөгөн тажрыйбалуу системалык администраторлор бар (мисалы, рейд-10догу дисктердин көпчүлүгү чагылгандын соккусунан талкаланганда). Мындай шарттарда, узак убакыт бою "питон аналитик" деген эмне экени белгисиз болчу. Python PHP сыяктуу, аты гана бир аз узунураак жана котормочунун баштапкы кодунда акыл-эсти өзгөртүүчү заттардын бир аз азыраак издери бар. Бирок, барган сайын аналитикалык отчеттор түзүлгөн сайын, тажрыйбалуу иштеп чыгуучулар numpy, pandas, matplotlib, seaborn сыяктуу куралдарда тар адистештирүүнүн маанилүүлүгүн түшүнө башташты.
Чечүүчү ролду, кыязы, кызматкерлердин күтүлбөгөн жерден эс-учун жоготуп, “логистикалык регрессия” деген сөздүн айкалышы жана чоң маалыматтар боюнча эффективдүү отчеттуулуктун, ооба, ооба, pyspark аркылуу көрсөтүүсү ойногон.
Apache Spark, анын функционалдык парадигмасы, ага реляциялык алгебра эң сонун дал келет жана анын мүмкүнчүлүктөрү MySQLге көнүп калган иштеп чыгуучуларга ушунчалык таасир калтыргандыктан, катарларды тажрыйбалуу аналитиктер менен бекемдөө зарылчылыгы күн өткөн сайын айкын болуп калды.
Apache Spark/Hadoopтун андан аркы учуп кетүү аракеттери жана эмнелер сценарийге ылайык болгон жок
Бирок, көп өтпөй Spark менен бир нерсе системалуу түрдө туура эмес экени, же жөн гана колду жакшыраак жууш керек экени айкын болду. Эгерде Hadoop/MapReduce/Lucene стеги тажрыйбалуу программисттер тарабынан жасалган болсо, бул Javaдагы баштапкы кодду же Дуг Каттингдин Luceneдеги идеяларын кылдаттык менен карасаңыз, анда Spark күтүлбөгөн жерден Scala экзотикалык тилинде жазылган. практикалык көз карашынан алганда абдан талаштуу жана учурда өнүкпөй жатат. Жана кыскартуу операциялары үчүн эстутум бөлүштүрүү менен логикасыз жана өтө ачык эмес иштөөдөн улам Spark кластериндеги эсептөөлөрдүн үзгүлтүксүз төмөндөшү (көптөгөн баскычтар дароо келет) анын айланасында өсө турган жери бар нерсенин ореолун жаратты. Кошумчалай кетсек, кырдаалды көп сандаган кызыктай ачык порттор, эң түшүнүксүз жерлерде өскөн убактылуу файлдар жана тозокко көз карандылык курчуткан - бул системалык администраторлордо бала кезинен эле белгилүү болгон бир сезимди пайда кылган: катуу жек көрүү (же балким). колдорун самын менен жууш керек болчу).
Натыйжада, биз Apache Spark (анын ичинде Spark Streaming, Spark SQL) жана Hadoop экосистемасын (ж. Убакыттын өтүшү менен биз “аны” жакшылап даярдап, көзөмөлдөгөндү үйрөнгөнүбүзгө жана “ал” иш жүзүндө күтүлбөгөн жерден иштебей калганына карабастан, маалыматтардын табиятынын өзгөрүшүнө жана бирдиктүү RDD хэшингинин дисбалансынан улам, даяр нерсени алуу каалоосу. , булуттун кайсы бир жеринде жаңыртылган жана башкарылган күчөгөн сайын күчөдү. Дал ушул убакта биз Amazon Web Services даяр булут жыйынын колдонууга аракет кылдык - жана, андан кийин, аны колдонуу менен көйгөйлөрдү чечүүгө аракет кылышкан. EMR бул Cloudera/Hortonworks курган сыяктуу экосистеманын кошумча программасы менен Amazon тарабынан даярдалган Apache Spark.
Аналитика үчүн резинадан жасалган файлдарды сактоо өтө зарыл
Дененин ар кайсы жерлери күйгөн Hadoop/Spark "бышыруу" тажрыйбасы текке кеткен жок. Аппараттык камсыздоонун бузулууларына туруштук бере турган жана ар кандай системалардан ар кандай форматта файлдарды сактоого жана бул маалыматтардан отчеттор үчүн эффективдүү жана убакытты үнөмдөөчү үлгүлөрдү түзүүгө мүмкүн болгон бирдиктүү, арзан жана ишенимдүү файл сактагычын түзүү зарылдыгы барган сайын күчөдү. ачык.
Мен ошондой эле бул платформанын программалык камсыздоосун жаңыртуу 20 барактан турган Java издерин окуу жана Spark History Server жана арткы жарыктандыргыч лупанын жардамы менен кластердин километрге созулган деталдуу журналдарын талдоо менен Жаңы жылдын коркунучтуу түшүнө айланбасын дегем. Мен жөнөкөй жана тунук куралга ээ болгум келди, ал капоттун астына үзгүлтүксүз сууга түшүүнү талап кылбаган, эгерде иштеп чыгуучунун стандарттуу MapReduce өтүнүчү аткарылбай калганда, маалымат кыскартуу кызматкеринин эс тутуму жакшы тандалбагандыктан, булактагы маалыматтарды бөлүштүрүү алгоритминен улам иштебей калса.
Amazon S3 DataLake үчүн талапкерби?
Hadoop/MapReduce менен болгон тажрыйба бизге масштабдуу, ишенимдүү файлдык тутумга жана маалыматтарды тармак аркылуу айдап албаш үчүн берилиштерге жакындап, анын үстүнө масштабдалуучу жумушчулар керек экенин үйрөттү. Жумушчулар ар кандай форматтагы маалыматтарды окуй алышы керек, бирок ашыкча керексиз маалыматты окубашы керек жана маалыматтарды жумушчулар үчүн ыңгайлуу форматтарда алдын ала сактоо мүмкүнчүлүгүнө ээ болушу керек.
Дагы бир жолу, негизги идея. Чоң маалыматтарды бир кластердик аналитикалык кыймылдаткычка "куюуга" эч кандай каалоо жок, ал эртеби-кечпи муунтуп калат жана сиз аны жаман сындырууга туура келет. Мен файлдарды, жөн гана файлдарды, түшүнүктүү форматта сактап, ар кандай, бирок түшүнүктүү куралдарды колдонуу менен аларга эффективдүү аналитикалык сурамдарды аткаргым келет. Жана ар кандай форматтагы файлдар дагы көп болот. Ал эми кыймылдаткычты эмес, баштапкы маалыматтарды сындырган жакшы. Бизге кеңейүүчү жана универсалдуу DataLake керек, биз чечтик...
Эгер сиз Hadoop'тон өзүңүздүн котлеттериңизди даярдабай туруп, Amazon S3 масштабдуу булут сактагычында файлдарды сактасаңызчы?
Жеке маалыматтар "төмөн" экени түшүнүктүү, бирок биз аны алып чыгып, "аны эффективдүү айдасак" башка маалыматтар жөнүндө эмне айтууга болот?
Amazon Web Services Cluster-bigdata-analytics экосистемасы - абдан жөнөкөй сөздөр менен
AWS менен болгон тажрыйбабызга караганда, Apache Hadoop/MapReduce ал жерде көптөн бери ар кандай соустардын астында жигердүү колдонулуп келет, мисалы DataPipeline сервисинде (мен кесиптештериме кызганам, алар аны кантип туура даярдоону үйрөнүштү). Бул жерде биз DynamoDB таблицаларынан ар кандай кызматтардын камдык көчүрмөлөрүн орнотобуз:
Жана алар бир нече жылдан бери саат механизми сыяктуу орнотулган Hadoop/MapReduce кластерлеринде үзгүлтүксүз иштеп келишет. "Аны коюп, аны унутуп":
Сиз ошондой эле аналитиктер үчүн булуттагы Юпитер ноутбуктарын орнотуу жана AI моделдерин согушка үйрөтүү жана жайылтуу үчүн AWS SageMaker кызматын колдонуу менен маалымат сатанизмине натыйжалуу катыша аласыз. Бул биз үчүн кандай көрүнөт:
Ооба, сиз өзүңүзгө же булуттагы аналитикке ноутбук алып, аны Hadoop/Spark кластерине туташтырсаңыз болот, эсептөөлөрдү жүргүзүп, анан бардыгын түптөй аласыз:
Жеке аналитикалык долбоорлор үчүн чындап ыңгайлуу, ал эми кээ бирлери үчүн чоң масштабдагы эсептөөлөр жана аналитика үчүн EMR кызматын ийгиликтүү колдондук. DataLake үчүн системалык чечим жөнүндө эмне айтууга болот, ал иштейби? Ушул учурда биз үмүт менен үмүтсүздүктүн чегинде болуп, издөөнү уланта бердик.
AWS клей - стероиддерге тыкан пакеттелген Apache Spark
Көрсө, AWSтин "Hive/Pig/Spark" стекинин өзүнүн версиясы бар экен. Уюктун ролу, б.а. DataLakeдеги файлдардын каталогун жана алардын түрлөрүн Apache Hive форматына шайкештигин жашырбаган “Маалымат каталогу” кызматы аткарат. Сиз бул кызматка файлдарыңыз кайда жайгашканы жана алар кандай форматта экени тууралуу маалыматты кошушуңуз керек. Маалыматтар s3 гана эмес, маалымат базасында да болушу мүмкүн, бирок бул посттун темасы эмес. Бул жерде биздин DataLake маалымат каталогу кантип уюштурулган:
Файлдар катталган, сонун. Эгерде файлдар жаңыртылган болсо, биз жөрмөлөгүчтөрдү кол менен же график боюнча ишке киргизебиз, алар көлдөн алар тууралуу маалыматты жаңыртып, сактап калат. Андан кийин көлдүн маалыматтарын иштетип, жыйынтыгын бир жерге жүктөсө болот. Эң жөнөкөй учурда, биз дагы s3ке жүктөйбүз. Маалыматтарды иштетүү каалаган жерден жасалышы мүмкүн, бирок AWS Glue API аркылуу өркүндөтүлгөн мүмкүнчүлүктөрдү колдонуу менен Apache Spark кластеринде иштетүүнү конфигурациялоо сунушталат. Чындыгында, сиз pyspark китепканасынын жардамы менен эски жана тааныш Python кодун алып, Hadoopтун ичине кирип, докер-мокер контейнерлерин сүйрөп, көз карандылыктын чыр-чатактарын жок кылбастан, мониторинг менен кандайдыр бир кубаттуулуктагы кластердин N түйүндөрүндө аткарылышын конфигурациялай аласыз. .
Дагы бир жолу, жөнөкөй идея. Apache Spark конфигурациялоонун кереги жок, сиз жөн гана pyspark үчүн python кодун жазып, аны иш тактаңызда локалдуу түрдө сынап, андан соң булактагы маалыматтар кайда экенин жана натыйжаны кайда коюуну көрсөтүп, аны булуттагы чоң кластерде иштетишиңиз керек. Кээде бул зарыл жана пайдалуу болот, биз аны кантип орнотобуз:
Ошентип, эгер сизге Spark кластеринде s3деги маалыматтарды колдонуу менен бир нерсени эсептөө керек болсо, биз python/pyspark ичинде код жазып, аны сынап көрөбүз жана булутка ийгилик каалайбыз.
Оркестр жөнүндө эмне айтууга болот? Эгер тапшырма түшүп, жок болуп кетсечи? Ооба, Apache Pig стилинде кооз трубаны жасоо сунушталууда жана биз аларды сынап көрдүк, бирок азыр биз PHP жана JavaScript тилдеринде терең ыңгайлаштырылган оркестрибизди колдонууну чечтик (мен түшүнөм, когнитивдик диссонанс бар, бирок ал иштейт, анткени жыл жана катасыз).
Көлгө сакталган файлдардын форматы аткаруунун ачкычы болуп саналат
Дагы эки негизги ойду түшүнүү абдан маанилүү. Көлдөгү файл маалыматтары боюнча суроо-талаптар мүмкүн болушунча тезирээк аткарылышы жана жаңы маалымат кошулгандан кийин иштин начарлашы үчүн сизге төмөнкүлөр керек:
- Файлдардын тилкелерин өзүнчө сактаңыз (мамычаларда эмне бар экенин түшүнүү үчүн бардык саптарды окуунун кажети жок). Бул үчүн биз кысуу менен паркет форматын алдык
- Файлдарды папкаларга бөлүү абдан маанилүү: тил, жыл, ай, күн, жума. Мындай сындырууну түшүнгөн кыймылдаткычтар бардык маалыматтарды катары менен электен өткөрбөй, керектүү папкаларды гана карашат.
Чындыгында, ушундай жол менен, сиз аналитикалык кыймылдаткычтар үчүн эң эффективдүү түрдө баштапкы маалыматтарды жайгаштырасыз, алар атүгүл майдаланган папкаларда файлдардан керектүү тилкелерди гана тандап кирип, окуй алат. Маалыматты эч жерде "толтуруунун" кереги жок (сактоо жөн эле жарылып кетет) - жөн гана туура форматта файл тутумуна дароо акылдуулук менен салыңыз. Албетте, бул жерде чоң csv файлын DataLakeде сактоо ачык болушу керек, ал тилкелерди алуу үчүн алгач кластер тарабынан саптан сап окулушу керек. Мунун баары эмне үчүн болуп жатканы азырынча түшүнүксүз болсо, жогорудагы эки пунктту дагы бир жолу ойлонуп көрүңүз.
AWS Athena - кутудагы джек
Анан көлдү жаратып жатып, биз кокусунан Амазонка Афинага туш болуп калдык. Күтүлбөгөн жерден биздин чоң журнал файлдарыбызды туура (паркет) тилке форматындагы папка сыныктарына кылдаттык менен жайгаштыруу менен, сиз алардан өтө маалыматтуу тандоолорду жасап, Apache Spark/Glue кластерисиз эле отчетторду түзө аласыз.
S3 ичиндеги маалыматтар менен иштеген Athena кыймылдаткычы легендарлууга негизделген - MPP (массивдүү параллель иштетүү) үй-бүлөсүнүн өкүлү, s3 жана Hadoop жана Cassandra жана жөнөкөй тексттик файлдарга чейин маалыматтарды ал жаткан жерде алып, маалыматтарды иштеп чыгууга. Сиз жөн гана Athenaдан SQL сурамын аткарууну суранышыңыз керек, анан баары "тез жана автоматтык түрдө иштейт". Бул Athena "акылдуу" экенин белгилей кетүү маанилүү, ал гана зарыл сынык папкаларга барат жана суроо-талапка керектүү тилкелерди гана окуйт.
Афинага кайрылуулардын баасы да кызыктуу. Биз төлөйбүз . Ошол. мүнөтүнө кластердеги машиналардын саны үчүн эмес, бирок... 100-500 машинада чындыгында сканерленген маалыматтар үчүн, суроо-талапты аткаруу үчүн зарыл болгон маалыматтар гана.
Жана туура бөлүштүрүлгөн папкалардан керектүү тилкелерди гана талап кылуу менен, Athena кызматы бизге айына ондогон долларды түзөт экен. Кластерлердеги аналитикага салыштырмалуу сонун, дээрлик бекер!
Айтмакчы, бул жерде биз s3 ичинде маалыматтарыбызды бөлүштүрөбүз:
Натыйжада, кыска убакыттын ичинде, компаниянын такыр башка бөлүмдөрү, маалыматтык коопсуздуктан аналитикага чейин, Athenaга жигердүү суроо-талаптарды бере башташты жана тез, секунданын ичинде, бир топ узак мезгилдерде "чоң" маалыматтардан пайдалуу жоопторду ала башташты: айлар, жарым жыл жана башкалар П.
Бирок биз андан ары кетип, жооп алуу үчүн булуттун жанына бара баштадык : аналитик SQL суроосун тааныш консолдо жазат, ал 100-500 машинада "тыйындарга" маалыматтарды s3ке жөнөтөт жана жоопту адатта бир нече секунданын ичинде кайтарат. Ыңгайлуу. Жана тез. Мен дагы деле ишене албайм.
Натыйжада, маалыматтарды s3 форматында сактоону чечип, эффективдүү мамычалык форматта жана маалыматтарды папкаларга туура бөлүштүрүү менен... биз DataLake жана тез жана арзан аналитикалык кыймылдаткычты алдык – бекер. Жана ал компанияда абдан популярдуу болуп калды, анткени... SQLди түшүнөт жана кластерлерди баштоо/токтотууга/орнотууга караганда ылдамыраак иштейт. "Эгер натыйжа бирдей болсо, эмне үчүн көбүрөөк төлөш керек?"
Афинага болгон өтүнүч ушуга окшош. Кааласаңыз, албетте, жетиштүү түрдө түзө аласыз , бирок биз жөнөкөй топтоштуруу менен чектелебиз. Келгиле, бир нече жума мурун кардар веб-сервер журналдарында кандай жооп коддору болгонун карап көрөлү жана эч кандай ката жок экенин текшерип көрөлү:
табылгалары
Узак, бирок азаптуу жолду басып өткөндөн кийин, тобокелдиктерди жана татаалдыктын деңгээлин жана колдоонун баасын ар дайым адекваттуу баалап, биз DataLake жана аналитика үчүн чечим таптык, ал бизди ылдамдыгы менен да, ээлик кылуу наркы менен да кубандырбай койбойт.
Компаниянын такыр башка бөлүмдөрүнүн муктаждыктары үчүн эффективдүү, тез жана арзан иштей турган DataLake куруу толугу менен архитектор болуп иштебеген жана квадраттарга квадраттарды кантип тартууну билбеген тажрыйбалуу иштеп чыгуучулардын мүмкүнчүлүктөрүндө экени белгилүү болду. жебелер жана Hadoop экосистемасынан 50 терминди билесиз.
Саякаттын башында менин башым ачык жана жабык программалык камсыздоонун жана урпактардын алдындагы жоопкерчилик жүгүн түшүнгөн көптөгөн жапайы зоопарктардан бөлүнүп калды. Жөнөкөй куралдардан өзүңүздүн DataLake түзө баштаңыз: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., пикир чогултуу жана болуп жаткан процесстердин физикасын терең түшүнүү. Баары татаал жана бүдөмүк - аны душмандарга жана атаандаштарга бер.
Эгер сиз булутка баргыңыз келбесе жана ачык булактуу долбоорлорду колдоону, жаңыртууну жана оңдоону жактырсаңыз, биздикине окшош схеманы Hadoop жана Presto менен кымбат эмес кеңсе машиналарында кура аласыз. Эң негизгиси, токтоп калбаңыз жана алдыга жылыңыз, санаңыз, жөнөкөй жана так чечимдерди издеңиз, ошондо баары сөзсүз түрдө ишке ашат! Баарыңарга ийгилик жана дагы көрүшкөнчө!
Source: www.habr.com