Big Data *

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

В PostgreSQL есть фича, про которую знают далеко не все, хотя она существует с незапамятных времён. Advisory locks — пользовательские блокировки, которыми управляет не БД, а ваше приложение. PostgreSQL только хранит их состояние и разруливает конкуренцию. А вы решаете, что именно заблокировать и когда отпустить.

Зачем это нужно? Вы строите распределённую систему, несколько инстансов приложения работают с одной базой, и вам нужно гарантировать, что определённую операцию выполняет только один инстанс одновременно. Классический ответ — Redis с SETNX или Consul/ZooKeeper. Но если у вас уже есть PostgreSQL — зачем тащить ещё одну зависимость?

Спроси любого уважаемого аналитика или инженера данных о том, какие бывают способы моделирования данных, тебе ответят: звезда, 3NF и DataVault. Спроси ИИ, получишь примерно такой же ответ. Придешь на какой-нибудь проект в компанию, также скорее всего встретишь там кого-нибудь из этих друзей. В 90% материалах про методологии моделирования освещаются только эти трое. Как будто других методологий не существует.

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

Привет! Сегодня на связи команда вендора Data Sapience, а именно Spark-разработчик Виталий Мартынов и технические лидеры направления разработки Apache Spark платформы Data Ocean Nova Дмитрий Паршин и Евгений Морозов.

Концепция Lakehouse активно продвигается как «золотая середина» между Data Lake и Data Warehouse: она обещает объединить гибкость хранения данных, расширенную аналитику и соблюдение транзакционности в единой архитектуре с использованием современных табличных открытых форматов, таких как Iceberg (который уже де-факто стал общепринятым стандартом при построении Data Lakehouse). И сегодня мы хотим посвятить статью разбору следующего вопроса: почему без использования Spark нельзя построить полноценный Lakehouse? 

Поговорим о том, какую роль Spark играет в Lakehouse-подходе, какие задачи он закрывает успешнее других, о его тесной взаимосвязи с Iceberg и том, почему альтернативы часто не дотягивают до нужного уровня универсальности, масштабируемости и надежности в рамках большой продуктивной среды. Также расскажем, почему мы в Data Ocean Nova используем Spark в качестве движка для обслуживания Iceberg-таблиц и инструмента для миграции данных в Lakehouse.

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

Десять лет всё работало. Поставщики присылали прайсы, менеджеры загружали. В 90% случаев клиенты искали товар по артикулу — просто вбивали номер и получали результат. Оставшиеся 10% запросов — это названия вроде «хомут бмв х5». И поиск как-то справлялся.

Да, в базе была каша: один и тот же товар мог называться «Хомут винт. BMW X5/E81» и «Хомут крепления топливного шланга 12мм для BMW». Но артикулы вывозили, а на остальное закрывали глаза.

А потом мы узнали про Честный знак.

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

Представьте стандартный отчёт по промокампании: «Пользователи, применившие промокод, потратили на 800 рублей больше среднего». Бизнес доволен, маркетинг рапортует об успехе. Но подождите, а сколько из них потратили бы эти деньги и без промокода?

Это не риторический вопрос. Это принципиальная проблема, которая называется selection bias — систематическая ошибка отбора.

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.

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

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

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

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

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

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

Привет, Хабр. Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform, VK Tech.

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

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

Привет, Хабр! Я Дмитрий Клепиков, разработчик в команде Modus BI. Хотя моя основная работа напрямую не связана с аналитикой данных, мне стало интересно: может ли разработчик без профильного опыта пройти весь путь аналитика — от гипотез до BI-дашбордов — используя только LLM и MCP-серверы?

Для проверки я взял открытую статистику ДТП Санкт‑Петербурга за 10 лет, подключил MCP‑серверы и составил Skill‑файлы для Claude Code, чтобы автоматизировать визуализацию. За 4 часа получилось собрать три дашборда, выполнить около 80 SQL-запросов и проверить 15 гипотез. Вот что из этого вышло...

Приветствую!

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

