Big Data *

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в 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 — декларируют углеродную нейтральность и снижение выбросов. Возникает очевидный вопрос: можно ли масштабировать ИИ и одновременно сокращать углеродный след? В статье разберёмся, как индустрия пытается решить это противоречие.

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

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

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

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

Data governance, data mesh, modern data stack, data lineage – столько разных data, столько разных популярных подходов и инструментов. Лидером по популярности (на мой скромный взгляд) среди всех них является data catalog. Многие говорят о нем, многие хотят его, многие уже внедрили. Но внедрить это одно дело, а вот получить от него пользу – дело совсем другое.

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

Привет, Хабр! На связи Keisilop. Последние полгода пристально слежу за тем, что происходит в мире ИИ. Для этого завёл ТГ-канал, где отмечаю главные события и тенденции, стараюсь делиться самыми важными инсайтами. Это моя первая статья на Хабре — пересказ и разбор материала, который заставил меня серьёзно задуматься о будущем.

Речь о статье Мэтта Шумера (Matt Shumer) «Something Big Is Happening». Мэтт — не теоретик, а практик: 6 лет он строит AI-стартапы и инвестирует в эту сферу. Он живет в этом мире. И его честное мнение, по его же словам, «звучит так, будто я сошел с ума».

Но именно потому, что оно звучит так пугающе и откровенно, я считаю, что каждый из нас должен это услышать. Мы стоим на пороге перемен, которые могут оказаться куда масштабнее, чем пандемия COVID-19. Помните февраль 2020-го? Большинство из нас отмахивалось от новостей о вирусе. А через три недели мир изменился до неузнаваемости.

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

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

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

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

Привет, Хабр! Важной составной частью Time Intelligence в DAX являются функции работы со временем, в частности, DATEADD, т.к. она является базовой для других (например, SAMEPERIODLASTYEAR является псевдонимом DATEADD('Date'[Date], -1, YEAR)) и возвращает таблицу (в отличие, например, от EDATE , которая возвращает только скаляр), и также может использоваться в качестве фильтра в CALCULATE.

Информацию о DATEADD приходится собирать из разных источников. Часть описано в официальной документации DATEADD, что-то есть в DAX Guide, что-то есть в материалах SQL BI, поэтому картина составляется по частям, хотя логика функции неочевидна и велики риски ошибок при использовании DATEADD в случае некорректного её использования.

Интересующимся правилами DATEADD для обеспечения Time Intelligence в DAX — добро пожаловать под кат :)

Зачем OpenAI купила базу данных Rockset за $117M и тут же убила её для всех клиентов.
Как устроена архитектура «пять слоёв контекста».
Почему принцип «meaning lives in code» меняет подход к документированию данных.
И что из этого может взять обычная компания уже сейчас без GPT-5 и без $117M.

Всем привет! Меня зовут Василий Калинин, я senior-аналитик в отделе ML-аналитики музыкального сервиса Звук. Про то, чем занимается наша команда, мы уже писали ранее (можно почитать в этой статье). 

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