Біз бірнеше дайын ашық бастапқы құралдарды жылдам және оңай қосуға, оларды stackoverflow кеңесіне сәйкес «бірнеше әріптерге» кірмей-ақ «сананы өшіру» күйінде орнатуға және іске қосуға болатын таңғажайып уақытта өмір сүріп жатырмыз. оларды коммерциялық пайдалануға. Жаңарту/кеңейту қажет болғанда немесе біреу кездейсоқ бірнеше машинаны қайта жүктегенде - сіз қандай да бір обсессивті жаман арманның шын мәнінде басталғанын түсінесіз, бәрі кенеттен адам танымастай күрделене түсті, кері қайтару жоқ, болашақ бұлыңғыр. және қауіпсіз, бағдарламалаудың орнына араларды көбейтіп, ірімшік жасаңыз.
Тәжірибелі әріптестердің бастары қателіктерге толы, сондықтан қазірдің өзінде сұр түсті, «контейнерлер» бумаларын «сәнді тілдердегі» ондаған серверлерде «текшелерде» өте жылдам орналастыруды ойластырып жатқаны бекер емес. асинхронды блокталмаған енгізу/шығару, қарапайым күлімдеу. Олар үнсіз «man ps» қайта оқуды жалғастырады, көздері қанғанша «nginx» бастапқы кодын зерттейді және бірлік сынақтарын жазады, жазады, жазады. Әріптестер «бәрі осының» бір күні Жаңа жыл қарсаңында түнде қадағаланатын кезде болатынын біледі. Және оларға тек unix табиғатын терең түсіну, есте сақталған TCP/IP күй кестесі және негізгі сұрыптау-іздеу алгоритмдері көмектеседі. Қоңыраулар соққан кезде жүйені қалпына келтіру үшін.
Иә, мен біраз алаңдадым, бірақ күту күйін жеткізе алдым деп үміттенемін.
Бүгін мен мүлдем басқа құрылымдық бөлімшелер үшін компаниядағы аналитикалық тапсырмалардың көпшілігін шешетін DataLake үшін ыңғайлы және қымбат емес стекті қолдану тәжірибесімен бөліскім келеді.
Біраз уақыт бұрын біз компанияларға өнімнің де, техникалық аналитиканың да жемісін (машиналық оқыту түріндегі торттағы глазурьді айтпағанда) көбірек қажет ететінін түсіндік және трендтер мен тәуекелдерді түсіну үшін - жинап, талдау керек. барған сайын көбірек көрсеткіштер.
Bitrix24-тегі негізгі техникалық аналитика
Бірнеше жыл бұрын Bitrix24 қызметін іске қосумен бір мезгілде біз инфрақұрылымдағы мәселелерді жылдам көруге және келесі қадамды жоспарлауға көмектесетін қарапайым және сенімді аналитикалық платформаны құруға уақыт пен ресурстарды белсенді түрде жұмсадық. Әрине, мүмкіндігінше қарапайым және түсінікті дайын құралдарды алған жөн. Нәтижесінде мониторинг үшін nagios, ал аналитика мен визуализация үшін мунин таңдалды. Қазір бізде нагиоларда мыңдаған чектер, мунинде жүздеген диаграммалар бар және біздің әріптестер оларды күн сайын сәтті пайдаланады. Көрсеткіштер анық, графиктер анық, жүйе бірнеше жылдар бойы сенімді жұмыс істейді және оған жаңа сынақтар мен графиктер үнемі қосылып отырады: біз жаңа қызметті іске қосқан кезде біз бірнеше сынақтар мен графиктерді қосамыз. Сәт сапар.
Импульстағы саусақ - Жетілдірілген техникалық талдау
Мәселелер туралы ақпаратты «мүмкіндігінше тез» алуға деген ұмтылыс бізді қарапайым және түсінікті құралдармен - pinba және xhprof көмегімен белсенді эксперименттерге әкелді.
Pinba бізге 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 тіліндегі бастапқы кодқа немесе Дуг Кутингтің Луцендегі идеяларына мұқият қарасаңыз, онда 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 кластерлік-үлкен деректер-аналитикалық экожүйе - өте қарапайым сөзбен айтқанда
AWS-пен тәжірибемізге сүйенсек, Apache Hadoop/MapReduce онда ұзақ уақыт бойы әртүрлі соустар астында белсенді түрде қолданылған, мысалы, DataPipeline сервисінде (мен әріптестеріме қызғанамын, олар оны қалай дұрыс дайындау керектігін үйренді). Мұнда біз DynamoDB кестелерінен әртүрлі қызметтерден сақтық көшірмелерді орнатамыз:
Олар бірнеше жылдан бері сағат механизмі сияқты ендірілген Hadoop/MapReduce кластерлерінде жүйелі түрде жұмыс істейді. «Оны орнатыңыз және оны ұмытыңыз»:
Сондай-ақ, сарапшылар үшін бұлттағы Jupiter ноутбуктерін орнату және AI үлгілерін шайқаста жаттықтыру және орналастыру үшін AWS SageMaker қызметін пайдалану арқылы деректер сатанизмімен тиімді айналысуға болады. Міне, ол бізге ұқсайды:
Иә, сіз өзіңізге немесе бұлттағы аналитикке ноутбук алып, оны Hadoop/Spark кластеріне тіркей аласыз, есептеулерді жасай аласыз, содан кейін бәрін шеге аласыз:
Жеке аналитикалық жобалар үшін өте ыңғайлы, ал кейбіреулер үшін біз ауқымды есептеулер мен аналитика үшін EMR қызметін сәтті қолдандық. DataLake үшін жүйелік шешім туралы не айтасыз, ол жұмыс істей ме? Осы сәтте біз үміт пен үмітсіздіктің шегіне жетіп, іздеуді жалғастырдық.
AWS желім - стероидтерге ұқыпты оралған Apache Spark
AWS-де «Hive/Pig/Spark» стекінің өзіндік нұсқасы бар екені белгілі болды. Hive рөлі, яғни. 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-те терең теңшелген оркестрді пайдалануды шештік (мен түсінемін, когнитивті диссонанс бар, бірақ ол жұмыс істейді, өйткені жылдар және қатесіз).
Көлде сақталған файлдардың пішімі өнімділіктің кілті болып табылады
Тағы екі негізгі ойды түсіну өте маңызды. Көлдегі файл деректері бойынша сұраулар мүмкіндігінше жылдам орындалуы және жаңа ақпарат қосылған кезде өнімділік төмендемеуі үшін сізге қажет:
- Файлдардың бағандарын бөлек сақтаңыз (бағандарда не бар екенін түсіну үшін барлық жолдарды оқудың қажеті жоқ). Ол үшін қысу арқылы паркет пішімін алдық
- Файлдарды қалталарға бөлу өте маңызды: тіл, жыл, ай, күн, апта. Шардингтің бұл түрін түсінетін қозғалтқыштар қатардағы барлық деректерді електен өткізбей, тек қажетті қалталарды қарайды.
Негізінде, осылайша сіз үстіңгі жағында ілулі тұрған аналитикалық қозғалтқыштар үшін бастапқы деректерді ең тиімді пішінде орналастырасыз, олар тіпті ұсақталған қалталарда файлдардан тек қажетті бағандарды таңдап енгізе және оқи алады. Деректерді кез келген жерде «толтырудың» қажеті жоқ (жад жай ғана жарылып кетеді) - оны файлдық жүйеге дұрыс пішімде дереу салыңыз. Әрине, бұл жерде DataLake-те үлкен csv файлын сақтау анық болуы керек, ол алдымен бағандарды шығару үшін кластер арқылы жол бойынша оқылуы керек. Мұның бәрі неліктен болып жатқаны әлі түсініксіз болса, жоғарыдағы екі тармақты қайта ойланыңыз.
AWS Athena - ұяшықтағы ұяшық
Содан кейін, көлді құру кезінде біз кездейсоқ Amazon Athena-ға тап болдық. Кенеттен белгілі болды, біздің үлкен журнал файлдарымызды дұрыс (паркет) баған пішіміндегі қалта бөліктеріне мұқият орналастыра отырып, сіз олардан өте ақпараттандыратын таңдаулар жасай аласыз және Apache Spark/Glue кластерінсіз есептерді жасай аласыз.
s3 деректерімен жұмыс істейтін Athena қозғалтқышы аңызға негізделген - s3 және Hadoop-тан Кассандраға және қарапайым мәтіндік файлдарға дейінгі деректерді алатын, деректерді өңдеуге арналған MPP (массивті параллель өңдеу) тәсілдер тобының өкілі. Сізге тек Афинадан SQL сұрауын орындауды сұрау керек, содан кейін бәрі «тез және автоматты түрде жұмыс істейді». Афинаның «ақылды» екенін, ол тек қажетті бөлшектелген қалталарға өтіп, сұрауда қажет бағандарды ғана оқитынын атап өткен жөн.
Афинаға сұраныстардың бағасы да қызықты. Біз төлейміз . Анау. минутына кластердегі машиналар саны үшін емес, бірақ... 100-500 машинада нақты сканерленген деректер үшін сұрауды орындау үшін қажетті деректер ғана.
Дұрыс бөлінген қалталардан тек қажетті бағандарды сұрау арқылы Athena қызметі бізге айына ондаған долларды құрайтыны белгілі болды. Кластерлердегі аналитикамен салыстырғанда тамаша, тегін дерлік!
Айтпақшы, s3 ішінде деректерімізді бөлісу әдісі:
Нәтижесінде, қысқа уақыт ішінде компанияның ақпараттық қауіпсіздіктен аналитикаға дейін мүлдем басқа бөлімдері Афинаға белсенді түрде сұраныстар жасай бастады және тез арада, бірнеше секундта жеткілікті ұзақ уақыт бойы «үлкен» деректерден пайдалы жауаптар алды: айлар, жарты жыл және т.б. П.
Бірақ біз әрі қарай жүріп, жауаптар үшін бұлтқа бара бастадық : талдаушы таныс консольде SQL сұрауын жазады, ол 100-500 машиналарда «тиындар үшін» деректерді s3-ке жібереді және әдетте бірнеше секундта жауапты қайтарады. Ыңғайлы. Және тез. Мен әлі де сене алар емеспін.
Нәтижесінде, деректерді s3 форматында, тиімді бағаналы форматта және деректерді қалталарға бөлу арқылы сақтауды ұйғарып, біз DataLake және жылдам әрі арзан аналитикалық қозғалтқышты тегін алдық. Және ол компанияда өте танымал болды, өйткені... SQL тілін түсінеді және кластерлерді іске қосу/тоқтату/орнатудан гөрі жылдамырақ жұмыс істейді. «Ал егер нәтиже бірдей болса, неге көбірек төлеу керек?»
Афинаға өтініш осылай көрінеді. Қаласаңыз, әрине, жеткілікті түрде қалыптастыруға болады , бірақ біз қарапайым топтастырумен шектелеміз. Клиентте бірнеше апта бұрын веб-сервер журналдарында қандай жауап кодтары болғанын көрейік және қателер жоқ екеніне көз жеткізіңіз:
қорытындылар
Ұзақ, бірақ азапты жолды басынан өткере отырып, тәуекелдер мен күрделілік деңгейін және қолдау құнын үнемі барабар бағалай отырып, біз DataLake және аналитика үшін шешім таптық, ол бізді жылдамдықпен де, иелену құнымен де қуантуды тоқтатпайды.
Компанияның мүлде басқа бөлімшелерінің қажеттіліктері үшін тиімді, жылдам және арзан жұмыс істейтін DataLake құру тіпті сәулетші болып жұмыс істемеген және квадраттарға квадраттар салуды білмейтін тәжірибелі әзірлеушілердің мүмкіндіктеріне толығымен сәйкес келетіні анықталды. көрсеткілер мен Hadoop экожүйесінің 50 терминін біледі.
Саяхаттың басында менің басым ашық және жабық бағдарламалық қамтамасыз ету және ұрпақ алдындағы жауапкершілік жүгін түсіну көптеген жабайы хайуанаттар бағында болды. Қарапайым құралдардан DataLake құруды бастаңыз: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., кері байланыс жинап, болып жатқан процестердің физикасын терең түсініңіз. Барлығы күрделі және бұлыңғыр - оны жаулар мен бәсекелестерге беріңіз.
Бұлтқа өткіңіз келмесе және бастапқы коды ашық жобаларды қолдағыңыз келмесе, сіз Hadoop және Presto бар қымбат емес кеңсе машиналарында жергілікті жерде біздікіне ұқсас схеманы құра аласыз. Ең бастысы - тоқтап қалмау және алға жылжу, санау, қарапайым және түсінікті шешімдерді іздеу және бәрі міндетті түрде орындалады! Барлығына сәттілік және тағы да кездескенше!
Ақпарат көзі: www.habr.com