Big Data *

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

Привет, Хабр! Меня зовут Александр Маркачев и я — Data Engineer команды Голосовой Антифрод в билайн. Расскажу, как борьба с мошенниками может обернуться личным вызовом.

Все техники сопровождаются объяснениями, примерами и рекомендациями для самостоятельного повторения.

🤖 Колхоз — это не только про тракторы. Это про мозги. И автоматизацию. В этой статье покажу, как мы собрали платформу для управления чем угодно — от теплицы до котельной — на базе ESP32.

Всем привет! Это DS-ы Павел Парфенов и Максим Шаланкин из команды Финтеха Big Data МТС. Мы и наши коллеги Data Scientists и Data Analysts ежедневно обрабатываем огромные массивы информации, строим модели и выделяем целевые сегменты, чтобы принимать обоснованные решения. Наши рутинные задачи — предварительный анализ данных (EDA), обучение ML-моделей и сегментация аудитории — часто отнимают кучу времени и ресурсов. 

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

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

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

20 марта мы провели митап для пользователей YTsaurus — главной платформы для хранения и обработки больших данных в Яндексе от разработчиков из Yandex Infrastructure, которая уже успела зарекомендовать себя за пределами компании.

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

Привет, Хабр! Меня зовут Александр Антипов, я продакт-оунер MWS Tables.

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

Полтора года назад мы в МТС создали для таких кейсов MWS Tables — внутреннюю платформу самостоятельной автоматизации. В этом посте — реальные примеры, как MWS Tables уже применяется на практике. Я покажу, как с помощью MWS Tables реализовали единый реестр для работы с качеством данных, централизованную систему по менеджменту IT-проектов и собственный таск-трекер. Все подробности — под катом.

Привет, Хабр! Меня зовут Михаил Килинский, я — Senior Developer в проекте Data Warehouse «Лаборатории Касперского». Наша команда строит хранилища данных и разрабатывает ETL- и ELT-процессы, мы пишем на Python, SQL и C# (.NET), а весь код находится в монорепозитории.

Гибкие методологии построения хранилищ данных — очень популярный тренд. Причина — возрастающая сложность корпоративных моделей данных и необходимость интеграции большого числа разнородных источников, которые включают в себя не только традиционные СУБД и плоские файлы, но и различные real-time-брокеры сообщений, внешние API и базы данных NoSQL.

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

Всем привет! Меня зовут Алексей Николаев, я работаю дата-инженером в команде ETL-платформы MWS Data (ex DataOps). Часто сталкиваюсь с тем, что в сложной инфраструктуре и больших проектах простые, на первый взгляд, задачи по работе с данными очень сильно усложняются. В результате возникают ситуации, когда хорошие практики превращаются в плохие решения, а плохие практики как раз могут дать хороший результат.

Мои коллеги уже рассказывали про нашу платформу, ее внедрение внутри экосистемы и наши инструменты для работы с данными. В процессе развития продукта перед нами встала проблема массовых регламентных загрузок данных из реляционных источников. Для этого мы создали внутренний инструмент — библиотеку d-van. В качестве движка в ней используется Apache Spark, с которым она взаимодействует через библиотеку onETL. На примере d-van я покажу нестандартный подход к использованию возможностей Apache Spark. Расскажу, какие задачи можно решить с помощью режима master=local и как свой инструмент может стать альтернативой Apache Nifi или Debezium.

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

Меня зовут Алина Шестакова. Я разработчик в команде разработки DataPlatform единой облачной платформы One-сloud. В этой статье расскажу о том, как устроен стриминг данных в ОК, а также обо всех патчах и челленджах, возникших в процессе обновления стримингового фреймворка.

Привет! Я Сергей Кляхандлер, senior DS-инженер в команде LLM Авито. 

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

Статья будет полезна DS-инженерам, которые работают с мультимодальными LLM-моделями.

