Как организирахме високоефективен и евтин DataLake и защо

Живеем в невероятно време, когато можете бързо и лесно да свържете няколко готови инструмента с отворен код, да ги настроите с „изключено съзнание“ според съветите на stackoverflow, без да се задълбочавате в „множеството букви“ и да стартирате в търговска експлоатация. И когато трябва да актуализирате/разширите или някой случайно рестартира няколко машини - разбирате, че е започнал някакъв натрапчив лош сън, всичко се е усложнило драматично до неузнаваемост, няма връщане назад, бъдещето е неясно и по-сигурно, вместо да програмирате, отглеждайте пчели и правете сирене.

Не напразно по-опитните колеги, с глави, изпъстрени с грешки и следователно вече сиви, обмислят невероятно бързото разполагане на пакети от „контейнери“ в „кубове“ на десетки сървъри на „модерни езици“ с вградена поддръжка за асинхронен неблокиращ I/O, усмихнете се скромно. И те мълчаливо продължават да препрочитат „man ps“, да се ровят в изходния код на „nginx“, докато очите им не кървят, и да пишат, пишат, пишат модулни тестове. Колегите знаят, че най-интересното ще дойде, когато „всичко това“ един ден стане заложено през нощта на Нова година. И те ще бъдат подпомогнати само от дълбокото разбиране на природата на unix, запаметената таблица на състоянията на TCP/IP и основните алгоритми за сортиране и търсене. За да върнете системата към живот, докато камбаните бият.

О, да, малко се разсеях, но дано успях да предам състоянието на очакване.
Днес искам да споделя нашия опит в внедряването на удобен и евтин стек за DataLake, който решава повечето аналитични задачи в компанията за напълно различни структурни подразделения.

Преди известно време стигнахме до разбирането, че компаниите все повече се нуждаят от плодовете както на продуктовия, така и на техническия анализ (да не говорим за черешката на тортата под формата на машинно обучение) и за да разберем тенденциите и рисковете – трябва да събираме и анализираме все повече и повече показатели.

Основен технически анализ в Bitrix24

Преди няколко години, едновременно с пускането на услугата Bitrix24, ние активно инвестирахме време и ресурси в създаването на проста и надеждна аналитична платформа, която да помогне бързо да се видят проблемите в инфраструктурата и да се планира следващата стъпка. Разбира се, препоръчително е да вземете готови инструменти, които са възможно най-прости и разбираеми. В резултат на това nagios беше избран за мониторинг и munin за анализ и визуализация. Сега имаме хиляди проверки в nagios, стотици диаграми в munin и нашите колеги ги използват успешно всеки ден. Метриките са ясни, графиките са ясни, системата работи надеждно от няколко години и към нея редовно се добавят нови тестове и графики: когато пуснем нова услуга в експлоатация, добавяме няколко теста и графики. Късмет.

С пръст на пулса - Разширен технически анализ

Желанието да получаваме информация за проблемите „възможно най-бързо“ ни доведе до активни експерименти с прости и разбираеми инструменти - pinba и xhprof.

Pinba ни изпрати статистически данни в UDP пакети за скоростта на работа на части от уеб страници в PHP и можехме да видим онлайн в MySQL хранилището (Pinba идва със собствена MySQL машина за бърз анализ на събития) кратък списък с проблеми и да отговорим на тях. И xhprof автоматично ни позволи да събираме графики на изпълнението на най-бавните PHP страници от клиенти и да анализираме какво може да доведе до това - спокойно, наливане на чай или нещо по-силно.

Преди известно време инструментариумът беше попълнен с друг доста прост и разбираем двигател, базиран на алгоритъма за обратно индексиране, перфектно внедрен в легендарната библиотека Lucene - Elastic/Kibana. Простата идея за многопоточно записване на документи в инверсен индекс на Lucene, базиран на събития в регистрационните файлове и бързо търсене в тях чрез разделяне на фасети, се оказа наистина полезна.

Въпреки доста техническия външен вид на визуализациите в Kibana с концепции от ниско ниво като „кофа“, „течаща нагоре“ и преоткрития език на все още не напълно забравената релационна алгебра, инструментът започна да ни помага добре в следните задачи:

