Bigdata

Паша Финкельштейн разработчик, серийный спикер, автор и ведущий нескольких подкастов. На конференции Java Meeting Point он сделает доклад Spark: let's touch it, на котором познакомит участников с миром больших данных.

В этом интервью Паша рассказал, что ждет участников конференции, как он начал заниматься DevRel-активностями и что, по его мнению, должно быть в хорошем докладе.

Расскажи, чем ты занимаешься?

Я Developer Advocate в JetBrains, занимаюсь темой Big Data и дата-инжиниринга. Я пытаюсь рассказывать людям о том, как устроен мир Big Data, что там интересного, какие есть инструменты.

О чем будет твой доклад на Java Meeting Point?

Я расскажу, что такое большие данные и как они отличаются от маленьких. Разберемся, как работает Apache Spark, как устроен его API, и поймем, что ничего принципиально сложного в этом нет.

Кому будет полезно посмотреть доклад?

Полезно будет Java или JVM-разработчикам ровня Middle+ и тем, кому интересно узнать, как работает Apache Spark. Мы научимся писать простенькие пайплайны на этом фреймворке. Станет понятно как, например, взять и написать пайплайн обработки данных на Apache Spark или проанализировать данные в датасете.

Ты много занимаешься DevRel-активностями: выступаешь с докладами, вел подкасты. Как ты начал этим заниматься?

Мой друг Слава Семушин уехал работать в Чехию. Я не особенно умею поддерживать отношения на расстоянии, но Слава очень классный, с ним хотелось продолжать общаться. Однажды он написал: Слушай, давай запишем подкаст. Решили попробовать, и так родился подкаст Паша+Слава.

Раз в пару недель мы созванивались и говорили на околотехнические темы. Потом к нам присоединился еще один Слава Артемьев, с которым я работал в компании Домклик. Очень удобно не пришлось менять название подкаста. Так возникла моя первая публичность.

Потом появилась идея выступить на сцене, и я сделал доклад на Joker. В последствии этот доклад я переделывал 3 раза и выступил с ним 14 раз.

С тех пор я подсел на этот крючок и сделал десятки докладов. Со временем мне стало намного проще их готовить. Я могу подготовить выступление по теме, в которой я не разбираюсь за неделю, а теме, в которой разбираюсь за 2-4 дня.

Можешь посоветовать, как научиться так же быстро готовить выступления?

Я думаю, это так не работает. У всех людей свой темп, и нужно себя любить и работать в комфортном режиме. И рассказывать про то, что хочется. Доклады из-под палки никогда не получатся хорошими, прожитыми.

Что должно быть в хорошем докладе?

Он должен быть живым и интересным, в нем должны быть эмоции, шутеечки. В нем не должно быть слишком много мыслей, но те, которые есть, не должны быть заезженными. Неплохо, если информация из доклада применима на практике. Людям становится интереснее, когда они понимают, как они смогут использовать эту информацию.

Альтернативный вариант, это если доклад полностью теоретический. На такой люди придут вывернуть мозги. Так тоже можно, но сложно. Я один раз сделал доклад про внутренности Kotlin, людям не зашло.

Я люблю странные форматы: лайвкодинги, демки, парные доклады. Мне кажется, что у меня получается неплохо. Но не любить какой-то из этих форматов нормально, выбирайте для себя тот, который больше нравится.

Какой формат будет у твоего доклада на Java Meeting Point?

Это будет демо, на котором Java или JVM-разработчик на примере не очень больших данных сможет посмотреть, как работают большие. Мы посмотрим 5-6 слайдов и перейдем к программированию.

Короткий обзор очередных обновлений смотрелки логов chipmunk. Много исправлений, много корректировок и немного фишек, в том числе запрашиваемых сообществом.

Последний релиз 2.16.2 вышел пару дней назад и содержит довольно много исправлений, кроме того оптимизирована работа ряда функций. Нет смысла останавливаться на полном перечне изменений, но стоит упомянуть о том, что могло бы быть полезно вам.

В деталях

Появилось новое приложение для боковой панели Shell. Фактически это простая запускалка консольных команд. Работает крайне просто вбиваем команду смотрим вывод. Таким образом вы можете проанализировать в chipmunk вывод от любой интересующей вас команды, будь то adb logcat, journalctl или tail.

Кстати о последнем, мы получали от сообщества вопросы о поддержке обновления открытого файла и это будет реализовано в версии 3.0 вместе с миграцией всего ядра на rust. Однако, уже сейчас вы можете просто запустить команду tail -f name_of_live_logfile и получать живой вывод. Естественно, если при этом у вас будет активный поиск, то и результаты его будут обновляться автоматически.

Кроме того, Shell позволяет редактировать переменные окружения. Вы можете изменить или добавить переменные, сохранить всё в ваш профайл и после просто его выбрать. Может быть весьма удобно, если какая-то из ваших консольных программ берёт данные из окружения.

Блиц

• DLT коннектор теперь понимает и UDP, и TCP, и IPv4 и IPv6. Последние не требуют каких-либо галочек и переключателей, тип адреса будет определён автоматически. Также можно подключиться к нескольким multicast точкам.

• Исправили рендер графиков. Теперь все отрисовывается корректно и при изменении размеров окна, и при переключении между сессиями.

• От встроенного терминала решили отказаться. Он не несёт в себе никакого функционала, который можно было бы с пользой интегрировать с chipmunk, но добавляет головной боли с точки зрения зависимостей и стабильности работы программы.

