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

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

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

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

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

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

Преди няколко години, паралелно с пускането на услугата „Битрикс24“, активно инвестираме време и ресурси в създаването на проста и надеждна аналитична платформа, която да помогне бързо да се видят проблемите в инфраструктурата и да се планира следващата стъпка. Разбира се, инструментите трябваше да бъдат готови и максимално прости и ясни. В резултат беше избран nagios за мониторинг и munin за аналитика и визуализация. Сега имаме хиляди проверки в nagios, стотици графики в munin и колегите ежедневно и успешно ги ползват. Метриките са ясни, графиките са разбираеми, системата работи надеждно вече няколко години и в нея редовно се добавят нови тестове и графики: въвеждаме нова услуга в експлоатация — добавяме няколко теста и графики. На добър път.

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

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

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

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

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

• Колко грешки в PHP имаше клиентът на Битрикс24 на портала p1 за последния час и какви? Да разберем, да простим и да поправим бързо.
• Колко видеозвъна бяха извършени на порталите в Германия през последните 24 часа, с какво качество и имаше ли проблеми с канала/мрежата?
• Насколько добре функционира системната функционалност (нашето разширение на C за PHP), компилирано от изходния код в последното обновление на услугата и предоставено на клиентите? Няма ли сегфолти?
• Поставят ли данните на клиентите в паметта на PHP? Няма ли грешки свързани с изчерпване на паметта, „out of memory“? Намерете и обезвредете.

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

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

Активността на всяко подразделение в компанията стана удобно за проследяване и измерване - вместо ръчен анализ на логовете на сървърите, достатъчно е веднъж да настроите парсинга на логовете и тяхното изпращане в кластер elastic, за да се наслаждавате, например, на наблюдението в таблото на kibana за броя продадени двуглави котенца, отпечатани на 3D принтер през предходния лунен месец.

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

Всеки знае, че често бизнес аналитиката в компаниите започва с изключително активно използване на 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“. Python е подобно на PHP, просто името е малко по-дълго и следите от вещества, променящи съзнанието, в изходния код на интерпретатора са малко по-малко. Въпреки това, с развитието на все нови и нови аналитични отчети, опитните разработчици започнаха да осъзнават важността на тясната специализация в инструменти като numpy, pandas, matplotlib, seaborn.
Решаваща роля, най-вероятно, изиграха внезапните припадъци на служителите от съчетанието на думите „логистична регресия“ и демонстрацията на ефективно изграждане на отчети на обемни данни с помощта на да, да, pyspark.

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

По-нататъшните опити на Apache Spark/Hadoop да се издигнат и какво не се получи съвсем по сценария

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

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

„Гумено“ файлово хранилище за аналитика — спешна нужда

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

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

Amazon S3 — кандидат за DataLake?

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

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

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

Ясно, личните данни "не могат", но какво да правим с другите данни, ако ги изнесем и "ефективно обработим"?

Клъстерно-бигдата-аналитична екосистема на 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, изпълнява услугата 'Data catalog', която не крие своята съвместимост с формата Apache Hive. В тази услуга трябва да добавите информация къде се намират вашите файлове и в какъв формат са. Данните могат да бъдат не само в s3, но и в база данни, но за това не в този пост. Ето как е организиран нашият каталог данни в DataLake:

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

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

Така че, ако трябва да направите изчисления на Spark клъстера с данни в s3 — пишете код на python/pyspark, тествате и в добро пътешествие в облака.

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

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

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

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

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

AWS Athena — „дяволът“ от кутията

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

Движокът Athena, работещ с данни в s3, е основан на легендарния Presto — представител на семейството MPP (massive parallel processing) подходи за обработка на данни, вземащи данни от s3 и Hadoop до Cassandra и обикновени текстови файлове. Нужно просто да помолим Athena да изпълни SQL запит и после всичко «работи бързо и само». Важно е да се отбележи, че Athena е «умна», ходи само в нужните шардировани папки и чете само нужните колони от запита.

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

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

Ето как шардируеме данните си в s3:

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

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

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

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

Изводи

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

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

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

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

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