Како смо организовали високо ефикасан и јефтин ДатаЛаке и зашто

Живимо у невероватном времену када можете брзо и лако да повежете неколико готових алата отвореног кода, подесите их са „искљученом свешћу“ према савету стацковерфлов-а, без удубљивања у „више слова“, и покренете их у комерцијални рад. А када треба да ажурирате/проширите или неко случајно рестартује пар машина - схватите да је почео неки опсесивни ружни сан, све се драматично закомпликовало до непрепознатљивости, нема повратка, будућност је нејасна и сигурнија, уместо програмирања, узгајајте пчеле и радите сир.

Не зря же, более опытные коллеги, с посыпанной багами и от этого уже седой головой, созерцая неправдоподобно быстрое развертывание пачек «контейнеров» в «кубиках» на десятках серверов на «модных языках» со встроенной поддержкой асинхронно-неблокирующего ввода-вывода — скромно улыбаются. И молча продолжают перечитывать «man ps», вникают до кровоточения из глаз в исходники «nginx» и пишут-пишут-пишут юнит-тесты. Коллеги знают, что самое интересное будет впереди, когда «всё это» однажды станет ночью колом под Новый год. И им поможет только глубокое понимание природы unix, заученной таблицы состояний TCP/IP и базовых алгоритмов сортировки-поиска. Чтобы под бой курантов возвращать систему к жизни.

О да, мало сам се омео, али надам се да сам успео да пренесем стање ишчекивања.
Данас желим да поделим наше искуство у примени погодног и јефтиног стека за ДатаЛаке, који решава већину аналитичких задатака у компанији за потпуно различите структурне дивизије.

Пре извесног времена дошли смо до схватања да компанијама све више требају плодови и производне и техничке аналитике (да не говоримо о шлагу на торту у виду машинског учења) и да бисмо разумели трендове и ризике – потребно је да прикупљамо и анализирамо све више и више метрика.

Основна техничка аналитика у Битрик24

Пре неколико година, истовремено са лансирањем услуге Битрикс24, активно смо уложили време и ресурсе у креирање једноставне и поуздане аналитичке платформе која би помогла да се брзо сагледају проблеми у инфраструктури и испланира следећи корак. Наравно, било је препоручљиво узети готове алате који су били што једноставнији и разумљивији. Као резултат тога, нагиос је изабран за праћење и мунин за аналитику и визуелизацију. Сада имамо хиљаде чекова у нагиос-у, стотине карата у мунин-у, а наше колеге их успешно користе сваки дан. метрике су јасне, графикони су јасни, систем ради поуздано већ неколико година и редовно му се додају нови тестови и графикони: када пуштамо у рад нови сервис, додајемо неколико тестова и графикона. Срећно.

Прст на пулсу - напредна техничка аналитика

Жеља да добијемо информације о проблемима „што је брже могуће“ довела нас је до активних експеримената са једноставним и разумљивим алатима - пинба и кхпроф.

Пинба нам је слала статистику у УДП пакетима о брзини рада делова веб страница у ПХП-у, а могли смо да видимо онлајн у МиСКЛ складишту (Пинба долази са сопственим МиСКЛ мотором за брзу аналитику догађаја) кратку листу проблема и одговоре на њих. А кхпроф нам је аутоматски омогућио да прикупимо графиконе извршавања најспоријих ПХП страница од клијената и анализирамо шта би могло да доведе до овога - мирно, сипајући чај или нешто јаче.

Пре неког времена, комплет алата је допуњен још једним прилично једноставним и разумљивим мотором заснованим на алгоритму обрнутог индексирања, савршено имплементираним у легендарној библиотеци Луцене - Еластиц/Кибана. Једноставна идеја вишенитног снимања докумената у инверзни Луцене индекс заснован на догађајима у евиденцији и брзом претраживању кроз њих помоћу поделе фасета показала се заиста корисном.

Упркос прилично техничком изгледу визуелизација у Кибани са концептима ниског нивоа попут „канте“ „тече нагоре“ и поново измишљеног језика још увек не потпуно заборављене релационе алгебре, алат је почео да нам добро помаже у следећим задацима:

• Колико ПХП грешака је клијент Битрикс24 имао на п1 порталу у последњих сат времена и којих? Схватите, опростите и брзо исправите.
• Колико је видео позива обављено на порталима у Немачкој у претходна 24 сата, са којим квалитетом и да ли је било потешкоћа са каналом/мрежом?
• Колико добро функционише системска функционалност (наша екстензија Ц за ПХП), компајлирана из извора у најновијем ажурирању услуге и представљена клијентима? Постоје ли сегфаулти?
• Да ли се подаци о клијентима уклапају у ПХП меморију? Има ли грешака у вези са прекорачењем меморије додељене процесима: „недостаје меморије“? Пронађите и неутралишите.

Ево конкретног примера. Упркос детаљном и вишестепеном тестирању, клијент је, са веома нестандардним кућиштем и оштећеним улазним подацима, добио досадну и неочекивану грешку, огласила се сирена и започео је процес брзог отклањања исте:

Поред тога, кибана вам омогућава да организујете обавештења за одређене догађаје, а за кратко време алат у компанији почело је да користи десетине запослених из различитих одељења – од техничке подршке и развоја до КА.

Активност било ког одељења у оквиру компаније постало је згодно за праћење и мерење – уместо да ручно анализирате логове на серверима, потребно је само једном да подесите рашчлањивање дневника и пошаљете их у еластични кластер да бисте уживали, на пример, у контемплацији у кибани контролна табла број продатих двоглавих мачића одштампан на 3-Д штампачу за последњи лунарни месец.

Основна пословна аналитика

Сви знају да пословна аналитика у компанијама често почиње изузетно активним коришћењем, да, Екцел-а. Али главна ствар је да се ту не завршава. Гоогле аналитика заснована на облаку такође долива уље на ватру – брзо почињете да се навикавате на добре ствари.

У нашој компанији која се складно развија, ту и тамо су почели да се појављују „пророци“ интензивнијег рада са већим подацима. Потреба за детаљнијим и вишеструким извештајима почела је да се редовно јавља, а залагањем момака из различитих одељења пре извесног времена организовано је једноставно и практично решење – комбинација ЦлицкХоусе и ПоверБИ.

Ово флексибилно решење је доста дуго помагало, али је постепено почело да долази до схватања да ЦлицкХоусе није гумена и да се не може тако исмевати.

Овде је важно добро разумети да су ЦлицкХоусе, попут Друида, као што је Вертица, као што је Амазон РедСхифт (који се заснива на постгресу), аналитички мотори оптимизовани за прилично згодну аналитику (збирови, агрегације, минимум-максимум по колони и неколико могућих спојева ), јер организован за ефикасно складиштење колона релационих табела, за разлику од МиСКЛ-а и других нама познатих база података (оријентисаних на редове).

У суштини, ЦлицкХоусе је само пространија „база података“, са не баш згодним убацивањем тачке по тачку (тако је замишљено, све је у реду), али пријатном аналитиком и скупом занимљивих моћних функција за рад са подацима. Да, можете чак и да направите кластер - али разумете да закуцавање ексера микроскопом није сасвим исправно и почели смо да тражимо друга решења.

Потражња за питоном и аналитичарима

Наша компанија има много програмера који пишу код скоро сваки дан током 10-20 година у ПХП, ЈаваСцрипт, Ц#, Ц/Ц++, Јава, Го, Руст, Питхон, Басх. Такође има много искусних систем администратора који су доживели више од једне апсолутно невероватне катастрофе која се не уклапа у законе статистике (на пример, када је већина дискова у раид-10 уништена јаким ударом грома). У таквим околностима, дуго није било јасно шта је „пајтон аналитичар“. Питхон је као ПХП, само што је име мало дуже и има мало мање трагова супстанци које мењају ум у изворном коду тумача. Међутим, како је креирано све више аналитичких извештаја, искусни програмери су почели све више да схватају важност уске специјализације у алатима као што су нумпи, пандас, матплотлиб, сеаборн.
Одлучујућу улогу је, највероватније, одиграла изненадна несвестица запослених од комбинације речи „логистичка регресија” и демонстрација ефикасног извештавања о великим подацима користећи, да, да, писпарк.

Апацхе Спарк, његова функционална парадигма на коју се релациона алгебра савршено уклапа, и његове могућности оставиле су такав утисак на програмере навикнуте на МиСКЛ да је потреба за јачањем редова искусним аналитичарима постала јасна као дан.

Даљи покушаји Апацхе Спарк/Хадооп-а да полете и оно што није ишло сасвим по сценарију