• Научили chipmunk обновляться через прокси (соответствующие настройки можно найти в меню Settings/General/Network

• Добавили поддержку копирования и экспорта результатов поиска.

Пожалуй это самое важное. Я не рискну сейчас анонсировать точные сроки по версии 3.0 с ядром на rust, скажу лишь то, что мы рассчитываем на этот год. И это будет легче достигнуть с Вашей поддержкой ведь каждая новая звёздочка на github это не только ценная обратная связь, но и наша ответственность перед Вами!

Спасибо. Тепла, добра и света!

Команды Airbnb собрались вместе, чтобы за год создать SLA Tracker визуальный аналитический инструмент, помогающий формировать культуру своевременности данных. Этот информационный продукт позволил нам разрешить и систематизировать следующие вопросы своевременности набора:

1. Когда считать, что набор опоздал?

2. Какие данные часто опаздывают?

3. По какой причине набор опоздал?

Трекер важная часть усилий в достижении высокого качества данных, и, чтобы создать его, потребовалось преодолеть многие технические, организационные проблемы и проблемы продукта. Здесь остановимся на дизайне: расскажем, как проектировали и создавали визуализацию о своевременности данных.

Данные запаздывают

Своевременность данных крайне важна для бизнеса, однако поставлять их вовремя трудно: путь от сбора до конечного вывода содержит множество шагов. В Airbnb и везде, где работают большие конвейеры, сырые наборы данных очищаются, объединяются и преобразуются в структурированные данные, затем эти данные улучшают функции продукта, позволяя аналитикам принимать обоснованные решения.

Для своевременной поставки данных Airbnb мы стремимся к тому, чтобы владельцы каждого промежуточного шага фиксировали соглашения об уровне обслуживания (SLA) по доступности данных к конкретному времени. Например, владелец набора обещает, что метрика "бронирование" будет содержать самые актуальные данные к 5 утра по UTC, и если набор к этому времени недоступен, то он опоздал.

Как часто наборы опаздывают?

Сначала мы решили, что, опираясь на представление отчёта, Report поставщики данных должны понимать, когда данные выгружены и как часто они соответствуют SLA (рис. 1).

В этом представлении поставщики в реальном времени отслеживают ситуацию и видят тенденции по нескольким наборам, которыми владеют или которым уделяют внимание.

Мы также позаботились о том, чтобы инструмент был полезен даже при отсутствии формального заданного SLA, когда проявится типичное время выгрузки. При первом запуске инструмента SLA ещё не было, кроме того, есть наборы, которые используются не очень широко, то есть SLA им не требуется.

В Report используются традиционные списки объектов данных и небольшие визуальные эффекты, которые кратко обобщают типичное время выгрузки и исторические данные. Поставщики могут организовать наборы по спискам и работать со списками командно. Благодаря такому обобщению данных время выгрузки и производительность SLA понять так же просто, как курировать список наборов.

Отчётность только вершина айсберга

Хотя Report сильно упрощает понимание того, действительно ли набор опаздывает, это представление не решило главные проблемы SLA:

• Каково разумное SLA набора?

• Как понять причину опоздания?

Это проблемные вопросы, потому что наборы зависят друг от друга и возникают последовательно: сначала одно преобразование, затем другое (рис. 2).

Таким образом, наличие одного набора неразрывно связано с иерархически сложным "происхождением" других наборов. Чтобы установить реалистичное SLA, нужно учитывать дерево зависимостей, которое иногда состоит из 100 сущностей, а также их SLA.

Добавим к этому сложности: когда что-то идёт не так, попытка сопоставить иерархические зависимости со временной последовательностью даёт результат: SLA упущено и ничего не видно. Трудно рассуждать о причинах в такой ситуации. Инструментальная оснастка Airbnb позволила дата-инженерам выявлять проблемы в конвейере одной команды; сделать то же самое на конвейерах нескольких команд экспоненциально сложнее.

Почему набор опоздал?

Ранний дизайн

Чтобы поставщики данных видели зависимости набора и временные рамках этих зависимостей, разработано представление о происхождении набора Lineage.

Информация о происхождении данных это от 10 до 100 таблиц, а каждая таблица это 30 дней исторических данных, а также SLA и связей между ними, поэтому мы нуждались в краткой форме представления, а это от 1,000 до 10,000 отдельных точек данных.

В наших первоначальных исследованиях акцент делался на происхождении выгрузки, но не на последовательности во времени (рис. 3). Несмотря на то что зависимости небольших участков линии происхождения понять было легко, не получалось выделить те из них, что вызывали задержки выполнения в общем конвейере, а также было трудно понять, сколько времени создавался набор.

Фокус на времени с помощью представления Timeline

Затем мы сместили акцент на последовательности во времени. Чтобы представлять последовательности, мы создали диаграмму Ганта, включающую зависимости (рис. 4) с такой функциональностью:

• Каждая строка представляет набор в смысле происхождения, конечный набор расположен наверху.

• У каждого набора есть горизонтальная полоса, отображающая начало, продолжительность и время окончания задачи обработки данных в пределах выбранных дат или времени.

• Если набор имеет SLA, время обозначается вертикальной линией.

• Распределения типичного времени начала и окончания помечены, чтобы помочь поставщикам данных оценить, опережают ли они график или не успевают и подвергают риску следующий набор.

• Между родительскими и дочерними наборами рисуются дуги, чтобы поставщики данных прослеживали происхождение и смотрели, не вызваны ли задержки зависимостями.

• Выделенные дуги представляют важнейшие узкие места.

С таким дизайном легко найти проблемный шаг (это часто длинный красный столбик) или определять общесистемные задержки, когда все шаги занимают больше времени, чем обычно (много жёлтых полос, каждая из которых длиннее типичного времени выгрузки). С помощью этой визуализации многие команды Airbnb сегодня отлаживают задержки в данных.

Ищем иголку в стоге сена "узкие" места

В наборах с очень большими деревьями зависимостей было трудно найти релевантные медленные узкие места, которые задерживают весь конвейер. Мы смогли существенно снизить уровень шума и выделить эти проблемные наборы, разработав концепцию узкого места последовательности последних полученных наборов-предков, препятствующих запуску преобразования дочерних данных и тем самым задерживая весь конвейер (рис. 5).

Погружение в историческое представление (Historical)

Итак, узкое место выявлено. Теперь важный вопрос вызвана задержка на этом этапе длительностью самой работы или замедлениями в зависимостях? Ответ на этот вопрос помогает поставщикам данных понять, нужно ли оптимизировать именно их конвейер, или, чтобы сократить время SLA, нужны переговоры с владельцами зависимостей. Чтобы позволить отслеживать причины, мы построили подробное представление выполнения выгрузки набора, показывающее длительность и выполнения, и задержки (рис. 6).

Процесс и оснастка

Почти год мы потратили на разработку концепции, проектирование, создание прототипов и внедрения SLA Tracker в производственную среду. Большая часть этого времени потрачена на разработку API данных в UI и на итерации Lineage.

Чтобы упростить Report, мы использовали статические конструкции и прототипы экранов с хот-спотами (инструмент Clickthrough Prototypes) и универсальные поддельные данные. В альфа- и бета-релизах мы выполняли итерации визуального языка, то есть визуализировали данные так, чтобы их было проще охватить и понять (рис. 8).

Совершенно иначе мы подошли к проектированию Lineage. Его информационная иерархия продиктована формой данных. Таким образом, критично прототипирование на выборках реальных данных. Мы разработали эти прототипы на TypeScript, используя низкоуровневый набор компонентов визуализации visx для React, этот набор позволяет повторно использовать код при внедрении в производственную среду (рис. 9).

После обретения уверенности в нашей визуализации, но до внедрения в производственную среду мы доработали визуальные элементы статических макетов в Figma (рис. 10).

Заключение

В этом проекте мы применили визуализацию данных и UI/UX-дизайн междисциплинарную область, которую называем "Data Experience", в отношении важных проблем своевременности данных, требующих глубокого понимания сложной временной и иерархической информации. Это позволило сделать анализ своевременности данных доступным даже в сложной экосистеме данных крупной компании. Для разработки сложных инструментов визуального анализа требуются время и итерации, но результат работы может принести большую пользу.
Если хотите научиться работать с данными не хуже специалистов из Airbnb то приходите учиться. Будет сложно, но интересно!

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Мутная вода и важность мониторинга

Удобно, когда не видно кто, что и когда делает?

Говоря о производстве, можно услышать да, конечно, многим это удобно!

Во-первых, это удобно операторам, которые работают непосредственно за станком. Сделал не по технологии - не страшно, никто не увидит. Сделал бракованную деталь не проблема, выбросил и работаешь дальше спокойно. Нужно сделать что-то на сторону легко, никто же не узнает. Хочется вздремнуть в ночную смену поставил выполнение программы на паузу или, наоборот, сделал обороты повыше и ушел отдыхать.

Во-вторых, это удобно тем, кто отвечает за приобретение нового оборудования и руководителям цехов. При слабых показателях выпуска всегда можно сослаться на нехватку станков. Не видя, как оборудование работает, обосновать закупку нового станка не составляет труда. По факту же станки недозагружены или не работают вовсе.

Ну и в-третьих, это удобно технологам, которые выполняют технологическую подготовку производства. Как правило, они формируют потребность в инструменте, расход которого на любом производстве это огромные траты бюджета. Поэтому, если кому-то нужно, чтобы закупалось больше режущего инструмента или, чтобы его номенклатура была шире, то обосновать это несложно, когда никто ничего не видит.

И таких недобросовестных выгодоприобретателей от ловли рыбки в мутной воде предостаточно: от производственного персонала (операторов станков), до инженерного персонала (технологов, главных инженеров, главных энергетиков) и руководителей (начальников цехов). К сожалению, при такой ловле страдает высшее руководство и все предприятие в целом, которое практически становится заложником данной ситуации. К примеру, руководителю крайне сложно возражать технологу, который настаивает, что именно такая номенклатура режущего инструмента является оптимальной. Или, например, начальнику цеха, который говорит, что не может выполнить план, так как свободных мощностей попросту нет, настаивая на покупке еще одного нового станка.

Всего несколько лет назад покупка еще одного станка или увеличение номенклатуры инструмента не была проблемой. Это не требовало первостепенного внимания со стороны высшего руководства. Не успеваем покупаем еще станок, есть узкое место по выпуску покупаем еще станок, много уходит в брак покупаем еще один более современный станок. Покупка новых станков требует больше инструмента. Станки все современнее, значит номенклатура режущего инструмента все шире. Это не проблема, пока у компании есть деньги.

Как только пропадает возможности купить новый станок и выделить с десяток миллионов рублей в год на режущий инструмент, все становится не так позитивно. Руководство начинает больше интересоваться работой производства изнутри и задавать непривычные вопросы нашим рыбакам. Например: Мы столько купили современных станков, а выпуск практически не растет?, Мы закрываем все больше и больше нормочасов ежемесячно, а готовой продукции больше выпускать не стали?, Все наши станки загружены, а на складе готовой продукции нет?, Мы столько тратим на режущий высокотехнологичный инструмент, а циклы обработки меньше не стали?. После таких вопросов многие начинают покупать и внедрять системы мониторинга станков, понимая, что с их помощью можно получить ответы и решить проблемы.

Сегодня убеждать в важности мониторинга станков уже никого не нужно. Мониторинг станков стал не столько важным, сколько обязательным элементом современного предприятия. Однако, как это ни странно, есть мониторинг, который делает еще хуже и только вредит предприятию. Давайте в этом разберемся подробнее.

Не все то золото, что блестит или заблуждения при мониторинге станков

В современном быстроменяющемся мире очень важно знать, в какие годы та или иная система мониторинга начала создаваться. Отчасти это связано с тем, что в разные времена, были разные проблемы, которые можно было решать с помощь мониторинга. А также сильно повлияло развитие самих технологий (информационных, передачи данных, производственных), которые накладывали сильный отпечаток на возможности мониторинга, а следовательно, и на системы мониторинга. Если мы посмотрим, например, на технологии 10-15-летней давности, то увидим: Windows XP, MS Internet Explorer 8, .NET Framework 2.0, Java 5.0, iPhone первых поколений. Разве эти технологии смогут решить проблемы современного человека? Давайте посмотрим на производственное оборудование того же времени. Что мы увидим? Производители только начали использовать программируемые контроллеры (ПКЛ) Simatic S7-200, Mori Seiki только объединилась с Gildemeister, а станки не такие умные и производительные, как сейчас. Все это сильно сказалось на системах мониторинга того времени.

К глубокому сожалению, устаревшие системы мониторинга существуют и по сей день. Узнать их очень легко. Они, как правило, отслеживают небольшое количества параметров станка: работает, не работает, какая программа выполняется, авария, причина остановки. Источником данных в этих системах всегда выступает производственный персонал, который эти данные вводит вручную. Например, как только станок начинает работать по программе, они отмечают это в системе мониторинга указывая имя программы. Когда станок перестает работать они указывают причину остановки. На основе этих данных строятся разные отчеты, графики, таблицы, которые с разных ракурсов показывают информацию о простоях, сколько времени станок не работал и по какой причине.

Своевременность ввода данных и их корректность в таких системах мониторинга на совести того, кто эти данные указывал, то есть оператора, который работал непосредственно за станком. А как мы узнали в самом начале, эти ребята очень любят мутную воду. Но ведь раньше никто не знал, чем они занимаются, а теперь все увидят! Конечно нет, увидят только то, что они захотят показать. Если им будет выгодно - они укажут, если нет не будут. Нужно, чтобы оборудование меньше простаивало, значит нужно указать, что оно работает. Работает полезно или бесполезно это не важно, главное, чтобы работало. Все просто, всем удобно.

Помимо своевременности и корректности данных, есть еще один недостаток, который присущ всем системам мониторинга 10-летней давности и старше. Этот недостаток фокус, то есть цели и задачи, которые эти системы решают. Повторим, раньше в производстве были другие проблемы, нежели сейчас. Когда покупался новый станок, то главной задачей было сделать так, чтобы он как можно больше работал. Понятное желание, особенно если целью покупки было освоение денег или мнимое увеличение производственных мощностей. Однако, системы мониторинга, фокус которых направлен на простои, не могут показать, насколько хорошо или плохо работает станок. Их фокус направлен только на время, показывая работает он или нет.

Конечно, разработчики таких систем мониторинга стараются их развивать, добавляют новую функциональность, усовершенствуют интерфейс пользователя. Однако, как и ранее, все строится вокруг причин простоя. Изначальный фокус на простои, как сильнейший магнит притягивает все к себе.

Современные системы мониторинга тоже требуют отдельного изучения. Как правило, такие системы разрабатываются молодыми командами, которые испытывают нехватку опыта. Если у команды квалифицированные программисты, значит нехватка опыта будет ощущаться в области производства. Вряд ли они будут хорошо разбираться в циклах обработки, нюансах технологической подготовки производства, режимах резания и т.д. Обратная сторона, когда у команды опытные постановщики задач, которые хорошо разбираются в производстве, а программисты без большого опыта. При таком сценарии технологии больших данных вряд ли будут ими использоваться. В каждом случае системы мониторинга, созданные такими командами, не будут эффективными. Если у команды нет опыта в области производства, значит фокус системы будет направлен на такие простые в понимании вещи, как работает станок или нет. Кроме того, такие системы легко сможет обмануть производственный персонал, а это та же мутная вода. Если у команды нет опыта в программировании, значит будут проблемы с производительностью. Скорее всего технологии больших данных ими применяться не будут, а это значит, что спустя год или даже полгода система будет неработоспособной, так как не будет в состоянии обрабатывать накопленный объем данных.

Почему простои это вред?

Для начала разберемся, что такое простой. Простой это время, когда станок был включен, но программа на нем не выполнялась. Мы уже разобрались, что многие системы мониторинга имеют фокус на простои. Зная причину простоя оборудования, можно ее устранить. Например, зная, что станок часто простаивает из-за отсутствия нужного инструмента, можно реорганизовать процесс подготовки рабочего места, чтобы оператор не тратил время на подготовку, а использовал заранее подготовленный специальным человеком инструмент. Фактически устраняя необоснованные простои, увеличивается время, когда станок работает. Это логично и понятно многим. Давайте посмотрим на экономику.

Допустим стоимость 1 часа работы станка составляет 1 000 рублей. За 1 год станок не работал 4 380 часов. Если сократить это время на 1%, то повышение производительности станка будет 43 800 рублей (4 380 / 100 = 43.8 * 1 000 = 43 800). Можно и дальше пофантазировать. Например, если мы сократим на 100 станках время простоя на 10%, то получим 43800000 рублей. И так фантазировать можно бесконечно. Но это все только фантазии, так как если станок будет работать больше, это не означает, что он будет делать больше продукции. Одну и ту же операцию можно сделать за 4 часа, а можно за 40 минут. Получается, что, сократив время простоя станка, мы не повысим производительность станка. Здесь нет прямой зависимости, как многим хотелось бы.

При таком подходе не смотрят на то, как оборудование работает. Работает цель достигнута. На современном производстве рост производительности напрямую зависит от того, насколько хорошо станок работает. Что это значит? Под качеством работы станка понимается время, когда изменялась геометрия заготовки, нагрузка на всех управляющих органах была выше определенного установленного значения, положения подачи и скорости было на 100% и станок был в режиме AUTO. Давайте еще раз посмотрим на экономику, но уже полезной работы, а не простоев.

За 1 год станок полено работал 2 190 часов и сделал 1500 деталей. Если мы увеличим полезную работу на 1%, то сделаем на 15 деталей больше (1 деталь за 1.46 часа, 2 190 / 100 = 21.9 + 2 190 = 2 211.9 / 1.46 = 1 515). Верно и обратное. Если мы работаем над увеличением полезной работы станка, то в большинстве случаев время полезной работы будет уменьшаться, а количество деталей останется прежним. К примеру, за 1 год станок полено работал 2 190 часов и сделал 1500 деталей. Если мы уменьшим полезную работу на 1%, то высвободим 21.9 часа машинного времени, при этом сделаем те же 1500 деталей!

Лучшие практики и зарубежный опыт

Как вы уже поняли, основное заблуждение при подключении мониторинга станков это попытка сократить не то время, которое нужно. Вместо полезной и бесполезной работы станка внимание уделяется времени, когда станок не работал вовсе. Отчасти это связано с тем, что полезная работа станка это технология и лучшие практики подготовки производства. Специальная оснастка, подготовка инструмента вне станка, ограниченный перечень инструмента, работа на правильных режимах и без вмешательств, и многое другое. Увеличение полезной работы станка это постоянная ежедневная работа. Именно в этом колоссальная польза от мониторинга, которая ее сильно упрощает.

Современный мониторинг это в первую очередь линейка, которая показывает насколько все хорошо или плохо. Конечно, есть разные линейки, и отличаются они точностью. Точность в этом случае определяется своевременностью, объективностью и объемом данных.

Помимо линейки, современный мониторинг служит неким фонарем, который в мутной воде подсвечивает проблемные места. Также, как есть разные линейки, есть и разные фонари. Отличаются они тем, что именно освещают, куда и на что заставляют обращать внимание.

Как часто мы видим распечатанные графики с показателями загрузки на производстве? По этим графикам можно легко понять удалось ли ввести в заблуждение руководство при внедрении системы мониторинга станков. Если вы видите на этих графиках цифры в 70% загрузки и выше, значит авантюра удалась.

Дружбы одна из важнейших механик любой социальной сети. Подавляющее большинство взаимодействий происходит между пользователями, которые дружат: мы видим и комментируем записи друг друга в лентах, заходим в список друзей, чтобы найти знакомых и написать сообщение. Именно поэтому рост социального графа так важен.

Меня зовут Женя Замятин, я работаю в команде Core ML ВКонтакте. Хочу рассказать, как устроены рекомендации, которые делают ближе пользователей самой крупной социальной сети рунета.

Обзор

Современные рекомендательные системы зачастую состоят из двух уровней, и наша не исключение. Задача первого уровня искать наиболее релевантных кандидатов среди всего множества пользователей (у нас их сотни миллионов). Такая постановка задачи подразумевает высокую скорость работы. Обычно здесь используют простые в применении модели вроде матричных факторизаций или эвристики на базе числа общих друзей. Полученные на первом уровне кандидаты отправляются на второй. Здесь на модель уже не накладываются такие жёсткие ограничения по скорости, её главная задача обеспечить максимальную точность предсказаний и сформировать список, который увидит пользователь. В этой статье мы рассмотрим только первый этап уровень отбора кандидатов.

Прежде всего сформулируем задачу, которую будем решать: для каждого пользователя необходимо найти k кандидатов, которых он с наибольшей вероятностью добавит в друзья. Метрика, на которую будем ориентироваться, recall@k. Она идеально описывает задачу: на первом уровне нам не интересен порядок кандидатов, но важна их релевантность.

Сначала рассмотрим базовые решения, придуманные десятки лет назад, но до сих пор актуальные. Первым приходит на ум одно из самых логичных эвристика на основе числа общих друзей. Для каждого пользователя отбираются кандидаты с наибольшим таким значением. Этот подход просто реализуется и неплох по качеству.

Ещё один важный метод рекомендаций Adamic/Adar. В его основе лежит всё тот же анализ общих друзей, но с модификацией: авторы предлагают учитывать число друзей у общего друга. Чем больше это значение, тем меньше информации о релевантности он несёт.

Кроме методов на основе анализа общих друзей, довольно распространены рекомендации на базе эмбеддингов. В Лаборатории искусственного интеллекта ВКонтакте в МФТИ мы провели исследование: сравнили эффективность разных подходов к задаче предсказания дружб в VK. Результаты совпали с нашим опытом решения на базе графовых эмбеддингов у нас работают плохо. Учитывая это, мы стали развивать систему отбора кандидатов по пути анализа общих друзей.

EGOML

Общая схема нашего метода продолжает идеи числа общих друзей и Adamic/Adar. Финальная мера релевантности E(u, v), с помощью которой мы будем отбирать кандидатов, всё так же раскладывается в сумму по общим друзьям u и v. Ключевое отличие в форме слагаемого под суммой: в нашем случае это мера ez_c(u, v).

Сначала попробуем понять физический смысл меры ez_c(u, v). Представим, что мы взяли пользователя c и спросили у него: Насколько вероятно, что два твоих друга, u и v, подружатся? Чем больше информации для оценки он учтёт, тем точнее будет его предсказание. Например, если c сможет вспомнить только число своих друзей, его рассуждения могут выглядеть следующим образом: Чем больше у меня друзей, тем менее вероятно, что случайные двое из них знакомы. Тогда оценка вероятность дружбы u и v (с точки зрения c) может выглядеть как 1/log(n), где n число друзей. Именно так устроен Adamic/Adar. Но что если c возьмёт больше контекста?

Прежде чем отвечать на этот вопрос, разберёмся, почему ez_c(u, v) важно определять через пользователя c. Дело в том, что в таком виде очень удобно решать задачу распределённо. Представим, что теперь мы разослали всем пользователям платформы анкету с просьбой оценить вероятность дружбы в каждой паре их друзей. Получив все ответы, мы можем подставить значения в формулу E(u, v). Именно так выглядит вычисление E(u, v) с помощью MapReduce:

• Подготовка. Для каждого c выделяется тот контекст, который он будет учитывать для вынесения оценок. Например, в Adamic/Adar это будет просто список друзей.

• Map. Спрашиваем у каждого c, что он думает про возможность дружбы в каждой паре его друзей. По сути, вычисляем ez_c(u, v) и сохраняем в виде (u, v) ez_c(u, v) для всех u, v in N(c). В случае Adamic/Adar: (u, v) 1/log|N(c)|.

• Reduce. Для каждой пары (u, v) суммируем все соответствующие ей значения. Их будет ровно столько, сколько общих друзей у u и v.

Таким образом мы получаем все ненулевые значения E(u, v). Заметим: необходимое условие того, что E(u, v) > 0, существование хотя бы одного общего друга у u и v.

Контекстом пользователя c в случае меры ez_c будет тот же список друзей, но дополненный информацией о связях внутри этого списка. Такую структуру в науке называют эго-графом. Если более формально, эго-граф вершины x это такой подграф исходного графа, вершинами которого являются все соседи x и сама x, а рёбрами все рёбра исходного графа между этими вершинами. Коллеги из Одноклассников написали подробную статью об эго-графах и затронули в ней вопрос их эффективного построения.

Ключевая идея меры ez_c в том, что её можно сделать обучаемой. Для каждого пользователя c, его эго-графа и всех пар пользователей u, v внутри него мы можем посчитать много разных признаков, например:

• число общих друзей u и v внутри эго-графа c;

• число общих друзей u и c;

• интенсивность взаимодействий между v и c;

• время, прошедшее с последней дружбы между u и кем-либо из эго-графа c;

• плотность эго-графа c;

• и другие.

Таким образом мы получим датасет с признаками. Но для обучения нужны ещё и метки. Пусть датасет был построен по состоянию графа на момент времени T. Тогда в качестве положительных примеров возьмём те пары пользователей, которые не были друзьями на момент T, но подружились к T + T. А как отрицательные все остальные, не подружившиеся, пары пользователей. Заметим: поскольку мы решаем задачу предсказания новых дружб, те пары пользователей, которые уже дружат на момент T, учитывать не нужно ни на обучении, ни на применении.

В конечном счёте мы получаем датасет следующего вида:

• для каждой пары пользователей u и v, а также их общего друга c, посчитаны признаки по эго-графу c;

• пара пользователей u и v встречается в датасете ровно столько раз, сколько у них общих друзей;

• все пары пользователей в датасете не являются друзьями на момент времени T;

• для каждой пары u и v проставлена метка подружились ли они в течение определённого промежутка времени начиная с T.

По такому датасету мы и будем обучать нашу меру ez_c. В качестве модели выбрали градиентный бустинг с pairwise функцией потерь, где идентификатором группы выступает пользователь u.
По сути, мера ez_c(u, v) определяется как предсказание описанной выше модели. Но есть один нюанс: при pairwise-обучении распределение предсказаний модели похоже на нормальное. Поэтому, если в качестве определения меры ez_c(u, v) взять сырое предсказание, может возникнуть ситуация, когда мы будем штрафовать финальную меру E(u, v) за общих друзей, так как значения предсказаний бывают отрицательными. Это выглядит не совсем логично хочется, чтобы с ростом числа общих друзей мера E(u, v) не убывала. Так что поверх предсказания модели мы решили взять экспоненту:

Такой подход хорошо себя показывает на небольших графах. Но чтобы применить его на реальных данных, необходимо выполнить ещё одно действие. Суть проблемы такая: мы не можем вычислять признаки и применять модель для каждой пары пользователей всех эго-графов это слишком долго. Для решения мы придумали специальный трюк. Представим, что наш градиентный бустинг обучился таким образом, что каждое дерево использует признаки только одного пользователя: либо u, либо v. Тогда мы могли бы разделить весь ансамбль на две группы: к группе A мы бы отнесли деревья, которые используют только признаки пользователя u, к B пользователя v. Предсказание такой модели можно представить в виде:

Имея такую модель, мы могли бы получить предсказания для всех пар пользователей одного эго-графа быстрее. Достаточно применить модели A и B для каждого пользователя, а затем сложить соответствующие парам предсказания. Таким образом, для эго-графа из n вершин мы могли бы сократить число применений модели с O(n^2) до O(n). Но как получить такую модель, каждое дерево которой зависит только от одного пользователя? Для этого сделаем следующее:

1. Исключим из датасета все признаки, которые одновременно зависят и от u и от v. Например, от признака число общих друзей u и v внутри эго-графа c придётся отказаться.

2. Обучим модель A, используя только признаки на базе u, c и эго-графа c.

3. Для обучения модели B оставим только признаки на базе v, c и эго-графа c. Также в качестве базовых предсказаний передадим предсказания модели A.

Если объединим модели A и B, получим то что нужно: первая часть использует признаки u, вторая признаки v. Совокупность моделей осмысленна, поскольку B была обучена корректировать предсказания A. Эта оптимизация позволяет ускорить вычисления в сотни раз и делает подход применимым на практике. Финальный вид ez_c(u, v) и E(u, v) выглядит так:

Вычисление меры E в онлайне

Заметим, что E(u, v) можно представить в виде:

Эта формула скалярное произведение разреженных векторов, индексами которых являются пользователи, а значениями экспоненты предсказаний модели. Ненулевые значения здесь проставлены только у друзей u по сути это просто списки друзей с дополнительными значениями.

При построении рекомендаций мы уже вычислили предсказания моделей для всех существующих дружб. Поэтому для каждого пользователя мы можем собрать векторы и сложить их в доступное онлайн key-value хранилище. После этого сможем получать значение E(u, v) для любой пары пользователей в онлайне простой операцией перемножения векторов. Это даёт возможность использовать E(u, v) как лёгкую функцию релевантности в нагруженных местах либо как дополнительный признак финальной модели ранжирования.

Итог

В результате система EGOML позволяет:

1. Распределённо отбирать кандидатов для каждого пользователя в офлайне. Асимптотическая сложность оптимизированного алгоритма составляет O(|E|) вычислений признаков и применений модели, где |E| число связей в графе. На кластере из 250 воркеров время работы алгоритма составляет около двух часов.

2. Быстро вычислять меру релевантности E(u, v) для любой пары пользователей в онлайне. Асимптотическая сложность операции O(|N(u)| + |N(v)|).

3. Улучшать качество рекомендаций, расширяя количество учтённых графов (по дружбам, скрытиям рекомендаций, отправленным сообщениям и другим графам) и добавляя всевозможные метки на рёбра и вершины. Например, интенсивность взаимодействий на ребре, дату образования ребра, город, место работы или учёбы пользователя.

В конечном счёте мы перешли со способа отбора кандидатов с использованием Adamic/Adar к системе EGOML и внедрили в модель второй уровень признаков на основе меры E(u, v). И это позволило увеличить количество подтверждённых дружб со всей платформы на несколько десятков процентов.

Благодарность

Хочу сказать спасибо руководителю команды Core ML Андрею Якушеву за помощь в разработке метода и подготовке статьи, а также всей команде Core ML за поддержку на разных этапах этой работы.

Внимание! Если данная статья наберет 1000 положительных голосов, то я организую хакатон по алготрейдингу с ценными призами.

Предыдущая статья о "Расчете дневного изменения цены"

Когда я писал прошлую статью (она была первой из цикла) я не предполагал, что читатели разделятся на 2 категории:
1. Те, кто верят, что в алготрейдинг
2. Те, кто верят, что я шарлатан

Для обоих групп я напоминаю, что цель алготрейдинга - это увеличить вероятность получить прибыль от сделки
Или же, как говорят в "теории игр" - сделать математическое ожидание от игры положительным

Поэтому, предлагаю аудитории договориться о следующем:
1. Если ваш комментарий несет научный смысл, то пишите его под постом в Хабре.
2. Если ваш комментарий несет дискуссионный посыл, то прошу задавать его в специально созданном канале в телеге:

Собственно, здесь я перехожу к сути данной статьи.

SMA (Simple Moving Average, Скользящее среднее) - индикатор, основанный на подсчете среднего значения цены закрытия ценной бумаги.

Для тех, кто не знает что такое SMA, приведу алгоритм его подсчета:
1. Взять цену закрытия "close" ценной бумаги за период от t1 до t2 и отсортировать ее от t1 к t2.
2. Взять таймфрейм из первых N значений цены close.
3. Посчитать среднее арифметическое значение таймфрейма (simple average).
4. Сдвинуть таймфрейм вперед на одно значение (происходит moving) и выполнить пункт 3
5. Пункт 4 проводить до тех пор, пока таймфрейм не дойдет до точки t2

Отрисуем график SMA (N=20) для цены close акций Северсталь (тикер CHMF) за 27 мая 2021г.:

По графику видно, что SMA является сглаженной версией цены Close с временным лагом в 20 периодов.

Полосы Боллинджера (Bollinger Bands)

В 1980х годах Джон Боллинджер предложил рассчитывать не только SMA, но и STD (standart deviation, среднеквадратическое отклонение). Таким образом, мы будем видеть не только график изменения средней цены, но и ее волатильность.

Обычно, значения std устанавливают равным 2. В таком случае, с вероятностью в 95% следующее значение цены close будет лежать внутри полосы Боллинджера и только в 5% случаях оно будет выходить из этой полосы.

В тех местах, где цена close близка к нижней грани полосы Боллинджера, стоимость акций считается низкой. И, наоборот, если цена close близка к верхней грани полосы Боллинджера, стоимость акций считается высокой.

И тут у трейдера срабатывает чуйка: покупаем на низах, продаем на хаях (никак не наоборот).

Весь код с использованием полос Боллинджера привел на Google Colab. Данная стратегия принесла +1,7% за 1 день (но это не точно).

В следующей статье поговорим об RSI

Всем привет! Меня зовут Александр и я пишу код для 2ip.ru. За добрую половину сервисов можно пинать меня, готов отбиваться. Cегодня я хочу немного рассказать про переделку одного нашего старого сервиса. Это конечно не "big data", но всё равно довольно большие объемы информации, поэтому думаю будет интересно.

Речь пойдет про Сайты на одном IP, который как вы уже догадались, позволяет узнать все домены зарегистрированные на одном IP. Довольно удобно посмотреть кто присосался к вашему серверу (да, есть и такие), ну или чужому (например shared хостинг).

Как это всегда работало? Мы ходили в Bing с большого пула адресов и парсили выдачу по специальному запросу. Да, решение так себе, но что было то было. Было, потому что бинг прикрутил гайки и мы решили всё это сделать по человечески.

Своя база

Что если взять и спарсить весь интернет? В общем то не проблема, но мы не Google и больших ресурсов для кролинга не имеем. Или имеем?

Есть сервер с 12 ядрами и 64 гигами памяти, а в арсенале MySQL, PHP, golang и куча всяких фреймворков. Очевидно, что благодаря горутинам можно достичь неплохих результатов. Golang быстр и требует минимум ресурсов. По базе вопросы, потянет ли это все обычный MySQL?

Пробуем.

Делаем прототип

Собирать все домены дело неблагодарное, поэтому мы купили базу доменов размером в 260 миллионов записей. Сервисов, которые предоставляют свои услуги довольно много и стоит это копейки.

Итак на моем диске CSV файл размером 5 ГБ, дело за малым, написать масс ресолвер, который будет читать строку за строкой, а на выход в STDOUT, отдавать пару "домен - IP адрес"

Вопрос только в производительности, нужно делать это очень и очень быстро, мы не можем ждать результата месяц.

Несколько часов работы и мой демон на гоу готов. Мэйн получился примерно такой:

func main() {    file, err := os.Open("domains.txt")    if err != nil {        log.Fatal(err)    }    defer file.Close()    maxGoroutines := 500    guard := make(chan struct{}, maxGoroutines)    scanner := bufio.NewScanner(file)    for scanner.Scan() {        guard <- struct{}{}        host := scanner.Text()        go func(host string) {            resolve(host)            <-guard        }(host)    }    if err := scanner.Err(); err != nil {        log.Fatal(err)    }}

Суть в том, что мы можем набрать пул в 500 горутинов и непрерывно обрабатывать большое количество данных в единицу времени, подгружая равномерно все 12 ядер сервера.

Функция resolve опущена, но кратко это обычный ресолвер IP с выдачей результата в STDOUT. Обращаемся к DNS, получаем A записи, выдаем результат.

DNS

Прогуглив немного я понял, что большие DNS особо не лимитируют количество запросов с одного IP, но кто знает. Поэтому было принято решение поднять undbound из Docker.

В несколько кликов я получил рекурсивный DNS, попробовал запустить и разочаровался. Так как DNS рекурсивный и кеша у него никакого нет, обращения сначала идут к корневым, а дальше разбегаются по зонам. Происходит это очень и очень медленно, порядка десятка доменов в секунду.

Второй вариант Google DNS, тот который четыре восьмерки, оказался гораздо быстрее. У меня были опасения по лимитам в 500 запросов в секунду но по факту их нет.

Тестируем в localhost и на проде

Нельзя сказать что на тестовом ноутбуке граббер работал быстро. 500 горутинов машина не потянула, процесс падал через несколько секунд. Зато все кардинально поменялось на боевом сервере.

1000 горутинов упали на 12 ядрах, а вот 500 практически не грузили проц и работали стабильно. Мощность получилась на уровне ~2000 доменов в секунду.

Это приемлемо, при таком раскладе всю базу можно спарсить за пару суток. На практике все оказалось немного хуже, очень сильно тупит TLD .bar, о которой вероятно нормальный человек и не слышал.

В конечном счёте я оставил процесс в tmux и через трое суток получил CSV размером 10 Гб. Идём дальше.

Ура! Переходим к следующему шагу.

База данных

Я создал таблицу domain_ip, в которой всего два столбца домен и IP. Оба не уникальны, на один домен может приходиться несколько IP адресов.

IP - это обычный BIGINT domain - VARCHAR 255

Индексы

Очевидно, что выборка из 260 млн записей это довольно большая работа. Поэтому без индексов не обойтись, поиск у нас по IP адресу, значит его и индексируем.

20 минут импорта на тестовой машине и я понял что это фиаско, выборка работает медленно несмотря на индексы. 260 млн записей это очень много. Переходим к плану Б.

Партиципирование

Это метод разделения больших таблиц на мелкие и в дальнейшем уже обращение по нужному адресу сразу к конкретной таблице.

Я разделил весь пул IP адресов на 20 таблиц с шагом 200 млн. Получилось примерно так:

ALTER TABLE domain_ip PARTITION BY RANGE COLUMNS (ip)  (    PARTITION p0 VALUES LESS THAN (200000000),    PARTITION p1 VALUES LESS THAN (400000000),    PARTITION p2 VALUES LESS THAN (600000000),    PARTITION p3 VALUES LESS THAN (800000000),    PARTITION p4 VALUES LESS THAN (1000000000),    PARTITION p5 VALUES LESS THAN (1200000000),    PARTITION p6 VALUES LESS THAN (1400000000),    PARTITION p7 VALUES LESS THAN (1600000000),    PARTITION p8 VALUES LESS THAN (1800000000),    PARTITION p9 VALUES LESS THAN (2000000000),    PARTITION p10 VALUES LESS THAN (2200000000),    PARTITION p11 VALUES LESS THAN (2400000000),    PARTITION p12 VALUES LESS THAN (2600000000),    PARTITION p13 VALUES LESS THAN (2800000000),    PARTITION p14 VALUES LESS THAN (3000000000),    PARTITION p15 VALUES LESS THAN (3200000000),    PARTITION p16 VALUES LESS THAN (3400000000),    PARTITION p17 VALUES LESS THAN (3600000000),    PARTITION p18 VALUES LESS THAN (3800000000),    PARTITION p19 VALUES LESS THAN (4000000000),    PARTITION p20 VALUES LESS THAN (MAXVALUE) );

И как вы поняли это сработало, иначе зачем эта статья? :)