• Колко PHP грешки имаше клиентът Bitrix24 на портала p1 през последния час и кои? Разберете, простете и бързо коригирайте.
• Колко видеообаждания са направени през портали в Германия през предходните 24 часа, с какво качество и имаше ли затруднения с канала/мрежата?
• Колко добре работи функционалността на системата (нашето C разширение за PHP), компилирано от източника в най-новата актуализация на услугата и пуснато на клиенти? Има ли сегментни грешки?
• Побират ли се клиентските данни в PHP паметта? Има ли някакви грешки относно превишаване на паметта, разпределена за процеси: „изчерпана памет“? Намерете и неутрализирайте.

Ето един конкретен пример. Въпреки задълбочено и многостепенно тестване, клиентът с много нестандартен случай и повредени входни данни получи досадна и неочаквана грешка, прозвуча сирена и започна процесът на бързо отстраняване:

Освен това kibana ви позволява да организирате известия за определени събития и за кратко време инструментът в компанията започна да се използва от десетки служители от различни отдели - от техническа поддръжка и развитие до QA.

Дейността на всеки отдел в рамките на компанията стана удобна за проследяване и измерване - вместо ръчно анализиране на регистрационни файлове на сървъри, трябва само да настроите парсинг на регистрационни файлове веднъж и да ги изпратите на еластичния клъстер, за да се насладите, например, на съзерцаване в kibana табло за управление броя на продадените двуглави котенца, отпечатани на 3-D принтер за последния лунен месец.

Основен бизнес анализ

Всеки знае, че бизнес анализите в компаниите често започват с изключително активно използване на, да, Excel. Но най-важното е, че не свършва дотук. Базираният в облака Google Analytics също налива масло в огъня – бързо започвате да свиквате с хубавите неща.

В нашата хармонично развиваща се компания тук-там започнаха да се появяват „пророци” на по-интензивна работа с по-големи данни. Необходимостта от по-задълбочени и многостранни отчети започна редовно да се появява и с усилията на момчета от различни отдели преди време беше организирано просто и практично решение - комбинация от ClickHouse и PowerBI.

Доста дълго време това гъвкаво решение помагаше много, но постепенно започна да идва разбирането, че ClickHouse не е гума и не може да се подиграва така.

Тук е важно да разберете добре, че ClickHouse, подобно на Druid, като Vertica, като Amazon RedShift (който е базиран на postgres), са аналитични машини, оптимизирани за доста удобни анализи (суми, агрегирания, минимум-максимум по колона и няколко възможни съединения ), защото организирани за ефективно съхранение на колони от релационни таблици, за разлика от MySQL и други (ориентирани към редове) бази данни, познати ни.

По същество ClickHouse е просто по-обемна „база данни“, с не много удобно вмъкване точка по точка (така е предназначено, всичко е наред), но приятни анализи и набор от интересни мощни функции за работа с данни. Да, можете дори да създадете клъстер - но разбирате, че забиването на пирони с микроскоп не е съвсем правилно и започнахме да търсим други решения.

Търсене на python и анализатори

Нашата компания има много разработчици, които пишат код почти всеки ден в продължение на 10-20 години на PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Има и много опитни системни администратори, които са преживели повече от една абсолютно невероятна катастрофа, която не се вписва в законите на статистиката (например, когато по-голямата част от дисковете в raid-10 са унищожени от силен удар от мълния). При такива обстоятелства дълго време не беше ясно какво е „python analyst“. Python е като PHP, само че името е малко по-дълго и има малко по-малко следи от вещества, променящи съзнанието, в изходния код на интерпретатора. Въпреки това, тъй като бяха създадени все повече и повече аналитични отчети, опитни разработчици започнаха все повече да разбират значението на тясната специализация в инструменти като numpy, pandas, matplotlib, seaborn.
Решаващата роля най-вероятно е изиграла внезапното припадане на служители от комбинацията от думите „логистична регресия“ и демонстрацията на ефективно отчитане на големи данни, използвайки, да, да, pyspark.

Apache Spark, неговата функционална парадигма, на която релационната алгебра пасва перфектно, и неговите възможности направиха такова впечатление на разработчиците, свикнали с MySQL, че необходимостта от укрепване на редиците с опитни анализатори стана ясна като бял ден.

Допълнителни опити на Apache Spark/Hadoop да излети и какво не върви съвсем според сценария

