Ми живемо в дивовижний час, коли можна швидко і просто з'єднати кілька готових відкритих інструментів, налаштувати їх з «відключеною свідомістю» за порадами stackoverflow, не вникаючи в «багатобукв», запустити в комерційну експлуатацію. А коли потрібно буде оновлюватися/розширюватися або хтось випадково перезавантажить пару машин — усвідомити, що почався якийсь нав'язливий дурний сон наяву, все різко ускладнилося до невпізнання, шляху назад немає, майбутнє туманно і безпечніше замість програмування розводити бджіл і робити сир.
Не дарма ж, досвідченіші колеги, з посипаною багами і від цього вже сивою головою, споглядаючи неправдоподібно швидке розгортання пачок «контейнерів» у «кубиках» на десятках серверів «модними мовами» з вбудованою підтримкою асинхронно-неблокуючого вводу-виводу. . І мовчки продовжують перечитувати «man ps», вникають до кровоточіння з очей у вихідники «nginx» та пишуть-пишуть-пишуть юніт-тести. Колеги знають, що найцікавіше буде попереду, коли "все це" одного разу стане вночі колом під Новий рік. І їм допоможе лише глибоке розуміння природи unix, завченої таблиці станів TCP/IP та базових алгоритмів сортування-пошуку. Щоб під бій курантів повертати систему до життя.
Ах так, трохи відволікся, але стан передчуття, сподіваюся, вдалося передати.
Сьогодні я хочу поділитися нашим досвідом розгортання зручного та недорогого стеку для DataLake, що вирішує більшість аналітичних завдань у компанії для різних структурних підрозділів.
Якийсь час тому ми дійшли розуміння, що компанії все сильніше і сильніше потрібні плоди як продуктової, так і технічної аналітики (не кажучи вже про вишеньки на торті у вигляді machine learning) і для розуміння трендів і ризиків - потрібно збирати і аналізувати все більше і більше. більше за метрик.
Базова технічна аналітика в «Бітрікс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), скомпільований з вихідних джерел в останньому оновленні сервісу та розкатаний клієнтам? Чи немає segfaults?
- Чи містяться дані клієнтів у пам'ять PHP? Чи немає помилок перевищення виділеної процесам пам'яті: "out of memory"? Знайти та знешкодити.
Ось конкретний приклад. Незважаючи на ретельне та багаторівневе тестування, у клієнта, при дуже нестандартному кейсі та пошкоджених вхідних даних з'явилася прикра та несподівана помилка, зазвучала сирена та почався процес її швидкого виправлення:
Додатково, kibana дозволяє організувати оповіщення за вказаними подіями та за короткий час інструментом у компанії стали користуватися десятки співробітників з різних підрозділів – від техпідтримки та розробки до QA.
Активність будь-якого підрозділу всередині компанії стало зручно відстежувати та вимірювати — замість ручного аналізу логів на серверах, достатньо один раз налаштувати парсинг логів та їх відправлення до кластера elastic, щоб насолоджуватися, наприклад, спогляданням у дашборді kibana числа проданих двоголових кошенят, надрукованих на 3-d принтер за минулий місячний місяць.
Базова бізнес-аналітика
Всі знають, що бізнес-аналітика в компаніях починається з екстремально активного використання, так, так, Excel. Але головне, щоб вона в ньому не закінчувалася. Олія у вогонь ще добре підливає хмарний Google Analytics – до хорошого починаєш швидко звикати.
У нашій компанії, що гармонійно розвивається, стали то тут, то там, з'являтися «пророки» більш інтенсивної роботи з більшими даними. Регулярно стали з'являтися потреби у більш глибоких та багатогранних звітах та зусиллями хлопців з різних підрозділів якийсь час тому було організовано просте та практичне рішення – зв'язка ClickHouse та PowerBI.
Досить довгий час це гнучке рішення відмінно допомагало, але поступово почало приходити розуміння, що ClickHouse - не гумовий і не можна над ним так знущатися.
Тут важливо добре зрозуміти, що ClickHouse, як і Druid, як і Vertica, як і Amazon RedShift (який на базі postgres), це аналітичні двигуни, оптимізовані на досить зручну аналітику (суми, агрегації, мінімум максимум по колонці і трошки можна джойнів ), т.к. організовані для ефективного зберігання колонок реляційних таблиць, на відміну від відомого нам MySQL та інших (row-oriented) баз даних.
По суті, 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 це приготований амазоном Apache Spark з додатковим софтом з екосистеми, приблизно як Cloudera/Hortonworks складання.
«Гумове» файлове сховище для аналітики — гостра потреба
Досвід «приготування» Hadoop/Spark із опіками різних частин тіла не пройшов даремно. Стала все чіткіше вимальовуватися необхідність створення єдиного недорогого і надійного файлового сховища, яке було б стійке до апаратних аварій і в якому можна було б зберігати файли в різному форматі з різних систем і робити за цими даними ефективні вибірки для звітів, що розумні час виконуються.
Також хотілося, щоб оновлення софту цієї платформи не перетворювалося на новорічний нічний жах із читанням 20-сторінкових Java трейсів та аналіз кілометрових докладних логів роботи кластера за допомогою Spark History Server та лупи з підсвічуванням. Хотілося мати простий і прозорий інструмент, який не вимагає регулярного пірнання під капот, якщо у розробника перестав виконуватися стандартний MapReduce запит при випаданні з пам'яті воркера reduce-даних при не дуже вдало обраному алгоритмі партиціонування вихідних даних.
Amazon S3 - кандидат на DataLake?
Досвід роботи з Hadoop/MapReduce навчив тому, що потрібна й масштабована надійна файлова система і над нею воркери, що масштабуються, «приходять» ближче до даних, щоб не ганяти дані по мережі. Воркери повинні вміти читати дані у різних форматах, але, бажано, не читати зайву інформацію та щоб можна було заздалегідь зберігати дані у зручних для воркерів форматах.
Ще раз – основна ідея. Немає бажання «заливати» великі дані в єдиний кластерний аналітичний двигун, який все одно рано чи пізно захлинеться і доведеться його некрасиво шардити. Хочеться зберігати файли, просто файли, у зрозумілому форматі та виконувати за ними ефективні аналітичні запити різними, але зрозумілими інструментами. І файлів у різних форматах буде дедалі більше. І краще шардити не двигун, а вихідні дані. Нам потрібен розширюваний та універсальний DataLake, вирішили ми…
А що якщо зберігати файли в звичному і багатьом відомому хмарному сховищі Amazon S3, що масштабується, не займаючись власним приготуванням відбивних з Hadoop?
Зрозуміло, пердані «низячи», але інші дані якщо туди винести та «ефективно поганяти»?
Кластерно-бігдата-аналітична екосистема Amazon Web Services – дуже простими словами
Судячи з нашого досвіду роботи з AWS, там давно і активно використовується під різними соусами Apache Hadoop/MapReduce, наприклад у сервісі DataPipeline (заздрю колегам, ось навчилися його правильно готувати). Ось тут ми налаштували бекапи з різних сервісів із таблиць DynamoDB:
І вони регулярно виконуються на вбудованих кластерах Hadoop/MapReduce як годинник вже кілька років. «Налаштував і забув»:
Також, можна ефективно займатися датасатанізмом, піднявши для аналітиків Jupiter-ноутбуки у хмарі та використовувати для навчання та деплоїнгу AI-моделей у бій сервіс AWS SageMaker. Ось як це виглядає у нас:
І так, можна підняти собі або аналітику ноутбук у хмарі та причепити його до 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 та тягання докер-мокер контейнерів та усунення конфліктів залежностей.
Ще раз – проста ідея. Не потрібно налаштовувати Apache Spark, потрібно лише написати код на python для pyspark, протестувати його локально на робочому столі і потім запустити на великому кластері в хмарі, вказавши, де лежать вихідні дані і куди покласти результат. Іноді це потрібно і корисно і як це налаштовано у нас:
Таким чином, якщо потрібно щось обрахувати на Spark-кластері на даних у s3 - пишемо на python/pyspark код, тестуємо і в добрий шлях у хмару.
А що з оркеструванням? А якщо завдання впало та зникло? Так, пропонується зробити гарний пайплайн в стилі Apache Pig і ми навіть спробували їх, але вирішили поки що використовувати своє глибоко кастомізоване оркестрування на PHP і JavaScript (я розумію, виникає когнітивний дисонанс, але працює, роками і без помилок).
Формат файлів, що зберігаються в озері, — ключ до продуктивності.
Дуже важливо зрозуміти ще два ключові моменти. Щоб запити за даними файлів в озері виконувалися максимально швидко та продуктивність не деградувала при додаванні нової інформації, потрібно:
- Колонки файлів зберігати окремо (щоб не потрібно було прочитати всі рядки, щоб зрозуміти, що в колонках). Для цього ми взяли формат parquet зі стисненням
- Дуже важливо шардувати файли за татками в дусі: мова, рік, місяць, день, тиждень. Двигуни, які розуміють цей тип шардування, будуть дивитися тільки в потрібні папочки, не перелопатуючи через себе всі дані поспіль.
По суті, таким способом, ви викладаєте в найбільш ефективному вигляді вихідні дані для аналітичних движків, що навішуються зверху, які і в шардовані папочки вміють вибірково заходити і читати з файлів тільки потрібні колонки. Не потрібно нікуди, вийдуть, "заливати" дані (сховище ж просто лусне) - просто відразу розумно їх покладіть у файлову систему у правильному форматі. Зрозуміло, тут має бути зрозуміло, що зберігати в DataLake величезний csv-файл, який потрібно спочатку весь терміново прочитати кластером, щоб витягти колонки - не дуже доцільно. Подумайте над двома вищезгаданими пунктами ще раз, якщо поки що незрозуміло навіщо все це.
AWS Athena - "чорт" з табакерки
І тут, створюючи озеро, ми, якось мимохідь, натрапили на Amazon Athena. Несподівано виявилося, що акуратно склавши по шардах-папочках у правильному (parquet) колонковому форматі наші файли величезних логів - можна дуже швидко по них робити вкрай інформативні вибірки та будувати звіти БЕЗ, без Apache Spark/Glue кластера.
Двигун Athena, що працює на даних у s3, заснований на легендарному - Представника сімейства MPP (massive parallel processing) підходів до обробки даних, що бере дані там, де вони лежать, від s3 і Hadoop до Cassandra та звичайних текстових файликів. Потрібно просто попросити Athena виконати SQL-запит, а далі все працює швидко і саме. Athena "розумна", ходить тільки в потрібні шардовані папочки і зчитує тільки потрібні в запиті колонки.
Тарифікуються запити до Athena також цікаво. Ми платимо за . Тобто. не за число машин у кластері щохвилини, а… за реально проскановані на 100-500 машинах лише необхідні виконання запиту дані.
А запитуючи тільки потрібні колонки з правильно шардованих папок, виявилося, що сервіс Athena нам коштує десятки доларів місяць. Ну, чудово ж, майже безкоштовно, порівняно з аналітикою на кластерах!
Ось, до речі, як ми шардуємо свої дані в s3:
В результаті, за короткий час, у компанії зовсім різні підрозділи, від інформаційної безпеки до аналітики, почали активно робити запити до Athena і швидко, за секунди, отримувати корисні відповіді з «великих» даних за досить великі періоди: місяці, півріччя тощо. п.
Але ми пішли далі і почали ходити за відповідями у хмару : аналітик у звичній консолі пише SQL-запит, який на 100-500 машинах "за копійки" шерстить дані в s3 і повертає відповідь зазвичай за одиниці секунд. Зручно. І швидко. Досі не віриться.
У результаті, прийнявши рішення зберігати дані в s3, в ефективному колонковому форматі і з розумним шардування даних по таткам ... ми отримали DataLake і швидкий і дешевий аналітичний двигун - безкоштовно. І він став дуже популярним у компанії, т.к. розуміє SQL і працює на порядки швидше, ніж через запуски/зупинки/налаштування кластерів. "А якщо результат однаковий, навіщо платити більше?"
Запит до Athena виглядає приблизно так. За бажання, звичайно, можна сформувати достатньо , але ми обмежимося простим угрупуванням. Подивимося, які коди відповідей були у клієнта кілька тижнів тому у логах роботи веб-сервера і переконаємося, що помилок немає:
Висновки
Пройшовши, не сказати що довгий, але болісний шлях, постійно адекватно оцінюючи ризики та рівень складності та вартість підтримки, ми знайшли рішення для DataLake та аналітики, яке нас не перестає радувати як швидкістю, так і вартістю володіння.
Виявилося, що побудувати ефективне, швидке і дешеве в експлуатації DataLake для потреб абсолютно різних підрозділів компанії - цілком під силу навіть досвідченим розробникам, які ніколи не працюють архітекторами і не вміють малювати квадратики на квадратиках зі стрілочками і знають 50 термінів з екосистеми Hadoop.
На початку шляху голова розколювалася від безлічі диких зоопарків відкритого та закритого софту та розуміння вантажу відповідальності перед нащадками. Просто починайте будувати свій DataLake від простих інструментів: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 …, збираючи зворотний зв'язок і глибоко розуміючи фізику процесів, що відбуваються. Все складне та каламутне — віддавайте ворогам та конкурентам.
Якщо ви не хочете в хмару і любите підтримувати, оновлювати та патчити відкриті проекти, можна побудувати аналогічну схему локально, на офісних недорогих машинках з Hadoop і Presto зверху. Головне - не зупинятися і йти вперед, рахувати, шукати прості та ясні рішення і все обов'язково вийде! Успіхів усім і до нових зустрічей!
Джерело: habr.com