Импорт

Кто работал с MySQL знает, что вливать большие дампы данных это довольно долгая операция. За долгие годы работы я не нашел ничего лучше, чем импорт данных из CSV. Выглядит это примерно так:

LOAD DATA INFILE '/tmp/domains.csv' IGNORE INTO TABLE domain_ipFIELDS TERMINATED BY ',' LINES TERMINATED BY '\n'

Машина переваривает CSV размером ~10 Гб за 30 минут.

Финал

Как результат получился вот такой милый сервис. Выборка из ~300 миллионов записей происходит мгновенно на довольно скромном по нынешним меркам сервере. Оперативной памяти нужно под это всё порядка 8 Гб.

Теперь можно узнать например, что к IP 8.8.8.8 человечество прицепило 8194 домена, ну или придумайте сами ... ;-)

Спасибо за внимание.

Алексей Миловидов делает ClickHouse и, конечно, знает его вдоль и поперек. В том числе и о том, как его можно использовать дополнительно к его штатным и всем хорошо известным функциям.

И сегодня расскажет про эти необычные способы его использования и, может быть, даже не для хранения и обработки данных.

ClickHouse для тестов железа

Самое простое, что можно сделать с ClickHouse, если есть свободные серверы это использовать его для тестов оборудования. Потому что его тестовый dataset содержит те же данные с production Яндекса, только анонимизированные и они доступны снаружи для тестирования. Про то, как подготовить хорошие анонимизированные данные, я рассказывал на Saint HighLoad++ 2019 в Санкт-Петербурге.

Ставим ClickHouse на любой Linux (x86_64, AArch64) или Mac OS. Как это сделать? мы собираем его на каждый коммит и pull request. ClickHouse Build Check покажет нам все детали всех возможных билдов:

Отсюда можно скачать любой бинарник с gcc и clang в релизе, в debug, со всякими санитайзерами или без, для x86, ARM или даже Mac OS. ClickHouse использует все ресурсы железа: все ядра CPU, шины памяти и грузит все диски. Какой сервер ему не дай проверит полностью, хорошо или плохо тот работает.

По этой инструкции можно скачать бинарник, тестовые данные и запустить запросы. Тест займёт около 30 минут и не требует установки ClickHouse. И даже если на сервере уже установлен другой ClickHouse, вы все равно сможете запустить тест.

В результате мы получаем публичный список протестированного железа:

Все результаты мы получаем от пользователей через краудсорсинг и выглядят они примерно так:

Вы можете выбрать серверы для сравнения для каждого можно посмотреть разницу в производительности. Конечно, и других тестов железа существует немало, например, SPECint и вообще куча тестов из организации SPEC. Но ClickHouse позволяет не просто тестировать железо, а тестировать рабочую СУБД на настоящих данных на реальных серверах откуда угодно.

ClickHouse без сервера

Конечно, обычно ClickHouse это сервер + клиент. Но иногда нужно просто обработать какие-то текстовые данные. Для примера я взял все исходники ClickHouse, собрал их в файл и сконкатенировал в файл под названием code.txt:

И, например, я хочу проверить, какие строчки в коде на C++ самые популярные. С помощью типичной shell-команды удалим из каждой строчки кода начальные пробелы и пустые строки, отсортируем и посчитаем количество уникальных. После сортировки видим, что, конечно, самая популярная строчка это открывающая фигурная скобка, за ней закрывающая фигурная скобка, а еще очень популярно return false.

Этот результат я получил за 1,665 секунд. Потому что все это было сделано с учетом сложной локали. Если локаль заменить на простую, выставив переменную окружения LC_ALL=C, то будет всего лишь 0,376 с, то есть в 5 раз быстрее. Но это всего-лишь шел скрипт.

Можно ли быстрее? Да, если использовать clickhouse-local, будет еще лучше.

Это как-будто одновременно и сервер и клиент, но на самом деле ни то, и ни другое clickhouse-local может выполнять SQL запросы по локальным файлам. Вам достаточно указать запрос, структуру и формат данных (можно выбрать любой из форматов, по умолчанию TabSeparated), чтобы обработать запрос на входном файле. За 0.103 секунд то есть в 3,716 раз быстрее (в зависимости от того, как вы запускали предыдущую команду).

Для демонстрации чего-то более серьезного давайте посмотрим на те данные, которые собирает GitHub Archive это логи всех действий всех пользователей, которые происходили на GitHub, то есть коммиты, создание и закрытие issue, комментарии, код-ревью. Все это сохраняется и доступно для скачивания на сайте https://www.gharchive.org/ (всего около 890 Гб):

Чтобы их как-нибудь обработать, выполним запрос с помощью ClickHouse local:

Я выбрал все данные из табличной функции file, которая берет файлы вида *.json.gz то есть все файлы в формате TSV, интерпретируя их как одно поля типа string. С помощью функции для обработки JSON я вытащил из каждой JSONины сначала поле 'actor', а потом поле 'login' в случае, когда оно равно Алексей Миловидов и выбрал таких первых 10 действий на GitHub.

Может возникнуть впечатление, что 890 Гб данных смогли обработаться за 1,3 секунды. Но на самом деле запрос работает потоково. После того, как находятся первые 10 строк, процесс останавливается. Теперь попробуем выполнить более сложный запрос, например, я хочу посчитать, сколько всего действий я совершил на GitHub. Используем SELECT COUNT... и через полторы секунды кажется, что ничего не происходит. Но что происходит на самом деле, мы можем посмотреть в соседнем терминале с помощью программы dstat:

И мы видим, что данные читаются с дисков со скоростью примерно 530 Мб/с и все файлы обрабатываются параллельно почти с максимальной скоростью насколько позволяет железо (на сервере RAID из нескольких HDD).

Но можно использовать ClickHouse local даже без скачивания этих 980 Гб. В ClickHouse есть табличная функция url то есть можно вместо file написать адрес https://.../*.json.gz, и это тоже будет обрабатываться.

Чтобы можно было выполнять такие запросы в ClickHouse, мы реализовали несколько вещей:

1. Табличная функция file.

2. Поддержка glob patterns. В качестве имени файлов можно использовать шаблон с glob patterns (звёздочка, фигурные скобки и пр.)

3. Поддержка сжатых файлов в формате gzip, xz и zstd из коробки. Указываем gz и всё работает.

4. Функции для работы с JSON. Могу утверждать, что это самые эффективные функции для обработки JSON, которые мы смогли найти. Если вы найдёте что-нибудь лучше, скажите мне.

5. Параллельная обработка файлов. Там несколько тысяч файлов, и будут использоваться все процессорные ядра. И даже один файл будет обрабатываться параллельно, потому что у нас есть параллельный парсинг форматов данных.

6. Тот самый параллельный парсинг.

Применять можно, само собой, для обработки текстовых файлов. Еще для подготовки временной таблицы и партиций для MergeTree. Можно провести препроцессинг данных перед вставкой: читаете в одной структуре, преобразовываете с помощью SELECT и отдаете дальше в clickhouse-client. Для преобразования форматов тоже можно например, преобразовать данные в формате protobuf с разделителями в виде длины в JSON на каждой строке:

clickhouse-local --input-format Protobuf --format-schema такая-то --output format JSONEachRow ...

Serverless ClickHouse

ClickHouse может работать в serverless-окружении. Есть пример, когда ClickHouse засунули в Лямбда-функцию в Google Cloud Run: https://mybranch.dev/posts/clickhouse-on-cloud-run/ (Alex Reid). Там на каждый запрос запускается маленький ClickHouse на фиксированных данных и эти данные обрабатывает.

Текстовые форматы

Для обработки текстовых данных, естественно, есть поддержка форматов tab separated (TSV) и comma separated (CSV). Но еще есть формат CustomSeparated, с помощью которого можно изобразить и тот, и другой в качестве частных случаев.

CustomSeparated:

format_custom_escaping_rule

format_custom_field_delimiter

format_custom_row_before/between/after_delimiter

format_custom_result_before/after_delimiter

Есть куча настроек, которые его кастомизируют. Первая настройка это правило экранирования. Например, вы можете сделать формат CSV, но в котором строки экранированы как в JSON, а не как CSV. Разница тонкая, но довольно важная. Можно указать произвольный разделитель типа | и пр. между значениями, между строками и т.п.

Более мощный формат это формат Template:

format_template_resultset

format_template_row

format_template_rows_between_delimiter

С его помощью можно указать произвольный шаблон, где в строке есть подстановки, и в этих подстановках тоже указывается, какой столбец в каком формате отформатирован. Можно даже парсить XML, если очень надо.

Есть формат Regexp:

format_regexp

format_regexp_escaping_rule

format_regexp_skip_unmatched

И тут clickhouse-local превращается в настоящий awk. Указываете регулярные выражения, в Regexp есть subpatterns, и каждый subpattern теперь парсится как столбец. Его содержимое обрабатывается согласно некоторому правилу экранирования. И конечно можно написать пропускать строки, для которых регулярное выражение сработало, или нет.

ClickHouse для полуструктурированных данных

Первая идея в этом случае не использовать ClickHouse. Берите Mongo, которая отлично подходит именно для этого. Но если вдруг вы так любите ClickHouse, что просто не можете им не пользоваться можно и с его помощью.

Допустим, у вас есть таблица с логами, в ней есть столбец с датой и временем, а вот всё остальное вообще непонятно что. Очень соблазнительно всю эту кучу данных записать в один столбец 'message' с типом String. Если эта куча в формате JSON, функции для работы с JSON будут работать. Но неэффективно каждый раз, когда нам будет нужно только одно поле, например 'actor.login', читать придется весь JSON не будет преимущества столбцовой базы данных. С помощью ClickHouse мы легко это исправим прямо на лету, добавив с помощью запроса ALTER материализованный столбец:

После того, как материализованный столбец actor_login начнет записываться для новых данных в таблице, SELECT для новых данных будет читаться эффективно, а для старых будет вычисляться. Для материализации старых данных можно использовать несколько странный запрос для материализации всех данных в прошлом:

ALTER TABLE logs UPDATE actor_login = actor_login

И вы можете добавлять столбцы по мере необходимости, чтобы ускорить запросы.

Ускорение MySQL

В ClickHouse можно создать таблицу на основе табличной функции MySQL. Это просто: указываете хост: порт, БД, таблицу, имя пользователя и пароль (прямо так, как есть), делаем SELECT и всё выполняется за 15 секунд:

Работает это тоже без всякой магии: табличная функция MySQL переписывает запрос, отправляет его в MySQL и читает все данные назад, на лету на всё 15 секунд. Но что будет, если я тот же самый запрос выполню в MySQL как есть?

5 минут 41 секунда это позор! У ClickHouse тут как-будто нет преимуществ данные нужно переслать из MySQL в ClickHouse и потом уже обработать. А MySQL обрабатывает сам у себя локально почему же он так медленно работает?