Скоро обаче стана ясно, че нещо системно не е наред със Spark или просто е необходимо да си измиете ръцете по-добре. Ако стекът Hadoop/MapReduce/Lucene е направен от доста опитни програмисти, което е очевидно, ако се вгледате внимателно в изходния код в Java или идеите на Дъг Кътинг в Lucene, тогава Spark внезапно е написан на екзотичния език Scala, който е много спорен от гледна точка на практичност и в момента не се развива. И редовният спад в изчисленията на клъстера на Spark поради нелогична и не много прозрачна работа с разпределението на паметта за операции за намаляване (много ключове пристигат наведнъж) създаде около него ореол на нещо, което има място за растеж. Освен това ситуацията се влошава от голям брой странни отворени портове, временни файлове, които растат на най-неразбираемите места и адски зависимости от jar - което накара системните администратори да изпитат едно чувство, което е добре известно от детството: яростна омраза (или може би трябваше да си измият ръцете със сапун).

В резултат на това „оцеляхме“ няколко вътрешни аналитични проекта, които активно използват Apache Spark (включително Spark Streaming, Spark SQL) и екосистемата Hadoop (и така нататък, и така нататък). Въпреки факта, че с течение на времето се научихме да го подготвим и наблюдаваме доста добре и „то“ практически спря внезапно да се срива поради промени в естеството на данните и дисбаланса на еднородното RDD хеширане, желанието да вземем нещо вече готово , актуализиран и администриран някъде в облака, ставаше все по-силен и по-силен. По това време се опитахме да използваме готовата облачна сборка на Amazon Web Services - EMR и впоследствие се опита да реши проблеми с него. EMR е Apache Spark, подготвен от Amazon с допълнителен софтуер от екосистемата, подобно на компилациите на Cloudera/Hortonworks.

Гуменото съхранение на файлове за анализи е спешна необходимост

Опитът от „готвенето“ на Hadoop/Spark с изгаряния на различни части на тялото не беше напразен. Необходимостта от създаване на единно, евтино и надеждно хранилище на файлове, което би било устойчиво на хардуерни повреди и в което би било възможно да се съхраняват файлове в различни формати от различни системи и да се правят ефективни и ефективни във времето проби за отчети от тези данни, става все по-голяма ясно.

Исках също така актуализирането на софтуера на тази платформа да не се превърне в новогодишен кошмар с четене на 20-странични следи на Java и анализиране на километрични подробни регистрационни файлове на клъстера с помощта на Spark History Server и лупа със задно осветяване. Исках да имам прост и прозрачен инструмент, който не изисква редовно гмуркане под капака, ако стандартната заявка на разработчика MapReduce спре да се изпълнява, когато работникът за редуциране на данни падне от паметта поради не много добре избран алгоритъм за разделяне на изходни данни.

Amazon S3 кандидат ли е за DataLake?

Опитът с Hadoop/MapReduce ни научи, че се нуждаем от мащабируема, надеждна файлова система и мащабируеми работници отгоре й, които „идват“ по-близо до данните, за да не управляват данните през мрежата. Работниците трябва да могат да четат данни в различни формати, но за предпочитане е да не четат ненужна информация и да могат да съхраняват данни предварително във формати, удобни за работниците.

Още веднъж основната идея. Няма желание да „излеете“ големи данни в един клъстерен аналитичен двигател, който рано или късно ще се задуши и ще трябва да го разделите грозно. Искам да съхранявам файлове, просто файлове, в разбираем формат и да извършвам ефективни аналитични заявки върху тях, като използвам различни, но разбираеми инструменти. И ще има все повече и повече файлове в различни формати. И е по-добре да разбиете не двигателя, а изходните данни. Имаме нужда от разширяем и универсален DataLake, решихме...

Какво ще стане, ако съхранявате файлове в познатото и добре познато мащабируемо облачно хранилище Amazon S3, без да се налага да приготвяте свои собствени пържоли от Hadoop?

Ясно е, че личните данни са „ниски“, но какво да кажем за други данни, ако ги извадим там и ги „управляваме ефективно“?

Cluster-bigdata-analytics екосистема на Amazon Web Services - с много прости думи