В далеком 2022 году решил я автоматизировать теплицу тёще и даже это реализовал на базе ESP32 с управлением автополива по WI-FI и мониторингом температуры, освещенности, влажности почвы в теплице. Использовал готовый сервис интернета вещей iocontrol.ru для управления поливом и мониторингом телеметрии - температура, влажность, освещенность. Удобная штука, но с ограничениями. Но тем не менее огромное спасибо создателям этого веб ресурса!

Вкратце расскажу про железную часть проекта

Всем привет! Меня зовут Станислав Ким, я ML-разработчик в команде качества поиска Ozon. В этой статье расскажу, как мы перешли от ранжирования товаров к ранжированию предложений, внедрили «матрицу памяти» для переноса статистики и получили +0,9% к GMV на пользователя.

Представьте простую ситуацию. Вы — продавец электроники. Выводите на Ozon новую модель робота-пылесоса. Чтобы ворваться на рынок, вы ставите цену на 20% ниже конкурентов и отгружаете партию на ближайший склад, чтобы доставка была «завтра». Логика подсказывает: алгоритмы увидят выгодное предложение (дёшево + быстро), подкинут товар в топ, и продажи взлетят.

Реальность: проходит день, два... а товар висит на 5-й странице выдачи. Потому что для алгоритма ранжирования ваш пылесос — «чистый лист». У него нет истории продаж, нет кликов, нет отзывов. Рядом в топе — конкуренты: они дороже, доставка дольше, но у них есть история: тысячи заказов за прошлый год. Алгоритм «любит» их за накопленную статистику, а ваше выгодное предложение игнорирует — он просто не знает, чего от него ждать. В индустрии эта проблема называется cold start — и с ней сталкиваются все крупные маркетплейсы.

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

Меня зовут Владислав Пономарев, я архитектор, проектирую дома. Ещё в магистратуре, 10 лет назад я занимался BIM-внедрением в проектной организации в Сочи. Это были Revit, Civil 3D и другие инструменты. Делал это в рамках своей темы магистерской работы. Потом переключился на архитектуру в частном домостроительстве, где больше изучал практические вопросы проектирования и философию архитектуры, ее эстетические качества. Но любовь к более сложному BIM осталась. С энтузиазмом продвигал тему BIM, когда до массового внедрения в РФ было еще далеко.

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

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

Этот вопрос стал основой моей ВКР на тему «Разработка методики определения квалификационного уровня программиста на основе мультимодального анализа».

Вместо того чтобы гадать, я решила довериться данным. Я собрала датасет из 721 вакансии стека C#/.NET и 16 различных репозиториев, прогнала их через LLM (Saiga Llama 3) и нейросеть GraphCodeBERT, чтобы найти объективные метрики «сеньорности».

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

Вечный конфликт: аналитики требуют свободы маневра, а DBA закрывают доступ к базе, опасаясь одного «убийственного» запроса, который положит весь кластер. В Postgres Professional мы разработали Tengri — систему, где каждый пользователь получает изолированные вычислительные ресурсы. Рассказываю, как архитектура индивидуальных вычислителей позволяет избежать конкуренции за ресурсы и почему после такого опыта возвращаться к общим очередям запросов уже не хочется.

Бум генеративного ИИ требует всё больше вычислительных мощностей — а значит, новых центров обработки данных. В 2026 году в США работает более 5 000 ЦОДов, по миру — свыше 8 000. По прогнозам Министерства энергетики США, в ближайшие четыре года ежегодно будут вводиться около 450 новых объектов, а суммарная мощность их энергопотребления вырастет с 100 до 200 ГВт.

Но ИИ-инфраструктура — это не только серверы и чипы, а ещё и бетон. Дата-центры требуют массивных фундаментов и инженерных корпусов, а производство цемента даёт около 7–8% мировых выбросов CO₂. Чем быстрее растёт ИИ, тем больше строится ЦОДов — и тем выше углеродный след строительства.

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

Здравствуйте, уважаемые читатели Хабра!

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

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

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