Data Engineering *

Привет! Меня зовут Кирилл Львов, я fullstack-разработчик в компании СберАналитика. В этой статье хочу рассказать про мощный инструмент трансформации данных — DBT (Data Build Tool).

Сегодня любой средний и крупный бизнес хранит множество данных в разрозненных источниках (CRM, ERP, HRM, базы данных, файловые хранилища и т.д.). Каждая из этих систем самодостаточна и закрывает определённую боль бизнеса, но собрав данные из таких источников и стандартизировав их, нам открывается возможность анализировать данные, строить модели машинного обучения и принимать на основе этих данных управленческие решения. Для того чтобы реализовать такой подход строятся ELT (или ETL) процессы. ELT (Extract, Load, Transform) — это процесс, состоящий из трех этапов:

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

Всем привет! Меня зовут Павел, я главный аналитик данных управления подготовки данных Банка.

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

В мире данных изменения — это неизбежность. Но как отслеживать и сохранять историю изменений, чтобы аналитика оставалась точной и релевантной? В нашей новой статье мы подробно разбираем концепцию медленно меняющихся измерений (Slowly Changing Dimensions, SCD) — ключевого инструмента для работы с изменяющимися данными в хранилищах и аналитических системах.

Вы узнаете, что такое медленно меняющиеся измерения и зачем они нужны, а также познакомитесь с разными типами SCD, такими как Type 1, Type 2 и Type 3. Мы рассмотрим их ключевые различия и приведем практические примеры использования: от простого обновления данных до сохранения полной истории изменений. Вы поймете, как выбрать подходящий тип SCD для ваших задач и избежать типичных ошибок.

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

Привет! Это команда Яндекс Практикума. Эксперты курса «Специалист по Data Science» поделились 12 статьями, которые помогут ближе познакомиться с разведочным анализом и основами статистики, — рассказываем о них и делимся ссылками.

Еще на этапе создания модели следует проделать работу направленную на замедление ее устаревания.

Реализацию процесса работы с устареванием моделей в ML можно разделить на 4 шага.

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

Мы пройдем полный путь создания модели и работы над замедлением ее устаревания.

Всем привет, меня зовут Евгений Мунин. Я Senior ML Engineer в Ad Tech в платформе ставок для рекламы. В этой статье мы познакомимся с Apache Kafka. Мы напишем демо пример Kafka Consumer'а на Python и запустим его в облачном сервисе Confluent Cloud.

В 2024 году популярными словами и постоянной темой для обсуждения в IT были большие языковые модели (LLM), обработка естественного языка (NLP), искусственный интеллект и создание ценностей. Однако вкатиться в эту экосистему без подготовки может быть довольно сложно. Давайте начнём с того, что рассмотрим понятие генерации с дополненной выборкой (Retrieval Augmented Generation, RAG), чтобы лучше понять эту технологию и возможность её использования в наших цифровых продуктах.

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

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

Что такое метрики оценки LLM, как их можно использовать для оценки систем LLM, а также распространенные ошибки и что делает метрики отличными.

Различные методы вычисления метрик оценки LLM и почему подход LLM-as-a-judge («LLM как судья») является наиболее эффективным.

Как реализовать и выбрать подходящий набор метрик оценки LLM с использованием библиотеки DeepEval (GitHub: DeepEval).

Как-то один из самых главных контрибьюторов в Airflow Ярек Потиюк рассказал, что Airflow 3 станет новым золотым стандартом индустрии. Это довольно смелое заявление. Я же считаю, что в Airflow 3  еще многого не хватает, чтобы действительно стать стандартом.

Если вы еще не знаете, что такое Airflow, то, к сожалению, это статья будет сложной. Давайте вместе освежим память.

Airflow - это платформа с открытым исходным кодом для написания и управления рабочих процессов. Airflow была основана в 2014 году в AirBnB. С тех пор платформа прошла путь до версии 1.0 в 2015 году, стала Apache Top Level Project в 2019 и плотно обосновалась как Enterprise Production-Ready в 2020 с версией 2.0.

Всем привет! Меня зовут Михаил, я руковожу разработкой хранилища данных «Магнит OMNI». Хочу рассказать, как мы решали проблемы его создания: разделение ресурсов хранилища между несколькими большими равнозначными заказчиками; переиспользование кода для оптимизации рутинных задач; развитие платформы DWH в условиях активно растущего бизнеса; навигация в сотнях витрин и соблюдение единообразия расчёта метрик.

Команда Python for Devs подготовила перевод статьи Клауса Вилке о том, почему Python, несмотря на статус языка №1 в data science, вовсе не идеален для анализа данных. Автор показывает на реальных примерах из лабораторной практики, что многие операции в Python оказываются куда более громоздкими, чем в R, — и это не вина программистов, а архитектурные особенности инструментов.