Међутим, убрзо је постало јасно да са Спарком нешто системски није у реду, или је једноставно било потребно боље опрати руке. Ако су Хадооп/МапРедуце/Луцене стек направили прилично искусни програмери, што је очигледно ако се пажљиво погледа изворни код у Јави или идеје Доуга Цуттинга у Луценеу, онда је Спарк, одједном, написан на егзотичном језику Сцала, тј. веома контроверзна са становишта практичности и тренутно се не развија. А редовни пад прорачуна на Спарк кластеру због нелогичног и не баш транспарентног рада са алокацијом меморије за операције редукције (много кључева стиже одједном) створио је око себе ореол нечега што има простора за раст. Поред тога, ситуацију је погоршавао велики број чудних отворених портова, привремени фајлови који су расли на најнеразумљивијим местима и паклене зависности од јар-а - због чега су администратори система имали један осећај који је добро познат од детињства: жестоку мржњу (или можда требало је да оперу руке сапуном).

Као резултат тога, „преживели смо“ неколико интерних аналитичких пројеката који активно користе Апацхе Спарк (укључујући Спарк Стреаминг, Спарк СКЛ) и Хадооп екосистем (и тако даље и тако даље). Упркос чињеници да смо временом научили да припремимо и пратимо „то“ прилично добро, а „оно“ је практично престало да се изненада руши због промена у природи података и неравнотеже униформног РДД хеширања, жеља да узмемо нешто већ спремно , ажуриран и администриран негде у облаку постајао је све јачи и јачи. У то време смо покушали да користимо готову клауд скупу Амазон Веб Сервицес - ЕМР и, након тога, покушао да реши проблеме користећи га. ЕМР је Апацхе Спарк који је припремио Амазон са додатним софтвером из екосистема, слично као Цлоудера/Хортонворкс верзије.

Складиштење гумених датотека за аналитику је хитна потреба

Искуство „кувања“ Хадооп/Спарк-а са опекотинама на разним деловима тела није било узалудно. Потреба за стварањем јединственог, јефтиног и поузданог складишта фајлова који би био отпоран на хардверске кварове и у којем би било могуће чувати датотеке у различитим форматима из различитих система и правити ефикасне и временски ефикасне узорке за извештаје из ових података постајала је све израженија. јасно.

Такође сам желео да се ажурирање софтвера ове платформе не претвори у новогодишњу ноћну мору са читањем Јава трагова од 20 страница и анализирањем километарских детаљних дневника кластера користећи Спарк Хистори Сервер и лупу са позадинским осветљењем. Желео сам да имам једноставан и транспарентан алат који не захтева редовно роњење испод хаубе ако програмеров стандардни МапРедуце захтев престане да се извршава када радник за смањење података испадне из меморије због не баш добро одабраног алгоритма за партиционисање изворних података.

Да ли је Амазон С3 кандидат за ДатаЛаке?

Искуство са Хадооп/МапРедуце научило нас је да нам је потребан скалабилан, поуздан систем датотека и скалабилни радници поврх њега, који ће се „приближити“ подацима како не би преносили податке преко мреже. Радници би требало да буду у стању да читају податке у различитим форматима, али пожељно је да не читају непотребне информације и да могу унапред да складиште податке у форматима који су погодни за раднике.

Још једном, основна идеја. Нема жеље да се велики подаци „сипају“ у један аналитички механизам кластера, који ће се пре или касније угушити и мораћете да га ружно разбијете. Желим да складиштим датотеке, само датотеке, у разумљивом формату и да обављам ефикасне аналитичке упите на њима користећи различите, али разумљиве алате. И биће све више датотека у различитим форматима. И боље је делити не мотор, већ изворне податке. Потребан нам је проширив и универзални ДатаЛаке, одлучили смо...

Шта ако складиштите датотеке у познатом и добро познатом скалабилном складишту у облаку Амазон С3, а да не морате да припремате сопствене комаде из Хадооп-а?

Јасно је да су лични подаци „ниски“, али шта је са другим подацима ако их извадимо и „ефикасно управљамо“?

Екосистем кластер-бигдата-аналитике Амазон Веб Сервицес - врло једноставним речима

Судећи по нашем искуству са АВС-ом, Апацхе Хадооп/МапРедуце се тамо већ дуже време активно користи под разним сосовима, на пример у сервису ДатаПипелине (завидим својим колегама, научили су како да га правилно припреме). Овде смо поставили резервне копије са различитих сервиса из ДинамоДБ табела:


И већ неколико година редовно раде на уграђеним Хадооп/МапРедуце кластерима као сат. „Подеси и заборави“:

Такође можете ефикасно да се бавите сатанизмом података тако што ћете поставити Јупитер преносне рачунаре у облаку за аналитичаре и користити услугу АВС СагеМакер за обуку и увођење АИ модела у борбу. Ево како то код нас изгледа:

И да, можете покупити лаптоп за себе или аналитичара у облаку и прикључити га на Хадооп/Спарк кластер, извршити прорачуне и онда све закуцати:

Заиста погодно за појединачне аналитичке пројекте, а за неке смо успешно користили ЕМР услугу за велике прорачуне и аналитику. Шта је са системским решењем за ДатаЛаке, да ли ће функционисати? У овом тренутку били смо на ивици наде и очаја и наставили смо потрагу.

АВС Глуе - уредно упакован Апацхе Спарк на стероидима

Испоставило се да АВС има сопствену верзију стека „Хиве/Пиг/Спарк”. Улога Кошнице, тј. Каталог датотека и њихових типова у ДатаЛаке-у врши услуга „Каталог података“, која не крије своју компатибилност са форматом Апацхе Хиве. Овој услузи морате да додате информације о томе где се ваше датотеке налазе и у ком су формату. Подаци могу бити не само у с3, већ и у бази података, али то није тема овог поста. Ево како је наш ДатаЛаке каталог података организован:

Фајлови су регистровани, одлично. Ако су датотеке ажуриране, покрећемо пописиваче или ручно или по распореду, који ће ажурирати информације о њима из језера и сачувати их. Тада се подаци из језера могу обрадити и резултати негде учитати. У најједноставнијем случају, такође отпремамо на с3. Обрада података се може обавити било где, али се предлаже да конфигуришете обраду на Апацхе Спарк кластеру користећи напредне могућности преко АВС Глуе АПИ-ја. У ствари, можете узети стари добри и познати Питхон код користећи писпарк библиотеку и конфигурисати његово извршавање на Н чворова кластера одређеног капацитета са надгледањем, без копања у цревима Хадооп-а и превлачења доцкер-мокер контејнера и елиминисања сукоба зависности .

Још једном, једноставна идеја. Нема потребе да конфигуришете Апацхе Спарк, само треба да напишете Питхон код за писпарк, да га тестирате локално на радној површини, а затим да га покренете на великом кластеру у облаку, наводећи где су изворни подаци и где да ставите резултат. Понекад је ово неопходно и корисно, а ево како то постављамо:

Стога, ако треба да израчунате нешто на Спарк кластеру користећи податке у с3, пишемо код у питхон/писпарк, тестирамо га и срећно облаку.

Шта је са оркестрацијом? Шта ако је задатак пао и нестао? Да, предложено је да се направи прелеп цевовод у стилу Апацхе Пиг и чак смо их испробали, али за сада смо одлучили да користимо нашу дубоко прилагођену оркестрацију у ПХП-у и ЈаваСцрипт-у (разумем, постоји когнитивна дисонанца, али ради, за године и без грешака).

Формат датотека ускладиштених у језеру је кључ за перформансе

Веома, веома је важно разумети још две кључне тачке. Да би се упити о подацима датотека у језеру извршили што је брже могуће и да се перформансе не би погоршале када се додају нове информације, потребно је:

• Чувајте колоне датотека одвојено (тако да не морате да читате све редове да бисте разумели шта је у колонама). За ово смо узели формат паркета са компресијом
• Веома је важно да делите датотеке у фасцикле као што су: језик, година, месец, дан, недеља. Механизми који разумеју ову врсту шардинга ће гледати само неопходне фасцикле, без прегледавања свих података у низу.

У суштини, на овај начин, изворне податке постављате у најефикаснијем облику за аналитичке машине окачене на врху, које чак иу разломљеним фасциклама могу селективно да уносе и читају само потребне колоне из датотека. Не морате нигде да „допуњавате“ податке (складиште ће се једноставно распрснути) - само га одмах мудро ставите у систем датотека у исправном формату. Наравно, овде треба да буде јасно да складиштење огромне цсв датотеке у ДатаЛаке-у, коју кластер мора прво да прочита ред по ред да би издвојио колоне, није препоручљиво. Поново размислите о горње две тачке ако још није јасно зашто се све ово дешава.

