Мы получили 1022 заявки, приняли из них 918, в шорт‑листы попало более 300 статей. Точной цифры по шорт‑листам нет неслучайно: поскольку наш естественный интеллект это вам не ChatGPT склонен уставать и ошибаться, несколько статей могут попасть в шорты, но, скорее всего, выпадут из них — так, во время подготовки этой статьи выяснилось, что из финала выбыли двое участников, скрывшие свои публикации в черновики.

Вообще, такого «Технотекста», как в этот раз, ещё не было: обычно мы сравнительно легко отсеивали участников и выбирали финалистов, разница в уровне материалов была очевидной. В этот раз номинанты сильные — и многие статьи не вышли в финал не потому, что они какие-то не такие, а потому что они объективно слабее лучших из лучших — но очевидно, что сильнее большей части статей на Хабре. Хотя участники «Технотекста» из года в год находят отличные способы добить нервную систему модераторов конкурса 😃

• что за зверь этот Airflow, из каких компонентов состоит и как они между собой взаимодействуют
• про основные сущности Airflow: пайплайны, которые называются DAG, Operator и еще про несколько вещей
• как преуспеть в разработке на Airflow
• как мы внедрили генерацию пайплайнов и так называемое «декларативное писание пайплайнов»
• про плюсы и минусы использования Airflow

Airflow в Lamoda Tech играет роль оркестратора процессов обработки данных. Ежедневно с его помощью мы запускаем 1 800+ тасок на проде, примерно половина из которых являются Spark-приложениями.

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

Меня зовут Андрей Булгаков, я лид команды разработчиков Big Data в Lamoda Tech. Вместе с разработчиком Иваном Васенковым в этой статье мы поделимся историей создания Airflow-оператора для запуска Spark-приложений.

Apache Spark – фреймворк для обработки больших данных, который давно уже стал одним из самых популярных и часто встречаемых во всевозможных проектах, связанных с Big Data. Он удачно сочетает в себе скорость работы и простоту выражения своих мыслей разработчиком.

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

Привет! 

Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.

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

Что такое spill-ы в Spark

Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.

В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».

Можно ещё сильнее упростить аналогию.

Привет! Меня зовут Василий Землянов, я занимаюсь разработкой ML-инфраструктуры. Несколько лет я проработал в команде, которая делает споттер — специальную маленькую нейросетевую модельку, которая живёт в умных колонках Яндекса и ждёт от пользователя слова «Алиса». Одной из моих задач в этой команде была квантизация моделей. На пользовательских устройствах мало ресурсов, и мы решили, что за счёт квантизации сможем их сэкономить — так в итоге и вышло.

Потом я перешёл в команду YandexGPT. Вместо маленьких моделей я стал работать с очень крупными. Мне стало интересно, как устроена квантизация больших языковых моделей (LLM). Ещё меня очень впечатляли истории, где люди берут гигантские нейросети, квантизируют в 4 бита и умудряются запускать их на ноутбуках. Я решил разобраться, как это делается, и собрал материал на доклад для коллег и друзей. А потом пришла мысль поделиться знаниями с более широкой аудиторией, оформив их в статью. Так я и оказался на Хабре :)

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

Сегодня все крупные компании сохраняют и обрабатывают большие объёмы информации, причём стремятся делать это максимально эффективным для бизнеса способом. Меня зовут Мазаев Роман и я работаю в проекте загрузки данных на платформу SberData. Мы используем PySpark, который позволяет очень быстро распределённо обрабатывать данные в оперативной памяти узлов нашего кластера на базе Hadoop. Я поделюсь способом, с помощью которого можно снизить потребление ресурсов кластера за счёт перезапуска PySpark-приложений между выполняемыми Spark-задачами, и расскажу, как это делать правильно.

Всем привет! Случались ли у вас ситуации, когда количество DAG’ов в вашем Airflow переваливает за 800 и увеличивается на 10-20 DAG’ов в неделю? Согласен, звучит страшно, чувствуешь себя тем героем из Subway Surfers… А теперь представьте, что эта платформа является единой точкой входа для всех аналитиков из различных команд и DAG’и пишут более 50 различных специалистов. Подкосились ноги, холодный пот и желание уйти из IT?