Съдейки по нашия опит с AWS, Apache Hadoop/MapReduce се използва активно там от дълго време под различни сосове, например в услугата DataPipeline (завиждам на колегите си, те се научиха как да го подготвят правилно). Тук настройваме резервни копия от различни услуги от DynamoDB таблици:


И те работят редовно на вградени Hadoop/MapReduce клъстери като часовник вече няколко години. „Настройте и забравете“:

Можете също така ефективно да се включите в сатанизма на данните, като настроите лаптопи Jupiter в облака за анализатори и използвате услугата AWS SageMaker за обучение и внедряване на AI модели в битка. Ето как изглежда при нас:

И да, можете да изберете лаптоп за себе си или за анализатор в облака и да го прикачите към Hadoop/Spark клъстер, да направите изчисленията и след това да заковате всичко:

Наистина удобно за индивидуални аналитични проекти и за някои успешно използвахме услугата EMR за мащабни изчисления и анализи. Какво ще кажете за системно решение за DataLake, ще работи ли? В този момент бяхме на ръба на надеждата и отчаянието и продължихме търсенето.

AWS Glue - добре опакован Apache Spark на стероиди

Оказа се, че AWS има собствена версия на стека “Hive/Pig/Spark”. Ролята на Hive, т.е. Каталогът на файловете и техните типове в DataLake се извършва от услугата „Каталог на данни“, която не крие съвместимостта си с формата Apache Hive. Трябва да добавите информация към тази услуга за това къде се намират вашите файлове и в какъв формат са. Данните могат да бъдат не само в s3, но и в базата данни, но това не е предмет на тази публикация. Ето как е организирана нашата директория с данни DataLake:

Файловете са регистрирани, супер. Ако файловете са актуализирани, стартираме роботи или ръчно, или по график, които ще актуализират информацията за тях от езерото и ще ги запазят. След това данните от езерото могат да бъдат обработени и резултатите да бъдат качени някъде. В най-простия случай качваме и на s3. Обработката на данни може да се извърши навсякъде, но се препоръчва да конфигурирате обработката на клъстер Apache Spark, като използвате разширени възможности чрез AWS Glue API. Всъщност можете да вземете добрия стар и познат код на Python с помощта на библиотеката pyspark и да конфигурирате изпълнението му на N възли на клъстер с известен капацитет с наблюдение, без да ровите в червата на Hadoop и да влачите контейнери docker-moker и да елиминирате конфликти на зависимости .

Още веднъж, проста идея. Няма нужда да конфигурирате Apache Spark, просто трябва да напишете код на python за pyspark, да го тествате локално на вашия работен плот и след това да го стартирате на голям клъстер в облака, като посочите къде са изходните данни и къде да поставите резултата. Понякога това е необходимо и полезно и ето как го настройваме:

По този начин, ако трябва да изчислите нещо на клъстер на Spark, използвайки данни в s3, ние пишем код на python/pyspark, тестваме го и желаем успех на облака.

Какво ще кажете за оркестрацията? Ами ако задачата падне и изчезне? Да, предлага се да се направи красив конвейер в стила на Apache Pig и ние дори ги опитахме, но засега решихме да използваме нашата дълбоко персонализирана оркестрация в PHP и JavaScript (разбирам, има когнитивен дисонанс, но работи, за години и без грешки).

Форматът на файловете, съхранявани в езерото, е ключът към производителността

Много, много важно е да разберете още две ключови точки. За да могат заявките за файлови данни в езерото да се изпълняват възможно най-бързо и производителността да не се влошава при добавяне на нова информация, трябва да:

• Съхранявайте колони от файлове отделно (за да не се налага да четете всички редове, за да разберете какво има в колоните). За това взехме формата на паркета с компресия
• Много е важно файловете да се разделят в папки като: език, година, месец, ден, седмица. Машините, които разбират този тип шардинг, ще разглеждат само необходимите папки, без да пресяват всички данни подред.

По същество по този начин вие излагате изходните данни в най-ефективната форма за аналитични машини, окачени отгоре, които дори в шардирани папки могат избирателно да влизат и четат само необходимите колони от файлове. Не е необходимо да „попълвате“ данните никъде (хранилището просто ще се спука) - просто веднага го поставете разумно във файловата система в правилния формат. Разбира се, тук трябва да е ясно, че съхраняването на огромен csv файл в DataLake, който първо трябва да бъде прочетен ред по ред от клъстера, за да се извлекат колоните, не е много препоръчително. Помислете отново за горните две точки, ако все още не е ясно защо се случва всичко това.