АВС Атхена - џек у кутији

А онда, стварајући језеро, некако смо случајно наишли на Амазонску Атину. Одједном се испоставило да пажљивим поређањем наших огромних лог фајлова у фрагменте фолдера у исправном (паркетном) формату колоне, можете врло брзо направити изузетно информативне селекције од њих и правити извештаје БЕЗ, без Апацхе Спарк/Глуе кластера.

Атхена мотор покретан подацима у с3 базиран је на легендарном Цхроме - представник МПП (массиве паралелне обраде) породице приступа обради података, узимајући податке тамо где леже, од с3 и Хадооп-а до Цассандре и обичних текстуалних датотека. Само треба да замолите Атину да изврши СКЛ упит, а онда све „ради брзо и аутоматски“. Важно је напоменути да је Атхена „паметна“, да иде само до неопходних подељених фасцикли и чита само колоне потребне у захтеву.

Занимљива је и цена за захтеве Атени. Ми плаћамо обим скенираних података. Оне. не за број машина у кластеру у минути, већ... за податке који су стварно скенирани на 100-500 машина, само подаци неопходни за довршавање захтева.

А тражењем само потребних колона из исправно подељених фасцикли, испоставило се да нас услуга Атхена кошта десетине долара месечно. Па, одлично, скоро бесплатно, у поређењу са аналитиком на кластерима!

Успут, ево како делимо наше податке у с3:

Као резултат тога, за кратко време, потпуно различита одељења у компанији, од информационе безбедности до аналитике, почела су активно да упућују захтеве Атени и брзо, у секунди, добијају корисне одговоре из „великих“ података у прилично дугим периодима: месеци, пола године итд.П.

Али отишли ​​смо даље и почели да идемо у облак по одговоре преко ОДБЦ драјвера: аналитичар пише СКЛ упит у познатој конзоли, која на 100-500 машина "за пени" шаље податке на с3 и враћа одговор обично за неколико секунди. Удобан. И брзо. Још увек не могу да верујем.

Као резултат тога, одлучивши да чувамо податке у с3, у ефикасном колонском формату и са разумним дељењем података у фасцикле... добили смо ДатаЛаке и брз и јефтин аналитички механизам - бесплатно. И постао је веома популаран у компанији, јер... разуме СКЛ и ради редове величине брже него кроз покретање/заустављање/подешавање кластера. "А ако је резултат исти, зашто плаћати више?"

Молба Атини изгледа отприлике овако. По жељи, наравно, можете формирати довољно сложен и вишестрани СКЛ упит, али ћемо се ограничити на једноставно груписање. Хајде да видимо које је кодове одговора клијент имао пре неколико недеља у евиденцији веб сервера и уверимо се да нема грешака:

Налази

Прошавши, да не кажем дуг, али болан пут, константно адекватно процењујући ризике и ниво сложености и цене подршке, пронашли смо решење за ДатаЛаке и аналитику које не престаје да нас радује и брзином и ценом поседовања.

Испоставило се да је изградња ефикасног, брзог и јефтиног за рад ДатаЛаке-а за потребе потпуно различитих одељења компаније у потпуности у могућностима чак и искусних програмера који никада нису радили као архитекте и не знају да цртају квадрате на квадратима са стрелице и знају 50 појмова из Хадооп екосистема.

На почетку путовања глава ми се цепала од бројних дивљих зоолошких вртова отвореног и затвореног софтвера и схватања терета одговорности према потомцима. Само почните да правите свој ДатаЛаке од једноставних алата: нагиос/мунин -> еластиц/кибана -> Хадооп/Спарк/с3..., прикупљајући повратне информације и дубоко разумевајући физику процеса који се одвијају. Све сложено и мутно - дајте непријатељима и конкурентима.

Ако не желите да идете у облак и желите да подржавате, ажурирате и крпите пројекте отвореног кода, можете да направите шему сличну нашој локално, на јефтиним канцеларијским машинама са Хадооп-ом и Престо-ом на врху. Главна ствар је да се не заустављате и идете напред, рачунајте, тражите једноставна и јасна решења и све ће сигурно успети! Срећно свима и видимо се поново!

Извор: ввв.хабр.цом