Big Data *

Привет! Меня зовут Павел Саликов, я Senior ML-инженер в команде Дубликатов Товаров Wildberries. В этой статье расскажу про наше решение матчинга товаров на маркетплейсе и про то, как удалось сделать его быстрым.

В статье исследуется использование DAX Studio, мощного инструмента, который помогает разработчикам Power BI извлекать и обрабатывать метаданные из дашбордов. Утилита позволяет оптимизировать рабочие процессы, делая задачи, такие как заполнение файлов метаинформацией, более эффективными.

Привет, Хабр! На связи Александр Бобряков, техлид в команде МТС Аналитики. Это мой десятый материал про Apache Flink. В предыдущей части мы закончили разбирать оператор с Flink-таймерами, использующими внутреннее состояние. Также я показал, как их можно тестировать с помощью классов TestHarness или Flink MiniCluster. В дополнение тестами была покрыта вся Flink-джоба, включая E2E-тесты.

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

Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии статей. Эта часть соответствует релизной ветке с названием release/9_JacksonStateSerializer.

По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже.

Всем привет! Меня зовут Андрей, я работаю дата аналитиком в Data Team продукта Dialog.X5/Insights в X5 Tech. Мы предоставляем аналитику по продажам и покупательскому поведению на данных X5 Group.  Для обработки больших объёмов данных в продукте используется  СУБД (система управления базами данных) Greenplum.

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

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

Но как контролировать качество на проектах разметки максимально эффективно? Выстроить такие процессы непросто, но мы считаем, что у нас это получилось.

Для того, чтобы гарантировать на каждом проекте высокое качество разметки, в Data Light существует отдел Контроля качества. Я, Евгений Шилкин, руководитель ОКК, расскажу, что нам позволяет обеспечивать стабильно высокое качество на проектах и какие советы для эффективной валидации мы можем дать.

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

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

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

Давайте разбираться.

Команда Business Intelligence GlowByte приветствует всех читателей сегодняшнего гайда по обработке данных в FineBI 6 версии. Меня зовут Александр Ларин, руководитель центра поддержки и обучения BI-решений в GlowByte, и в этой статье я поделюсь полезными функциями, которые облегчат вашу работу по подготовке данных для их последующего анализа. С первой частью вы можете ознакомиться по ссылке.

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

Привет, Хабр! На связи Business Intelligence GlowByte. 

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

Привет, Хабр! На связи Александр Бобряков, техлид в команде МТС Аналитики. В предыдущих постах я рассказал, как собрать первое приложение Flink со Spring, реализовав пайплайн дедупликации сообщений Kafka-to-Kafka. В этом примере погружусь в использование таймеров в Flink, а в следующих статьях расскажу, как работать с более сложными состояниями, эволюционировать их схему и покрыть это все тестами.

Весь разбираемый исходный код есть в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Эта статья соответствует релизной ветке с названием release/7_Trigger_Flink_Job.

Это восьмой материал из моей серии про Apache Flink. По мере выхода новых ссылки на них будут появляться ниже.

Привет, Хабр! Меня зовут Сергей Смирнов, я аналитик в продукте CVM в X5 Tech. Я занимаюсь разработкой инструмента анализа A/B экспериментов. Мы ежедневно считаем десятки метрик для сотен экспериментов на десятки миллионов клиентов –- это терабайты данных, поэтому наш инструмент разработан на Spark.

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

Привет, чемпионы!

AI решение, которые я разберу в этой статье - после запуска в телеграм привлекло почти органически внимание 70 000 новых пользователей за месяц, а всего было произведено 400 000 генераций. Разбираю, как реализовал сама ML модель. Погнали!

Представьте, что вы ни разу не выступали на конференциях или митапах, а тут решились и едете на ваше первое выступление, да не куда-нибудь, а на Data + AI Summit в Сан-Франциско. «Так не бывает!» — скажете вы, а я отвечу: «бывает!»

Привет! Это Женя Добрынин, Senior Data Engineer в Dodo Engineering. Сегодня я расскажу о том, как мы с коллегой ездили на конференцию в США, а заодно и о том, во сколько вам обойдётся такая поездка, и что нужно сделать, чтобы она состоялась.

Привет, Хабр! Это тимлид DS группы ранжирования и поиска Дана Злочевская и тимлид группы разработки Михаил Нестеров из Lamoda Tech. 

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

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

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

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

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

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

• Рост time-to-market. На каждый новый ML-продукт или эксперимент у команд уходило всё больше времени просто на «разогрев»: сбор данных, выравнивание форматов, отладка пайплайна.

Тогда мы поняли, что пора систематизировать наш подход к хранению и работе с датасетами, и реализовали собственный фреймворк на основе Apache Spark — Feature Storage, который сейчас является стандартом в компании. А позже мы выделили отдельное решение для специфичных кликстрим-данных — Action Storage.

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

Такие workflow-оркестраторы, как Metaflow или Apache Airflow, на слуху. Однако в их тени существуют не менее интересные решения — например, StepWise, Dagu, Windmill, Flyte и µTask. Они предоставляют интересные возможности для автоматизации, ускорения и упрощения настройки сложных workflow, и часто обладают более современной архитектурой, меньшим порогом входа или ярко выраженной специализацией для типовых задач.

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