Динамические таблицы — это распределённая база данных, key‑value‑пары которой объединяются в привычные пользователям реляционных СУБД таблицы. В YTsaurus в них можно хранить огромные массивы данных, при этом их можно быстро читать — поэтому YTsaurus используют почти все сервисы Яндекса: Реклама, Маркет, Такси, даже Поиск при построении поисковой базы, и другие.

Я руковожу службой разработки динамических таблиц в Yandex Infrastructure и раньше уже рассказывал, как мы оптимизировали чтение, улучшали выборку строк в SQL‑запросах и защищались от перегрузок. Сегодня вышла новая версия YTsaurus 24.1.0, в которой динамические таблицы получили ещё несколько долгожданных доработок. В статье расскажу про них подробнее.

Привет! Если после заголовка вы решили, что это очередная статья в стиле «Топ-10 способов ускорить Pandas», то не торопитесь с выводами. Вместо топов и подборок предлагаю взглянуть на бенчмарки скорости и потребления памяти в зависимости от характеристик датафрейма и убедиться, что часть советов из статей по ускорению могут оказаться даже вредными. Разберём, какой из способов ускорения нужно пробовать в разных ситуациях, как это зависит от размера датафрейма и как ведёт себя в реальном проекте.

Всем привет! Меня зовут Саттар Гюльмамедов и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал «Слухи о моей смерти сильно преувеличены» — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ. 

В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурам, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.

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

Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме «E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.

Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации «Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? 

Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы.

Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

Сейчас данные – новая нефть, этот тренд становится важным для принятия решений в компаниях. Зачем искажают данные? Обычно это делается, когда желаемое хотят выдать за действительное, представить что-то в выгодном свете, подтолкнуть к ошибочным выводам «на основе данных». Чаще такие искажения встречаются в презентациях, поскольку при использовании дашбордов пользователь, как правило, самостоятельно может углубиться в данные и перепроверить их, если возникают сомнения.

Привет, Хабр! Меня зовут Андрей Машковцев, я — ведущий BI-аналитик в «Т-банке», эксперт Skillbox, веду телеграмм–канал «Лайфхаки в аналитике» и увлекаюсь бегом. Для закрытого комьюнити Skillbox Code Experts рассказал об этике визуализации данных. Как представлять данные этично и каким образом нами манипулируют с помощью графики. Основные мысли переложил в статью. Напомню, что в первой части статьи я рассказывал, как не нужно визуализировать данные и показал антипаттерны на примерах. В этой статье приведу примеры намеренного искажения данных при визуализации и научу их распознавать.

Привет, Хабр! На связи команда продуктовой аналитики.

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

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

Привет! Меня зовут Андрей Татаренко, я работаю Data Scientist-ом в Альфа-Банке. Я вам расскажу о своем опыте разработки Python-библиотеки для автоматизации разработки типовых ML-моделей. В статье привожу ту структуру основных классов, которая у меня получилась. Надеюсь, читатель сможет почерпнуть какие-то идеи, особенно если уже сталкивался с подобной задачей.

Привет, Хабр! Меня зовут Дима Пичугин, и уже семь лет я занимаюсь различными компонентами T Data Platform. Эта статья — результат внутреннего аудита наших инструментов, но я подумал, что она может быть интересна не только нашим аудиторам, но и более широкой аудитории. Enjoy!

Платформа данных в Т-Банке существует более 18 лет и за это время прошла значительный путь эволюции. Она помогает более чем 17 тысячам пользователей извлекать из данных ценную информацию для бизнеса. За последние годы подходы к работе с данными заметно изменились: индустрия постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — Lakehouse-архитектур. Вместе с отраслью менялась и наша платформа.

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

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

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

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

Прийти и по запросу быстро найти нужные данные — идеальный сценарий. Но он практически невозможен при условии использования множества баз данных и хранилищ. В реальных условиях без «надстройки» над всеми БД и «единой точки входа» команды вынуждены тратить время на исследование разных хранилищ, их каталогов и подкаталогов в поиске нужных файлов без какой-либо гарантии успешного результата. Такой «надстройкой» являются каталоги данных.

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