Большие языковые модели (LLM) стали основой современных ИИ-продуктов, обеспечивая работу всего - от чат-ботов и виртуальных ассистентов до исследовательских инструментов и корпоративных решений. Но LLM различаются по сильным сторонам, ограничениям и стоимости: одни лучше в рассуждениях, другие - в креативе, коде или работе со структурированными запросами. Здесь и нужен маршрутизатор LLM.

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

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

«Широкие» таблицы

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

Однако у этой простоты обнаружилась обратная сторона — избыточность. Представьте, что данные о сотрудниках и их работодателях хранятся в одной таблице. Если компания меняет название, то необходимо обновлять каждую запись, которая связана с изменяемой информацией. Это не только расточительно с точки зрения хранения, но и чревато аномалиями в данных. Также при увеличении количества данных в «широких плоских» таблицах возрастает и риск нарушения консистентности информации.

Сравнение ClickHouse и StarRocks: архитектура и функциональность, типы join и модели данных (широкая таблица vs звезда), конкурентность, частые обновления (Primary Key, Merge‑on‑Read), администрирование и онлайн‑масштабирование. Приводим результаты бенчмарков SSB и TPC‑H, а также тесты загрузки (GitHub dataset). Все тестовые данные и конфигурации актуальны на 2022 год. Если вам интересно, воспроизведите эксперименты по актуальным инструкциям проектов и поделитесь результатами и замечаниями — это поможет уточнить выводы и обновить сравнение.

Выпуск 448

Пределы космологии (The limits of cosmology)Authors: Joseph SilkComments: 23 pages, Gen Relativ Gravit 57, 127 (2025) 

Если вы думаете, что известный космолог-теоретик пишет про теорию, то вы ошибаетесь! Силк внезапно втопил за лунные проекты. И это не только низкочастотные радионаблюдения на другой стороне Луны, но и совершенно фантастические (очень дорого и сложно) проекты гравитационно-волновых детекторов (типа LIGO, Virgo) на Луне (там низкий сейсмический шум, и можно уйти на низкие частоты).

Радиопроекты могут быть реализованы в середине этого века. Гравволновые - точно нет. Но интересно, что Силк погружает все это в интересный и понятно описанный контекст космологических задач (отсюда и название статьи). Так что читать все равно интересно. Вот это и впрямь научная фантастика!

А еще… затронем ИИ и прочие захватывающие темы.

До сегодняшнего дня сборка и запуск AI-агентов напоминала джунгли. Разработчики метались между десятками несовместимых SDK, кастомных пайплайнов и ручных интеграций. Построить надёжного агента значило неделями клеить код, чинить баги в оркестрации и постоянно балансировать между скоростью и качеством. Теперь OpenAI предлагает другой путь — AgentKit, набор инструментов, который объединяет в себе всё, что раньше требовало десятков фреймворков и недель настройки.

Привет, Хабр! На связи снова Александр Токарев. И это третья часть из серии статей о том, почему в космосе нет дата-центров.

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

Привет, хабр! 👋

Позвольте представиться: я - Настя, Data Scientist и TeamLead в одной вполне себе серьезной компании (когда чистишь данные в 3 ночи, чувствуешь себя совсем не серьезно, но это детали). Веду свой скромный телеграм-канальчик, где делюсь болью, радостью и абсурдом нашей необъятной профессии. И вот сегодня хочу вынести на ваш суд тему, которая не дает спать спокойно не только мне, но и многим моим коллегам.

Помните тот трепетный момент, когда вы только начинали свой путь в Data Science? Я — очень хорошо. Картинка была радужной: ты — повелитель нейросетей, твои модели творят магию, а бизнес-задачи падают к ногам, поверженные точностью в 99.9% (ну или хотя бы 97%).

Курсы, будь то знаменитые онлайн-платформы или университетские программы, учат нас прекрасному: бустинги, метрики, градиентный спуск, SVM, k-means, сверточные слои... Это наш фундамент, наш джентельменский набор. И да, именно за этим набором охотятся 90% рекрутеров на собеседованиях. Создается стойкое ощущение, что я и интервьюер одновременно загуглили «Топ-50 вопросов на DS собеседовании» и теперь ритуально их отрабатываем. Ну, must have, что уж тут.

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

Одним из крупнейших сдвигов в современном софтверном девелопменте стало стремительное распространение AI-инструментов для написания кода. Эти решения помогают как разработчикам, так и людям без технического бэкграунда быстрее писать код, запускать прототипы и готовые приложения. Среди таких инструментов достаточно быстро привлёк внимание Cursor, почти сразу он занял позицию одного из лидеров рынка.

В этой статье я подробнее рассмотрю Cursor, его сильные и слабые стороны, а также сравню его с другими AI-редакторами кода. Это будет практический гайд, в котором я поделюсь своим опытом использования Cursor для создания to-do приложения. К концу материала у вас сложится четкое представление о том, подходит ли Cursor для вашего собственного девелоперского workflow.

Поехали.