Эксперты компании «Криптонит» проанализировали главные тренды использования Apache Spark в бизнесе, выделили особенности его применения в России и спрогнозировали дальнейшее развитие на основе выявленных тенденций.

Растущая востребованность Spark объясняется не только открытым исходным кодом и гибкостью, но и лёгкостью интеграции с современными технологиями — от машинного обучения до облачных платформ.

«В России Apache Spark становится не просто популярным фреймворком для обработки данных, а частью экосистемы отечественных решений в сфере Big Data. Особенно это касается объектов критической инфраструктуры, где всегда отдаётся предпочтение только самым надёжным и проверенным решениям», — пояснил Иван Попович, руководитель направления обработки данных компании «Криптонит».

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

«Открытый исходный код здесь играет ключевую роль, так как обеспечивает прозрачность и возможность тщательной верификации. Также он даёт уникальную возможность адаптировать решение под конкретные требования проекта. Хотя само по себе наличие открытого кода не является гарантией безопасности, Apache Spark за 15 лет своего развития доказал эффективность и надёжность в самых различных областях применения», — добавил эксперт.

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

Почему, по данным экспертов GlowByte, целых 80% проектов внедрения систем бизнес-аналитики выходят за рамки изначально запланированного бюджета? Ответ парадоксально прост и сложен одновременно: компании систематически недооценивают реальную совокупную стоимость владения BI-системами. Наши наблюдения показывают, что большинство заказчиков концентрируются исключительно на очевидных статьях расходов, игнорируя множество "скрытых" факторов, которые неизбежно проявляются по мере развития проекта.

За годы работы с десятками проектов внедрения аналитических систем мы в GlowByte выявили закономерность — даже опытные ИТ-директора порой не учитывают до 40% реальных затрат при планировании бюджета на BI-инициативы. В этой статье я поделюсь инсайтами о наиболее типичных "финансовых ловушках", которые подстерегают компании на этом пути.

Каждый, кто работал с большими языковыми моделями (LLM), знает про ограничение длины контекста: модель не может напрямую обработать текст, превышающий определённое число токенов. Это накладывает ограничения на работу с длинными документами и обширным контекстом. Но что если бы мы могли упаковать длинный текст в один-единственный вектор и скормить его модели как обычный токен? Звучит фантастично, однако свежие исследования показывают, что это возможно – такие “mem-векторы” позволяют сохранить сотни и даже полторы тысячи токенов информации в одном эмбеддинге. Это принципиально иной подход, нежели классическое сжатие данных, и он сулит интересные применения.

Mem-вектор (от “memory vector”) – это специально обученный вектор, который хранит содержание целого текста. Идея в том, что если модель умеет предсказывать текст, то можно подобрать такой вектор на входе, при котором замороженная (неизменяемая) LLM сама декодирует исходный текст. Иначе говоря, mem-вектор играет роль «семени», из которого предобученная модель порождает заложенное в нём сообщение. В этой статье разберём, как это работает, почему вообще возможно “запихнуть” роман в один вектор и какие ограничения при этом появляются. Также сравним mem-подход с классическими алгоритмами сжатия (Huffman, арифметическое кодирование, zlib и др.), обсудим последние научные работы на эту тему и возможные применения: от Retrieval-Augmented Generation (RAG) до передачи новых знаний замороженным моделям. Центральная мысль: mem-векторы – это не просто компрессия текста, а способ напрямую скормить модели смысл и знания, минуя последовательное чтение токенов.

Перевели и дополнили статью Марины Уисс, applied scientist (дата-сайентист со специализацией в прикладной статистике) в Twitch. Когда-то Марина перешла в IT из не связанной с технологиями сферы деятельности, а потом помогла с этим переходом многим людям без IT-бэкграунда.

В этой статье она делится советами для дата-аналитиков, которым хотелось бы заниматься data science. А мы добавили мнение экспертов и рекомендации, актуальные для российских образовательных реалий.

Это мой вольный перевод статьи "Data Engineering is Not Software Engineering", с рядом моих правок, дополнений, а так же сокращений (так как автор склонен повторять одно и то же, но иными словами или излишне "разжевывать" очевидные вещи). Мне кажется, автор действительно поднял очень важную тему, которую я "чувствовал" по своей практике, но не мог сформулировать так точно, как это сделал он.

Мало кто задумывается, что дата-инженерия и разработка ПО имеют значительные различия. Поэтому распространено мнение, что некое отставание дата-инженерии в части внедрения современных методов разработки, таких как Agile, Test Driving Development и т.д. обусловлено лишь отставанием в освоении этих передовых практик.

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

История, связанная с этой задачей, началась для нас в мае 2024 года. Один из крупных пользователей Greenplum/Arenadata DB обратился к нам с запросом реализовать возможность отслеживания изменения размеров файлов данных таблиц. Эта функциональность стала бы составной частью, источником событий для системы мониторинга пользовательских кластеров. Задача показалась нам крайне интересной и перспективной. Однако пользователю, как это часто бывает, решение требовалось уже вчера.

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