Еще одна проблема результаты расходятся. У ClickHouse две строки счетчик (20577 и 13772), у MySQL один (44744), потому что он здесь учитывает collation (правила сравнения строк в разном регистре) при GROUP BY. Чтобы это исправить, можно перевести имя в нижний регистр, сгруппировать по нему и выбрать любой вариант:

Теперь счетчик один, данные почти совпадают и запрос даже ускорился. То есть ClickHouse быстрый независимо от того, какие выражения я напишу. Попробуем ускорить запрос еще больше. На основе данных из MySQL в ClickHouse можно создать словарь. Указываем в словаре ключ и источник MySQL со всеми этими данными:

Словарь будет периодически загружать таблицу в оперативку, она будет кэшироваться. Можно применять SELECT:

Получилось уже 6 секунд, хотя основное предназначение словаря использование для джойнов, когда, например, нам нужно получить данные динамически через другие столбцы. Можно также создать словари MySQL на каждом сервере в кластере ClickHouse и быстро с ними работать. Но если MySQL не выдержит нагрузки при обновлении словаря на каждом сервере в кластере, то можно создать из MySQL словарь на двух ClickHouse-серверах, и они будут доступны в виде таблиц в ClickHouse. Если с помощью движка Distributed создать таблицу, которая смотрит на эти два сервера как на реплики, то можно на всех ClickHouse-серверах создать словари из ClickHouse, которые смотрят на таблицу, которая смотрит на словарь MySQL.

Словари еще можно использовать для шардирования, если схема расположена во внешней мета-базе (и не обязательно в ClickHouse). Это тоже будет работать:

Есть вариант как радикально ускорить запрос, и для этого не нужны словари надо всего лишь переложить данные в полноценную таблицу типа MergeTree такой же структуры. Вставляем туда данные и делаем SELECT:

Видим, что SELECT выполняется за 0,6 с. Вот это настоящая скорость, какая должна быть это скорость ClickHouse!

В ClickHouse можно даже создать базу данных типа MySQL. Движок БД MySQL создает в ClickHouse базу данных, которая содержит таблицы, каждая из которых представляет таблицу, расположенную в MySQL. И все таблицы будут видны прямо в ClickHouse:

А вообще в ClickHouse много табличных функций. Например, с помощью табличной функции odbc можно обратиться к PostgreSQL, а с помощью url к любым данным на REST-сервере. И все это можно поджойнить:

Примечение: в свежих релизах ClickHouse появилась табличная функция postgresql, движок баз данных PostgreSQL и даже поддержка бинарного протокола PostgreSQL. Кажется это даже слишком круто.

Машинное обучение в ClickHouse

В ClickHouse можно использовать машинное обучение с помощью подключения готовых моделей CatBoost. После объявления модели в конфигурационном файле, она доступна для применения в виде функции modelEvaluate.

Это можно использовать для заполнения пропусков в данных. Пример: компания, занимающаяся недвижимостью, публикует объявления о квартирах с разными параметрами: количество комнат, цена, метраж. Часто некоторые параметры не заполнены например, квадратные метры есть, а количества комнат нет. В этом случае мы можем использовать ClickHouse с моделью CatBoost, чтобы заполнить пропуски в данных.

Более простые модели можно обучать прямо в ClickHouse. Модель машинного обучения у нас будет представлена как агрегатная функция например, стохастическая логистическая регрессия. Задаются гиперпараметры, значение предсказываемой функции и значения фич, причем обучение будет независимым для каждого ключа агрегации, если в запросе указан GROUP BY:

А еще мы можем добавить к агрегатной функции суффикс State:

SELECT stochasticLogisticRegressionState(...

Так можно обучить логистическую регрессию для каждого k и получить состояние агрегатной функции. Состояние имеет полноценный тип данных AggregateFunction(stochasticLogisticRegression(01, 00, 10, 'Adam'), ...), который можно сохранить в таблицу. Достать его из таблицы и применить обученную модель можно функцией applyMLModel:

Но и это еще не все. Мы можем обучить тысячи маленьких простых моделей, записать их в таблицу и сделать джойн из этой таблицы, чтобы применять свою модель для каждого ключа:

Более развернуто описано в этой презентации.

ClickHouse как графовая база данных

Конечно, ClickHouse это не графовая БД и никогда даже не планировался для этого, но тем не менее. Представьте, что таблицы представляют собой ребра графа. С помощью табличной функции можно записывать алгоритмы на графах, например, реализовать алгоритм pagerank:

Это работает, и говорят, даже быстрее, чем некоторые другие графовые базы данных. Разработал его наш друг, один из ведущих контрибьюторов Amos Bird. Правда, эта разработка не доступна в open-source. Но мы не обижаемся.

UDF в ClickHouse

Казалось бы, в ClickHouse нет возможности написать пользовательские функции (user defined functions). Но на самом деле есть. Например, у вас есть cache-словарь с источником executable, который для загрузки выполняет произвольную программу или скрипт на сервере. И в эту программу в stdin передаются ключи, а из stdout в том же порядке мы будем считывать значения для словаря. Словарь может иметь кэширующий способ размещения в памяти, когда уже вычисленные значения будут кэшированы.

И если вы пишете произвольный скрипт на Python, который вычисляет, что угодно пусть те же модели машинного обучения, и подключаете его в ClickHouse, то получаете вы как раз аналог user defined function.

Примечание: полноценная реализация UDF находится в roadmap на 2021 год.

ClickHouse на GPU и как Application Server

Это ещё два необычных примера. В компании nVidia ClickHouse заставили работать на графических ускорителях, но рассказывать я про это не буду.

А наш друг Zhang2014 превратил ClickHouse почти в Application Server. У Zhang2014 есть pull request, где можно определить свои HTTP-хэндлеры и этим хэндлерам приписать подготовленный запрос (SELECT с подстановками или INSERT). Вы делаете POST на какой-то хэндлер для вставки данных, или делаете вызов какой-то GET ручки, передаете параметры, и готовый SELECT выполнится.

Вывод

ClickHouse очень интересная система, в которой всегда можно найти что-то новое, причем, что интересно, что-то новое там всегда могу найти даже я. Многие разработчики удивляют меня тем, что они могут реализовывать внутри ClickHouse всего лишь чуть-чуть поменяв его код. И эти штуки будут работать и в production!

Представьте, что вы, например, bitly то есть очень большой сервис сокращения ссылок. И вот, вы хотите скопировать свои 150 ТБ сжатых данных с одного физического кластера на другой, новый. Чтобы сделать это, вы запускаете distcp из набора инструментов hadoop и рады тому, насколько быстро он работает. Но, несколько позже, вы уже совсем не радуетесь жалобам обычных пользователей веб-сайта и API-клиентов случаются ошибки, задерживаются ответы, а данные их дата-центра только запутывают. К старту курса о DevOps мы перевели материал о том, что делать, если вы, как и bitly, оказались в подобной ситуации.

Мы в bitly очень любим работать с данными и устройствами, а если говорить точнее, то с устройствами для передачи данных. Сегодня расскажем историю о том, как мы пытались перекачать через устройства очень и очень много данных.

Важной частью инфраструктуры bitly и основным инструментом команды Data Science и рабочей группы обслуживания операций и инфраструктуры (Ops/Infra) в течение довольно долгого времени был физический кластер hadoop набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч узлов. Мы уже давно вынашивали идею подключения нового кластера, копирования и объединения данных старого кластера с данными нового.

И вот, были созданы ветки, проведена вся подготовительная работа, сгенерированы серверы и запущен новый кластер. Но, прежде чем приступить к изложению истории, приведём некоторые технические детали:

• bitly работает с огромными объёмами данных: на момент миграции кластер hadoop занимал более 150 ТБ дискового пространства сжатых потоковых данных, то есть данных, полученных в результате работы наших различных приложений. Объёмы таких данных продолжали увеличиваться в результате дополнительной обработки другими приложениями;

• физически инфраструктура bitly располагается в центре обработки данных нашего партнёра. Она состоит из трёх физических видов шасси (приложения, хранилище и база данных), расположенных в ряд в смежных стойках. На момент написания этой статьи каждое шасси имело три физических гигабитных Ethernet-канала (каждый логически изолирован посредством организации сети VLAN) прямой канал, обратный канал и схему удалённого управления (для внеполосного управления серверными шасси). Каждое соединение после прохождения через ряд патч-панелей и коммутаторов подключается к нашим главным коммутаторам через стеклянное оптоволокно 10 Gb по звездообразной схеме сети;

• инфраструктура bitly занимает значительные физические ресурсы (сотни физических серверных шасси), однако управлением такой сетевой инфраструктурой и топологией занимается наш партнёр в центре обработки данных. Другими словами, на большинстве уровней физического сетевого стека мы имеем крайне ограниченную видимость сетевых операций, не говоря уже об их контроле.

Вернёмся к нашей истории.

Для быстрого копирования данных с одного кластера на другой мы воспользовались инструментом distcp, поставляемом в комплекте с кластером hadoop. Говоря просто, инструмент distcp выдаёт задание программному фреймворку mapreduce (используемому для параллельных вычислений над очень большими наборами данных в компьютерных кластерах) на перемещение данных из одного кластера hdfs в другой при копировании узлов в режиме "многие ко многим". Инструмент distcp сработал быстро, и это нас порадовало.

Но тут сломался сервис bitly, и это не привело в восторг команду Ops/Infra.

Пользователи веб-сайта и API-клиенты стали жаловаться на ошибки и задержки в получении ответов. Нам удалось выяснить, что причиной ошибок было получение нашим сервисом ошибок от других сервисов, что приводило к превышению времени ожидания при вызове баз данных и даже сбоям при обработке DNS-запросов внутри нашей собственной сети. Мы выяснили, что копирование данных привело к необъяснимому увеличению нагрузки на сетевые устройства, особенно на устройства, передающие трафик через физические стойки. Мы надеялись решить проблему, получив информацию от нашего партнёра из центра обработки данных, но эта информация не только не помогла, но и ещё больше нас запутала: ни одно соединение и ни одна стойка не проявляли никаких признаков насыщения, перегруженности или ошибок.

Теперь нам нужно было решать сразу две противоречивые задачи: с одной стороны, надо было продолжать миграцию hadoop, а с другой устранить неполадки и понять, в чём же кроется наша сетевая проблема.

Мы ограничили количество диспетчеров mapreduce, которые инструмент distcp использовал для копирования данных между кластерами, что позволило искусственно снизить пропускную способность при копировании и кое-как возобновить миграцию. После завершения копирования нам, наконец, удалось установить новый кластер взамен старого.

В новом кластере было больше узлов, значит, по идее, hadoop должен был работать быстрее.

Мы, кажется, осчастливили команду Data Science.

Но, к сожалению, поскольку кластер hadoop стал крупнее и быстрее, во время работы mapreduce на большее количество узлов стало передаваться большее количество данных, и это привело к непредвиденному эффекту:

Сервис bitly опять сломался, на этот раз очень серьёзно. Команда Ops/Infra была от этого не в восторге.

Первым импульсивным действием было вообще отрубить hadoop.

Но такое решение очень не понравилось команде Data Science.

Отключение кластера hadoop самое плохое из возможных решений (по последствиям может сравниться разве что с поломкой bitly), поэтому мы вернули кластер в состояние 1995 года, заставив все сетевые карты перейти на 100 Мбит/с (с 1 Гбит/с) с помощью команды ethtool -s eth1 speed 100 duplex full autoneg on. Теперь можно было спокойно подключить hadoop, но какой же медленной стала его работа!

Команда Data Science по-прежнему не выказывала признаков восторга.

И действительно, работа кластера была настолько "тормозной", что при вводе данных, выполнении запланированных заданий ETL (извлечения, преобразования и загрузки) и выдаче отчётов стали часто возникать сбои, постоянно срабатывали аварийные сигналы, будившие среди ночи членов команды Ops/Infra.

Надо ли говорить, как это не нравилось команде Ops/Infra!

Поскольку мы были лишены возможности удовлетворительно контролировать состояние сети, работа по поиску и устранению неисправностей вместе с партнёром из центра обработки данных предстояла сложная и длительная. Нужно было что-то сделать, чтобы привести hadoop в пригодное для использования состояние, и одновременно сделать так, чтобы сервис bitly перестал выходить из строя.

Сделаем ещё одно небольшое отступление:

Что нам было доступно в bitly?

• roles.json : список серверов (app01, app02, userdb01, hadoop01 и т. д.), ролей (userdb, app, web, monitoring, hadoop_node и т.д.), а также сведения об отображении серверов на роли (app01,02 -> app, hadoop01,02 -> hadoop_node и т. д.);

• $datacenter/jsons/* : каталог, содержащий json-файл для каждого логического сервера с атрибутами, описывающими сервер, IP-адресами, именами, информацией конфигурирования и, что наиболее важно в нашей истории, расположением стоек.;

• Linux : Linux.

Поскольку мы могли легко определить, какие серверы за что отвечают и где они расположены, мы могли воспользоваться мощными функциями Linux. Проблему, в принципе, можно было решить, и мы приступили к работе.

Но команда Ops/Infra не проявляла признаков радости.

Её не устраивал синтаксис системы контроля сетевого трафика (Traffic Control, tc) в Linux, не говоря уже о совершенно неудобочитаемой документации. После напряжённого периода работы (с многочисленными проклятиями и разбиванием о стену клавиатур) мы смогли, наконец, создать не вызывающие отторжения работающие сценарии в tc. Были открыты ветви, написаны скрипты, выполнены развёртывания, проведены эталонные тестирования, и в результате было создано несколько тестовых узлов с таким кодом:

$ tc class show dev eth1class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b    cburst 1561bclass htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b     cburst 1433bclass htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b     cburst 1561b$ tc filter show dev eth1filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16filter parent 1: protocol ip pref 49129 u32 filter parent 1: protocol ip pref 49129 u32 fh 817: ht divisor 1 filter parent 1: protocol ip pref 49129 u32 fh 817::800 order 2048 key     ht 817 bkt 0 flowid 1:10     match 7f000002/ffffffff at 16filter parent 1: protocol ip pref 49130 u32 filter parent 1: protocol ip pref 49130 u32 fh 816: ht divisor 1 filter parent 1: protocol ip pref 49130 u32 fh 816::800 order 2048 key     ht 816 bkt 0 flowid 1:20     match 7f000003/ffffffff at 16<snipped>$ tc qdisc showqdisc mq 0: dev eth2 root qdisc mq 0: dev eth0 root qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100     direct_packets_stat 24

Говоря простым языком, есть три класса управления траффиком. Каждый класс это логическая группа, на которую может быть подписан фильтр, например:

class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b cburst 1561b

Каждый класс это потолок пропускной способности исходящего трафика, агрегированного по всем подписанным на этот класс фильтрам.

Каждый фильтр это конкретное правило для конкретного IP (к сожалению, каждый IP выводится в шестнадцатеричном формате), поэтому фильтр:

filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16

можно интерпретировать как "subscribe hadoop14 to the class 1:20", где "7f000001" можно интерпретировать как IP для hadoop14, а "flowid 1:20" класс для подписки. Затем запускаем команду qdisc, формирующую более или менее активную очередь для устройства eth1. Данная очередь по умолчанию помещает любой хост, не определённый в фильтре класса, в класс 1:100:

qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100 direct_packets_stat 24

В такой конфигурации любой хост (hadoop или другой), находящийся в одной стойке с конфигурируемым хостом, получает фильтр, назначенный классу "1:10", разрешающий скорость передачи до ~800 Мбит/с для класса в целом. Аналогичным образом для предопределённого списка ролей, считающихся "ролями приоритетных узлов", создаётся фильтр по тому же правилу "1:100". Такие узлы выполняют довольно важные задачи, например запускают сервисы hadoop namenode или jobtracker, а также наши узлы мониторинга. Любой другой хост hadoop, не находящийся в той же стойке, подключается к классу "1:20", ограниченному более консервативным классом ~200 Мбит/с.

Как было сказано выше, любой хост, не определённый в фильтре, попадает в класс по умолчанию для eth1 qdisc, то есть в класс "1:100". Как это выглядит на практике? Вот хост, подпадающий под действие правила "1:100":

[root@hadoop27 ~]# iperf -t 30 -c NONHADOOPHOST------------------------------------------------------------Client connecting to NONHADOOPHOST, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 35897 connected with NONHADOOPHOST port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.1 sec   735 MBytes   205 Mbits/sec

Теперь при подключении к другому хосту, расположенному в той же стойке или подпадающему под правило "1:10":

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER------------------------------------------------------------Client connecting to CABINETPEER, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39016 connected with CABINETPEER port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  2.86 GBytes   820 Mbits/sec

Что произойдёт при подключении к двум серверам, подпадающим под правило "1:10"?

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER1------------------------------------------------------------Client connecting to CABINETPEER1, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39648 connected with CABINETPEER1 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.47 GBytes   421 Mbits/sec[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER2------------------------------------------------------------Client connecting to 10.241.28.160, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 38218 connected with CABINETPEER2 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.43 GBytes   408 Mbits/sec

Трафик уменьшится вдвое? Похоже на правду. Даже лучше стало относительно проще отслеживать тренды данных, анализируя статистические данные, выводимые на наши сервисы трендов:

$ /sbin/tc -s class show dev eth1 classid 1:100class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit     burst 1561b cburst 1561b Sent 5876292240 bytes 41184081 pkt (dropped 0, overlimits 0 requeues 0) rate 3456bit 2pps backlog 0b 0p requeues 0 lended: 40130273 borrowed: 0 giants: 0tokens: 906 ctokens: 906

После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.

Мы осчастливили команду Data Science.

Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.

Мы осчастливили и команду Ops/Infra.

Выводы:

• Попав в трудное положение, помните: ваш набор инструментов для управления средой так же важен, как и сама среда. Поскольку у нас уже имелся набор инструментов для комплексного контроля среды, мы сумели выбраться из ямы почти так же быстро, как попали в неё.

• Не загоняйте себя в трудные ситуации: изучите все нюансы среды, в которой будете работать. В данном случае нам следовало лучше понять и оценить масштабы миграции hadoop и её возможные последствия.

• Linux TC это дорогой инструмент, но и отдача от него очень большая. Этот инструмент почти наверняка создавали бородатые люди с самыми мохнатыми свитерами на свете, и для его применения требуются время и терпение. В любом случае это невероятно мощный инструмент он помог нам исправить наши собственные ошибки.

• Linux: Linux

И последнее

Эта история хорошая иллюстрация "закона Мерфи для девопсов":

Закон Мёрфи для девопсов: "Если что-то может пойти не так, значит, что-то уже идёт не так, просто Nagios ещё не предупредил".

Временные решения, подобные тем, о которых идёт речь в этой статье, позволили нам выиграть время для поиска и устранения неисправностей в сети. Мы разогнали кластер hadoop, перенесли его в собственную выделенную сеть, обошли проблему некачественного сетевого оборудования, укрепив тем самым основную сеть, и сделали много чего ещё. Оставайтесь с нами.

Эта статья подчёркивает, что правильная, эффективная организация инфраструктуры не менее важна, чем данные и программное обеспечение. По мере развития информационных технологий, увеличения нагрузок, специалисты DevOps, возможно, станут называться иначе, а область станет ещё более самостоятельной. Если она вам интересна, вы можете обратить внимание на наш курс о DevOps, после которого будете иметь полное представление об этой профессии и сможете работать в DevOps.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

Выпуск малыми партиями как нельзя лучше подходит для разработки программных продуктов. Однако идея Lean еще не сильно распространена среди разработчиков ПО, можно предположить, что обычно команды разработчиков довольно крупные, а нагрузка не велика.

В нашем случае было все наоборот: небольшая команда из 5 разработчиков разного уровня, сокращенные сроки и многоэтапная задача внедрения нового программного продукта в крупной организации.

После завершения основного блока разработки, в процессе тестовой эксплуатации, а затем опытной, мы столкнулись с рядом проблем. Перегруз разработчиков, большое количество повторных доработок уже реализованных задач, превышение длительности проекта, сложность прогнозирования сроков этапов разработки.

Также сказался разный уровень опыта разработчиков, кто-то выполнял поставленные задачи быстро, кто-то медленно, периодически возникали простои в разработке у более опытных сотрудников.

Влияние оказал размер и инфраструктура заказчика корпорация, содержащая большое число крупных удаленных подразделений с собственными особенностями бизнес-процессов. Заказчик использует в работе множество учетных систем и сервисов, с которыми необходимо было обеспечить бесшовную интеграцию. Все процессы согласования и принятия управленческих решений выполнялись в рамках внедряемой системы.

Решили стабилизировать существующую ситуацию. Полноценный Lean внедрять уже было поздно, да и не было такого опыта. Решили адаптировать элементы Agile-Lean в текущий процесс управления проектом, и вот что из этого получилось.

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

1. Руководитель проекта сотрудник, который планирует процесс реализации требований, координирует действия всех участников, вплоть до завершения проекта.

2. Scrum-мастер обычно тимлид группы разработки, занимается управлением процесса разработки, несет ответственность за конечный результат работы разработчиков.

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

4. Команда консультантов сотрудники погруженные в бизнес-процессы заказчика. Занимаются подготовкой требований, взаимодействием по требованиям и бизнес-процессам с конечными пользователями, консультируют конечных пользователей, тестируют разработанную функциональность.

Совещания:

1. Ежедневный митинг команды.

2. Ретроспектива в конце спринта.

3. Ежеквартальные ретроспективы.

Параметры спринта:

1. Продолжительность: 1 месяц.

2. Ежедневные обновления продуктивной системы по итогам завершения работ по блокам задач.

Данный подход использовался на большинстве проектов, динамика при использовании была положительная.

Во время локдауна подход дал сбой. Удаленная работа наложила свой отпечаток на эффективность работы команды, столкнулись со сложностями, которые необходимо было решить.

Хьюстон, у нас проблемы

Явные проблемы заметили на втором месяце этапа ОПЭ (опытно-промышленной эксплуатации), когда новые требования по дефектам начали закрывать время затраченное на запланированные дефекты и пожелания. Фактически мы стояли на месте. Вероятность успеха сделать все вовремя стремилась к 0.

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

1. Сильный перегруз разработчиков. Стабильное превышение 8-часового рабочего дня, выход на работу в выходные. Снижена мотивация, нарастает напряжение в команде.

2. Недостаточное качество итогового кода, требуется повысить контроль качества.

3. Много задач возвращается на доработку, в процессе тестирования выявляются не зафиксированные требования в описании задачи. Необходимо улучшить описание требований.

4. Разные направления работ выполняют разные группы разработчиков, недостаточно взаимодействия по реализованной функциональности. Необходимо отказаться от разделения.

5. Много времени уходит на разработку и доработку, консультанты простаивают.

6. Недостаточная компетентность разработчиков в администрировании и настройке ОС, тестовых стендов, стендов разработки. Системные инженеры не всегда могут быстро переключиться с других проектов. Необходимо повышать компетенции разработчиков.

А что думает заказчик? Заказчик недоволен динамикой реализации требований. Но готов рассмотреть вариант с четким и прогнозируемым планом.

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

Основываясь на описании бережливого производства, можно выделить не только сильные, но и слабые стороны для бережливой разработки.

Сильные стороны:

1. Получение результата в ограниченное время.

2. Устранение ненужных действий, которые могут снизить стоимость.

3. Расширение прав и возможностей команды разработчиков, помогающих им принимать решения.

4. Гибкость проекта, возможность его корректировки под требования заказчика.

Слабые стороны:

1. Большие требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

3. Необходимость детального планирования перед каждым спринтом.

4. Необходимо выделять сотрудников, которые будут следить за процессом, при этом не будут участвовать в производстве, что ослабит команду.

5. Продолжительность процесса разработки может вырасти, необходимо быть к этому готовым.

В процессе адаптации к текущему проекту мы постарались минимизировать слабые стороны за счет более простого документирования (мини-техпроекты, создаваемые разработчиками), упрощенного планирования с небольшим числом участников, договорились с заказчиком работать на результат.

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

• Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя: излишняя функциональность; ожидание (паузы) в процессе разработки; нечеткие требования; бюрократизация; медленное внутреннее сообщение.

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

• Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.

• Предельно быстрая доставка заказчику. Короткие итерации.

• Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

Проанализировав принципы, сформировали 7 своих, которые подошли к нашей текущей ситуации и должны были помочь закрыть существующие проблемы:

1. Убрать ненужное

Под ненужным будем понимать следующее:

1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

2. Ненужный код, дублирование кода.

3. Нечеткие цели и требования. Если есть такие задачи, то их отправляем на проработку и исключаем из Backlog. После детальной проработки задача может быть снова помещена в Backlog.

4. Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.

5. Переключение разработчика между задачами. Задача не должна быть слишком маленькой или слишком большой. Большие задачи приводят к низкому качеству проверки, маленькие увеличивают количество переключений, что в итоге сказывается на производительности.

Что мы сделали, чтобы решить задачу:

1. Детальная проработка требований и согласование описания требований с тимлидом разработки, дополнительная расшифровка требований тимлидом на понятный для разработчиков язык.

2. Ввели отдельную колонку в Trello Техдолг, в которую помещаются задачи с приоритетом, для устранения дублированного кода, для доработки найденных в процессе разработки потенциально сбойных участков и задачи с не оптимальным кодом.

3. Повышение взаимодействия разработчиков, консультантов и тимлида. Регулярные встречи 1:1, еженедельные встречи для мини-обучения и небольших вебинаров, еженедельная упрощенная ретроспектива для обсуждения и решения на месте текущих сложностей.

4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

Процесс разработки сам по себе порождает новые знания, которые необходимо зафиксировать и распространить. Было решено для каждой задачи выделять дополнительное время на проектирование, чтобы разработчик успел детально зафиксировать вносимые изменения.

Эта информация распространяется по команде разработки, консультанты используют ее, чтобы кроме основного требования протестировать функциональность, которая была затронута при выполнении разработки.

3. Повышение качества кода

Любые дефекты, несоответствия полученной функциональности требованиям появляются, когда код не проходит достаточную проверку качества.

Для повышения качества были приняты следующие предложения:

1. Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.

2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

3. Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

Принципы гибкой разработки прежде всего ориентированы на быструю реализацию требований. Ускорение разработки становится проще, когда организован стабильный рабочий процесс, конкретные сроки разработки и публикации.

Поэтому решили сделать ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

2. На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.

3. Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).

4. Публикация на продуктивный стенд выполняется только один раз в последний день спринта.

5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

Данный принцип основывается на том, что все участники команды проекта должны уважать друг друга. Когда дела идут плохо или не по плану, необходимо сосредоточить внимание на выявлении пробелов в рабочем процессе, которые могут приводить к конфликтам и проблемам. Мнение каждого участника процесса важно и должно быть принято во внимание другими участниками процесса.

При выявлении проблемной ситуации у одного участника, эта ситуация не должна быть только его проблемой. Такая ситуация должна считаться общей проблемой и решаться совместно.

Для реализации данного принципа проводятся встречи ответственных лиц проекта 1 на 1 с каждым участником команды, выявляются конфликтные ситуации, и затем выносятся на очередную ретроспективу, как общая точка улучшения.

6. Не торопиться с принятием решений

Если следовать принципам бережливого производства, необходимо понимать, что принятие решения с опозданием это нормальная ситуация. Фактически у команды появляется больше времени на сбор и анализ данных по текущей проблеме.

Решение принятое под воздействием эмоций может породить к большому числу проблем.

7. Регулярная оптимизация процесса

Регулярные ретроспективы по итогам каждого спринта и сбор фидбека со всех участников команды проекта позволяют наметить шаги улучшения.

Для улучшения процесса разработки необходимо выделить роль, которая будет этим заниматься.

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

1. Организует периодическое обучение, разбор сложных ситуаций.

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимается развитием разработчиков и расширением их компетенций.

5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

Для исключения бутылочного горлышка из наиболее опытных разработчиков был выделен помощник тимлида (саблид, sublead), который также подключается к этим задачам, если тимлид уже занят.

Основная проблема бережливого производства отодвигание сроков

Принципы бережливого производства позволяют минимизировать многие отрицательные факторы влияющие на процесс разработки, повышают мотивированность команды и качество реализуемых требований. Но необходимо учитывать, что Lean ориентирован на непрерывное улучшение в течение продолжительного времени, эффекты появятся не сразу.

Нельзя забывать, что проект имеет определенные сроки, превышение которых может привести как к штрафным санкциям, так и к разрыву контракта. Это необходимо учитывать, если вы планируете внедрять Lean в текущий проект.

Самый правильный вариант помнить о перспективе внедрения бережливой разработки на этапе планирования проекта и закладывать дополнительное время на выстраивание процесса. В нашем случае помогло то, что заказчик был готов пойти на встречу, ему был важен конечный результат.

Итоги

Процесс выстраивания бережливой разработки занял примерно месяц, принятые улучшения позволили решить существующие проблемы. Со стороны заказчика получили положительный фидбек. Сроки разработки удалось вернуть к заявленному плану, за счет исключения ряда несущественных требований. Нагрузка разработчиков была снижена до норматива, появилось время на реализацию задач техдолга.

Методология Lean Agile представляет собой ориентированную на клиента, адаптированную и гибкую систему, не предлагает жестких правил, которые потребуется выполнять. Всегда потребуется адаптировать эту методологию к своим существующим процессам, требованиям проекта, особенностям заказчика.

Но в любом случае необходимо взрастить эксперта среди ваших сотрудников. Он будет сосредоточен на улучшении процесса разработки и мотивирован в повышении своих навыков и навыков команды разработки.

Бережливая разработка построена на взаимодействии. Очень важно выстраивать доверительное общение внутри команды, чтобы все участники понимали, что всегда могут получить помощь, их требования будут услышаны и приняты к обсуждению. Для команды, работающей удаленно, необходимо выстраивать взаимодействие:

1. Обеспечить единую общую среду общения и обмена знаниями.

2. Организовывать совместные видеоконференции, желательно с камерой, чтобы видеть эмоции участников.

3. Не пренебрегать неформальным общением.

Немаловажно обеспечивать канал связи между командой разработки и командой внедрения со стороны заказчика. Заказчику необходимо понимать ваш процесс разработки и публикации, понимать сроки реализации требований. Для клиента важны и качество и скорость разработки, поэтому необходимо находить с ним точки соприкосновения, совместно планировать предстоящий спринт.

По итогам внедрения Lean получили следующие количественные изменения:

1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

2. Сократилось количество публикаций примерно вдвое. На самом деле это существенная экономия времени, поскольку процесс публикации многоэтапный и затрагивает большое множество сотрудников.

3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

5. Втрое уменьшилось количество дефектов, фиксируемых конечными пользователями.

Данный опыт планируется транслировать на другие проекты компании.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Привет, Хабр! Команда ВТБ запустила серию подкастов о передовых решениях финтеха Деньги любят техно. Журналист, технологический обозреватель Марина Эфендиева будет обсуждать с экспертами банка, рынка, учеными и бизнесменами перспективы и сложности финтеха: внедрения технологий на основе Big Data, машинного обучения, искусственного интеллекта, вопросы кибербезопасности и защиты данных, перспективные технологические специальности, голосовых помощников и многое другое.

В первом выпускезаместитель президента-председателя правления ВТБ Вадим Кулик и директор Физтех-школы прикладной математики и информатики д.ф.-м.н. Андрей Райгородский обсуждают, почему банки вРоссии так любятData science, можно ли стать дата-сайнтистом за три месяцаигде учиться, чтобысоздатьуспешную карьеру. Под катом основные темы этой беседы и ссылка на сам подкаст.

Откуда взялся банковскийData Science

Тривиальный, но важный вопрос: почему именно банковский Data Science сегодня занимает передовые позиции?

По словам Вадима Кулика, сегодняшние тренды это новый этап в решении вопросов, которые стояли перед банковским сектором еще в 90-х. Тогда жесткая нехватка какой-либо информации о клиентах усложняла процесс выдачи потребительских кредитов и выход на B2C-рынок в целом.

Решая важный для финансовой устойчивости вопрос кому дать кредит, банки параллельно соревновались друг с другом в том, кто быстрее одобрит кредит и выдаст повторный.

Поэтому ВТБ уделяет такое внимание подходу Data Fusion, который предполагает объединение, обезличивание данных из разных источников и их обработку. По этому поводу недавно прошлабольшая конференция.

Хорошей иллюстрацией применения данного подхода может служить СП ВТБ и РостелекомаПлатформа больших данных, которое уже предоставляет рынку продукты на основе Big Data для увеличения эффективности и развития бизнеса.

Data Science за 3 месяца без SMS и регистрации

Андрей Райгородский ответил на ещё один очень важный вопрос: можно ли стать дата сайентистом за 3 месяца, как сейчас предлагают многие онлайн-платформы. Он также рассказал о том, какова сейчас потребность в этих специалистах.

Страна очень требует большого количества людей, которые разбираются в том, что такое данные, как их можно обрабатывать, какие существуют методы. Есть такие хайповые слова, как искусственный интеллект, машинное обучение, нейронные сетки и так далее. В принципе, неудивительно, что люди начинают этим торговать. Это очень востребованный рынок, очень много компаний сейчас предоставляют рабочие места для людей, которые занимаются такого рода анализом, аналитикой. Но тут надо разбираться, что-то можно сделать за три месяца, но топовым специалистом за этот период ты точно не станешь,сказал Райгородский.

По его словам, существуютхорошие онлайн-курсы по аналитике данных. Но стоит различать уровень квалификации, подходящий для решения некоторого ограниченного круга прикладных задач стандартными методами, и уровень, на котором строится повестка завтрашнего дня.

МФТИ (Московский физико-технический институт) лидер этого направления в России фокусируется на фундаментальном обучении и готовит кадры для будущего. При этом есть и специальные нишевые программы например,Школа глубокого обучения, которая заработала в онлайн-формате ещё до того, когда это стало ковидным мейнстримом.

Главной особенностью МФТИ можно считать взаимодействие прикладного и фундаментального. В наши дни это связка между коммерческой индустрией, которая формирует запрос, и академической наукой, которая даёт фундаментальные математические решения. Отличный пример такого симбиоза созданная в начале 2021 года лаборатория ВТБ при МФТИ.

Резюме

Современный мир устроен так, что во многих сферах а в финансовой в первую очередь умение собирать и анализировать данные становится главным фактором роста. Скорость этого роста такова, что не позволяет только сиюминутные задачи. Нужно уметь формировать повестку будущего. Как выразился Андрей Райгородский, нельзя упускать фундаментальное в гонке за количеством кадров: цель не в том, чтобы снесло крышу, а в том, чтобы потолка не стало. А что вы об этом думаете? Делитесь мнениями в комментариях.

А вот и сам подкаст:

Решения на базе R, как классические отчетные, так и в контуре операционной аналитики, очень хорошо себя зарекомендовали в enterprise окружении. Несомненно, значительную роль в этом играет компания RStudio и ее увлеченный коллектив. В коммерческих продуктах RStudio можно не думать об инфраструктурных вопросах, а просто обменять небольшую денежку на готовые решение из коробки и положиться на их разработчиков и поддержку. В open-source редакциях, а большинство инсталляций в российских компаниях именно такие, приходится думать про инфраструктурные вопросы самостоятельно.

Решения на R хорошо закрывают нишу средних данных, когда данных чуть больше чем влезает в excel или в ненастроенную реляционку и нужны сложные алгоритмы и процессинг, но когда разворачивать пусковой комплекс бигдаты еще более чем рано. Речь идет о десятках-сотнях террабайт в полном объеме, которые легко умещаются в бэкенд на Cliсkhouse. Важный момент: все находится во внутреннем контуре, в подавляющем большинстве случаев ПОЛНОСТЬЮ отрезанном от интернета.

Является продолжением серии предыдущих публикаций, уточняет публикацию Конструктивные элементы надежного enterprise R приложения.

Проблематика

Для продуктивного решения необходимо обеспечить воспроизводимость результатов и вычислений. Задача воспроизводимости делится на несколько различных направлений. Крупными блоками можно выделить:

• инфраструктурная воспроизводимость. Многие вопросы закрываются комбинацией технологий docker + renv + git.

• программная воспроизводимость. Многие вопросы закрываются технологией пакетов и автотестов.

• статистическая похожесть выдаваемых результатов. Тут уже возникает специфика каждой отдельной задачи. Ниже предложены отдельные моменты, позволяющие ее обеспечить.

В чем заключается сложность?

Алгоритмы, выкатываемые в продуктив

• могут быть многофазными с совокупным временем расчета несколько часов;

• могут использовать кроме данных из основного бэкенда множество дополнительных неструктурированных источников данных (внешние справочники, excel файлы, технические логи и т.д.);

• опираются на данные, которые поступают от постоянно изменяемых объектов наблюдения и эволюционируют во времени;

• могут активно использовать случайные выборки из данных бэкенда;

• могут в рамках своего жизненного цикла постоянно уточняться и модифицироваться.

• могут иметь на выходе не один показатель, а семейства таблиц в которых каждая метрика характеризуются своим распределением;

• оценка корректности работы алгоритма может быть проведена только в конце вычислений, по расчету стат. характеристик выданных таблиц.

В таких случаях крайне затруднительно сделать тестовый набор данных (рефересный снапшот), а для ИТ служб задача бэкапа всего инстанса БД зачастую становится либо крайне дорогой либо непосильной. Приходится дополнять аналитические решения дополнительным модулем статистической самодиагностики, исполняемым как в продуктивном процессе так и по требованию. А также приходится применять широкий спектр средств отладки для быстрой диагностики возникших отклонений, как в prod контуре (постфактум), так и в dev среде.

Контроль в продуктивном контуре

Исходные постулаты

• Валидация и логирование являются одним из основных способов. Чем раньше будет обнаружена ошибка, тем легче ее локализовать.

• Техническая и логическая валидация поступающих параметров как при вызове собственных функций, так и при загрузке данных из источников.

• Валидация стат. характеристик загружаемых источников позволяет обнаружить перекосы уже на этапе ввода.

• Необходимо выбирать компромисс между глубиной охвата и сложностью проверок и временем их проведения.

• Маркируйте используемые в расчетах данные и по мере возможности оставляйте на диске временные дампы data.frame в критических точках с тем, чтобы можно было повторно проиграть непонятную ситуацию при отладке.

Логирование

Существуют несколько популярных пакетов для логирования, каждый может выбрать на свой вкус:

• futile.logger

• lgr

• logger

Также есть подходы к логированию warning и message, все очень хорошо расписано в документации на указанные пакеты.
Стоит отметить, что в многопоточном исполнении логфайлы могут являться единственным окошком к сути происходящего в другом потоке.

С точки зрения формирования дампов, штатный подход с использованием .Rds файлов для данных среднего размера (1-1000 Гб Ram) никуда не годится.
Существует 3 хорошие многопоточные альтернативы:

• fst

• qs

• arrow

У каждого из формата есть свои сильные стороны -- оптимальный вариант можно выбрать исходя из задачи. Какой объект сохраняется, нужен ли межплатформенный доступ, нужен ли последующий выборочный доступ с диска и т.д. Детальные бенчмарки и сравнения можно найти по приведенным ссылкам.

Валидация

Комбинируйте в зависимости от задачи и вкуса:

• checkmate -- физическая + базовая логическая;

• skimr -- базовая логическая;

• validate -- логическая;

• testthat / tinytest -- логическая;

• dplyr / data.table -- логическая.

Есть и другие пакеты, если этого будет недостаточно. Любители альтернативных решений могут почитать репозиторий Win-Vector.

Трекинг пайплайнов

Очень часто вычисления проводятся через pipe (%>%). Все промежуточные результаты скрыты. Если что-то идет не так (а особенно часто рвет на слиянии со справочниками по уникальному ключу, который ни разу не уникальный), то по выходу очень тяжело понять проблемный шаг. В таких случаях помогают пакеты, фиксирующие характеристики объектов, передаваемых посредством . с шага шаг.

Вот примеры полезных пакетов для трекинга:

• tidylog. Тут важно, что tidylog перехватывает глаголы tidyverse, поэтому конструкции dpylr::mutate останутся без трекинга.

• lumberjack. Сохраняем изменения

Отладка

Есть масса хороших публикаций насчет отладки, например:

• Статья Debugging with RStudio by Jonathan McPherson

• Книга Advanced R, гл. Debugging

Какие сценарии на практике оказываются крайне востребованными (shiny здесь не затрагиваем)?

• browser(). Никаких точек останова в IDE. Хардкорное прерывание в любом месте и в любом сценарии исполнения. Бонусом -- доп. трюк ниже.

• debug()/undebug()/debugonce(). Для отладки функций, в т.ч., прилинкованных из пакетов.

• traceback(). Докапываемся до причины в цепочке ассертов.

• options(datatable.verbose = TRUE). Что творится у основной рабочей лошадки data.table под капотом (план запроса, перформанс, ошибки).

• utils::getFromNamespace и пр. Хирургический скальпель для модификации функций из пакетов.

• Пакеты waldo и diffobj. Прецизионное сравнение небольших объектов.

• pryr::object_size(). Честное взвешивание объектов.

• Пакет reprex. Запрашиваем помощь друга.

• Пакет gginnards. Отладка графиков ggplot.

Трюк по использованию browser(), отлаживаем внутренние циклы data.table.

library(data.table)library(magrittr)dt <- as.data.table(mtcars) %>%  .[, {m <- head(.SD, 2); print(ls()); browser(); m}, by = gear]#>  [1] "-.POSIXt"  "am"        "carb"      "Cfastmean" "cyl"       "disp"     #>  [7] "drat"      "gear"      "hp"        "m"         "mpg"       "print"    #> [13] "qsec"      "strptime"  "vs"        "wt"       #> Called from: `[.data.table`(., , {#>     m <- head(.SD, 2)#>     print(ls())#>     browser()#>     m#> }, by = gear)

Профилировка

Зачастую профилировка кода с целью повышения производительности помогает найти концептуальные проблемы по применению тех или иных функций. Длительное исполнение за счет неэффективных преобразований внутри функций (своих и чужих) порождает массу проблем и не дает реализовать алгоритм так, как хотелось бы изначально.

• bench

• microbenchmark

• system.time({})

• profvis

• proffer

Заключение

1. Инструменты и методы приведены.
   Но что помогает более всего? Постоянно улучшать методы разработки и написания кода. Компактный, лаконичный, понятный и эффективный код будет содержать куда меньше ошибок.

2. Для отдельного класса задач может оказаться целесообразно использовать makeинструменты. drake/targets

Предыдущая публикация -- Как в enterprise приручить при помощи R технологии process mining?.

Как отдельная профессия Big Data Engineering появилась довольно недавно. И даже крупные компании очень часто путают, чем занимается этот специалист, каковы его компетенции и зачем он вообще в организации.

Поэтому в сегодняшней статье мы разберёмся, кто такой Big Data Engineer, чем он занимается и чем отличается от Data Analyst и Data Scientist. Этот гайд подойдёт людям, которые хотят работать с большими данными и присматриваются к профессии в целом. А также тем, кто просто хочет понять, чем занимаются инженеры данных.

Кто такой Big data engineer

Задачи, которые выполняет инженер больших данных, входят в цикл разработки машинного обучения. Его работа тесно связана с аналитикой данных и data science.

Главная задача Data engineer построить систему хранения данных, очистить и отформатировать их, а также настроить процесс обновления и приёма данных для дальнейшей работы с ними. Помимо этого, инженер данных занимается непосредственным созданием моделей обработки информации и машинного обучения.

Инженер данных востребован в самых разных сферах: e-commerce, финансах, туризме, строительстве в любом бизнесе, где есть поток разнообразных данных и потребность их анализировать.

К примеру, при разработке умного дома. Создание подобной системы требует считывания и обработки данных с IoT-сенсоров в режиме реального времени. Необходимо, чтобы данные обрабатывались с максимальной быстротой и минимальной задержкой. И даже при падении системы данные должны продолжать накапливаться, а затем и обрабатываться. Разработка системы, которая удовлетворяет этим требованиям, и есть задача инженера данных.

С технической стороны, наиболее частыми задачами инженера данных можно считать:

Разработка процессов конвейерной обработки данных. Это одна из основных задач BDE в любом проекте. Именно создание структуры процессов обработки и их реализация в контексте конкретной задачи. Эти процессы позволяют с максимальной эффективностью осуществлять ETL (extract, transform, load) изъятие данных, их трансформирование и загрузку в другую систему для последующей обработки. В статичных и потоковых данных эти процессы значительно различаются. Для этого чаще всего используются фреймворки Kafka, Apache Spark, Storm, Flink, а также облачные сервисы Google Cloud и Azure.

Хранение данных. Разработка механизма хранения и доступа к данным еще одна частая задача дата-инженеров. Нужно подобрать наиболее соответствующий тип баз данных реляционные или нереляционные, а затем настроить сами процессы.

Обработка данных. Процессы структурирования, изменения типа, очищения данных и поиска аномалий во всех этих алгоритмах. Предварительная обработка может быть частью либо системы машинного обучения, либо системы конвейерной обработки данных.

Разработка инфраструктуры данных. Дата-инженер принимает участие в развёртывании и настройке существующих решений, определении необходимых ресурсных мощностей для программ и систем, построении систем сбора метрик и логов.

В иерархии работы над данными инженер отвечает за три нижние ступеньки: сбор, обработку и трансформацию данных.

Что должен знать Data Engineer

• Структуры и алгоритмы данных;

• Особенности хранения информации в SQL и NoSQL базах данных. Наиболее распространённые: MySQL, PostgreSQL, MongoDB, Oracle, HP Vertica, Amazon Redshift;

• ETL-системы (BM WebSphere DataStage; Informatica PowerCenter; Oracle Data Integrator; SAP Data Services; SAS Data Integration Server);

• Облачные сервисы для больших данных Amazon Web Services, Google Cloud Platform, Microsoft Azure;

• Кластеры больших данных на базе Apache и SQL-движки для анализа данных;

• Желательно знать языки программирования (Python, Scala, Java).

Стек умений и навыков инженера больших данных частично пересекается с дата-сайентистом, но в проектах они, скорее, дополняют друг друга.

Data Engineer сильнее в программировании, чем дата-сайентист. А тот, в свою очередь, сильнее в статистике. Сайентист способен разработать модель-прототип обработки данных, а инженер качественно воплотить её в реальность и превратить код в продукт, который затем будет решать конкретные задачи.

Инженеру не нужны знания в Business Intelligence, а вот опыт разработки программного обеспечения и администрирования кластеров придётся как раз кстати.

Но, несмотря на то что Data Engineer и Data Scientist должны работать в команде, у них бывают конфликты. Ведь сайентист это по сути потребитель данных, которые предоставляет инженер. И грамотно налаженная коммуникация между ними залог успешности проекта в целом.

Плюсы и минусы профессии инженера больших данных

Плюсы:

• Отрасль в целом и специальность в частности ещё очень молоды. Особенно в России и странах СНГ. Востребованность специалистов по BDE стабильно растёт, появляется всё больше проектов, для которых нужен именно инженер больших данных. На hh.ru, по состоянию на начало апреля, имеется 768 вакансий.

• Пока что конкуренция на позиции Big Data Engineer в разы ниже, чем у Data Scientist. Для специалистов с опытом в разработке сейчас наиболее благоприятное время, чтобы перейти в специальность. Для изучения профессии с нуля или почти с нуля тоже вполне хорошо (при должном старании). Тенденция роста рынка в целом будет продолжаться ближайшие несколько лет, и всё это время будет дефицит хороших спецов.

• Задачи довольно разнообразные рутина здесь есть, но её довольно немного. В большинстве случаев придётся проявлять изобретательность и применять творческий подход.Любителям экспериментировать тут настоящее раздолье.

Минусы

• Большое многообразие инструментов и фреймворков. Действительно очень большое и при подготовке к выполнению задачи приходится серьёзно анализировать преимущества и недостатки в каждом конкретном случае. А для этого нужно довольно глубоко знать возможности каждого из них. Да-да, именно каждого, а не одного или нескольких.

  Уже сейчас есть целых шесть платформ, которые распространены в большинстве проектов.

  Spark популярный инструмент с богатой экосистемой и либами, для распределенных вычислений, который может использоваться для пакетных и потоковых приложений.
  Flink альтернатива Spark с унифицированным подходом к потоковым/пакетным вычислениям, получила широкую известность в сообществе разработчиков данных.
  Kafka сейчас уже полноценная потоковая платформа, способная выполнять аналитику в реальном времени и обрабатывать данные с высокой пропускной способностью. ElasticSearch распределенный поисковый движок, построенный на основе Apache Lucene.
  PostgreSQL популярная бд с открытым исходным кодом.
  Redshift аналитическое решение для баз/хранилищ данных от AWS.
  

• Без бэкграунда в разработке ворваться в BD Engineering сложно. Подобные кейсы есть, но основу профессии составляют спецы с опытом разработки от 12 лет. Да и уверенное владение Python или Scala уже на старте это мастхэв.

• Работа такого инженера во многом невидима. Его решения лежат в основе работы других специалистов, но при этом не направлены прямо на потребителя. Их потребитель это Data Scientist и Data Analyst, из-за чего бывает, что инженера недооценивают. А уж изменить реальное и объективное влияние на конечный продукт и вовсе практически невозможно.Но это вполне компенсируется высокой зарплатой.

Как стать Data Engineer и куда расти

Профессия дата-инженера довольно требовательна к бэкграунду. Костяк профессии составляют разработчики на Python и Scala, которые решили уйти в Big Data. В русскоговорящих странах, к примеру, процент использования этих языков в работе с большими данными примерно 50/50. Если знаете Java тоже хорошо.

Хорошее знание SQL тоже важно. Поэтому в Data Engineer часто попадают специалисты, которые уже ранее работали с данными: Data Analyst, Business Analyst, Data Scientist. Дата-сайентисту с опытом от 12 лет будет проще всего войти в специальность.

Фреймворками можно овладевать в процессе работы, но хотя бы несколько важно знать на хорошем уровне уже в самом начале.

Дальнейшее развитие для специалистов Big Data Engineers тоже довольно разнообразное. Можно уйти в смежные Data Science или Data Analytics, в архитектуру данных, Devops-специальности. Можно также уйти в чистую разработку на Python или Scala, но так делает довольно малый процент спецов.

Перспективы у профессии просто колоссальные. Согласно данным Dice Tech Job Report 2020, Data Engineering показывает невероятные темпы роста в 2019 году рынок профессии увеличился на 50 %. Для сравнения: стандартным ростом считается 35 %.

В 2020 году темпы замедлились, но всё равно они многократно опережают другие отрасли. Спрос на специальность вырос ещё на 24,8 %. И подобные темпы сохранятся еще на протяжении минимум пяти лет.

Так что сейчас как раз просто шикарный момент, чтобы войти в профессию Data Engineering с нашим курсом Data Engineering и стать востребованным специалистом в любом серьёзном Data Science проекте. Пока рынок растёт настолько быстро, то возможность найти хорошую работу, есть даже у новичков.

Узнайте, как прокачаться и в других областях работы с данными или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс "Machine Learning и Deep Learning"

• Курс "Алгоритмы и структуры данных"

Что делать с данными в 2021 году, если вы финансовая компания с традиционной инфраструктурой и не смотрели дальше BI? Как и зачем договариваться разным бизнесам в B2B и что можно найти среди маленьких данных?

Мы расскажем про опыт НРД центрального депозитария РФ. НРД хранит активы на сумму более 60 трлн руб. и аккумулирует практически весь рынок ценных бумаг в России. Основной бизнес сфокусирован на надежности: хранение, проведение расчетов, отчетность.

Если вы тоже задаетесь похожими вопросами или вам знакомы слова финансовый бэк-офис, добро пожаловать под кат.

Согласно Big Data Executive Survey 2020, 98,8% опрошенных компаний, входящих в список Fortune-1000, инвестировали в создание дата-центричного бизнеса. Две трети опрошенных компаний инвестировали больше 50 млн долл., а каждая пятая больше 500 млн долл. Но то же исследование из года в год показывает: примерно две трети опрошенных руководителей признают, что их бизнес так и не стал дата-центричным. А трое из четверых замечают, что эта тема стала для них настоящим вызовом. Что делать с этой информацией, если последние 15 лет вы прицельно не занимались данными и наконец решили, что пора?

Данные, или что мы делали позапрошлым летом

Сначала задали себе ряд ключевых вопросов:

1. Сколько у нас данных? Как быстро они прирастают или обновляются? Какие они? Где хранятся?

2. Какие из наших данных уникальны?

3. Как устроены процессы работы с данными? Как данные появляются в системах, где дублируются и теряются?

4. С какой задержкой мы получаем информацию? Сколько занимает и стоит типичный запрос или сложная аналитика?

5. Что нам на самом деле нужно от данных?

Ответы на них не статичны и могут и будут меняться на разных стадиях зрелости компании. Например, мы ориентируемся на классификацию Google и Deloitte, а можно рассчитать data maturity index по аналогии с BCG. Сейчас мы считаем, что идеи ниже актуальны как минимум до уровня mature.

Чтобы понять картину в НРД, мы начали с аудита. Аудит данных и процессов работы с ними занял 3 месяца. Команда на этом этапе: продакт и техлид, занятые на 30-50%, по 1-2 представителя каждого бизнеса для интервью и по одному лиду ключевых систем для единичных запросов.

Результат получился неоднозначный: с одной стороны, в силу законодательных требований и глубокой интеграции с глобальной финансовой инфраструктурой системы и процессы управления данными в бизнесах сейчас работают отлично. В какой-то степени весь современный финансовый бизнес и есть бизнес вокруг данных. С другой стороны, как и другие финансовые компании, мы в основном работаем со структурированными данными: транзакции, профили контрагентов, счета, плановые денежные потоки, отчетность, статусы процессов и т.д. Неструктурированные данные: переписка, логи, переговоры, видео и фотоинформация хранятся в разных системах и используются в основном для аудита.

И болевая точка, которую выявил аудит: без радикальных изменений никакие новые направления, связанные с комбинацией имеющихся, а тем более с новыми данными, невозможны. Мы просто не сможем поддержать взрывной рост или выход в новый сегмент.

В целом если учитывать только объем и скорость прироста структурированной информации, то НРД при всём масштабе бизнеса раз в 10 не дотягивает до традиционной границы big data. Но если смотреть на ценность и уникальность наших данных, мы в топе.

1. Проблемы с данными, с которыми часто встречаются наши коллеги в индустрии:

2. Внутренних данных мало, доступные внешние данные не используются.

3. Не все доступные данные надлежащим образом собираются, обрабатываются и хранятся.

4. Те, что собираются, содержат ошибки и не всегда появляются вовремя.

5. Те, что собраны и почищены могут дублироваться незаметно для бизнес-процессов и критично для аналитики или наоборот.

6. Аналитика ассоциируется с ошибочным выбором метрик или возможностей монетизации.

Мы поймали все проблемы в разном объеме. Тут главное не отчаиваться. Если данных не хватает, проверьте открытые. Kaggle, тестовые датасеты вендоров, прямые запросы партнерам, открытые API интернет-сервисов. Проверьте на истории, насколько вам подходит сет. Как только вы поняли, что конкретные данные ценны для вас и работают, можно покупать. Если данные нужно разметить и они не конфиденциальные, привлекайте студентов, придумывайте исследование. Если данные дублируются, выбирайте мастер источник, которому будете доверять. Если в данных есть ошибки, оцените трезво, насколько они влияют на результат и вносят вклад в конечную точность анализа. Важно исправляйте, неважно смиритесь.

Кстати, бюрократический ответ на аудит и концепцию KYD (know your data; понимание профиля данных, которыми вы оперируете) каталог данных. Но, по-честному, тут все зависит от масштаба: если можете описать данные в простом виде и вам все понятно, пункт выполнен. Если нет, усложняйте постепенно. Начните с таблички и, если действительно потребуется, добавляйте документы и спецрешения. По поисковому запросу data catalogue есть варианты на любой кошелек :) Для себя мы остановились на Amundsen, но об этом в следующей серии.

Технологии: копать, не копать, делать вид, что копаешь?

Следующий шаг после понимания своих данных технологии. Заманчивый ответ для задачи внедрить биг дату from the top предложить правильную архитектуру и красивое технологическое решение для работы с абстрактными большими данными. Но во-первых, не факт, что ваши данные большие, а во-вторых, не факт, что вы с технологиями справитесь и создадите новую ценность.

Для ответа на вопрос про размер данных можно ориентироваться на концепцию 3V Gartner: volume, velocity, variety. И добавить любые слова на V, которые кажутся вам подходящими для классификации (например, Спутник V к данным не относится, но если очень хочется, тоже можно использовать для классификации).

Очень условно стадии развития инфраструктуры работы с данными можно описать так:

1. 1C/Excel все понятно. Данных мало, хоть мелом на заборе графики рисуй.

2. BI-решения. Могут быть витринами и собирать данные из нескольких БД, могут основываться на DWH. Сюда же Tableau, Cognus, Qlik и аналоги.

3. Специализированные решения для хранения и анализа больших или быстрых данных. Сюда попадает все дорогое и не всегда полезное и условно бесплатное, но требующее классной команды: in-memory БД, кластерные решения на основе Hadoop/Spark/Kafka/Hive/NiFi и другие.

4. Облачные решения: Amazon Athena/Redshift, Google BigQuery, Data Lake Analytics. Интересно, но страшно для финансовых компаний с точки зрения информационной безопасности. Как альтернатива возникают внутренние облака для группы компаний.

5. Платформы данных, комбинирующие пункты 2-4, виртуализация данных.

При этом любая инфраструктура устаревает примерно раз в 5 лет. Поэтому, говоря о технологиях работы с данными, мы обсуждали стратегию развития инфраструктуры компании в целом, а не только локальное решение по работе с данными. Не data lake, не универсальное хранилище, не аналитическая система.

Мы стартовали с технологического уровня 2 (работающий BI) и надеялись не переходить к следующим пунктам в ближайшие 2 года. Команда на этом этапе: 1 продакт, 1 дата-аналитик, 1/2 тимлида, 1 стажер. Плюс 1 человек от каждого бизнес-линии и от каждой системы для периодических консультаций.

Ключевые вопросы к технологиям на этом этапе входят в категории как сделать и действительно ли нам это нужно. Как быстро аналитик получит доступ к новым данным? Сколько человек действительно потребуется, чтобы выгрузить данные для аналитики? Можно ли сделать новый отчет или получить доступ к данным в новом разрезе без разработки? Что мешает? Какую задержку в задачи вносит data mining? Какие технологические ограничения есть у разных систем?

На первый взгляд, схема BI плюс прямые запросы к источникам под задачу работала. Но через полгода мы поняли, что с текущими технологиями получение данных, не включая очистку и разметку, занимает 75% времени аналитики. Основные ограничения: legacy мастер систем со сложными структурами баз данных, не унифицированные API и множественные интеграции систем, последовательное согласование между разными бизнес-линиями и ИТ-функциями и привязка ролей доступа к конкретным системам, а не данным.

Мы вернулись к вопросу централизованной инфраструктуры по работе с данными. Три важных для нас элемента: каталог данных для поиска нужной информации, ETL и, собственно, хранилище. А основной риск делать инфраструктурные проекты больно, а переделывать еще больнее.

Поэтому мы начали с proof of concept (POC). На POC стоит проверять максимальное количество технологий на реальной задаче. Задача должна включать в себя максимально разнообразные данные и проверять самые архитектурно сложные места. Как референс можно использовать riskiest assumption test из продуктовой разработки. То есть если вы больше всего сомневаетесь в работе с объемными данными, пробуйте на объеме. Если в сохранности данных прогоняйте все риск-сценарии для нагруженных систем. Если в объединении данных из разных источников и доступности для аналитики подключайте максимум источников и ограничивайте объем. Если в гибкости пробуйте радикальные изменения. Например, мы выбрали для тестирования работу с профилем клиента и предсказание вероятности покупки дополнительных продуктов из линейки с учетом того, что часть данных обезличена.

Команда на этом этапе: 1 продакт, 2 дата-аналитика/дата-сайнтиста, 1 ИТ тимлид, 1 дата-инженер, 1 ML-разработчик, 1/2 аналитика. С этого момента все завязано на людей.

Люди, или у нас другие cultural references

По большому счету вся работа с данными вопрос людей: их компетенций, открытости, культуры, участия. Поэтому люди, выстраивание процессов и культуры работы с данными ключевая часть дата-стратегии НРД.

До пандемии мы думали, что можно не инвестировать, пока не проверим гипотезы и не поймем, как монетизировать. Это полуправда. Чтобы проверить гипотезу, нужны как минимум:

1. Аналитик(и).

2. Сервер или облако для экспериментов (Сюрприз! Даже если данные пролезают в 1 скрипт или на ПК, совместной работы не получается и времени на коммуникации уходит больше, чем на анализ).

3. Дата-инженер настраивать доставку данных не больше, чем за 30% времени задачи.

4. Участие бизнеса владельцев данных и дата-стюардов.

Поэтому параллельно с тестированием технологий мы начали строить матричное взаимодействие между людьми в разных бизнесах и подразделениях. Ключевые роли в дата-матрице НРД: дата-аналитики/дата-саентисты, дата-стюарды, дата-инженеры и ML-инженеры. Дата-аналитик отвечает за построение моделей, проверку гипотез, прототипирование. Дата-стюард за данные внутри бизнес-линий. При этом роль дата-стюарда совмещена с продуктовой за данные отвечают те же люди, что и за развитие бизнеса и продуктовую разработку. Сейчас так получается избежать конфликта интересов между быстрым развитием и доступностью данных. Дата-стюарды есть в каждой бизнес-линии. Дата-инженер делает данные доступнее, а ML-инженер помогает докатить сервисы до продакшн.

Такая структура матрицы дает взгляд на развитие с трех сторон: сам бизнес, ИТ-архитектура, управление данными (на C-level это управляющие директора, CIO и CDO) и подходит для текущего уровня зрелости компании.

Что делать, если у дата-стюарда не будет хватать ресурса на 2 роли? Или снова появится конфликт интересов между развитием и архитектурно правильными решениями? Или работа замедлится еще по каким-то причинам? Договариваться.

Короче, сейчас мы понимаем data friendliness как открытость. Открытость для сотрудников компании: каждый может посмотреть задачи в работе, раз в 5-6 недель проводится демо и обсуждение с дата-стюардами и всеми, кому интересны данные. Открытость к идеям: идеи приходят из несвязанных областей, от студентов на конференциях, из самих данных. Открытость к людям: в финансы сложно нанимать звезд data science за разумные деньги, проще растить внутри.

Быть открытым значит понимать и принимать риски. И risk taking культура в разумных количествах должна быть на каждом уровне. Например, мы не можем снижать контроль за конфиденциальными данными, но можем работать со студентами на открытых датасетах с похожей структурой. Не можем рисковать основным бизнесом, но можем проверить 10 новых гипотез, чтобы найти классную. Risk taking в нашем случае значит, что лучше решать задачу и ошибиться, чем не решать вообще. Право на ошибку на этапе исследований есть у каждого: дата-стюарда, дата аналитика, дата-инженера.

И финальный совет: не отдавайте работу с данными на аутсорс. Да, растить или собирать команду внутри дорого на горизонте года, но стоит того, если смотреть на данные как на актив на ближайшие 5-10 лет.

Привет.

В конце прошлого года GlowByte и Газпромбанк сделали большой совместный доклад на конференции Big Data Days, посвященный созданию современного аналитического хранилища данных на базе экосистемы Cloudera Hadoop. В статье мы детальнее расскажем об опыте построения системы, о сложностях и вызовах с которыми пришлось столкнуться и преодолеть и о тех успехах и результатах, которых мы достигли..

Появление технологии Hadoop десятилетние назад вызвало на рынке интеграции данных небывалый ажиотаж и оптимизм. Индустрия задалась вопросом а готова ли технология вытеснить традиционные системы обработки данных?. За прошедшую декаду было сломано немало копий в этой битве. Кто-то успел разочароваться, кто-то добился локальных успехов, а тем временем сама экосистема прошла короткий, но стремительный эволюционный путь, который позволяет уверенно сказать, что в настоящий момент не существует задачи и вызова в области обработки и интеграции данных, которую не способен решить Hadoop.

В этой статье мы попытаемся дать ответ на главный вопрос как создать современное аналитическое хранилище данных на базе экосистемы Cloudera на примере проекта, реализованного нами в Газпромбанк АО. Попутно расскажем как мы справились с основными вызовами при решении задачи.

Газпромбанк АО один их ведущих системообразующих финансовых институтов РФ. Он входит в топ-3 банков по активам России и всей Восточной Европы и имеет разветвленную сеть дочерних филиалов.

Банк традиционно на рынке финансовых услуг был консервативным и ориентировался на корпоративный сектор, но в 2017 году принял стратегию Цифровой трансформации с целью развития направления розничного бизнеса.

Розничный банковский сектор является высококонкурентным в РФ и для реализации стратегии Газпромбанку потребовалось создание новой технологической платформы, которая должна удовлетворять современным требованиям, так как основой интенсивного роста на конкурентном рынке могут быть только data driven процессы.

На тот момент в Банке уже было несколько платформ интеграции данных. Основная платформа КХД занята классическими, но критичными с точки зрения бизнеса задачами: управленческой, финансовой и регуляторной отчетности. Внесение изменения в текущую архитектуру КХД несло серьезные риски и финансовые затраты. Поэтому было принято решение разделить задачи и создавать аналитическую платформу с нуля.

Верхнеуровнево задачи ставились следующие:

• Создание озера данных (как единой среды, в которой располагаются все необходимые для анализа данные);

• Консолидации данных из озера в единую модель;

• Создание аналитический инфраструктуры;

• Интеграция с бизнес-приложениями;

• Создание витрин данных;

• Внедрение Self-service инструментов;

• Создание Data Science окружения.

Этап проработки архитектуры важно начинать после консолидации и уточнения всех ключевых требований к системе. Требования были разделили на два больших блока:

Бизнес-требования

• Обеспечение данными бизнес-приложений: аналитический CRM, Real Time Offer, Next Best Offer, розничный кредитный конвейер;

• Возможность работы с сырыми данными из систем-источников as is (функция Data Lake);

• Среда статистического моделирования;

• Быстрое подключение новых систем источников к ландшафту;

• Возможность обработки данных за всю историю хранения;

• Единая модель консолидированных данных (аналитическое ядро);

• Графовая аналитика;

• Текстовая аналитика;

• Обеспечение качества данных.

Требования ИТ

• Высокая производительность при дешевом горизонтальном масштабировании;

• Отказоустойчивость и высокая доступность;

• Разделяемая нагрузка и гарантированный SLA;

• ELT обработка и трансформация данных;

• Совместимость с имеющимися Enterprise решениями (например, SAP Business Objects, SAS);

• Ролевая модель доступа и полное обеспечение требований информационной безопасности.

Кроме этого, система должна быть линейно масштабируемой, основываться на open source технологиях, и самое главное соотношение стоимость\производительность должно быть самым конкурентным из всех предложений на рынке.

Для создания единой аналитической платформы розничного бизнеса мы выбрали стек Hadoop на базе дистрибутива Cloudera Data Hub

Архитектура решения

Рассмотрим архитектуру решения.

Рис. Архитектура

Система разделена на два кластера Cloudera Data Hub. Кластер регламентных процессов и Лаборатория данных

1. Кластер регламентных процессов

Все регламентные источники данных подключаются к данному кластеру. Все регламентные ETL расчеты также работают на этом контуре. Все системы потребители данных запитываются из регламентного кластера. Таким образом выполняется жесткая изоляция непредсказуемой пользовательской нагрузки от критичных бизнес процессов.

В настоящий момент к Hadoop подключено свыше 40-ка систем-источников с регламентом от t-1 день до t-15 минут для batch загрузки, а также real-time интеграция с процессинговым центром. Регламентный контур поставляет данные во все системы розничного бизнеса:

• Аналитический CRM;

• Розничный кредитный конвейер;

• Антифрод система;

• Система принятия решений;

• Collection;

• MDM;

• Система графовой аналитики;

• Система текстовой аналитики;

• BI отчетность

2. Кластер пользовательских экспериментов Лаборатория данных

В то же время, все данные которые загружаются на регламентный контур в режиме онлайн реплицируются на контур пользовательских экспериментов. Задержка по времени минимальная и зависит только от пропускной способности сетевого канала тк контур лаборатории данных находится в другом ЦОДе. Те пользовательский контур одновременно выполняет роль Disaster Recovery плеча в случае выхода из строя основного ЦОДа.

Дата инженеры и дата science специалисты получают все необходимые данные для проведения своих исследований и проверки гипотез без задержки и без ожидания днями и неделями, когда нужные им данные для расчетов или тренировки моделей куда то выгрузят. Они доступны все в одном месте и всегда свежие. Дополнительно на кластере лаборатории данных создаются пользовательские песочницы, где можно создавать и свои объекты. Также ресурсы кластера распределены именно для высококонкурентной пользовательской нагрузки. На регламентный кластер у пользовательского доступа нет.

После проверки гипотез, подготовки требований для регламентных расчетов либо тренировки моделей, результаты передаются для постановки на регламентный контур и сопровождения.

Дополнительно на контуре лаборатории создано окружение управления жизненным циклом моделей, окружение пользовательских аналитических приложений с управлением ресурсами на K8S, подключены два специализированных узла с GPU ускорением для обучения моделей.

Система мониторинга и управления кластерами, загрузками, ETL, реализована на дополнительных виртуальных машинах, не включенных напрямую в кластера Cloudera.

Сейчас версия дистрибутива CDH 5.16.1. В архитектурный подход закладывалась ситуация выхода из строя двух любых узлов без последующей остановки системы.

Характеристики Data узлов следующие: CPU 2x22 Cores 768Gb RAM SAS HDD 12x4Tb. Все собрано в HPE DL380 в соответствии с рекомендациями Cloudera Enterprise Reference Architecture for Bare Metal Deployments. Такой необычный, как кому-то может показаться, сайзинг связан с выбором подхода по ETL и процессингового движка для работы с данными. Об этом немного ниже. Необычность его в том, что вместо 100500 маленьких узлов, мы выбираем меньше узлов, но сами узлы жирнее.

Основные технические вызовы

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

• Выбор основного процессингового движка в Hadoop;

• Подход по трансформации данных (ETL);

• Репликация данных Система-источник > Hadoop и Hadoop > Hadoop;

• Изоляция изменений и консистентность данных;

• Управление конкурентной нагрузкой;

• Обеспечение требований информационной безопасности

Далее рассмотрим каждый из этих пунктов детально.

Выбор основного процессингового движка

Горький опыт первых попыток некоторых игроков реализовать ХД в Hadoop 1.0 показал, что нельзя построить систему обработки данных руками java программистов, не имеющих опыта построения классических ХД за плечами, не понимающих базовых понятий жизненного цикла данных, не способных отличить дебит от кредита или рассчитать просрочку. Следовательно, для успеха нам надо сформировать команду специалистов по данным, понимающих нашу предметную область и использовать язык структурированных запросов SQL.

В целом, базовый принцип работы с данными которого стоит придерживаться если задачу можно решить на SQL то ее нужно решать только на SQL. А большинство задач с данными решаются именно с помощью языка структурированных запросов. Да и нанять и подготовить команду SQL-щиков для проектной работы быстрее и дешевле чем специалистов по данным, окончивших курсы на диване из рекламы в инстаграм.

Для нас это означало что необходимо выбрать правильный SQL движок для работы с данными в Hadoop. Остановили свой выбор на движке Impala так как он имеет ряд конкурентных преимуществ. Ну и собственно ориентация на Impala во многом и предопределила выбор в пользу Cloudera как дистрибутива Hadoop для построения аналитического хранилища.

Чем же Impala так хороша?

Impala движок распределенных вычислений, работающий напрямую с данными HDFS, а не транслирующий команды в другой фреймворк вроде MapReduce, TEZ или SPARK.

Impala движок который большинство всех операций выполняет в памяти.

Impala читает только те блоки Parquet, которые удовлетворяют условиям выборки и соединений (bloom фильтрация, динамическая фильтрация), а не поднимает для обработки весь массив данных. Поэтому в большинстве аналитических задач на практике Impala быстрее чем другие традиционные MPP движки вроде Teradata или GreenPlum.

Impala имеет хинты, позволяющие очень легко управлять планом запроса, что весьма важный критерий при разработке и оптимизации сложных ETL преобразований без переписывания запроса.

Движок не разделяет общие ресурсы Hadoop с другими сервисами так как не использует YARN и имеет свой ресурсный менеджмент. Это обеспечивает предсказуемую высоко конкурентную нагрузку.

Синтаксис SQL настолько близок к традиционным движкам, что на подготовку разработчика или аналитика, имеющего опыт другой SQL системы, уходит не больше 3-4х часов.

Вот как работа с Hadoop выглядит глазами аналитика:

Рис. Работа с Impala SQL в Hue

Это работа в веб-ноутбуке Hue, который идет вместе с Cloudera. Не обделены и те пользователи, кто предпочитает работать с классическими толстыми SQL клиентами или сводными таблицами Excel.

Рис. SQL доступ к Hadoop в локальном толстом клиенте.

Многие кто читал рекомендации Cloudera могут задаться вопросом а почему Impala не рекомендована как ETL движок, а только как движок пользовательского ad-hoc или BI доступа? Ответ на самом деле прост - Impala не имеет гарантии исполнения запроса чтобы не стало в отличие от Hive. Eсли падает запрос или узел, то запрос автоматически не перезапустится и поднимать его надо вручную.

Это проблема легко решаема ETL поток или запрос в приложении должны уметь перезапускаться в таких ситуациях.

ETL потоки в нашем решении перезапускаются без вмешательства администратора автоматически:

• При падении запроса происходит автоматический анализ причины;

• При необходимости автоматически подбираются параметры конкретного запроса или параметры сессии чтобы повторный перезапуск отработал без ошибок;

• Выполняется сбор статистической информации по ошибкам для дальнейшего анализа и настройки потока чтобы в будущем по данному запросу или jobу таких ситуаций не возникало.

У нас на проекте сложилась парадоксальная ситуация - команда аналитиков и инженеров по данным, работающих над проектом, знала про Hadoop только то, что на логотипе есть желтый слоник. Для них Hadoop - это привычный SQL. Уже после уборки урожая (завершения разработки аналитического слоя, о котором речь пойдет ниже), ребята попросили провести для них обучение по Hadoop чтобы быть в теме.

Подход по трансформации данных

В разработке трансформации данных важно не только выбрать правильный движок, но и принять правильные стандарты разработки. У нас давно сформировался подход к таким задачам как metadata driven E-L-T при котором трансформация данных отрисовывается в диаграмме ETL инструмента, который в свою очередь генерирует SQL и запускает его в среде исполнения. При этом SQL должен быть максимально оптимальным с точки зрения конкретной среды исполнения. На рынке не так много ETL инструментов, позволяющих управлять генерацией SQL. В данном внедрении использовался инструмент SAS Data Integration.

Весь регламентный ETL выполнен в подходе metadata driven ELT. Никаких ручных скриптов с планировкой на airflow!

Такой подход позволяет

• Автоматизировать процессы управления метаданными;

• Автоматизировать процесс построения lineage данных как средствами самого ETL инструмента, так и средствами доступа к API;

• Повысить качество процессов внесения изменений и управления данными т.к. вся информация о зависимостях всех объектов и всех jobв хранится в метаданных ETL инструмента.

• Использовать CI/CD процессы в разработке

Рис. Примеры диаграмм ETL процессов

SAS DI позволяет визуализировать граф зависимостей в штатном функционале или можно выгрузить метаданные через API и использовать их для анализа в других средах.

Рис. Граф зависимостей объектов.

Репликация данных

Загрузка данных в систему ключевая отправная точка реализации функциональных бизнес требований системы.

Для этой функции был разработан специализированный инструмент Data Replicator. Инструмент позволяет в очень короткие сроки подключать системы источники и настраивать загрузку данных в Hadoop.

Из возможностей

• Синхронизация метаданных с источника;

• Встроенные механизмы контроля качества загруженных данных;

• Загрузка в различных режимах работы в т.ч. полная копия, извлечение и загрузка инкремента (по любой скалярной детерминированной функции), архивация данных источника и т.д.

Решение имеет гибкие настройки позволяющие приоритизировать задания загрузки, балансировку, контроль многопоточности. Это позволяет бережно относится к источнику при извлечении данных, но в то же время гарантировать SLA доступности данных в Hadoop.

Другая очень важная функция Data Replicatorа - автоматическая репликация данных с регламентного кластера Hadoop на DR кластер. Данные, загружаемые из систем-источников реплицируются автоматически, для деривативных данных существует API. Все регламентные ETL процессы, при обновлении целевой таблицы вызывают API которое запускает процесс мгновенного копирования изменений на резервный контур. Таким образом, DR кластер, который так же выполняет роль пользовательской песочницы, всегда имеет свежие данные.

Нами реализовано множество конфигураций для различных СУБД используемых как источники в ГПБ, также для других процессинговых движков Hadoop (для случаев когда другой кластер Hadoop является источником данных для системы) и есть возможность обрабатывать данные, загруженные в систему другими инструментами, например kafka, flume, или промышленный ETL tool.

Изоляция изменений и консистентность

Любой кто работал в Hadoop сталкивался с проблемой конкурентного доступа к данным. Когда пользователь читает таблицу, а другая сессия пытается туда записать данные, то происходит блокировка таблицы (в случае Hive) либо пользовательский запрос падает (в случае Impala).

Самое распространенное решение на практике выделение регламентных окон на загрузку во время которых не допускается работа пользователей, либо каждая новая порция загрузки записывается в новую партицию. Для нас первый подход неприемлем тк мы должны гарантировать доступность данных 24х7 как по загрузке так и по доступу. Второй подход не применим т.к. он предполагает секционирование данных только по дате\порции загрузке, что неприемлемо если требуется отличное секционирование (по первичному ключу, по системе источнику и т.д.). Так же второй метод приводит к избыточному хранению данных.

Забегая вперед хочется отметить, что в настоящее время в HIVE 3 проблемы решена путем добавления поддержки ACID транзакционности, но, в нашей версии дистрибутива у нас далеко не третий Hive (да еще и на Map Reduce), а хотим получить высокую производительность и конкурентную нагрузку и поэтому нам пришлось реализовать ACID для Impala в Hadoop самостоятельно.

В нашем решении изоляция выполнена с применением подхода HDFS snapshot и разделения слоя хранения и доступа к данным через VIEW.

Когда данные записываются в HDFS, сразу, мгновенно создается снапшот на который переключается VIEW.

Пользователь читает данные с VIEW, а не напрямую с таблицы, поэтому следующая сессия записи никак не влияет на его текущий запрос.

Все что остается делать это переключать VIEW на новые HDFS снапшоты, число которых определяется максимальной длительностью пользовательских запросов и частотой обновления данных в Hadoop. Те в сухом остатке мы получаем аналог UNDO в Oracle, retention период которого зависит от количества снапшотов и регламента загрузки данных.

Основной секрет в том, что как только процессинговый движок определил какие данные из HDFS он должен прочитать, после этого DDL VIEW или таблицы может быть изменен т.к. оптимизатор больше не будет обращаться к словарю metastore. Т.е. можно выполнить переключение VIEW на другую директорию.

Функционал HDFS Snapshot настолько легковесный и быстрый что позволяет создавать сотни снапшотов в минуту и никак не влияет на производительность системы.

Изоляции изменений в нашем решении также является функцией DataReplictorа. Все загружаемые данные изолируются автоматически, причем на обеих контурах системы, а производные ETL данные изолируются через вызов API. Каждое изменение целевого объекта, которое происходит в рамках ETL процесса завершается вызовом API по созданию снапшота и переключению VIEW.

Благодаря такому решению, все загрузки и все данные доступны в режиме 24х7 без регламентных окон. HDFS снапшоты не приводят к большому избыточному хранению данных в HDFS. Наш опыт показал, что для часто меняющихся регламентных данных хранение снапшотов за трое суток приводит к увеличению размера максимум на 25%.

Управление конкурентной нагрузкой

Следующий большой блок требований управление конкурентной нагрузкой.

На практике это означает что нужно обеспечить

• Предсказуемую работу регламентных процессов;

• Приоритизация пользователей в зависимости от принадлежности к ресурсной группе;

• Отсутствие, минимизация или управление отказами в обслуживании;

Как это обеспечено на практике

• Настроено разделение ресурсов между сервисами Hadoop на уровне ОС через cgroups;

• Правильное распределение памяти между нуждами ОС и Hadoop;

• Правильное распределение памяти внутри кластера между служебными сервисами Hadoop, YARN приложениями и Impala;

• Выделение ресурсных пулов Impala отдельным пользовательским группам для гарантии обслуживания и приоритизация запросов

Результат предсказуемая высококонкурентная нагрузка десятков пользователей одновременно и десятков тысяч ETL запросов в сутки без влияния на другие составляющие экосистемы Cloudera.

Ри. Количество SQL запросов, завершающихся каждую секунду.

В настоящий момент на кластере регламентных расчетов в сутки регистрируется и успешно выполняется в среднем 900 тыс SQL запросов по трансформации и загрузке данных. В дни массовых загрузок и расчетов эта цифра поднимается до полутора миллионов.

Рис. Средняя утилизация CPU за сутки

При этом мы видим, что остается внушительный запас по производительности с тз возможностей повышения конкурентной работы. Есть понимание что это может быть и 1,5 млн и 2 млн запросов. Это означает что выбранный подход оказался верным и пропускная способность системы как и ее предсказуемость под нагрузкой показывает выдающиеся результаты.

Информационная безопасность

В финансовом секторе традиционно вопросы информационной безопасности являются одними из самых ключевых тк приходится работать с данными, которые не только подлежат защите с тз федерального законодательства, но и с требованиями, которые периодически ужесточаются госрегулятором. При выборе дистрибутива Hadoop стоит особое внимание уделять этим требованиям, так как большинство не вендорских сборок, либо сборок, спроектированных на базе популярных open source дистрибутивов (например Apache Big Top) не позволяют закрывать часть требований и при выводе системы в промышленную эксплуатацию можно столкнуться с неприятными сюрпризами недопуска системы от службы ИБ.

В кластере Cloudera нами были реализованные следующие требования:

• Ролевая модель доступа к данным

  • Все пользователи включены в группы Active Directory (AD) каталога;

  • Группы AD зарегистрированы в Sentry;

  • В Sentry выполнено разграничение доступа для баз Impala и директорий HDFS;

  • Каждый Target слой данных имеет ролевые слои VIEW с ограничениями на чувствительные данные в соответствии с ролевой моделью доступа;

• Кластеры керберизированы;

• Подключение клиентских приложений только с применением SSL шифрования. Также шифрование используется при передачи данных внутри кластера.

• Выполняется парсинг и приведение всех журналов сервисов Hadoop к единому реляционному формату стандартного журнала ИБ (единая точка интеграции для системы сбора данных ИБ)

  • Пользовательские запросы;

  • Запросы ETL;

  • Точки интеграции Hadoop с другими системами;

• Все серверы, ОС, компоненты и прикладное ПО настроены в соответствии с согласованными профилями информационной безопасности и периодически проходят проверку на предмет известных уязвимостей.

Единый аналитический слой данных

Наличие общего слоя консолидированных данных основное требование аналитического ХД.

Без этого Hadoop (как и любое другое ХД) озеро данных, которое пользователи начинают превращать со временем в неуправляемое болото. Поэтому важно иметь общую версию правды над этим озером чтобы все задачи решались в единой системе координат.

Был разработан единый аналитический слой консолидированных данных. Источником для него является копия детального слой КХД, которая регулярно реплицируется в среду Hadoop, а также дополнительные источники, подключаемые напрямую, минуя КХД.

Модель ориентирована на пользовательский ad-hoc доступ и проектировалась с учетом требований типовых задач клиентской аналитики, риск моделей, скоринга.

Реализованы все области данных, необходимые для решения задач розничного бизнеса и моделирования такие как:

• Аккредитивы

• Депозиты

• Залоги

• Заявки

• Карты

• Контрагенты

• MDM

• Кредиты

• Сегмент клиента

• Рейтинги

• Агрегаты

• Справочники

• Счета

• Эквайринг

• Векселя

• РЕПО

• Резервы

В настоящий момент слой состоит из 177 целевых объектов и порядка 2350 бизнес-атрибутов. В snappy сжатии объем данных порядка 20 Тб (не менее 100 Тб в RAW).

В модель загружена история с 2010 года. Ведь точность моделей зависит от глубины истории данных, на которых она обучается. Более того, история очищалась аналитическими алгоритмами. Дето в том, что в банке разветвленная филиальная сеть и часть филиалов мигрировали друг в друга, клиенты переходили из одного филиала в другой, производили пролонгацию сделок и тд. Все это составляет определенные сложности для анализа данных. Но в конечном целевом слое вся история отношений с каждым клиентом, все сделки, имеют непрерывную историю в рамках одного суррогатного ключа без пересекающихся интервалов историчности.

Реализованный единый слой - источник данных для производных прикладных витрин под бизнес-приложения, отчетность и модели. Сейчас у нас около 40 производных регламентных витрин, состоящих из 550 целевых таблиц и примерно 13200 атрибутов.

Надежность

Часто приходится слушать о ненадежности решений, спроектированных на Hadoop. За два года эксплуатации Cloudera Data Hub у нас практически не было каких-либо проблем, связанных с простоем системы. Случилось буквально пара инцидентов, повлиявших не регламентные процессы.

Один раз у нас забилось место, выделенное под БД metastore (недостатки мониторинга).

В другой раз была попытка выгрузить несколько сотен миллионов транзакций через Impala. В результате прилег координатор и другие пользователи и процессы не могли подключиться на этот координатор. Как результат выработали правило каждый отдельный вид процессов (загрузка данных, ETL, пользователи, приложения) подключается к своему координатору, который еще имеет дублера для балансировки. Ну и конечно большие выгрузки данных в системы потребители лучше делать через sqoop export. Ну и в последних релизах Impala уже без проблем может отдавать десятки миллионов записей на подключение.

Да, случаются выходы из строя дисков, приходится иногда делать decommission узлов для их замены, но все это проходит прозрачно для пользователей без остановки работы, ведь наш архитектурный подход сразу подразумевал устойчивость к выходу из строя как минимум двух любых узлов.

Итоги

В настоящий момент система является фабрикой данных всех розничных процессов Банка и аналитических приложений. Платформой ежедневно пользуется 36 департаментов и примерно 500 пользователей для самостоятельного решения задач по аналитике и моделированию.

Реализованный нами проект стал финалистом номинации Cloudera Data Impact 2020 в категории Data For Enterprise AI.

Выводы

После двух лет промышленной эксплуатации нашей Системы мы сегодня с уверенностью можем сказать, то экосистема Hadoop полностью позволяет реализовать все современные требования к аналитической платформе при использовании дистрибутива Cloudera и при правильных архитектурных подходах. Система может полностью вытеснить все традиционные аналитические СУБД без какого-либо ущерба к накопленному опыту разработчиков и аналитиков. Нужно всего лишь принять правильные решения и сделать прыжок веры. Традиционно консервативный Газпромбанк сделал с нами этот прыжок веры и смог построить современную аналитическую платформу, ввязавшись в гонку на розничном рынке в кратчайшие сроки.

Об успехах в цифрах можно посмотреть в записи нашего совместно доклада.

Для проектирования современной аналитической системы не требуется гетерогенная архитектура слоеного пирога с пропитками из гринпламов, тарантулов, игнайтов и так далее. Все данные и сервисы работы с данными должны находится под управлением одной целостной системы. Такой подход снижает наличие дополнительных точек интеграции, а следовательно, и потенциальные отказы. Не требуются дополнительные работы и длительные сроки по интеграции и пропитке этих слоев данными.

Наш архитектурный подход позволяет ускорить внедрение нового функционала и как следствие улучшить time to market новых продуктов, основанных на data driven процессах.

В современных аналитических задачах не существует понятий горячих и холодных данных. Ситуация прилета пачки проводок, за диапазон t - 3-5 лет - это каждодневная регламентная ситуация. И для такого случая вы должны пересчитать остатки, обороты, просрочки и предоставить данные для модели или определения сегмента клиента в аналитическом CRM. Как я уже писал выше, чем глубже в истории данные, тем точнее ваши модели. Такие задачи можно решить только если все данные в одном месте и в одной системе. Наш принцип - все данные горячие!

Для успешной реализации проектной команде недостаточно опыта знания технологии Hadoop. Hadoop это всего лишь инструмент. Необходимо применять подходы проектирования классического ХД на базе SQL MPP, иначе ваша система навсегда останется помойкой под архивные данные, нарисованной внизу слоеного пирога как хранилище неструктурированных и холодных данных на архитектурной картинке.

Наши ближайшие планы

В настоящий момент мы находимся в завершающей стадии миграции на новую платформу Cloudera Data Platform 7.1. Вполне вероятно, что на момент публикации мы уже на CDP и в ближайшее время тут будут опубликованы результаты. Пока, можно с уверенностью сказать, что после проведенных тестов, мы ожидаем ряд оптимизационных улучшений, связанных с Impala 3.4, появлением страничных индексов в parquet, наличием Zstd компрессии. Новые сервисы вроде Atlas и Cloudera Data Flow позволят закрывать функции управления данными и потоковой аналитики из коробки. В ближашее время мы также планируем пилотировать родной для Cloudera BI инструмент - Cloudera Data Visualization.

Что еще мы еще сделали в нашем ландшафте Hadoop

• Real-time интеграция системы с процессинговым центром с использованием Kudu (real-time клиентские данные, доступные для работы с минимальной задержкой наступления события). Горячие данные в Kudu, холодные в Parquet, общий склеивающий интерфейс доступа для пользователей через SQL Impala. Результат - данные в реальном времени о состоянии карточных транзакций и остатков по карточному счету открывают для бизнеса новые возможности.

• Историзируемый слой ODS

Построение слоя ODS с использованием Oracle Golden Gate с сохранением истории изменения источника с возможностью задания гранулярности истории по каждому объекту репликации, а также архивированием в Hadoop с возможностью схлопывания интервалов холодных данных.

• Графовая аналитика

  • Построение витрины property графа в Hadoop;

  • Загрузка в графовую БД Arango;

  • Интерфейс работы с графом для андерайтеров над Arango;

  • Графовые модели (анализ окружения клиента при скоринге);

• Текстовая аналитика

  • Работа моделей по распознаванию первичных документов клиента и поиска в них аномалий (контроль фронта, антифрод, автоматизация работы с заявкой);

  • Анализ новостных лент, тематических форумов

• Геоаналитика

  • Анализ удаленности и проходимости офисов от основных пешеходных маршрутов, автомобильных проездов и парковок;

  • Оптимизация курьерских маршрутов

• Система управления качеством данных, позволяющая оценить качество всех загружаемых и производных данных для принятия решений об использовании этих данных на прикладном уровне. Результат - мониторинг через визуальные дашборды и почтовые рассылки состояния качества данных аналитического слоя, поставка данных в системы потребители вместе с паспортом качества.

• Контейнеризация пользовательских приложений и моделей с использованием окружения K8S

Каждый пункт из этого списка достоин отдельной развернутой статьи, которые обязательно появятся в будущем. Следите за обновлениями, задавайте ваши вопросы и делитесь своим опытом.

Авторы:

Евгений Вилков, Глоубайт.

Колесникова Елена, Газпромбанк (АО).