Не спешите паниковать, под катом я расскажу о том, как контролировать потребление ресурсов DAG’ов Airflow для предупреждения неоптимально написанных DAG’ов и борьбы с ними.

Меня зовут Давид Хоперия, я Data Engineer в департаменте данных Ozon.Fintech и моим основным инструментом является Apache Airflow, поэтому настало время углубиться в детали его работы.

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

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

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

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

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

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

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

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

Привет, Хабр!

В наше неспокойное время, когда сфера AI стремительно движется вперёд, хочется немного стабильности и уверенности в завтрашнем дне. Как это связано с темой статьи?

Самым прямым образом — алгоритмы прокачивают умение системно мыслить, искать нестандартные пути решения; человека, у которого эти скиллы на высоте, вряд ли заменит ИИ. Так что, тратя бесценное время на алгоритмы, вы занимаетесь очень полезным делом, расслабьтесь и получайте удовольствие) В качестве бонуса к прокачиванию серого вещества вы получите сверхспособность пройти любой алгособес в FAANG и удовлетворить любые потребности пирамиды Маслоу — довольно приятно)

В этой статье мы разберём графовые алгоритмы типо DFS, Флойда–Уоршелла и строковые наподобие Ахо-Корасик.

Привет, Хабр!

Так уж повелось, что любой уважающий себя работодатель перенимает передовые методики FAANG — по этой причине практически во всех IT-собесах есть она: секция алгоритмов. Кто-то ей рад, кто-то не очень, но секция есть и уходить пока не планирует. Поэтому нужно закатать рукава и достойно встретить суровую реальность.

Привет, Хабр! Я Ульяна, старший аналитик в направлении продуктового и системного анализа в отделе Tinkoff Mobile Core. Наш отдел разрабатывает общие технические решения — библиотеки, которые используются в мобильных приложениях экосистемы Тинькофф.

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

Документацию мы ведем в Confluence — и обычно, когда я рассказываю про Confluence, у многих он вызывает, мягко говоря, неприятные ассоциации. Миллион разделов, неудобная навигация, портянки бесконечного текста и многое другое, что отбивает желание даже открывать любую wiki. Но я спешу вас обрадовать — все может быть совсем иначе!

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

Привет, Хабр! На связи ведущий аналитик Ульяна. В первой главе я рассказала, что такое Confluence, зачем его используют и как работать с макросами. 

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

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

Но что если я расскажу вам о некоторых полезных библиотеках, о которых вы скорее всего не слышали? В списке не будет всем известных библиотек таких, как Pandas, Polars, Scipy и тд

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

Надеюсь, вы найдете что-то полезное для себя.

Предположим, у вас есть две последовательности чисел, которые вы хотите сравнить, чтобы измерить, насколько они связаны или зависимы друг от друга. Это действительно довольно общий сеттинг: две последовательности могут представлять временные ряды, так что у вас есть таблица с тремя столбцами и кучей строк. Первый столбец будет временем (скажем, с часовыми интервалами), а затем по одному столбцу для каждой последовательности; первый, например, может быть средней ценой акции за этот интервал, а второй - объемом торгуемых акций за этот интервал. Или вы могли бы сравнить процентное изменение цены одной акции по сравнению с другой. Конечно, это вовсе не обязательно должны быть временные ряды: у вас также может быть всего два столбца (то есть вообще без столбца времени). Первый может быть ростом американца старше 30 лет в дюймах, а второй — весом того же человека в фунтах. Или, чтобы использовать более актуальный пример, каждый столбец может представлять вектор эмбеддингов некоторых предложений на английском языке от определенной модели LLM. Первый столбец может быть вектором от модели Mixtral 8x7B для строки "I love my 3 sons" (Я люблю моих трех сыновей), а другой — от той же модели для строки "I cherish my 5 daughters" (Я дорожу моими пятью дочерьми).

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

Привет, Хабр! Меня зовут Иван Антипов, я занимаюсь ML в команде матчинга Ozon. Наша команда разрабатывает алгоритмы поиска одинаковых товаров на сайте. Это позволяет покупателям находить более выгодные предложения, экономя время и деньги.

В этой статье мы обсудим кластеризацию на графах, задачу выделения сообществ, распад карате-клуба, self-supervised и unsupervised задачи — и как всё это связано с матчингом.

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

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

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