AWS Athena - жак в кутията

И тогава, докато създавахме езеро, по някакъв начин случайно попаднахме на Amazon Athena. Изведнъж се оказа, че чрез внимателно подреждане на нашите огромни регистрационни файлове в сегменти на папки в правилния (паркетен) формат на колони, можете много бързо да направите изключително информативни селекции от тях и да изградите отчети БЕЗ, без Apache Spark/Glue клъстер.

Енджинът Athena, задвижван от данни в s3, е базиран на легендарния Престо - представител на семейството от подходи за обработка на данни MPP (масивна паралелна обработка), като взема данни там, където се намират, от s3 и Hadoop до Cassandra и обикновени текстови файлове. Просто трябва да помолите Athena да изпълни SQL заявка и тогава всичко „работи бързо и автоматично“. Важно е да се отбележи, че Athena е „умна“, тя отива само до необходимите шардирани папки и чете само колоните, необходими в заявката.

Ценообразуването за заявки към Athena също е интересно. Ние плащаме за обем сканирани данни. Тези. не за броя на машините в клъстера на минута, но... за действително сканираните данни на 100-500 машини, само данните, необходими за изпълнение на заявката.

И като поискахме само необходимите колони от правилно шардирани папки, се оказа, че услугата Athena ни струва десетки долари на месец. Е, страхотно, почти безплатно, в сравнение с анализа на клъстери!

Между другото, ето как споделяме нашите данни в s3:

В резултат на това за кратко време напълно различни отдели в компанията, от информационна сигурност до анализи, започнаха активно да отправят заявки към Athena и бързо, за секунди, да получават полезни отговори от „големи“ данни за доста дълги периоди: месеци, половин година и др. П.

Но ние отидохме по-далеч и започнахме да отиваме в облака за отговори чрез ODBC драйвер: анализатор пише SQL заявка в позната конзола, която на 100-500 машини „за стотинки“ изпраща данни до s3 и връща отговор обикновено след няколко секунди. Удобен. И бързо. Още не мога да повярвам.

В резултат на това, след като решихме да съхраняваме данни в s3, в ефективен колонен формат и с разумно шардинг на данните в папки... получихме DataLake и бърз и евтин аналитичен двигател - безплатно. И той стана много популярен в компанията, защото... разбира SQL и работи с порядъци по-бързо, отколкото чрез стартиране/спиране/настройване на клъстери. „И ако резултатът е същият, защо да плащаме повече?“

Молба към Атина изглежда така. При желание, разбира се, можете да оформите достатъчно сложна и многостранична SQL заявка, но ще се ограничим до обикновено групиране. Нека да видим какви кодове на отговор имаше клиентът преди няколко седмици в регистрационните файлове на уеб сървъра и да се уверим, че няма грешки:

Данни

След като преминахме през, да не кажем, дълъг, но болезнен път, постоянно адекватно оценявайки рисковете и нивото на сложност и цената на поддръжката, намерихме решение за DataLake и анализи, което не спира да ни радва както със скорост, така и с цена на притежание.

Оказа се, че изграждането на ефективен, бърз и евтин за работа DataLake за нуждите на напълно различни отдели на компанията е напълно по силите дори на опитни разработчици, които никога не са работили като архитекти и не знаят как да рисуват квадрати върху квадрати с стрелки и да знаете 50 термина от екосистемата Hadoop.

В началото на пътуването главата ми се цепеше от многото диви зоопаркове на отворен и затворен софтуер и разбирането за тежестта на отговорността към потомците. Просто започнете да изграждате своя DataLake от прости инструменти: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., събиране на обратна връзка и дълбоко разбиране на физиката на протичащите процеси. Всичко сложно и мътно - дайте го на врагове и конкуренти.

Ако не искате да отидете в облака и искате да поддържате, актуализирате и кръпвате проекти с отворен код, можете да изградите схема, подобна на нашата локално, на евтини офис машини с Hadoop и Presto отгоре. Основното нещо е да не спирате и да вървите напред, да броите, да търсите прости и ясни решения и всичко определено ще се получи! Успех на всички и до нови срещи!

Източник: www.habr.com